LLM大模型系列（九）：NVIDIA Dynamo框架详解——PD分离式部署技术解析

猫先生@魔方AI空间

已于 2025-06-17 19:30:20 修改

阅读量442

点赞数 5

分类专栏：大模型部署 LLM大模型文章标签：大模型大模型部署 PD分离部署人工智能

于 2025-06-17 19:27:01 首次发布

本文链接：https://blog.youkuaiyun.com/m_aigc2022/article/details/148722171

版权

LLM大模型同时被 2 个专栏收录

9 篇文章

订阅专栏

大模型部署

3 篇文章

订阅专栏

〔更多精彩AI内容，尽在 「魔方AI空间」 ，引领AIGC科技时代〕

本文作者：猫先生

NVIDIA Dynamo是2025年3月GTC大会推出的开源分布式推理服务框架，旨在解决大语言模型（LLM）推理过程中的资源不匹配和低效问题。

Dynamo通过PD分离式部署（Prefill-Decode Disaggregation）技术，将LLM推理拆分为两个阶段：计算密集型的预填充（Prefill）和内存密集型的解码（Decode），并分别部署到不同GPU上运行，从而实现资源的最优利用和推理效率的大幅提升。

这一创新技术基于DistServe和Splitwise等研究论文的思路，结合NVIDIA在GPU加速计算领域的深厚积累，形成了独特的分布式推理架构。

一、Dynamo框架整体架构

Dynamo采用模块化的分布式架构，由多个协同工作的核心组件构成，各组件均可独立扩展。

Dynamo 是一个高吞吐量低延迟的推理框架，专为在多节点分布式环境中服务生成式 AI 和推理模型而设计。Dynamo 设计为与推理引擎无关（支持 TRT-LLM、vLLM、SGLang 或其他），并捕获 LLM 特定的功能，例如：

分离预填充和解码推理 – 最大化 GPU 吞吐量，并促进吞吐量和延迟之间的权衡。
动态 GPU 调度 – 根据波动需求优化性能。
LLM 感知请求路由 – 消除不必要的 KV 缓存重新计算。
加速数据传输 – 使用 NIXL 减少推理响应时间。
KV 缓存卸载 – 利用多个内存层次结构提高系统吞吐量。

Dynamo的核心优势在于其完全开源，采用Rust和Python混合编程模式（核心性能模块用Rust编写，上层逻辑用Python实现），为开发者提供了完全的透明度和灵活性。通过模块化设计，用户可根据需要选择特定组件，确保与现有AI技术栈兼容，避免高昂的迁移成本。

二、PD分离式部署技术原理

PD分离技术是Dynamo的核心创新，其原理基于对LLM推理过程的深入理解。

LLM推理通常分为两个阶段：Prefill和Decode，这两个阶段对硬件资源的需求存在显著差异：

阶段	资源需求特性	计算模式	显存占用模式
Prefill	计算密集型	高并行度，矩阵乘法为主	低，固定规模
Decode	内存密集型	顺序生成，访存为主	随上下文增长指数级上升

在传统集成式推理流水线中，LLM的Prefill和Decode阶段往往被置于同一GPU上运行，导致资源需求不匹配，资源利用率不高。例如，当用户请求的Prefill长度和Decode长度非常不匹配时，同一GPU需要同时处理高算力需求和高内存带宽需求的任务，难以发挥最佳性能。

Dynamo通过以下方式实现PD分离：

1、阶段拆分：将LLM推理拆分为两个独立阶段，Prefill负责处理用户输入（prompt），生成第一个输出token和KV Cache；Decode负责基于KV Cache依次生成后续token。

2、Worker分离：为两个阶段分别部署Worker节点，Prefill Worker和Decode Worker在不同GPU上运行，避免相互干扰。例如，在腾讯云的部署案例中，使用了3个H20节点（每个节点8个GPU），其中：

2个节点专门部署Prefill Workers（每个节点部署8个Worker，tp=1，pp=8）
1个节点专门部署Decode Workers（部署8个Worker，tp=8，pp=1）

3、通信优化：通过NIXL库实现GPU间零拷贝数据传输，当Prefill阶段完成后，迅速将生成的KV Cache经由NIXL推送给Decode节点，减少数据传输延迟。

4、智能调度：GPU Planner监控GPU容量指标（如算力利用率、内存带宽使用率、队列长度等），根据实时负载动态调整Worker数量与GPU分配。例如，在Hopper架构上运行Llama模型时，Dynamo可将性能提升一倍以上；在GB200 NVL72集群上运行DeepSeek-R1 671B模型时，吞吐量可提升30倍。

