同样 16 块 GPU，服务用户数却倍增：面向 LLM 集群的推理感知型路由

长话短说： 同样是 16 块 GPU，能够服务的用户数却增加了一倍。您的 GPU 费用保持不变，而处理能力却实现倍增。原本只能处理 20 个并发用户的集群，现在能够处理 200 个并发用户。这一切都归功于 llm-d 的推理调度程序，它专为跨分布式集群路由每一个请求而打造，能够全面监控每个节点、每个队列和每个缓存。大语言模型（LLM）的请求响应速度缓慢、不统一且成本高昂，而推理调度程序正是为此而生。

在任何其他场景均有效的模式

每使用 GPU 一小时都要付出相应的成本，关键在于您能从中获得多少有效的工作成果。

Kubernetes 是大规模构建、部署和运营分布式服务的有效方式。在标准的 Kubernetes 配置下，您只需定义部署，设置副本数量，然后 Kubernetes 服务会为您提供一个入口，通过轮询方式在所有 pod 之间实现负载均衡。对于 REST API、Web 服务和微服务而言，这种模式几乎堪称完美。请求响应迅速、一致，且每个请求的完成时间大致都在一秒以内。

但是，当您开始大规模提供大型生成式模型服务（例如 Llama、Mistral 或 GPT 级别的开源模型）时，这一假设便不再成立。

轮询机制的局限性

LLM 推理请求与普通的 HTTP 请求不同，正是这些差异导致标准负载均衡机制失效：

• 时间差异：一个请求可能耗时不到一秒，也可能超过一分钟，具体取决于要求模型执行的操作。轮询机制分配的是请求数量，而非工作量。如果某个副本连续收到多个耗时且成本高昂的请求，它就会成为瓶颈，而另一个副本则基本处于空闲状态。
• 形态差异：提示词短但生成的响应长的请求，与提示词长但响应短的请求，两者的行为特征截然不同。计算配置文件、内存压力和完成时间都各不相同。
• 阶段差异：每个推理请求内部都包含两个阶段：预填充阶段——通过一次并行扫描处理整个输入提示词；以及解码阶段——逐词元生成响应。这两个阶段的资源配置文件、持续时间以及对负载的敏感度各不相同。如果系统无法区分它们，就无法针对任一阶段进行优化。

轮询机制专为请求周期短、统一且成本低廉的工作负载而设计。无法洞察请求内部细节的调度程序，会无差别对待所有请求。

图 1：轮询机制分配的是请求数量，而非工作量。同样的 5 个请求（大小和计算成本各不相同）在各个 pod 之间的分布不均。一个 pod 被两个长请求压得不堪重负，而另一个 pod 则基本处于闲置状态。推理感知型路由能够洞察请求的形态、大小和负载情况，从而对实际工作量进行均衡分配。

在错误的 pod 上命中缓存即视为缓存未命中

vLLM 是 LLM 领域事实上的标准推理引擎，各大主流硬件加速器都针对它进行了优化，新模型发布时也自带 Day 0 级别的 vLLM 支持。它在单节点推理机制方面的表现尤为出色。

vLLM 引入了前缀缓存，以解决推理过程中成本最高的环节之一，即反复处理相同的提示词前缀。当多个请求共享相同的前缀（例如系统提示词、文档、对话历史记录）时，vLLM 可以缓存首次计算生成的键值对（KV）状态，并将其重复用于后续请求。缓存命中时，预填充步骤将完全跳过：提示词中已缓存部分的占比越高，首个词元生成时间（TTFT）缩短得就越多，但前提是请求必须被路由到存储该缓存的特定副本上。

一个在某个副本上几乎零成本的请求，却被路由到另一个副本，从头开始计算。优化机制虽然存在，但轮询路由并未加以利用。

在流量较低的情况下，这不过是错失一次机会。而在大规模场景下，您需要为相同的计算量支付双倍成本。

从节点走向集群

每个 pod 只了解自身情况。尽管每个 vLLM Pod 都能很好地处理自己负责的请求（例如管理内存、高效分批处理、以硬件允许的最快速度提供词元），但它并不知道其他 pod 正在处理什么、哪些副本正在承受高负载，也不知道前缀缓存状态数据在集群中的具体位置。 

协调问题出现在节点之上的集群层面，而 Kubernetes 是大规模分布式基础架构和编排的首选平台，因此 llm-d 从设计之初就以 Kubernetes 原生为构建目标，以解决这一具体问题。 

