# 07 · 模型加速与工程化

模型选对只是第一步。同样一张 4090，"原生跑"和"工程化跑"的差距是 5–10 倍，甚至决定跑不跑得起来。这一层全是把不可能变可能的东西。

---

## 1. 量化与低精度：nunchaku

| 项目 | ★ | 协议 | 最近提交 |
|---|---|---|---|
| `mit-han-lab/nunchaku` | 3,963 | Apache-2.0 | 2026-09-06 |

**做什么**：SVDQuant 的官方实现，把扩散模型权重压到 **4-bit**，同时用低秩分支吸收量化误差，画质损失极小。

**为什么重要**：Wan2.2-A14B 这类模型 fp16 要 28 GB 权重，4-bit 后约 7 GB——**原本 24G 卡要 offload 跑十几分钟，量化后可以常驻显存，速度提升 2–3 倍**。视频模型比图像模型更吃这个：显存带宽是瓶颈，权重变小等于带宽变大。

**门槛**：需要特定架构（Blackwell 优化最好，Ada 也支持）；量化权重需自行转换或用社区发布版。
**短板**：不是所有模型都有现成量化包；4-bit 在细纹理和文字渲染上仍有可见劣化。

---

## 2. 注意力加速：SageAttention

| 项目 | ★ | 协议 | 最近提交 |
|---|---|---|---|
| `thu-ml/SageAttention` | 3,988 | Apache-2.0 | 2026-01-17 |

**做什么**：把注意力的 QK^T 用 INT8/FP8 计算，其余保持高精度，端到端 2–5 倍加速，画质基本无损。

**视频模型为什么最受益**：视频注意力的序列长度是图像的数倍到数十倍，注意力占比从 30% 涨到 60%+，优化它的回报最高。

**用法**：ComfyUI 里 `--use-sage-attention` 启动参数即可（需要先装 wheel）；HunyuanVideo/Wan 官方脚本也都支持替换。
**短板**：需要匹配 CUDA 版本和显卡架构，装不上就是装不上（编译失败是最常见的问题）。

---

## 3. 缓存复用：TeaCache

| 项目 | ★ | 协议 | 最近提交 |
|---|---|---|---|
| `ali-vilab/TeaCache` | 1,387 | Apache-2.0 | 2025-06-08 |

**做什么**：扩散去噪过程中相邻时间步的输出高度相似，TeaCache 判断"这步可以跳过"，直接复用上一步的残差。

**效果**：1.5–2 倍加速，代价是细节轻微损失；对 Wan、HunyuanVideo 都有现成配置。
**适用**：批量出草稿时开，终稿关。和其他加速手段（SageAttention、量化）**可以叠加**。

---

## 4. 多卡并行：xDiT

| 项目 | ★ | 协议 | 最近提交 |
|---|---|---|---|
| `xdit-project/xDiT` | 2,748 | Apache-2.0 | 2026-11-03 |

**做什么**：DiT 模型的并行推理引擎，支持 USP（序列并行）、PipeFusion（流水线）、CFG 并行、Tensor 并行。

**什么时候需要**：单卡跑不动 30B/24B 级模型（Step-Video、MAGI-1、HunyuanVideo 原生精度）时，用 2–8 张卡把序列切开。
**短板**：多卡通信有开销，2 卡大约 1.7 倍而不是 2 倍；部署复杂度陡增。

---

## 5. 统一的加速/后训练框架：FastVideo

| 项目 | ★ | 协议 | 最近提交 |
|---|---|---|---|
| `hao-ai-lab/FastVideo` | 4,777 | Apache-2.0 | 2026-11-03 |

**做什么**：把"推理加速 + 蒸馏 + 后训练"打包成一个框架，支持 Wan、Hunyuan 等模型的蒸馏版（少步数出片）。

**价值**：蒸馏模型 4–8 步就能出片，配合量化可以在消费卡上做到"一分钟内出一条"。这是 2026 年最实际的速度来源。
**短板**：蒸馏版画质与运动幅度有折损，题材适配需要试。

