DB-stored model with `api_key: os.environ/VAR` is not resolved (sent literally) — works in config.yaml
快速结论：开启 STORE_MODEL_IN_DB=true 时，通过数据库存储的模型若在 litellm_params.api_key 中使用了 os.environ/VAR 格式，LiteLLM 会将 os.environ/VAR 这个字符串原封不动地发送给上游服务商，导致 401 认证失败。优先确认是否使用了 DB 存储模型，且 api_key 写成 os.environ/XXX 格式。
问题场景
用户在 LiteLLM Proxy 中开启 STORE_MODEL_IN_DB=true（即通过数据库而非 config.yaml 管理模型），通过 Admin UI 或 /model/new API 添加模型时，在 litellm_params.api_key 字段中使用了 os.environ/MY_KEY 格式引用环境变量。调用该模型时，上游服务商收到的 API Key 是字面字符串 os.environ/MY_KEY 而非解析后的环境变量值。
报错原文
401 ... api key: ...MY_KEY is invalid注：实际报错可能因上游服务商不同略有差异，但核心是认证失败且日志中 API Key 显示为 os.environ/MY_KEY 的字面字符串。
原因分析
LiteLLM 对 os.environ/ 前缀的环境变量解析仅在 Router.set_model_list 方法中执行，该方法处理的是 config.yaml 中定义的模型。对于存储在数据库中的模型，数据经过 ProxyConfig._add_deployment / ProxyConfig.decrypt_model_list_from_db 路径加载，这些路径只对 litellm_param 执行了解密操作（decrypt_value_helper），但从未运行 os.environ/ 的环境变量解析步骤。因此解密后的 os.environ/MY_KEY 字符串被直接传递给了部署实例。
环境排查
- 确认 LiteLLM 版本：
v1.89.3（该版本被确认为回归问题，旧版本main-stable~2026-03 正常） - 确认
STORE_MODEL_IN_DB环境变量已设置为true - 确认
LITELLM_SALT_KEY已配置（用于数据库字段加密） - 确认模型中
api_key字段的值是否以os.environ/开头
解决步骤
- 临时规避方案：将模型定义移回
config.yaml的model_list中，而非存储在数据库中。经测试，config.yaml路径能正确解析os.environ/语法。 - 长期修复（等待上游合并）：Issue 维护者已确认该问题并计划在
_add_deployment/decrypt_model_list_from_db的解密步骤之后，对os.environ/前缀的字符串值执行get_secret解析，使其行为与set_model_list一致。关注 BerriAI/litellm 仓库的后续发布。 - 如果自行修改源码：在
litellm/proxy/proxy_server.py的_add_deployment或decrypt_model_list_from_db方法中，在解密完毕后加上类似以下的条件逻辑（示例代码，需根据具体版本调整）：if isinstance(v, str) and v.startswith("os.environ/"): _litellm_params[k] = get_secret(v)
可优先尝试：使用 config.yaml 定义模型来绕过此问题。
验证方法
在修复或规避后，调用该模型时检查上游服务商返回的状态码：不再收到 401 认证失败错误。也可以在 LiteLLM Proxy 日志中确认发送的 Authorization 头部包含正确的 API Key（解析后的环境变量值）。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
