ComfyUI本地部署MiniMax H3性能优化教程

本教程是《ComfyUI本地部署MiniMax H3消费级显卡文生视频、图生视频教程》的进阶篇，聚焦消费级显卡上 MiniMax H3 视频生成的性能优化。教程先分析消费级显卡的性能瓶颈，再依次讲解分辨率策略、注意力加速（SageAttention 与 comfy kitchen）、20 系显卡的 fp16 强制加速、Turbo 8-step LoRA 加速、TE-Speed 块级缓存加速，以及首尾帧循环与 AddGuide 动作锚定两项实战技术，最后给出调优组合建议与实测性能参考。本版（v1.2）补充了 RTX 2080 Ti（Turing 架构） 实战项目验证的完整优化路线与全套实测数据：20 系显卡用户可全程按实测路线操作，其他架构用户同样适用。

前置教程

如想快速开始学习本教程，你可能需要先完成以下前置教程：

• ComfyUI本地部署MiniMax H3消费级显卡文生视频、图生视频教程，本教程基于已完成部署的 MiniMax H3 与 ComfyUI 环境，先完成部署再进阶调优。
• 本地图像与视频生成模型部署与调用教程，本教程介绍了消费级显卡上视频生成模型的部署思路，是性能优化的背景知识。

资源下载

本教程涉及的全部资源已统一打包，可通过夸克网盘下载：

• resources.zip（夸克网盘），包含 TE-Speed-MiniMaxH3-OSS 加速插件、ComfyUI-MiniMax-H3-LongMedia 低显存节点、MiniMax H3 本地部署指南（16GB 显存）、MiniMax H3 ComfyUI 工作流合集、ComfyUI_MiniMaxH3_Director 工作流仓库、minimax-h3-comfyui 参考生视频节点。
• Turbo LoRA 与封面生成脚本（夸克网盘），包含 Turbo 8-step 加速 LoRA（通用版与 768p 专用版）与 minimax-h3-cover-scripts.zip 封面生成脚本（动态封面 5 秒、首尾帧循环 6 秒含五锚点链两套完整脚本）。
• H3 模型权重（int8 量化扩散模型、nvfp4 AWQ 文本编码器、视频/音频双 VAE）已包含在前置教程的 MiniMax H3 模型网盘下载地址中，无需重复下载。

1. 性能瓶颈分析

1.1 消费级显卡的主要瓶颈

视频生成是显存与算力的双重消耗，在消费级显卡上主要受三方面制约：

1.2 两条优化主线

优化手段可分为提速与省显存两条主线，可叠加使用：

• 提速主线：分辨率策略 + 注意力加速 + 采样步数压缩 + TE-Speed，多手段组合后提速显著
• 省显存主线：Dynamic VRAM 动态卸载 + LongMedia 长视频节点，让 16GB 显卡跑更长时间、更高分辨率

1.3 Turing（20 系）实测叠加路线

原文给出的提速主线「分辨率策略 + SageAttention + TE-Speed ≈ 2.2 倍」中，SageAttention 要求 SM80+，20 系不可用。实测 RTX 2080 Ti 22G 上可用的完整叠加路线为：

实测基准（896×512、22 帧、固定种子）：原始配置（PyTorch 注意力 + 20 步）采样约 83 秒，叠加 comfy kitchen 注意力 + Turbo 8 步后约 21.5 秒，采样合计快约 3.9 倍。

2. 分辨率策略：480p 生产、768p 精选

2.1 H3 原生画布与分辨率约束

H3 的原生高质量画布为 1344×768（短边 768），分辨率必须是 32 的倍数对齐。768p 的画质明显优于 480p，但像素量约是 480p 的 2.5 倍，实际耗时放大 3–5 倍，不宜全程使用。

画布方向可自由组合：768×1344 竖屏、768×768 方形均合法且可正常出片。正方形画布对封面类需求（1:1 平台封面）正好匹配，无需为方形输出做二次裁切。

2.2 三阶段生成策略

建议按"预览 → 确认 → 成片"三个阶段生成，只在最后阶段使用高分辨率：

