LLM-D: Kubernetes原生分布式推理框架

宣布成立 llm-d 社区​

llm-d 是一个 Kubernetes 原生的高性能分布式 LLM 推理框架，为任何希望进行规模化服务的人提供了一条清晰明确的路径：针对大多数硬件加速器上的大多数模型，以最快速度实现价值，并获得具有竞争力的单位成本性能。

借助 llm-d，用户可以将生成式 AI 部署投入生产运行。它提供模块化、高性能的端到端服务解决方案，采用 KV-cache 感知路由和解耦式服务等最新的分布式推理优化技术，并与 Inference Gateway（IGW）中的 Kubernetes 运维工具协同设计、深度集成。

LLM 推理走向分布式​

Kubernetes 通常通过配置相同的副本并采用轮询负载均衡，对应用工作负载进行横向扩展。

这种简单模式对大多数请求模式都非常有效，这些请求通常具有以下特征：

• 请求生命周期较短，资源利用率通常较为一致
• 请求的延迟服务等级目标（SLO）通常一致
• 每个副本处理每个请求的能力基本相同
• 让不同变体各司其职，并协调多个副本共同处理单个请求，并无实际价值

然而，LLM 推理工作负载十分特殊，其请求缓慢、不均衡且成本高昂。这意味着，典型的横向扩展和负载均衡模式无法实现最优性能。

下面逐项进行分析：

A. 请求成本高昂，资源利用率差异显著

每个 LLM 推理请求都有不同的“形状”，可以通过输入 token 数量和输出 token 数量来衡量。不同请求和工作负载之间的这些参数存在显著差异。RAG 的输入很长——包括提示词和检索到的文档——但生成的输出较短。推理任务的输入较短或中等，而生成的输出较长。

RAG 的输入很长——包括提示词和检索到的文档——但生成的输出较短。

推理任务的输入较短或中等，而生成的输出较长。

请求耗时的这些差异可能导致实例间出现严重失衡，而负载较高的实例一旦不堪重负，这种失衡还会进一步加剧。过载会导致更长的 ITL（Inter-Token Latency，token 间延迟），进而造成更高的负载，并进一步增加 ITL。

B. 将请求路由到缓存了先前计算结果的特定副本，可以将延迟改善数个数量级

许多常见的 LLM 工作负载都具有“多轮”请求模式，即将相同的提示词反复发送到同一个实例。智能体式任务（工具调用属于迭代式请求流程）。代码补全任务（请求会复用当前代码库作为上下文）。

智能体式任务（工具调用属于迭代式请求流程）。

代码补全任务（请求会复用当前代码库作为上下文）。

vLLM 等 LLM 推理服务器实现了一种名为“自动前缀缓存”的方法。当缓存命中时，它可以“跳过”大量的 prefill 计算。如果请求被路由到缓存中已有相关数据的 vLLM 副本，就可以跳过这些计算。通过扩大缓存容量来提高前缀缓存命中的概率，可以显著改善尾延迟。

C. 让不同副本各司其职，并协调它们共同处理单个请求，可以提高每块 GPU 的吞吐量

推理分为两个阶段——prefill 和 decode。prefill 会生成第一个输出 token，并针对提示词中的所有 token 并行运行——这一阶段受计算能力限制。decode 通过每次完整遍历模型来逐个生成 token，因此这一阶段受内存带宽限制。

推理分为两个阶段——prefill 和 decode。prefill 会生成第一个输出 token，并针对提示词中的所有 token 并行运行——这一阶段受计算能力限制。decode 通过每次完整遍历模型来逐个生成 token，因此这一阶段受内存带宽限制。

标准 LLM 部署会在单个副本中执行推理的 prefill 和 decode 阶段。鉴于推理的 prefill 和 decode 阶段具有不同的资源需求，将这两个阶段放在同一个副本中会导致资源利用效率低下，尤其是在处理长序列时。

