多家模型 API 参数各不相同：用 LiteLLM 虚拟 Key 做路由和配额隔离

多家模型 API 真正难维护的地方，通常不是把请求发出去，而是每家供应商的模型名、鉴权字段和限流方式都不一样。把这些差异散落到业务服务里，换模型就要改配置、改密钥、改客户端。

更稳的做法是把 LiteLLM Proxy 放在服务端：用 model_list 把供应商部署映射成稳定的 model_name，客户端统一请求代理；再用虚拟 Key 给项目分配模型白名单、预算和速率限制。这样供应商密钥留在代理侧，调用方只拿到可撤销的项目凭证。

先记住三个结果：统一入口隔离供应商差异；虚拟 Key 隔离调用方；数据库记录让预算和消费可追踪。下面用最小配置把这条边界搭起来。

先把“供应商差异”收敛到代理层

LiteLLM 官方文档把 Proxy 定位为统一的 LLM Gateway。先准备 PostgreSQL，并在代理环境中设置 DATABASE_URL 和以 sk- 开头的 LITELLM_MASTER_KEY。供应商的真实密钥也只放在服务端环境变量。

model_list:
  - model_name: team-chat
    litellm_params:
      model: openai/
      api_key: os.environ/OPENAI_API_KEY
  - model_name: team-chat
    litellm_params:
      model: azure/
      api_key: os.environ/AZURE_API_KEY
      api_base: os.environ/AZURE_API_BASE
general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL

这里两个条目故意使用相同的 model_name。业务端只请求 team-chat，至于实际落到哪个部署，由代理的模型组和路由策略处理。不要把供应商密钥、api_base 或部署名写进浏览器代码。

用 model_list 和虚拟 Key 划分路由

启动代理后，用 master key 调用 /key/generate 创建虚拟 Key。请求体的 models 是这个 Key 可访问的模型名；如果只给项目开放 team-chat，就不要把管理用途的其他模型一并放进去。

curl http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "models": ["team-chat"],
    "metadata": {"project": "support-bot"},
    "max_budget": 20,
    "budget_duration": "30d",
    "rpm_limit": 30,
    "tpm_limit": 12000
  }'

返回的 sk-... 只交给对应服务使用。实际项目建议以 team 作为归属单位，再为不同应用生成 Key；这样人员变动时可以吊销单个 Key，应用额度也不会混在一个共享密钥里。

让配额与调用方绑定，而不是写死在客户端

LiteLLM 会在启用数据库时记录 Key、用户或 team 的消费，并可通过 /key/info、/user/info 或 /team/info 查询。额度设计要先回答三个问题：这个 Key 能调用哪些模型、一个周期最多花多少、并发或速率上限是多少。

不要把预算判断只写在客户端：客户端可以被绕过，而且多实例并发时很容易出现各自计数。代理层的 Key 限制负责做硬边界，业务日志再补充请求 ID、业务租户和失败原因。需要统一追踪下游用户时，可考虑官方提供的 overwrite_user_with_key_hash 设置，让经过代理校验的请求使用与 Key 绑定的稳定标识。

用统一 OpenAI 客户端验证隔离效果

LiteLLM Proxy 提供 OpenAI 风格的请求入口，因此业务代码只需要替换 base_url 和 Key：

from openai import OpenAI

client = OpenAI(
    api_key="sk-project-key",
    base_url="http://localhost:4000"
)
response = client.chat.completions.create(
    model="team-chat",
    messages=[{"role": "user", "content": "给我一句简短的欢迎语"}]
)
print(response.choices[0].message.content)

验证时不要只看“能返回”。至少做三组检查：项目 Key 请求允许的 team-chat；请求一个未授权模型应被代理拒绝；连续超过 rpm 或预算后应出现可识别的限流/预算错误。换供应商时只改代理配置，客户端请求形状保持不变。

上线前还要安排 Key 轮换：新 Key 生效后再吊销旧 Key；master key 仅给管理接口使用；日志里只记录 Key 的标识或哈希，不记录完整凭证。若网关需要自定义请求头，官方支持通过 litellm_key_header_name 指定头名，但仍应在网关层完成 TLS、权限和过期管理。

常见问题

虚拟 Key 能代替供应商密钥吗？不能。它是 LiteLLM Proxy 的访问凭证，供应商密钥仍由代理服务端保存。

为什么配置了多个模型却没有切换？检查多个条目的 model_name 是否形成同一模型组，并确认客户端请求的名称就是该组名，而不是供应商原始部署名。

只设置 max_budget 就够了吗？不够。预算控制花费，rpm/tpm 控制请求速度和令牌量；生产项目通常需要按调用方同时设置。

统一接口是否保证所有参数都兼容？不能保证。统一的是常见请求/响应形状，供应商特有参数、工具调用和响应能力仍应按实际模型文档做兼容测试。

小结：把供应商差异收敛到 model_list，把调用方权限收敛到虚拟 Key，再把预算、速率和消费记录放到代理与数据库层，客户端就能保持稳定，路由和配额也有了清晰的责任边界。参考：LiteLLM Virtual Keys、LiteLLM Getting Started。