这是性价比最高的优化手段：构图阶段用低分辨率快速迭代，能大幅减少高分率重跑的浪费。16GB 显卡在 1344×768 下峰值显存约 15.6GB，接近上限，成片阶段要保持环境干净（关闭浏览器、游戏等占用显存的程序）。

首尾帧循环（fl2v）场景下构图已被关键帧钉死，三阶段策略主要用于动作与提示词试错：先用 480p 出 2 秒预览验证动作是否符合预期（如睁眼节奏、有无多余动作），确认后再上目标分辨率，试错成本约降到原来的三分之一。

3. 注意力加速：SageAttention 与 comfy kitchen

3.1 SageAttention 原理与作用

SageAttention 是一种高效的注意力计算实现，可加速 DiT 每步去噪中的注意力矩阵运算，是消费级显卡上最直接的提速手段之一。配合 cu130 版 PyTorch 与 TE-Speed，整体提速约 2.2 倍。

3.2 SageAttention 启用方法

在启动脚本 run_nvidia_gpu.bat 中追加启动参数 --use-sage-attention，或在命令行手动启动：

python main.py --use-sage-attention

验证是否生效：启动完成后观察终端日志。若日志仍显示 Using pytorch attention，说明 SageAttention 未加载成功，最常见的原因是显卡架构不支持（见 3.4 节），此时参数不会带来任何提速。

3.3 SageAttention 画质风险与回退

注意：SageAttention 的 int8 QK 路径在少数情况下会损伤 H3 的画面细节（如眼睛出现"糊掉、旋涡状"）。若发现生成细节异常，去掉 --use-sage-attention 参数，或在 comfy/ldm/minimax/model.py 中将 low_precision_attention 设为 False。

SageAttention 需要额外安装其依赖，安装失败时不影响其余功能。

3.4 硬件前提：20 系（Turing）显卡与 SageAttention 不兼容

SageAttention 的快速内核要求 SM80（Ampere）及以上的计算能力，即 RTX 30 系、RTX 40 系与 RTX 50 系显卡；RTX 20 系（Turing，SM75）及更老的显卡不支持。在 20 系显卡上追加 --use-sage-attention 后，参数会被接受但内核无法加载，生成时仍走 PyTorch attention，不会带来任何提速。

判断方法：在 ComfyUI 启动日志中确认显卡型号与计算能力；或直接启用 --use-sage-attention 后观察日志是否仍显示 Using pytorch attention。20 系显卡用户请继续阅读 3.5 节，使用 comfy kitchen attention 替代。

3.5 Turing 替代方案：comfy kitchen attention

SageAttention 用不了，20 系仍有注意力加速方案。comfy kitchen（ComfyUI v0.37+ 自带）提供 ModelAttentionBackend 节点，其中 comfy kitchen attention 后端在 Turing 上可正常运行，实测 H3 提速约 1.85 倍，Qwen-Image-2.1 提速约 17–19%，画质等效、无伪影。

两种启用方式：

• 工作流接线：LoraLoader 输出 → ModelAttentionBackend（attention 选 comfy kitchen attention）→ 调度器/引导器
• 启动参数：追加 --use-ck-attention

comfy kitchen attention 与 Turbo LoRA、int8 量化权重、TESpeed 缓存节点均兼容，可放心叠加使用。

4. Turing（20 系）显卡：fp16 强制加速

4.1 问题根源：H3 默认以 bf16 加载，而 Turing 无 bf16 快速内核

MiniMax H3 的 supported_inference_dtypes 列表为 [bfloat16, float32]，ComfyUI 会优先选择 bf16。在 Ampere 及以上架构上，bf16 拥有与 fp16 同级的张量核加速，没有性能问题；但在 Turing（SM75） 架构上，GPU 没有 bf16 张量核，bf16 的矩阵乘与注意力只能走慢速模拟路径，实测（RTX 2080 Ti）比 fp16 慢约 6 倍：

H3 是 50 层 DiT，每步去噪几乎全由矩阵乘与注意力构成，bf16 慢路径会直接放大到整体生成时间。20 系显卡用户即使不追求额外加速，也建议先切换到 fp16。

4.2 启用方法：--fp16-unet

在启动命令中追加 --fp16-unet：

python main.py --windows-standalone-build --fp16-unet