标准 LLM 部署会在单个副本中执行推理的 prefill 和 decode 阶段。鉴于推理的 prefill 和 decode 阶段具有不同的资源需求，将这两个阶段放在同一个副本中会导致资源利用效率低下，尤其是在处理长序列时。

解耦（例如 Distserve）会将 prefill 和 decode 阶段分离到不同的变体上，从而能够独立优化和扩展每个阶段。Google 在 TPU 上采用解耦式服务，以改善首 token 延迟并简化运维扩展。DeepSeek 发布了对其推理系统设计的讨论；该系统通过积极采用解耦架构，在规模化场景下实现了出色的性能。

解耦（例如 Distserve）会将 prefill 和 decode 阶段分离到不同的变体上，从而能够独立优化和扩展每个阶段。

Google 在 TPU 上采用解耦式服务，以改善首 token 延迟并简化运维扩展。

Google 在 TPU 上采用解耦式服务，以改善首 token 延迟并简化运维扩展。

DeepSeek 发布了对其推理系统设计的讨论；该系统通过积极采用解耦架构，在规模化场景下实现了出色的性能。

DeepSeek 发布了对其推理系统设计的讨论；该系统通过积极采用解耦架构，在规模化场景下实现了出色的性能。

D. 生产部署通常具有多种服务质量（QoS）要求

单个 LLM 端点的不同使用场景可能具有多种多样的服务质量要求。请考虑以下示例：延迟是最重要的因素：代码补全请求和搜索响应需要尽可能降低延迟，以提供“人在环路中”的体验。可容忍 O(ms) 级延迟。延迟很重要：聊天智能体会话以及交互式场景下的电子邮件起草。可容忍 O(seconds) 级延迟。可容忍延迟：视频通话和电子邮件摘要，以及按天或按小时使用的“深度研究”智能体。可容忍 O(minutes) 级延迟。对延迟不敏感：夜间批处理工作负载、会议纪要生成和自主智能体。可容忍 O(hours) 级延迟。

单个 LLM 端点的不同使用场景可能具有多种多样的服务质量要求。请考虑以下示例：

延迟是最重要的因素：代码补全请求和搜索响应需要尽可能降低延迟，以提供“人在环路中”的体验。可容忍 O(ms) 级延迟。

延迟很重要：聊天智能体会话以及交互式场景下的电子邮件起草。可容忍 O(seconds) 级延迟。

可容忍延迟：视频通话和电子邮件摘要，以及按天或按小时使用的“深度研究”智能体。可容忍 O(minutes) 级延迟。

对延迟不敏感：夜间批处理工作负载、会议纪要生成和自主智能体。可容忍 O(hours) 级延迟。

鉴于 LLM 需要密集计算，因而成本高昂，实现严格的延迟 SLO 所需的成本也会高得多。这种多样化的延迟要求为进一步优化基础设施效率提供了机会——工作负载对延迟的容忍度越高，我们就越能在与其他工作负载共存时优化基础设施效率。

鉴于 LLM 需要密集计算，因而成本高昂，实现严格的延迟 SLO 所需的成本也会高得多。这种多样化的延迟要求为进一步优化基础设施效率提供了机会——工作负载对延迟的容忍度越高，我们就越能在与其他工作负载共存时优化基础设施效率。

为了利用这些特征并为 LLM 工作负载实现最优性能，推理服务领域正在迅速转向分布式、集群规模的架构。例如，在“Open Source Week”期间，DeepSeek 团队公布了其推理系统的设计。该系统积极采用解耦和 KV 缓存，以实现出色的单位计算成本性能。

然而，对大多数生成式 AI 创新者、ML 平台团队和 IT 运维团队而言，这些优势仍然遥不可及。构建和运行复杂的单体系统既耗时又极具挑战，尤其是在技术创新日新月异、企业部署需要为不同使用场景运行数十乃至数百个模型的背景下。这种复杂性会带来产品上市延迟、运维成本升高、系统无序扩张，以及难以采用新技术和开展实验等风险。

