LiteLLM 评测：多模型时代的 AI Gateway，不只是统一 API

它解决多模型调用格式不统一、密钥分散、成本难追踪、故障切换难设计的问题。应用层可以继续使用接近 OpenAI 风格的接口，网关层负责路由和治理。

团队从一个模型扩展到多个模型后，问题会从“怎么调用 API”变成“怎么治理调用”。LiteLLM 的价值在于把供应商切换、成本、限流和日志集中到一层。

GitHub API 返回的许可证状态需要按具体版本复核，不能只看仓库介绍。商业采用前应确认开源版、企业版、依赖包和部署镜像的许可边界。由于它处理模型密钥和请求日志，供应链与版本固定也应纳入上线清单。

非技术用户不会直接操作 LiteLLM，但会受益于统一账单、模型切换和失败降级。产品或运营团队可以定义模型使用规则，工程团队负责把规则落到路由和权限配置里。

先让 Codex 或 Claude 生成一个最小代理配置：两个模型提供商、一个测试 endpoint、基础日志和预算标签。确认请求能路由后，再加入数据库、访问令牌、限流、回退策略和观测平台。

LiteLLM 的上限是网关治理，不是模型质量本身。它能降低多供应商接入复杂度，但不会自动告诉你哪个模型更适合业务，也不会替代离线评测和人工验收。

### 什么时候需要 LiteLLM

如果团队只调用一个模型，直接用供应商 SDK 更简单。当你同时使用云模型、本地 vLLM、不同区域账号和不同成本策略时，LiteLLM 才开始有价值。它把模型选择从业务代码里抽出来，让路由、预算和日志更集中。

### 生产化风险

网关会经过密钥、提示词、用户输入和模型输出，所以它属于高敏感基础设施。上线前要固定版本，限制管理后台访问，记录配置变更，并决定哪些日志可以保存。不要把快速开始配置直接放到公网。

### 与观测平台的关系

LiteLLM 负责调用和路由，Langfuse、Helicone 等更偏评测、观测和分析。它们不是完全替代关系。更合理的架构是 LiteLLM 作为入口，观测平台负责追踪质量、成本和异常。

### 结论

LiteLLM 适合多模型、多团队、多成本中心的场景。它能让模型调用治理更清楚，但也会成为关键依赖。采用前先做小规模路由验证，再决定是否把所有模型流量放进同一个网关。