当 AI 应用从原型进入生产环境，成本问题往往不再是“模型单价多少”，而是“哪项业务、哪个用户、哪条调用链正在消耗预算”。尤其在智能客服、知识库问答和 Agent 场景中，一次业务请求可能包含多轮推理、检索、工具调用与失败重试。选择成本监控与 Token 优化工具时，不能只看仪表盘是否美观，而应考察计量准确性、调用链追踪、预算治理和优化闭环能力。
先明确需要监控什么
最基础的数据是输入 Token、输出 Token、缓存 Token、模型名称、调用次数、响应时间和错误状态。由于不同模型、部署方式及输入输出类型可能采用不同计费规则，成本计算应使用可维护的价格配置，而不是把单价写死在业务代码中。对于 Azure OpenAI，还要区分按量付费、预配吞吐量和批处理等模式；实际价格可能受区域、协议与币种影响，因此预算测算应以Azure OpenAI 定价页面为准。citeturn1search7
生产环境还应记录应用、租户、用户、项目、功能、模型版本和提示词版本等标签。只有把 Token 消耗关联到业务维度，才能回答“哪个功能成本最高”“一次成功任务平均花费多少”“某次发布为何导致支出上升”。如果系统采用 Agent，监控粒度应深入到每一步模型调用和工具调用，而不是只统计入口请求。
工具大致分为四类
一、模型厂商自带控制台
厂商控制台适合快速查看账户级用量、账单和额度，部署成本低，也通常最接近最终结算结果。缺点是跨模型、跨供应商和跨业务归因能力有限，难以还原一次复杂任务内部的多次调用。它适合个人项目、验证阶段，以及作为财务对账的数据来源，但不宜成为大型应用唯一的监控手段。
二、云成本管理平台
如果模型服务主要运行在 Azure 等云平台，可利用云账单、预算、标签和告警能力进行统一治理。这类工具擅长从订阅、资源组和资源层面控制总支出，也便于纳入企业 FinOps 流程。不过，云账单通常难以直接解释某个提示词、会话或 Agent 步骤为何昂贵，因此仍需要应用侧遥测进行补充。
三、LLM 可观测性平台
这类平台通常能追踪提示词、响应、Token、延迟、模型参数、会话和调用链，并按用户、标签或应用聚合成本。例如 Langfuse 支持记录生成与嵌入调用的用量和成本，可使用模型定义推算费用，也能接收应用直接上报的实际数据；其指标接口还可以服务于分析、计费和限流。具体能力可参考Token 与成本追踪文档。citeturn1search13turn1search14
选择此类产品时，应重点验证是否支持当前 SDK 和框架、能否自托管、是否提供数据脱敏、权限控制、保留周期和数据导出。还要确认它如何处理流式响应、缓存 Token、推理 Token、图像或音频用量，以及模型价格变更后的历史账单。平台自动推算的费用适合运营分析，但财务结算仍应与供应商账单核对。
四、自建遥测与数据仓库
对多供应商、大规模或强合规团队，可在模型网关统一采集 usage 字段，再将指标发送到 OpenTelemetry、日志平台或数据仓库。OpenTelemetry 的生成式 AI 约定正在定义模型、操作、输入输出 Token 和延迟等标准化属性，有助于降低监控后端绑定风险，相关规范可查看生成式 AI 指标约定。citeturn1search19turn1search24
自建方案控制力强，能够结合内部结算、配额和审批系统，但需要持续维护采集器、价格表、数据质量与可视化。如果团队尚未具备平台工程能力，建议先用成熟产品验证指标体系，再逐步建设统一数据层。
选型时重点比较的能力
- 计量准确性：优先使用模型响应中的实际 usage 数据，并验证流式、中断、重试和缓存场景是否会漏记或重复计算。
- 成本归因：至少支持按应用、环境、团队、用户、模型、提示词版本和任务类型筛选与聚合。
- 调用链追踪：应能看到一次请求中的检索、模型推理、工具调用、重试及其各自成本。
- 预算治理：除了事后报表，还应支持阈值告警、日月预算、异常增长检测、用户配额和模型限流。
- 数据安全：检查提示词是否默认上传、能否关闭内容采集、是否支持脱敏、自托管、审计和分级授权。
- 开放性：确认能否导出原始数据、接入现有监控系统，并支持自定义模型、私有模型和动态价格。
Token 优化不能只靠压缩提示词
第一步是建立成本基线。例如统计每个成功任务的平均输入、输出、调用次数和费用，再定位高成本长尾。对于简单的分类、改写和信息抽取任务，可以先评估较小模型；复杂推理再路由到能力更强的模型。模型路由应同时比较准确率、失败率和人工返工成本，避免只降低账面 Token，却损害业务效果。
第二步是治理上下文。应删除无效历史消息，限制检索文档数量，对长文档先分块、筛选或摘要，并给输出设置合理上限。Agent 还要设置最大步骤数、超时、重试上限和循环检测。无边界地保留对话历史或自动重试，往往比单条提示词冗长更容易造成费用异常。
第三步是利用缓存与批处理。重复的系统指令、示例和工具定义可尽量保持稳定，并放在提示词前部，以提高前缀缓存命中机会。缓存是否可用、触发条件和计费方式因供应商及模型而异，应依据提示词缓存文档核查，并监控缓存 Token 占比，而不是假设所有请求都会获得折扣。citeturn1search2turn1search5 对实时性要求不高的离线任务，则可评估供应商提供的批处理模式。
一套稳妥的落地方法
- 先在模型网关统一记录请求标识、模型、业务标签、Token、延迟、状态与重试次数。
- 选取真实业务流量进行小规模接入，并与供应商用量页面和账单交叉核对。
- 建立“单次成功任务成本”指标，同时观察质量、延迟和失败率。
- 为日成本突增、单请求超额、Agent 步骤过多和缓存命中率下降设置告警。
- 按高成本场景逐项实施模型降级、上下文裁剪、缓存、批处理和调用合并。
- 在每次优化后进行质量评测，防止以牺牲正确率换取表面节省。
总结
小型或单一模型项目，可以从厂商控制台加应用日志起步；需要提示词调试和调用链分析时，优先考虑 LLM 可观测性平台；多云、多模型及强合规场景，则更适合模型网关、OpenTelemetry 与数据仓库组合。真正值得选择的工具，不只是展示“用了多少 Token”，而是能够定位成本来源、及时阻止异常，并验证每项优化是否在保持质量的前提下降低了单次业务任务成本。
