LLM Gateway 总览
一句话理解：LLM Gateway 是客户端与多种推理后端之间的访问控制与抽象层，它把“用哪家模型、走哪条链路、限多少流、失败怎么办”这些横切问题从业务代码里抽离出来，集中治理。
学习目标
阅读完本主题后，你应该能够：
- 解释为什么企业在 vLLM / TensorRT-LLM / Triton / OpenAI / Azure 共存时需要 LLM Gateway。
- 说清楚 LLM Gateway 的 8 大核心能力：Provider 抽象、统一 API、路由、负载均衡、限流、重试降级、认证、可观测。
- 画出典型 LLM Gateway 架构，并说明控制面与数据面的职责边界。
- 理解一个请求从进入网关到返回的完整生命周期。
- 对比 LiteLLM Proxy、Envoy AI Gateway、Kong AI Gateway、NGINX AI Gateway、Cloudflare AI Gateway 的侧重点。
- 跑通并扩展本主题的 Mini Demo，理解其代码组织。
- 回答生产部署、多租户、成本追踪、安全相关的面试问题。
LLM Gateway 与 LLMOps 其他主题的关系
| 主题 | 解决的核心问题 | 与 LLM Gateway 的关系 |
|---|---|---|
| vLLM | 单个开源 LLM 如何跑得快 | Gateway 可以把 vLLM OpenAI-compatible Server 作为一个上游 Provider |
| SGLang | LLM Program 执行与结构化生成 | Gateway 可路由到 SGLang 后端并做请求/响应格式转换 |
| TensorRT-LLM | NVIDIA 编译型推理引擎 | Gateway 可以把 TensorRT-LLM Triton backend 作为高性能上游 |
| Triton Inference Server | 多框架统一推理服务 | Gateway 通常位于 Triton 前面，处理认证、限流、多租户 |
| LLM Gateway | 多引擎/多云/多租户统一接入 | 承上启下，向下屏蔽 Provider 差异，向上暴露统一 API |
本章结构
- 背景 — 多供应商与多引擎带来的协议碎片化。
- 核心思想 — Gateway 的 8 大横切能力。
- 架构设计 — 控制面与数据面，以及与 Service Mesh 的关系。
- Runtime 工作流程 — 请求生命周期详解。
- 核心模块 — 配置、Provider、路由、限流、重试、认证、转换、指标。
- 源码分析 — 以 LiteLLM 为主，Envoy/Kong 为辅。
- 工程实践 — 纯 Python 可运行的 Mini Demo。
- 企业生产实践 — Sidecar、独立服务、Kubernetes 部署、多区域降级。
- 最佳实践 — 供应商选择、限流、超时、缓存、PII 过滤。
- 面试题 — 初级/中级/高级面试题。
- 延伸阅读 — 官方文档、论文、开源项目。
一句话总结
LLM Gateway 不是又一个推理引擎，而是推理服务的“前门”和“控制面”；它让业务方像调用一家供应商一样调用多家模型，同时让平台方统一治理路由、成本、质量与安全。