llm-d：基于 Kubernetes 的原生分布式推理框架

llm-d, Kubernetes native distributed inference

Source | HN Comments

文章介绍了 llm-d，一个基于 Kubernetes 的分布式 LLM 推理框架。llm-d 旨在通过结合 vLLM、Kubernetes 和 Inference Gateway，提供高性能、模块化的 GenAI 部署方案。它利用分离式服务、前缀缓存感知路由等技术优化推理，并支持跨硬件、工作负载和流量的自动缩放。llm-d 社区欢迎 AI 工程师和研究人员参与，并提供了快速入门指南。

Skip to main content What is llm-d?User Guide Community News Recent posts

2025

隆重推出 llm-d 社区！

2025年5月20日 · 阅读时长11分钟 Robert Shaw Director of Engineering, Red Hat Clayton Coleman Distinguished Engineer, Google Carlos Costa Distinguished Engineer, IBM

隆重推出 llm-d 社区

llm-d 是一个 Kubernetes 原生的、高性能的分布式 LLM 推理框架，它为任何希望大规模提供服务的人提供了一条清晰的路径，在大多数硬件加速器上，对于大多数模型来说，它都具有最快的价值实现时间和具有竞争力的每美元性能。

借助 llm-d，用户可以通过模块化、高性能的端到端服务解决方案来运营 gen AI 部署。该解决方案利用最新的分布式推理优化技术，如 KV-cache 感知路由和分离式服务，这些技术与 Kubernetes 操作工具在 Inference Gateway (IGW) 中共同设计和集成。

LLM 推理走向分布式

为什么标准的横向扩展方法效果不佳

Kubernetes 通常使用统一的副本和轮询负载均衡来横向扩展应用程序工作负载。

Figure 1: Deploying a service to multiple vLLM instances

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

请求是短期的，并且在资源利用率方面通常是均匀的
请求通常具有统一的延迟服务级别目标 (SLO)
每个副本都可以同等地处理每个请求
专门化变体和协调副本来处理单个请求没有用处

LLM 服务是独特的

然而，LLM 推理工作负载是独特的，因为它具有缓慢、不均匀且昂贵的请求。这意味着典型的横向扩展和负载均衡模式无法达到最佳性能。

Figure 2: Comparison of modern HTTP requests

让我们逐步来看一下：

A. 请求很昂贵，并且在资源利用率方面存在显着差异。

每个 LLM 推理请求都有不同的“形状”，以输入 token 和输出 token 的数量来衡量。这些参数在不同的请求和工作负载之间存在显着差异。
- RAG 具有较长的输入（prompt 和检索到的文档）和较短的生成输出
- Reasoning 具有较短或中等的输入和较长的生成输出

Figure 3: Comparing the RAG pattern and Thinking/Reasoning pattern with prefill and decode stages

请求时间的这些差异可能导致实例之间的显着不平衡，并且随着负载的增加，这些不平衡会加剧。过载会导致更长的 ITL（Inter-Token Latency，Token 间延迟），这会导致更多负载，从而导致更多 ITL。

B. 路由到具有缓存的先前计算的特定副本可以实现数量级更高的延迟。

许多常见的 LLM 工作负载具有“多轮”请求模式，其中相同的 prompt 被迭代地发送到相同的实例。
- Agentic（工具调用是迭代请求流）
- 代码完成任务（请求重用当前代码库作为上下文）

The agentic pattern sequence

LLM 推理服务器（如 vLLM）实现了一种称为“自动前缀缓存”的方法，该方法可以在缓存命中时“跳过”大量 prefill 计算。如果请求被路由到 vLLM 副本，该副本的缓存中具有数据，那么我们可以跳过计算。通过更大的缓存大小来增加前缀缓存命中的可能性可以显着改善尾部延迟。

The prefix aching method

C. 专门化和协调副本以处理单个请求可以提高每个 GPU 的吞吐量。

