MiniMax H3 显存要求：16GB 能运行吗？本地部署与 API 怎么选
MiniMax H3 能否在 16GB 显存上运行？核对权重与 offload 要求、4–15 秒时长限制，以及本地 768p 和托管 2K 的区别。
先说结论： MiniMax 官方规格把单次输出限定在 4–15 秒，16GB 显存不会把一段视频变长。H3-Base-Ref2VA 最多接收 9 张图片；“12”指图片、视频和音频混用时的文件总数上限，不是 12 张图。官方开源本地路径是 H3-Base 的 768p 输出，完整 2K 还要经过托管的 H3-Context-IR 与 H3-Regenerate-2K。官方没有给出 16GB 原始 BF16 权重的可复现实测或实时速度，低显存运行必须说明量化、剪枝和 CPU offload。
一张 16GB 显卡能不能跑 H3，最容易被一句“能启动”带偏：模型加载成功，不等于原始权重完整驻留，也不等于 15 秒视频能在可接受时间内生成，更不等于本地复现官方完整 2K 管线。
对想本地跑 H3 的人来说，真正重要的问题仍是三个：**官方有没有实时结论？16GB 显存到底限制什么？9 张参考图怎样用于跨镜头一致性？**下面逐项回答。
本文依据公开规格与部署要求整理，不是一次 16GB 显卡性能实测。
先认识 H3：这个 33B 的开源模型凭什么
MiniMax H3 是 33B 参数的全模态视频生成模型，统一处理文本、图像、视频、音频四类上下文。根据官方仓库，生成侧的边界是：
- 24 FPS、4–15 秒单段视频，默认短边为 768 像素；2K 由 H3-Regenerate-2K 完成；
- 原生 32kHz 立体声音频——不是后期配音，是生成时就带声；
- H3-Base-Ref2VA 最多接收 9 张图片、3 段视频和 3 段音频；图片、视频、音频混合输入时，全部文件合计最多 12 个；
- 权重在 GitHub（MiniMax-AI/MiniMax-H3）开放，ComfyUI 已支持三类工作流；
- 开源部分是 H3-Base；H3-Context-IR 依赖托管模型与服务，H3-Regenerate-2K 也尚未开源。
官方仓库的 System Overview 直接列出 4–15 秒、默认短边 768 像素、24 FPS 与 32 kHz 立体声等输出规格。
这三层不能混成一个“本地 H3”：H3-Context-IR 先把复杂多模态输入整理成模型可用的中间表示；H3-Base 在本地生成 768p 音视频；H3-Regenerate-2K 再把 768p 结果与原始上下文一起送回模型重生成 2K。本地只跑 H3-Base，与官方完整托管 2K 流程不是同一条路径。
问题一：它真的能”实时生成”吗？
**官方资料没有给出可以据此下结论的实时基准。**官方仓库说明了输出规格和部署路径，但没有提供“3 秒生成 5 秒”、消费级显卡实时生成或名为“H3 Max”的统一性能数据。直播演示和第三方引语只能代表当时那套服务，不能作为 H3 通用速度。
判断某个具体服务是否实时，要看同一组条件下的完整日志：模型路由、分辨率、时长、并发、冷启动、排队时间和失败重试。第三方托管服务的一次演示也不能外推到 MiniMax 官方 API、SandBase 路由或本地显卡。
问题二：16GB 显存能跑多长？
先给结论：单段时长由模型规格决定（4–15 秒）；显存只回答某套具体配置能否装入和完成生成。“长视频”要靠多段工作流，不是靠显存硬堆。
只按 8GB、12GB、16GB 写成“可跑/流畅/甜点位”并不可靠；缺少 checkpoint、量化精度、offload、画布尺寸、时长和耗时，就无法复现。更准确的边界如下：
| 配置 | 官方能确认什么 | 不能据此推出什么 |
|---|---|---|
| 原始 H3-Base | 33B 模型；官方 SGLang 示例使用 4 张 GPU | 不能推出原始 BF16 权重可直接装进 16GB |
| 16GB 社区低显存方案 | 可能通过量化、剪枝、CPU offload 完成短片 | 不能省略具体权重、峰值内存和耗时后宣称“流畅” |
| 托管 H3 路径 | 服务方负责显存与扩缩容，可提供 768p/2K 路由 | 不能把托管速度当成本地 16GB 性能 |
Hugging Face 模型卡将 MiniMax H3 标记为 33B 参数、F32/BF16；这仍不能证明某张 8GB、12GB 或 16GB 显卡的生成速度。
所以 16GB 不是时长开关，也不能脱离配置被称为“甜点位”。同一张卡上，4 秒低分辨率、量化权重和大量 CPU offload 可能跑完；15 秒、更大画布或更高精度则可能显存不足或等待很久。真正要记录的是 checkpoint、量化格式、系统内存、offload 策略、帧数、分辨率和总耗时。
想做几分钟成片，仍要把 4–15 秒片段按分镜生成，再在剪辑软件里串联。上一段尾帧可以作为下一段关键帧，角色卡和场景描述继续复用，但接缝、音频连续性和物体位置仍需人工检查。
问题三：人物一致性怎么保？
H3 给的工具是 R2V（参考生视频）多参考机制：H3-Base-Ref2VA 最多接收 9 张图片，或最多 3 段视频、3 段音频；混合时所有文件总计不超过 12。参考输入能提高角色、场景和声音线索的连续性，但官方没有承诺“锁定”或跨镜头完全一致。
ComfyUI 文档分别列出文生视频、图生视频与参考生视频三种原生工作流，并说明 R2V 可使用图片、视频和音频参考。
实践中可以按这个顺序排查一致性翻车：参考图是否来自同一角色设定 → 正面、侧面、服装和关键道具是否互相矛盾 → 分镜提示词是否复用同一套角色描述 → 前后片段的尾帧与首帧能否衔接。固定 seed 可以帮助复现同一配置，却不能单独保证跨分段角色一致。
成本账：本地和 API 怎么选
这里不写统一的“每秒价格”或“多久回本”：价格会随路由、分辨率和服务商变化，本地也有电费、系统内存、存储、维护时间和失败重跑成本。只有把这些项目一起算进去，本地与 API 的成本比较才有意义。
SandBase 目前提供独立的 H3 文生视频、图生视频、参考生视频和视频重生成路由。它是托管调用入口，不代表 SandBase 拥有 MiniMax 模型，也不能证明第三方演示的速度或 MiniMax 的计费政策。调用前应以当前 H3 参考生视频路由展示的 schema 和价格为准。
| 场景 | 本地 H3-Base | 托管 H3 路由 |
|---|---|---|
| 偶尔做一条 2K 成片 | 本地开源路径只验证 H3-Base 768p | 适合调用托管的 2K 流程，但价格以路由页为准 |
| 高频反复试错 | 要维护量化、offload 与本地环境 | 不用维护 GPU，成本随调用次数累积 |
| 速度要求 | 必须用同配置日志实测 | 必须看具体服务的排队、生成和重试时间 |
| 单段时长 | 4–15 秒 | 4–15 秒 |
| 几分钟长视频 | 多段生成后拼接 | 同样需要生成多个片段再拼接 |
第一次做参考生视频，可以先选两张互不矛盾的人物图，设置 duration: 4、resolution: "768P"，提示词只描述一个简单动作。检查脸、服装和镜头衔接帧后，再增加时长或选择 "2K"。这些是托管路由支持的选项，不是实测速度，也不是本地 16GB 配置。提交任务与轮询结果可按图片和视频 API 文档操作；拿到任务 ID 还不代表视频已经生成完毕。
结论：按本地 768p 与托管 2K 的边界来选
三个问题的答案已经足够清楚：官方没有给出可外推的实时基准；16GB 显存不改变 4–15 秒单段上限，低显存成功必须连同量化和 offload 配置一起描述；人物一致性可以利用最多 9 张图片的 Ref2VA 输入提高，但不能保证完全锁定。
如果只是验证提示词和镜头，本地 768p H3-Base 更可控；如果需要官方完整 2K 路径或不想维护 GPU 服务，选托管路由。无论哪条路，几分钟视频都仍是一项分段生成、连续性检查和后期剪辑的工作。
FAQ
MiniMax H3 本地部署最低要什么显卡？
官方没有给出单卡最低显存结论。原始 33B H3-Base 不是 16GB 直接运行的官方配置；12–16GB 社区方案通常依赖量化、剪枝和 CPU offload，必须查看具体 checkpoint、系统内存、分辨率和耗时。
MiniMax H3 能实时生成视频吗？
官方仓库没有提供统一的实时生成基准。判断本地或托管服务是否实时，需要在相同分辨率、时长、并发和冷启动条件下查看完整日志。
16GB 显存能生成多长的视频？
单段视频为 4–15 秒，这是模型规格上限，与显存容量无关。显存是否够用取决于权重精度、offload、帧数与分辨率；长视频需要多段生成和后期拼接。
H3 的人物一致性怎么做？
用 H3-Base-Ref2VA 参考生视频模式，最多放 9 张图片；图片、视频和音频混用时文件总数最多 12。统一角色设定和衔接帧可以提高连续性，但不能保证跨分段完全一致。
H3-Regenerate-2K 是什么？为什么本地用不了？
它把 H3-Base 的 768p 结果连同原始上下文送回模型，重新生成 2K 结果。完整流程还依赖托管的 H3-Context-IR；这两部分都不能被描述成纯本地开源 2K 管线。
