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

- **调研日期**：2026-08-24
- **目标机器**：远程服务器 `zywpc`（RTX 5060 Ti 16GB / 32GB RAM / 72GB swap / NVMe / Ubuntu / ComfyUI 已部署）
- **目标规格**：约 1MP（约 100 万像素，如 1344×768 或 1280×720）× 15 秒，24fps
- **结论先行**：**能跑，但是「容量上限档」而不是「舒适生产档」。** 在当前这套量化 + 动态卸载 + 分块注意力/FFN 的组合下，1MP × 15s **单次前向生成在 16GB 上已被社区实测完跑**；真正更紧的约束是 **32GB 系统内存** 和 **时间（约 15–40 分钟/条）**，而不是「显存绝对装不下」。

---

## 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](https://github.com/MiniMax-AI/MiniMax-H3)、[MiniMaxAI/MiniMax-H3](https://huggingface.co/MiniMaxAI/MiniMax-H3)）给出的输出规格：

- 时长：4–15 秒
- 帧率：24 fps
- 默认短边：**768 px**
- 2K：需 H3-Regenerate-2K（未开源）
- 音频：32 kHz stereo
- 两种权重：`FL2VA`（文生 / 首尾帧）与 `Ref2VA`（参考图/视频/音频），**不能混用同一份 DiT**

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

HuggingFace Diffusers 文档写明：

- `canvas_short_edge` 默认 **768**
- `canvas_max_pixels` 默认 **1,032,192**（即 **768 × 1344 ≈ 1.03 MP**）
- 宽高必须是 **32 的倍数**
- 帧数会向上对齐到视频 VAE 可解的 `17n + 5`：73 / 90 / 107 / 124 / … / **362（15.08s）**
- 训练范围上限约 **124–362 帧（约 5–15 秒）**