llm-d 的目标是为所有人提供一条清晰明确的路径，使其能够在现有部署框架——Kubernetes——中采用领先的分布式推理优化技术。

为了实现这一目标，我们为该项目制定了以下设计原则：

可运维性：采用模块化且具有弹性的架构，通过 Inference Gateway API 与 Kubernetes 进行原生集成

灵活性：跨平台（正在积极支持 NVIDIA、Google TPU、AMD 和 Intel），并为技术栈中关键的可组合层提供可扩展的实现

性能：利用解耦和前缀感知路由等分布式优化，在满足 SLO 的同时实现最高的 tok/$

为实现这一目标，我们基于行业标准的开源技术——vLLM、Kubernetes 和 Inference Gateway——为 llm-d 设计了模块化、分层式架构。

vLLM。vLLM 是领先的开源 LLM 推理引擎，以高性能支持广泛的模型（包括 Llama 和 DeepSeek）和硬件加速器（包括 NVIDIA GPU、Google TPU、AMD）。

vLLM。vLLM 是领先的开源 LLM 推理引擎，以高性能支持广泛的模型（包括 Llama 和 DeepSeek）和硬件加速器（包括 NVIDIA GPU、Google TPU、AMD）。

Kubernetes（K8s）。K8s 是一个开源容器编排引擎，用于自动执行容器化应用的部署、扩缩容和管理。它是在各种硬件加速器上部署和更新 LLM 推理引擎的行业标准。

Kubernetes（K8s）。K8s 是一个开源容器编排引擎，用于自动执行容器化应用的部署、扩缩容和管理。它是在各种硬件加速器上部署和更新 LLM 推理引擎的行业标准。

Inference Gateway（IGW）。IGW 是 Kubernetes 的官方项目，通过推理专用路由扩展 Gateway API（下一代 Kubernetes Ingress 和负载均衡 API）。IGW 包含模型路由、服务优先级以及用于“智能”负载均衡的可扩展调度逻辑等许多重要功能。IGW 可与 Envoy 等多种不同的网关实现集成，因此能够广泛移植到各种 Kubernetes 集群中。

Inference Gateway（IGW）。IGW 是 Kubernetes 的官方项目，通过推理专用路由扩展 Gateway API（下一代 Kubernetes Ingress 和负载均衡 API）。IGW 包含模型路由、服务优先级以及用于“智能”负载均衡的可扩展调度逻辑等许多重要功能。IGW 可与 Envoy 等多种不同的网关实现集成，因此能够广泛移植到各种 Kubernetes 集群中。

我们的主要新贡献如下：

面向 vLLM 优化的推理调度器——IGW 通过 Endpoint Picker Protocol（EPP）定义了一种可定制“智能”负载均衡的模式。该推理调度器利用 vLLM 提供的增强型运行遥测，实现了围绕解耦式服务、前缀缓存感知和负载感知进行“智能”调度决策所需的过滤与评分算法，并已验证可供 llm-d 用户开箱即用。高级团队还可以调整或实现自己的评分器和过滤器，针对其用例进行进一步定制，同时仍能受益于推理网关即将推出的流量控制、延迟感知均衡等运行功能。有关更多详细信息，请参阅我们的 Northstar：[PUBLIC] llm-d Scheduler Northstar

面向 vLLM 优化的推理调度器——IGW 通过 Endpoint Picker Protocol（EPP）定义了一种可定制“智能”负载均衡的模式。该推理调度器利用 vLLM 提供的增强型运行遥测，实现了围绕解耦式服务、前缀缓存感知和负载感知进行“智能”调度决策所需的过滤与评分算法，并已验证可供 llm-d 用户开箱即用。高级团队还可以调整或实现自己的评分器和过滤器，针对其用例进行进一步定制，同时仍能受益于推理网关即将推出的流量控制、延迟感知均衡等运行功能。