推理分为两个阶段：prefill 和 decode。Prefill 生成第一个输出 token，并在所有 prompt token 上并行运行——此阶段是计算密集型的。Decode 通过对模型进行完整传递来一次生成一个 token，从而使该阶段受内存带宽限制。
标准 LLM 部署在单个副本中执行推理的 prefill 和 decode 阶段。鉴于推理的 prefill 和 decode 阶段具有不同的资源需求，因此将这些阶段放在同一副本上会导致资源使用效率低下，尤其是对于长序列而言。
Disaggregation（分离）（例如 Distserve）将 prefill 和 decode 阶段分离到不同的变体上，从而可以独立优化和扩展每个阶段。
- Google 利用 TPU 上的分离式服务来提供更好的首 token 延迟并简化操作扩展。
- DeepSeek 发布了对其推理系统设计的讨论，该设计利用了激进的分离来实现卓越的规模化性能。

Disaggregation separates the prefill and decode phases

D. 生产部署通常具有一系列服务质量 (QoS) 要求。

单个 LLM 端点的用例可能具有各种服务质量要求。考虑以下示例：
- 延迟是最重要的因素：代码完成请求和搜索响应需要最大限度地减少延迟，以提供“循环内”体验。O(ms) 延迟容忍度。
- 延迟很重要：具有交互式用例的聊天机器人会话和电子邮件起草。O(秒) 延迟容忍度。
- 延迟容忍：视频通话和电子邮件摘要以及具有每日或每小时使用模式的“深度研究”代理。O(分钟) 延迟容忍度。
- 延迟无关：夜间批量处理工作负载、会议纪要生成和自主代理。O(小时) 延迟容忍度。
鉴于 LLM 的计算强度（以及因此产生的高成本），实现严格的延迟 SLO 成本要高得多。这种延迟要求范围提供了一个进一步优化基础设施效率的机会——工作负载的延迟容忍度越高，我们就可以在其他工作负载中优化基础设施效率。

为什么选择 llm-d？

为了利用这些特性并实现 LLM 工作负载的最佳性能，推理服务领域正在迅速过渡到分布式集群规模架构。例如，DeepSeek 团队在其“开源周”中发布了其推理系统的设计，该设计积极利用分离和 KV 缓存来实现卓越的每美元计算性能。

然而，对于大多数 GenAI 创新者、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），并具有高性能。
Kubernetes (K8s)。K8s 是一个开源容器编排引擎，用于自动化容器化应用程序的部署、扩展和管理。它是跨各种硬件加速器部署和更新 LLM 推理引擎的行业标准。
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 实现分离式服务 - llm-d 利用 vLLM 最近启用的通过可插拔 KV Connector API 对分离式服务的支持，使用高性能传输库（如 NVIDIA 的 NIXL）在独立实例上运行 prefill 和 decode。

在 llm-d 中，我们计划支持 prefill/decode (P/D) 分离的两个“清晰”的路径：

