首页 / 24G 显存能跑什么
24G 显存能跑什么
把视频生成搬到本地之前，最先要确认的不是提示词写法，而是这张卡到底扛不扛得住。这篇是本机（Ubuntu 24.04 + AMD RX 7900 XTX 24G）跑 MiniMax-H3 一个多月的口径记录，包含能跑通的组合、跑崩的边界、以及全流程每个阶段实测花了多久。
一、能跑和不能跑
| 组合 | 能不能跑 | 实测情况 |
|---|---|---|
| 768 × 768 · 64 帧 · 4 步（Turbo LoRA） | ⚠️ 擦边 | 整条 236 秒（2026-09-18 实测出片）；视频 VAE 进场时可用显存只剩 2.7G，同一天在这里崩过一次 |
| 1280 × 720 · 168 帧 · 20 步（不加 LoRA） | ✅ 能跑但吃紧 | 约 21 分钟，显存峰值 23.7 GB，基本贴着上限 |
| 1344 × 768 · 124 帧 | ❌ 卡死 | 进程锁死在采样阶段，只能重启服务 |
| 和本地大模型同时开 | ❌ 不行 | 显存只有一份，必须二选一 |
三条结论直接记住：24G 是 768 档的出生线，768 档能出片但没有余量；720p 是天花板，走 20 步满血，代价是 21 分钟一条；再往上不是慢，是死，1344×768 那个尺寸会把注意力计算的显存吃干净，进程直接锁死。
二、硬件底线
| 项目 | 要求 | 我这台 |
|---|---|---|
| 显存 | 24 GB 起步（16 GB 只能跑小尺寸短片段） | AMD Radeon RX 7900 XTX 24 GB |
| 内存 | 32 GB 以上，加载模型时会先落内存 | 62 GB |
| 磁盘 | H3 全家桶约 47 GB，建议留 80 GB 余量 | 915 GB SSD（已用 206 G） |
| 系统 | Ubuntu 22.04 / 24.04 均可 | Ubuntu 24.04，内核 6.8 |
| 显卡栈 | N 卡走 CUDA；A 卡走 ROCm | ROCm + PyTorch ROCm 6.3（gfx1100） |
| 权限 | Linux 下当前用户要在 render 组 | 已加，否则 /dev/kfd 打不开 |
显存之外，内存和磁盘经常被忽略：模型加载时会先在内存里做一次转换，磁盘不够时你会在下载到一半失败，而内存不够的现象是「进度条走到一半整机变卡」。这三样里任何一样掉链子，表现都不像显存不足那样干脆。
三、显存到底被谁吃掉
这是本机实测的加载记录（数字取自 ComfyUI 日志，单位是日志里的原始值）：
| 组件 | 文件体积 | 日志里的加载量 | 说明 |
|---|---|---|---|
| 底模 fp8_scaled | 20 GB | 19,984 MB | 采样阶段常驻 |
| 文本编码器 Qwen3-VL 32B | 15 GB | 14,960 MB | 编码完不主动释放 |
| 视频 VAE | 4.9 GB | — | 解码阶段才进场 |
| 音频 VAE | 578 MB | 577 MB | 解码阶段加载 |
| Turbo 4 步 LoRA | 1.9 GB | — | 随底模一起 |
权重加起来 42 GB 以上，显存只有 24 GB。它能跑起来，靠的是分阶段装卸：先放编码器把提示词编码完，再换成底模采样，最后换成 VAE 解码。每一步切换都要把上一批权重挪走，所以真正决定成败的不是「模型一共多大」，而是每次切换那一刻还剩多少余量。
这也解释了为什么加一个 2.5 GB 的参考图 LoRA 会明显变危险：多那 2.5 GB 不算多，但它挤掉的是切换时的缓冲。
四、每个阶段要花多久
一次 768 × 768 × 64 帧、4 步的提交，分段实测如下（同一次运行的日志时间戳）：
| 阶段 | 耗时 | 日志时间 |
|---|---|---|
| 入队 → 文本编码器开始加载 | 6 秒 | 22:39:04 → 22:39:10 |
| 文本编码器加载（14,960 MB） | 17 秒 | 22:39:10 → 22:39:27 |
| 底模加载（19,985 MB） | 40 秒 | 22:39:32 → 22:40:12 |
| 采样 4 步 | 1 分 49 秒 | 22:40:12 → 22:42:01 |
| 音频 VAE 加载 + 解码（577 MB） | 6 秒 | 22:42:01 → 22:42:07 |
| 回收 3,374 MB → 视频 VAE 加载（4,966 MB）→ 逐帧解码 | 46 秒 | 22:42:07 → 22:42:53 |
| 合计（ComfyUI 自报 229.82 秒） | 236 秒 | 22:39:04 → 22:43:00 |
结论：这条链路里三段各占三分之一——等模型上卡 57 秒、采样 1 分 49 秒、双 VAE 加解码 52 秒。所以「步数少 = 很快」这个直觉在视频生成里是错的：4 步采样仍然要 1 分 49 秒，因为 64 帧的注意力计算量摆在那里。要省时间，优先降的是帧数（采样和解码都与帧数成正比），不是步数。
另一条路是 1280 × 720 × 168 帧、20 步：约 21 分钟，显存峰值 23.7 GB。多出来的时间主要花在 20 步采样和 7 秒素材的解码上。
五、绝对不能碰的组合
1344 × 768 × 124：直接锁死
这个尺寸我试过一次就够了。现象是采样阶段进度条停住不动，GPU 占用维持在满值，日志不再刷新；等十分钟也不会有反应。原因是这个尺寸的注意力计算把显存余量吃干净，AMD 这套栈在显存压力下的表现比 N 卡更脆。处理办法只有一个：重启服务，任务重来。
先用小尺寸把链路跑通，再一档一档往上加，别跳档。
768 × 768 × 64：看显存回收成不成，成了 236 秒、败了整进程 abort
这个档位我跑成过好几次。2026-09-18 白天复现时它把 ComfyUI 进程直接打崩了，日志最后三行是：
[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采样已经跑完，只是轮到视频 VAE 进场时可用显存只剩 2.7 GB，而它要 4.9 GB。ComfyUI 不会优雅报错，是整进程 abort，systemd 重启服务、队列清空——你看到的现象是「任务凭空消失」。先看日志尾，别急着怀疑提示词。
同一天晚上 22:39，同一档位跑通了，整条 236 秒。区别只有两处：服务启动时加了 PYTORCH_HIP_ALLOC_CONF=expandable_segments:True，并让运行器在显存全空时独占提交。日志里能直接看到分岔点：
[22:42:07] Requested to load MiniMaxH3VideoVAE
[22:42:08] Unloaded partially: 3373.51 MB freed, 16611.04 MB remains loaded
[22:42:38] loaded completely; 6008.17 MB usable, 4966.19 MB loaded也就是说：能不能过，取决于请求视频 VAE 那一刻显存回收是否成功。崩的那次在同一位置没有任何回收动作，可用显存 2.7 GB 直接 abort；通的那次先卸掉 3.4 GB，可用显存变成 6.0 GB，VAE 就装下了。两次日志里 Unloaded partially 分别出现 0 次和 1 次——这就是 768 档「擦边」的全部含义：它不是不能跑，是每次都踩在那条线上。完整的档位数字在显存档位表里。
别和本地大模型同时开
我这台机器平时还跑一个本地大模型，占 22 GB 显存。要出片必须先把它停掉，否则就是显存争抢。正规做法是给两个服务加互斥关系（一个启动时自动停另一个），而不是手动 kill：
# systemd 单元里互相声明
[Unit]
Conflicts=llama-server.service这样做之后，切到视频生成时本地模型自动让位，跑完再切回来，中间不需要记得任何事。llm stop / llm fast / gpu video 这类小脚本就是包在这层之上的。
六、磁盘要留多少
H3 需要的文件一共 7 个，合计约 46.8 GB：
| 文件 | 体积 | 作用 |
|---|---|---|
| minimax_h3_fl2va_pruned_fp8_scaled.safetensors | 20 GB | 底模，出画面带声音 |
| qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors | 15 GB | 文本编码器 |
| minimax_h3_video_vae_fp16.safetensors | 4.9 GB | 视频 VAE |
| minimax_h3_ref_lora_rank_256_bf16.safetensors | 2.5 GB | 参考图一致性（可选） |
| minimax_h3_fl2v_turbo_4step / 8step LoRA | 各 1.9 GB | 加速（二选一即可） |
| minimax_h3_audio_vae_fp32.safetensors | 578 MB | 音频 VAE |
再加上 ComfyUI 本体、输出视频和系统占用，建议留 80 GB 以上。输出比想象中占地方：一条 3 秒 768×768 的 mp4 是 3.1 MB，一分钟 24 fps 的素材量级是几百 MB，批量出片几天就能吃掉几十 GB。
另一件事：模型和输出别放同一个机械盘。加载 20 GB 底模时磁盘是满速读，同时解码写视频会和它抢 IO，表现出来就是「有时候莫名其妙慢一倍」。
七、开跑前的检查清单
- 显存空的吗？
rocm-smi --showmeminfo vram应在 0.5 GB 左右；还挂着 20 GB 说明本地大模型没停干净。 - 磁盘还剩多少？
df -h至少留 80 GB。别在只剩几个 GB 的时候提交任务。 - 目录放对了吗？底模在
diffusion_models/、编码器在text_encoders/、两个 VAE 在vae/、LoRA 在loras/。放错的表现是下拉框里根本选不到文件。 - 尺寸从小的开始？第一次跑用 768 × 768 × 64 帧、4 步、Turbo LoRA，别一上来就 720p 20 步。
- 知道自己要等多久？768 档 236 秒，720p 满血约 21 分钟。中途不要重复提交，会排队抢显存。
八、只有 16G 或 12G 的卡怎么办
- 降尺寸不降步数：640 × 640 × 32 帧的量级在 16 GB 上还能跑，视频平台的竖屏短视频按 3 秒剪辑够用。
- 把解码分块：视频 VAE 是峰值最集中的一步，分块解码能显著降低瞬时峰值，代价是慢一些。
- 老老实实用云端出关键镜头：本地跑草稿、云端出成片，比硬凑一台机器便宜。我这台机器的定位就是把流程和参数摸清、把草稿出够，成片量一大就该算成本了。
小结
24G 显存能做的：768 × 768 × 64 帧 4 步（擦边）、1280 × 720 × 168 帧 20 步（吃紧但稳）。不能做的：再往上的尺寸、以及和任何占显存的东西并存。真正要留意的不是「能不能跑」，而是每一步切换时的余量——这也是后面排错时最先要看的地方。
下一篇讲怎么把这 47 GB 的模型文件下下来并校验完整，这也是新手最容易卡住的一步。