有关更多详细信息，请参阅我们的 Northstar：[PUBLIC] llm-d Scheduler Northstar

使用 vLLM 实现解耦式服务——llm-d 利用 vLLM 最近通过可插拔 KV Connector API 新增的解耦式服务支持，在相互独立的实例上运行预填充和解码，并使用 NVIDIA 的 NIXL 等高性能传输库。在 llm-d 中，我们计划为预填充/解码（P/D）解耦支持两条“重点支持”的路径：使用高速互连（IB、RDMA、ICI）的延迟优化实现；使用数据中心网络的吞吐量优化实现。有关更多详细信息，请参阅我们的 Northstar：[PUBLIC] llm-d Disaggregated Serving Northstar

使用 vLLM 实现解耦式服务——llm-d 利用 vLLM 最近通过可插拔 KV Connector API 新增的解耦式服务支持，在相互独立的实例上运行预填充和解码，并使用 NVIDIA 的 NIXL 等高性能传输库。

在 llm-d 中，我们计划为预填充/解码（P/D）解耦支持两条“重点支持”的路径：

使用高速互连（IB、RDMA、ICI）的延迟优化实现

使用数据中心网络的吞吐量优化实现

有关更多详细信息，请参阅我们的 Northstar：[PUBLIC] llm-d Disaggregated Serving Northstar

使用 vLLM 实现解耦式前缀缓存——llm-d 使用解耦式服务所采用的同一个 vLLM KV Connector API，为先前的计算提供可插拔缓存，包括将 KV 卸载到主机、远程存储以及 LMCache 等系统中。在 llm-d 中，我们计划为 KV 缓存解耦支持两条“重点支持”的路径：独立缓存，通过将数据基本卸载到主机内存和磁盘，提供一种能够利用全部系统资源且没有运维成本的机制；共享缓存，在实例之间传输 KV，并使用带有全局索引的共享存储，以更复杂的系统运维为代价，提供实现更高性能的可能性。有关更多详细信息，请参阅我们的 Northstar：[PUBLIC] llm-d Prefix Caching Northstar

使用 vLLM 实现解耦式前缀缓存——llm-d 使用解耦式服务所采用的同一个 vLLM KV Connector API，为先前的计算提供可插拔缓存，包括将 KV 卸载到主机、远程存储以及 LMCache 等系统中。

在 llm-d 中，我们计划为 KV 缓存解耦支持两条“重点支持”的路径：

独立缓存，通过将数据基本卸载到主机内存和磁盘，提供一种能够利用全部系统资源且没有运维成本的机制

共享缓存，在实例之间传输 KV，并使用带有全局索引的共享存储，以更复杂的系统运维为代价，提供实现更高性能的可能性。

有关更多详细信息，请参阅我们的 Northstar：[PUBLIC] llm-d Prefix Caching Northstar

跨硬件、工作负载和流量的变体自动扩缩容——不同加速器硬件在计算能力、内存和成本方面存在巨大差异；共享相同模型的工作负载对服务质量有着不同要求；LLM 推理的不同阶段以及大型混合专家模型受到的计算、内存或网络瓶颈各不相同；传入流量也会随时间和工作负载而变化。目前，所有这些决策都在部署时作出，而几乎所有部署者都难以通过启用自动扩缩容来安全地降低成本。借鉴终端用户和 AIBrix 等 OSS 协作者的丰富经验，我们计划实现一种能够感知流量和硬件的自动扩缩容器，它将：测量每个模型服务器实例的容量；推导一个将不同请求形态和 QoS 纳入考虑的负载函数；根据近期的流量组合——QPS（Queries Per Second，每秒查询数）、QoS 和形态分布——计算处理预填充、解码和可容忍延迟请求的最优实例组合，并为每个实例标记其所属分组；报告每个分组的负载指标，使 Kubernetes 水平 Pod 自动扩缩容能够让使用中的硬件与所需硬件相匹配，同时不违反 SLO。有关更多详细信息，请参阅我们的 Northstar：[PUBLIC] llm-d Autoscaling Northstar

