你的财务团队构建了一个精美的 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 支出中有很大一部分没有负责人，这在董事会报告中会显得很尴尬。
这个无人负责的篮子有一个反常的属性：它是最容易优化的一项，也是最难推动优化的。如果一个检索团队知道其重索引成本，他们会积极研究更小的 Embedding 维度、将新查询 Embedding 映射到旧空间的漂移适配器模式（drift-adapter patterns），以及将成本推迟到读取时间的惰性重新 Embedding（lazy re-embedding）策略。而一个不知道其重索引成本的检索团队，每个季度都会在没有审查的情况下运行相同的流水线，因为没有人过问。涉及的金额巨大，政治压力却是零。这种组合导致了账单滚雪球般地增长。
更糟糕的是，按功能仪表盘通过排除重索引成本，系统性地低估了每个依赖检索的功能的成本。支持副驾驶看起来很便宜，因为仪表盘只计算了它的 Token 支出。如果计算副驾驶真实的单位经济效益（Token 支出，加上检索调用，加上保持其查询索引新鲜的摊销成本），就会呈现出完全不同的景象。产品经理根据那个廉价的数字做资源决策。工程师根据那个廉价的数字在延迟与召回率之间做权衡。定价团队根据那个廉价的数字设定每个席位的利润空间。仪表盘对重索引成本的沉默并非中立；它积极地误导了每一个参考它的下游决策。
重新索引是资本支出，却被计入运营支出 理解重新索引最清晰的方法是借用物理基础设施的词汇：它是一项伪装成运营支出的资本支出。你一次性投入一大笔资金，而收益则在接下来的几个月里随着用户查询索引而逐渐显现。将这笔支出视为发生当月的单项运营成本，在会计上相当于在服务器上架的那一周就把购买服务器的费用全部抵扣掉。这会扭曲当月的账单，而且无法告诉你该资产在其使用寿命内是否赚回了成本。
做法正确的团队会将每次重新索引视为一个项目，拥有明确的成本、有效期和摊销计划。未来四个月的检索成本中包含了上一次重新索引成本的四分之一。支持 Copilot 的成本包含了它在摊销金额中占有的份额，并根据其在检索查询中的占比进行加权。在这种会计核算下，一个让 3 月份账单翻倍的重新索引，看起来与分布在 3 月到 5 月的重新索引大致相同，而这正是从用户角度出发的实际情况。仪表板不再谎称哪个月份是高支出的。
这种准则更难的部分是询问重新索引是否真的有必要发生。一个物有所值的重新索引是那些下游查询结果明显变好的——召回率可衡量地提高、幻觉可衡量地降低、延迟可衡量地减少。而一个不值得的重新索引，往往是根据日历进度而非测量结果触发的。大多数仔细审视的团队每年都会发现至少有一次重新索引属于第二类，而这种优化正是因为“无主分类”的存在让你无法发现的。
让重新索引成本变得清晰透明 解决这个问题不是工具问题；工具大多已经具备了。这是一个归因准则问题。通过三个具体的步骤可以将成本移出“无主分类”。
首先，使用与按功能划分的仪表板相同的词汇为重新索引作业本身打上标签。批处理流水线中的每个 Embedding API 调用都有一个元数据字段。填入语料库标识符和消耗该服务的特性，就像处理同步的用户触发调用一样。现在，重新索引就会出现在按功能划分的视图中，通过 event_type 为 reindex 与运行时调用区分开来，这样就可以对其进行过滤或摊销，而不会被误认为是日常流量。
其次，给语料库指定一个所有者。负责支持知识库的团队也负责重新向量化的成本。如果语料库是跨功能共享的，则按查询份额归因——如果支持 Copilot 消耗了 60% 的检索调用，它就承担 60% 的重新索引摊销成本。核算遵循消耗情况，这是分配共享资产唯一诚实的方式。
第三，将 Embedding 模型升级视为一个有预算的决策，而不是默认操作。升级的诱惑是真实存在的：新模型通常每 token 更便宜，在基准测试上表现更好。但与之抵消的阻力是现有语料库的重新向量化成本、验证新索引的工程时间，以及长尾查询中细微召回率下降的风险。一个能够列出权衡双方的决策框架，正是拥有“责任归属单项”所能带来的价值。而无主单项则得不到决策框架；它得到的只是自动续期。
隐藏在仪表板背后的领导力问题 看到这些，人们很容易将其视为一个通过更好的标签和仪表板就能解决的 FinOps 问题。这固然没错，但不完整。更深层的问题在于，工程组织有一种结构性惯性，即把难以分类的成本推入共享桶中，因为共享桶没有单一的预算所有者需要为其辩护。同样的本能将重新索引成本放入“基础设施”，将共享 GPU 池放入“基础设施”，将跨团队的可观测性支出放入“基础设施”，将 LLM 网关本身也放入“基础设施”。这些分类中的每一个都具有与 Embedding 重新索引相同的属性：耗资巨大、没有政治压力、无需审查。
领导层的举措不是建立更好的仪表板。而是决定任何 AI 成本项都不能处于无主状态，并在成本出现之前就指定所有者。从设计上讲，基础设施分类应该是空的，这并非因为成本消失了，而是因为每项成本都被推到了一个必须有人关注的栏目中。这种准则区分了两种组织：一种组织的 AI 支出随使用量线性增长，另一种组织的 AI 支出则随心所欲地增长，而仪表板却静悄悄地少报了那些无人负责的部分。
该成本仪表板将重新索引留在“基础设施”中时，它并没有撒谎。它只是如实报告了标签所标记的内容。谎言存在于上游——在于那种认为某些成本不需要有人负责，因为它们无法被清晰归因的默契。解决方案也在上游。确定谁拥有语料库。确定谁负责 Embedding 模型的决策。像标记面向用户的调用一样标记批处理作业。只要你给仪表板真相，它就会告诉你真相。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
