← 返回列表

grok-h3-feasibility-report.md

MiniMax H3（Hailuo）在 RTX 5060 Ti 16GB 上生成 1MP × 15s 视频的可行性调研

0. 一句话结论

问题结论
16GB 能不能生成 1MP × 15s？能。 最接近的硬证据：RTX 5070 Ti 16GB（同代 Blackwell）完跑 736×1280 ≈ 0.94MP × 15s（14 步，全程含音视频 VAE decode，约 18 分钟）。RTX 4060 Ti 16GB 完跑 1344×768 × 5s。本机已跑通 0.5MP × 15s。
是不是「官方推荐配置」？不是。 官方满血 BF16 是 4×H100 级服务；ComfyUI 官方宣传线是「pruned INT8 + 动态卸载，RTX 3060 可跑」。16GB 属于社区验证的消费级档，不在官方 SGLang 配方里。
主要风险① 1MP×15s 的 激活值尖峰（attention / FFN 临时缓冲）导致 VRAM OOM；② 32GB RAM 不够放权重匿名副本（不加 --fast-disk 会到 ~45GB RSS）；③ 速度过慢（20 步官方档可能 30–60 分钟）；④ H3 原生画布上限 ≈ 1.03MP，本地开源权重 没有 2K。
推荐策略用 v4 启动脚本再加 --disable-pinned-memory；工作流保持 turbo LoRA 8 步 + Spectrum + SolAttn/Sage + LowVRAM Attention + ChunkFF；分辨率用 1344×768（0.98–1.03MP）或 1280×736（0.94MP），不要填 1280×720（高度不是 32 倍数），也不要用 Resolution Selector 的 1.0 MP（会算出 1376×768，超出画布）。

1. 官方能力边界与硬件要求

1.1 模型是什么（避免把 API 规格当成本地规格）

MiniMax H3（海螺 3.0）是 2026-08-03 开源的全模态视频模型，一次前向同时出视频 + 32kHz 立体声音频。完整系统分三块：

模块开源情况本地能做什么
H3-Context-IR未开源（官方 API / 平台服务）本地需自己写 prompt，或调官方 Context-IR API
H3-Base（FL2VA / Ref2VA）已开源，BF16 原权重 + Comfy-Org 量化重打包本地生成 768p 画布、4–15 秒、24fps
H3-Regenerate-2K尚未开源广告里的「最高 2K」是二次 in-context 重生，不能在本机直接出 2K

官方 GitHub / HuggingFace 模型卡（MiniMax-AI/MiniMax-H3、MiniMaxAI/MiniMax-H3）给出的输出规格：

1.2 原生画布上限（这是 1MP 目标的硬约束）

HuggingFace Diffusers 文档写明：

ComfyUI 官方教程（docs.comfy.org MiniMax H3）额外强调：

16:9 全质量请把 Resolution Selector 的 Megapixels 设为 0.98（1344×768），跳过 1.0——1.0 MP 会算出 1376×768，超过 768×1344 面积上限。

因此目标分辨率应这样选：

目标像素是否 32 对齐相对画布建议
1344×7681.032 MP是正好打满上限16:9 成片首选
1280×7360.942 MP是约 91%更稳的「接近 720p」
1280×7200.922 MP否（720÷32=22.5）—不要用，节点会报错或被改尺寸
1152×6400.737 MP是约 71%质量/时间甜点（社区称 0.7MP 档）
960×5440.522 MP是约 51%本机已跑通的 0.5MP 档
864×4800.415 MP是约 40%官方模板默认预览档
1024×10241.049 MP是略超 1.032 MP 上限不建议；1:1 用 1024×992 或 992×992

1MP × 15s 在模型能力上合法：1344×768 × 362 帧正好落在「原生画布上限 × 训练时长上限」。这不是「超规格硬拉」，是 H3-Base 的设计顶点。

1.3 官方硬件：没有一张「最低显存表」

MiniMax 没有发布面向消费卡的 VRAM 最低/推荐表（Oflight 等二次来源也明确写了这一点）。官方给的是服务端配方：