ComfyUI 官方教程（[docs.comfy.org MiniMax H3](https://docs.comfy.org/tutorials/video/minimax/minimax-h3)）额外强调：

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

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

| 目标 | 像素 | 是否 32 对齐 | 相对画布 | 建议 |
|---|---|---|---|---|
| **1344×768** | 1.032 MP | 是 | **正好打满上限** | 16:9 成片首选 |
| 1280×736 | 0.942 MP | 是 | 约 91% | 更稳的「接近 720p」 |
| **1280×720** | 0.922 MP | **否（720÷32=22.5）** | — | **不要用**，节点会报错或被改尺寸 |
| 1152×640 | 0.737 MP | 是 | 约 71% | 质量/时间甜点（社区称 0.7MP 档） |
| 960×544 | 0.522 MP | 是 | 约 51% | 本机已跑通的 0.5MP 档 |
| 864×480 | 0.415 MP | 是 | 约 40% | 官方模板默认预览档 |
| 1024×1024 | 1.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×B300 | BF16 或在线 FP8 | 单卡峰值约 50–94 GB |
| 双卡消费级 | 2×RTX 5090 + SGLang layerwise offload | — | 约 26.3 GiB/卡 |
| Diffusers 文档 | 80GB 单卡 / 24–32GB 消费卡 INT8 + group offload | INT8 | **12–16GB 需再卸载 VAE，权重常驻主机内存约 75GB（INT8）** |
| ComfyUI 官方博客 | pruned INT8 把足迹从 **123.6GB → 42.5GB**，配合 DynamicVRAM，**RTX 3060 可本地跑** | pruned INT8 + NVFP4 | 「可跑」≠「快」 |

权重体积（Comfy-Org 重打包，[HuggingFace Comfy-Org/MiniMax-H3](https://huggingface.co/Comfy-Org/MiniMax-H3)）：

| 组件 | BF16 | INT8 convrot | **pruned INT8（推荐）** | NVFP4 |
|---|---|---|---|---|
| DiT FL2VA / Ref2VA | 61.7 GB | 31.7 GB | **~19.5–21 GB** | pruned FP8 同约 21 GB |
| Qwen3-VL-32B 文本编码器 | 48–62 GB | 25.3 GB | — | **~14.6–15.7 GB** |
| Video VAE fp16 | 4.9–5.2 GB | 同左 | 同左 | 同左 |
| Audio VAE fp32 | 0.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 MP | 736×416 | ~125 s（2.1 分钟） | **约 31.7 GB，三档权重几乎相同** |
| 0.5 MP | 960×544 | ~257 s（4.3 分钟） | 同上 |
| 0.7 MP | 1152×640 | ~446 s（7.4 分钟） | 同上 |
| 1.0 MP | 1376×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.com | RTX 3060 12GB | 512×288 × 22 帧 | 11,591 MiB | 43.2 GB |
| 同上（同机） | RTX 3060 12GB | **1344×768 × 124 帧** | **11,649 MiB（+58 MiB，+0.5%）** | 43.6 GB |
| Tomiigo / HF 讨论 #6 | RTX 5070 Ti 16GB | 5s @ 1344×768 | 14,437 MiB | — |
| 同上 | RTX 5070 Ti 16GB | 30s @ 640×480 | 14,197 MiB | — |
| ByronLeeeee | RTX 5070 Ti 16GB | 1280×736 × 5s × 20 步 + Sage | **已分配峰值 3.8–5.1 GB**（不含桌面/碎片） | — |
| neng320 | RTX 4060 Ti 16GB | 生产档 | ~14 GB | ~44 GB |
| animede Diffusers | 真 4060 Ti 16GB | 768² t2va 5s | 11.4 GB | 需投影 TE |
| animede Diffusers | 真 4060 Ti 16GB | **768×1344 5s** | **13.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 就不要用 FP8 | FP8 在 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 / 文件切片，而不是匿名 RSS | **32GB RAM 几乎刚需** | 每步从 NVMe 回流；NVMe 够快则可接受 |
| **`--disable-pinned-memory`** | Linux 默认钉住 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/Q4** | DiT 再压到 ~10–16GB | 本机有 ComfyUI-GGUF，作 **OOM 后备** | 画质低于官方 pruned INT8；部分报告 I2V 异常 |
| **ClipProj / 4B 投影 TE** | 用 Qwen3-VL-4B 代替 32B | Diffusers 16GB 路线的关键，ComfyUI 非必须 | 语义条件变弱 |
| **WanGP 低显存实现** | 5–6GB / 5s，8–9GB / 15s @ 832×480 | 可作「一定要出片」的平行通道 | 分辨率/生态与 ComfyUI 原生节点不同 |

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

- **TE-Speed**：4060 Ti 16GB 实测文字乱码/结构失真（neng320 明确弃用）。
- **EasyCache 阈值过高**：ComfyUI issue #15326 报告 H3 音频劣化。
- **再降 GGUF 到 Q2**：能塞进 8–12GB，但速度/质量都不适合成片。
- **BF16 满血**：本机 RAM/VRAM 都不够，不要试。

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

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

#### 最接近：Blackwell 16GB

| 来源 | 硬件 | 内存 | 任务 | 结果 | 证据等级 |
|---|---|---|---|---|---|
| **ByronLeeeee Optimization Suite** | RTX **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-16gb | 5070 Ti 16GB（无约束） | 32GB 内核 cap 或 125GB | length=243 全分辨率参考视频 | **1027s**，峰值 **14.5–15.6 GB**（含桌面） | 高 |
| HuggingFace Comfy-Org #6（UdonJP） | 5070 Ti 16GB | 125GB | 5s @ 1344×768 vs 30s @ 640×480 | VRAM 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 RAM | 64GB | 4s @ 0.4MP；Sage 使迭代从 ~12s → ~8s | 4s 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 RAM** | pruned INT8，T8 8 步 | 864×480 5s ~**109s**；1056×608 ~**180s**；**1344×768 5s ~360s**；显存 ~14GB，内存 ~44GB |
| Reddit r/comfyui `1vflhue` | RTX **4070 Ti SUPER 16GB** + 32GB RAM | pruned 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=group` | t2va 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 Guide | 12GB（4070 SUPER / 3060） | **1280×736（0.94MP）** | 5s / 20 步 **1006s（16.8 分钟）**；Turbo 4 步+EasyCache **420s**；**15s 用 MotionContext 三段 5s 链，不是单次 362 帧** |
| minimaxh3tutorial | RTX 3060 12GB +（实测 RAM>43GB） | **1344×768 × 124 帧**，无 Turbo/Sage | **43 分钟**，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）

- WanGP：5–6GB 跑 5s（124 帧）；**8–9GB 跑 15s @ 832×480**（deepbeepmeep / cocktailpeanut）。
- 8GB 4060 Ti：640p 5s 约 12–20 分钟。
- 8GB 5060 Laptop：15s 只能 864×480；10s 约 540p；5s 才到约 720p。
- Tomiigo 在 5070 Ti 上用 sidecar **人工封顶 8GB**，640×384 × ~9.4s 跑完，但那是低分辨率。

### 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](https://docs.comfy.org/development/comfyui-server/startup-flags)（与本调研同期）：

| 参数 | 官方含义 | 对 H3 + 16GB/32GB RAM 的实际影响 |
|---|---|---|
| `--lowvram` | **DynamicVRAM 开启时无效果**；否则把 TE 放到 CPU | NVIDIA 上 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 下无效但无害。 |
| **v3** | v2 + `--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 基础上只做两处手术：

```bash
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
```

说明：

- **去掉 `--lowvram`**：官方写明 DynamicVRAM 下无效；避免误以为「已经在 lowvram 模式」。真正的 lowvram 在图里做。
- **去掉 `--cache-none` / `--disable-smart-memory`**：v3 的两个有害项。
- **加上 `--disable-pinned-memory`**：32GB Linux 的第二刚需。若发现速度明显变差且 `free -h` 显示大量 RAM 空闲，可以再拿掉对比。
- **不要同时**再在图里放一层全局 Sage patch（`--use-sage-attention` 已开）。KJNodes 的 MiniMax 专用 `MemoryEfficientSageAttentionPatch` / SolAttn 节点是 **H3 图级**优化，与全局旗标的职责不同，可保留图级节点。
- 工作流侧保持：`pruned_int8_convrot` + `nvfp4_awq` + turbo 8 步 + Spectrum + SolAttn + LowVRAM Attention（1MP 时 `head_chunks` 提到 2 或 4）+ ChunkFF。
- 若仍 OOM：把 Spectrum 历史存 CPU、VAE 前后加 VRAM/RAM cleanup 节点（Civitai Spectrum 工作流把 RAM 从 ~50GB 降到 ~30GB）。

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

- 时长填 **15**，确认节点对齐到 **362 帧**（`17×21+5`），24fps → 15.08s。
- 16:9 成片：**1344 × 768**，或 Selector `0.98 MP`。
- 接近 720p：**1280 × 736**（不要 1280×720）。
- `ref_image_size` 用 `match`（`max` 会把参考图短边拉到 2048，参考视频全分辨率曾在 8GB cap 上直接 OOM）。
- R2V 必须加载 `ref2va_*` 权重；T2V/I2V 用 `fl2va_*`。

---

## 4. 预计生成速度与瓶颈

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

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

相近锚点：

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

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

- **乐观**：8–12 分钟（Spectrum 跳步 + Sage/Sol 都生效，且权重已在 page cache）
- **中位**：12–20 分钟
- **冷启动第一次**：再加 3–8 分钟（Sage/Triton JIT + 21GB 权重进 cache）

若用户手头有那次跑的 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 步走，不是逐帧扩散）：

- 15s = 362 帧
- 若 1MP 端到端 30 分钟 → **约 5.0 s/帧 墙钟**（含编码/采样/VAE/封装）
- 若 18 分钟（5070 Ti 对照）→ 约 3.0 s/帧
- 采样环本身：20 步时每步要扫完整 33B 栈；turbo 8 步把这部分砍到 40%，Spectrum 再跳过部分 actual step

### 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×768 | 1.03 | ×2.2–3.2 时间，VRAM 尖峰风险最高 | 成片 |
| **推荐折中** | **1280×736** | 0.94 | 约 ×2.0–2.8；Byron 15s 就是这个面积 | 接近 720p，16GB 已有完跑先例 |
| 甜点 | 1152×640 | 0.74 | 约 ×1.5–2.0；5090 上 0.7MP 是「最佳价值档」 | 质量/时间比最好 |
| 已跑通 | 960×544 | 0.52 | 1.0× | 抽卡、对 prompt |

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

| 时长 | 帧数 | 相对 15s token | 说明 |
|---|---|---|---|
| 15s | 362 | 1.00× | 目标 |
| 10s | 244 | 0.67× | 仍在训练范围内，显存尖峰明显下降 |
| 8s | 192 | 0.53× | 5090 1MP 要 14 分钟；本机估计 20–35 分钟（8 步会更快） |
| 5s | 124 | 0.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 段：

- 段 1：T2V 5s → SaveLatent  
- 段 2–3：MotionContext 延续 + 重叠帧  
- ffmpeg 裁 pinned 帧后拼接  

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

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

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

- **WanGP**：15s @ 832×480 只需 8–9GB，作为保底出片。
- **Diffusers + 投影 TE + `H3_LOWVRAM=group`**：4060 Ti 实测 768×1344 5s 能跑，但要 66 分钟，且是 5s。
- 官方 API / Comfy Cloud：要 2K 或要量产时的务实出口。

### 建议的本机实操顺序

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. 主要信息源（交叉验证）

**官方 / 框架**

- [MiniMax-AI/MiniMax-H3](https://github.com/MiniMax-AI/MiniMax-H3) 与 [MiniMaxAI/MiniMax-H3](https://huggingface.co/MiniMaxAI/MiniMax-H3) 模型卡：时长、768p 默认短边、2K 未开源、4×GPU SGLang 示例
- [HuggingFace Diffusers MiniMax-H3](https://huggingface.co/docs/diffusers/en/api/pipelines/minimax_h3)：`canvas_max_pixels=1032192`、`17n+5` 帧、12–16GB 需 VAE offload、960×544 比 1344×768 每步快约 2.3×
- [Comfy-Org/MiniMax-H3](https://huggingface.co/Comfy-Org/MiniMax-H3) 与 [Day-0 博客](https://blog.comfy.org/p/minimax-h3-day-0-support-in-comfyui)：42.5GB 最小足迹、RTX 3060、优先 INT8 convrot
- [ComfyUI H3 教程](https://docs.comfy.org/tutorials/video/minimax/minimax-h3)：0.98MP=1344×768，禁止 Selector 1.0MP；Sage 用法
- [ComfyUI Startup Flags](https://docs.comfy.org/development/comfyui-server/startup-flags)：`--lowvram` 在 DynamicVRAM 下无效；`--fast-disk` / `--cache-none` / `--disable-smart-memory` / `--disable-pinned-memory` 定义

**16GB / 12GB 实测**

- [ByronLeeeee/ComfyUI-MiniMax-H3-Optimization-Suite](https://github.com/ByronLeeeee/ComfyUI-MiniMax-H3-Optimization-Suite)：5070 Ti 16GB，**0.94MP×15s 完跑 1064s**
- [Tomiigo/minimax-h3-16gb](https://github.com/Tomiigo/minimax-h3-16gb) 与 [HF Discussion #6](https://huggingface.co/Comfy-Org/MiniMax-H3/discussions/6)：`--fast-disk` 3.6× RAM 差；VRAM 不随分辨率动
- [neng320/minimax-h3-local-deployment](https://github.com/neng320/minimax-h3-local-deployment)：4060 Ti 16GB，1344×768 5s ~360s；内存 ~44GB
- [shiqikuangsan31/MiniMax-H3-12GB-ComfyUI-Guide](https://github.com/shiqikuangsan31/MiniMax-H3-12GB-ComfyUI-Guide)：12GB 上 1280×736；15s 靠分段
- [minimaxh3tutorial.com/vram](https://www.minimaxh3tutorial.com/vram)：3060 12GB，40× 工作量 VRAM +0.5%，RAM >43GB
- [animede/Diffusers_minimax-h3](https://github.com/animede/Diffusers_minimax-h3)：真 4060 Ti，768×1344 5s 顶满 15.2GB
- Reddit r/comfyui：4070 Ti SUPER 16GB + 32GB RAM，5–7 分钟级 5s I2V，无 OOM
- YouTube：RTX 5060 Ti 16GB 本地可跑（短片）

**速度与量化**

- [wan2-7 MiniMax H3 local requirements](https://wan2-7.io/blog/minimax-h3-local-requirements/)：5090 上 0.5MP 257s vs 1.0MP 829s（8s/25 步）；峰值 31.7GB
- [Saganaki22/ComfyUI-sol-attn](https://github.com/Saganaki22/ComfyUI-sol-attn)：ChunkFF −37% MLP 峰值；长 token 上 Sol > Sage ≫ SDPA
- [tonyd2wild/minimax-h3-local](https://github.com/tonyd2wild/minimax-h3-local)：31GB RAM 必须 `--disable-pinned-memory` 才能 15s
- Unsloth / ComfyUI Wiki GGUF 分档：16GB 用 Q3/Q4 或 pruned INT4

**环境上下文**

- `/home/zyw/Downloads/h3-env-context.md`：5060 Ti 16GB、32GB+72GB swap、ComfyUI 模型与 v2/v3/v4 脚本、0.5MP×15s 已跑通

---

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