AREX Feed Article
vLLM-Omni 发布分布式逐层卸载：124GB 的 Cosmos3-Super 视频模型跨多卡运行
8 月 17 日，vLLM-Omni 团队在发布分布式逐层卸载（Distributed Layerwise Offload，DLO）：权重超过单卡 HBM 容量的视频生成模型，现在可以跨多张 NVIDIA GPU 或 Ascend NPU 运行，每张卡同一时刻只在 HBM 里保留两层权重。新功能随 vLLM-Omni v0.27.0rc1 提供，需要搭配 vLLM 0.27.0。
博客给出的两个实测数字是这次发布的核心。Cosmos3-Nano（33 GB）在 DP4 配置下冷启动，cgroup 可见峰值内存从 178 GB 降到 47 GB，降幅 73%；DP 多并发把吞吐从单请求 HSDP 基线的 0.967 帧/秒提到 3.22 帧/秒，约 3.3 倍。而 124 GB（BF16）的 Cosmos3-Super 64B 模型，此前放不进任何一张 64 GB HBM 的设备。
塞不下的 124GB：三种现成方案各有短板
Cosmos3-Super 有 64B 参数、BF16 权重 124 GB，单张 64 GB HBM 卡装不下。博客对比了三条现成路线：HSDP（FSDP2）把权重摊到各卡，但 Super 在 4 卡上每卡要吃掉约 56 GB（权重加激活与通信缓冲），只剩 8 GB 余量；纯 DP 的逐层卸载把完整模型复制进每张卡的主机内存，4 张卡就是 4×124 GB＝496 GB，超过多数服务器的内存；张量并行（TP）不占主机内存，通信开销却随规模上升。
加载期的内存更糟。旧路径下每个 rank 各自调用 param.data.copy_(loaded_weight)，在 RSS 里生成 dp_size 份完整私有拷贝，峰值 RSS 按 O(dp_size × model_size) 增长。按博客的推算，200B 模型配 dp_size=4 时 RSS 会到 2 TB。
四项技术合起来：每卡只留两层权重
DLO 用四项技术分别解决 HBM 与主机内存两个瓶颈。
第一，meta 设备初始化加 mmap 权重加载。已创建的 DiT 模块先用 to_empty(device="meta") 转成 meta 设备、释放参数存储，再把参数替换成指向操作系统 page cache 的 mmap 视图。所有 rank mmap 同一批 safetensors 文件，OS 对每个文件页只保留一份。178 GB 的基线里，132 GB 是四份私有模型拷贝，33 GB 是共享 page cache，约 13 GB 是框架与瞬时开销；换用 mmap 后冷启动峰值降到 47 GB。
第二，权重分片加 AllGather 重建。每个 rank 只存 1/dp_size 的权重，运行时用 all_gather_into_tensor 在专用通信流上重建完整层。pinned 内存总量从 dp_size × model_size 降到 model_size：Cosmos3-Super DP4 从 4×124 GB 变成 124 GB，每 rank 31 GB。
第三，固定双缓冲预取。每张卡同时只有两个权重缓冲槽，按模型最大 block 尺寸分配，与层数无关；计算流跑第 N 层时，后台流并行准备第 N+1 层（H2D 拷贝加 AllGather，事件同步）。HBM 里任意时刻只放约 2 GB（Nano）或约 3 GB（Super）权重。720p 10 秒负载下从 Nano 换到 Super，模型大了 3.8 倍，峰值 HBM 只从 23.1 GB 涨到 28.1 GB（约 22%），而 HSDP+SP 在 Super 上要 56.3 GB。
第四，DP 多并发。AllGather 只交换权重分片、与请求内容无关，调度器于是把最多 dp_size 个请求打包进一次广播 RPC，每个 DP rank 各算一个请求。4 个并发请求把固定 AllGather 开销（约 150 ms/步）摊薄 4 倍，吞吐达到理想 4× 缩放的约 83%。
实测：输出逐字节一致，内存曲线换了个形状
博客在两条硬件路上做了验证。Ascend 910B3（单卡 64 GB HBM、2 TB 系统内存）上，Cosmos3-Nano 与 Cosmos3-Super 的 DP2/DP4 各配置全部产出正确视频，HTTP 请求全部 200，29 帧输出完整。Super 的每卡空闲 HBM 只有约 10–15 GB，64 GB 的卡留出约 49–54 GB 余量。cgroup 可见主机内存按 O(model_size + dp_size × 常数) 增长，而不是 O(dp_size × model_size)。博客还发现，Ascend 上 pin_memory() 经由 /dev/davinci_manager 分配 DMA 内存，落在 CPU 内核空间，cgroup 看不见。Nano DP2 的实测 cgroup 用量 49 GB 与 cache 31 GB 加 rss 18 GB 精确吻合，但服务器物理 RAM 依旧要付这笔账。
NVIDIA 侧用 4 张 B300 SXM6 跑 Cosmos3-Super。1024×1024 T2I、50 步下，DLO+AllGather DP4（4 并发）吞吐 0.0915 outputs/s，是 HSDP+USP4（0.0658）的 1.39 倍，单卡峰值 HBM 12.62 GiB，只有 HSDP 的 42.00 GiB 的三成。所有策略在相同 seed 下输出 SHA256 完全一致；720p 10 秒负载下 DLO+AG+USP4 用时 214.53 秒，距 HSDP 的 210.05 秒差 2.13%，HBM 只用了对方的 47%。
MiniMax-H3 拓扑测量：DLO 模式没有全局最优解
博客还附了 Shunyang Li 在单台 8×B300 SXM6 上对 MiniMax-H3（768×1344、124 帧视频加立体声音频、50 步）的拓扑策略研究，测试三个路由。DP1×SP8 配 AllGather 延迟最低：P50 34.55 秒，103.84 videos/h；DP4×SP2 配 AllGather 是平衡点：94.73 秒，151.89 videos/h；DP8×SP1 改用 rank-local（不做 AllGather）吞吐最高：183.78 videos/h，每段视频 43.97 Wh（八卡板卡功耗合计，未减空闲基线）。
AllGather 的收益随拓扑快速衰减：在 DP1×SP8 下把吞吐提高 129.4%、P50 降低 56.6%；到 DP4×SP2 收益只剩 2.2%；到 DP8×SP1 反而把吞吐拉低 4.1%、单卡峰值从 20.03 GiB 抬到 94.03 GiB。博客特意标注这是拓扑研究而非普适生产结论：DP2×SP4 没有测，测试用的 vLLM 0.24.0 与 vLLM-Omni 0.26.0rc2.dev11 快照加本地 patch，与发布版本并不对齐。
版本门槛与 200B+ 的边界：推算能装下，还没人跑过
DLO 的入口是两条命令：--enable-distributed-layerwise-offload 加 --data-parallel-size，Nano 用 DP4、Super 用 DP2 即可，--dlo-no-use-allgather 可关掉权重分片。版本有门槛：v0.26.0 上 Cosmos3 的 DLO+DP 路径会拒绝所有请求，因为引擎要求 pipeline 声明 supports_request_batch=True（#5953）；#5864 绕开这一要求，修复了 DLO+AllGather+DP 路径，而不启用 AllGather 模式的独立请求分发（#5911）至今仍开着。
博客标题里的「迈向 200B+」目前只是推算。基于实测内存模型的外推显示，400 GB 模型配 dp_size=4 需要约 423 GB cgroup 可见内存加约 400 GB 内核 DMA，合计约 823 GB，2 TB 服务器放得下，而不用 mmap 的老路径要 2000 GB。博客写明：没有真的跑过 200B 级模型，最大 block 尺寸、HBM 余量、带宽、延迟与输出质量在这个规模均未验证。