大模型 API 账单为什么总比预期高 30%：五个隐藏计费项

很多团队都遇到过同一件事：按 token 单价乘以预估用量的账单测算，和实际账单对不上——普遍高出 20~40%。不是厂商算错，是测算时漏了隐藏计费项。五个最常被漏的，逐个拆。

一、系统提示词：每次请求都在重复付费

你的 system prompt 有 2000 token，每轮对话都会整体计费——10 轮对话，这 2000 token 被计了 10 次。测算时只按「用户输入+输出」估，系统提示词这部分直接漏掉。优化：system prompt 瘦身+启用上下文缓存（缓存命中部分按折扣计费，多数厂商支持）。

二、失败请求的重试放大

超时重试、限流退避、格式错误重新生成——每次重试都是一次全额计费。5% 失败率配 3 次重试策略，实际消耗放大 10~15%。测算时按「理想请求」估，重试这一项就漏了。优化：失败率进成本仪表盘+重试上限收紧。

三、多轮对话的上下文滚动

多轮对话里，历史消息每次都作为上下文重发——第 10 轮的输入是前 9 轮的全文加新输入。对话越长，单轮计费越贵，成本随对话深度二次增长。测算按「平均对话轮数×平均轮成本」估，会严重低估长对话用户。优化：对话摘要压缩历史+超长对话强制开新会话。

四、流式输出的心跳与半包

流式输出（SSE）的计费粒度问题：部分厂商按 chunk 累计，部分按最终全文——差异在「半包重传」场景。网络不稳时客户端断线重连，服务端可能已经生成了内容（计费了）但客户端没收到（用户体验丢了）。优化：重连走断点续传而非重新生成（省钱且体验一致）。

五、模型路由的隐式升舱

「自动选择模型」的路由策略，在复杂请求时悄悄切到贵的模型——测算按便宜模型估，实际跑在贵的模型上。路由日志要审计：每个请求实际用了哪个模型、为什么。优化：路由规则显式化+按功能固定模型档位。

结语

账单偏差的本质：单价是显性的，用量是隐性的。把这五个隐藏项做成对账清单，每月跑一次「测算 vs 实际」的偏差分析——偏差稳定在 5% 以内，你的成本模型才算及格。