AREX Feed Article
vLLM-Omni 宣布 Day-0 支持 MiniMax-H3-Image：NVIDIA 与 AMD GPU 双平台可用，VeRL-omni 同步上线强化学习配方
11 月 10 日，vLLM 项目官方 X 账号 @vllm_project 发帖宣布，vLLM-Omni 对 MiniMax 开放权重的图像生成与编辑模型 MiniMax-H3-Image 提供 Day-0 支持，当天即覆盖 NVIDIA 与 AMD 两类加速卡，名单中包括 NVIDIA H200、RTX PRO 6000 Blackwell 和 AMD Instinct MI350X 等（）。这是一个用一套开放权重同时做文生图和参考图编辑的模型：原生输出约 1600 万像素（16MP）图像，vLLM-Omni 发布配方中单次请求最多接受 9 张参考图，提示词上限 4,096 token，并支持密集文字渲染。官方同步给出 Docker 镜像 vllm/vllm-omni:minimax-h3-image。
帖文给出的延迟数字：4× NVIDIA H200（SP 4、文本编码器 TP 4）上 2048×2048 文生图 0.88 秒、单参考图编辑 1.35 秒；4× NVIDIA B300 分别为 0.63 秒和 0.85 秒；4× RTX PRO 6000 约为 1.6 秒和 2.5 秒。同一帖文还宣布 VeRL-omni 提供 Day-0 强化学习支持：用 DiffusionNFT 训练 LoRA（低秩适配），训练侧用 FSDP2（全分片数据并行）、采样生成（rollout）用 vLLM-Omni，配方已提交为 verl-project/verl-omni 的 PR #890。这些性能与延迟数字均为 vLLM 项目帖文单方口径，未经独立核实。
一个检查点同时管生成与编辑：331 亿参数 DiT、6 步蒸馏、约 16MP 画布
MiniMax-H3-Image 来自 MiniMax 的 H3 家族。家族里先开源的 H3 是接收文本、图像、视频、音频参考输入的视频加音频联合生成模型，vLLM-Omni 今年 9 月已对那套视频栈做过系统级优化，在 8× B300 上用 FastVideo 的四步 FastH3 把 10.125 秒的完整 MP4 压到约 8.7 秒生成完毕（）。这次的 H3-Image 把同一架构思路搬到图像上：显示，其扩散 transformer（DiT）就是 H3 架构去掉音频层，331 亿参数（33.1B）、50 层单流结构；文本编码器原封不动沿用 H3 的 Qwen3-VL 编码器（配方页口径 334 亿参数），再配一个 CNN 编码加 2D ViT 解码的图像 VAE（变分自编码器）。
模型卡写明的能力边界：检查点蒸馏到 6 个采样步（6 次网络前向），不需要 classifier-free guidance（无分类器引导）；有效工作区间约 4～20 MP，16 MP 左右效果最好，从 4096×4096（1:1）到 6272×2688（21:9）直接生成、不经超分器。请求参数上，num_inference_steps 只能省略或填 6，guidance_scale 只能省略或填 1，负向提示词直接拒绝，提示词截断到 4,096 token。参考图容量有两层口径：模型卡称模型本身支持最多 16 张参考图，而 vLLM-Omni 发布配方按单请求最多 9 张执行。帖文列举的落地场景从产品图、游戏素材到海报和 UI 设计稿，「保留你想要的细节，改掉你不要的」。
模型卡同日在 Hugging Face 更新，页面顶部拼了 15 张横竖版文生图样张，从 3D 奇幻战斗、青绿山水、树蛙微距、饺子静物到鱼眼自拍，直观展示不同画幅下的输出。
单卡 14.7 GiB 也能跑：H200 档位表与官方延迟口径
按硬件给出部署档位，实测都在 H200 上完成：单卡把文本编码器分层卸载，峰值 73.4 GiB、2048² 文生图 3.2 秒；DiT 和文本编码器都卸载（分层卸载配置 DLO）压到 14.7 GiB、8.3 秒；4 卡 Ulysses 序列并行（SP 4）全驻留 81.3 GiB、0.88 秒；4 卡张量并行（TP 4）只要 36.2 GiB、1.0 秒。整套权重的磁盘规划约 127 GB（DiT 33.1B BF16、Qwen3-VL 文本编码器 33.4B、图像 VAE 0.58B FP32）；全驻留单卡估计要 135 GiB、尚未实测，配方称这是 B200/B300 的自然选择。80 GB 的 H100 得走 DLO 或 TP 4（SP 4 放不下），96 GB 的 RTX PRO 6000 则所有驻留布局都装得下，SP 4 在 PCIe 互联上最快。
延迟的测量口径写在配方页：三次热请求取中位数、并发 1、客户端端到端计时。4× H200（SP 4）下，1024×1024 文生图 0.77 秒、2048×2048 为 0.88 秒、4736×3552 为 3.84 秒、单参考图 2048² 编辑 1.35 秒，帖文引用的 H200 数字与之一致；小于 2048² 的请求会在同比例的至少 2048² 画布上生成、再用 LANCZOS 缩回，直接请求画布尺寸可跳过缩放。配方页注明档位表全部在 H200 上实测，RTX PRO 6000 配方另有自己的实测，其余加速卡按 H200 峰值推算、仅给配置；AMD Instinct MI350X 的支持由帖文与模型卡共同声明。
不改采样器做强化学习：DiffusionNFT LoRA 直接落在 6 步 PDD 采样器上
强化学习部分由 VeRL-omni 承担，配方以 提交，作者是 aoshen02。这份配方不替换模型原生采样器：H3-Image 用 6 个每步独立输出头（PDD fused heads）替换 DiT 的输出层并配 6 步采样调度，PR 里的训练适配器就只对这 6 个采样 sigma 训练、并配对每步对应的头；PR 还附带一个原生权重到 Diffusers 格式的转换器，并新增可选项 VERL_OMNI_FSDP_REPLICATE_FROZEN=1，把冻结底座在每个 rank 上复制、只分片 LoRA 张量，省掉每次前向对底座的 all-gather，默认行为不变。
奖励设计上，帖文把它概括为三项相乘：OCR（光学字符识别）分数、layout guard 和 HPSv2.1 质量门槛；PR 的配方文档给出完整组合——0.5×PickScore + 0.2×(OCR×layout guard) + 0.3×HPSv2.1，学习率 1e-4，LoRA rank 66，512×512 直接画布。
PR 同时解释了 layout guard 存在的原因：去掉它，同一权重只挂纯 OCR 项时，策略会把文字越拉越大直到撑满画布——文字面积从 0.054 涨到 0.175，第 50 步时 20% 的验证图文字触边，而 PickScore 和 HPSv2.1 对此毫无反应。guard 的实现是文字触边即记 0，否则取 min(1, 0.08/文字面积)。
训练结果同样写在 PR 里：GB300 上 3 张训练卡加 1 张打分卡、每步 60～85 秒，跑 50 步（种子 42）；在 64 条留出验证（held-out）的提示词上，奖励之外的第二套 OCR 引擎 PP-OCR 从 0.415 提到 0.719，PickScore 与 HPSv2.1 基本持平。PR 写明的限制：单一种子、只在 512×512 上验证，边缘强度从 18.0 漂移到 16.0，偏好项起的是锚定而非驱动作用。
发布包、依赖与配方写明的边界
这条支持线压在 vLLM-Omni 0.33 上：PR #890 写明配方需要带 MiniMax H3 image 支持的 vLLM-Omni 0.33（此前的 PR #878 已把依赖 pin 升到 v0.33.0）。模型卡在本地部署一节把 SGLang、vLLM-Omni、diffusers、ComfyUI 并列为推荐推理框架，vLLM-Omni 只是其中一条路径；帖文附带视频的标题卡署名 Engineered by Inferact × MiniMax，帖文结尾感谢了 MiniMax 的开源以及 NVIDIA 与 AMD 团队的支持。帖文还提到 vLLM-Omni 侧的配套优化：多 GPU VAE tiling、CUDA Graph replay 和一条更快的图像响应路径。
配方页自己列出的未认证项包括模型 CPU offload、量化与缓存加速，CFG parallel 与 HSDP 并行方式被直接拒绝；RL 配方只验证过单一种子和 512×512 一种画布。