PD分离技术使每个GPU专注于特定任务，避免了资源浪费。例如，Prefill阶段可使用计算性能更强但内存带宽相对较低的GPU，而Decode阶段则使用内存带宽更高的GPU（如配备HBM的H100或Blackwell GPU）。

三、Dynamo的源代码关键部分解析

Dynamo作为开源框架，其代码结构清晰展示了PD分离的实现细节。

以下是关键代码模块的解析：

1、PrefillQueue实现

PrefillQueue是PD分离的核心组件。在Dynamo的dynamo/examples/llm/utils/prefill_queue.py中，对 NATSQueue 的包装，专门用于处理 RemotePrefillRequest 类型的请求队列，主要用于 LLM 推理系统中 prefill 阶段的请求分发和处理。

class PrefillQueue(NATSQueue):
    """
    A wrapper of NATSQueue for PrefillRequest.
    The stream name is forced to be "prefill_queue".
    """

    def __init__(
        self,
        stream_name="prefill_queue",
        nats_server: str = "nats://localhost:4222",
        dequeue_timeout: float = 1,
    ):
        super().__init__(
            stream_name=stream_name,
            nats_server=nats_server,
            dequeue_timeout=dequeue_timeout,
        )

    async def enqueue_prefill_request(
        self, prefill_request: RemotePrefillRequest
    ) -> None:
        encoded_request = msgspec.json.encode(prefill_request)
        await self.enqueue_task(encoded_request)

    async def dequeue_prefill_request(self) -> Optional[RemotePrefillRequest]:
        encoded_request = await self.dequeue_task()
        if encoded_request is not None:
            prefill_request = msgspec.json.decode(
                encoded_request, type=RemotePrefillRequest
            )
            return prefill_request
        else:
            return None

2、模型并行配置

Dynamo支持灵活的模型并行策略，允许为Prefill和Decode阶段设置不同的TP（张量并行）和PP（流水线并行）度数。配置文件通常位于examples/llm/configs/中：

Common:
  model: deepseek-ai/DeepSeek-R1-Distill-Llama-8B
  router: kv
  block-size: 64
  max-model-len: 16384
  kv-transfer-config: '{"kv_connector":"DynamoNixlConnector"}'

Frontend:
  served_model_name: deepseek-ai/DeepSeek-R1-Distill-Llama-8B
  endpoint: dynamo.Processor.chat/completions
  port: 8000

Processor:
  common-configs: [model, block-size, max-model-len, router]

Router:
  min-workers: 1
  common-configs: [model, router]

VllmWorker:
  enforce-eager: true
  max-num-batched-tokens: 16384
  enable-prefix-caching: true
  tensor-parallel-size: 1
  ServiceArgs:
    workers: 1
    resources:
      gpu: 1
  common-configs: [model, block-size, max-model-len, router, kv-transfer-config]

Planner:
  environment: local
  no-operation: true

3、KV Cache管理模块

dynamo/docs/kv_cache_manager.md

Dynamo的KV Cache管理器（KV Cache Manager）负责维护全局的KV Cache索引和多层次存储。

Dynamo Distributed KV Manager 有两种实现：V1 和 V2。例如上图Dynamo KV manager V1的设计。

左侧部分说明了 V1 架构中的执行时间线和数据移动顺序。vLLM 等推理引擎可以启动具有灵活访问粒度的异步作，从而支持各种重叠策略，以根据优先级是吞吐量还是延迟来优化执行。
右侧部分描述了运行时内的数据流。目前，不会分配超出推理引擎所需的 GPU 高带宽内存（HBM）的任何部分，确保其对推理任务的独占利用。在推理运行时中，GPU 设备内存可以完全专用于键值（KV）存储，也可以部分分配给前缀 KV 缓存，这些缓存由推理引擎动态管理，类似于 vLLM。

当推理引擎确定应从 GPU 内存中驱逐 KV 缓存中的某些条目时，它会调用 put_async（） API 由 KV 管理器卸载这些条目，KV 管理器会更新其索引并将数据传输到适当的存储层（CPU 内存或 CPU 和 SSD 的组合）。相反，如果推理引擎无法在其自行管理的前缀缓存中找到所需的 KV 条目，它会向 KV 管理器发出 get_async（）请求。如果 KV 条目已经存在，则通过 get_async（）进行检索将显著减少重新计算开销，确保高效的 KV 管理、优化的内存利用率和改进的推理性能。

