为什么越来越多人用 AI Gateway？一文拆解 LiteLLM 的核心原理与用法

文章以一个接入了 OpenAI、Anthropic 和通义千问三家供应商的 AI 客服系统为例，指出直调模型 API 会带来协议不统一、故障处理零散、成本不可见、安全管控分散四类问题：OpenAI 用 tool_calls 字段，Anthropic 用 tool_use content block，Gemini 用 functionCall part，每接一家就要写几百行胶水代码。 AI Gateway 把调模型这件事从业务代码里抽出来，统一收口到一个地址。核心能力包括四块：协议归一化，业务只说 OpenAI Chat Completions 格式，网关负责翻译；模型路由，从固定模型到成本路由（如先用 DeepSeek 试，置信度低再转 GPT-4o 重答），再到 Fallback 与熔断；Key 管理，给应用发虚拟 Key 映射真实供应商 Key，可按部门设预算、随时吊销；可观测性，用 Token 消耗、成本归因、首 Token 延迟替代传统的 QPS 指标，两个请求成本可能差一千倍，按 QPS 限流在 AI 场景下几乎无效。 实操部分用 LiteLLM 跑通整个流程：pip 安装 proxy 模式后写 config.yaml 定义 model_list 和路由。Thoughtworks 技术雷达已把 LiteLLM 从语言与框架类别移到平台类别，理由是它更像基础设施而非库；阿里云 AI 网关文档也把 Token 计量计费和语义缓存列为并列核心能力。换供应商（比如全量切到 DeepSeek）时业务代码一行不用改，只改网关配置。