场景官方/半官方配置精度备注
SGLang 服务4× GPU（示例 --num-gpus 4 --ulysses-degree 4）BF16面向可复现 768p
数据中心实测4×H100 / 4×H200 / 8×B300BF16 或在线 FP8单卡峰值约 50–94 GB
双卡消费级2×RTX 5090 + SGLang layerwise offload—约 26.3 GiB/卡
Diffusers 文档80GB 单卡 / 24–32GB 消费卡 INT8 + group offloadINT812–16GB 需再卸载 VAE，权重常驻主机内存约 75GB（INT8）
ComfyUI 官方博客pruned INT8 把足迹从 123.6GB → 42.5GB，配合 DynamicVRAM，RTX 3060 可本地跑pruned INT8 + NVFP4「可跑」≠「快」

权重体积（Comfy-Org 重打包，HuggingFace Comfy-Org/MiniMax-H3）：

组件BF16INT8 convrotpruned INT8（推荐）NVFP4
DiT FL2VA / Ref2VA61.7 GB31.7 GB~19.5–21 GBpruned FP8 同约 21 GB
Qwen3-VL-32B 文本编码器48–62 GB25.3 GB—~14.6–15.7 GB
Video VAE fp164.9–5.2 GB同左同左同左
Audio VAE fp320.6 GB同左同左同左
最小全家桶~123.6 GB~67 GB~42.5 GB 磁盘—

ComfyUI 团队的工程要点：AdaLN 调制支路约占 33B 参数中的 13B（约 40%），推理时可剪成查找表，这就是 pruned_* 比满血 INT8 少约 12GB 的原因。剪枝主要省磁盘和系统内存，不自动降低峰值显存——这一点被 RTX 5090 无卸载实测反复证实。

本机已具备 pruned INT8 + NVFP4 编码器 + 双 VAE + turbo LoRA，模型侧没有缺口。

1.4 不同分辨率/时长的显存：两条完全不同的曲线

必须先分清「权重常驻」和「激活值」：

A. 无卸载、权重大部进显存（5090 32GB 实测，wan2-7，8s / 192 帧 / 25 步）

分辨率档分辨率端到端时间（pruned INT8）峰值 VRAM
0.3 MP736×416~125 s（2.1 分钟）约 31.7 GB，三档权重几乎相同
0.5 MP960×544~257 s（4.3 分钟）同上
0.7 MP1152×640~446 s（7.4 分钟）同上
1.0 MP1376×768（略超画布）~829 s（13.8 分钟）同上 31,745–31,798 MiB

含义：在 32GB 卡、模型尽量驻留 GPU 时，峰值显存被权重钉死在 ~31.8GB，分辨率几乎不改峰值，只改时间。16GB 卡走这条路会立刻 OOM，所以 16GB 必须走卸载/流式。

B. DynamicVRAM / layer-wise offload（12–16GB 实测，峰值几乎不随分辨率变）

来源硬件任务峰值 VRAM峰值 RAM
minimaxh3tutorial.comRTX 3060 12GB512×288 × 22 帧11,591 MiB43.2 GB
同上（同机）RTX 3060 12GB1344×768 × 124 帧11,649 MiB（+58 MiB，+0.5%）43.6 GB
Tomiigo / HF 讨论 #6RTX 5070 Ti 16GB5s @ 1344×76814,437 MiB—
同上RTX 5070 Ti 16GB30s @ 640×48014,197 MiB—
ByronLeeeeeRTX 5070 Ti 16GB1280×736 × 5s × 20 步 + Sage已分配峰值 3.8–5.1 GB（不含桌面/碎片）—
neng320RTX 4060 Ti 16GB生产档~14 GB~44 GB
animede Diffusers真 4060 Ti 16GB768² t2va 5s11.4 GB需投影 TE
animede Diffusers真 4060 Ti 16GB768×1344 5s13.37 GB 分配 / 15.2 GB 真实占用（顶满）—

关键机制：工作量放大约 40 倍，峰值显存只动 0.5%。 时间几乎线性（或超线性）膨胀，显存被「当前驻留的那一层权重 + 一块工作缓冲」钉住。

