为什么 LLM 推理需要一种新型路由器 - 第一部分

来源：https://www.modular.com/blog/why-llm-inference-needs-a-new-kind-of-router-part-1?utm_source=x Gemma 4 现已在 Modular 上发布，Day Zero！了解更多 → (https://www.modular.com/blog/day-zero-launch-fastest-performance-for-gemma-4-on-nvidia-and-amd) 2026 年 5 月 8 日

Aayush Deshpande

Deep Dhillon

Alexandr Nikitin

Michael Dunn-O’Connor

HTTP 路由多年来一直是一个已解决的问题。轮询、一致性哈希、最少连接。任选一种，放在一群相同的服务器前面，流量就会相当均匀地分布。

但随后出现了大语言模型。

这里的后端不是可互换的 Web 服务器。它们是 GPU pods，内置大型本地 KV 缓存，存储在高速带宽 RAM 或 SSD 内存中。这种状态重建成本很高，在集群中并非均匀可用，而且往往决定了一个请求是快速返回还是花费数秒重新计算之前的工作。有些 pods 可能专门处理 prefill，有些专门处理 decode。对话通常会跨越多个请求。单个推理调用有时需要按顺序访问两个后端。旧的“可互换后端“和“独立请求“的假设无法满足这些需求。

缓存路由：盲路由 vs 感知路由 传统路由对这一切视而不见。它将每个后端视为可互换的，每个请求视为独立的，每个 pod 都是同等优秀的。GPU pods 以上都不是。它们是有状态的、专业化的且异构的。推理路由必须考虑到这一点。

这是关于路由必须如何演进以处理推理工作负载的三部分系列文章的第一篇。Modular Cloud 的编排层围绕这个路由问题构建，本系列将解释它如何解决这一问题。

多年的无状态路由

HTTP 时代的负载均衡建立在一小部分算法之上，每种算法都针对特定的部署形态进行调整。它们有不同的策略，但共享相同的前提条件：无状态后端。

经典路由策略

轮询 (Round-robin) 将请求均匀分布到一组相同的后端上。它假设每个后端以相同的成本处理每个请求。这看起来可能像是同一个 Web 服务的八个副本放在负载均衡器后面，每个获得 12.5% 的流量。简单、公平、无状态。

一致性哈希 将每个请求路由到由请求的某个属性（键、url、会话标识符）哈希决定的后端，选择哈希环上位置最接近的后端。当您希望同一键落在同一后端上时（用于客户端缓存或会话亲和性），这是首选的路由策略。后端的“粘性“是请求键的函数，而不是后端内存中任何内容的函数。

最少请求 (Least-requests) 将每个新请求发送到当前活动请求最少的后端，假设活动请求越少意味着越多的空闲容量。当每个请求花费大致相同的工作量时，这种方式很有效。

这些策略共享相同的三个假设：

1. 任何后端都可以处理任何请求。分配是策略选择而非正确性选择。
2. 请求是独立的。请求 N 上发生的事情不会改变您在请求 N+1 上应该做的事情。
3. 后端是可互换的。负载均衡器可以换掉一个而客户端不会注意到。

这些假设适用于无状态 Web 服务。LLM 推理打破了所有这三个假设。

LLM 在哪里打破了模型

LLM 工作负载以四种特定方式违反无状态假设。每一个都引入了一个传统路由无法处理的维度。

KV 缓存状态

KV 缓存状态：相同的 prompt 带来 80 倍的延迟差异 当一个 pod 处理推理请求时，前向传播会构建 KV 缓存：模型在每个 token 位置的中间状态，存储在 GPU 内存中。现代引擎在响应完成后会保留该缓存，以便后续共享前缀的请求可以跳过等效计算。

这极大地改变了路由问题。一个 100K token 的 prompt 如果落在已经缓存了前 75K token 的 pod 上，可以在毫秒级完成 prefill。而同一个 prompt 落在冷 pod 上则需要数秒。轮询方式对缓存状态视而不见，会导致相同请求的首个 token 时间 (TTFT) 不可预测。

缓存状态是规模化下 prefill 延迟差异的主要驱动因素。基于缓存驻留选择 pods 的路由器每一次命中都能节省与共享前缀长度成比例的 prefill 计算。这释放了集群原本会花费在重复计算已有工作上的 GPU 周期。

硬件专业化

LLM 推理有两个阶段，它们对硬件的要求不同。

Prefill vs decode pods Prefill 并行处理整个 prompt。它是计算密集型的。这意味着 GPU 核心被密集矩阵乘法（https://www.modular.com/blog/matrix-multiplication-on-nvidias-blackwell-part-1-introduction）饱和，同时处理数千个 token。

Decode 以自回归方式逐个生成 token，每个 token 依赖于它之前的所有 token。它是内存带宽密集型的。这意味着 GPU 大部分时间花在从高带宽内存 (HBM) 获取模型权重和 KV 缓存上，而大部分计算资源处于空闲状态。

在同一个 pod 上运行两个阶段意味着硬件永远无法针对任何一个进行优化。Prefill 需要密集计算；decode 需要内存带宽。针对其中一个优化的 pod 会低效利用另一个所需的资源。分解式部署使用针对每个阶段分别优化的 pods。单个客户端请求需要跨两者分配工作。