也可以使用 --force-fp16（该参数会自动带出 --fp16-unet）。该参数只影响扩散模型（UNet/DiT）的计算精度，不改变文本编码器与 VAE 的加载方式。

4.3 验证与副作用

提交一次生成任务，观察模型加载日志：

• 生效：日志显示 model weight dtype torch.float16（未生效时为 torch.bfloat16）
• 副作用（可忽略）：日志可能出现 Mismatch dtype between input and weight 警告。原因是少数 RMSNorm 层的尺度权重仍是 bf16，未随主权重切换。PyTorch 会把这段小权重自动转成输入精度再计算，结果不受影响；该层计算量占比极小，速度损失可忽略，无需处理。

4.4 画质风险与回退

fp16 数值范围比 bf16 窄（最大 65504），少数模型会因中间激活溢出出现 NaN、黑帧、画面破裂。H3 的输出投影层已经是 fp32，溢出风险相对可控，但仍需实测。若第一段成片出现上述异常，移除 --fp16-unet 参数即可回退到 bf16。

4.5 精度边界：fp8 用不了，int8 量化可放心用

ComfyUI 对 fp8 计算能力有硬性检测（supports_fp8_compute）：计算能力低于 SM80 的显卡直接返回不支持，fp8 的 fp8_ops 路径根本不会被选中；mxfp8、nvfp4 更是要求 SM90+ / SM100+。20 系显卡的精度选择如下：

实测确认，int8 量化扩散模型（minimax_h3_fl2va_pruned_int8_convrot.safetensors，19.5GB）与 nvfp4 AWQ 量化的文本编码器（qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors，14.6GB）在 RTX 2080 Ti 22G 上可正常加载并完整跑通，与 fp16 主路径兼容。这套权重组合正是前置教程模型网盘包提供的版本。

5. Turbo 8-step LoRA：单项收益最大的加速

5.1 原理与文件

Turbo 加速 LoRA（lightx2v/Minimax-h3-Turbo 蒸馏）把 20 步采样压缩到 8 步：步数减少约 60%，每步因蒸馏引导增加约 20% 开销，实测采样总耗时快 2.08 倍，是单项收益最大的加速手段。两个版本二选一：

另有 4-step v1.2 版可进一步提速，画质再让一步；日常推荐 8-step 版本。两个文件均已放入本教程资源下载区的网盘包。

5.2 接入方法

工作流中在 UNETLoader 之后串入 LoraLoader，强度保持 strength_model / strength_clip 均为 1.0，再把 LoraLoader 输出接到注意力后端（ModelAttentionBackend）与调度器/引导器；步数在 BasicScheduler 中从 20 改为 8。

API 调用注意：通过 API 提交工作流时，LoraLoader 必须带 clip 输入，否则校验直接报错。

5.3 实测数据

（RTX 2080 Ti 22G 实测）

5.4 画质与兼容性

同种子下构图会有变化，但画面更锐利、无伪影；LoRA 加载零 key 警告，与 int8 量化权重、comfy kitchen 注意力、TESpeed 缓存节点均兼容。

6. TE-Speed 块级缓存加速

6.1 原理

TE-Speed 通过块级缓存对 H3 的 50 层 DiT 做加速：在部分去噪步骤中跳过大部分网络层，复用前一步缓存的结果，实测可再提升约 40–45% 速度。

6.2 安装与打补丁

# 在 custom_nodes 目录下克隆
git clone https://github.com/HELPMEEADICE/TE-Speed-MiniMaxH3-OSS custom_nodes/TE-Speed-MiniMaxH3-OSS
cd custom_nodes/TE-Speed-MiniMaxH3-OSS

# 打一次补丁（自动备份原 model.py 为 model.py.te_speed.bak）
python patch_model.py

打补丁后重启 ComfyUI。若想恢复原样，运行 python patch_model.py --revert 即可。该插件已包含在本教程资源下载区的 resources.zip 中，可直接解压到 custom_nodes 目录，免去在线克隆。

补丁原理：patch_model.py 对 comfy/ldm/minimax/model.py 做两处最小改动——新增 _run_blocks(start, end) 方法（支持只执行部分块区间），并在 forward 的块循环处增加 ("block_loop", 0) 钩子分支。脚本自带语法校验与备份，若模型文件与补丁不兼容会报错并停止，不会损坏原文件。