因此对 1MP × 15s 的显存估算不应写成「0.5MP 的 2 倍」，而应写成：

  1. 常驻/流式权重：pruned INT8 单层 ~1–2GB 量级 + NVFP4 TE 编码阶段可到 15GB 瞬时 → 峰值常在 11–15 GB。
  2. 激活值尖峰（真正会炸 16GB 的部分）：
    • 视觉 token 粗算：(H/32)×(W/32)×(T/4)
    • 960×544 × 362 帧（0.5MP×15s）≈ 4.6 万 token
    • 1344×768 × 362 帧（1.03MP×15s）≈ 9.1 万 token（约 2.0×）
    • 未分块时 FFN 临时缓冲：Byron 在 15s 长序列上测到 FC1 上限从 5488 MiB → 分块后 224 MiB
    • Attention 工作区随序列近似二次：Sol-Attn 仓库在 65536 token 上 Sage 229ms / Sol 98ms，SDPA 则 1516ms 且显存更大
  3. VAE decode：像素×帧线性；15s 1MP 的 decode 峰值可能单独顶到数 GB，是长视频 OOM 的第二高发点。

对这台 16GB 机器的显存结论：权重本身「流起来」能进 16GB；1MP×15s 会不会 OOM，取决于 attention/FFN 分块 + VAE 分时 decode 有没有开。本机已经在 0.5MP×15s 上启用了 LowVRAM 分块 + ChunkFF，这正是冲 1MP 所需要的手段。

2. 16GB 显存可行性与社区案例

2.1 需要的技术手段（按优先级）

手段作用对本机代价
pruned INT8 convrot DiT + NVFP4 AWQ TE把 123GB BF16 压到 ~42.5GB 磁盘；INT8 在 cu130 上有硬件反量化已具备，保持；Comfy-Org 明确：能用 cu130 就不要用 FP8FP8 在 Blackwell 上甚至可能更慢（5090 实测 FP8 比 INT8 慢 8–30%）
ComfyUI DynamicVRAM（NVIDIA 默认开）按 tensor 在 VRAM / pinned RAM / 普通 RAM / NVMe 间搬权重保持开启，不要 --disable-dynamic-vram每步都可能重读权重，16GB 上速度受 PCIe/NVMe 限制
--fast-disk权重走 page cache / 文件切片，而不是匿名 RSS32GB RAM 几乎刚需每步从 NVMe 回流；NVMe 够快则可接受
--disable-pinned-memoryLinux 默认钉住 90% RAM，钉住的页不能换出32GB 强烈建议实测约慢 20%（8GB cap 实验：180s vs 150s）
SageAttention v2注意力 1.5–2×，降低工作区已在用；5060 Ti 是 SM 12.0，应用 sm_120 轮子与 --use-sage-attention 或 KJNodes patch 二选一，不要叠两层
Sol-Attn（ComfyUI-SolAttn_triton / sol-attn）相对 Sage 再快 1.14–1.44×；长序列更明显本机已装与 Sage 可联用（社区有组合），注意 dtype 回退日志是正常的
MiniMax H3 Low VRAM Attention（head_chunks）按头分组算 attention，压峰值0.5MP×15s 已用；1MP 建议 head_chunks=2~4分组越多越慢（launch 开销）
Chunk FeedForward沿 packed sequence 切 FFN，峰值约降 37%已用；1MP×15s 不要关轻微变慢；Byron 的 16gb_chunked 非 bit-exact
Turbo LoRA 8 步（LightX2V / Comfy-Org）20 步 → 8 步已用；官方模板也支持 turbo_mode运动/音频略降质；4 步更激进，音质风险更大
Spectrum部分 step 用 forecast 跳过整栈 Transformer已用非 bit-identical；与 EasyCache 同类，长视频音频可能漂
GGUF Q3/Q4DiT 再压到 ~10–16GB本机有 ComfyUI-GGUF，作 OOM 后备画质低于官方 pruned INT8；部分报告 I2V 异常
ClipProj / 4B 投影 TE用 Qwen3-VL-4B 代替 32BDiffusers 16GB 路线的关键，ComfyUI 非必须语义条件变弱
WanGP 低显存实现5–6GB / 5s，8–9GB / 15s @ 832×480可作「一定要出片」的平行通道分辨率/生态与 ComfyUI 原生节点不同

不建议作为 1MP 主力的手段：

2.2 同档硬件成功案例（交叉验证）

按「和这台 5060 Ti 16GB 的距离」排序。

最接近：Blackwell 16GB

