快速结论:当 OpenAI 兼容上游(如 OmniRoute 或自建网关)在响应里返回数值型 usage.cost,并且该部署通过 LiteLLM proxy 以 custom_llm_provider: openai 路由时,非流式调用的 response_cost 会被记为 0。优先排查非流式路径的 provider-reported cost 处理,并确认 custom_pricing 是否把 usage.cost 置空。
适用环境:Issue 中确认的环境为 LiteLLM 1.106.0(镜像 ghcr.io/berriai/litellm:main-stable);操作系统、Python、CUDA、显卡等未在 Issue 中给出,因此不作推断。
最快修复方案:暂无确认的一步修复方案。Issue 讨论中提到有已测试的自动定价路径修复并计划提交聚焦 PR,但正文没有给出可直接执行的一步命令或配置。
注意事项:不要仅依赖 model_info 中手工维护的 input_cost_per_token / output_cost_per_token 来掩盖问题;评论指出显式 custom-pricing 在某些部署形状下也可能记录 0,并产生 pricing_not_applied 警告。另外,流式路径“已原生传递 usage.cost”指的是客户端收到的内容,内部 spend 日志是否记录正确仍需单独验证。
问题场景
用户通过 LiteLLM proxy 的 /v1/chat/completions 发起一个 "stream": false 的普通聊天补全请求。该部署的 litellm_params.model 为 openai/omni-model,api_base 指向一个会返回 usage.cost 的 OpenAI 兼容上游。上游响应中明确携带 usage: {"prompt_tokens": 100, "completion_tokens": 20, "total_tokens": 120, "cost": 0.037},但 LiteLLM 的 spend log 与 response_cost 显示为 0。相同请求改为 "stream": true 时,成本可以被正确记录。
报错原文
[Bug]: provider-reported usage.cost is ignored on non-streaming calls for OpenAI-compatible upstreams (spend/budget reads $0)
原因分析
LiteLLM 的 response_cost_calculator 只通过按 provider 维护的允许列表来消费上游上报的成本:_USAGE_COST_HEADER_PROVIDERS(OpenRouter)用于流式路径,_CALCULATOR_PRICED_REPORTED_COST_PROVIDERS(xAI)用于 calculator 路径。通用的 openai 部署不在任一列表中,因此非流式调用不会读取 usage.cost,最终 response_cost = 0。
此外,当 custom_pricing 为 true 时,completion_cost 会调用 _without_provider_stated_cost,在任何价格计算之前显式把 usage.cost 置空。这会让这类部署只能依赖手工维护的价格,并破坏预算限制:budget limiter 需要数值型 response_cost,否则 spend 显示为 $0 或 unknown。可能原因还包括显式 custom-pricing 路径在某些部署形状下未生效,评论中提到的 pricing_not_applied 警告即与此相关,但尚未完全隔离。
环境排查
- 确认 LiteLLM 版本是否为 Issue 中的 1.106.0 或对应
main-stable镜像。 - 确认部署的
litellm_params.model是否为openai/...形式,custom_llm_provider是否为openai。 - 确认上游非流式响应正文中是否确实返回数值型
usage.cost,而不是仅在其他字段或流式块中返回。 - 确认是否启用了
custom_pricing,以及input_cost_per_token/output_cost_per_token是否同时配置在litellm_params与model_info中且数值一致。 - 检查 proxy 日志中是否有
pricing_not_applied警告,尤其是使用openrouter/<vendor>/<model>这类多段路径时。 - 分别用
"stream": false与"stream": true发起同一请求,对比 spend log 中的response_cost。
解决步骤
- 先复现并记录证据:向目标部署发送非流式请求,保存上游原始响应中
usage.cost的数值,同时记录 LiteLLM spend log 里的response_cost。 - 确认该部署走的是非流式路径,且
custom_llm_provider为openai;这是当前允许列表不会命中 provider-reported cost 的关键条件。 - 检查
custom_pricing配置。如果开启,请验证显式价格是否在litellm_params和model_info中都存在且一致,并观察日志是否出现pricing_not_applied。 - 作为临时规避,可优先尝试在部署上显式配置正确的
input_cost_per_token与output_cost_per_token,使completion_cost能走显式定价路径;但评论表明该路径在部分部署形状下仍可能记录 0,因此需要逐部署验证。 - 若显式定价仍不生效,关注 Issue 讨论中提到的自动定价路径修复 PR,并在升级后重新验证非流式
response_cost。 - 对流式路径单独做回归:即使客户端收到的内容正确,也要检查内部 spend log 是否记录非零
response_cost,评论指出流式行的内部成本也可能为 0。
验证方法
重新发送同一个非流式请求,确认上游仍返回数值型 usage.cost,并检查 LiteLLM spend log / response_cost 是否变为上游上报的成本(示例中为 0.037),而不是 0。随后用相同参数发送流式请求,确认流式与非流式两条路径的内部成本记录一致;同时观察日志中是否不再出现与目标部署相关的 pricing_not_applied 警告。若仍为 0,说明修复未覆盖该部署形状,需要继续收集 provider、model 路径与 custom_pricing 配置细节。
参考来源
BerriAI/litellm PR #48875(评论中提到的已合并功能,与 rpd/tpd 相关;请以仓库实际变更说明为准)
BerriAI/litellm PR #48957(评论中提到的 daily_reset_time 补充)
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。
![[Bug]: Claude models on Vertex AI fail at batch creation (404 batchPredictionJobs) — OpenAI batch translation doesn't cover Anthropic's nati](https://www.chat-gpts.plus/wp-content/uploads/2026/10/45671-ea844db1-768x403.jpg)
![[Bug]: zai provider drops response_format, making structured output impossible for GLM models](https://www.chat-gpts.plus/wp-content/uploads/2026/10/37720-7b5a1357-768x403.jpg)
