LiteLLM 与开源 LLM 网关：多模型路由的工程实现

为什么需要 LLM 网关：应用的「模型依赖」问题

应用直连模型 API 的架构有一个隐性债务：模型的选择散落在应用的每一处——每段代码里硬编码的 provider 与 key、每处的重试与错误处理各自为政。换模型 = 全代码库的改造、成本的归因没有统一口径、限流与密钥管理各自实现。LLM 网关的解法：在应用与模型之间插入一个统一层——应用只对接网关（OpenAI 兼容接口），网关负责路由到真实的模型——本库网关篇的设计理念在开源实现层的落地。LLM 网关的四个核心能力：统一接口（多模型的协议翻译）、智能路由（按任务/成本/延迟选模型）、可靠性（重试、降级、熔断）、治理（限流、密钥管理、成本归因）。

LiteLLM：开源网关的事实标准

LiteLLM（开源）是这一层的事实标准，两种形态。SDK 形态：Python 库——litellm.completion(model="claude-3-5/...") 的统一调用接口（100+ 提供商的协议翻译、重试与 fallback 内建）——嵌入应用的轻量用法（不需要独立服务）。Proxy 形态（LLM Gateway）：独立的服务——OpenAI 兼容的服务端点（应用把 base_url 指向网关）、路由规则与限流的配置化、成本追踪与预算（按项目/团队的用量统计与预算熔断——本库 FinOps 篇的落点）、虚拟 key 管理（给不同团队发不同的虚拟 key、各自的配额与可见的用量）。Proxy 的架构价值：应用的「模型依赖」收敛到网关的配置——换模型改配置不改代码、限流与预算集中在网关、密钥统一管理（应用侧只持有网关的虚拟 key——真实模型密钥不出网关，本库安全篇的密钥治理）。

路由策略的实现：从简单到智能

网关的路由策略分级实现。级别一：静态路由——按规则分流（生产走旗舰、测试走便宜模型、特定 header 走特定模型——配置式的规则表）。级别二：fallback 链——主模型失败自动切换备选（fallbacks: [{"claude-3-5": ["gpt-4o", "qwen"]}]——降级的自动闭环，重试到成功或全部失败）、上下文长度的自动路由（长 prompt 走长窗口模型）。级别三：智能路由——按任务的难度与历史表现动态分配（本库推理经济学篇的黄金段位——需要路由效果的闭环数据）。路由的工程要点：路由决策要可观测（每次路由的理由可追溯——为什么这个请求走了这个模型）、路由的灰度能力（新模型的小比例灰度——在网关层做，本库灰度篇的机制）、以及路由的失败安全（路由器自身的高可用——网关挂了所有应用都挂，网关自身的部署冗余是前提）。

成本追踪与治理：网关的第二价值

成本追踪是网关的第二价值（与路由并列）。口径的统一：每次调用记录「模型、token 输入输出、成本、归属标签」（项目/团队/功能的标签——本库 FinOps 篇的归因），月度账单按标签拆分——「谁在花、花在哪」的可见性。预算与熔断：虚拟 key 的预算上限（超限自动降级或拒绝——本库后台 Agent 篇的熔断）。密钥与合规：真实密钥的集中保管（轮换、审计）、数据流向的记录（哪些请求走了哪些模型/区域——合规审计的依据）。自建网关 vs 商业平台的选择：自建（LiteLLM Proxy）——开源免费、数据自持、深度可定制，代价是运维；商业平台（Portkey 类）——托管省心、企业功能齐全，代价是费用与绑定。选型判断：用量小或强工程团队 → LiteLLM 自托管；预算充足或运维力量薄弱 → 商业平台；无论哪个，网关层「统一 OpenAI 兼容接口」的设计是共同的正确起点——它是未来所有路由与治理能力的基础。

LiteLLM 实战细节：重试、降级与上下文的网关处理

LiteLLM（正文能力）的实战细节：重试、降级与上下文的网关处理——网关的「可靠性三件套」的实现细节。重试的策略配置。重试的次数与退避（指数退避 + 抖动——重试风暴的防护：限流时的重试要退避，否则重试本身就是 DDoS）、重试的范围（可重试的错误：限流 429、临时性 5xx；不可重试：上下文超长 400——错误分类决定重试策略）。降级（fallback）链的设计。fallback 的顺序设计（主模型 → 同级备选 → 降级模型——降级的「质量阶梯」：每一级的质量下降要有预期）、fallback 的条件（错误码触发、延迟超时触发、内容过滤触发）、以及fallback 的成本核算（降级模型的成本差异——降级也是省钱：高峰期的自动降级是成本治理）。上下文的网关处理。超长上下文的处理（超过模型窗口的请求——网关层的截断与拒答策略、自动摘要压缩的进阶——本库上下文工程篇在网关层的实现）、上下文的脱敏（敏感信息的网关级过滤——本库安全篇的合规点）。三件套的收束：重试、降级、上下文处理，是网关「可靠性与健壮性」的三件套——它们让应用的模型调用「不管后台发生什么都有合理的出路」；三件套的配置质量，直接决定应用在故障日的表现。