来源硬件内存任务结果证据等级
ByronLeeeee Optimization SuiteRTX 5070 Ti 16GB未标（工作站）736×1280（0.94MP）× 15s，CAB-14 + Fused Kernels + Low-Memory Sage2 + 16gb_chunked完跑；denoise ~940s，端到端 1064s ≈ 18 分钟；含音视频 VAE高（公开仓库 + 联系图 + 配置链）
同上5070 Ti 16GB—1280×736 × 5s × 20 步denoise 194–209s，峰值已分配 3.8–5.1 GB高
Tomiigo/minimax-h3-16gb5070 Ti 16GB（无约束）32GB 内核 cap 或 125GBlength=243 全分辨率参考视频1027s，峰值 14.5–15.6 GB（含桌面）高
HuggingFace Comfy-Org #6（UdonJP）5070 Ti 16GB125GB5s @ 1344×768 vs 30s @ 640×480VRAM 14.4 vs 14.2 GB，几乎不随尺寸变；--fast-disk 把 RSS 从 45.4 → 12.6 GiB高
YouTube「MiniMax H3 On RTX 5060 Ti」RTX 5060 Ti 16GB + 64GB RAM64GB4s @ 0.4MP；Sage 使迭代从 ~12s → ~8s4s 0.4MP 145s；Sage 大约再省 100s中（视频实测，非 15s/1MP）
neng320 手册转引5060 Ti（非其本机）—8 步 / 20 步8 步 154s；20 步 首轮 194s / 次轮 185s（分辨率未在 README 展开，手册 §7）中

Byron 的 0.94MP × 15s 完跑是本调研中对「16GB 能否打 1MP×15s」最直接的肯定证据。 5070 Ti 算力大约是 5060 Ti 的 1.8–2.0 倍（8960 vs 4608 CUDA、约 70 vs 36 SM、带宽约 2 倍），所以本机应预期 更慢，但显存账同类。

次接近：Ada 16GB（4060 Ti / 4070 Ti SUPER）

来源硬件任务结果
neng320（2026-08-08）RTX 4060 Ti 16GB + 64GB RAMpruned INT8，T8 8 步864×480 5s ~109s；1056×608 ~180s；1344×768 5s ~360s；显存 ~14GB，内存 ~44GB
Reddit r/comfyui 1vflhueRTX 4070 Ti SUPER 16GB + 32GB RAMpruned INT8 + Sage + cu130，音频关640×832 1.6s → 2m09s；1056×672 5s → 5m58s；736×960 6.6s → 6m55s；无 OOM
animede/Diffusers_minimax-h3真 4060 Ti 16GB（Diffusers，非 ComfyUI）投影 TE + H3_LOWVRAM=groupt2va 768² 5s：25 分钟 / 11.4GB；768×1344 5s：66 分钟 / 真实 15.2GB 顶满

注意：Diffusers 16GB 路线用了 4B 投影编码器 才能把 768×1344 塞进 16GB；ComfyUI 原生走 32B NVFP4 TE + DynamicVRAM，编码阶段会把 TE 短暂灌满显存（HF #6：TE 编码时 VRAM 15,219 MiB），然后把 TE 踢回主机、DiT 进来。这是 16GB 上「能跑但 RAM 回不来」的根因。

12GB 也能跑 1MP，但 15s 往往要分段

来源硬件任务结果
shiqikuangsan31 12GB Guide12GB（4070 SUPER / 3060）1280×736（0.94MP）5s / 20 步 1006s（16.8 分钟）；Turbo 4 步+EasyCache 420s；15s 用 MotionContext 三段 5s 链，不是单次 362 帧
minimaxh3tutorialRTX 3060 12GB +（实测 RAM>43GB）1344×768 × 124 帧，无 Turbo/Sage43 分钟，VRAM 11,649 MiB
ComfyUI 官方博客RTX 3060动态卸载「可本地跑」，未给 1MP×15s 数字

12GB 上 SageAttention 有人测到 更慢 2.5–3×（额外显存加重 offload）。本机 16GB 余量比 12GB 多约 4GB，Sage/Sol 更可能是净加速——4070 Ti SUPER / 4060 Ti 16GB / 5060 Ti 视频都支持这一点。

更低档（只证明「能出片」，不证明 1MP×15s）

2.3 针对 RTX 5060 Ti 的特殊点

