深色模式
LLM 网关架构与价值
摘要：当 LLM 调用方超过 3 个团队、模型超过 2 家，直连模型 API 的模式就会失控：Key 散落各处、无统一限流、成本无法归因、换模型要改所有调用方。LLM 网关把模型调用收口为一个入口、一套接口、一份账单。本文讲清网关的核心能力、参考架构、主流开源方案（LiteLLM / Higress / Kong AI Gateway / APISIX）对比与选型建议。前置阅读：AI 平台架构总览。
为什么需要专用网关
传统 API 网关假设"请求等价、成本均匀"；LLM 流量打破了四个假设：
| 传统网关假设 | LLM 流量现实 |
|---|---|
| 成本按请求计 | 按 token 计，单请求成本差两个数量级 |
| 限流按 QPS | 需按 token 速率与预算双维度限流 |
| 失败 = 5xx | 429/过载/超长上下文/内容过滤各有处置策略 |
| 观测 = 状态码+延迟 | 还需 token 数、成本、finish_reason、质量分 |
LLM 网关 = 传统网关的流量治理能力 + LLM 特有的模型抽象层。
核心能力与参考架构
六项核心能力，按落地优先级：
- 统一接口：所有上游抹平为 OpenAI 兼容协议，调用方只改 base_url 与 key；
- 虚拟 Key 与多租户：给每个调用方发独立 Key，支持预算、限流、吊销；
- 计量与审计：每次调用的 token、成本、模型、调用方全量落库（见 Token 成本与用量监控）；
- 路由与降级：按成本/延迟/可用性在多模型间路由，故障自动 fallback（见 多模型路由与降级）；
- Token 级限流：QPS + TPM（每分钟 token 数）+ 月预算三层（见 限流与配额）；
- 安全插件：Prompt 注入检测、PII 脱敏、输出过滤（见 安全合规）。
网关放哪一层
网关应处于应用与模型之间，而不是替换应用入口的南北向网关。典型部署：业务 → 南北向网关（Ingress/APISIX）→ LLM 网关（LiteLLM 等）→ 模型。Higress 一类方案可以把两层合一。
主流方案对比
| 方案 | 形态 | 优势 | 局限 | 适合 |
|---|---|---|---|---|
| LiteLLM Proxy | Python 进程，Docker/K8s | Provider 覆盖最广（100+），虚拟 Key/预算/用量开箱即用，上手最快 | Python 单进程吞吐有限，流量治理偏弱 | 快速收口、中小团队 |
| Higress AI 网关 | Envoy + K8s，Wasm 插件 | 云原生，限流/熔断/可观测复用 Envoy 体系，AI 插件开源完整 | 需熟悉 K8s/Envoy | 已有云原生体系的团队 |
| Kong AI Gateway | Nginx/OpenResty + 插件 | 企业级插件生态，已在用 Kong 的团队迁移平滑 | 部分 AI 能力在企业版 | 已有 Kong 资产的企业 |
| APISIX | Nginx + Lua/Wasm | 性能强，AI 能力在开源核心，Apache 治理 | AI 插件需自行组装 | 高并发、已有 APISIX 基础 |
| 云厂商托管网关 | 全托管 | 免运维、生态集成 | 厂商绑定、按量成本 | 深度使用对应云的团队 |
[厂商/版本相关]：各家功能边界随版本快速演进（如 Kong 3.14 起统一管理 LLM/MCP/A2A 流量），选型前以官方文档为准做 PoC 验证。
选型决策树
- 调用方 < 5 个、模型 < 2 家 → 先不建网关，用一个内部 SDK 封装即可，避免过度设计；
- 需要快速收口、看重 Provider 覆盖 → LiteLLM；
- 已有 K8s/Envoy/Istio 体系 → Higress；
- 已在用 Kong/APISIX → 优先在现有网关上加 AI 插件，保护既有投资；
- 全栈单一云且不想自运维 → 云厂商托管方案。
演进路径建议
不要一步到位上全功能。经验路径：统一接口 → 虚拟 Key + 计量 → 限流预算 → 路由降级 → 安全插件。前两步一周内可上线，收益（成本可见、Key 可控）已占全部价值的一半以上。