ModelExpress：以光速分发模型制品（12分钟阅读）

# ModelExpress：以光速分发模型工件 来源：https://developer.nvidia.com/blog/modelexpress-distributing-model-artifacts-at-the-speed-of-light 每移动一个字节都有成本。当模型检查点增长到数百吉字节甚至一太字节时，这些成本会迅速累积。更糟的是，在集群中移动这些模型权重非常常见。例如，冷启动可能需要将权重从远程存储拉取到 GPU 内存；自动扩缩和滚动更新必须填充每一个新副本；而强化学习后训练则不断将更新后的权重从训练器转移到推出工作者。这些看似不同的工作流，却都施加了相同的重复代价：在开始有用工作之前花费时间移动权重。 ## ModelExpress：加速模型权重生命周期https://developer.nvidia.com/blog/modelexpress-distributing-model-artifacts-at-the-speed-of-light#modelexpress_accelerating_the_model_weight_lifecycle NVIDIA ModelExpress (MX) 基于一个简单的想法构建：在加载模型之前，首先询问其权重的兼容副本已经存在于何处。MX 不将每个副本视为独立的冷启动，而是选择最快的可用源和传输路径。 当服务中的对等节点已经在 GPU 中持有兼容的权重时，MX 通过 NVIDIA Inference Xfer Library (NIXL) 使用 P2P RDMA 直接从 GPU 到 GPU 传输权重，从而绕过对对象存储、本地磁盘和主机内存的冗余访问。当没有对等节点可用时，MX 通过从对象存储流式传输（不落盘）或直接将本地文件读入 GPU 内存，从最快支持的路径启动。 MX 在 10 秒内将 DeepSeek-V4 Pro 权重和 JIT 内核缓存工件从服务中的副本传输到新副本，将总启动时间从 8 分钟减少到 1 分 44 秒。这篇文章的其余部分展示了 MX 如何选择最快的可用路径到 GPU 内存，优先使用来自服务副本的 P2P RDMA，并在此过程中消除冗余下载和复制。然后，它将相同的方法扩展到重用内核缓存和分发强化学习权重更新。 ModelExpress 概述。控制平面通过 Redis 或 Kubernetes 元数据发现兼容源。数据平面沿探测的优先级链传输权重——通过 NIXL 经 GPUDirect RDMA 直接从服务对等节点移动权重，通过 ModelStreamer 从对象存储流式传输，或通过 GDS 从本地存储读取。 *图 1. ModelExpress 概述* ## 加速从远程存储到 GPU 内存的每个阶段https://developer.nvidia.com/blog/modelexpress-distributing-model-artifacts-at-the-speed-of-light#accelerating_every_stage_from_remote_storage_to_gpu_memory 每个新工作者必须从以下三个位置之一获取其权重：远程存储（例如 HF 或 S3）、本地存储，或已经服务于该模型的另一个工作者。对于第一个工作者，还没有对等节点，因此它必须从存储启动。MX 可以从对象存储流式传输检查点，或从快速本地存储加载，从而消除任一路径上可避免的复制。 一旦第一个工作者开始服务，首选源就会改变。其权重已经在 GPU 内存中驻留、后处理并布局好，因此之后所有兼容的工作者都应该通过 P2P RDMA 直接从该对等节点加载。MX 自动完成这一过渡：从存储启动一次，然后按 GPU 到 GPU 进行扩展，仅在没有兼容对等节点可用时才回退到存储。 ### 启动第一个工作者：从存储启动https://developer.nvidia.com/blog/modelexpress-distributing-model-artifacts-at-the-speed-of-light#starting_the_first_worker_bootstrap_from_storage **远程对象存储到 GPU：避免本地磁盘** 当检查点位于云存储桶中，而您不想配置和管理磁盘缓存层时，MX 使用 Model Streamer 通过可重用的 CPU 暂存缓冲区分片拉取 safetensors 并进入 GPU。检查点从不落盘到本地磁盘，从而消除了中间下载、重新加载和存储卷。 Model Streamer 使用多线程张量读取器并发跨检查点分片获取张量范围。随着张量到达，它将远程读取与 GPU 放置流水线化：完成的张量传递给推理引擎，而后续张量仍在获取中。这使存储、网络和 GPU 复制路径保持忙碌，同时重用有限的主机内存。 在张量并行部署中，参与等级划分远程读取并共享结果（通常通过 NCCL），而不是让每个等级独立下载完整检查点。MX 将此分布式流直接连接到推理引擎的权重加载器，为第一个工作者成为后续每个兼容副本的 P2P 源做好准备。 **集群入口：一次下载，而非 N 次** 当集群维护一个共享磁盘缓存层（例如 K8s 中的持久卷）时，MX 确保整个集群只填充一次。如果 10 个副本同时想要获取 806 GiB 的 DeepSeek-V4 Pro 模型，它们将需要通过网络拉取大约 8 TiB 的相同数据，同时竞争相同的入口带宽。MX 模型缓存服务将这些请求合并为一个协调下载：元数据存储中的原子声明选择一个下载器，而其余副本跟踪其进度并重用缓存的副本。集群一次性承担外部下载成本，然后每个副本可以从相同的缓存检查点开始。 **本地存储到 GPU：绕过主机内存暂存** 当系统支持 GPUDirect Storage (GDS) 时，MX 通过 NIXL 的多线程 GDS 后端直接从本地存储将检查点文件读入 GPU 内存。NIXL 并行执行批量张量读取，直接进入 GPU 内存，绕过主机内存和传统加载器所需的暂存副本。用户无需显式启用 GDS：MX 自动检测能力，并在不可用时回退到其他加载策略。 **本地存储到 GPU：使用 ModelStreamer 流水线化本地读取** MX 也可以通过 ModelStreamer 加载本地检查点。多个操作系统线程并发将 safetensors 读入可配置的 CPU 缓冲区，同时完成的张量移动到 GPU，后续读取并行继续。与 GDS 不同，此路径仍然通过主机内存暂存，但它将磁盘 I/O 与 GPU 放置重叠，受益于操作系统页面缓存，并在直接存储到 GPU 访问不可用时提供可移植的快速路径。 ### 启动第一个之后的所有工作者：从服务对等节点获取https://developer.nvidia.com/blog/modelexpress-distributing-model-artifacts-at-the-speed-of-light#starting_every_worker_after_the_first_fetch_from_a_serving_peer 这是 MX 的关键特性。一旦另一个副本已经在服务同一模型，权重已完成大部分旅程：它们驻留在 GPU 内存中，经过后处理并布局好以用于推理引擎。MX 将该副本视为实时权重源。在确认兼容性后，它直接从源 GPU 将张量传输到目标 GPU。一旦其权重加载完毕，新副本加入源池，为后续副本提供另一个可加载的对等节点。每次成功传输后，该池随部署规模一起增长，将扩展转变为 GPU 到 GPU 的扇出，而不是重复的冷加载。 MX 控制平面发现兼容的对等节点，交换传输元数据，并跟踪源就绪状态，但从不处理权重字节本身。在数据平面上，MX 使用 NIXL 作为默认传输引擎，其可插拔后端允许在各种网络上获得峰值性能，例如 InfiniBand、RoCE、NVLink、EFA 等。MX 拥有一流的传输接口，允许诸如 `fabric-lib` 和独立 Mooncake 等库与 MX 集成。 一个图示，展示新的引擎副本如何发现并通过 NIXL 经 RDMA 直接从源获取模型权重，新副本加入源池以实现扇出扩展。 *图 2. 通过 NIXL 的 P2P GPUDirect RDMA 权重传输* 在任何传输开始之前，MX 根据模型和运行时设置计算 `mx_source_id`，这些设置决定张量布局，然后只考虑具有匹配 ID 的对等节点。控制平面通过 Redis、Kubernetes CRD 或 `k8s-service`（无服务器）元数据后端发现这些对等节点。 ### 优化 NIXL 内存注册开销https://developer.nvidia.com/blog/modelexpress-distributing-model-artifacts-at-the-speed-of-light#optimizing_nixl_memory_registration_overhead 在 NIXL 可以对张量进行 RDMA 之前，其背后的 GPU 内存必须注册：一个返回用于远程访问的远程密钥 (rkey) 的 `ibv_reg_mr` 调用。大型模型有数万个张量，逐个注册它们的速度足够慢，以至于会影响到预算。默认情况下，MX 单独注册每个张量。两种可选策略可减少注册成本： - **池注册** 对每个底层 `cudaMalloc` 分配只注册一次，而不是每个张量，在典型模型上将注册计数减少 80% 到 99%，且不改变传输语义。 - **VMM 区域注册** 更进一步。它安装一个 `CUDAPluggableAllocator`，将所有加载时分配路由到单个 16 TiB 虚拟地址区域，然后在加载结束时将整个使用的范围注册为一个 dmabuf 支持的内存区域。注册从每个张量一次调用缩减为总共一次调用；张量描述符只需携带该单一区域的偏移量。 使用 DeepSeek-V4-Pro TP=8 在 vLLM 引擎上，如下面图 3 所示，我们测量了每种方法的平均 NIXL 注册时间。 一个柱状图，比较 DeepSeek-V4-Pro (vLLM 上 TP=8) 在三种策略下的 NIXL 内存注册时间：逐张量注册（基线）、池注册和 VMM 区域注册（最快）。 *图 3. NIXL 内存注册优化* ### 运行时路径选择和安全回退https://developer.nvidia.com/blog/modelexpress-distributing-model-artifacts-at-the-speed-of-light#runtime_path_selection_and_safe_fallback 启动时，MX 探测可用的能力，自动跳过环境不支持的任何路径。第一个适用的策略按当前优先级顺序运行：`P2P RDMA -> ModelStreamer -> GDS -> 默认加载器（主机暂存 POSIX I/O）`。如果路径不可用或在修改模型状态之前失败，MX 自动回退。如果在权重开始落地后发生故障，它会在继续之前重新初始化模型，因此永远不会服务部分写入的权重。 P2P 重试仅在传输开始前针对元数据故障交替使用其他对等节点，而本地加载器始终是最终回退。这种能力驱动的设计使 MX 核心与硬件和软件无关，仅在支持的平台上启用特定于平台的快速路径。 ### 端到端结果https://developer.nvidia.com/blog/modelexpress-distributing-model-artifacts-at-the-speed-of-light#end-to-end_results 我们在一个 8×B200 GPU 节点上运行 DeepSeek-V4-Pro，配备 NVIDIA ConnectX-7 NIC，并比较了不同冷启动场景下的总模型加载时间。每个副本使用 vLLM 0.23.0，TP=8 和 `--enable-flashinfer-autotune`。见下图 4。 一个柱状图，比较 DeepSeek-V4-Pro 在 8×B200 节点上通过四条路径的总模型加载时间：P2P RDMA、ModelStreamer、GDS 和默认主机暂存 POSIX I/O。 *图 4. 端到端冷启动模型加载时间比较：HF vs ModelStreamer (S3) vs 磁盘 vs P2P RDMA* ## 不仅加载，更是预热：继承已编译的内核https://developer.nvidia.com/blog/modelexpress-distributing-model-artifacts-at-the-speed-of-light#warm_not_just_loaded_inheriting_the_compiled_kernels 将权重放入 GPU 内存至关重要，但加载的模型尚未准备好服务。在其第一次前向传播中，引擎会 JIT 编译和自动调优内核（例如 torch.compile、Triton、DeepGEMM、TileLang 等），并为精确的模型、数据类型、量化和 GPU 捕获 CUDA 图。对于像 DeepSeek-V4 Pro 这样的模型，这可能需要几分钟，一旦 MX 减少了权重加载延迟，这就会成为主要的启动成本（见下图 5）。 一个堆叠柱状图，显示在 ModelExpress 消除权重加载延迟后，JIT 内核编译（torch.compile、Triton、DeepGEMM 等）成为 DeepSeek-V4-Pro 的主要启动成本。 *图 5. DeepSeek-V4 Pro (TP=8 vLLM) 的启动时间分解* 这种重复的预热是可以避免的。当模型、软件栈和 GPU 架构匹配时，一个副本可以支付编译成本，其余副本可以继承生成的缓存。 MX 的工件传输 API 打包这些基于文件的工件，通过 NIXL 的 CPU 到 CPU RDMA 路径直接在已注册的主机内存缓冲区之间传输，然后验证并安装到目标引擎的缓存目录中。这消除了 Kubernetes 中共享 ReadWriteMany (RWX) 卷的需求，同时工件特定的 `mx_source_id` 防止跨不兼容副本的重用。当配置了 Redis 或 Kubernetes 元数据后端时，MX 自动检测标准缓存位置。 我们使用相同的设置来测量内核工件传输可以减少多少启动时间。启用工件的运行传输了 Triton/DeepGEMM/TileLang/CuTe DSL/FlashInfer 缓存。图表比较了主要启动阶段以及从进程开始到 API 就绪的总挂钟时间。 一个分组柱状图，比较磁盘基线和 ModelExpress P2P RDMA 在有和无工件传输机制时的总启动时间，显示继承 Triton、DeepGEMM、TileLang、CuTe DSL 和 FlashInfer 内核缓存显著减少了到 API 就绪的挂钟时间。 *图 6. 使用 ModelExpress 减少总启动时间* ## 当权重每一步都变化时：RL 后训练https://developer.nvidia.com/blog/modelexpress-distributing-model-artifacts-at-the-speed-of-light#when_the_weights_change_every_step_rl_post-training 到目前为止，所有内容都假设模型的权重一旦加载就是固定的。RL 后训练打破了这一假设。训练器每一步都更新策略，而生成 rollouts 的推理 Actor 必须在下一次生成之前获取这些权重。与推理启动一样，权重移动在 RL 中处于关键路径：当更新后的权重从训练器的分布式布局（无论是 FSDP/DTensor 分片还是 Megatron TP、PP 和 EP 分区）转移到推理引擎的布局时，Rollout 工作者在等待。 一个图示，展示 ModelExpress RL 重新拟合流程，其中训练器等级向控制平面通告张量所有权以供源发现，Rollout 工作者通过 NIXL 直接从训练器等级拉取更新后的权重字节。 *图 7. ModelExpress 使 RL 重新拟合成为接收者驱动* MX 通过以下四个阶段驱动重新拟合： 1. **发布：** 每个训练器等级通告其已拥有的张量或分片，以及描述其形状、数据类型、放置和参数映射的元数据给 MX。 2. **发现：** Rollout 工作者通过 MX 查找请求的权重版本及其可用源。 3. **规划：** 接收者将已发布的拥有信息映射到其自身的布局，并识别哪些源包含所需的张量或范围。 4. **拉取、转换和加载：** 接收者直接对这些源发出单侧读取。 MX 包含接收者驱动重新拟合的核心构建块，客户正在评估它们。