本机是 Blackwell SM 12.0 + CUDA 13.2，比 4060 Ti（Ada SM 8.9）更适合 H3 的量化栈：

  1. NVFP4 文本编码器可走原生计算（Ada 上 supports_nvfp4_compute=false，要运行时展开，丢失速度）。
  2. INT8 convrot + cu130 是 Comfy-Org 官方优先路径（「能用 int8_convrot 就别用 fp8_scaled」）。
  3. SageAttention / Sol-Attn 对 SM 12.x 有内核；KJNodes 在只有 sm89 轮子时会静默回退到 compile，5060 Ti 应尽量装 sm_120 的 Sage 轮子。
  4. Byron 的 NVFP4 Fused MLP 标明「仅 Blackwell」。本机若改用 NVFP4 DiT 才能吃到这颗节点；当前主流仍是 INT8 convrot，不必为 Fused MLP 换权重。

劣势：5060 Ti 算力和带宽大约只有 5070 Ti 的一半，Byron 那条 18 分钟的 15s 片子在本机很可能变成 30–45 分钟（14–20 步） 或 15–25 分钟（turbo 8 步 + Spectrum）。

3. ComfyUI 运行方案与现有启动脚本评估

3.1 官方与社区对启动参数的共识（2026-08 文档）

ComfyUI 现行 Startup Flags（与本调研同期）：

参数官方含义对 H3 + 16GB/32GB RAM 的实际影响
--lowvramDynamicVRAM 开启时无效果；否则把 TE 放到 CPUNVIDIA 上 DynamicVRAM 默认开，v2/v4 里的 --lowvram 基本是空操作。真正干活的是工作流里的 LowVRAM Attention / ChunkFF。
--fast-disk优先磁盘支撑的动态加载，而不是 unpinned RAM；适合快 NVMe本机最重要的旗标之一。 HF #6：RSS 45.4 → 12.6 GiB。32GB 机器不加这个，权重匿名副本会把 RAM 打满再进 swap。
--cache-none每次重跑所有节点不降低权重占用（HF #6 对照实验：45.1 vs 45.4 GiB）。会强迫 32B TE 每次重编码，重抽卡极慢。H3 Wiki 明确写 Never add cache none。
--disable-smart-memory激进卸载到普通 RAM，而不是尽量留在 VRAM在 31GB RAM 的 3090 案例里被点名「让 OOM 更糟」。AMD 上有人靠它避免 WDDM 抖动，NVIDIA+DynamicVRAM 上不要开。
--disable-pinned-memory禁止页锁定Linux 默认钉 90% RAM。tonyd2wild：31GB RAM 上 不加则内核 OOM killer，加上则 15s@832×480 在 3090 跑完。本机 32GB 建议加。
--reserve-vram给 OS/桌面留显存无头服务器 1.0GB 合理；有桌面/浏览器共用 GPU 时 1.5GB。
--use-sage-attention全局 Sage与 KJNodes Patch Sage Attention 不要同时开。官方教程两种二选一。
--force-fp16全局 fp16可留。Sage 要求 fp16/bf16；H3 部分层会回退 PyTorch attention，日志可忽略。
--cache-lru 20缓存最多 20 个节点输出对重抽卡有用；32GB 上比 --cache-none 健康。默认可改用 --cache-ram。
--preview-method none关闭采样预览正确，省 VRAM/时间。

--fast-disk 的机制（Tomiigo / HF #6）：把权重从 不可回收的匿名内存 挪到 可回收的 page cache。OS 缺 RAM 时丢 cache、再从 NVMe 读回。匿名内存不够就只能 swap 或被 OOM killer 杀掉。本机有 NVMe + 72GB swap，但 swap 救不了 pinned memory——所以顺序是：先 --fast-disk，再 --disable-pinned-memory，swap 只作最后安全网。

3.2 评估现有 v2 / v3 / v4 脚本

上下文中的演进：

脚本参数要点评价
start_comfyui_optimized.sh / v2--lowvram --force-fp16 --reserve-vram 1.5 --use-sage-attention --cache-lru 20 --preview-method none作为 16GB 基线合理；缺 --fast-disk，在 32GB RAM 上跑 42.5GB 模型族会把 RSS 顶到 40GB+。--lowvram 在 DynamicVRAM 下无效但无害。
v3v2 + --vram-headroom 2 --fast-disk --cache-none --disable-smart-memory用户自己标了「过于激进」，判断正确。--fast-disk 该留；--cache-none 只伤重跑、不省权重 RAM；--disable-smart-memory 把压力推向 32GB RAM，是反向优化。--vram-headroom 非当前官方主文档旗标，收益不明。
v4（当前推荐档）v2 + --fast-disk，--reserve-vram 降到 1.0方向对。 --fast-disk 是 32GB 机器的关键补丁；无头机把 reserve 从 1.5 降到 1.0 能多给采样 ~0.5GB，合理。仍缺 --disable-pinned-memory。

