快速结论:通过 LiteLLM Proxy 调用 /v1/rerank 后,/ui/usage 和 spend log 中 prompt_tokens/completion_tokens/total_tokens 全部显示为 0,通常是因为 rerank 响应的 usage 位于 meta.billed_units/meta.tokens,而日志逻辑只读取顶层 usage。优先排查 rerank 响应与日志取值逻辑,而不是计费模型本身。
适用环境:Issue 中已确认:LiteLLM v1.95.0,涉及 hosted_vllm 等 rerank 提供商;原始报告基于 LiteLLM Proxy 的 /v1/rerank 与 /ui/usage。操作系统、Python、CUDA、显卡、PyTorch 版本未在 Issue 中给出。
最快修复方案:暂无确认的一步修复方案。Issue 评论显示修复 PR #49308 已合并,可优先尝试升级到包含该 PR 的 LiteLLM 版本;具体版本号 Issue 中未给出,需自行核对该 PR 的合入版本。
注意事项:该问题影响的是用量展示和 spend log,不代表实际请求失败或未计费。升级前请确认目标版本包含 PR #49308;Issue 未提供升级后的验证日志,升级后仍需按“验证方法”自行核对。
问题场景
用户在 LiteLLM Proxy 中配置 rerank 模型(例如 hosted_vllm/BAAI/bge-reranker-v2-m3),通过 curl <proxy>/v1/rerank 发起重排请求。rerank 响应中带有真实用量,例如 meta.billed_units.total_tokens 为 42,但在 /ui/usage 以及 spend log 中,该请求的 prompt_tokens、completion_tokens、total_tokens 均显示为 0。Issue 指出该现象不限于 hosted_vllm,其他 rerank 提供商也会出现。
报错原文
[Bug]: /ui/usage shows 0 tokens for rerank calls (hosted_vllm and other providers)
Raw rerank response:
{"id":"rerank-d618748e0f5543e8ba09ee7dd131ac59","results":[...],"meta":{"billed_units":{"total_tokens":42},"tokens":{"input_tokens":42}}}
Spend log entry:
prompt_tokens: 0
completion_tokens: 0
total_tokens: 0
原因分析
Issue 中给出的可能原因有两层:
- rerank 响应结构
RerankResponse没有顶层usage字段,用量只存在于meta.billed_units/meta.tokens;而litellm_core_utils/litellm_logging.py中的StandardLoggingPayloadSetup.get_usage_from_response_obj()和get_usage_as_dict()只读取response_obj["usage"],因此对 rerank 响应静默返回全 0 用量。 - 对
hosted_vllm而言,llms/hosted_vllm/rerank/transformation.py中的HostedVLLMRerankConfig._transform_response()只读取response["usage"],但 vLLM 的/rerank端点(Cohere 兼容)把用量放在response["meta"],导致原始RerankResponse.meta也不正确。
简言之,用量数据在响应中确实存在,但日志与转换逻辑没有从正确位置提取。
环境排查
- 确认 LiteLLM 版本:Issue 报告为 v1.95.0;检查当前部署版本是否低于包含修复 PR #49308 的版本。
- 确认 rerank 提供商与模型配置:例如
hosted_vllm/BAAI/bge-reranker-v2-m3或其他 rerank 提供商,用以判断是否所有 rerank 请求都受影响。 - 直接查看原始 rerank 响应,确认用量字段位于
meta.billed_units或meta.tokens,而不是顶层usage。 - 对照
/ui/usage与 spend log 的同一请求记录,确认 token 字段是否均为 0。 - 操作系统、Python、CUDA、PyTorch、显卡驱动及 vLLM 版本未在 Issue 中给出,需按实际部署环境另行核对;这些不是本 Issue 已确认的根因。
解决步骤
- 先复现并留证:调用
/v1/rerank,保存响应中的meta.billed_units.total_tokens与meta.tokens.input_tokens,同时记录相同请求在/ui/usage和 spend log 中的 token 值。 - 确认当前 LiteLLM 版本,并核对是否已包含 Issue 评论中提到的修复 PR #49308。
- 可优先尝试升级到包含 PR #49308 的 LiteLLM 版本;Issue 未说明具体合入版本号,请以 PR 的实际合入信息为准。
- 升级后重新发起同类 rerank 请求,再次检查原始响应中的
meta用量与 UI/spend log 中的 token 字段。 - 如果升级后仍为 0,收集 LiteLLM 版本、rerank 提供商、原始响应和 spend log 记录,向项目方反馈;Issue 中未提供其他已验证的规避方案。
验证方法
对同一 rerank 请求,原始响应中 meta.billed_units.total_tokens 为 42 时,/ui/usage 与 spend log 中的 total_tokens 应显示为对应的非零值,而不是 0。由于 Issue 未给出修复后的日志样例,请以实际响应中的用量字段为基准进行核对。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。
![[Bug]: MinerU 3.x /file_parse upload ignores the pipeline context and stays open after the run is cancelled](https://www.chat-gpts.plus/wp-content/uploads/2026/10/21572-82f3bc14-768x403.jpg)
![[Bug]: MinerU polling ignores cancellation and reports the wait timeout as a missing result](https://www.chat-gpts.plus/wp-content/uploads/2026/10/21570-666056f1-768x403.jpg)
![2024/01/10 19:17:53 [W] [service.go:132] login to server failed: dial tcp 44.237.78.176:7000: connect: connection refused](https://www.chat-gpts.plus/wp-content/uploads/2026/10/6988-22b6a761-768x403.jpg)