验证补丁是否成功：重启 ComfyUI 后，启动日志的 Import times for custom nodes 段应出现 TE-Speed-MiniMaxH3-OSS 的加载记录；也可在安装目录运行 python patch_model.py --check 查看钩子状态。

6.3 工作流接入与参数

在 T2V 工作流中，将 UNETLoader 输出的模型接入 TESpeedMiniMaxH3 节点。节点位于菜单 sampling → custom_sampling → minimax_h3，在节点搜索框输入 TE-Speed 也可找到。

接线要点：TESpeedMiniMaxH3 的 MODEL 输出需要同时接到基本引导器（BasicGuider）和基本调度器（BasicScheduler）两个节点。真正调用模型执行去噪的是引导器，它必须拿到打过缓存补丁的模型：

Latent 图像（或空 Latent）节点照常接到采样器的 latent 输入，与 MODEL 链路互不影响。节点参数建议保持默认：

控制台会在每次运行后打印本次的加速百分比。TE-Speed 存在一定画质损失风险，成片阶段如追求极致画质可调低 cache_depth 或关闭缓存。

6.4 运行节奏、结果判定与叠加说明

TE-Speed 的缓存步依赖前一步保存的残差，因此运行节奏是固定的：

• 第 1 步强制全量计算（前 10% 与后 10% 的步骤同样全量），用于生成缓存残差，这一步耗时与未加速时相当
• 中间步骤走缓存步，只计算前部热启块并叠加残差，单步速度明显快于全量步

跑完整个任务后，控制台会打印一行统计，这是判断加速是否生效的直接依据：

TE-Speed-MiniMaxH3(OSS): acceleration xx.x%

• 出现该行且百分比在 30% 以上，说明节点生效
• 若跑完没有任何 TE-Speed 字样，说明节点未接入工作流，跑的是原速，请检查 6.3 节的接线
• 若出现 no block_loop hooks ... Returning the model unpatched，说明补丁未生效，请重新执行 6.2 节的补丁命令

与其他手段的叠加：fp16（精度）、comfy kitchen（注意力内核）、TE-Speed（跨步跳块）三者原理正交，理论上可叠乘。实测环境中三者已共存安装，封面项目当时采用 comfy kitchen + Turbo LoRA 路线完成，TE-Speed 的叠乘收益与画质需按 6.3 节参数自行验证；叠加后重点检查眼睛等细节是否发糊（TE-Speed 与 SageAttention 共有的画质风险点）。

7. 首尾帧循环视频实战（fl2v）

7.1 能力与节点

MiniMaxH3ImageToVideo 原生支持可选的 first_frame 与 last_frame 输入，模型与 Turbo LoRA 命名中的 fl2v / fl2va 即 first-last-frame video：

• first_frame：几何锚点，拉伸适配画布
• last_frame：跟随锚点，等比 cover 裁切适配画布（方形源图到方形画布时两者等价）
• 两帧之间模型自由生成过渡运动；首尾使用同一张图即可得到无缝循环视频

7.2 帧数网格：length 的硬约束

length 参数单位是帧（24fps），必须落在 17k+5 网格上（训练范围约 124–362），任意值会被拒绝或对齐异常：

要精确输出 6.000 秒：生成 141 帧 + ffmpeg 克隆末帧 3 帧补齐（末帧与首帧相同时，克隆不破坏循环）：

ffmpeg -i in.mp4 -vf "tpad=stop_mode=clone:stop_duration=0.125" -t 6.0 -an \
  -c:v libx264 -crf 18 -preset slow -pix_fmt yuv420p -movflags +faststart out.mp4

7.3 实测循环质量与提示词要点

768×768、141 帧，首尾帧使用同一张封面图，实测：首帧对原图平均像素差 3.6、尾帧 3.27、循环接缝 1.74（肉眼无感）。

提示词是循环质量的关键，三条要点：

