Token 消耗异常排查

有时用户只输入了一个简短问题，但控制台显示的用量或费用却比预期高。用户看到的文字只是请求的一部分，实际请求还可能包含系统提示词、历史消息、工具定义、知识库片段、图片、音频、视频和模型输出。Agent 还可能在一次用户操作中执行多轮模型调用。排查时先区分“单次请求变贵”和“请求次数变多”，不要直接把两者都归因于 Token 分词。

常见原因与优化方法

常见原因	表现	优化方式
系统自动携带历史对话	多轮对话越长，输入 Token 越高	设置历史保留轮数，对长对话做摘要压缩
提示词和工具说明过长	用户输入较短，但实际输入 Token 较高	精简系统提示词，只传入必要工具
知识库召回片段过多	知识库问答成本明显增加	限制召回数量和片段长度，优先传入高相关片段
Agent 多轮执行	一次用户操作触发多次模型调用	设置最大执行轮次、工具调用次数和停止条件
输出内容过长	输出 Token 占比过高	设置最大输出 Token，明确字数、条数或格式
选用了高价格模型	简单任务成本偏高	建立模型分层策略，简单任务使用低成本模型
失败重试或异常循环	短时间内调用次数异常增加	限制重试次数，增加幂等、告警和熔断机制
图片、视频或音频参数变化	媒体输入用量或生成价格突然升高	对比图片尺寸、视频时长、FPS、分辨率、质量和数量
缓存未命中或重复写入	长上下文每次都按普通输入或缓存写入计费	对比 cached tokens、cache read/write 字段和前缀版本
账单与用量更新时间不同	控制台数字暂时对不上	用请求 ID 和任务 ID 等待数据同步后再核对

排查步骤

发现 Token 消耗或费用异常时，可以按以下顺序排查：

先确认统计口径：记录异常发生时间、模型、API Key、租户、请求 ID 或异步任务 ID，区分 API 响应中的 usage、用量统计和最终账单。
核对单次请求：查看输入、输出、总量、思考和缓存字段；不要用用户问题的字数代替真实输入量。
核对调用次数：统计一次用户操作触发的模型请求数，排查 Agent 循环、工具调用、定时任务、批处理和失败重试。
检查上下文组成：比较系统提示词、历史消息、工具定义、工具结果、知识库片段和重复字段的长度。
检查媒体参数：对图片核对数量、尺寸和 detail；对视频核对时长、FPS、分辨率和截取区间；对音频核对时长、任务类型和文件大小。
检查缓存状态：确认稳定前缀是否改变，查看 cached tokens、缓存读取和写入字段；缓存命中仍然可能计费，首次写入也可能更贵。
检查模型和价格项：确认是否发生模型版本、协议、区域、质量档位或输出尺寸变化，重新按当前价格项计算。
最后核对余额和账单：等待用量和账单同步后，用请求 ID、任务 ID 和 Key 维度核对结算金额。

优化建议

对多轮对话设置历史消息保留轮数。
对长对话和长文档进行摘要压缩。
精简系统提示词和工具说明。
限制知识库召回片段数量和单片段长度。
限制 Agent 最大执行轮次和工具调用次数。
设置最大输出 Token。
对媒体输入设置时长、FPS、分辨率、尺寸和数量上限。
为生成任务设置幂等键，避免客户端超时后重复提交。
对稳定长上下文测试缓存命中率和单位任务成本，不要只看缓存字段是否存在。
为不同业务和环境拆分 API Key。
设置账户余额和 Token 消耗告警。

小结

Token 消耗或费用偏高通常需要结合现有的单次 usage、实际请求次数、媒体参数、缓存状态、模型价格项和最终账单一起排查。优先查看异常请求的响应和控制台明细，再定位调用链和输入组成，最后核对财务明细，才能判断问题是“单次请求变大”“请求被放大”还是“统计尚未同步”。