LLM 网关的监控与审计：治理层的落地

LLM 网关（正文治理）的监控与审计：治理层的落地——网关不只是路由，是治理的执行点。监控的指标体系。流量指标：按模型/租户的 QPS、token、成本（本库 FinOps 的归因）、质量指标：错误率、超时率、降级率（降级率的突增 = 模型或上游出问题的信号）、延迟指标：各模型的延迟分位数。审计的体系。调用日志的留存（谁、何时、用了什么模型、多少 token——合规审计的原始凭证）、敏感操作的审计（密钥的变更、路由规则的修改——治理动作本身要留痕）、以及数据流向的记录（哪些请求走了哪些区域/供应商——本库合规篇的数据流向）。治理的执行。密钥的生命周期（真实密钥的轮换、虚拟 key 的发放与回收——本库安全篇的密钥治理）、配额的执行（预算的熔断、超限的处置——本库 FinOps 篇）、以及策略的版本化（路由规则与限流策略的变更走评审——网关的配置是生产资产，变更要有流程）。治理层的收束：LLM 网关是「AI 应用的治理控制面」——路由管效率、监控管健康、审计管合规、治理管纪律；这四个面合起来，LLM 网关才不只是「路由器」，而是企业 AI 流量的「操作系统」。

LiteLLM 实战案例：一个多团队网关的搭建

LiteLLM（正文能力）的实战案例：多团队网关的搭建——一个组织内的 LLM 网关的完整配置。场景：一个公司有三个团队（产品/研发/数据），各自用不同的模型、不同的预算。网关的配置。虚拟 key 的发放：三个团队各发一个虚拟 key（sk-team-product、sk-team-rds、sk-team-data）、各 key 的预算与模型白名单（产品团队只能用旗舰模型、研发可以用全部——key 的模型白名单是「权限的模型维度」）。路由的策略：默认模型与降级链（旗舰 → 中档 → 小模型的三级降级）、成本的标签（每次调用自动打上团队的标签——成本的归因从网关层自动完成）。监控的面板：每团队的用量仪表盘（token/成本/调用次数——团队自己看自己的用量——透明度的治理）、预算的告警（80% 预算的告警——预算的提前预警比超限后追责好）。这个案例的元意义：LLM 网关的价值在多团队场景最大化——单团队用网关是「锦上添花」，多团队用网关是「治理的必需品」——成本的归因、配额的执行、密钥的管理，三件事在多团队场景里缺一不可。

LLM 网关的安全与合规

LLM 网关的安全与合规：密钥审计与数据流向。密钥管理：真实密钥集中保管（模型厂商 API key 只在网关层——应用侧只持有网关虚拟 key——真实密钥不出网关）、密钥轮换（定期轮换——轮换过程应用无感）、密钥审计（谁何时用了哪个密钥——密钥使用日志）。审计体系：调用日志留存（每次调用完整日志：时间用户模型token成本——合规审计原始凭证）、敏感操作审计（密钥变更路由修改配额调整——治理动作本身要留痕）、数据流向记录（哪些请求走了哪些模型区域——数据出境合规记录）。网关安全收束：LLM 网关是 AI 应用合规控制面——密钥集中管理调用全量审计数据流向记录——三件事合起来网关才是合规枢纽而不只是路由枢纽。

LLM 网关的选型与实施建议

LLM 网关的选型与实施建议：从决策到上线的完整路径。选型判断：用量小或强工程团队 → LiteLLM 自托管；预算充足或运维薄弱 → 商业平台（Portkey 类）；超大规模 → 自研网关（定制化需求超出开源能力）。实施的建议：网关的部署先于大规模应用（网关是基础设施，先建后用——所有应用从第一天就走网关，避免后补的迁移成本）；OpenAI 兼容接口的坚持（应用层只对接 OpenAI 兼容接口——接口的统一是网关所有价值的前提）；监控与审计的同步上线（网关上线时监控与审计同步部署——不要先跑起来再补）。实施的收束：网关的上线是一个组织级的决策——它改变了「应用与模型的交互方式」——这个决策需要工程团队、业务团队与合规团队的共识；共识的达成往往比技术实施更难——网关的选型，一半是技术一半是组织。

小结

LLM 网关把应用的模型依赖收敛到统一层：LiteLLM 的 SDK/Proxy 双形态覆盖「嵌入」与「服务」两种用法，路由策略从静态到智能分级实现，成本追踪与预算熔断是治理的第二价值。自建与商业的选择按用量与运维力量定，但「应用只对接 OpenAI 兼容的网关接口」是共同的正确起点——它把「换模型」从代码改造降级为配置修改，把成本从黑箱变成仪表盘。