AI产品的暗能量：没人预算过的后台计算

当你的AI功能上线时，你会制定延迟预算：模型调用需要多长时间、检索需要多长时间、完整请求的p99是多少。但你几乎可以肯定没有为那些在没有用户观察时发生的推理制定预算。

每个拥有持久化状态的AI产品都在后台运行不可见的工作。文档在上传时被预处理。长对话在会话边界处被重新摘要，以防下一个会话撑爆上下文窗口。主动建议按照没人刻意设定的计划表被生成。当有人更新模式时，嵌入向量被重新生成。这些都不会出现在你的延迟仪表盘上，通常也不在你的成本模型中，几乎从未被监控到。

这就是你AI产品的暗能量——那些解释了你的推理账单"应该是多少"与"实际是多少"之间差距的计算。

不可见推理的分类​

在你能为后台计算做好监控之前，你需要知道该寻找什么。这些类别比大多数团队预想的要多得多。

摄入时的预处理。 当用户上传文件时，需要有人把它转换成模型可以使用的形式。文档分块很便宜，摘要生成可不便宜。如果你的产品在上传时为每个文档构建摘要——用于上下文注入、语义索引，或者"这个文件里有什么"的功能——那个调用发生在任何面向用户的请求之外，通常在任务队列上。这是你的延迟监控不会捕捉到的推理，因为它在用户问题到达之前就已经运行了。

会话边界重处理。 维护对话历史的产品面临一个结构性问题：对话会变长，长上下文很贵，而下一个会话不应该继承80,000个token的历史。常见的解决方案是后台摘要——在用户返回之前将先前的对话压缩成紧凑的表示。这个推理在会话关闭时或计时器触发时运行，而不是响应任何用户操作。一个服务于一万名日活用户、每次对话有十轮的功能，每天产生一万次后台模型调用，这些调用永远不会出现在你的请求追踪中。

主动建议生成。 这是最有可能在没有刻意进行成本分析的情况下被添加的类别。有人希望"智能推荐"或"建议的后续步骤"在用户打开视图时立即出现。实现方式：提前生成它们，缓存结果，在打开时从缓存提供。按计划表、由数据变更或用户活动信号或定时任务触发的后台推理。延迟体验很好；成本是不可见的。

模式变更时的嵌入重生成。 向量搜索运行良好，直到你改变了索引内容。更新分块策略、切换嵌入模型、添加新的元数据字段——语料库中的每个文档都需要重新嵌入。在模型迁移时重新嵌入百万文档索引是一项可观的推理任务。团队通常会为所需时间做计划；他们很少为成本做预算，因为上次做这件事时语料库还只有现在的十分之一大。

评估和裁判调用。 LLM-as-judge架构调用一个模型来为另一个模型的输出打分。如果你的产品对采样输出运行质量评估，那些裁判调用就是后台计算。如果你运行生成候选答案并为其打分的改进循环，那些也是后台计算。用户看到一个响应；系统燃烧了三到五次模型调用来决定它是否足够好以展示。

为什么它从不出现在仪表盘上​

监控缺口有一个结构性原因：标准可观测性是以请求为中心的。追踪在请求到达时开始，在响应发出时结束。后台任务不符合这个模型。它们在队列上运行、按计划运行、由事件触发——没有任何东西将它们链接到用户请求ID。当你查看追踪浏览器时，你看到的是面向用户的推理。后台推理根本不在那里。

成本归因有同样的问题。如果你在追踪每次API调用的成本，你追踪的是源于用户请求的调用。调用嵌入API的任务队列工作进程不携带你的Web服务器所携带的相同请求上下文。成本积累在你发票上的同一行项目中，但每请求归因逻辑永远无法捕捉它。

结果是系统性的低计数。当你考虑到扇出、重试、裁判调用、改进循环、回退链和无界上下文增长时，真实系统为每个单一可见的用户操作产生15到40次模型调用。查看每请求token数量的团队看到的是实际支出状况的一小部分。其余的是后台、未归因、通常甚至没被认识到是需要预算的计算。

这解释了一个让许多团队感到惊讶的模式：功能在生产中的成本扩展速度远快于用户数量。用户不是驱动推理的唯一因素。后台任务随着数据量、语料库中的文档数量、需要重处理的会话数量、需要主动推荐的条目数量而扩展。这些东西增长的速度可能快于用户数量，而它们对每用户成本归因是不可见的。

将后台计算作为一级成本类别​

修复从命名开始。AI成本可观测性中最有用的区分是由用户操作触发的推理和不由用户操作触发的推理之间的区分。一旦你命名了这两个类别，你就可以分别度量它们，并对每个提出不同的问题。

对于用户触发的推理，相关问题是：每次用户操作的成本是多少，是否在我们设计的预算之内？对于后台推理，问题是：这个任务在做什么，它是否提供用户价值，那个价值是否足以证明其计算成本合理？