MiniMax-H3-Image 已登陆三大平台：每个平台究竟能为你提供什么

本周关于 MiniMax-H3-Image 最短、也最属实的一句话是：它有三个获取渠道——Hugging Face、MiniMax Code，以及 MiniMax 自家的 API。但采购方真正需要的那句话，范围要窄得多。这三个渠道里，有两个给你的只是一个请求端点和一张价目表；另一个给你的则是 135 GB 的权重、一份得你自己去读的许可证，以及一个硬件层面的决策。这三者并不是同一种访问方式的不同口味；把它们当成可以随意互换的选项，正是一个团队为一件事排出一周预算的由来——而那件事本来可以按张两分钱就买到。

模型本身是一次真正的发布，而非重新打包。M​iniMax 于 2026 年 11 月 10 日 14:50 UTC 将权重放入 Hugging Face 仓库 MiniMaxAI/MiniMax-H3-Image，并于当天下午 15:40 发帖提及此事；该仓库本身可追溯至 11 月 3 日，也就是说，权重在任何人能够下载之前已私下存在了一周。它是一个 331 亿参数的扩散 Transformer，生成分辨率约为 1600 万像素，也就是公告中所说的“4K”，并且可从单一检查点进行文生图和参考图引导编辑。下文围绕公告没有回答的那个问题展开：你应该使用哪个入口。

三扇前门，而其中只有一扇是下载

先说明每扇门是什么，因为差异是结构性的，而不是表面上的。

该API是常规路径。该模型以MiniMax-H3-Image的名称列出，并有一个 Highspeed 同级型号，在 M​iniMax 的国际和中国大陆平台上提供，按每百万输入和输出 token 计费，而不是按图像计费。该接口的限制异常严格——六步采样、没有引导尺度、没有负面提示词——而且 M​iniMax 自己的参考文档称，要求其他任何参数的请求都会返回 HTTP 400。你买到的是一个内置固定配方的可用端点。

M​iniMax Code 和 Hailuo AI 都是产品界面：同一个模型藏在提示框后面，采样决策已经替你做好，无需你逐 token 计算。用来评估输出质量好不好很有用；但用来构建任何东西则没用，因为你要构建所依赖的东西并未暴露。另请注意，M​iniMax Code 是一个编程智能体产品，因此其中的图像生成只是旁门而非主要功能——不要把“可在 M​iniMax Code 上使用”理解为带代码封装器的图像 API。

Hugging Face是第三扇门，也是唯一一扇属于“交付”而非“服务”的门。你会得到一个仓库、一个许可证文件，以及一组现在必须由你让它跑起来的权重。自托管正是大多数团队会考虑开放权重图像模型的根本原因；也正是在这里，算账的重点不再落在模型上，而开始落在你的机架上。

该仓库比其标称参数量所暗示的更为庞大。

以 BF16 表示的 331 亿参数约为 66 GB，这还没算上其他任何东西，而“其他任何东西”正是这个仓库让人意外的地方。仅扩散 Transformer 本身就有 66.28 GB。完整下载为 68.65 GB，其中包含 Transformer 以及 VAE 和配置。文本编码器并未计入该数字：MiniMax-H3-Image 复用了 MiniMax-H3 视频仓库中的 Qwen3-VL 文本编码器，从其第 50 层读取，而该编码器需要单独下载 66.7 GB。换句话说，在生成第一张图像之前，请为磁盘上约 135 GB 的文件预留空间，而这还不包括任何框架自身的缓存。

这套架构值得用一段话来讲，因为它能说明这个模型究竟是什么。50 个 Transformer 层，隐藏维度 5,376，56 个注意力头，前馈网络宽度 14,336，并采用三维多模态旋转位置编码。VAE 是一个卷积编码器，搭配一个 24 层二维 ViT 解码器，空间下采样倍率为 16×，潜通道数为 24——选择这样的解码器，会让管线末端的计算开销高于普通卷积解码器，而 4K 下的一些精细细节很可能正来源于此。模型卡中将这一设计描述为“H3 架构去掉音频”，这个概括很中肯：它就是那个视频模型的图像分支，被单独发布了出来。

