快速结论:在 LiteLLM 1.98.0 的 Admin UI 里修改模型别名等不涉及价格的字段后,会把数据库中的有效定价(catalog-derived pricing)写回为自定义定价;随后价格表重载(reload)会让这些 Azure 部署的请求即使有真实 token 用量也被记录为 $0。优先排查发生 Admin UI 编辑后 model_info 是否被写入了大量 input_cost_per_token/output_cost_per_token 等派生字段。
适用环境:LiteLLM 1.98.0(Docker/代理模式),PostgreSQL 后端,Azure OpenAI 部署;同一 LiteLLM 凭据被多个 Azure 部署复用,base_model 留空,各部署通过 model_info.base_model 指定 provider-qualified 模型。触发场景与 STORE_MODEL_IN_DB、价格表重载相关。Issue 中未提供 Python、CUDA、显卡等信息。
最快修复方案:升级到 v1.102.0(或含 PR #36222 的 v1.102.0-rc.1 及以上版本)。报告者在 v1.102.0-rc.1 及 Docker Hub 的 v1.102.0 上确认:Admin UI 编辑不再保存 cost_per_token 相关字段,价格重载后花费仍被正确记账。Issue 关闭时说明机制已由 #41944 修复并在下一个版本发布。
注意事项:升级只能阻止新写入的派生定价,不能自动清理数据库里已经写入的 model_info 派生定价字段。旧版本受污染的部署行需要手动比对并移除这些字段,操作前请备份数据库。若升级后仍出现零花费,可能仍有其他数据库模型或响应后计算路径未覆盖,需要单独排查。
问题场景
用户在 LiteLLM 1.98.0 上以 PostgreSQL 为后端运行代理,为 Azure OpenAI 配置了多个部署。管理员在没有修改定价的情况下,仅在 Admin UI 中重命名了几个公共模型别名。之后数据库快照显示,同一个部署 UUID 的 model_info 从 3 个键(id、db_model、base_model)膨胀到 44 个键,包含 input_cost_per_token、output_cost_per_token、缓存、优先级和长上下文费率等 catalog-derived 定价字段,以及派生能力/展示字段。一次短暂的 UI 编辑会话中影响了 15 个部署。
这些被污染的部署一开始仍能记录正确花费,但在配置的 24 小时价格数据重载之后,同一个 Azure 部署 UUID、团队、后端模型和 key 从非零花费突然变成零花费,而成功响应中仍包含真实 token 用量。捕获的历史中有 58 条成功但零花费的请求,合计 1,720,035 tokens,涉及 5 个部署。最后一条正确计费请求在 01:11 UTC,推断的重载时间约为 01:37 UTC,第一条零花费请求在 02:13 UTC,转换期间没有部署行更新或 worker 重启。
报错原文
[Bug]: Admin UI model edit persists derived pricing; price-map reload then records Azure spend as $0
persisted pricing present -> custom_pricing=True
deployment UUID absent from model_cost
selected model=<Azure deployment name>
selected model mapped=False
原因分析
可能原因是 Admin UI 的模型信息读取响应中包含了用于展示的 effective pricing,而一次与定价无关的 UI 保存把这个被扩展后的对象整体写回数据库,使部署被标记为自定义定价(custom_pricing=True)。这对应 Issue 中提到的 #36222 所描述的 Admin UI/write-path 触发点。
当价格表重载发生后,该部署 UUID 不在 model_cost 中,选择器不再回退到 provider-qualified 的 catalog 模型,而是选到了 Azure 部署名,且 mapped=False,因此响应后的成本选择返回不到价格,最终把有真实用量的请求记为 $0。日志行中 metadata.model_map_information 仍包含正确的 provider-qualified catalog 模型和非零费率,cost_breakdown 为 null,说明定价数据本身存在,但 post-response 成本选择未命中。
报告者也指出,在 1.98.0 的 reload 路径已包含 runtime-registration replay,因此可能还存在未覆盖的数据库模型或 post-response 计算路径。Issue 中“24 小时定时重载”是基于数据库只保留最近一次重载时间戳做出的推断,并非直接日志证据。
环境排查
- 确认 LiteLLM 版本:是否为 1.98.0,或已升级到含 PR #36222 的 v1.102.0-rc.1 / 正式 v1.102.0(Docker Hub)。
- 确认后端数据库:PostgreSQL,且是否启用
STORE_MODEL_IN_DB。 - 确认部署是否使用同一个 LiteLLM 凭据服务多个 Azure 部署,
base_model是否留空,各部署是否通过model_info.base_model指定 provider-qualified 模型。 - 检查数据库
LiteLLM_ProxyModelTable中相关部署的model_info键数量与内容,确认是否出现input_cost_per_token、output_cost_per_token、cache_read_input_token_cost等派生定价字段。 - 检查代理是否配置了定时价格表重载,以及重载发生时间是否与零花费转换时间吻合。
- 确认零花费请求的
metadata.model_map_information中是否仍有正确的 provider-qualified catalog 模型和非零费率。
解决步骤
- 先升级 LiteLLM 到 v1.102.0 或更高版本(至少包含 PR #36222 的版本)。报告者在 v1.102.0-rc.1 上验证 Admin UI 编辑不再保存
cost_per_token相关字段,且即使 Price Data Reload 后花费仍被正确计数;在 Docker Hub 的 v1.102.0 上确认问题不再复现。 - 升级后,检查此前被污染部署的数据库行。Issue 中给出的对比方式是:编辑前
model_info只有id、db_model、base_model,编辑后多出大量派生定价和展示字段。可参考 Issue 中的 SQL 脚本按模型名或模型 ID 列出model_info的每个键值。 - 对仍残留派生定价字段的部署,在备份数据库后手动移除这些
cost_per_token相关字段,同时保留原有的model_info.base_model。报告者本地验证,移除派生定价字段并保留相同model_info.base_model后,选择器会重新选中 provider-qualified catalog 模型,且该模型是 mapped 且费率正确。 - 如果不方便手动改库,也可在升级后重新创建或重写受影响的部署配置,确保不再携带 UI 编辑写入的派生定价字段。
- 升级后观察一次价格表重载周期,确认 Azure 部署在重载后仍有非零花费记录。
验证方法
在升级并清理派生定价字段后,等待或手动触发一次价格表重载,然后发送带真实 token 用量的 Azure 请求,检查 /spend/logs 或数据库中该请求的 spend 是否非零,cost_breakdown 是否存在。报告者的复现路径为:创建别名、通过 PATCH /model/{id}/update 回显完整 /model/info blob、POST /reload/model_cost_map、发起 chat、检查 /spend/logs。若重载后成功请求的 spend 仍为 $0,则需要回到数据库核对 model_info 是否仍有派生定价字段。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。
![[Bug]: Databricks non-GPT models 400 with reasoning_effort must be a string when reasoning.summary is set](https://www.chat-gpts.plus/wp-content/uploads/2026/09/42347-6e601b9c-768x403.jpg)
![[Bug]: Streaming responses broken since 0.14.0 for ContextChatEngine and similar classes](https://www.chat-gpts.plus/wp-content/uploads/2026/09/22749-8310a4fe-768x403.jpg)
