MiniMax-H3-Image 与 MiniMax-H3：一个是视频模型，另一个是它的静帧剪辑版

关于 MiniMax-H3-Image，最诚实的莫过于它的文件清单。66 GB 的扩散 Transformer、2.34 GB 的 VAE、12 MB 的逐步采样头——而整个仓库里没有任何文本编码器。编码器并非缺失，而是借来的：model_index.json 会伸手探进 MiniMax-H3（那个 33B 的全模态视频模型，由 MiniMax 于 2026 年 7 月 31 日开源），并从那里加载 text_encoder/——66.7 GB 的 Qwen3-VL，原封未动。如果 MiniMax-H3 已经躺在你的磁盘上，那么用这个图像模型编码提示词不产生任何额外开销。如果不在，你的第一张静帧就要付出 135 GB 的下载量，而这场对比中的第二个模型，正在为第一个模型干着实实在在的活。

那一行配置就是两个模型之间的关系，也解释了它们之间大多数实际差异。MiniMax-H3-Image 是在 MiniMax-H3 的基础上去掉音频分支、将输出头从潜空间视频重新定向到潜空间图像，并把整个模型蒸馏到六步采样。文本侧没有任何改变。DiT 甚至从同一个编码器读取相同的第 50 层隐藏状态，这就是为什么 tokenizer 和 processor 文件夹字节级完全一致，以及为什么图像模型继承了 H3 的英语提示词处理能力，而无需在该路径上新增任何训练。

如今值得写这件事，原因不在其内容，而在其发布方式。M​iniMax 并未为这个图像模型发布博客文章。公司的博客和新闻索引中没有任何关于该图像模型的内容——那里最新的一条是 10 月 19 日的 M3.1 Flash 文章——而模型页面仍以 H3 作为视频系统打头。我们所能找到的唯一厂商侧确认，是 API 文档模型发布列表里一张日期为 2026 年 11 月 10 日的卡片，上面写着“领先的开放权重图像模型。从想法到新世界”——这句话没有规格、没有基准测试，也没有自己的日期。Hugging Face 仓库创建于 11 月 3 日，权重于 11 月 10 日 14:50 UTC 上线。随后一小时内又出现了两次 README 修订和一份 vLLM-Omni 部署指南。这是一次悄无声息的发布：制品真实且可下载，公告却没有。下文所有内容均读自该仓库、许可证文件以及 M​iniMax 自己的文档；凡属厂商自称但未经复现的数字，我们都会予以说明。

这两种模式，按各自实际销售时所依据的条件来看

MiniMax-H3 是一个通用全模态生成器。它将文本、图像、视频和音频作为一个打包上下文，输出 4 到 15 秒、每秒 24 帧的视频，并带原生 32 kHz 立体声音频，原生分辨率为 768p，并通过单独的再生阶段——H3-Regenerate-2K——将结果和原始上下文重新输入模型以达到 2K。有两个重要的输入变体：H3-Base-FL2VA 接收零张、一张或两张图像作为首帧/末帧，而 H3-Base-Ref2VA 最多接收 9 张图像、3 个视频片段和 3 个音频片段，总文件数上限为 12 个。名为 H3-Context-IR 的托管预处理器会解析混合输入，并将其重写为结构化形式，并且 M​iniMax 明确表示，它不属于开源发布的一部分，因为它依赖多个托管模型。

MiniMax-H3-Image 接收文本和最多 16 张参考图像，并输出一张图像。其扩散 Transformer 有 331 亿参数——采用稠密单流设计，50 层，隐藏维度 5,376，56 个注意力头，FFN 宽度 14,336，使用 3D 多模态 RoPE，权重为 BF16，嵌入、时间步和输出层为 FP32。图像 VAE 是 CNN 编码器搭配 24 层 ViT 解码器，具备 16 倍空间下采样和 24 个潜变量通道；DiT 将该潜变量按 2×2 切块，因此一个 Transformer token 覆盖 32×32 像素块。通过 API 输出面积可达 2000 万像素，而该卡宣称的核心卖点是：在各种宽高比下均约 1600 万像素——1:1 时为 4096×4096，最高到 21:9 时的 6272×2688，且无需超分器。

把这两段并排读，分岔就一目了然了。视频模型把容量花在时间上，以及第二种模态上。图像模型则把容量花在空间上。同样的主干，不同的目标。

六步且不使用无分类器引导，这才是真正的工程实现。

