8.0
热点
AI SCORE
编程提效2026-08-10 01:01
生产级 LLM 成本拆解：建立 Trace Budget 的六步法
dev.to · AI#LLM 成本#工程实践#生产级 AI
Editor brief · 编辑速览
文章指出 LLM 可观测性成本由 Trace 量、Span 密度、Eval 采样率、Judge Token 等多变量共同决定，需先建立 Trace Budget 再比较供应商方案，并给出可抄走的成本计算模板。
LLM 可观测性成本并非单次 trace 的单一价格，而是多个工作负载乘数的总和：请求变为 trace，trace 包含 span，被选中的 span 成为评估任务，judge 消费 token，负载占用存储，而保留策略使这些字节在时间维度上持续计费。
实际的解决办法是在比较供应商方案之前先建立 trace 预算。从六个可以在自己应用中测量的变量入手：每月 trace 数、每个 trace 的 span 数、每个 span 的字节数、评估采样率、每次评分的 judge token 数，以及保留天数。只有将这些单位转换为实际工作负载后，才能判断某个供应商层级是否负担得起。
TL;DR：分别预测事件、字节、评分、judge token 和保留数据，然后用同一份 trace 预算去套用每个供应商的计费表。永远不要把层级名称当作等量的物理单位来比较。
本文面向在生产环境中运行 LLM 功能的工程师和技术负责人。文章提供了一个可操作的工作示例、一份可复制的预算收据，以及防止成本静默增长的防护栏。
trace 代表一次端到端交互，但它可以包含数量不固定的观测事件。一次简单的检索请求可能产生用于编排、embedding、向量搜索、重排序、生成和工具调用的 span。如果加上重试或并行工具，相同的用户请求可能产生更多事件，但请求数并未增加。
这就是 AI 可观测性定价的第一个陷阱：两个系统每月都有 100,000 条 trace，但摄入量可能差异巨大。一个系统平均每条 trace 产生 3 个 span；另一个可能平均产生 18 个。如果平台按观测事件、处理的字节数或两者联合计费，"trace 数量"只是第一个输入变量。
因此，预算应该建立在生产 AI 工程工作流内部——功能所有权、插桩、评估和支出应该在同一边界内共享。否则，应用团队控制 trace 形态，而独立的基础平台团队在乘数已经改变之后才能收到账单。
将账单视为四个独立层级。平台可能会将其中某些捆绑销售，但你的模型应该将它们分开。
摄入层由事件或字节驱动。其有用变量是每月 trace 数、每个 trace 的观测数，以及每个观测序列化后的字节数。完整记录 prompt、工具参数、检索到的文档和输出可能使字节量增长远快于事件数。
保留层是一个体积×时间的问题。将 1 GB 存储 90 天消耗的容量大约是将相同月流入量存储 30 天稳态容量的三倍。索引、副本、压缩和供应商特定的核算方式可能改变账单，但不会消除底层的时间乘数。
评估层添加评分。一条 trace 可以接收零条、一条或若干条来自确定性检查、人工审核或 LLM-as-a-judge 工作流的评分。例如，Braintrust 的定价模型将处理的数据、评分和保留作为独立的计量项暴露出来。这种分离提醒我们：捕获一条 trace 和对它进行评判是不同的操作。
LLM judge 产生了另一轮模型调用。其输入可能包括原始 prompt、响应、检索到的上下文、评分规则和参考答案。因此，可观测性平台的评分计量表和模型供应商的 token 费用是同一评估任务的两个不同成本行项目。
先使用一个供应商无关的方程：
monthly_observability_cost =
ingestion_cost(events, bytes)
+ retention_cost(bytes, days)
+ evaluation_platform_cost(scores)
+ judge_model_cost(input_tokens, output_tokens)
当变量按 trace 量的 LLM 可观测性成本模型排列时，变量更容易审计，因为每个转换假设都紧邻它转换的计量表。为每个功能记录以下六个输入：
不要用零替代未知值。标记为未知，添加一个插桩任务，然后计算一个范围。建立在缺失乘数上的精确总数远不如一个明确的范围有用。
考虑一个具有以下规划假设的应用：
换算过程很直接：
observations = 100,000 × 6 = 600,000
raw_ingestion = 600,000 × 2 KB = 1.2 GB/month
scores = 100,000 × 10% = 10,000/month
judge_input = 10,000 × 1,200 = 12,000,000 tokens/month
judge_output = 10,000 × 120 = 1,200,000 tokens/month
在稳定摄入率下，将原始保留期从 30 天增加到 90 天，会将保留的原始数据估计值从约 1.2 GB 提高到 3.6 GB（供应商特定的压缩、索引和副本因素之前）。将评估覆盖率从 10% 提高到 25% 会将每月评分数量从 10,000 增加到 25,000，并将两条 judge token 线路都乘以 2.5。
这些不是市场价格，而是工作负载单位。只有在这个转换之后才应用当前的供应商费率，并将费率保存在单独的配置中，这样价格变动就不会重写工作负载模型。
只显示总金额的仪表板无法解释变化。记录导致变化的维度：功能、环境、模型、trace 名称、观测类型、评分名称和保留类别。
Langfuse 的 trace 结构指南描述了按 trace 分组的观测，并建议在 generation 观测上携带模型、用量和成本详情。稳定的名称很重要，因为重命名一个 generation 可能破坏一个成本序列，即使应用本身仍在正常工作。
Token 覆盖率也需要自己的可靠性指标。OpenTelemetry GenAI 属性注册表指出，插桩应该尽最大努力填充输入 token 用量。在实践中，这意味着要跟踪具有可用 token 计数的 generation span 百分比。源自 62% 覆盖率的总计不应该被呈现为完整账单。
当 p95 spans per trace 超过预期边界时发出告警。这可以在月度账单到来之前捕获重试循环和意外嵌套的插桩。
对所有发布候选版本和高风险路径进行评分，然后对常规生产流量进行采样。固定的 100% judge 率很少是唯一有用的策略。
只在调试或审计需要的时间内保留原始负载；当脱敏摘要和聚合指标保留了必要信号时，让它们保留更长时间。
在每个成本估算旁边报告 token 覆盖率和字节覆盖率百分比。缺失的遥测是不确定性，不是免费用量。
每当 prompt、工具图谱、模型、评估器或保留策略发生变化时，都要审查这些防护栏。每一项都可能改变账单而不改变请求量。
将假设与结果放在一起：
period: 2026-08
feature: support-agent
monthly_traces: 100000
spans_per_trace:
p50: 5
p95: 9
bytes_per_span: 2048
evaluation_sample_rate: 0.10
scores_per_sampled_trace: 1
judge_tokens_per_score:
input: 1200
output: 120
retention_days:
raw: 30
aggregate: 365
coverage:
token_usage: 0.98
serialized_bytes: 1.00
将这份收据与插桩配置一起做版本管理。当估算发生变化时，diff 应该揭示是流量、trace 形态、评估策略、token 用量还是保留策略导致了变化。
没有普遍适用的最大驱动因素。事件密集型的 agent 工作流会放大 span 数量，冗长的负载会放大处理的字节数，宽泛的 judge 覆盖率会放大评分和模型 token，长保留期会放大存储。在优化其中一个之前，先对工作负载的四个层级进行测量。
通常不需要用昂贵的 LLM judge 来评估。有意地对高风险路径和发布候选版本进行评估，然后以能够检测有意义的回归的速率对常规流量进行采样。确定性检查和用户反馈可以覆盖更多 trace，而无需为每个请求支付 judge 模型推理费用。
每月重新计算一次，并且在模型、prompt、工具图谱、评估器、采样规则、负载策略或保留期发生变化时重新计算。这些变化可能改变观测、字节、评分或 token，即使用户流量保持平稳，因此仅监控请求数会错过这个转变。
当每个价格都关联到一个可测量的单位，且每个未知值都保持可见时，LLM 可观测性成本估算才变得可辩护。统计 trace，将其展开为观测和字节，应用评估覆盖率，计算 judge token，并将存储扩展到实际保留窗口。
然后用同一份收据比较供应商。最便宜的层级名称不是答案。真正的答案是适合你测量得到的 trace 预算的方案，并且不会隐藏最可能增长的乘数。