Embedding API 的 “隐藏税”：为什么向量支出在不知不觉中超过了生成成本

我在上个季度交谈过的一个团队在财务伙伴指出 AI 账单时陷入了短暂的恐慌。他们原以为，像大多数团队一样，昂贵的支出项会是生成——即聊天、总结和智能体推理背后的 GPT 级调用。事实并非如此。他们的每月 Embedding 支出在 1 月悄然超过了生成支出，到 3 月翻了一番，并有望在年中翻两番。没有人为此建模，因为 Embedding 模型的每 Token 定价看起来就像舍入误差：小型模型每百万 Token 2 美分，大型模型 13 美分。按照这个费率，谁会为此做预算？

答案是：任何产品度过了原型阶段并开始大规模索引内容的团队。在不断增长的语料库上进行语义搜索、重复检测、分类、聚类、更换模型时的重新索引——每一个工作负载消耗的 Embedding Token 都是以十亿计，而不是以百万计。与受用户请求限制的生成不同，Embedding 的吞吐量仅受你决定索引的内容限制。而这一决定很少经过成本审查。

本篇文章将探讨 Embedding 支出升级的具体机制、改变成本曲线的架构杠杆，以及从托管 API 转向自建服务的盈亏平衡计算。

为什么每 Token 的计算逻辑在欺骗你

对于中层 Embedding 模型，每百万 Token 0.02 美元，对 100 万个 500 Token 的文档进行 Embedding 的成本是 10 美元。这个数字锚定了人们的直觉。它感觉像是免费的。但生产环境下的工作负载不会停留在 100 万个文档，而且也不会对每个文档仅进行一次 Embedding。

以一个拥有 1000 万个用户生成文档、平均分块大小为 500 Token 的中型 SaaS 为例。在 Standard 层级上，首次索引大约需要 100 美元——这只是零花钱。现在加上最初预估漏掉的现实情况：每当文档被编辑时，你都会重新 Embedding 受影响的分块；每当在 Schema 中添加新字段时，你都会重新 Embedding 所有内容；每当你决定尝试更好的 Embedding 模型时，你又要重新 Embedding 所有内容。我听到的典型复盘是：“我们为了获得更好的召回率，从 text-embedding-3-small 升级到了更大的模型，单单重新索引的费用就超过了我们原来 6 个月的账单。”

随着规模扩大，数字变得惊人。即使使用廉价模型，对 10 亿个 1000 Token 的文档进行 Embedding 的成本也会达到六位数。运行持续去重、分类或语义缓存的团队——所有这些都是针对每个请求而非每个批次调用 Embedding 端点——很容易发现自己每月处理数百亿个 Token。在这种体量下，Embedding 成为了主要的推理成本，而不是一个可以忽略的细项。

陷阱在于，成本并非以峰值的形式出现。它随着你的索引线性增长，而你的索引随着用户增长而增长。生成支出有一个天然的限制（人类必须输入查询）。Embedding 支出没有天然限制——它受你的架构限制，而大多数架构根本没有任何限制。

主导账单的四种工作负载

当我审计 Embedding 支出时，总有四种相同的工作负载排在最前面。每一种都有团队低估的失效模式。

初始语料库索引。 团队实际会规划的一次性成本。易于建模，易于报销。在第一天基本无害，但它为其他一切设定了基数——如果你的语料库有 1 亿个文档，下游的每一个决策都会针对这个规模进行乘法运算。

持续摄入。 每次编辑、评论、消息或上传都会触发受影响分块的重新 Embedding。大多数团队的做法很简陋：在每次写入时计算 Embedding 并更新。在产品拥有大量编辑行为的用户之前，这没问题。版本历史、实时协作和高编辑率文档（笔记、聊天、草稿）使持续摄入成为主要成本，因为每次细微的编辑都可能触发对周围上下文的 Embedding。

模型或 Schema 变更时的重新索引。 这是没有人预料到的预算杀手。你不能在同一个向量空间中混合两种模型的 Embedding——几何结构是不兼容的，它们之间的余弦距离毫无意义。从一个模型系列升级到另一个意味着要重新 Embedding 所有内容。重大的分块策略变更、影响 Embedding 内容的元数据 Schema 迁移，或需要重新索引的距离度量变更也是如此。我给团队的经验法则是：每年预算一次完整的重新索引，并将任何更频繁的需求视为重新审视流水线的强制因素。

