大模型服务的路由，关键是把全局优化与本地决策拆开

先说结论

生产级大模型推理不能靠轮询，也不能让每个前端集群只凭自己的局部视图选“看起来最好”的 GPU。OpenAI 推理团队分享的核心经验是：把请求路径上的快速本地选择，与持续运行的全局优化拆开。数据平面用已发布的路由状态立即转发请求，控制平面根据全局流量、网络距离、引擎容量、健康度和缓存局部性计算下一版权重；惩罚、动态重试上限和主动削峰则负责在故障与过载时保持系统可用。中文深度整理，非逐字翻译。

原始来源：Routing LLM Inference in Production。节目：AI Engineer。嘉宾：Qianru Lao、Lu Zhang。原始日期：2026-09-19。时长：约 17 分钟。内容类型：技术演讲 / 推理基础设施。

这期内容在讨论什么

推理负载均衡器位于接收用户请求的 CPU 集群和承载模型引擎的 GPU 集群之间。它既要选择合适的引擎，也要把请求代理过去。模型服务的特殊性在于，引擎并不完全同质：硬件和容量不同，跨区域距离不同，健康度会实时变化，同一会话的 KV cache 还可能让“继续使用原引擎”比寻找最近节点更划算。

早期系统把这些信号压缩成周期性的性能分数，再通过反馈回路调整每个引擎的权重。这种方式有适应性，却很难解释某次路由为什么发生，也容易因为流量迁移导致引擎变凉、权重回升、流量再迁回，从而产生振荡并破坏缓存局部性。

核心观点

第一，局部最优可能造成全局过载。若每个 CPU 集群都把请求发给自己看到的最佳引擎，多个集群可能同时选中同一组 GPU，导致它们超载，而其他引擎闲置。全局控制平面必须同时看到所有请求来源和所有候选引擎，才能把流量分配问题作为整体优化。

第二，请求路径应该保持短而确定。数据平面不应为每个请求同步询问控制平面，而是读取本地缓存的候选引擎和路由权重，立即做出选择。它仍然持续采集引擎信号，但这些信号通过异步路径反馈给控制平面，用来改善未来的路由。

第三，最近的引擎不一定是端到端最快的。一个近处引擎如果接近容量上限，排队时间可能远大于跨区域网络增加的那点延迟。优化器因此同时考虑网络延迟和引擎侧延迟，目标是最小化端到端延迟，而不是单独最小化网络距离。与此同时，所有需求都必须被路由，引擎不能超过有效容量，权重也必须保持非负。

推理链与关键例子

团队把系统拆成三个循环。第一个是同步的请求循环：请求到达 CPU 集群，数据平面根据当前本地状态选引擎并转发。第二个是引擎信号循环：系统持续采集首 token 延迟、token 间隔、可用副本数、利用率和其他健康信号。第三个是路由权重循环：控制平面将这些信号与流量需求、网络距离、容量模型结合，计算新的权重并发布，数据平面异步拉取。

这个拆分兼顾了反应速度与全局视野。数据平面面对故障时可以做快速本地保护，控制平面则负责更慢但更全面的重新分配。对于一个附近引擎只能承受 100 RPS、所在集群却有 120 RPS 的场景，优化器可以把超出的流量送往更远但有余量的引擎；看起来多了一点网络成本，整体却可能少了大量排队时间。

保护机制是这套架构的最后一层。被检测为异常值的引擎会被降低权重，给它恢复或更换硬件的时间；重试会设置动态预算，避免系统在高负载时陷入“失败—重试—更高负载”的 retry storm；当需求超过容量，系统主动丢弃一部分流量，让服务以可控方式降级，而不是所有请求一起失败。

边界、保留意见与争议

这期分享描述的是一个复杂生产系统的设计原则，不包含所有实现细节和绝对性能数字。控制平面需要可靠的容量回归模型和实时信号，数据平面也需要处理状态过期、网络分区和局部故障。任何一环出错，都可能把“全局优化”变成集中式故障点。

此外，缓存局部性与全局负载平衡之间存在真实冲突。把连续会话固定在一个引擎上有助于复用 KV cache，却可能使局部热点持续存在；频繁迁移可以均衡负载，却会丢失缓存收益。系统需要把它们放进同一个成本函数，而不是用一条固定规则解决所有流量。

整理后的观察

这期内容的普适启示是：高并发 AI 系统应该把“快速执行”和“持续优化”分开。请求路径只做必要工作，复杂计算和策略更新走异步闭环；全局策略负责效率，本地策略负责韧性。这个分层也适用于检索、工具调用和 Agent 调度：不要让每个请求重新发明一次全局决策，同时也不要让集中式控制阻塞关键路径。