每移动一个字节都有成本。随着模型检查点增长到数百 GB 甚至 1 TB，这一成本会迅速累积。更糟的是，在集群中搬运这些模型权重极为常见。例如，冷启动可能需要将权重从远程存储拉取到 GPU 内存；自动扩缩容和滚动更新必须为每个新副本填充权重；而 RL 后训练则持续将更新后的权重从训练器移动到 rollout worker。这些看起来可能是不同的工作流，但它们施加的是同一种反复出现的负担：在真正有用的工作开始之前，先花时间搬运权重。
ModelExpress：加速模型权重生命周期
NVIDIA ModelExpress（MX）围绕一个简单的理念构建：在加载模型之前，先询问其权重的兼容副本已经存在于何处。MX 不把每个副本都当作独立的冷启动，而是选择最快的可用来源和传输路径。
当某个服务对等节点已在 GPU 中持有兼容权重时，MX 通过 NVIDIA Inference Xfer Library（NIXL）经由 P2P RDMA 直接在 GPU 到 GPU 之间传输这些权重，绕过对对象存储、本地磁盘和主机内存的冗余访问。当没有可用对等节点时，MX 从最快的受支持路径进行引导，从对象存储流式传输，而无需落盘，或直接将本地文件读入 GPU 内存。
MX 将 DeepSeek-V4 Pro 权重和 JIT Kernel 缓存产物从服务副本传输到全新副本，耗时不到 10 秒，将总启动时间从 8 分钟缩短至 1 分 44 秒。本文的其余部分将展示 MX 如何选择通往 GPU 内存的最快可用路径，优先采用来自服务副本的 P2P RDMA，并在此过程中消除冗余的下载和复制。随后，它将同样的方法扩展到复用内核缓存和分发 RL 权重更新。
图 1. ModelExpress 概览
加速从远程存储到 GPU 内存的每个阶段
每个新 worker 都必须从三个地方之一获取其权重：远程存储（例如 HF 或 S3）、本地存储，或另一个已在服务该模型的 worker。对于第一个 worker，尚不存在对等节点，因此它必须从存储进行引导。MX 可以从对象存储流式传输检查点，或从快速本地存储加载，从而消除任一路径上可避免的复制。
一旦第一个 worker 开始服务，首选来源就发生了变化。它的权重已经常驻、经过后处理，并以 GPU 内存中的布局就位，因此其后的每个兼容 worker 都应通过 P2P RDMA 直接从该对等节点加载。MX 会自动完成这一转换：从存储引导一次，然后以 GPU 到 GPU 的方式横向扩展，仅在没有兼容对等节点时才回退到存储。
启动第一个 worker：从存储引导
远程对象存储到 GPU：避免本地磁盘
当检查点存放在云存储桶中，而你又不想额外配置和管理磁盘缓存层时，MX 会使用 Model Streamer 通过可复用的 CPU 暂存缓冲区将 safetensors 拉取到 GPU 中。检查点永远不会落到本地磁盘上，从而消除了中间的下载、重新加载和存储卷。
Model Streamer 使用多线程张量读取器，跨检查点分片并发获取张量范围。当张量到达时，它将远程读取与 GPU 放置流水线化：已完成的张量被传递给推理引擎，而后续张量仍在获取中。这在复用有限主机内存的同时，保持存储、网络和 GPU 拷贝路径处于忙碌状态。
在张量并行部署中，参与的 rank 会分担远程读取并共享结果，通常通过 NCCL 进行，而不是让每个 rank 独立下载完整的检查点。MX 将这种分布式流直接连接到推理引擎的权重加载器，准备好第一个 worker 成为后续每个兼容副本的 P2P 源。
集群入口：下载一次，而非 N 次
当集群维护共享磁盘缓存层（例如 K8s 中的持久卷）时，MX 确保整个集群只填充一次。如果 10 个副本同时想要获取 806 GiB 的 DeepSeek-V4 Pro 模型，它们将需要在网络上拉取大约 8 TiB 的相同数据，同时竞争相同的入口带宽。MX Model Cache Service 将这些请求合并为一次协调下载：Metadata Store 中的原子声明选择一个下载器，而其余副本跟踪其进度并复用缓存的副本。集群只需支付一次外部下载成本，之后每个副本都可以从同一个缓存的检查点开始。
本地存储到 GPU：绕过主机内存暂存
当系统支持 GPUDirect Storage (GDS) 时，MX 通过 NIXL 的多线程 GDS 后端直接从本地存储读取检查点文件到 GPU 内存。NIXL 并行执行批量张量读取，直接读入 GPU 内存，绕过主机内存以及传统加载器所需的暂存拷贝。用户无需显式启用 GDS：MX 会自动检测该能力，并在不可用时回退到另一种加载策略。
本地存储到 GPU：使用 ModelStreamer 流水线化本地读取
MX 也可以通过 ModelStreamer 加载本地检查点。多个操作系统线程并发地将 safetensors 读入可配置的 CPU 缓冲区，同时已完成的张量移动到 GPU，后续读取继续并行进行。与 GDS 不同，此路径仍然通过主机内存暂存，但它将磁盘 I/O 与 GPU 放置重叠，受益于操作系统页面缓存，并在直接存储到 GPU 访问不可用时提供可移植的快速路径。
在第一个 worker 之后启动每个 worker：从服务对等节点获取
这是 MX 的关键特性。一旦另一个副本已经在为同一个模型提供服务，权重就已经完成了大部分旅程：它们驻留在 GPU 内存中，经过后处理，并为推理引擎布局好。MX 将该副本视为一个活跃的权重源。在确认兼容性后，它直接将张量从源 GPU 传输到目标 GPU。一旦新副本的权重加载完成，它就会加入源池，为后续副本提供另一个可加载的对等节点。随着每次成功传输，该池随部署一同增长，将横向扩展转变为 GPU 到 GPU 的扇出，而非重复的冷加载。
MX 控制平面发现兼容的对等节点、交换传输元数据并跟踪源就绪状态，但从不处理权重字节本身。在数据平面上，MX 使用 NIXL 作为默认传输引擎，其可插拔后端可在各种网络（如 Infiniband、RoCE、NVLink、EFA 等）上实现峰值性能。MX 拥有一流的传输接口，允许诸如 fabric-lib
和独立的 Mooncake 等库与 MX 集成。
图 2. 通过 NIXL 进行点对点 GPUDirect RDMA 权重传输
在任何传输开始之前，MX 会根据决定张量布局的模型和运行时设置计算一个 mx_source_id
，然后仅考虑具有匹配 ID 的对等节点。控制平面通过 Redis、Kubernetes CRD 或 k8s-service
（无服务器）元数据后端发现这些对等节点。
优化 NIXL 内存注册开销
在 NIXL 能够通过 RDMA 传输张量之前，必须注册支持它的 GPU 内存：即调用 ibv_reg_mr
，返回用于远程访问的远程密钥（rkey）。大型模型有数万个张量，逐个注册它们慢到足以在预算中显现。默认情况下，MX 单独注册每个张量。两种可选策略可降低注册成本：
池注册为每个底层 cudaMalloc
分配注册一次，而不是为每个张量注册，在典型模型上将注册数量减少 80% 到 99%，且不改变传输语义。VMM 竞技场注册更进一步。它安装一个 CUDAPluggableAllocator
，将每个加载时分配路由到单个 16 TiB 虚拟地址竞技场，然后在加载结束时将整个已使用范围注册为一个由 dmabuf 支持的内存区域。注册从每个张量一次调用坍缩为总共一次调用；每个张量描述符只需携带该单一区域中的偏移量。
在 vLLM 引擎上使用 DeepSeek-V4-Pro TP=8，如下图 3 所示，我们测量了每种方法的平均 NIXL 注册时间。
图 3. NIXL 内存注册优化
运行时路径选择与安全回退
启动时，MX 会探测可用的能力，自动跳过环境不支持的路径。第一个适用的策略按当前优先级顺序运行：P2P RDMA -> ModelStreamer -> GDS -> 默认加载器（主机暂存的 POSIX I/O）
。如果某条路径不可用，或在修改模型状态之前失败，MX 会自动回退。如果失败发生在权重已开始落地之后，它会在继续之前重新初始化模型，因此部分写入的权重永远不会被提供。
P2P 仅在传输开始前发生元数据失败时重试备用对等节点，原生加载器仍是最终回退方案。这种能力驱动的设计使 MX 核心与硬件和软件无关，仅在支持的地方启用平台特定的快速路径。
端到端结果
我们在配备 NVIDIA ConnectX-7 网卡的 8xB200 GPU 节点上运行了 DeepSeek-V4-Pro，并比较了不同冷启动场景下的总模型加载时间。每个副本使用 vLLM 0.23.0，TP=8，并启用 --enable-flashinfer-autotune
。见下方图 4。
图 4. 端到端冷启动模型加载时间比较：HF vs ModelStreamer (S3) vs Disk vs P2P RDMA
预热，而不仅仅是加载：继承已编译的内核
将权重加载到 GPU 内存中至关重要，但已加载的模型尚未准备好提供服务。在其首次前向传播期间，引擎会针对确切的模型、数据类型、量化和 GPU 进行 JIT 编译和自动调优内核（例如 torch.compile、Triton、DeepGEMM、TileLang 等），并捕获 CUDA 图。对于 DeepSeek-V4 Pro 等模型，这可能需要几分钟，并且一旦 MX 降低了权重加载延迟，它可能成为主要的启动成本（见下方图 5）。
图 5. DeepSeek-V4 Pro 的启动时间分解（TP=8 vLLM）
这种重复的预热是可以避免的。当模型、软件栈和 GPU 架构匹配时，一个副本可以承担编译成本，其余副本可以继承生成的缓存。
MX 的 Artifact Transfer API 打包这些基于文件的产物，通过 NIXL 的 CPU 到 CPU RDMA 路径在注册的主机内存缓冲区之间直接传输它们，然后验证并将它们安装到目标引擎的缓存目录中。这消除了 Kubernetes 中对共享 ReadWriteMany (RWX) 卷的需求，而特定于产物的 mx_source_id
可防止在不兼容的副本之间重用。当配置了 Redis 或 Kubernetes 元数据后端时，MX 会自动检测标准缓存位置。
我们使用相同的设置运行，以测量内核产物传输可以减少多少启动时间。启用产物的运行传输了 Triton/DeepGEMM/TileLang/CuTe DSL/FlashInfer 缓存。该图表比较了主要启动阶段以及从进程启动到 API 就绪的总挂钟时间。
图 6. 使用 ModelExpress 减少的总启动时间
当权重每一步都变化时：RL 后训练
到目前为止，一切都假设模型权重在加载后是固定的。RL 后训练打破了这一假设。训练器每一步都会更新策略，而生成 rollout 的推理 actor 必须在下一轮生成之前获取这些权重。与推理启动一样，权重移动在 RL 中处于关键路径上：rollout worker 会等待，直到更新后的权重从训练器的分布式布局（无论是 FSDP/DTensor 分片，还是 Megatron TP、PP 和 EP 分区）移动到推理引擎的布局中。
图 7. ModelExpress 使 RL refit 变为接收方驱动
MX 通过以下四个阶段驱动 refit：
发布：每个训练器 rank 通告其已拥有的张量或分片，以及描述其形状、dtype、放置位置和到 MX 的参数映射的元数据。发现：rollout worker 通过 MX 查找所请求的权重版本及其可用来源。规划：接收方将已发布的所有权信息映射到自己的目标布局上，并确定哪些来源包含所需的张量或范围。拉取、转换和加载：接收方直接对这些来源发起单边读取。
MX 包含接收方驱动 refit 的核心构建块，客户正在积极的集成中评估它们。我们还在测试用于跨集群权重传输的增量权重差异 refit，这是 Fireworks/Cursor、Cognition 等在近期 RL 运行中使用的技术。
为 Dynamo 做贡献以及我们的路线图
MX 与 vLLM 和 SGLang 原生集成，并支持包括 Dynamo 和 llm-d 在内的服务框架。
Dynamo 开源社区正在积极致力于更深入的 TensorRT-LLM 集成和更广泛的推理能力。探索当前的 Dynamo 文档和路线图，在您自己的环境中尝试可用的工作流，并贡献反馈以帮助塑造项目的方向。
致谢ModelExpress 是团队努力的成果。感谢 MX 团队的其他成员 Zhongdongming Dai 和 Tanushriya Singh 在该项目上的核心工作。我们感谢 Itay Neeman、Anish Maddipoti、Istvan Haller 和 Omri Kahalon 对项目技术方向的指导，以及 Red Hat 的 Will Eaton 对 llm-d 集成的支持。