* 使用快速互连 (IB, RDMA, ICI) 优化的延迟实现
* 使用数据中心网络优化的吞吐量实现
* 有关更多详细信息，请参阅我们的 Northstar：[[PUBLIC] llm-d Disaggregated Serving Northstar](https://llm-d.ai/blog/<https:/docs.google.com/document/d/1FNN5snmipaTxEA1FGEeSH7Z_kEqskouKD1XYhVyTHr8/edit?tab=t.0#heading=h.ycwld2oth1kj>)

通过 vLLM 实现分离式前缀缓存 - llm-d 使用与分离式服务中使用的相同的 vLLM KV 连接器 API 来为先前的计算提供可插拔的缓存，包括将 KV 卸载到主机、远程存储和类似 LMCache 的系统。

在 llm-d 中，我们计划支持 KV 缓存分离的两个“清晰”的路径：

* 独立缓存，基本卸载到主机内存和磁盘，提供零运营成本机制，利用所有系统资源
* 在实例之间进行 KV 传输和具有全局索引的共享存储的共享缓存，以更高的性能为代价提供可能更高的性能。
* 有关更多详细信息，请参阅我们的 Northstar：[[PUBLIC] llm-d Prefix Caching Northstar](https://llm-d.ai/blog/<https:/docs.google.com/document/d/1d-jKVHpTJ_tkvy6Pfbl3q2FM59NpfnqPAh__Uz_bEZ8/edit?tab=t.0#heading=h.6qazyl873259>)

跨硬件、工作负载和流量的变体自动缩放 - 加速器硬件在计算、内存和成本方面差异很大，共享相同模型的工作负载因其所需的服务质量而异，LLM 推理的不同阶段和大型专家混合模型因其计算、内存或网络限制而异，并且传入的流量随时间和工作负载而变化。如今，所有这些决策都是在部署时做出的，几乎所有部署者都在努力启用自动缩放以安全地降低其成本。

借鉴来自最终用户和像 AIBrix 这样的 OSS 合作者的丰富经验，我们计划实施一个流量和硬件感知的自动缩放器，该缩放器：

* 测量每个模型服务器实例的容量
* 派生一个考虑不同请求形状和 QoS 的负载函数
* 使用最近的流量组合 - QPS（每秒查询数）、QoS 和形状分布 - 计算处理预填充、解码和延迟容忍请求的最佳实例组合，并使用分组标记每个实例
* 报告每个分组的负载指标，允许 Kubernetes 水平 Pod 自动缩放将正在使用的硬件与所需的硬件相匹配，而不会违反 SLO
* 有关更多详细信息，请参阅我们的 Northstar：[[PUBLIC] llm-d Autoscaling Northstar](https://llm-d.ai/blog/<https:/docs.google.com/document/d/1inTneLEZTv3rDEBB9KLOB9K6oMq8c3jkogARJqdt_58/edit?tab=t.0>)

llm-d 功能示例

llm-d 集成了 IGW 和 vLLM，从而实现了一个高性能的分布式服务堆栈。让我们讨论一下 llm-d 启用的一些示例功能。

前缀和 KV 缓存感知路由

IGW 和 vLLM 在 llm-d 中的第一个关键合作是开发前缀缓存感知路由，以补充 IGW 中现有的 KV 缓存利用率感知负载均衡。

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

Model| Configuration| ISL| OSL| Latency SLO ---|---|---|---|--- S1| LlaMA 4 Scout FP8| TP2, 2 replicas| 20,000| 100| None S2| LlaMA 4 Scout FP8| TP2, 4 replicas| 12,000| 100| P95 TTFT <= 2s S3| Llama 3.1 70B FP16| TP2, 4 replicas| 8,000| 100| P95 TTFT <= 2s

主要观察结果：

S1： 在 4 QPS 下，llm-d 实现的平均 TTFT 比基线低约 3 倍（越低越好）。
S2： 在满足 SLO 要求的同时，llm-d 提供的 QPS 比基线高约 50%（越高越好）。
S3： 在 SLO 约束下，llm-d 维持的 QPS 是基线的 2 倍（越高越好）。

这些结果表明，与基线相比，llm-d 的缓存和前缀感知调度有效地减少了 TTFT 并增加了 QPS，同时始终满足 SLA 要求。

在我们的快速入门中使用 base.yaml 配置来试用一下。作为自定义示例，请参阅模板以添加您自己的调度器过滤器。

P/D 分离

我们已经完成了 vLLM 和 llm-d-inference-scheduler 的 P/D 分离的初始实现，该实现为预填充密集型工作负载（20:1 ISL | OSL）提供了有希望的加速。我们接下来的重点是完成具有异构 TP 的实现，并完成分离式服务的全面基准测试。短期优先级包括启用异构 TP，通过高性能 P/D + EP<>DP 扩展大型 MoE，以及 DP 感知负载均衡。我们将在未来几周内发布一篇详细的性能博客。

在我们的快速入门中使用 pd-nixl.yaml 配置来试用一下。