AREX Feed Article
vLLM-Omni 宣布为 MiniMax-H3-Image 增加 NVIDIA Vera Rubin 支持：官方称 4 卡原生 4K 生成 0.87 秒、吞吐 6,115 张图/小时
vLLM 项目 2026 年 11 月 12 日在 与同日发布的中宣布：vLLM-Omni 为 MiniMax 开放权重图像模型 MiniMax-H3-Image 增加 NVIDIA Vera Rubin 平台支持。博客给出的数字是，4 张 Rubin GPU、SP4 序列并行加 MXFP8（8 位浮点格式）的配置下，原生 4096×4096 文生图的中位数延迟 0.866 秒；初步吞吐调优后，另一套配置在 4 卡上达到每小时 6,115 张。以 MiniMax 官方未打折的 Standard 4K 示例单价 0.06879 美元/张、满负荷计费折算，博客算出的毛收入上限是 105.16 美元/GPU·小时。这些性能、吞吐与收入数字均为 vLLM 项目自报的基准结果与测算；截至发稿，未能检索到第三方在同一口径下的独立复测。
帖文同时把支持面列全：NVIDIA 数据中心与 RTX GPU、AMD、Intel、摩尔线程（MUSA）以及华为昇腾 NPU（神经网络处理器），并向 MiniMax 道贺：H3-Image 据 Artificial Analysis 位列开放权重图像编辑模型第一。两天前的 11 月 10 日，vLLM 项目刚宣布 vLLM-Omni 对 H3-Image 的 Day-0 支持，当时覆盖 NVIDIA 与 AMD 两类 GPU，并同步给出 VeRL-omni 强化学习配方；这一轮更新把 Vera Rubin、Intel、摩尔线程与昇腾补进名单。
H3-Image 的 于 11 月 3 日上线：单一 checkpoint（模型权重文件）同时承担文生图与图像编辑，蒸馏到 6 个采样步、不使用 classifier-free guidance（无分类器引导），原生直出约 1600 万像素、不经放大器，图像编辑最多接受 16 张参考图。
Rubin Bringup：一次 MXFP8 内核接入，一处 4K 卡顿修复
博客把这轮 Rubin 移植称作 Rubin Bringup，起点是 vLLM-Omni 已有的 H3-Image 实现和 vLLM 在 中发布的 Rubin 支持，运行时为 CUDA 13.4。这笔负载不小：H3-Image 由 Qwen3-VL 文本编码器、33.1B 参数的稠密 DiT（扩散变换器）和图像 VAE（变分自编码器）组成，一张原生 4096×4096 的图对应 16,384 个目标图像 token、6 个去噪步，之后才轮到 VAE 解码。
团队为此做了两处改动。第一处接内核：把 Omni 的扩散线性层挂到 vLLM 的在线 MXFP8 加载与内核选择上，Rubin 上符合条件的 DiT 线性层走 FlashInfer CuTe-DSL MXFP8 GEMM（矩阵乘内核），注意力用 TRTLLM_ATTN；文本编码器与 VAE 保持各自原生精度。第二处修稳定性：连续 4K 请求会在输出传输路径上停住，团队把最终的图像布局转换挪到 CPU、放在传输解码后的 uint8（8 位无符号整数）张量之后执行，回归测试确认重复请求能完成、解码像素不变。
解码侧还有一层并行优化：VAE 按独立图块出图，图块摊到多张卡上，每张卡再把 CUDA Graph replay 与多条 CUDA stream 组合，前者省去重复启动开销，后者让图块互相重叠。博客给出的 4×GB300 BF16（16 位浮点精度）对照是，VAE 解码从 2.635 秒降到 0.213 秒，端到端从约 4.0 秒缩到 1.6 秒，即博客所称的 2.5 倍加速。
亚秒延迟与峰值吞吐是两个工作点
0.87 秒与 6,115 张/小时不来自同一套配置。延迟档用 SP4，并发 1 时的中位延迟为 0.866 秒、p95（95 分位）为 0.944 秒；同为 4 卡、SP4、MXFP8 的口径下，博客给出的对比是比 GB200 快 2.21 倍、比 GB300 快 1.64 倍。吞吐档换成 4 个单卡副本（SP1×DP4），在并发 8 时达到 6,115 张/小时、中位延迟 4.411 秒；SP4 档在并发 2 是 4,407 张/小时、中位 1.421 秒。博客写明，副本方式比单批多 38.7% 吞吐。
口径边界也写在博客里。0.87 秒的标题数字出自短提示词服务基准：20 条 122～160 字符的提示词乘 8 个种子，每个并发点 160 个请求；跨硬件对比用的咖啡产品提示词长 1,292 字符，在 Rubin 上 4K 平均 1.09 秒。每个计时都包含完整 PNG 响应。博客同时提醒，各平台的 GPU 数量、精度与显存布局不同，这些数字比较的是部署出来的系统，而不是单独衡量 GPU 架构。
同口径跨硬件对照里，4 张 GB300 跑 4K 文生图平均 1.48 秒、带 1 张参考图的 4K 编辑平均 1.77 秒，单张 H200 以 BF16 常驻权重跑 2K 文生图平均 1.49 秒。博客称这组测量覆盖了 10 种 NVIDIA 硬件。
收入测算的公式与边界
博客的收入测算由三层假设叠出来。产量取吞吐档配置的数字，外推成每套 4 卡 Rubin 系统每天 146,755 张，博客注明这是按实测速率外推，并非跑满 24 小时的负载测试。单价取 0.06879 美元/张，按博客说明，这是 中 Standard 4K 文生图（无参考图）的示例价，未计入上线折扣。利用率按满负荷计费算，公式为每小时张数 × 单价 × 计费利用率 ÷ 4 张卡：100% 计费利用率对应 105.16 美元/GPU·小时，75% 对应 78.87 美元/GPU·小时。
博客同时写明，这笔数未扣运营成本，实际托管 API 的计费还会随文本 token 用量浮动。
AMD、Intel、昇腾与摩尔线程：配方与各家自报的数字
支持面这次写全了：消费级与数据中心 GPU 覆盖 NVIDIA、AMD、Intel 与摩尔线程（MUSA），另有华为昇腾 NPU。博客为每家给出实现与配方，数字由各方在自己的工作负载下测得：
- AMD Instinct：配方包含 MI325X 与 MI350X 的文生图与编辑测量，1～8 卡，BF16 加 FLASH_ATTN，覆盖 Ulysses 序列并行与张量并行；ROCm（AMD 的 GPU 计算平台）上只用单个 VAE graph 副本，以避开并发 graph replay 观察到的挂起。
- Intel Arc Pro B70：记录 1、2、4 卡部署；推荐的四卡布局是 DiT TP4（4 路张量并行）加文本编码器逐层 offload（把权重搬出显存、放进 CPU 内存），以塞进 32 GB 显存的卡，更小的布局连 DiT 权重也 offload，VAE 在 XPU 上 eager（逐步即时执行、不建计算图）解码。
- 华为昇腾：覆盖 Atlas 800I A2、Atlas 800T A3 与 Atlas 350（A5）；实测配置用 1、2 或 4 颗 NPU、BF16、eager 执行，四 NPU 时 A2 用 DiT TP4，A5 用 Ulysses SP4 加文本编码器 TP4。
- 摩尔线程 MTT S5000：经 MUSA 实现支持，启用 VAE graph 解码，配方给出 80 GB S5000 卡上的 TP2 与 TP4 布局，graph 测试核对与 eager 解码逐位一致。
NVIDIA 一侧，单张 RTX 5090 也能跑：靠 DiT 与文本编码器逐层 CPU offload，4K 文生图 52.29 秒、单参考图 4K 编辑 61.45 秒；RTX 6000D 与 RTX PRO 6000 则让 DiT 常驻、只 offload 编码器并用 VAE CUDA Graph。博客把与常驻数据中心配置的延迟差距部分归因于这类 offload。边界同样写明：AMD、Intel、昇腾与摩尔线程的数据是社区在各自工作负载与配置下的验证，同口径性能对比只覆盖 NVIDIA 那组。
AA 榜单上的位次与 OpenDirector 在途集成
帖文向 MiniMax 道贺的排名来自 Artificial Analysis：目前把 H3-Image 排在第 12 位、Elo（等级分）为 1,138；按 AA 的口径，排在其前的 GPT Image 2.6、MAI-Image-2.7-Preview、Seedream 5.5 等均不属于开放权重模型，榜单上下一个开放权重模型 Fibo 2.0 的 Elo 为 1,085。
帖文还介绍了 vLLM-Omni 维护者开发的 ：GitHub 上 ThinkFlowLab/OpenDirector 仓库，Apache-2.0 许可，11 月 6 日发布首个版本 v0.1.0，定位是本地运行、浏览器访问的智能体创作工作台，功能覆盖对话生成素材、画布上管理与串联、编辑图像视频音频、时间线排布后导出 MP4。仓库示例短片《我们还能赢》（60 秒、Dota 2 题材）的视频生成走的正是 vLLM-Omni 服务的 FastH3。但图像侧尚未切到本地部署：博客说明，OpenDirector 的 Day-0 H3-Image 集成目前使用 （文生图与编辑两个端点），由 vLLM-Omni 驱动的本地 H3-Image 工作流被列为计划，帖文称集成「正在路上」。
OpenDirector 用户要把 H3-Image 换成本地 vLLM-Omni 部署，需等这次集成落地，帖文与博客都把它列为下一步。