MiniMax-H3-Image 中不只是做减法的环节是蒸馏，而且这是强制执行而非建议。该检查点运行六个采样步——六次 NFE——完全不用无分类器引导。对外提供的 API 并不把这些当作默认值：num_inference_steps必须省略或为 6，guidance_scale必须省略或为 1，任何其他值都会返回 HTTP 400。负面提示词会被直接拒绝。另有一个文件，pdd_fused_heads.safetensors，其中包含用于替换 Transformer 输出层的按步输出头，调度表位于 pdd_config.json；也就是说，在总计 68.65 GB 中，这 12 MB 完成了比例极不相称的大量工作。

这就是可置于交互式界面背后的模型与无法置于其后的模型之间的区别。1600 万像素下经过引导的 30 步扩散模型是一项批处理任务；同等分辨率下的六步无引导则是一次请求。MiniMax 自己的说法——“以实用的计算成本生成 1600 万像素图像”——是一个关于每像素 FLOPs 的主张，而六步调度方案正是兑现该主张的方式。它能否在展示图所暗示的质量水平上成立，是尚无第三方回答的问题；截至 2026 年 11 月 10 日，两个图像榜单上都没有 MiniMax-H3-Image 的 Artificial Analysis 条目，模型卡中也没有厂商评测表。

对于本地部署而言，对于如此年轻的模型，框架生态异常完整。SGLang 是参考路径，配有文档化的操作指南；vLLM-Omni 发布了包含各硬件配置和实测延迟的方案，点名 NVIDIA H200、RTX PRO 6000 Blackwell 和 AMD Instinct MI350X；diffusers 和 ComfyUI 都内置支持。序列并行只是一个开关——--ulysses-degree 在 SGLang 上，--usp 在 vLLM-Omni 上——单块 GPU 就足以开始。文本编码器才是真正的内存开销，而且它是视频模型的文本编码器，这正是整个比较的关键所在。

两台仪表，而且它们都不是能靠肉眼估读的 token 计数器。

MiniMax 对这两个模型采用互不兼容的计费单位，这正是任何“哪个更便宜”问题中的陷阱。H3 按生成输出的秒数计费，并依分辨率而定：768P 下每秒 $0.08，2K 下每秒 $0.13，输入素材还需额外计费——基础模型上前五张参考图像免费，之后每张 $0.04，音频输入免费，参考视频按其自身时长、按输出分辨率计费。一段 10 秒的 2K 片段，在计入任何参考素材之前，仅输出费用就是 $1.30。

MiniMax-H3-Image 按 token 计费，计费依据是图像输出费率。在标准层级下，公布的价格表显示：每百万输入文本 token 为 $2.30，每百万输入图像 token 为 $1.50，每百万输出图像 token 为 $3.80；供应商自己给出的计算示例将其折算为：

• 1K（1024×1024）文生图 — 每张图片 $0.02179。

• 2K（2048×2048）文生图 — 每张 $0.02333。

• 4K（4096×4096）文生图 — 每张图像 $0.06879，限时五折优惠标价 $0.03439。

• 使用一个参考进行 1K 编辑 — $0.02654；2K — $0.02658；4K — $0.07312，折扣价为 $0.03656。

• 含三张参考图的 1K 编辑 — $0.03563；2K — $0.04177；4K — $0.07914，折扣后为 $0.03957。

那座阶梯的形状才是有意思的地方。像素数变为十六倍，费用只略高于三倍，因为计费单位是 token，而 token 数量并不像直觉以为的那样随面积线性增长。高速变体 MiniMax-H3-Image-Highspeed 采用相同的参数和限制，按每百万输出图像 token 7.60 美元计费——在同样的折扣前，1K 时为 0.03529 美元，4K 时为 0.13001 美元。当交付图像至少为 16,600,000 像素时适用该折扣，有效期至 2026 年 11 月 17 日 16:00 UTC，这是整个发布中唯一带有日期的商业信息。

把两个计价器并排放在一起，分岔口就有了价码。一秒 768P 视频是 $0.08；最便宜的 M​iniMax 静态图大约是 $0.022。一段四秒短片——H3 能生成的最短时长——成本大致相当于十五张 1K 图像。这并不是支持任一模型的论据。这正是为什么在你说清自己要产出什么之前，“哪个更便宜”没有答案。

在实际部署中，分叉会在哪里真正带来问题

三种不对称比基准问题更重要。

