向量嵌入的隐性成本清单

推理有价目表，所以它容易被建模。运行一个 AI 功能的其它成本出现在四张不同的账单上，没有一张写着"AI"字样，而这正是精心核算的账单仍然超出预期的原因。

三个结构性原因，知道它们就知道该往哪里看。它们记在别人的预算下——向量数据库在基础设施账单上，日志摄入在可观测性合同里。它们单笔很小、总量很大，所以单独拎出来都通不过"值得建模吗"的测试，合在一起才通过。而且其中几项的规模取决于一个没人关注的变量：语料库大小、保存期限，或者评估运行次数——这些都不会出现在按请求计费的成本模型里。

实际后果是没有人对总额负责。知道推理账单工程师看不到存储那行；看到存储那行的平台团队不知道那是由 AI 功能导致的。所以第一步根本不是优化——而是调出同一月份的四张账单，把每一行归因到具体功能。这个动作花一个下午就能完成，这是让下面的数字变得真实而不是借来的唯一方式。

ingest_cost = corpus_tokens * P_embed / 1e6

50M tokens at an assumed $0.02 per million = $1.00

一美元。嵌入几乎从来不是问题所在，值得算一次让对它的恐惧不再影响架构。真正贵的是嵌入所隐含的东西。

raw_bytes = n_vectors * dims * bytes_per_element
stored    = raw_bytes * index_overhead     (roughly 1.5x - 2x)

5,000,000 chunks * 1,536 dims * 4 bytes = 30.7 GB
at 2x overhead                          = ~61 GB
at an assumed $0.25 / GB-month          = ~$15 / month

这里数字很小，而且它随语料库线性增长，而你的收入未必。两个值得在规模变大之前掌握的杠杆：量化为 8 位或 4 位元素可以把第一项削减 4 倍或 8 倍，同时召回率损失不大；更小的嵌入维度按比例削减成本。两者在设计时选择都比日后迁移要容易得多。

bytes_per_request ~= (T_in + T_out) * 4     bytes per token, roughly
monthly_GB        = requests * bytes_per_request / 1e9

200,000 requests at 3,000 tokens = 2.4 GB / month  (object storage: pennies)
                                    but on a $2/GB ingest platform: ~$5/month

At 10M requests / month:  120 GB  ->  $240 / month on the same platform,
and it accumulates if retention is longer than a month.

这里重要的数字是日志落地的每 GB 价格，在对象存储和按摄入计价的可观测性产品之间相差两个数量级。对 body 做采样——1% 保留完整文本，所有保留 metadata——是标准解决方案，而且通常不会损失你真正需要的东西。

eval_cost = cases * models * runs_per_month * cost_per_case

400 cases * 3 models * 40 runs * $0.01 = $480 / month

每个触发这套评估的 Pull Request 就是一次评估运行。这行随工程活动增长而非随流量增长，这意味着它在产品最小时反而最大——而且这是这里你最不愿意削减的一行，因为它阻止的是昂贵的错误。

review_cost = requests * review_rate * minutes_each / 60 * hourly

200,000 * 2% * 0.5 min / 60 * $25 = 4,000 * 0.00833 * 25 = $833 / month

对 2% 的输出每条审核三十秒，成本大约相当于产生它的推理费用的可观份额。如果你的质量策略涉及人在回路，这个决定就是商品成本决策，应该放进利润率模型，而不是放在质量文档里。

计算你自己的份额

没有正确的百分比。份额是多少取决于你的资产清单，而且在没有检索的聊天产品和有审核队列的文档平台之间差异巨大。所以自己去算：

non_inference_share = other / (inference + other)

Assembled from the assumed figures above, for a product
spending $8,000 / month on inference:

  embeddings, amortised .....    $50
  vector storage + query ....   $180
  logs and traces ...........   $240
  egress ....................    $90
  evaluation and dev ........   $480
  moderation ................   $120
  human review ..............   $850
                       other = $2,010

share = 2,010 / (8,000 + 2,010) = 20.1%

在上述那组假设下是百分之二十。换一个假设——没有人工审核的产品降到 13%；在十倍体量的按摄入计价日志平台上的产品则远远超过 30%。跑你自己的资产清单而不是借用这一个；这是一个下午加四张账单的事，这是唯一真实的数字版本。

自己会增长的那些

大多数行与流量成正比，因此在预测中表现可期。有三个不是，它们才是制造意外的：

存储会累积。日志和向量是存量，不是流量。恒定的请求速率会产生单调递增的存储账单，除非有保留策略，而"我们以后再加保留策略"就是小行变成大行的路径。在创建桶的时候就设定策略。

语料库增长是客户变量。向量存储随客户上传的东西 scale，这与他们付多少钱无关，除非你让它们关联起来。一个拥有大型档案的企业客户在存储上的花费可能超过推理费用。

重建索引是阶梯函数。更换嵌入模型意味着重新嵌入一切并重建索引——这笔成本一年中是零，然后一周内变成可观的量。把它作为偶发项目做预算，并注意它的规模随语料库增长，所以你越推迟它代价就越大。

最后说一下 egress，因为这是人们最难相信的一项。把数据移出云是按 GB 定价的，跨区域移动通常也是。如果你的应用跑在一个云而你的模型在另一个，每个请求会跨越那个边界两次。它单次请求很小，值得查一次，因为做同地部署通常免费，而事后补救则代价不菲。