环境变量 PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:512,expandable_segments:True 与 OMP_NUM_THREADS=4 应保留。H3 长序列很容易把显存打成碎片，expandable_segments 能减少「还有 1GB 却 OOM」的假碎片。

3.3 建议的启动组合（针对这台 5060 Ti + 32GB）

在 v4 基础上只做两处手术：

export PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:512,expandable_segments:True
export OMP_NUM_THREADS=4

python main.py \
  --listen 0.0.0.0 --port 8189 \
  --force-fp16 \
  --reserve-vram 1.0 \
  --use-sage-attention \
  --fast-disk \
  --disable-pinned-memory \
  --cache-lru 20 \
  --preview-method none

说明：

3.4 工作流分辨率与帧数设置

4. 预计生成速度与瓶颈

4.1 本机 0.5MP × 15s 的速度锚点（需用比例外推）

上下文只确认「0.5MP×15s 已跑通（turbo LoRA + 8 步 + Spectrum + SolAttn + Sage + LowVRAM 分块 + ChunkFF）」，没有给出秒数。下面先用同档公开实测把 0.5MP×15s 反推一个区间，再外推 1MP。

相近锚点：

锚点规格时间折算到本机的含义
YouTube 5060 Ti 16GB0.4MP × 4s，有 Sage145s同卡、短片
neng320 4060 Ti 16GB0.42MP × 5s，pruned，8–12 步~109sAda 卡，略慢于 Blackwell
neng320 转引 5060 Ti8 步 / 20 步154s / ~190s更像 480p 短片
Reddit 4070 Ti SUPER 16GB0.71MP × 5s，20 步，无音频5m58s更强 Ada 16GB，官方步数
5090 无卸载0.5MP × 8s，25 步257s算力上限参考，不是 16GB 曲线
Byron 5070 Ti 16GB0.94MP × 15s，14 步1064s最像目标任务

粗算本机 0.5MP × 15s / turbo 8 步 + Spectrum 很可能落在：

若用户手头有那次跑的 ComfyUI 历史时间，应用实测值替换本节；后文倍数关系仍然成立。

4.2 1MP 相对 0.5MP 的增长（同 15s）

Token 比：

tokens ≈ (W/32) × (H/32) × (frames/4)

0.5MP  960×544 × 362f  ≈ 30 × 17 × 90.5 ≈ 46,155
1.03MP 1344×768 × 362f ≈ 42 × 24 × 90.5 ≈ 91,224
空间 token 比 ≈ 1.98×

时间为什么不是单纯 2 倍：

部分随 token 的标度1MP / 0.5MP
DiT FFN（H3 主体参数）近似线性~2.0×
Attention（未分块 SDPA）近似二次~4×
Sage / Sol 分块 attention介于 1.5–3×实测更接近 2–3×
权重 offload / NVMe 回流每层每步几乎恒定若已是带宽瓶颈，总时间增量会 小于 2×
VAE decode像素 × 帧，线性~2.0×
文本编码（32B）与视频分辨率无关~0 增量（但占冷启动）

无卸载、算力打满（5090，8s，25 步）时，0.5MP → 1.0MP 是 257s → 829s = 3.22×（超线性，attention 仍有二次成分）。
16GB 卸载档时，neng320 4060 Ti：0.42MP 109s → 1.03MP 360s ≈ 3.3×（同为 5s）。Diffusers 4060 Ti：768² 5s 25 分钟 → 768×1344 5s 66 分钟 ≈ 2.6×。

综合：在本机这套「Sage + Sol + ChunkFF + turbo 8 + Spectrum + fast-disk」下，同 15s、0.5MP → 1MP 的墙钟时间建议按 2.2–3.2× 估，显存峰值按 +0–2 GB 估（卸载钉住权重，激活分块压尖峰）。