• 亮度恒定：明确写出"台灯亮度不变，整个画面光照没有任何明暗变化"。若写"灯光呼吸、星光闪烁"这类描述，模型会真的让整体亮度起伏，破坏循环
• 唯一动作明确写出：如"唯一的动作：缓缓睁眼……然后闭上"，其余部位全部声明静止
• 固定机位：声明无推拉、无摇晃

本章实战对应的完整生成脚本见资源下载区 minimax-h3-cover-scripts.zip 中的 gen_cover_loop_6s_v4.py（API 工作流版，含五锚点链与 ffmpeg 补帧）。

8. AddGuide 动作锚定：锁构图的关键

8.1 问题：画面暗示的动作，提示词压不住

首尾帧项目实测中遇到过典型现象：原图是"手悬停在发光手机上方"，尽管提示词明确写"绝不落下、绝不触碰手机"，模型仍在中段让手指落屏按压。视觉先验强于文本指令——提示词只能引导模型，不能禁止画面暗示的强先验动作。

8.2 解法：MiniMaxH3AddGuide 链式锚定

MiniMaxH3AddGuide 可在视频任意帧锚定一张参考图（转 latent 后作为附加关键帧进 conditioning）。把原图每隔约 1 秒锚定一次（如 141 帧任务锚定 24/47/70/94/117 帧），手部漂移不足 1 秒即被拉回原位；睁眼动作在每个约 1 秒的自由窗口内仍能完成。

# 链式接线（每个节点消费上一个节点的 conditioning）
g["50"] = {"class_type": "MiniMaxH3AddGuide", "inputs": {
    "positive": ["4", 0], "latent": ["4", 1], "vae": ["3", 0],
    "image": ["30", 0], "frame_idx": 24}}
g["51"] = {"class_type": "MiniMaxH3AddGuide", "inputs": {
    "positive": ["50", 0], "latent": ["4", 1], "vae": ["3", 0],
    "image": ["30", 0], "frame_idx": 47}}
# ... 以此类推；BasicGuider 的 conditioning 接最后一个锚点节点

接线坑（API 调用均实测踩过）：

• latent 每个锚点都接 MiniMaxH3ImageToVideo 的 latent 输出
• guider 输入必须接 BasicGuider 节点（不是锚点的 CONDITIONING 输出）
• 不要在静态字典里写死下游节点号，用变量串接锚点链

完整锚点链实现见资源下载区 minimax-h3-cover-scripts.zip 中的 gen_cover_loop_6s_v4.py。

8.3 代价与修复

字幕重影不必重跑模型（可省约 20 分钟）：提取全部帧 → 定位重影帧 → 用相邻干净帧的字幕带区域做羽化替换（该区域背景近乎静止，接缝不可见）→ 按原帧率重组转码。实测修复后验收零缺陷。

9. 低显存与稳定性优化

9.1 Dynamic VRAM 动态卸载

ComfyUI 默认开启 Dynamic VRAM：显存放不下的模型层会被卸载到系统内存，需要时再换入。这是 16GB 显卡能运行约 40GB 量化模型的基础。

提醒：显存较大（如 22GB）并不等于没有卸载压力。H3 量化模型本体约 21.6GB，加上生成时的激活值与 KV cache 仍可能超出显存，触发层换入换出。显存越大只是卸载次数越少、越稳定，不代表完全不卸载。

Turing 机器实测修正（ComfyUI v0.37+）：在 20 系显卡上运行 v0.37+ 版本时，Dynamic VRAM 会在 KSampler 阶段报 aimdo memory compile error（用 --disable-comfy-compiler 绕过后则转为纯 OOM）。Turing 机器必须追加 --disable-dynamic-vram。关闭后 H3 权重自动分层驻留，实测 768×768、141 帧任务显存占用 8.2GB、内存卸载 13.4GB（lowvram patches 158），生成正常。未触发该 bug 的环境（Ampere 及以上架构或旧版本 ComfyUI）仍建议保持 Dynamic VRAM 开启。

内存紧张时配合 9.2 节的 --disable-pinned-memory 一起使用。

9.2 内存减压：--disable-pinned-memory

H3 三件套约 39GB（UNET 19.5GB + CLIP 14.6GB + VAE 4.9GB），32GB 内存机器上会向内存卸载 13GB 以上。启动时添加 --disable-pinned-memory，实测可把内存占用从约 21.5GB 降到约 6.9GB（64GB 内存环境实测），32GB 内存机器同样值得加上。

