0
0

用 LiteLLM Proxy 给团队留一个可替换的 AI 网关

2026-06-08
AI 工具
LiteLLM / AI 工具 / 开源项目 / 开发实践 / LLMOps
用 LiteLLM Proxy 给团队留一个可替换的 AI 网关

当一个团队的 AI 功能从实验脚本走向多个应用时，最先变乱的通常是模型出口。一个项目直接接 OpenAI，另一个项目接 Anthropic，第三个项目又把本地 vLLM 或云厂商兼容接口写进配置。短期看都能跑，后续想切模型、限预算、查调用链时，就会发现每个应用都要单独改一遍。LiteLLM Proxy 的适用位置，正是在应用和模型服务之间加一层可审计的 AI 网关。

LiteLLM Proxy 连接应用与多模型服务的流程示意图

应用侧统一调用 Proxy，平台侧集中管理模型路由、虚拟密钥、预算观察和回退策略。 来源：Codex image generation

先把模型出口收拢

LiteLLM 官方把它定位为开源 AI Gateway，可以用 OpenAI 格式调用 100 多类 LLM 服务，也可以作为集中式 Proxy Server 部署给团队使用。对已有代码最友好的地方是 OpenAI 兼容入口：应用侧仍然使用 OpenAI SDK，只需要把 base_url 指向 LiteLLM Proxy，例如官方示例里的 http://0.0.0.0:4000，再使用代理层暴露出来的模型名发起请求。

这种做法的重点是把模型选择从业务代码里移到配置。litellm_config.yaml 里的 model_list 可以定义对外模型别名，再映射到 Azure OpenAI、OpenAI、Anthropic、Vertex AI、Ollama、vLLM 或其他兼容端点。应用只关心 chat/completions 或 responses 这类稳定接口，平台侧负责把别名路由到具体供应商。

小团队可以先落三个能力

第一是虚拟密钥。不要把供应商原始 API key 分散给每个服务，可以由 Proxy 统一持有上游凭据，再给应用、环境或团队成员发放 LiteLLM virtual key。这样一来，撤销权限、轮换密钥和区分调用来源都会更容易。

第二是成本观察。LiteLLM 的虚拟密钥文档写明，spend 可以按 key、user、team 查询，并且在调用 /completions、/chat/completions、/embeddings 时自动更新为 USD 口径。这里更适合做工程侧的趋势观察和预算预警，正式财务对账仍应以供应商账单为准。

第三是回退和迁移。业务刚上线时，可以先用一个稳定模型名，比如 default-chat。当某个供应商延迟升高、价格变化或上下文窗口不合适时，平台侧改配置和回退策略，应用侧无需理解每家模型 SDK 的差异。

落地时别把网关做成黑盒

AI 网关会经过提示词、响应内容、用户标识、供应商密钥和预算信息，信任边界比普通反向代理更高。建议一开始就把三件事写进部署清单：配置文件和环境变量分离，Proxy 管理接口只放在内网或受控访问层后面，日志按业务需要脱敏和分级保留。

如果要容器化部署，官方 GitHub README 也给出了镜像签名校验示例，使用 cosign verify 校验 ghcr.io/berriai/litellm:<release-tag>。对生产环境来说，固定版本、记录配置变更、保留回滚路径，比追求一次性接入更多模型更重要。

一个够用的起步流程

可以先挑一个低风险内部工具试点。第一步，写一个最小 model_list，只暴露一个聊天模型别名。第二步，让应用把 OpenAI SDK 的 base_url 切到 Proxy。第三步，为开发、测试、生产分别生成 virtual key，并在请求里带上项目或团队标识。第四步，每周看一次 key 和 team 的 spend，确认调用量、失败率和延迟是否符合预期。

当这条链路稳定后，再逐步加缓存、日志回调、预算限制和备用模型。LiteLLM Proxy 的价值不在于让团队马上拥有复杂平台，价值在于先把 AI 调用从散落在业务代码里的供应商适配，整理成一个可配置、可观察、可替换的出口。

来源链接

评论