高 QPS 运行时工作负载。 语义缓存、搜索时的查询 Embedding、写入时去重以及实时分类都是针对每个请求计算 Embedding。这些随用户活动而扩展，而非随语料库大小扩展。当产品流行起来时，这一项会与 DAU 成比例增长，并可能在一夜之间超过摄入项。

这四种工作负载很少整齐地汇总在财务报表中，因为它们分散在各个服务中。索引流水线位于数据工程中，摄入流水线位于应用团队中，重新索引任务是计划外的单次任务，而查询时调用则在搜索服务中。孤立来看，每一项都很小。汇总起来，它们是预算中最大的推理支出项。

真正能够扭转局势的杠杆

有五种架构层面的调整能够持续产生显著影响。前三种成本较低；后两种则需要更多的投入。

对明显的重复内容进行哈希键缓存

大多数向量嵌入（embedding）流量都是重复的。同样的样板内容出现在数千份文档中；不同的用户会输入逐字相同的查询；同样的模板文本页眉出现在语料库的每一张发票上。在调用向量嵌入 API 之前设置一个内容哈希缓存——对规范化后的文本进行 SHA-256 哈希处理，并将向量嵌入结果作为值（value）存储——通常可以在流量到达 API 之前减少 30% 到 70%。这是你可以做的投资回报率（ROI）最高的改变，而且确实只需要一下午的工作。Redis 或列式键值（KV）存储可以廉价地处理数十亿个条目。

一个警告：不要在这里使用近似/语义缓存。那是另一个问题（针对 LLM 响应的语义缓存），对于向量嵌入去重来说它太“有损”了，因为你需要的是位级精确（bit-exact）的复用。精确匹配缓存，精确匹配命中。

激进地进行批处理，并将非紧急工作转移到批处理层

托管的向量嵌入 API 通常会提供大约半价的批处理层（batch tier），延迟容忍度最高可达一天。大多数摄取（ingest）和重新索引（reindex）工作负载并不需要亚秒级的向量嵌入延迟。通过批处理层进行路由，成本就能免费减半。只有查询时和写入路径的流量才需要标准层。

团队经常忘记，批处理还能提高吞吐量利用率。向量嵌入端点在大批量处理时运行效率最高；一次发送一个文档会使 API 和你自己的基础设施都处于低效利用状态。

使用套娃式向量嵌入进行截断

现代向量嵌入模型——OpenAI 的 text-embedding-3 系列、Nomic Embed、Gemini Embedding 以及大多数 2025 年发布的开源模型——都采用了套娃式表示学习（Matryoshka Representation Learning）进行训练。这意味着向量的前 N 维承载了大部分语义信号，而后面的维度承载的是递减的微调信息。你可以将一个 3,072 维的向量截断为 768、256 甚至 128 维，重新进行归一化，并保留非常接近完整向量的检索质量。

截断不会直接减少你的向量嵌入 API 账单，但它会大幅缩减下游的存储和查询成本。在大多数向量数据库中，维度削减 4 倍意味着存储成本削减 4 倍，查询成本也大致削减 4 倍，而这通常才是真正的开销所在。结合标量或二进制量化，团队经常报告向量侧成本降低了 70% 到 90%。Azure AI Search 发布了一项案例研究，将维度从 3,072 削减到 768，检索损失极小；类似的结论在各类内部基准测试中也屡见不鲜。

如果你的向量嵌入模型支持 MRL，截断实际上是“免费”获得的质量优化。诀窍在于记得对截断后的向量进行 L2 归一化——跳过这一步会使几何空间变得不稳定，并破坏基于余弦相似度的检索。

使用 CDC 和增量重新索引，而非全量重建

如果你必须重新索引，请采用增量方式。利用变更数据捕获（CDC）信号或文件差异（diffs）来驱动你的向量嵌入流水线——仅针对自上一个快照以来确实发生变化的行进行重新计算。对于大多数语料库，这可以将重新索引的成本降低一到两个数量级。唯一的例外是模型升级，这确实需要全量重新索引，因为来自不同模型的向量嵌入占据了不同的几何空间。

对于模型升级，蓝绿模式是标准的安全路径：在旧索引（蓝色）旁边构建新索引（绿色），原子化地切换查询，然后停用蓝色索引。这在迁移期间会使存储成本翻倍，但能为你提供零停机时间和回滚路径。另一种变体——试图将旧向量投影到新空间中的“适配层（adapter layers）”——虽然有人尝试过，但无法保证质量；建议还是计划重建。