由此会带来两个结果。首先，一个 33B 级扩散 Transformer 在 1600 万像素下并不是笔记本能跑的模型——无论参数规模与现代语言模型相比听起来如何；激活内存随输出面积增长，而面积正是此次发布的关键所在。其次，由于文本编码器与视频模型共用，已经运行 MiniMax-H3 的工作室磁盘上已经有了大部分下载内容。这是实打实的优惠，而“可在 Hugging Face 上获取”这句话并不能传达这一点。

四种供应方式，以及一个对不上的数字

模型卡列出了四条路线：SGLang、vLLM-Omni、diffusers 和 ComfyUI。vLLM 团队在发布当天就通过 vLLM-Omni 为 NVIDIA 和 AMD 硬件实现了首日支持，原生输出约为 1600 万像素；这比权重已经存在是更强的发布信号——在公告发布还不到一小时的时候，MiniMax 之外就有人把它跑起来了。Diffusers 覆盖参考路径，ComfyUI 覆盖工作流图用户群体。

这一分歧值得指出，因为终会有人因此吃亏。模型卡描述编辑时最多可使用16张参考图，按位置指代为<Picture 1>到<Picture 16>（按上传顺序）。同一模型的 vLLM-Omni 发布配方记录每次请求最多9张图像。两者可以同时成立——框架的服务限制和模型的训练容量是两个不同的数字，而服务栈中的批处理或内存约束会先成为瓶颈——但如果你的工作流需要十二张参考图，那么今天诚实的答案是：能力确实存在，而文档所述的服务路径可能承载不了它。请在你的技术栈上实测这个数字，而不是相信任何一份文档。

提示词窗口也适用同样的注意事项。卡片最多接受 32,000 个字符，而模型实际据以生成内容的大约只是前 4,096 个 token。长提示词不会被拒绝；只是尾部根本不会起作用。任何带着大语言模型的使用习惯、想移植一份详细艺术指导提示词的人，都会以高昂的代价发现这一点。

采样器是你继承下来的约束，而不是你可以调节的设置。

六步，无无分类器引导，也无负面提示词。这不是一个还能往上调的默认值；API 会直接拒绝其他步数和引导值。该模型经过蒸馏，只需六次前向传递即可运行，而 33B Transformer 能足够快地返回一张 1600 万像素图像、使其具备实用价值，这一切的根本原因正是这种蒸馏。

对于 API 路径来说，这是不可见的，也无妨。对于自托管路径来说，它是规格表中唯一最有用的数字，而且其价值是双重的。它将每张图像的计算量限制在六次 transformer 评估，而不是非蒸馏模型所需的二十五到五十次，这正是让 1600 万像素真正可行的原因。这也意味着常见的自托管调参循环——尝试更多步数、增加引导、添加负面提示词、反复迭代——在这里并不存在。如果输出质量令人失望，可调的杠杆是提示词和参考图，而不是采样器。那些为“调优模型”预留一周时间的团队，应该把这周时间改用于提示词工作。

每条路径以实际计费单位计算的费用

API 按 token 计费，而卡片自带的演算示例是理解这一点最清楚的方式。一次 1,024×1,024 的文生图请求费用为 $0.02179。一次 2,048×2,048 的请求费用为 $0.02333——像素数是四倍，价格却只有 1.07 倍，因为 token 数量的增长远慢于面积。一次 4,096×4,096 的请求标价为 $0.06879，在限时 50% 折扣下为 $0.03439，该折扣持续到 2026年11月17日 16:00 UTC，并要求交付图像至少达到 16,600,000 像素。标准层级费率为每百万输入文本 token $2.30、每百万输入图像 token $1.50、每百万输出图像 token $3.80；Highspeed 层级保持输入费率不变，输出收费为 $7.60。

把这三个数字放在一起看，4K 在价格上的理由基本就不成立了。在 2K 这一档，用 1.07 倍的钱换来四倍像素，简直是白送；从 2K 到 4K，面积同样增加四倍，花费却约为三倍，只有折扣才能把它拉回到接近 2K 的价格水平。如果你的用例不需要单边 4,096 像素，那么这个型号在 2K 档才便宜。