在 V1 实现中，CPU 内存充当 SSD 存储的缓存层。如果所需的 KV 条目驻留在 CPU 内存中，则系统会绕过 SSD 访问，从而减少传输延迟。异步 API （如 get_async（）或 put_async（））也启用传输，因此不会影响系统性能。

V2 实现引入了跨工作程序实例和存储的分布式 KV 池，其中包含设计中概述的所有功能。开发仍在进行中

4、NIXL通信库集成

NIXL是Dynamo的底层通信库，支持GPU间零拷贝数据传输。

NIXL库通过GPUDirect RDMA等硬件加速技术实现低延迟通信，绕过CPU中转，保障跨服务器通信的高吞吐和低延迟。这一设计确保了Prefill和Decode阶段之间的数据交换不会成为性能瓶颈。

四、PD分离式部署实战操作步骤

1、环境准备

硬件要求：

多GPU节点集群（建议至少3个节点，每个节点8个GPU）
支持HBM显存和NVLink通信的GPU（如NVIDIA H100或Blackwell架构）
推荐操作系统：Ubuntu 24.04

依赖安装：

apt-get update
DEBIAN_FRONTEND=noninteractive apt-get install -yq python3-dev python3-pip python3-venv libucx0
python3 -m venv venv
source venv/bin/activate

pip install "ai-dynamo[all]"

信库配置：

安装NVIDIA容器工具包
配置NIXL通信库（集成在Dynamo中，无需单独安装）

2、启动服务

本地启动：

# 启动API服务和Worker节点
dynamo serve graphs.agg:Frontend -f configs/agg.yaml

# 发送测试请求
curl localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{
    "model": "deepseek-ai/DeepSeek-R1-Distill-Llama-8B",
    "messages": [{"role": "user", "content": "Hello, how are you?"}],
    "stream": false,
    "max_tokens": 300
}' | jq

Docker Compose部署：

# deploy/docker-compose.yml
version: '3.8'
services:
  planner:
    image: dynamo-planner:latest
    ports:
      - "8080:8080"
    depends_on:
      - router
      - prefills-worker
      - decodes-worker

  router:
    image: dynamo-router:latest
    ports:
      - "8090:8090"
    depends_on:
      - prefills-worker
      - decodes-worker

  prefills-worker:
    image: dynamo-prefills:latest
    environment:
      - WORKER_CONFIG=prefills.yaml
      - GPU_ID=0
    deploy:
      replicas: 8  # 根据GPU数量调整
      resources:
        limits:
          nvidia.com/gpu: 1

  decodes-worker:
    image: dynamo-decodes:latest
    environment:
      - WORKER_CONFIG=decodes.yaml
      - GPU_ID=0
    deploy:
      replicas: 4
      resources:
        limits:
          nvidia.com/gpu: 1

Kubernetes集群部署：

编写Prefill和Decode Worker的Deployment YAML文件
配置Service暴露API端口
使用kubectl apply部署组件
设置Horizontal Pod Autoscaler（HPA）实现动态扩缩容

3、性能验证

PD分离部署后，可通过以下指标验证其效果：

首包延迟（TTFT）：从输入到输出第一个token的延迟
逐token延迟（TPOT）：每个后续token的生成时间
吞吐量（Throughput）：每秒生成的token总数

在腾讯云的测试案例中，使用Dynamo的PD分离部署对比vLLM传统部署，取得了以下性能提升：

首包延迟（TTFT）降低55.7%
预填充吞吐量提高125%
解码阶段性能波动减少
集群整体吞吐量提升30倍（DeepSeek-R1 671B模型）

五、PD分离式部署的应用场景与优势

PD分离式部署特别适合以下应用场景：

推理流量波动大的场景：通过动态资源调度，Dynamo能够适应推理流量的峰谷变化，避免固定分配GPU资源导致的高负载或资源浪费。
长上下文推理场景：当用户请求的输入序列较长（如>4096 tokens）时，Decode阶段的显存需求会迅速增长。通过KV Cache分层存储，Dynamo能够有效管理长上下文推理的显存压力。
高吞吐量需求场景：在需要同时处理大量请求的场景中，PD分离部署允许独立扩展Prefill和Decode Worker的数量，实现吞吐量的线性增长。
成本敏感的场景：通过将KV Cache卸载到CPU内存或SSD，Dynamo能够在保持用户体验的同时降低GPU资源消耗，从而降低总体推理成本。

PD分离式部署的主要优势在于：