当成本效益跨越临界点时，脱离托管 API

自行托管优于托管 API 的盈亏平衡点比大多数团队想象的要低。单张消费级 GPU（RTX 4090 级别，抢占式价格约为 0.34 美元/小时）每天可以使用 BGE-M3 或 Nomic Embed 等现代开源模型嵌入约 3,000 万个 token。这相当于每月约 9 亿个 token，计算成本约为 250 美元。

在托管 API 上，如果价格是每百万 token 0.02 美元，9 亿个 token 的成本是 18 美元。在这个规模下，托管 API 仍然更便宜。但在每月 100 亿个 token 的规模下，托管成本为 200 美元，而自行托管的成本……仍然是那张持续运行的 GPU 产生的约 250 美元。对于小型模型向量嵌入，原始计算的交叉点出奇地高。而大型模型向量嵌入（text-embedding-3-large 价格为每百万 token 0.13 美元）则是自行托管获胜最早的地方：大约在每月 20 亿到 50 亿个 token 之间。大规模嵌入多语言或代码内容的团队达到这一阈值的速度会比预想的更快。

诚实的警告：自行托管存在一些不会出现在竞价价格表上的隐藏成本。必须有人负责维护推理服务器、监控质量、处理模型升级并应对突发流量。发布的行业数据显示，运行一个自托管向量嵌入栈每月需要 15 到 20 个工程师小时。将其乘以你的综合人力成本。如果这个数字超过了你支付给托管 API 的费用，那就继续留在 API 上。

向量数据库占了账单的一半

Embedding token 的费用通常最受关注，但向量数据库才是剩下账单的大头。一个拥有 1 亿个 1,536 维向量的生产级索引，在计算任何索引结构之前，原始浮点存储大约就有 600 GB。按照托管服务的定价（高级层级大约每月 0.30 美元/GB），仅仅是存储就需要每月 180 美元，此外还要加上读写单元的费用。对于高查询负载的工作量，向量数据库的支出通常比 embedding API 的支出高出 3 到 10 倍。

那些有助于优化 embedding 的截断和量化手段，在这里同样有效。1-bit 二进制量化配合 MRL 截断可以将存储压缩 90% 以上，且对于大多数用例来说，其检索损失在可接受范围内。2026 年的共识模式是：根据你实际检索任务的离线基准测试结果，使用 MRL 截断到目标维度，然后根据对召回率的容忍度应用标量量化 (int8) 或二进制量化，最后只为你需要的存储付费。

自托管向量数据库胜过托管服务的临界点通常在每月 6,000 万到 8,000 万次查询左右。在此之下，考虑到运维成本，托管服务通常更便宜；在此之上，在固定价格的 VPS 或 K8s 上自托管通常能将成本降低 3 到 10 倍。请根据你的实际 QPS 而非峰值 QPS 进行计算，因为某些层级的托管服务是按预置的峰值容量计费的。

总结：决策框架

当有人问我如何在账单爆炸前建模 embedding 成本时，我会给出一套简单的流程。虽然这不怎么优雅，但它能捕捉到常见的错误。

首先，预测未来 12 个月的语料库增长，而不是当前的语料库规模。然后乘以预期的重新索引频率——每年一到两次重新索引是很常见的。接着，将查询时的 embedding 向量估算为 DAU 的函数，而不是语料库规模的函数（这是大多数团队都会忽略的一点）。最后加上向量数据库存储和查询吞吐量的成本——这通常是数额较大的那一项。

只有在完成这些步骤后，选择工具才有意义。如果预计每月支出在几千美元以下，托管 API 加上托管向量数据库就是正确的答案；节省的工程时间比那点溢价更有价值。如果预计支出每月超过五位数，就该认真评估 MRL 截断、量化、批处理层路由，以及可能需要自托管的 embedding 模型了。如果超过六位数，自托管就是一种责任而非选择了，早期做出的架构决策将产生多年的复利影响。

那些被打得措手不及的团队，往往是在成本微不足道时构建了架构，而在成本变得沉重时从未重新审视过它。Embedding 的支出就像数据库支出一样：在变得昂贵之前都很便宜，一旦变贵，在结构上进行调整的成本极高。为 18 个月后的账单做设计的时间点应该是你的产品开始规模化的那一天，而不是财务部门在 Slack 上发来忧虑信息的那一天。