这篇学完你能回答什么
- LLM 网关解决什么？限流为什么不能只按 QPS，输出 token 事前不可知怎么办？
- 上游限流了怎么优雅降级？跨厂商 fallback 的真实代价是什么？
- 语义缓存和 prompt 缓存有什么本质区别？模型路由怎么判断"简单"、什么时候不该做？
从一个真实故障讲起
一个 toB 助手产品，早高峰上游返回 429，应用直接把 500 抛给用户。团队做了三次修复，每次都引出新问题。
第一次：加自动重试。 上线五分钟后 429 率不降反升。原因写在上游文档的一句话里——失败的请求同样计入你的每分钟配额。重试等于用配额去买配额，把限流打成了雪崩。
第二次：加跨厂商 fallback。 可用性上去了，但第二天账单涨了 40%。真因是 prompt 缓存：主链路那套 8000 token 的 system prompt 一直吃命中价（输入价的 0.1 倍），切到备用厂商后 100% 未命中，输入成本翻十倍。更糟的是有一批请求切到了同厂商的小模型上——小模型的最小可缓存长度门槛更高，那批 800 token 的短 prompt 从"命中缓存"掉回"全价重算"。
第三次：上语义缓存降本。 一周后客服收到投诉：一位用户问"我的订单能退款吗"，拿到的是别人的答案——缓存键没隔离租户，两句话相似度 0.91，越过了 0.8 的阈值。
三次修复，三种代价。本篇要讲的就是：网关的每一项能力都在关键路径上收税，而这些税在你打开它的那一刻是看不见的。
早高峰上游返回 429
应用直接把 500 抛给用户
第一次：加自动重试断点
失败请求同样计入配额，429 率不降反升
第二次：跨厂商 fallback
可用性上去了，第二天账单涨 40%
第三次：上语义缓存
相似度 0.91 越过 0.8 阈值，串了租户
核心概念：先打比方，再给定义
LLM 网关（AI Gateway / LLM Proxy）。所有模型调用的统一出入口，负责鉴权、限流、路由、重试、缓存、观测与分账。像公司的采购部门：业务方不直接找供应商，预算、合同、备选供应商就能集中管理。
三种形态混为一谈是这道题最常见的失分点：
A. SDK / 库 进程内调用，零网络跳数，但无法跨服务统一治理 B. 自托管 Proxy 独立进程，统一入口，自己承担单点故障与容量 C. 托管 SaaS 零运维，但 prompt 流经第三方 ← 合规评审的死穴
TPM / ITPM / OTPM。厂商的限流维度不是 QPS，是每分钟 token 数，输入侧输出侧还分开计。一句人话：上游按 token 计费就按 token 限流；用 QPS 近似一个方差三个数量级的变量，一定翻车。
语义缓存（semantic cache）。把问题向量化、比相似度，超阈值就直接返回旧答案，模型根本不跑。区别于 prompt 缓存（prefix caching）——后者是厂商侧复用 KV，模型照常跑、照常生成新输出。
模型路由（model routing）。在请求到达模型前判断"这题难不难"，简单的送小模型、难的送大的。
预算、合同、备选供应商集中管理
但采购部门自己也占一道流程 —— 它就长在关键路径上
AI Gateway / LLM Proxy
所有模型调用的统一出入口：鉴权、限流、路由、重试、缓存、观测与分账。三种形态混为一谈是这道题最常见的失分点 —— 托管 SaaS 的死穴是 prompt 流经第三方
QPS 都是 1，配额消耗差 900 倍
一次 200 token 的分类，和一次 18 万 token 的摘要 —— 用 QPS 近似一个方差三个数量级的变量，一定翻车
每分钟 token 数，输入侧输出侧分开计
厂商的限流维度不是 QPS。难的是输出 token 在请求发出前不可知 —— 业界只有三种解，三家厂商的文档合起来正好把三条路各证明了一遍
原理拆解
retry-after 退避加抖动；529 重试无用，直接切 fallback403 / 413 不可重试，504 官方建议改流式或批处理。跨厂商 fallback 的三重代价：缓存归零、契约破裂、合规越界| 层级 | 位置 | 命中条件 | 模型跑不跑 | 正确性风险 |
|---|---|---|---|---|
| exact cache | 应用 / 网关 | 请求完全相同 | 不跑 | 零 |
| prompt / prefix | 厂商侧 | prefix 逐 token 相同 | 跑 | 零 |
| semantic cache | 应用 / 网关 | 向量相似度 ≥ 阈值 | 不跑 | 不可消除 |
降本动作有正确顺序：exact cache（零风险，吃掉典型流量 15–30%）→ prompt/prefix cache（零风险，只省输入侧）→ effort 档位（改输出侧）→ 跨模型路由（有双轴评测之后）→ 级联。路由不是不能做，是多数团队在零风险动作还没做满时就去做了。
易变查询必须在查缓存之前拦掉：「现在几点」在 14:00 和 14:05 问，余弦相似度永远是 1.0、答案却不同，分数不会给你任何过期提示。官方另划了一条边界：多轮与 Agent 场景不适用，连续轮次相似度约 0.99，会重放旧响应。
一、限流：先问"你在保护谁"
这是第一性问题，四个目标对应四种量纲：
| 保护对象 | 限什么 | 为什么 |
|---|---|---|
| 上游商业配额 | TPM / ITPM / OTPM | 厂商就是这么计的 |
| 自己的钱包 | 成本 | token 数不等于钱，模型单价差 10–80 倍 |
| 自建推理集群 | 并发 in-flight 数 | 瓶颈是 KV Cache 显存不是 token 速率（见 T6-1） |
| 多租户公平性 | 每租户配额 | 一个大客户能把所有人饿死 |
上来就说"用 Redis 令牌桶限 QPS"的人，四个目标一个都没答。 一次 200 token 的分类和一次 18 万 token 的摘要 QPS 都是 1，对配额的消耗差 900 倍。
LLM 特有的硬问题是：输出 token 在请求发出前不可知。 业界只有三种解，三家厂商的文档合起来正好把三条路各证明了一遍。
① 悲观预扣 按 max_tokens 预扣
代价：配额被大量浪费，会出现"用量看着很低却一直 429"
—— 不是 bug 是设计；对策是把 max_tokens 调到贴近真实需求
② 后验记账 先放行，响应回来读 usage 记账，超额影响下一次
代价：单次超大请求一定漏过限流
③ 预扣+回填 按 max_tokens 预占 → 响应回来归还差额
代价：需要事务性计数器。这是生产上的正解还有一条官方结论：并发请求下 token 消耗会临时超过配置的限额——token 数要等响应回来才知道，并发窗口内的请求都是"盲发"的。所以并发闸门是唯一在请求发出前生效的硬约束，token 限流必须配并发限流。
另外流式会让限流精度必然下降（见 T6-2）：stream: true 时输入与输出 token 都只能估算。
二、降级：429 不等于 529
本节最锋利、也最容易翻车的一刀：
| 状态码 | 含义 | 正确动作 |
|---|---|---|
| 429 | 你超限了 | 读 retry-after 指数退避 + 随机抖动，同厂商重试 |
| 529 | 上游过载 | 重试无用甚至加重雪崩，正确动作是切 fallback |
| 403 / 413 | 配额耗尽 / 请求过大 | 不可重试，降级、拒绝或换大窗口模型 |
| 504 | 处理超时 | 官方建议改用流式或批处理 |
把 429 和 529 一律当限流重试，是典型的没做过生产。 叠加"失败请求也消耗配额"，盲目重试是把自己往雪崩里推。官方在批处理场景给的建议反而是主动注入延迟——限额 20 RPM 就给每个请求加 3 到 6 秒，在天花板附近平稳运行。
跨厂商 fallback 的真实成本是三重的，不是"配一行 config"：
① 缓存归零 跨厂商必然 100% 未命中；即使同厂商跨模型降级，
也可能因最小可缓存长度跳档（旗舰 512 → 小模型 4096 token），
让一批 800 token 的 prompt 从 0.1× 掉回 1.0× —— 输入成本涨 10 倍
② 契约破裂 tool schema、tool_choice、结构化输出、流式事件语义都可能不兼容
③ 合规越界 主链路走签了协议的 A 厂商，故障时自动降到 B 厂商
—— 用户数据在无人察觉时流出了合规边界fallback 不是配置项，是给降级链单独跑一遍输出契约测试 + 单独过一遍合规评审 + 单独算一遍成本模型。 敏感流量的降级目标只能在同等合规级别内选，宁可返回错误也不跨界降级。
三、缓存三层：正确性责任在哪一层转移
层级 位置 命中条件 模型跑不跑 正确性风险 ───────────────────────────────────────────────────────────────────── exact cache 应用/网关 请求完全相同 不跑 零 prompt/prefix 厂商侧 prefix 逐 token 相同 跑 零 semantic cache 应用/网关 向量相似度 ≥ 阈值 不跑 不可消除
第二层和第三层之间，正确性的责任发生了转移。 prompt 缓存由厂商保证"输出与不用缓存时完全相同"，只省重算不改结果；语义缓存没有任何人给你这个保证。
有一组公开评测把这件事钉死了：某云厂商用 6 万多条真实 query 做的基准里，阈值拉到 0.99（几乎等于精确匹配）时命中答案的准确率仍只有 92.1%；放宽到 0.75，准确率只掉到 91.2%，降本幅度却从 15.8% 涨到 86.3%。
两个反直觉结论： ① 误命中是结构性的，调阈值消不掉——阈值买的是命中率不是准确率。② 真正决定准确率的是缓存键的硬隔离维度：租户、用户、权限组、模型与 embedding 版本、prompt 模板版本、语料版本、语言，必须硬相等匹配。开头那个故障就是想用相似度做软隔离，已有公开安全 issue 证明这条路必然漏。
还有一整类 query 必须在查缓存之前拦掉：时间敏感、个性化、权限相关的"易变查询"。最锋利的例子是"现在几点"在 14:00 和 14:05 问，两次余弦相似度永远是 1.0、答案却不同，分数不会给你任何"过期了"的提示——这个判定只能放在应用层。官方还明说了一条边界：多轮与 Agent 场景不适用，连续轮次文本几乎相同、相似度约 0.99，会导致 agent 重放旧响应、重复工具调用。
降本动作有一个正确的顺序（T6-4 展开每一步的量化判据）：
exact cache（零风险，吃掉典型流量 15–30%）→ prompt/prefix cache（零风险，只省输入侧） → effort 档位（改输出侧）→ 跨模型路由（有双轴评测之后）→ 级联
四、路由：怎么判断"简单"，以及为什么大多数团队做不好
判定方法五类，从便宜到贵：规则与元数据（任务类型、输入长度、租户等级）、分类器打分、相似度与最近邻、级联（先小模型跑，不行再升级）、模型自评置信度。最后一类要直接排除——模型校准度普遍很差，"它说自己有 90% 把握"和实际正确率几乎脱钩。不要拿"模型说自己不确定"当升级信号，要用外部质量估计器或结构化验证。
四个必须校正的认知：
① "95% 质量"不是绝对准确率，指的是补回强弱模型之间差距的 95%。且收益随分布外衰减剧烈：分布内只需 14% 的强模型调用，分布外即使加了标注仍需 54%。
② 路由的失败模式是"不敢用小模型"。 2026 年的路由基准里最好的路由器距理论上限还差 17 个百分点，共性失败原因写得很直白：不擅长识别"什么时候小模型就够了"。多数路由器聚集在"接近 100% 成本、接近 100% 准确率"——等于把收益全吃掉了。根因是错路由代价高度不对称：简单题送贵模型，损失线性可预算、用户看不见；难题送小模型，损失非线性、用户直接能看见。所以生产路由器必然偏保守，甚至有基准测出某商用路由相对最强单模型是 −24.7%。
③ 路由延迟跨两个数量级（11 到 547 毫秒），超过 100 毫秒就威胁 SLO。部署前必须先问"路由器本身要多久"。
④ "路由会打穿 prompt 缓存"已被实测证伪（真实流量近五千次模型切回中，一小时 TTL 下 99.3% 的缓存仍是热的），真正的风险是无粘性的无状态路由 + 短 TTL。反过来的对照更有说服力：只路由不缓存比"单模型 + 缓存"还贵约 4 倍。
什么时候不该做路由：日调用量小；流量难度分布单一（路由的前提是有方差）；prompt 缓存与 effort 档位还没做满（缓存读比未缓存输入便宜 75%–90% 且零风险）；没有质量与成本的双轴评测。
有团队公开写过下线自建路由的复盘，核心理由值得记住：判断难度所需的信息是在执行过程中产生的，而不是执行之前就能拿到。 同样一句"评估一下这些测试"，简单 HTML 是琐事、大型代码仓库是极难——prompt 可以一模一样。
工程实践（截至 2026-08）
网关能力矩阵（易腐化，本章只在这一张表点名一次）
| 产品 | 形态 | Token 限流 | Fallback | LLM 专用负载均衡 | 语义缓存 |
|---|---|---|---|---|---|
| LiteLLM | SDK + Proxy（MIT） | 多级 | 含上下文超长/内容策略专用 | 多算法 | |
| Kong AI Gateway | 自托管（部分企业版） | 可按 token 或成本 | 优先级组 | 最完整 | 企业版 |
| Envoy AI Gateway | 自托管 K8s（Apache-2.0） | 面向自建推理 | |||
| Cloudflare AI Gateway | 托管 | 部分 | 只有精确匹配 | ||
| Azure APIM | 云原生 | 可切预估/后验 | + 熔断 | （阈值是距离） |
三条时效坑（截至 2026-08）：Anthropic 的限流分层已不是 Tier 1~4，是 Start / Build / Scale / Custom；Cloudflare AI Gateway 至今没有语义缓存；Azure 的语义缓存阈值是"距离"不是"相似度"，超过 0.2 就容易误命中。
两起 2026 年的格局变动正好是"选型要看厂商存活性"的现成案例：Portkey 被安全厂商收购并入其安全平台，Helicone 被收购后转入维护模式。架构原则由此而来：只依赖统一 API 这一层、不绑定某家的专有 DSL，才是可撤退的架构。
两种负载均衡是两个问题
- 多个商业 API 之间：信号是 token 数、成本、每输出 token 耗时。精妙的细节是默认用每输出 token 耗时而非端到端延迟——端到端延迟主要由输出长度决定，用它做负载均衡等于惩罚那个恰好接到长回答的健康节点。
- 自建推理的多个副本之间：信号是 KV Cache 利用率、队列深度、前缀命中、LoRA 亲和。
被问"怎么给 LLM 做负载均衡"时先反问"上游是商业 API 还是自建推理"，是这道题最强的开场。
避坑清单
- 限流计数存储是隐藏的单点：Redis 挂了，限流器 fail-open 还是 fail-close？前者成本失控，后者全量瘫痪。这个取舍必须提前写进预案。
- 网关自报延迟不含排队时间（官方排障文档明说它从 handler 开始计时），会出现"日志说 10 秒、用户说 20 秒"，必须用 in-flight 请求数交叉验证。
- 网关 benchmark 基本不可比：同一家官方给过 P95 8 毫秒和 P99 257 毫秒两个数（前者打的是假上游）。看数字先查三件事——是不是 mock 上游、有没有开日志与护栏与缓存、报的是 P50 还是 P99。
- 什么时候不该上网关：单服务单厂商无分账需求；首字延迟预算低于 300 毫秒的实时链路；强合规下选托管 SaaS；以及组织还没开始追问 AI 账单的时候。
- 模型侧网关与工具侧网关是两层：前者管 client 到 LLM，后者管 agent 到 MCP。
| 产品 | 形态与能力 | 缺口与点评 |
|---|---|---|
| LiteLLMMIT · 四项俱全 | SDK + Proxy（MIT）；多级 token 限流，fallback 含上下文超长与内容策略专用，多算法负载均衡 | 四项能力都在，也是表里唯一的 MIT |
| Kong AI Gateway | 自托管（部分企业版）；可按 token 或成本限流，fallback 走优先级组 | LLM 专用负载均衡最完整；语义缓存要企业版 |
| Envoy AI Gateway | 自托管 K8s（Apache-2.0）；负载均衡面向自建推理 | 没有语义缓存，胜在贴着自建推理集群 |
| Cloudflare AI Gateway | 托管；token 限流与 fallback 齐备，负载均衡只有部分 | 至今没有语义缓存，只有精确匹配 |
| Azure APIM | 云原生；限流可切预估或后验，fallback 带熔断 | 语义缓存阈值是距离不是相似度，超 0.2 易误命中 |
- 限流分层
- Anthropic 已不是 Tier 1~4，是 Start / Build / Scale / Custom
- 两种负载均衡
- 商业 API 之间默认用每输出 token 耗时（端到端会惩罚接到长回答的节点）；自建推理副本之间看 KV Cache 利用率与队列深度
- 可撤退的架构
- 只依赖统一 API 这一层、不绑定某家的专有 DSL —— 两起收购已经把这条原则证明过了
- 限流计数是单点
- Redis 挂了走 fail-open 还是 fail-close？前者成本失控，后者全量瘫痪，取舍写进预案
- 自报延迟有盲区
- 网关从 handler 开始计时，不含排队 —— 日志说 10 秒用户说 20 秒，用 in-flight 数交叉验证
- benchmark 不可比
- 同一家给过 P95 8 毫秒和 P99 257 毫秒；先查是不是 mock 上游、开没开日志护栏缓存、报的哪个分位
面试视角
- 先反问上游商业 API 还是自建推理 —— 它决定限流量纲与负载均衡信号
- 再按四段讲统一 API → 限流 → 降级 → 观测与分账
- 错误码分开答429 同厂商退避重试，529 直接切 fallback
- 主动交代代价缓存归零、契约破裂、合规越界，三重都要点到
- 用「不该用」收尾什么时候不上网关、什么时候不做路由
- 限流只说 QPS 或「令牌桶 + Redis」—— 四个保护目标一个没答
- 429 一刀切重试，不知道 529，也不知道失败请求同样消耗配额
- 把 fallback 说成「配一个备用 model」，不提缓存、契约与合规
- 把语义缓存和 prompt 缓存混为一谈，或认为「阈值调高就安全」
- 谈路由只报「能省 85%」，却不问这个数字是怎么定义的
- 开口先反问「上游是商业 API 还是自建推理」，再谈量纲
- 说得出预估与实际 token 不一致的三种解、自己选了哪种、前后 429 率
- 能解释「用量看着很低却一直 429」，并点出并发闸门那条硬约束
- 谈负载均衡用「每输出 token 耗时」而非端到端，并说得出为什么
- 谈 fallback 先谈缓存：跨模型降级可能因最小缓存长度跳档而涨价
面试官怎么问 + 答题结构
分水岭信号
暴露只读过： 限流只说 QPS 或"令牌桶 + Redis"；429 一刀切重试、不知道 529、不知道失败重试也消耗配额；把 fallback 说成"配一个备用 model"；把语义缓存和 prompt 缓存混为一谈或认为"阈值调高就安全"；谈路由只报"能省 85%"却不问这个数字的定义；只讲网关好处不讲代价。
证明真做过：
- 先反问"上游是商业 API 还是自建推理"
- 说得出预估与实际 token 不一致的三种解、自己选了哪种、前后 429 率变化；能解释"用量很低却一直 429"这个反直觉现象
- 指出并发闸门是唯一在请求发出前生效的硬约束
- 谈负载均衡时提到"每输出 token 耗时"而非端到端，并说得出为什么
- 谈 fallback 时先谈缓存：跨模型降级可能因最小缓存长度跳档而让成本反而上升
- 对语义缓存持保留态度且给得出理由；说得出路由的失败模式是"不敢用小模型"
- 讲得出网关自身的可观测盲区（自报延迟不含排队）与"什么时候不该上网关"
小结与延伸
继续深入
本篇归属第 6 章「部署与成本」，去做这一章的题。