首页 / 显存档位表

显存档位表

2026-09-18 · 速查

三个档位，先看结论

档位	分辨率 × 帧数	步数	采样耗时	出片耗时	结论
常用档	768×768 × 64	4	1 分 49 秒	236 秒	能出片，但踩在边缘
满血档	1280×720 × 168	20	—	约 21 分钟	显存几乎用满
禁区	1344×768 × 124	—	—	—	直接卡死，别试

「常用档」不等于「安全档」。它出过片，也在同一台机器上把 ComfyUI 进程打崩过——崩在解码阶段，不是采样阶段，原因见下面第三节。

显存被谁占了

这是本机实测的加载记录（取自 ComfyUI 日志，单位是日志里的原始数字）:

组件	文件体积	日志里的加载量	说明
MiniMax-H3 底模（fp8_scaled）	20G	19,984 MB	一次全量加载，不再卸载
文本编码器 Qwen3-VL 32B	15G	14,960 MB	编码完不释放，和底模抢位置
视频 VAE	4.9G	—	解码阶段才加载，崩溃点
音频 VAE	578M	577 MB	解码阶段加载
Turbo 4 步 LoRA	1.9G	—	采样时随底模一起

权重加起来约 42G，显存却只有 24G。能跑起来，靠的是分阶段装卸：编码时只放编码器，采样时换底模，解码时再换 VAE。所以真正决定成败的不是「总模型多大」，而是每一步切换时还剩多少余量。

崩溃点：解码阶段

跑 768×768 × 64 帧、4 步，采样顺利完成，接着日志里出现这样一行：

[21:05:15] 启动前显存： 544 MB
[21:05:26] 文本编码器加载：23148.8 MB usable, 14960.2 MB loaded
[21:06:23] 底模加载：20884.5 MB usable, 19984.5 MB loaded
[21:08:02] 采样 4/4 [01:38, 24.69s/it]
[21:08:16] 音频 VAE 加载：2692.9 MB usable, 577.1 MB loaded
[21:08:21] Requested to load MiniMaxH3VideoVAE
[21:08:21] Fatal Python error: Aborted   ← 进程直接崩，core dump

采样结束时可用显存只剩 2.7G，而视频 VAE 要 4.9G。ComfyUI 不会优雅报错，是整个进程 abort,systemd 把服务重启，队列清空 —— 你看到的现象是「任务凭空消失」。

同一天晚上 22:39，同一套参数跑通了，整条 236 秒——区别是请求视频 VAE 时它先卸掉 3,374 MB（日志里的 Unloaded partially），可用显存从 2.7G 变成 6.0G。崩的那次在同一位置没有这一行，直接 abort。所以 768 档的正确描述是：擦边档，成败取决于切换那一刻的显存能不能回收成功，别在同一张卡上并发跑别的任务。

三条规则

一次只跑一个。本地 LLM 速度档常驻 22.2G、质量档 20.6G，和 H3 争的是同一份显存。跑 H3 前先 llm stop。
跑前看基线。rocm-smi --showmeminfo vram 应回到 0.5G 左右再提交任务；还挂在 20G 以上说明前一个进程没退干净。
崩了先看日志尾。最后一行停在哪个 Requested to load，就说明是哪个组件加载失败。tail -5 ~/comfy/ComfyUI/user/comfyui_8188.log。

常用命令

llm stop                          # 释放显存(停本地 LLM)
llm fast                          # 跑完 H3 后切回速度档
gpu video                         # 切到 ComfyUI(自动停 LLM)
rocm-smi --showmeminfo vram       # 看当前显存占用
journalctl -u comfyui -n 20       # 看服务日志

想让 768 档稳一点

把视频解码改成分块解码（VAEDecodeTiled 类节点），把一次 4.9G 的峰值摊成多段小峰值 —— 代价是慢一些。
帧数从 64 降到 48 或 32，显存峰值跟着降；短视频平台 3 秒左右的镜头够用。
要质量和时长都保，就别在 24G 上硬扛：720p 168 帧那条路是给 20 步准备的，老老实实接受 21 分钟。