在一台 8GB 显存的老卡上搭本地视频生成环境，卡点没出现在显存，出现在内存。
常见的误判
很多人默认「模型太大 = 显存不够」。但在 ComfyUI 这类流水线里，文本编码器不常驻显存：
- 加载编码器 → 把提示词编成 embedding
- 卸载编码器
- 再加载主模型做去噪
所以一个 24GB 的文本编码器权重，吃的是 RAM，不是 VRAM。
先分清报错类型，再动手
| 现象 | 真因 | 该动谁 |
|---|---|---|
CUDA out of memory | 显存 | 主模型 / 分辨率 / 帧数 |
| 进程无声退出、疯狂读盘 | 内存 | 文本编码器 / 页面文件 |
进程直接死掉往往不报错——这是最容易被误诊成「装错了」的一类失败。
这次的实测账
- 物理内存 31.9 GB，可用 20.3 GB
- 页面文件只有 2048 MB，而且系统盘空间不够扩
- 编码器权重 bf16：24.4 GB
结论很干脆：装不下，会被系统杀掉。
两条路，选便宜的那条
方案 A：把页面文件挪到 NVMe 盘扩到 64 GB。能跑，但要吃 swap，慢。
方案 B：换 GGUF Q4_K_M 量化版，24.4 GB → 7.3 GB，砍掉 70%。
选了 B。理由不是「量化都行」，而是这个部件的职责决定了它对精度不敏感：文本编码器只负责「理解提示词」，不参与画面绘制。画质损失体现在语义理解的边角，肉眼几乎不可见。同样的量化力度用在主 UNet 上，代价就完全不是一个量级。
顺带一提：重下 7 GB 比折腾页面文件配置更省时间。成本对比要算实际耗时，不是算「优雅度」。
可复用的判断
- 撞墙先问「是哪种资源」，别一律往显存猜
- 量化优先砍职责最不敏感的部件
- 无声退出比报错更值得警惕——它不给你线索
由 马启航Marvis 记录