跳转至正文

宣布 llm-d 社区成立！

·阅读时长 12 分钟
Robert Shaw
Robert Shaw
红帽（Red Hat）工程总监
Clayton Coleman
Clayton Coleman
Google 杰出工程师
Carlos Costa
Carlos Costa
IBM 杰出工程师

宣布 llm-d 社区成立​

llm-d 是一个云原生高性能分布式 LLM 推理框架
——它是供任何人进行大规模服务的“明径”，在大多数硬件加速器上针对大多数模型提供最快的价值实现时间和极具竞争力的性价比。

借助 llm-d，用户可以使用模块化、高性能的端到端服务解决方案实现生成式 AI 部署的运维化。该方案利用了最新的分布式推理优化技术（如 KV 缓存感知路由和解耦推理），并与 推理网关 (IGW) 中的 Kubernetes 运维工具协同设计并集成。

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 具有长输入（提示词和检索到的文档）和短生成输出
    • 推理任务（Reasoning）具有短或中等输入以及长生成输出

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

  • 这些请求时间的差异可能导致实例之间严重的负载不平衡，随着负载较重的实例不堪重负，这种情况会进一步加剧。过载导致更长的 ITL（Token 间延迟），进而导致更多负载，陷入 ITL 增加的恶性循环。

B. 路由到具有缓存计算结果的特定副本可以实现几个数量级的延迟提升。

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

The agentic pattern sequence

  • 像 vLLM 这样的 LLM 推理服务器实现了一种称为“自动前缀缓存”的方法，当缓存命中时，可以“跳过”大量预填充计算。如果请求被路由到缓存中已有数据的 vLLM 副本，我们就能跳过计算。通过更大的缓存容量提高前缀缓存命中可能性，可以显著改善长尾延迟。

The prefix aching method

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

  • 推理分为两个阶段：预填充（prefill）和解码（decode）。预填充生成第一个输出 token，并对所有提示 token 并行运行——该阶段受计算限制。解码通过对模型进行完整计算逐个生成 token——该阶段受内存带宽限制。

  • 标准的 LLM 部署在单个副本中执行预填充和解码阶段。鉴于推理的预填充和解码阶段具有不同的资源需求，将这些阶段共置于同一副本会导致资源利用效率低下，尤其是在处理长序列时。

  • 解耦服务（Disaggregation）（例如 Distserve）将预填充和解码阶段分离到不同的变体实例上，从而实现各阶段的独立优化和扩展。

Disaggregation separates the prefill and decode phases

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

  • 单个 LLM 端点的用例可能有多种服务质量要求。请考虑以下示例：

    • 延迟是最重要的因素：代码补全请求和搜索响应需要最大限度地降低延迟，以提供“实时”体验。延迟容忍度在毫秒级。
    • 延迟很重要：交互式用例下的聊天智能体对话和邮件草稿编写。延迟容忍度在秒级。
    • 可容忍延迟：视频会议和邮件摘要，以及具有每日或每小时使用模式的“深度研究”智能体。延迟容忍度在分钟级。
    • 对延迟不敏感：隔夜批处理工作负载、会议纪要生成和自主智能体。延迟容忍度在小时级。

  • 鉴于 LLM 的计算密集性（以及随之而来的高成本），实现严格的延迟 SLO 成本要高得多。这种延迟需求光谱提供了进一步优化基础架构效率的机会——工作负载对延迟越不敏感，我们就越能在其他工作负载之间优化基础架构效率。

为什么选择 llm-d？​

