前言

不少团队上线LLM应用后，都遭遇过API账单莫名暴涨的困境。文中分享了一个真实运维案例：某线上LLM应用24小时调用成本，较上周同期暴涨47%，监控只能看到Token总量曲线飙升，却无法追溯是哪个用户、哪项功能、哪款模型造成消耗。

运维人员只能耗费4小时逐行翻日志、核对时间戳，才定位到新上线RAG功能未做分片大小限制，单次请求输入Token直接飙到120K。如果提前搭建Token粒度可观测体系，这类故障本可5分钟内快速定位。本文完整复刻工程落地全流程，保留核心参数、代码实现与生产方案，带你从零落地LLM链路追踪与成本归因能力。

一、为什么LLM必须做Token级可观测性

传统Web可观测性以HTTP Request为最小单位，但这套逻辑完全不适用于LLM应用。LLM一切核心指标都围绕Token展开：计费按输入输出Token分开计价、生成Token数量决定接口延迟与TTFT耗时、上下文窗口利用率影响模型输出质量，业务限流也以TPM每分钟Token数作为基准。

Token级可观测性，就是追踪每一次大模型调用的Token消耗、归属用户、业务场景与实际成本，是LLM应用专属的工程能力。 对比传统Web APM，LLM可观测性有着明显差异：以Token为度量核心、直接关联计费成本、原生适配SSE流式输出，同时覆盖多模型路由、语义缓存等独有场景，传统监控框架直接套用极易水土不服。在多模型调度架构中，借助TreeRouter等大模型API聚合平台做智能模型转换时，也依赖标准的Token追踪数据，实现负载均衡与成本优化。

二、基于OpenTelemetry GenAI搭建标准化Trace

随着OpenTelemetry GenAI语义规范正式进入稳定版，行业有了厂商无关的LLM链路追踪标准。通过标准化Span属性，可统一记录模型标识、Token用量、请求参数与响应元数据。

核心埋点属性代码如下：

span.set_attributes({
    "gen_ai.system": "dashscope",
    "gen_ai.request.model": "qwen-max",
    "gen_ai.usage.input_tokens": 1250,
    "gen_ai.usage.output_tokens": 380,
    "gen_ai.request.temperature": 0.7,
    "gen_ai.request.max_tokens": 1024,
    "gen_ai.response.finish_reasons": ["stop"],
    "gen_ai.response.id": "chatcmpl-abc123",
})

真实LLM调用链具备清晰Span层级，一次用户请求可拆解为主模型对话、向量嵌入、二次摘要等多个环节，精准统计各环节Token消耗。工程上可采用自动埋点+手动埋点结合模式：自动Instrumentation适配主流大模型SDK，手动埋点补充用户ID、租户、功能标识等业务维度，为后续成本归因打下基础。

三、流式场景Token计数三大解决方案

生产环境LLM普遍采用SSE流式输出，但原生流式接口存在一大痛点：分片数据仅返回增量内容，不携带最终用量；若网络中断、客户端主动取消，完全无法获取官方Token统计数据。

文章给出三套可落地方案： 方案一依托厂商接口原生include_usage参数，在最后一个分片获取精准Usage数据； 方案二基于本地Tokenizer实时累积文本计数，规避BPE分词跨分片边界误差； 方案三搭建LLM Gateway代理层，在网关统一采集请求与完整响应，业务代码零侵入，是生产环境最优选择。

同时文中给出流式计数器核心实现思路，必须累积完整文本再重新编码统计，不能逐分片累加，避免分词误差。

四、Cost Attribution四维成本归因：将Token转为可视账单

采集Trace数据后，核心是搭建User、Tenant、Feature、Model四维归因模型，从用户、租户、业务功能、模型四个维度拆分消耗。既能定位高消耗用户、做多租户配额管控，也能对比不同功能、不同模型的成本与收益。

内置定价表按主流模型输入、输出、缓存分词差异化计价，通过换算公式将Token消耗转为实际费用，同时兼容缓存Token折扣抵扣。生产采用实时估算+异步对账双轨制：网关层实时粗略计算用于告警限流，每小时通过链路数据库精准对账，兼顾低延迟与计费精度。

五、生产环境核心策略与取舍

落地过程需要平衡采样策略、计数精度与隐私合规三大问题。 采样采用异常全采、常规抽样：错误请求、延迟超10s、单次Token超50K请求100%留存，普通请求按10%抽样，控制存储成本的同时不丢失故障线索。

Token计数不追求绝对一致，以厂商返回数据为基准，本地Tokenizer仅作流式中断兜底，并在看板标注数据来源类型。 隐私合规实行分级管控：开发环境完整记录对话原文，生产对内工具脱敏存储，面向外部用户仅留存Token与元数据，不记录Prompt和回复内容。

六、四阶段渐进式落地路线

团队可分四个阶段稳步落地：1-2周完成基础Trace采集，一周内注入业务维度并搭建Grafana成本看板，随后配置异常告警与租户配额，最后持续迭代趋势预测、模型选型分析与缓存命中率监控。整套体系落地后，成本异常排查可压缩至4分钟以内。

总结

Token级可观测性不是锦上添花的附加能力，而是LLM应用上生产的必备基建。没有Token粒度的链路追踪与成本归因，应用只能盲目运行，成本失控、故障难定位、资源浪费将成为常态。

依托OpenTelemetry标准化埋点、解决流式计数难题、落地四维成本归因，合理做好采样、精度与隐私平衡，按照渐进式路线搭建体系，就能让LLM应用实现成本可查、故障可定位、资源可管控、优化可量化，为业务长期稳定迭代筑牢工程基础。