Embeddings 价格计算器

估算 OpenAI / Voyage / Cohere / Gemini / Mistral / Together 等 15+ 嵌入模型的初始索引构建成本和月度查询成本。同时提供维度数、最大令牌和 MRL (Matryoshka Representation Learning) 支持情况的完整列表。

完全免费无需注册浏览器内完成 5 种语言深色模式

⚠ 2026-04 价格 OpenAI · Voyage · Cohere · Google

相关: 🪓 RAG 切分器 · 🪙 LLM Token 计数

📚 索引构建

文档数 token/文档

🔍 查询

月查询 token/查询

📊 概要

索引输入

0 tokens

月查询

0 tokens

模型	维度	Max tok	$/MT	索引费	月查询费	合计	MRL

※ 价格截至 2026-04。MRL = Matryoshka Representation Learning（维度可以事后削减）。

📖 常见的坑

按文档量与模型估算 Embedding 的初次构建成本与每月检索成本。处理全部在浏览器内完成。此处给出的仅是 API 费用——真实的 RAG 总成本还包括向量数据库的月费、重新嵌入（重建索引）的费用，以及把检索结果送入 LLM 的推理成本。在多数架构中，最后这项推理成本是 Embedding 的数十倍。

情形	会发生什么	怎么处理
只看初次构建成本就下决定	得知嵌入 10 万篇文档只需几美元确实让人安心，但那个数字只发生一次。真正会累积的，是文档每次更新时的重新嵌入与每条检索查询的嵌入。若每天 1 万次查询，就是每月 30 万次查询嵌入，持续不断。	请把三项分开累加：初次构建 × 1、更新量 × 频率、查询 × 月次数。查询嵌入每条只有几十个 token，因此为查询改用更便宜的模型看似诱人，但文档侧与查询侧必须使用同一模型——向量空间不同，距离就失去意义。若同一模型提供降维选项，那才是可行的调节杆。
选择维度最高的模型	维度数会直接影响向量数据库的存储容量与内存占用。3072 维以 float32 保存，每个向量 12KB，100 万条就是 12GB；1536 维减半，768 维再减半。相比 API 费用，这部分存储成本往往在后期更为致命，检索速度也会随维度上升而变慢。	请先用较小的维度构建并测量精度，不够再往上加。多数场景 768~1024 维已足够。支持降维的模型可在不更换模型的前提下降低输出维度，返工成本很小。当存储规模成为瓶颈时，还可以把 float32 量化为 int8，体积降为四分之一，而精度损失通常只有几个百分点。
没有考虑更换模型的成本	更换嵌入模型会让已有的全部向量作废。向量空间不同，把新旧混在一起测距在原理上就没有意义。因此必须对全部文档重新嵌入，等于再付一次初次构建的费用。模型换代周期是一到两年，所以这不是「会不会」，而是「什么时候」的问题。	请从设计阶段起，就把「由哪个模型生成」与向量一并保存。迁移时能否分辨出旧世代，直接决定工作量。同时请务必保留原始文本——重新嵌入需要原文，若只丢弃了分块，就得从重新获取文档开始。迁移时让新旧索引并行运行、比较检索质量后再切换更为稳妥。

降低成本最有效的手段，是从一开始就减少需要嵌入的量。与其把全公司文档一股脑放进去，只放真正会被检索的范围，既便宜又快、准确率还更高——无关文档越多，混入检索结果的噪声也越多。也请避免每次更新就全量重嵌：为每篇文档保存哈希，只对内容变化的部分重新嵌入，日常成本就会大幅下降。切分设计整理在 RAG 文本分块器，token 估算见 Token 计数器。

📖 使用方法

1

索引大小

文档数 × token
2

月查询量

查询 × token
3

比较

成本/维度/精度

❓ 常见问题

一次？

初次 + 增量

维度选择？

512-1536, MRL 可裁剪

开源？

BGE/E5/Nomic 免费

🐛 此工具出现问题了吗？

免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。