项目0.5MP × 15s（已跑通）1.03MP × 15s（目标）
视觉 token~4.6 万~9.1 万（×2.0）
峰值 VRAM（DynamicVRAM + 分块）估计 12–15 GB估计 13–16 GB（尖峰风险在 FFN/Attn/VAE）
峰值 RAM（有 --fast-disk）匿名 RSS ~12–18 GB + page cache基本同左；cache 仍约 40GB 可回收
峰值 RAM（无 --fast-disk）40–50 GB → 必进 swap同左，与分辨率几乎无关
时间（turbo 8 + Spectrum）假设 12–20 分钟约 25–50 分钟（×2.2–3.2）
时间（20 步官方、无 Spectrum）很可能 25–40 分钟45–90 分钟，体验上接近「不能当生产」
对照：5070 Ti 0.94MP×15s 14 步—18 分钟；本机约 1.8–2.2× → 32–40 分钟（14–20 步）

秒/帧（仅便于直觉，H3 按 latent 步走，不是逐帧扩散）：

4.3 瓶颈排序（这台机器）

  1. 系统内存 32GB（第一约束）
    无 --fast-disk 时 pruned 全家桶 RSS ~45GB，超过物理内存。TE 的主机副本 卸载后也不会释放（HF #6 采样：idle 7.3 → TE 24.1 → DiT 45.6 → VAE 51.0 GiB）。72GB swap 能避免立刻被杀，但一进 swap，速度会从「分钟」掉到「不可用」。
    对策：--fast-disk + --disable-pinned-memory + 图中 RAM cleanup；不要同时加载 FL2VA 和 Ref2VA。
  2. 1MP×15s 激活尖峰（第二约束，表现为 VRAM OOM）
    权重流式后峰值看似只有 14GB，但 9 万 token 的 FC1/attention 临时张量可以再要 4–6GB。Byron 就是靠 16gb_chunked 才把 15s 跑完。
    对策：ChunkFF 保持开启；LowVRAM Attention head_chunks 提到 2–4；必要时关音频 decode 试采样（不保证省采样期音频 latent）。
  3. 速度 / NVMe 回流（第三约束）
    16GB 无法常驻 21GB DiT，每层每步可能读盘。Tomiigo 在 8GB cap 上测到单次任务 读盘 270GB。本机 NVMe 剩余 705GB，带宽足够当内存层次，但 5060 Ti 的 PCIe 和 448-class 显存带宽仍会让 1MP×15s 停在「数十分钟/条」。
    这不是 OOM，是产能问题：按 30 分钟/条，一天有效工作 8 小时大约 16 条。
  4. H3 分辨率限制（产品约束，不是硬件）
    本地开源权重 不能出 2K。1MP 已经是 H3-Base 画布顶点；再往上只会报错或被裁到 768×1344 面积内。想 2K 只能等开源 Regenerate-2K，或走官方 API。
  5. VRAM 绝对容量（第四）
    16GB 在分块开启时 不是 1MP×15s 的主杀手——12GB 都跑过 1344×768×5s。只有分块关闭、或 TE+DiT+VAE 试图同时驻留时才会爆。

5. 若 1MP × 15s 跑不动：降级阶梯

按「尽量接近目标」排序，不要一次砍两维。

阶梯 A — 先保 15s，降一点分辨率（推荐首选）

档分辨率MP预期相对 0.5MP×15s用途
目标1344×7681.03×2.2–3.2 时间，VRAM 尖峰风险最高成片
推荐折中1280×7360.94约 ×2.0–2.8；Byron 15s 就是这个面积接近 720p，16GB 已有完跑先例
甜点1152×6400.74约 ×1.5–2.0；5090 上 0.7MP 是「最佳价值档」质量/时间比最好
已跑通960×5440.521.0×抽卡、对 prompt

阶梯 B — 先保 1MP，缩短时长

时长帧数相对 15s token说明
15s3621.00×目标
10s2440.67×仍在训练范围内，显存尖峰明显下降
8s1920.53×5090 1MP 要 14 分钟；本机估计 20–35 分钟（8 步会更快）
5s1240.34×4060 Ti 16GB 已有 1344×768 ~6 分钟（pruned 8–20 步）

5s @ 1344×768 是 16GB 上把握最大的「满画布」规格。 再要 15s，用阶梯 D 的分段。