OrcaRouter 不提供 MiniMax-H3-Image——这里没有它的路由，本文中的 CTA 指向其同系列视频模型，minimax/minimax-h3，而该模型我们确实有路由。我们提供的功能与这条路由上线那天息息相关：0% 加价，供应商列表价原样透传，这意味着像 4K 折扣这样的供应商价格变动，会在供应商页面更新的同一天反映到你的账单上；如果某条供应商路径质量下降，还会自动故障转移。在那之前，真正重要的比较是 API 支出与你自有硬件的对比，而任何路由层都不会改变这笔账。

自托管，诚实定价

没人能在不知道你使用什么 GPU 的情况下，给你报出每张图的自托管成本，因为主导因素在于 135 GB 的权重是能放进内存，还是必须被卸载。可以精确说明的是：六步采样器决定了计算量，1600 万像素输出决定了激活预算，而两者都很大。单张 80 GB 显卡能装下 transformer，但装不下 transformer 加全精度的 Qwen3-VL 编码器，所以现实可行的配置是多 GPU、卸载编码器，或者使用附带质量疑问的量化 transformer。再加上电力成本，以及把 SGLang 或 vLLM-Omni 正常部署起来所需的工程师周数，相对于每张 2K 图像 $0.02333 的盈亏平衡点，其对应的量级是数十万张图像，而不是几十张。

多数情况下应选 API、少数情况下才应选权重，理由分别是：有的企业出于数据原因需要让模型留在自己的边界内，或者已经运行 MiniMax-H3 并持有编码器，或者生成量足够大、能让固定成本摊薄。其他人则应先比较 API 的价格，只有当边界确实要求时才自托管。

在下载前阅读许可证，而不是下载后

权重依据 MiniMax-H3-Image Community License Agreement 发布，该协议既不是 Apache 2.0，也不是 MIT。“Open-weight”是准确的说法；“open-source”才是会让团队陷入麻烦的说法，而这也正是流程中应当由律师阅读实际文件、而不是阅读博客文章（包括本文）的节点。实际问题在于大规模商业使用，以及该许可证是否带有会附着到你的产品上的条款；这个问题在仓库中有答案，任何摘要都无法替代。

还有第二个更小、值得了解的产物：MiniMax 为该模型随附了一个 Context-IR 组件，以及一个可选的提示词扩展器模型 MiniMax-H3-Image-PE。该扩展器在一定程度上解释了模型为何能容忍冗长、详细的提示词；它是可选的，与 68.65 GB 是分开的，而且它属于那种你会在仓库列表中而不是公告里发现的东西。

本周该在自己的技术栈上检查哪些内容

• 参考资料——请用真实请求而不是阅读文档来确认：你的服务路径是支持 16 张图像，还是支持 vLLM-Omni 方案文档中记录的 9 张。

• 有效面积——模型将在低于 1600 万像素下运行，且配置提供了一个最小生成面积，默认值为 4,194,304 像素。如果你的用例是缩略图，请测试小尺寸端，因为这种规模的模型在 1K 下可能并不是便宜的选择。

• 显存 — 购买硬件前，先测量 4,096×4,096 下的峰值显存占用。六步的计算开销很低；激活值则不然。

折扣倒计时——如果计划是 4K，50% 的费率将于 2026 年 11 月 17 日 16:00 UTC 结束，而你使用的是 API 还是自己的硬件，将决定这个截止日期是否与你有关。

• 许可证——读一读吧。下载量是 135 GB，这个决定可以撤回；许可证则不行。

这次发布有意思的地方，不在于出现了一个优秀的开放图像模型——而在于时隔许久，第一次有一个模型在同一周内让权重、框架配方和托管端点全部落地。这比基准图表是更强的信号，因为这意味着它真的能跑起来。至于你应该自己运行它，还是调用它，完全取决于你走的是三扇门中的哪一扇，而这三扇门之间的差距，远比公告听起来要大得多。