你的财务团队构建的那个排除了 Embedding 重新索引成本的成本仪表盘

你的财务团队构建了一个精美的 AI 成本仪表盘。Token 支出，按功能划分。Embedding 支出，按供应商划分。每个季度，按功能的面板都会在领导会议上接受审查，有人会问为什么支持聊天（support-chat）的工作流增长了 12%，而产品经理会给出一个合理的解释。每个季度，按供应商的面板都会在基础设施会议上接受审查，有人会问为什么 OpenAI 的支出增长了 8%，而平台工程师会给出一个合理的解释。然而，每个季度，真正让你 AI 账单翻倍的那一行——语料库重索引（corpus re-index）——却落入了一个名为“基础设施”的第三个篮子里，没有人审查它，因为没有人负责。

那个篮子是 40% 的 AI 支出在没有归属的情况下白白流失的地方。本可以优化它的团队从未见过它。而能看到它的团队却无法告诉你它是为哪个功能服务的。仪表盘对它能解释的所有成本都保持诚实，而对它无法解释的成本保持沉默，而这恰恰是至关重要的成本。

仪表盘构建的两个维度

按功能归属成本作为主视图是有道理的，因为它回答了高管们实际会问的问题：“这个支持副驾驶（support copilot）花了我们多少钱？”实现这一目标的架构举措很小——在每个 LLM 调用上打一个 feature_id 标签，通过网关传播，并每晚进行汇总。在 2026 年撰写关于 LLM FinOps 的从业者们不断回到这个决定，因为这是决定按功能核算是否可能的唯一一行代码。

按供应商归属作为第二个维度也是合理的，因为采购团队负责供应商关系，并需要根据实际数字进行谈判。OpenAI、Anthropic、Voyage 的费用都在这里汇总。基础设施团队可以比较单价，与客户代表沟通，并决定何时进行迁移。

这两种视角都是正确的。两者都很有用。但两者都看不到季度的重索引支出。

原因是结构性的：重索引（re-index）不是一个请求（request）。它不会带着 feature_id 请求头通过你的网关。它不会出现在你的单次调用遥测数据中。它作为一个批处理作业运行——由平台工程师发起，通常在非工作时间，针对一个不属于任何单一产品团队的语料库——并在每月一号作为供应商发票上的一个巨大的分列项目计费。你的按功能仪表盘看不到它，因为没有任何东西标记它。你的按供应商仪表盘能看到它，但无法说明它的用途。

为什么重索引才是真正花钱的地方

数字因技术栈而异，但模式是高度一致的。使用前沿 Embedding 模型对一亿个 Token 的语料库进行重新 Embedding，仅 API 费用就在 5,000 到 15,000 美元之间，这还不包括读取、分块（chunking）和写回向量数据库所消耗的计算资源。因为语料库会发生偏移，每季度执行一次；每当你升级 Embedding 模型时，再做一次；每当你更改分块策略时，再做一次。于是你就有了一项经常性开支，它超过了所有小功能整个月的 Token 支出总和。

实际支付过这些账单的团队报告了同样的模式：基础设施成本的增长速度超过了单次调用成本，因为单次调用成本是可见的且得到了优化，而批处理成本是不可见的且无人问津。撰写关于内部存储系统隐藏成本的工程师指出，Embedding API 的价格微不足道——每百万 Token 仅几分钱——但运行重索引流水线的运营税、向量数据库的出网流量、存储周转、以及验证所需的工程师人周，使这些成本比 API 账单高出一个数量级。OpenAI 账单上的那个标题数字其实是实际成本中最小的一部分。

当你询问运行重索引的团队它发生的频率时，你会得到类似“每个季度左右”的答案。当你问为什么是每个季度时，你会得到类似“因为模型版本更新了”或“因为索引质量下降了”或“因为我们想尝试更小的 Embedding 维度”之类的回答。这些答案没有一个与产品路线图挂钩。重索引的节奏是由 Embedding 模型的发布时间表和发现召回率下降的平台工程师的耐心决定的，而这两者都不是预算负责人。

名为“基础设施”的篮子是所有权隐藏的地方

云成本报告中有一个从业者们疲惫地描述的反复出现的模式：被归属的成本是有人有理由去归属的成本。按功能支出被归属，是因为产品经理需要合理的预算。按供应商支出被归属，是因为采购在谈判中需要筹码。其他一切都落在残余的篮子里——称之为“基础设施”、“平台”或“共享”——它们在构造上就是无人负责的。这个篮子之所以存在，是因为如果不这样，就得承认你的 AI 支出中有很大一部分没有负责人，这在董事会报告中会显得很尴尬。

加载中…