9.3 大权重加载偶发崩溃的规避：预热页缓存

现象：加载 14–20GB 级 safetensors（如 Qwen3-VL 文本编码器）时，load_torch_file 处偶发 Windows access violation 崩服。与内存余量无关（空闲 22.6GB 仍崩、18GB 反而成功过），是原生加载代码的偶发问题，文件不在页缓存（冷读磁盘）时容易触发。

可靠规避方法（实测多次 100% 成功）：启动 ComfyUI 前先把模型文件完整读一遍，预热页缓存：

dd if=<模型文件>.safetensors of=/dev/null bs=8M

配合"冷启动期只提交一个任务"的节奏使用；模型已热后可连续排队。同时保持 --disable-mmap 启动参数（safetensors mmap 在提交内存紧张时的常规防护）。

9.4 LongMedia 长视频节点与长视频两条路线

ComfyUI-MiniMax-H3-LongMedia 是一组面向长视频单次生成与低显存显卡的自定义节点，提供流式 Sol 注意力、压缩 KV、Token 轴 MLP 分块、自适应显存守卫等优化，官方在 16GB 显卡上完成 15 秒、1920×1088、8 步的单次生成：

# 在 custom_nodes 目录下克隆后重启 ComfyUI（resources.zip 中已包含）
git clone https://github.com/vizart-vj/ComfyUI-MiniMax-H3-LongMedia custom_nodes/ComfyUI-MiniMax-H3-LongMedia

节点包含 Long Media Setup / Sampler / Decode 三个主节点。保守配置参考：

超过单次生成容量的长任务，有两条可行路线：

注意：22G 显存卡单次直出 15 秒不可行——362 帧的单次前向需约 22.16GB 显存，超出上限且伴随图编译失败。超过单次容量时优先尝试 LongMedia，再退回分段接力拼接。

10. 调优组合与实测参考

10.1 推荐调优组合

Ampere 及以上架构（30/40/50 系）按侧重不同选择：

Turing（20 系）实测推荐组合（RTX 2080 Ti 22G 验证）：

Turing 启动参数模板：

python main.py --windows-standalone-build --fp16-unet --disable-dynamic-vram --disable-mmap --use-ck-attention
# 内存紧张再加: --disable-pinned-memory

10.2 实测性能参考

16GB 显存 + 64GB 内存环境（Ampere 路线，动态显存卸载开启，5 秒视频）：

RTX 2080 Ti 22G（Turing 实测口径）：

20 系注意：fp16 强制加速后，单步耗时相对 bf16 大幅下降（矩阵乘与注意力快约 6 倍）。生成第一步包含模型初始化与全量计算，耗时显著高于后续步骤，属正常现象，不要被第一步的进度条速度误导。

显存低于 16GB（如 12GB）时，ComfyUI 会自动将显存溢出部分卸载到内存，生成速度变慢但一般不会直接崩溃；进一步降低分辨率与帧数即可稳定出片。

11. 总结

11.1 核心内容回顾

• 瓶颈：注意力计算、分辨率像素量、模型层换入换出是消费级显卡上的三个主要瓶颈
• 分辨率策略：480p 抽卡、768p 精选，三阶段生成最高效；画布方向可自由组合
• 注意力加速：30 系及以上用 SageAttention（--use-sage-attention，注意 int8 QK 画质风险）；20 系用 comfy kitchen attention（ModelAttentionBackend 节点或 --use-ck-attention），实测约 1.85 倍
• fp16 强制加速：20 系显卡用 --fp16-unet 切换计算精度，规避 bf16 慢路径（实测矩阵乘与注意力快约 6 倍）；int8 量化权重可正常使用
• Turbo 8-step LoRA：20 步压缩到 8 步，采样快 2.08 倍，单项收益最大；768p 任务用 768p 专用版
• TE-Speed：块级缓存加速约 40–45%，patch_model.py 打补丁即可接入；与 fp16、comfy kitchen 原理正交，可尝试叠乘
• 首尾帧循环：length 必须落在 17k+5 网格，141 帧加 ffmpeg 补帧精确到 6 秒；提示词锁亮度、锁机位、写明唯一动作
• AddGuide 锚定：每约 1 秒锚定一次原图对抗视觉先验，代价是采样变慢与偶发字幕重影（可羽化修复）
• 低显存与稳定性：Turing 机器 v0.37+ 必须关闭 Dynamic VRAM；--disable-pinned-memory 减内存；大权重加载前 dd 预热页缓存；长视频走分段接力或 LongMedia