现代引擎使用分块 prefill 在同一 pod 上交错两个阶段，模糊了边界。但计算与带宽的根本区别仍然存在，当您在部署层面进行分解时，您的路由器必须知道哪个 pod 能做什么。

对话连续性

多轮对话和会话亲和性 大多数 LLM 流量是多轮的。用户发送一条消息。助手回复。用户发送另一条消息，而该消息隐含地包含整个对话历史作为上下文。

第 N+1 轮与第 N 轮共享一个前缀：系统 prompt、所有之前的轮次、所有之前的助手回复。如果第 N 轮的 KV 缓存仍然驻留在某个 pod 上，第 N+1 轮对于共享部分实际上是免费进行 prefill 的。如果缓存已被驱逐，或者第 N+1 轮落在不同的 pod 上，共享前缀将从零开始重新计算。

HTTP 中的会话亲和性过去意味着“将这个用户的请求路由到同一个后端，以便应用程序可以使用内存状态。“在 LLM 推理中它意味着相同的意思，但内存状态是 KV 缓存。做对了意味着首轮之后的每一轮都能获得亚秒级响应 vs 多秒级响应。

多步执行

Prefill → decode 流程 单个面向客户端的请求可能需要多个后端。

在分解式部署中，prefill pod 构建 KV 缓存，decode pod 生成 token。两者都无法单独服务请求。路由器选择一个 prefill pod，然后选择一个 decode pod，然后编排序列：将 prompt 发送到 prefill，等待完成，将相同的 prompt 加上缓存提示发送到 decode，将 token 流式返回给客户端。

HTTP 负载均衡器不这样做。它们每个请求只选择一个后端。在单调度路由器中添加多步协调是一种完全不同的路由形态。

三层架构

上述四个维度中的每一个都对路由系统提出了要求。这些要求分为三个不同的架构关注点，每个由一个单独的层处理。

三层路由架构

数据层

该层以路由决策所需的延迟跟踪 LLM 特定的状态。“N 个 pods 中哪个缓存了这些块？“这个问题必须在微秒级可回答，同时支持并发更新，对 pod 变化有弹性。带互斥锁的哈希表是不够的。

决策层

该层将路由逻辑表达为小型、可测试、可重用组件的组合。操作员选择一个过滤器、几个评分器、一个选择器，然后组装一个配置文件。框架在构建时验证组合，而不是在凌晨 3 点 traffic 下验证。

执行层

该层在决策层之上协调多步请求流程。单步路由是多步的一个退化情况：一个 pod，一个步骤。分解式 prefill/decode 是一般情况：两个 pods，两个步骤，第二个决策由第一个决定。同一框架处理两者，无需为每个变体添加新的 HTTP 处理程序。

本系列的第二和第三部分将构建这些层。

Modular Cloud 的路由层

本系列描述了 Modular Cloud 分布式推理框架内的路由层，以及它如何在生产推理工作负载中处理这四个问题。

前缀感知路由（token 化、块级哈希、负载感知绑定的缓存感知评分、上游延迟的熔断器）作为配置文件发货，而不是新算法。当团队需要新的路由行为时，工作是将插件组合成新配置文件，而不是从头编写新的路由策略。每种新的部署模式都重用已有的东西。

结论

LLM 引入了传统负载均衡器无法处理的四个维度：使后端选择成为性能关键决策的 KV 缓存状态、将单个请求拆分到不同 pod 类型的硬件专业化、将会话绑定到缓存驻留的对话连续性、以及需要协调一系列后端而不是选择一个的多步执行。

这个问题已从多个角度解决。NVIDIA Dynamo、llm-d、vLLM 生产栈、AIBrix、KServe 和 Envoy AI Gateway 各自在不同方向推动了推理路由：分解式 prefill/decode、前缀感知调度、KV 感知负载均衡、生产级服务原语。Modular Cloud 在此基础上构建。为了支持其目标的各种部署模式，Modular Cloud 将可组合插件和多步执行都作为一等公民，使新的部署模式成为您组装的配置文件，而不是您需要 fork 的策略。

这就是 Modular Cloud 的路由层设计要弥合的差距：三个架构层，以组合作为扩展模型，而不是 fork 或包装。本系列的其余部分将展示它是如何构建的。

下一步

第二部分：数据层。使得缓存感知路由成为可能的数据结构：分片位图、Fibonacci 扰动分布，以及对累积块哈希的二进制搜索，将 P x N 扫描变成 O(K x log N)。

第三部分：决策和执行层。将缓存状态转化为路由决策，然后转化为执行。五阶段可组合管道、插件间的类型化状态、以及 Selector/Workflow/Executor 分裂，使同一框架能够从轮询扩展到分解式 prefill/decode。

• 金发人士使用带有 Apple 标志的笔记本电脑。立即注册 立即注册我们的云平台，轻松上手。注册 (https://docs.modular.com/max/get-started) https://docs.modular.com/max/get-started
• 黑色手柄和圆形透明镜片的放大镜表情符号。浏览开放模型 浏览我们的模型目录，或部署您自己的自定义模型 浏览模型 (https://www.modular.com/models) https://www.modular.com/models

订阅我们的新闻通讯

获取我们最新的新闻、公告和更新，直接发送到您的邮箱。随时可取消订阅。

感谢订阅我们的新闻通讯！🚀

谢谢，

Modular 销售团队

哎呀！提交表单时出现错误。