跨硬件、工作负载和流量的变体自动扩缩容——不同加速器硬件在计算能力、内存和成本方面存在巨大差异；共享相同模型的工作负载对服务质量有着不同要求；LLM 推理的不同阶段以及大型混合专家模型受到的计算、内存或网络瓶颈各不相同；传入流量也会随时间和工作负载而变化。目前，所有这些决策都在部署时作出，而几乎所有部署者都难以通过启用自动扩缩容来安全地降低成本。

借鉴终端用户和 AIBrix 等 OSS 协作者的丰富经验，我们计划实现一种能够感知流量和硬件的自动扩缩容器，它将：

测量每个模型服务器实例的容量

推导一个将不同请求形态和 QoS 纳入考虑的负载函数

根据近期的流量组合——QPS（Queries Per Second，每秒查询数）、QoS 和形态分布——计算处理预填充、解码和可容忍延迟请求的最优实例组合，并为每个实例标记其所属分组

按分组报告负载指标，使 Kubernetes 水平 Pod 自动扩缩容能够在不违反 SLO 的前提下，让实际使用的硬件与所需硬件相匹配。

有关更多详细信息，请参阅我们的 Northstar：[公开] llm-d 自动扩缩容 Northstar

llm-d 将 IGW 与 vLLM 集成在一起，打造出一个高性能的分布式服务栈。下面我们来讨论 llm-d 所支持的一些示例功能。

前缀感知与 KV 缓存感知路由

llm-d 中 IGW 与 vLLM 的首次关键协作，是开发前缀缓存感知路由，以补充 IGW 中现有的 KV 缓存利用率感知负载均衡。

我们进行了一系列实验，以评估 llm-d-inference-scheduler 在启用前缀感知路由后的性能。实验使用 LMbenchmark，在 2 个 NVIDIA 8xH100 节点上运行，并采用长输入/短输出配置，旨在重点考验 KV 缓存复用能力和路由决策质量。

S1：在 4 QPS 下，llm-d 的平均 TTFT 大约比基线低 3 倍（越低越好）。

S2：在满足 SLO 要求的同时，llm-d 提供的 QPS 比基线高约 50%（越高越好）。

S3：在 SLO 约束下，llm-d 可持续维持基线 2 倍的 QPS（越高越好）。

这些结果表明，与基线相比，llm-d 的缓存感知与前缀感知调度能够有效降低 TTFT 并提高 QPS，同时始终满足 SLA 要求。

你可以使用快速入门中的 base.yaml 配置进行尝试。作为自定义示例，还可以参阅用于添加自定义调度器过滤器的模板。

我们已经使用 vLLM 和 llm-d-inference-scheduler 完成了 P/D 解耦的初步实现，对于以预填充为主的工作负载（20:1 ISL | OSL），该实现带来了令人期待的加速效果。下一步，我们将重点完成异构 TP 的实现，并对解耦式服务开展全面的基准测试。短期优先事项包括：支持异构 TP、通过高性能 P/D + EP<>DP 扩展大规模 MoE，以及实现 DP 感知负载均衡。未来几周内，我们将发布一篇详细的性能博客文章。

你可以使用快速入门中的 pd-nixl.yaml 配置进行尝试。

开始使用 llm-d​

llm-d 将 vLLM 的高性能与 Kubernetes 的可运维性结合起来，为分布式 LLM 推理打造了一种模块化架构，旨在为最新模型和智能体架构提供高性能支持。

我们欢迎 AI 工程师和研究人员加入 llm-d 社区并作出贡献：

查看我们的 Github 仓库：https://github.com/llm-d/llm-d

加入我们的开发者 Slack：/slack

尝试我们的快速入门，在你的 Kubernetes 集群上部署 llm-d：https://github.com/llm-d/llm-d-deployer/tree/main/quickstart

欢迎加入我们。AI 的未来是开放的。