快速结论:该 403 通常发生在 LiteLLM Proxy 使用团队作用域模型(team-scoped model)创建 Batch 后,再调用 GET /v1/batches/{batch_id} 查询或取消时;根因是批量路由用内部模型名 model_name_{team_id}_{uuid} 做 team.models 权限校验,而团队表里只存公开模型名。优先确认模型是否带 model_info.team_id,并关注是否升级到包含修复的版本。
适用环境:Issue 报告版本为 LiteLLM v1.104.1(由 v1.99.2 升级),源码还检查过 v1.101.0、v1.102.0、v1.103.0、v1.105.1、v1.107.0-dev.3;配置开启 general_settings.store_model_in_db: true;模型通过 POST /model/new 管理 API 创建,带 model_info.team_id 与 model_info.team_public_model_name。Issue 未提供操作系统、Python、CUDA、显卡信息。
最快修复方案:暂无确认的一步修复方案。Issue 讨论中已提交修复 PR #47067,计划在解析出团队作用域部署时,改用其 team_public_model_name 进行授权(并以解析出的名称兜底);可等待包含该 PR 的 LiteLLM 版本发布后升级验证。
注意事项:修复 PR 在评论中仍为 draft,合入与发布节奏由维护者决定;Issue 中关于 v1.104.1-enterprise 及后续版本是否回移的问题没有明确答复。报告者尚未在干净部署上用新建团队虚拟密钥复现,团队虚拟密钥路径属于“从代码推断适用”,未经验证。
问题场景
在 LiteLLM Proxy 中开启 store_model_in_db,通过管理 API 创建带 model_info.team_id 的团队作用域模型,并成功用该模型的公开名称创建 Batch。随后调用 GET /v1/batches/{batch_id} 检索(或取消)该 Batch 时返回 403。Chat Completions 和 Batch 创建正常,因为它们使用公开别名,而检索路径会把统一 batch id 解析成部署的内部模型名再校验权限。
报错原文
[Bug]: Batch retrieve returns 403 for team-scoped models since v1.103.0 (authorize_model_for_key checks internal model_name_{team_id}_{uuid} against team.models, which holds only public names)
原因分析
在 litellm/proxy/batches_endpoints/endpoints.py 中,retrieve_batch 从统一 batch id 解析模型时调用 llm_router.resolve_model_name_from_model_id(...),对团队作用域部署返回的是内部生成名 model_name_{team_id}_{uuid}。随后 authorize_model_for_key 经 can_key_call_resolved_model → can_team_access_model → _can_object_call_model 做校验,把该内部名与 team.models、team_model_aliases 比对;但 team.models 只保存公开名称,team_model_aliases 的键也是公开名称,因此内部名无法匹配,_check_model_access_helper 返回 False,最终抛出 403。
该问题被归因于 v1.103.0 引入的访问检查(关联 PR #41934),并与 #32580/#32587 的旧问题相关但不同:旧的修复只把部署哈希解析成模型名,而团队作用域部署解析出的仍是内部名。可能的修复方向是:在批量/文件路由的访问检查前,把解析出的内部团队模型名转换为 team_public_model_name;或当部署的 model_info.team_id 等于调用方 team_id 时放行。Issue 中两种方案均未原型验证。
环境排查
- 确认 LiteLLM 版本:Issue 在 v1.104.1 复现,源码检查到 v1.107.0-dev.3 仍存在相同逻辑;v1.101.0、v1.102.0 的
retrieve_batch没有该访问检查。 - 确认
general_settings.store_model_in_db: true是否开启。 - 检查数据库
LiteLLM_ProxyModelTable.model_name是否为model_name_{team_id}_{uuid}形式,model_info.team_public_model_name是否已设置。 - 检查
LiteLLM_TeamTable.models是否只包含公开模型名,而非内部名。 - 确认调用方鉴权对象上的
team_id是否与模型model_info.team_id一致;Issue 报告者在自定义 auth hook 环境观察到问题。 - Issue 未提供操作系统、Python、CUDA、PyTorch、显卡等信息,无需按这些项排查。
解决步骤
- 先核对模型是否为团队作用域:查看是否为
POST /model/new创建且带model_info.team_id和team_public_model_name。 - 对照数据库确认内部名与公开名:
LiteLLM_ProxyModelTable.model_name为model_name_{team_id}_{uuid},而team.models中为公开名。若符合,该 403 与 Issue 机制一致。 - 区分操作路径:用公开名创建 Batch 和 Chat Completions 正常、仅
GET /v1/batches/{batch_id}或取消返回 403,可优先怀疑此问题。 - 可优先尝试:升级到包含修复 PR #47067 的 LiteLLM 版本后重试检索和取消 Batch。Issue 评论中未给出具体版本号或发布日期,需以官方发布说明为准。
- 若暂无法升级,可按 Issue 建议方向评估临时方案(例如在自定义路由/鉴权层把内部团队模型名映射为公开名),但这些都属于推测性绕过,未在 Issue 中验证。
验证方法
在目标版本上,用团队作用域模型以公开名称创建 Batch,再调用 GET /v1/batches/{batch_id} 检索并取消同一 Batch;确认不再返回 403,且仍能正确校验调用方是否有权访问该团队模型。若修复 PR #47067 的回归测试已合入,也可参考其针对团队作用域模型批量检索的测例。
参考来源
相关修复 PR:BerriAI/litellm #47067
相关背景 Issue/PR:#32580、#32587、#41934
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。
![[Bug]: Request Failed Error Code: 500 Message: litellm.APIConnectionError: APIConnectionError: Hosted_vllmException -](https://www.chat-gpts.plus/wp-content/uploads/2026/10/43518-60da76fd-768x403.jpg)