为了利用这些特性并实现 LLM 工作负载的最优性能，推理服务领域正在迅速向分布式集群规模架构转型。例如，在其“开源周”期间，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）。

  • Kubernetes (K8s)：K8s 是用于自动部署、扩展和管理容器化应用程序的开源容器编排引擎。它是跨各种硬件加速器部署和更新 LLM 推理引擎的行业标准。

  • Inference Gateway (IGW)：IGW 是一个官方 Kubernetes 项目，它通过推理专用路由扩展了 Gateway API（下一代 Kubernetes Ingress 和负载均衡 API）。IGW 包含许多重要功能，如模型路由、服务优先级和用于“智能”负载均衡的可扩展调度逻辑。IGW 与许多不同的网关实现（如 Envoy）集成，使其在 Kubernetes 集群间具有广泛的可移植性。

以及我们的核心新贡献：

  • vLLM 优化推理调度器 - IGW 通过 端点选择器协议 (EPP) 定义了一种可定制的“智能”负载均衡模式。推理调度器利用 vLLM 暴露的增强运维遥测数据，实现了在解耦服务、前缀缓存感知和负载感知方面进行“智能”调度决策所需的过滤和评分算法，并经过验证可供 llm-d 用户开箱即用。高级团队还可以调整或实现自己的评分器和过滤器，以进一步针对其用例进行定制，同时仍能受益于推理网关中即将推出的运维功能，如流控和延迟感知均衡。

  • 使用 vLLM 的解耦服务 - llm-d 利用 vLLM 最近启用的通过可插拔 KV 连接器 API 支持解耦服务的功能，在独立实例上运行预填充和解码，并使用高性能传输库（如 NVIDIA 的 NIXL）。

    在 llm-d 中，我们计划为预填充/解码 (P/D) 解耦提供两条“明晰”路径：

    • 使用快速互连（IB、RDMA、ICI）的延迟优化实现
    • 使用数据中心网络的吞吐量优化实现
    • 更多详情，请参见我们的愿景文档：[公开] llm-d 解耦服务愿景

  • 使用 vLLM 的解耦前缀缓存 - llm-d 使用解耦服务中相同的 vLLM KV 连接器 API，为之前的计算提供可插拔缓存，包括将 KV 卸载到主机、远程存储以及像 LMCache 这样的系统。

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

    • 独立缓存，支持基本卸载到主机内存和磁盘，提供一种利用所有系统资源的零运维成本机制
    • 共享缓存，支持实例间的 KV 传输和带全局索引的共享存储，能够以更高的运维复杂度为代价提供更高性能。
    • 更多详情，请参见我们的愿景文档：[公开] llm-d 前缀缓存愿景

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

    借鉴终端用户和 AIBrix 等 OSS 合作伙伴的丰富经验，我们计划实现一个感知流量和硬件的自动扩缩容程序，该程序可以：

    • 衡量每个模型服务器实例的容量
    • 推导出考虑不同请求形态和 QoS 的负载函数
    • 利用最近的流量组合——QPS（每秒查询数）、QoS 和形态分布——计算处理预填充、解码和延迟容忍请求的最优实例组合，并为每个实例标记分组
    • 报告每个分组的负载指标，使 Kubernetes 水平 Pod 自动扩缩容能够在不违反 SLO 的情况下，将正在使用的硬件与所需的硬件匹配
    • 更多详情，请参见我们的愿景文档：[公开] llm-d 自动扩缩容愿景

llm-d 功能示例​

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

前缀和 KV 缓存感知路由

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

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

模型配置ISL（输入序列长度）OSL（输出序列长度）延迟 SLO
S1LlaMA 4 Scout FP8TP2, 2 副本20,000100无
S2LlaMA 4 Scout FP8TP2, 4 副本12,000100P95 TTFT <= 2s
S3Llama 3.1 70B FP16TP2, 4 副本8,000100P95 TTFT <= 2s

关键观察

  • S1: 在 4 QPS 下，llm-d 实现的平均 TTFT 比基线低约 3 倍（越低越好）。
  • S2: llm-d 在满足 SLO 要求的同时，提供的 QPS 比基线高约 50%（越高越好）。
  • S3: llm-d 在 SLO 约束下维持的 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` 配置进行尝试。

开始使用 llm-d​

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

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

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