---

## 附加：上下文并行 ParaAttention

`chengzeyi/ParaAttention`（436★，自定义许可）：把长序列注意力切到多卡上算，是 xDiT 之外的另一种并行思路，适合做"单条超长视频"而不是"高吞吐批量"。

---

## 6. ComfyUI 生态：真正决定生产力的一层

| 项目 | ★ | 协议 | 作用 |
|---|---|---|---|
| `comfyanonymous/ComfyUI` | 144,745 | GPL-3.0 | 底座 |
| `Comfy-Org/ComfyUI-Manager` | 16,711 | GPL-3.0 | 插件/模型管理器，装节点必备 |
| `mcmonkeyprojects/SwarmUI` | 4,741 | MIT | ComfyUI 的上层 UI，多用户/队列/模型管理更规整 |
| `kijai/ComfyUI-WanVideoWrapper` | 6,806 | Apache-2.0 | Wan 系高级功能：长视频拼接、LoRA 组合、分块生成 |
| `kijai/ComfyUI-HunyuanVideoWrapper` | 2,592 | 未声明 | HunyuanVideo 的封装，支持多种量化后端 |
| `Kosinkadink/ComfyUI-VideoHelperSuite` | 1,909 | GPL-3.0 | 视频读写、帧提取、批处理，几乎所有视频工作流都依赖它 |
| `Fannovel16/ComfyUI-Frame-Interpolation` | 1,093 | MIT | 补帧节点（RIFE/FILM），把 16fps 补到 32/60 |
| `comfyanonymous/ComfyUI_bitsandbytes_NF4` | 424 | AGPL-3.0 | NF4 量化加载，显存不够时的兜底 |

**装节点的顺序建议**：Manager → VideoHelperSuite → 对应模型的 Wrapper → Frame-Interpolation。先能跑通再谈优化，反过来的顺序会让人怀疑人生。

---

## 7. 显存优化矩阵（按卡选策略）

| 显存 | 模型 | 策略组合 | 预期速度 |
|---|---|---|---|
| 8 GB | Wan2.1-1.3B / LTX-2B | fp16 + `--lowvram` | 慢，可用 |
| 8 GB | Wan2.2-TI2V-5B | NF4/GGUF Q4 + TeaCache | 5s 720P 约 15 分钟 |
| 12 GB | Wan2.2-TI2V-5B | fp8 + SageAttention + TeaCache | 5s 720P 约 8 分钟 |
| 16 GB | LTX-13B | fp8 + block swap | 5s 720P 约 10 分钟 |
| 24 GB | Wan2.2-A14B | **nunchaku 4-bit + SageAttention** | 5s 720P 约 6–10 分钟 |
| 24 GB | HunyuanVideo-13B | GGUF Q5 + offload | 5s 720P 约 20 分钟 |
| 48 GB | Wan2.2-A14B | fp8 常驻 | 5s 720P 约 4–5 分钟 |
| 80 GB | HunyuanVideo-13B | fp16 原生 | 5s 720P 约 3 分钟 |
| 多卡 | Step-Video-30B / MAGI-1 | xDiT USP + fp8 | 随卡数线性(打折) |

> 这些是量级估算，实际取决于分辨率、帧数、步数和采样器。第 10 篇给了自测脚本，用你自己的素材跑一遍比看任何表格都准。

---

## 8. 工程化的五条硬规则

1. **先降步数，再降精度，最后 offload**。offload 的代价最大（PCIe 往返），能不用就不用。
2. **VAE 解码单独算显存预算**。很多人卡在最后一步 OOM，是 VAE 解码爆的，用 tiled VAE 解决。
3. **固定种子 + 固定参数做基线**，任何优化后跑同一条提示词对比，否则"感觉快了"不可靠。
4. **批处理比并行更划算**：同一模型连续跑 20 条，比同时跑 4 条更快（显存碎片和调度开销）。
5. **模型放 NVMe**。14B 模型从机械盘加载要几分钟，直接吃掉你的迭代节奏。
