vLLM-Omni 实战基于分布式逐层卸载DLO在 RTX 5090 上部署 MiniMax-H3 视频音频生成服务【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni本篇技术指南以 vllm-omni 仓库中的 MiniMax-H3-5090 部署配方 为核心系统讲解如何在一张或两张 RTX 509032 GiB HBM上以**内存优先memory-first的思路承载 MiniMax H3 这一联合视频/音频扩散模型采用 BF16 权重、tiled VAE 解码、可选的张量并行TP以及关键的分布式逐层卸载Distributed Layerwise OffloadDLO**机制把 270 GiB 级别的双分区检查点压进消费级 GPU 的显存预算内。读完本文你将掌握 1344×768、5 秒、50 步采样在单卡/双卡 RTX 5090 上的可运行服务命令、DLO 参数的内存语义以及验证部署正确性的实测依据。配方概览面向 32 GiB 消费级 GPU 的内存优先方案MiniMax H3 是 CFG-distilled 的联合视频/音频扩散 Transformer其检查点包含两个任务专用 DiT 分区FL2VA承载 text-to-videoaudiot2va与 first-frame-to-videoaudiofl2va任务Ref2VA承载最多 9 张图片、3 段视频、3 段音频参考输入的ref2va任务纯音频输入会被拒绝。每个分区约含134 GiB的 BF16 safetensors磁盘上约135 GiB两个分区同时落地需要约270 GiB的模型存储空间。这意味着模型权重体量远超 RTX 5090 的 32 GiB 显存因此 5090 配方整体设计为内存优先降低常驻resident权重的数量以压缩 HBM 占用代价是增加 CPU 到 GPU 的传输时间。换言之这是容量路径capacity path而非延迟路径其目标是让请求在消费级硬件上跑得起来且结果正确。容量需求显存、系统内存与检查点存储三者分开规划配方要求把 GPU HBM、主机 RAM 与检查点存储当作三个相互独立的资源维度来规划资源单张 RTX 5090两张 RTX 5090GPU HBM32 GiB每卡 32 GiB检查点存储每分区 135 GiB每分区 135 GiB可用系统 RAM最低 200 GiB最低 200 GiB推荐系统 RAM384 GiB384 GiB两点必须牢记的约束FL2VA与Ref2VA是两个独立的 135 GiB 检查点分区应一次只启动一个服务。配方推荐用--task-type fl2va或--task-type ref2va只下载并加载所选分区以保持单分区行为。DLO 会把 rank 本地的权重保存在固定pinned主机内存中在当前实现下增大--dlo-resident-layers会改善延迟但不会减少主机 RAM 占用——因为常驻层仍然保留着固定内存中的 CPU 主副本。所以 200 GiB 是最低可用内存、384 GiB 是推荐配置且不应在一个按最低内存规划的主机上同时运行 FL2VA 与 Ref2VA 两个服务。Modular H3 说明当仓库合入后续的 Modular 改造文档中记为 #5720后配方希望用--task-type fl2va或--task-type ref2va保持当前的单分区行为。在当前版本中组合服务会同时下载两个分区而--task-type只下载所选分区。单张 RTX 50901344×768、5 秒的容量路径单卡方案的关键参数是12 个常驻 DiT 层resident layers。配方给出的参考数据点一个 50 步的 B300 分配测试在完全相同的单 rank 拓扑下峰值约26.50 GiB——因此在目标卡上提高常驻层数之前务必先在目标卡上重新测量峰值 HBM。CUDA_VISIBLE_DEVICES0 vllm serve /path/to/MiniMax-H3/FL2VA \ --omni --trust-remote-code --host 0.0.0.0 --port 8000 \ --num-gpus 1 --tensor-parallel-size 1 --text-encoder-tp-size 1 \ --usp 1 --ring 1 --vae-patch-parallel-size 1 \ --vae-parallel-mode tile --vae-use-tiling \ --enable-distributed-layerwise-offload --dlo-no-use-allgather \ --dlo-resident-layers 12 --enforce-eager \ --diffusion-attention-backend CUDNN_ATTN命令要点逐项拆解--omni启用 vLLM-Omni 的多模态一体化服务路径--trust-remote-code允许执行仓库远端代码H3 检查点需要。--num-gpus 1 --tensor-parallel-size 1 --text-encoder-tp-size 1单 rank 拓扑文本编码器不做 TP。--usp 1 --ring 1 --vae-patch-parallel-size 1Ulysses 序列并行度、Ring 并行度、VAE patch 并行度均为 1。--vae-parallel-mode tile --vae-use-tiling启用 H3 VAE 原生的 tiled 解码。注意 H3 VAE 只支持tile模式不支持spatial_shard_height/spatial_shard_width。--enable-distributed-layerwise-offload开启 DLO。--dlo-no-use-allgather关闭 AllGather 权重重建详见下文 DLO 原理。--dlo-resident-layers 12前 12 个 DiT 块常驻显存、跨采样步复用其余块按需从主机流式传输。--enforce-eager消费级路径显式选择 eager 执行规避未经验证的编译路径。--diffusion-attention-backend CUDNN_ATTN消费级 RTX 路径显式选用 cuDNN attention无需 FlashAttention-4。两张 RTX 5090TP2 20 个常驻层的双卡方案双卡方案使用TP2 与 20 个常驻 DiT 层。配方的参考数据两 rank 的 B300 容量测试在 1344×768、50 步时每 rank 峰值27,726 MiB。文档明确强调这是内存/正确性代理数据memory/correctness proxy不是消费级 GPU 的延迟承诺。CUDA_VISIBLE_DEVICES0,1 vllm serve /path/to/MiniMax-H3/FL2VA \ --omni --trust-remote-code --host 0.0.0.0 --port 8000 \ --num-gpus 2 --tensor-parallel-size 2 --text-encoder-tp-size 2 \ --usp 1 --ring 1 --vae-patch-parallel-size 2 \ --vae-parallel-mode tile --vae-use-tiling \ --enable-distributed-layerwise-offload --dlo-no-use-allgather \ --dlo-resident-layers 20 --enforce-eager \ --diffusion-attention-backend CUDNN_ATTN这条拓扑把所有可用的并行能力都用上了TP2 同时切分 DiT 与 Qwen3-VL 文本编码器--dlo-no-use-allgather让每个 rank 流式传输自己局部的 TP 分片无需重建完整权重块VAE patch 并行度 2把 tiled 解码拆分到两张卡上。值得强调的语义常驻层数量只改变权重放置与传输频率不改变计算精度——它不会做量化也不会改动 BF16/FP32 的去噪数学。在换用不同请求形状之前应重新测量峰值内存再决定是否提高常驻层数。切换 Ref2VA 分区停止 FL2VA 服务用同样的命令把模型路径改为/path/to/MiniMax-H3/Ref2VA重新启动即可。Ref2VA 的参考视频数量与提示词长度会增加激活内存建议开始时一次只提交一个请求。DLO 原理rank-local 传输为何能省显存从源码看DLO 的参数定义与校验逻辑位于 arg_utils.py 与 offloader/config.pydlo_use_allgather: bool True、dlo_resident_layers: int 0、vae_use_tiling: bool False、vae_parallel_mode: str tile是引擎参数层的字段定义CLI 侧--dlo-no-use-allgather的语义在 serve.py 中写得很清楚关闭 AllGather 后每个 rank 直接流式传输标准加载器产出的 rank 本地张量包括已有的 TP 分片仅走 H2D 拷贝——没有额外的 DP 切分、没有 AllGather、也没有并发请求的同步要求。配置解析层resolve_offload()还会做一致性校验dlo_resident_layers必须是非负整数dlo_resident_layers要求 DiT 的 DLO 传输方式为 rank-local即必须配合--dlo-no-use-allgather否则直接报错dlo_resident_layers requires the DiT DLO transfer to be rank-local; set dlo_use_allgatherFalseresident_layers目前只支持dit组件resident_layers currently supports only the dit component若同时使用--diffusion-offload-config与新式配置则不能再叠加dlo_use_allgather/dlo_resident_layers等兼容性旧选项。这套约束解释了 5090 配方为什么必须成对出现--enable-distributed-layerwise-offload --dlo-no-use-allgather --dlo-resident-layers N常驻层语义建立在 rank-local 流式传输之上。从双卡执行路径看DLO 与标准加载器的配合是标准加载器先创建 rank 局部的 TP 分片DLO 把该分片保留在固定主机内存中尾部 DiT 块通过共享的双缓冲窗口流式进入 GPU前 20 个 DiT 块在每个去噪阶段只拷贝一次、被所有采样步复用并在 VAE 解码前释放以便解码器复用其 HBM。这也是为什么增大 resident 层数不省主机内存——固定内存中的 CPU 主副本始终存在。与 RTX 4090 配置的对照与目标硬件验证主配方文档MiniMax-H3.md给出了两个消费级配置文件的对照表ProfileGPU起始形状常驻 DiT 块注意力执行状态rtx50902 × 32 GB1344×76820cuDNN attentioneager目标硬件已验证rtx40902 × 24 GB1024×57612cuDNN attentioneager容量代理起点在 vLLM-Omni commitae6577ea上一次完整的 50 步 T2VA 请求在 2 × RTX 5090 上无 OOM 完成形状帧数客户端端到端采样峰值/卡输出校验1344×768124 24 FPS8 分 38 秒约 22.6 GiBH.264 视频 32 kHz 立体声 AACffmpeg全量解码通过需要说明的边界这是一次端到端验证不是多轮预热后的延迟基准采样峰值来自nvidia-smi采样也不是 CUDA 分配器的高水位标记。验证环境为 vLLM 0.26.0、vLLM-Omni0.26.1.dev14gae6577ea、PyTorch 2.11.0cu130。在正式跑目标卡之前两个 profile 都在两 rank B300 上做过分配与正确性代理1344×768、124 帧、50 步时 20 层 profile 每 rank 峰值 27,726 MiB1024×576 时 12 层 profile 在 5 步容量测试中每 rank 峰值 18,888 MiB。常驻与全流式两种放置方式对相同形状、步数、提示词与种子产生了完全一致的解码视频帧与音频哈希——这从正确性角度印证了 DLO 传输不改变去噪数值结果。B300 结果不能推导 RTX 4090 PCIe 的延迟表现4090 profile 在实测之前应视为保守起点。仓库还提供了可复现的端到端脚本 run_h3_2gpu_all_tasks.sh它依次运行 T2VA、FL2VA、imageaudio Ref2VA 与双视频 Ref2VA校验每个 MP4 的 H.264/AAC 流并保留服务端与 GPU 内存日志。脚本对PROFILErtx5090选择 20 个常驻层、PROFILErtx4090选择 12 个DLO_RESIDENT_LAYERSN可覆盖默认值RUN_ROOT/path/to/run-root \ MODEL_ROOT/path/to/MiniMax-H3 \ GPU_IDS0,1 \ PROFILErtx5090 \ bash examples/offline_inference/minimax_h3/run_h3_2gpu_all_tasks.sh服务与调用以/v1/videos完成文本到视频音频生成5090 配方启动的即 OpenAI 兼容的/v1/videosHTTP 服务。以 T2VA 任务为例通过同步端点/v1/videos/sync可以直接把响应体保存为 MP4。所有任务统一使用 24 FPS、50 个 sigma 点视频/音频 flow shift 分别取 12 与 3小数时长经extra_params传递export API_URLhttp://127.0.0.1:8000/v1/videos/sync curl -sS -X POST ${API_URL} \ -F promptA quiet cinematic night scene with matching ambient sound. \ -F width1344 \ -F height768 \ -F aspect_ratio16:9 \ -F fps24 \ -F num_inference_steps50 \ -F flow_shift12 \ -F seed1101 \ -F extra_params{task:t2va,duration:5.0,audio_flow_shift:3.0} \ -o t2va.mp4请求通过extra_params.task选择任务专用 DiTt2va/fl2va路由到FL2VA/transformerref2va路由到Ref2VA/transformer。输出契约固定为 4–15 秒、24 FPS、立体声 32 kHz 音频、32 像素画布倍数。H3 是 CFG-distilled 模型因此--cfg-parallel-size必须保持为 1。需要强调的是以上是配方主题RTX 5090 部署下的最小调用示例完整的 T2VA / FL2VA / Ref2VA 请求矩阵、参考输入约束与官方输入矩阵可查阅 MiniMax-H3 主配方文档 与 视频 API 文档。部署清单与注意事项总结在 RTX 5090 上落地本配方的完整检查清单环境准备从包含 MiniMax H3 支持的 vLLM-Omni 检出安装uv pip install -e .RTX 5090/4090 消费级 profile 使用 cuDNN attention无需FlashAttention-4。ffmpeg与ffprobe必须在PATH上用于参考视频处理与 MP4 输出。资源规划单分区 135 GiB 检查点存储、每卡 32 GiB HBM 预算、200 GiB 最低/384 GiB 推荐系统 RAM三者在同一台主机上不要同时跑 FL2VA 与 Ref2VA 服务。分区选择先--task-type fl2va跑 FL2VA需要 Ref2VA 时停掉服务、换路径重启。参数组合--enable-distributed-layerwise-offload必须与--dlo-no-use-allgather、--dlo-resident-layers N搭配单卡取 12、双卡取 20改动前务必在目标卡上重测峰值 HBM。注意力后端消费级路径固定--diffusion-attention-backend CUDNN_ATTN并保持--enforce-eager。验证口径以无 OOM 完成 ffprobe报告 H.264 视频与 32 kHz 立体声 AAC作为通过标准记录实测峰值而非假定标称值。本配方定位清晰它是一份消费级硬件的容量与正确性部署方案不是吞吐或延迟基准。若需要吞吐导向的部署无卸载、四卡、Ulysses 序列并行、tiled VAE patch 并行、区域torch.compile与稠密TRTLLM_ATTN或想了解更完整的 API 用法可继续阅读 MiniMax-H3 主配方、支持模型列表 与 Diffusion 并行总览。【免费下载链接】vllm-omniA framework for efficient model inference with omni-modality models项目地址: https://gitcode.com/GitHub_Trending/vl/vllm-omni创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考