每移动一个字节都会产生一定的成本。随着模型检查点数量增长到数百 GB 甚至一 TB，这一成本会迅速增加。更糟糕的是，在集群中移动这些模型权重非常常见。例如，冷启动可能会将权重从远程存储提取到 GPU 显存中；自动扩展和滚动更新必须填充每个新副本；而 RL 后训练会不断从训练器中移动更新的权重，以推出工作者。这些工作流程可能看起来不同，但却产生了相同的重复性负担：在有用的工作开始之前，需要花费时间移动权重。
ModelExpress：加速模型权重生命周期
NVIDIA ModelExpress (MX) 的构建理念非常简单：在加载模型之前，首先要询问其权重的兼容副本已位于何处。MX 没有将每个副本视为独立的冷启动，而是选择最快的可用源和传输路径。
当服务点已在 GPU 中拥有兼容的权重时，MX 会通过 NVIDIA 推理 Xfer 库 (NIXL) 将其通过 P2P RDMA 直接从 GPU 传输到 GPU，从而绕过对对象存储、本地磁盘和主机内存的冗余访问。当没有对等设备可用时，MX 会从对象存储中进行流式传输，从而从支持的最快路径进行引导，而无需登陆磁盘或直接将本地文件读取到 GPU 显存中。
MX 可在 10 秒内将 DeepSeek-V4 Pro 权重和 JIT 内核缓存伪影从服务副本传输到新副本，将总启动时间从 8 分钟缩短到 1 分 44 秒。本文其余部分介绍了 MX 如何选择通往 GPU 显存的最快可用路径，优先从服务副本中选择 P2P RDMA，并在此过程中消除冗余下载和复制。然后，它扩展了重复使用内核缓存和分发 RL 权重更新的相同方法。
加速从远程存储到 GPU 显存的每个阶段
每位新工作人员必须从以下三个位置之一获取其权重：远程存储 (例如。HF 或 S3) 、本地存储或其他已在为模型服务的工作者。对于第一个工作进程，还没有对等节点，因此它必须从存储中启动。MX 可以从对象存储中串流检查点，或从快速本地存储中加载检查点，从而删除任何路径上可避免的副本。
当第一个 worker 开始服务后，首选源会发生变化。其权重已经驻留、后处理并在 GPU 显存中进行了布局，因此之后的每个兼容工作节点都应通过 P2P RDMA 直接从该对等节点加载。MX 会自动进行这种过渡：从存储中启动一次，然后将 GPU 横向扩展到 GPU，仅在没有兼容对等可用时才回退到存储。
启动第一个工作进程：从存储中启动
GPU 的远程对象存储：避免使用本地磁盘
当检查点位于云桶中，而您不想调配和管理磁盘缓存层时，MX 会使用 Model Streamer 通过可重复使用的 CPU 暂存缓冲区将安全传感器拉入 GPU。Checkpoint 永远不会登陆本地磁盘，从而省去了中间的下载、重新加载和存储卷。
Model Streamer 使用多线程张量读取器在检查点分片中同时获取张量范围。当张量到达时，它会通过 GPU 放置来进行远程读取：完成的张量会传递给推理引擎，而稍后的张量仍在提取中。这样会使存储、网络和 GPU 复制路径保持繁忙状态，同时重复使用有限数量的主机内存。
在张量并行部署中，参与的秩通常通过 NCCL 划分远程读取并共享结果，而不是让每个秩单独下载完整的检查点。MX 将此分布式流直接连接到推理引擎的权重加载器，使第一个工作者做好准备，成为后续每个兼容副本的 P2P 来源。
集群入口：下载一次，而非 N 次
当集群维护共享磁盘缓存层 (例如。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 加载本地检查点。多个操作系统线程同时将安全传感器读取到可配置的 CPU 缓冲区中，而完成的张量则转移到 GPU，之后的读取将继续并行进行。与 GDS 不同，此路径仍会分阶段通过主机内存，但会将磁盘 I/ O 与 GPU 放置重叠，并受益于操作系统页面缓存，并且在无法直接访问存储到 GPU 时提供可移植的快速路径。
在第一个工作节点之后启动每个工作节点：从服务节点获取
这是 MX 的主要功能。当另一个副本已经为同一模型提供服务时，权重便已完成大部分工作：它们驻留在 GPU 显存中，经过后处理，并为推理引擎进行布局。MX 将该副本视为实时权重来源。确认兼容性后，它会将张量直接从源 GPU 传输到目标 GPU。加载权重后，新副本将加入源池，从而为后续副本提供另一个加载对等节点。每一次成功的迁移，该池都会随着部署而增长，从而将横向扩展转变为 GPU 到 GPU 的扇出，而不是重复的冷加载。
MX 控制平面会发现兼容的节点、交换传输元数据并跟踪源就绪情况，但绝不会自行处理权重字节。在数据平面上，MX 使用 NIXL 作为默认传输引擎，其可插拔后端允许在 InfiniBand、RoCE、NVLink、EFA 等各种网络中实现峰值性能。MX 具有一流的传输接口，可支持 fabric-lib 和独立 Mooncake 等库与 MX 集成。
在任何传输开始之前，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 支持的内存区域。注册从每个张量的一次调用折叠为总计一次调用；每个张量描述符只需将偏移量带入该单个区域。
如下图 3 所示，我们在 vLLM 引擎上使用 DeepSeek-V4-Pro TP = 8 测量了每种方法的平均 NIXL 注册时间。
运行时路径选择和安全后备
在启动时，MX 会探测可用的功能，自动跳过环境不支持的任何路径。第一种适用策略按当前优先级顺序运行：P2P RDMA -> ModelStreamer -> GDS -> default loader (host-staged POSIX I/O)。如果在修改模型状态之前路径不可用或失败，MX 会自动掉线。如果在权重开始着陆后发生故障，它会在继续之前重新初始化模型，因此永远不会提供部分写入的权重。
在传输开始之前，P2P 仅会针对元数据故障重试备用节点，而原生加载程序仍是最终的后备程序。这种功能驱动型设计使 MX 核心硬件和软件不受影响，仅在支持的情况下启用特定于平台的快速路径。
端到端结果
我们在搭载 NVIDIA ConnectX-7 网卡的 8xB200 GPU 节点上运行 DeepSeek-V4-Pro，并比较了不同冷启动场景下的模型加载总时间。每个副本都使用 vLLM 0.23.0，TP = 8 和 --enable-flashinfer-autotune。请参见下图 4.
温暖而不仅仅是加载：继承编译的内核
将权重输入 GPU 显存至关重要，但加载的模型尚未做好服务准备。在首次前向传递期间，引擎 JIT 会编译并自动调整内核 (例如。torch.compile、Triton、DeepGEMM、TileLang 等)并捕获确切模型、数据类型、量化和 GPU 的 CUDA 计算图。对于 DeepSeek-V4 Pro 等模型，这可能需要几分钟的时间，并且一旦 MX 降低了权重加载延迟，这可能会成为主要的启动成本 (请参见下面的图 5) 。
这种重复的热身是可以避免的。当模型、软件堆栈和 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 准备就绪的总总时间。
当权重改变每个步骤时：RL 后训练
到目前为止，所有内容都假定模型的权重在加载后是固定的。RL 后训练打破了这一假设。训练器会在每一步更新策略，而生成部署结果的推理行为者必须在下一轮生成之前获取这些权重。与推理初创公司一样，权重移动也是 RL 的关键路径：部署工作者等待，而更新的权重从训练器的分布式布局 (无论是 FSDP/ DTensor 分片还是 Megatron TP、PP 和 EP 分区) 移动到推理引擎的布局。
MX 通过以下四个阶段推动改装：
- 发布：每个训练器等级都会公布其已拥有的张量或分片，以及描述其形状、dtype、位置和参数映射到 MX 的元数据。
- 发现：发布人员通过 MX 查找请求的权重版本及其可用来源。
- 计划：接收器将已发布的所有权信息映射到自己的目标布局上，并识别包含所需张量或范围的来源。
- 拉取、转换和加载：接收器直接针对这些源发出单向读取。
MX 包含用于接收机驱动改装的核心构建模块，客户正在主动集成中对其进行评估。我们还在测试用于跨集群权重迁移的增量权重差异调整，这是 Fireworks/ Cursor、Cognition 等公司在近期 RL 运行中使用的技术。
为 Dynamo 和我们的路线图做出贡献
MX 与 vLLM 和 SGLang 进行了原生集成，并支持包括 Dynamo 和 llm-d 在内的服务框架。
Dynamo 开源社区正积极致力于更深层次的 TensorRT-LLM 集成和更广泛的推理功能。探索当前的 Dynamo 文档和 路线图，在您自己的环境中试用可用的工作流，并提供反馈以帮助确定项目方向。
致谢 ModelExpress 是一项团队合作成果。感谢 MX 团队的其他成员戴忠东鸣和 Tanushriya Singh 在项目中的核心工作。我们感谢 Itay Neeman、Anish Maddipoti、Istvan Haller 和 Omri Kaharon 对项目技术方向的指导，并感谢 Red Hat 的 Will Eaton 对 llm-d 集成的支持。
