把多模型调用收口到 LiteLLM 前，我会先做这三层边界

多模型调用最容易在项目长大后失控：前端、后台任务、运营脚本各自拿供应商 Key，日志口径不一致，预算也很难按人或按场景切。LiteLLM 的价值在于把这些调用先收口成一个 AI Gateway。官方文档说明，LiteLLM Proxy 可以用 OpenAI 兼容格式调用 100 多种 LLM API，并在代理层提供鉴权、花费追踪、预算和负载均衡入口。小团队不必一开始就做完整平台，先把出口统一，后面的治理才有抓手。

原创示意图：从应用请求、网关策略、模型路由到成本观测的轻量治理流程。来源：Codex image generation

先统一出口，再谈模型策略

第一层边界是调用出口。不要让业务代码散落多个供应商 SDK，也不要把模型切换写进每个功能里。LiteLLM 的 config.yaml 支持用 model_list 定义用户可见的模型别名，再把别名映射到 Azure OpenAI、OpenAI 兼容端点、本地 vLLM 或其他供应商。业务侧只需要把 base_url 指向代理，把模型名当作团队内部约定来用。

这一步的收益很直接：模型替换可以在网关层完成，应用代码只关心输入、输出和错误处理。试验新模型时，也可以先给一小段调用链换别名，观察延迟、失败率和成本，再决定是否扩大范围。对于有多个环境的项目，我会把开发、预发、生产拆成不同的代理配置，避免测试流量误用生产预算。

Key 要按场景发

第二层边界是身份和预算。LiteLLM 的虚拟 Key 文档写得很清楚：要做 Key 管理，需要 Postgres 数据库、DATABASE_URL 和一个以 sk- 开头的 master key，之后可以通过 /key/generate 生成面向用户、团队或应用场景的 Key。它还支持按 Key、用户和团队查看 spend，并把调用成本写回数据库。

我会按场景发 Key，避免按工程师分发一个通用 Key。例如：客服摘要一个 Key，内部搜索一个 Key，批处理脚本一个 Key。每个 Key 限定可用模型、预算上限和过期时间。这样排障时能直接看到是哪条产品路径在烧钱，临时关闭某个实验功能时也不会影响其他调用。master key 只放在受控后台或运维环境，绝不进入浏览器、移动端或公开仓库。

路由先保守

第三层边界是路由策略。LiteLLM 的 Router 文档提到，它可以在多个部署之间做负载均衡，也支持 cooldown、fallback、timeout 和 retry。生产环境还可以用 Redis 跟踪限流和用量。功能很多，但第一版不需要把所有策略都打开。

我的默认做法是先用简单稳定的模型组：同一类请求给一个主模型和一个备用模型，超时、重试次数和单次最大 token 都写清楚。只有当调用量稳定后，才考虑按 RPM、TPM、延迟或成本做更细的路由。预算路由看起来很诱人，但如果每次路由都需要额外读写用量状态，低延迟场景会更敏感。先拿到可靠日志，再上复杂策略，通常更稳。