推理网关（IGW）正是这一理念在实践中的体现，它是一个基于 Envoy 和 Kubernetes 网关 API 构建的流量层，不仅理解 HTTP，还能理解 LLM 工作负载。在其背后，推理调度程序会实时监控 InferencePool 中的每个 pod（包括 队列深度、KV 缓存状态和负载），并将每个请求路由到正确的实例，而非按轮询顺序将请求发送给下一个实例。

图 2：推理网关（IGW）接收每个请求，并通过 ext_proc 向推理调度程序（EPP）进行咨询。调度程序根据两个实时信号（KV 缓存状态和负载）对 InferencePool 中的所有 pod 进行评分，将选定的端点返回给 IGW，随后 IGW 转发该请求。当发生缓存命中时，预填充的缓存部分将被重复使用，并立即开始解码。缓存未命中时，则完整执行预填充。

大规模推理调度： 相同的硬件，双倍的处理能力

推理调度程序（llm-d 的推理调度程序或 EPP）是将集群级协调落地的关键。它不会将所有 pod 视为可互换的个体，而是根据实时信号来路由每个请求：KV 缓存状态、队列深度和负载情况。每次请求都能准确地路由到正确的实例。

llm-d v0.5 的基准测试结果展示了该方案这在实际应用中带来的成效。

推理调度（使用 Qwen3-32B 模型，配置 8 个 vLLM pod、16 个 NVIDIA H100）：

• 与基准 Kubernetes 服务相比，吞吐量提升高达 109%。同样是 16 块 GPU，在满足服务级别目标（SLO）的前提下，可服务的并发用户数大约是原来的两倍。
• 同等负载下，首个词元生成时间（TTFT）缩短高达 99%。基准测试结果显示，在高负载下，基准 TTFT 攀升至约 80 秒，这令人难以忍受。而借助智能调度，可将这个时间控制在大约 150 毫秒。这就形成了两种极端的产品体验，一种让人感觉像是出现故障，另一种则是让人感觉即时响应。
  • 在这项基准测试中，16 块 GPU 稳定地维持了每秒约 11,000 个词元的输出速度。假设每次响应包含约 1,000 个词元，每位活跃用户每分钟约发送三次请求，这大致相当于在满足服务等级目标（SLO）的前提下支撑约 200 个并发用户——而在同样的硬件配置下，基准 Kubernetes 服务在并发用户数超过 20 时后便无法正常提供服务。

每个结果都受版本控制，并与特定的可再现指南相关联。

图 3：llm-d 推理调度与基准 Kubernetes 的对比——平均 TTFT 和总吞吐量与 QPS 的对比。拓扑：8 个 vLLM pod，16 块 NVIDIA H100（TP=2）。工作负载：使用共享前缀的合成数据，150 个组，每组包含 5 个提示词，系统/问题/输出长度分别为 6000/1200/1000 个词元。结果：P50 TTFT 为 136–157 毫秒，每秒输出 4500 到 11000 个词元，与基线相比，吞吐量提升高达 109%，TTFT 降幅达 99%。来源：llm-d v0.5。

vLLM 优化节点，llm-d 优化集群

vLLM 和 llm-d 旨在协同工作，只采用其中一项与两者并用，所产生的性能差距是可量化的：相同硬件上支持的用户数是原来的两倍，高负载下的延迟时间缩短 99%，集群面对 250 个并发用户时的表现与面对 20 个并发用户时一样稳定。

如果您正在运行两个或更多副本，则智能推理调度适用于您当前的工作负载。性能差距并非微乎其微，而是可扩展的集群与难以应对负载的集群之间的本质区别。 

这就是分布式推理的起点。

亲自体验规模化带来的效果

这篇博客文章中每个数字背后所依据的 llm-d 指南和基准测试配置均已公开，且可再现。llm-d v0.5 发行版是一个不错的起点。

红帽 AI Enterprise 包含企业级支持的 llm-d 版本，并提供红帽 AI Enterprise 的 60 天免费试用。如果您想在自己的基础架构上运行该方案，这是一个很好的起点。

如果您想先了解调度程序的运行情况，可查看《llm-d 入门交互式演示》，其中详细介绍了如何路由请求。

作者注释：基准测试数据源自 llm-d v0.5 版本。所有结果均可使用 llm-d 指南中发布的、受版本控制的配置进行再现。