可观测性税：当监控 AI 的成本超过运行 AI 本身

你的团队上线了一个 AI 驱动的客服机器人。它运行良好，用户很满意。然后月度账单到了，你发现监控 LLM 调用的基础设施成本比 LLM 调用本身还要高。

这不是假设。团队报告称，将 AI 工作负载监控添加到现有的 Datadog 或 New Relic 设置中，可观测性账单增加了 40-200%。与此同时，推理成本持续下降——GPT-4 级别的性能现在每百万 token 仅需 0.40 美元，而 2022 年末为 20 美元。监控技术栈还没有收到这个消息。

结果是一个倒挂现象，如果不是这么贵的话会很有趣：你花在观察 AI 思考上的钱比让 AI 思考的钱还多。

为什么 AI 遥测数据会让你的监控账单爆炸

传统可观测性是为遥测数据随流量线性增长的世界设计的。一个处理每天 10,000 个请求的 REST API 大约产生 10,000 个 span、一些日志和少量指标。可预测，可预算。

AI 工作负载打破了这一假设。单个 LLM 推理请求不会只产生一个 span——而是产生一连串的级联。

考虑一个每天处理 10,000 次对话的客服机器人：

• 每天 50,000 条用户消息
• 200,000 次 LLM 调用（每条消息大约 4 次调用，用于检索、分类、生成和验证）
• 每天 100 万个 span（每次调用约 5 个 span）
• 400 万个指标数据点（每次调用 20 个自定义指标：token 计数、延迟百分位数、成本归因、模型版本、temperature 设置）
• 每天 400 MB 的日志

这是同等传统服务的 10-50 倍遥测数据。在按量计费的平台上，每一个数据点都要花钱——按日志 GB 数、按百万 span 数、按自定义指标数。

Agent 架构使问题更加复杂。一个调用工具、生成子 agent 并执行多步计划的 agent 可以产生深度分支的追踪树。每个分支都会倍增你的遥测数据量。一个包含 10 个步骤、每步 3 次工具调用的 agent 工作流不会产生 10 个 span——而是产生数百个。

层层叠加的四个层次

大多数团队不是有意建立昂贵的监控栈的。他们逐步增加层次，每一层单独看都是合理的：

第一层：基础追踪和日志。 你需要知道 LLM 调用在生产环境中是什么样子的。合理。你用 OpenTelemetry 进行埋点，将追踪数据发送到 APM 平台。成本：适中。

第二层：成本归因。 财务部门想知道哪些功能和客户消耗了最多的 token。你添加了每请求 token 追踪、每用户成本汇总、模型版本标记。每个请求现在携带 15-20 个额外的元数据字段。成本：成倍增长。

第三层：质量评估。 你添加了 LLM-as-judge 评估来捕捉幻觉、相关性偏移和语调违规。即使以 5% 的采样率，你现在也在进行额外的 LLM 调用来评估你的 LLM 调用。成本：至少翻倍。

第四层：人工审核队列。 对于高风险输出，你将被标记的回复发送给人工审核员。管理这些队列、追踪审核员吞吐量和计算评估者间一致性的工具增加了另一个监控层面。成本：现在你在监控监控器了。

每一层都解决了真实的需求。但叠加在一起，它们创造了一个随流量超线性增长的可观测性账单——与推理成本的走势恰恰相反。

收益递减曲线

这让情况更加痛苦：每增加一个监控层的价值遵循一条急剧递减的曲线，而成本遵循线性（或更差的）曲线。

第一层给你 70% 所需的信号。你可以看到发生了什么，捕捉故障，调试失败。第二层增加大约 15%——你现在理解了成本驱动因素并可以优化。第三层再增加 10%——你在用户报告之前捕捉到质量问题。第四层增加最后的 5%——你拥有最困难案例的真实标签。

但成本不遵循这条曲线。如果你使用一个能力强的模型作为评判者，仅第三层——对生产流量运行评估——的成本就可能与第一层和第二层加起来一样多。第四层引入的人工成本超过了其他所有层。

陷入困境的团队是那些把监控当作二元选择的：要么有，要么没有。他们直接跳到所有四层的完整埋点，因为"可观测性很重要"，而没有问边际信号是否值得边际成本。

合理化监控的真正样子

解决方法不是停止监控，而是像对待推理架构一样，有意识地对待监控架构。以下是有效的策略。

分层采样而非全量采集

并非每个请求都需要完整的遥测数据。分层方法在不增加数据量的情况下提供统计覆盖：