阶梯 C — 量化 / 采样降档（硬件不变）

  1. 保持 pruned INT8，把 turbo 8 步改 turbo 4 步（速度再翻倍，运动/音频风险上升）。
  2. head_chunks 2 → 4，ChunkFF 更细：换稳定性，不换分辨率。
  3. 关 Spectrum / EasyCache，改用 CAB-14（Byron 15s 验证链）：步数少但比乱跳 cache 更可控。
  4. DiT 换 GGUF Q4_K / Q5（Unsloth：16–24GB 建议 Q5/Q6；12–16GB 建议 Q3/Q4）。画质低于官方 INT8，作为 OOM 逃生口。
  5. TE 换更小 GGUF（Q2_K ~8GB）或 ClipProj 4B：只在 TE 编码阶段 OOM 时用。

阶梯 D — 分段 15s（12GB 指南的成熟做法）

单次只生成 5s @ 1280×736 或 1344×768（本机很稳），用 MotionContext / latent 延续链 接 3 段：

代价：段间仍可能漂（角色/光线）；12GB 指南声称角色一致性可用。音频需要单独拼接或只在最后一段出声。

这比「单次 362 帧硬冲」更像 16GB 的生产策略：满画布 5s 抽卡，确认后再链 15s。

阶梯 E — 换运行时（ComfyUI 搞不定时）

建议的本机实操顺序

  1. 用 §3.3 启动参数 重启 ComfyUI，确认 nvidia-smi 空闲、free -h 在加载后匿名内存不要长期 >28GB。
  2. 先复现一条 0.5MP × 15s，记下端到端秒数（这是外推 1MP 的唯一真实锚）。
  3. 只改分辨率到 1280×736 × 15s（0.94MP，Byron 同规格）。head_chunks=2，ChunkFF 开。
  4. 成功再上 1344×768 × 15s。若 VRAM OOM：先加 head_chunks=4，再关音频 decode 对比是不是 VAE 阶段炸的。
  5. 若 RAM 被杀 / 疯狂 swap：确认 --fast-disk 与 --disable-pinned-memory 生效；不要开 v3 的 --cache-none。
  6. 仍失败：退到 1344×768 × 5s 或 1152×640 × 15s，15s 用 MotionContext 三段链。

6. 总表：这台 5060 Ti 16GB + 32GB RAM 的定位

规格可行性主要风险粗估时间（turbo 8 + Sage/Sol + Spectrum，预热后）
0.4–0.5MP × 5s稳无2–4 分钟
0.5MP × 15s已跑通RAM（无 fast-disk）约 12–20 分钟（待用本机日志替换）
0.74MP × 15s（1152×640）高激活尖峰约 18–35 分钟
0.94MP × 15s（1280×736）高（有 16GB 完跑先例）激活尖峰、速度约 25–45 分钟
1.03MP × 15s（1344×768）中高（容量上限档）FFN/Attn/VAE 尖峰、32GB RAM、30 分钟+约 30–55 分钟
1MP × 5s（1344×768）高较小约 6–12 分钟
本地 2K不可行Regenerate-2K 未开源—

最终判断：在指定硬件上，MiniMax H3 可以生成约 1MP × 15s 的视频，前提是：

  1. 继续用 pruned INT8 + NVFP4 TE，不要上 BF16；
  2. 启动参数以 v4 为底，加 --disable-pinned-memory，去掉 v3 的 --cache-none / --disable-smart-memory；
  3. 工作流保留 分块注意力 + ChunkFF + turbo 8 步；分辨率用 1344×768 或 1280×736，避开非法的 1280×720 和 Selector 1.0 MP；
  4. 接受 每条 15s 成片大约半小时量级，并把 32GB RAM 当作比 16GB VRAM 更需要盯着的资源。

若第一次 1344×768×15s 失败，优先怀疑 激活分块不够 或 RAM/pinned，而不是「16GB 绝对跑不动这个模型」。12GB 卡已经跑过满画布 5s，16GB Blackwell 卡已经跑过近 1MP 的 15s。

7. 主要信息源（交叉验证）

官方 / 框架

16GB / 12GB 实测

速度与量化

环境上下文

本报告为公开资料交叉验证，不是在目标机器上新跑的 1MP×15s 实测。建议按 §5 实操顺序用一条 1280×736×15s 作业给出本机墙钟时间与 nvidia-smi / free -h 峰值，再决定是否冲 1344×768。

下载此文件