第一项是输入处理。H3-Image 在一次编辑中最多接受 16 张参考图像，并以位置方式将它们引用为 <Picture 1>、<Picture 2>等等，按上传顺序；请求体总大小上限为 64 MiB，而 Base64 会使文件大小增加约三分之一，因此包含 16 张图像的请求必须使用 URL 或预先上传的文件引用，而不能使用内联数据。H3 的参考模式则完全是另一回事——9 张图像、3 个视频、3 个音频片段、12 个文件，全部打包进一个具有时间结构的序列中。两种模型的参考处理方式互不构成对方的超集。

第二个问题是提示词长度。H3-Image 对外提供的 API 最多接受 32,000 个字符，但在禁用提示词增强时，只有大约前 4,096 个 token 会生效；本地 SGLang 路径则在 4,096 个 token 处截断，仅此而已。对于一个以细致遵循指令为卖点的模型来说，这算不上宽裕的预算，这也正是配套提示词扩展器存在的原因——MiniMax-H3-Image-PE，它是 Qwen3.8-27B 的 27B FP4 微调版本，可将简短请求改写成详细描述并给出宽高比建议，于 11 月 8 日发布，采用同一社区许可证。它的编辑部分仅以提示词形式发布；用于编辑侧扩展的权重仍被描述为开发中。

第三项是许可证，而且对于两个模型来说，这个同名许可证只在名称上相同。MiniMax-H3-Image 社区许可证协议要求，如果你的年化收入或你的关联公司的年化收入超过一百万美元，或者你向第三方提供托管服务，则必须事先获得 MiniMax 的单独书面授权。它要求你在任何使用该模型的商业产品界面上显著展示“MiniMax-H3-Image”。它将使用限制在定义的适用区域内，禁止使用输出改进任何其他 AI 模型，并且不主张对输出本身拥有任何权利。H3 视频许可证是另一份单独协议，有其自身条款。如果你同时基于两者构建产品，那么你持有的是两个许可证，而不是一个。

两个模型都不做的事

MiniMax-H3-Image 无法生成视频。它没有时间轴、没有音频分支，也没有时长参数——音频 VAE 已从架构中彻底消失，每次请求只输出一张潜空间图像，通过 API 单次调用最多可生成十张。MiniMax-H3 无法生成 1600 万像素的静态图像。它默认生成 768p，并通过一次重生成过程达到 2K；要求它输出 4096×4096 的单帧并不是受支持的请求。如果你的流水线需要同一视觉世界中的一张主视觉静帧和一个带同步对白的五秒循环视频，那你就是在调用两个模型，而在 MiniMax 的平台上，你也要按两套不同的计量方式付费。

两者确实有一个容易忽略的共同点：没有负面提示词。H3-Image 会拒绝该字段。H3 的提示词引导通过正向描述和 Context-IR 来实现，而不是通过排除。任何将 Stable Diffusion 工作流迁移到这两个模型的人，第一天就会失去这个手段。

要调用哪一个

诚实的劳动分工是按交付物来划分，而不是按质量。如果产物是静帧——产品渲染图、关键帧、一张包含清晰可读文字的 1600 万像素底图——那么 MiniMax-H3-Image 就是该选的模型，而六步调度意味着你有余力对它反复迭代。如果产物会动，那么 H3 就是该选的模型，而音频分支正是它比把静帧拼接成序列更值得选的原因。

在这里，路由层所带来的改变比听起来要有限得多，值得直说：OrcaRouter 并不提供 MiniMax-H3-Image。该模型于 11 月 10 日公开权重，但我们的目录里没有对应路由，所以如果你今天就想用它，只能通过 MiniMax 自家的 API 获取，或者自己运行那 68.65 GB 的代码仓库。我们确实提供的是 minimax/minimax-h3，即那个视频模型，按秒计费、按标价收费、不加价——而对于双模型流水线来说，真正有用的特性是 调用 H3 的同一个密钥也能访问平台上其他 200 多个模型。

真正值得关注的不是 H3-Image 好不好，而是 M​iniMax 是否会对它作出任何表态。一个随附权重、许可证、定价卡和四个框架集成，却没有博客文章、也没有基准测试的模型，其说法仍然完全属于厂商。图像榜单上的首次独立排位，或首次与同分辨率的闭源模型正面交锋，会比展示图墙告诉你更多。在那之前，仓库就是记录，而仓库说的是：这就是关掉了声音的 H3。