• 头部采样 10-20% 用于正常请求。这为你提供了正常路径的可靠统计覆盖。
• 尾部采样 100% 用于错误、高延迟异常值和被标记的输出。你永远不想错过一个故障。
• 自适应采样，在检测到异常时增加采集率，在稳态时降低。

实施分层采样的团队通常将遥测数据量减少 50-70%，同时保留了调试每个重要事件的能力。

评估采样，而非逐请求评估

对 100% 的生产流量运行 LLM-as-judge 是团队做出的最昂贵的可观测性决策。对于大多数应用，异步评估 5% 的流量就能提供等效的质量信号。将 100% 评估保留给：

• 任何 prompt 更改后的前两周
• 已知存在质量问题的分段
• 触发现有启发式护栏的请求

异步部分也很重要。同步评估增加了每个请求的延迟，并使你的监控成为推理路径的依赖——如果评估模型宕机，你的产品就宕机了。

激进的保留策略

大部分可观测性支出用于存储没人查询的数据。行业数据显示大约 70% 的存储日志从未被访问。设置与实际使用匹配的保留策略：

• 详细追踪：7-14 天
• 聚合指标：90 天
• 评估结果：30 天
• 成本归因数据：12 个月（财务需要这个）

先整合再优化

工具蔓延是一个无声的成本倍增器。常见模式：Datadog 用于 APM，Langfuse 用于 LLM 追踪，自定义仪表板用于成本追踪，PagerDuty 用于告警，还有一个电子表格用于评估结果。每个工具按席位收费，它们之间的重叠是巨大的。

在中等生产规模（每月 5000 万 span，5 个用户）下，LLM 可观测性工具之间的定价差距令人震惊：同样的工作负载，从每月 129 美元到 5,170 美元不等，取决于你的供应商。使用开源工具（Grafana、Prometheus、Jaeger）自托管可以降低 90-97% 的成本，但你是在用工程时间换金钱。

决策框架

在添加任何监控层之前，执行以下检查清单：

• 这些数据能驱动什么决策？ 如果你无法说出基于数据你会采取的具体行动，你就不需要它。
• 每个洞察的成本是多少？ 将监控层的月度成本除以它产生的可操作发现数量。如果你每月为评估管道支付 3,000 美元，只捕获了 2 个真实问题，那就是每个捕获问题 1,500 美元。相对于让这些问题到达用户的成本，这值得吗？
• 采样能达到目的吗？ 几乎总是可以的。问题是什么采样率能给你关心的指标提供统计显著性。
• 这是上线关注点还是稳态关注点？ 许多监控层在变更后的头几周至关重要，但在稳态时是浪费的。建立自动降级策略。

基础设施镜像问题

这里有一个更深层的结构性问题。AI 推理基础设施受益于大规模竞争和优化——定制芯片、量化、推测性解码、激进缓存。每 token 的推理成本在三年内下降了约 50 倍。

可观测性基础设施没有经历这样的压力。主要平台仍然使用在遥测数据稀缺时代设计的按数据量计费模型。当单个 AI 请求产生比传统 API 调用多 50 倍的遥测数据时，你要为监控支付 50 倍的费用——即使请求本身的成本更低。

这个差距最终会缩小。OpenTelemetry 正在建立减少供应商锁定的开放标准。AI 原生的可观测性工具正在以理解基于 token 的工作负载的定价模型出现。随着开源替代方案的成熟，自托管变得更加实际。

但等待市场自行修复可能意味着在接下来的 12-18 个月里，你在监控上的花费超过推理。现在就进行合理化的团队——智能采样、激进保留、整合工具——将比那些因为能监控一切就监控一切的团队拥有有意义的成本优势。

像管理推理预算一样管理监控预算

心智转变很简单：将监控视为一个具有自身成本-性能权衡的工程系统，而不是一份买了就忘的保险。

你不会让每个推理请求都通过你最昂贵的模型。你将简单查询路由到小模型，将大模型留给困难案例。将同样的逻辑应用于可观测性：简单请求获得采样遥测，异常请求获得全量采集，评估保留给质量不确定性最高的案例。

做好这一点的团队将推理预算的 5-10% 花在监控上，捕获 90% 的问题。没做好的团队花费 200% 并捕获 95%。额外 5% 的覆盖率成本高出 20 倍。

是否值得取决于你的风险偏好——但至少要让它成为一个有意识的选择，而不是工具逐步叠加决策的意外结果。