11.2 常见问题与解答

问：SageAttention 开启后画面细节异常？

答：SageAttention 的 int8 QK 路径可能损伤细节（如眼睛糊掉）。去掉 --use-sage-attention，或在 comfy/ldm/minimax/model.py 中将 low_precision_attention 设为 False 后重启。20 系显卡本身用不了 SageAttention，请直接使用 3.5 节的 comfy kitchen attention。

问：TE-Speed 打补丁后想恢复原样？

答：运行 python patch_model.py --revert 即可从备份 model.py.te_speed.bak 恢复。

问：16GB 显卡 1344×768 会爆显存吗？

答：1344×768 峰值显存约 15.6GB，非常接近 16GB 上限，稍有余量不足就会 OOM。稳妥做法是成片阶段保持环境干净，或使用 LongMedia 节点配合保守显存守卫配置。

问：内存占用太高怎么办？

答：启动时添加 --disable-pinned-memory，内存占用可从约 21.5GB 降到约 6.9GB。

问：加了 --use-sage-attention 却没有任何提速？

答：先确认显卡是否为 20 系及更老（Turing 架构不支持 SageAttention，见 3.4 节），再看启动日志是否仍显示 Using pytorch attention。20 系显卡请改用 3.5 节 comfy kitchen attention 加第 4 章 fp16 强制加速。

问：--fp16-unet 后日志出现 Mismatch dtype 警告，要紧吗？

答：不要紧，可以放心。这条警告来自 RMSNorm 层的混合精度调用：主权重被 --fp16-unet 切成 fp16，但少数 RMSNorm 的尺度权重仍是 bf16，PyTorch 在 rms_norm 中检测到不一致后，会把这段小权重自动转成输入精度再计算，结果正确。RMSNorm 占模型计算量比例极小，这次隐式转换的额外耗时可以忽略，也不影响画质——归一化尺度向量精度需求很低。一个反向证据：同一台机器上 F.linear 遇到 fp16 输入 + bf16 权重会直接报错而非警告，你的生成能跑通，恰恰说明残留 bf16 的只有这些 norm 尺度向量。真正需要盯的画质风险是 fp16 数值溢出导致的 NaN、黑帧（见 4.4 节），判断标准是成片画面而非警告文本。

问：我的显卡显存有 22GB，为什么生成还是会慢？

答：H3 量化模型本体约 21.6GB，加上生成时的激活值与 KV cache，仍可能超出显存触发 Dynamic VRAM 卸载。显存大只是卸载更少、更稳定，不等于完全没有卸载开销（见 9.1 节）。

问：生成第一步特别慢，是什么原因？

答：第一步包含模型初始化（加载、量化、优化）与全量计算，且 TE-Speed 每轮第一步强制走全量模式，耗时显著高于后续缓存步，属正常现象，不要被第一步的进度条速度误导。

问：加载大模型时偶发 access violation 崩服？

答：与内存余量无关，冷读磁盘时容易触发。启动 ComfyUI 前先用 dd if=<模型文件> of=/dev/null bs=8M 预热页缓存，冷启动期只提交一个任务（见 9.3 节）。

问：模型明明该做的动作不做、不该做的动作一直做？

答：提示词只能引导，不能禁止。画面暗示的强先验（如手悬停在手机上方就会去摸屏）要用 AddGuide 锚定对抗，把原图每隔约 1 秒锚定一次（见第 8 章）。

问：锚点视频里字幕偶尔出现重影？

答：锚点窗口中间的瞬时瑕疵。提取全部帧后，用相邻干净帧的字幕带区域做羽化替换，再按原帧率重组转码即可，无需重跑模型（见 8.3 节）。