8GB 显存本地生图
怎样避免爆显存
“显卡是 8GB，为什么模型还是说显存不够？”我们在同一台 RTX 4060 Ti 上经历过只剩 1.85GB 空闲、模型拒绝启动，也完成过 1024×1536 的稳定出图。这篇把中间真正有效的排错顺序完整记录下来。
一、先看“空闲显存”，不是显卡型号
第一次检查时，电脑虽然识别到 8188MiB 显存，但剪辑、图形和浏览器程序已经占用了约 5665MiB。模型真正能用的只剩约 2GB。此时继续加载并不会“慢一点”，而是很可能在加载权重或解码图片时直接失败。
我们因此给启动程序加了一道保护：生成前读取显卡真实空闲显存，低于 5.5GB 就停止，不让用户等到最后才看到 OOM。关闭剪辑和图形软件后，空闲显存回到约 6GB，FLUX.2 klein 4B 的第一张图才顺利完成。
二、按这个顺序排错，别一上来删模型
- 保存正在编辑的项目。先保存剪映、Filmora、Adobe、Blender 等软件里的工作。
- 真正退出占用 GPU 的程序。只关窗口不一定结束后台进程；退出后再检查显存。
- 从小尺寸跑通。先用 512×512 或 768×1024 验证模型、环境和参数，不要直接挑战最大尺寸。
- 启用低显存策略。模型组件分批进入显卡，VAE 使用分块解码；代价是更依赖系统内存，速度可能稍慢。
- 再逐级增加尺寸。一次只改变一个变量，失败时才能知道是尺寸、步数还是模型造成。
如果小尺寸也失败，应先检查 CUDA 环境、模型文件是否完整和系统内存，而不是继续降低画质。能够生成 512×512，只在大图失败，才更像是显存或解码峰值问题。
三、8GB 显存的尺寸起点
| 任务 | 建议起点 | 我们为什么这样选 |
|---|---|---|
| 场景构图草案 | 768×432 或 512×512 | 快速判断主体、光线、色彩和空间关系，不把时间浪费在错误构图上。 |
| 写实头肩人像 | 768×1024 或 832×1024 | 脸部有足够像素，同时不会像超近景那样放大眼睛和鼻翼的小误差。 |
| 竖版高清成片 | 1024×1536 | 本机实测可以完成，但应开启 offload，并限制总像素不超过约 160 万。 |
| 更高分辨率 | 先生成再放大 | 先保证结构正确，再用低强度高清修复或专用放大器，通常比直接超大图稳定。 |
四、显存、系统内存和磁盘空间不是一回事
显存 VRAM
决定当下能放多少模型组件和图像张量。爆显存通常发生得快，常见表现是 CUDA out of memory。
系统内存 RAM
启用 CPU offload 后，暂时不用的模型组件会放到这里。我们测试机约 64GB 内存，因此可以用空间换显存。
磁盘空间
用于模型权重、缓存和输出图。FLUX.2 官方组件完整缓存明显大于单文件 SDXL 权重，下载前必须单独计算。
删模型只能释放磁盘，不会让正在运行的显卡多出显存；关闭剪辑软件能释放显存，却不会增加 D 盘空间。把这三者分清，排错会快很多。
五、本机已经跑通的边界
| 模型与尺寸 | 耗时 | 记录峰值显存 | 结果 |
|---|---|---|---|
| FLUX.2 klein 4B · 768×432 · 4步 | 18.04秒 | 0.97GB | 场景构图、夜景与冷暖色关系完整。 |
| Juggernaut XL v9 · 768×1024 · 30步 | 50.51秒 | 2.83GB | 写实人像达到可继续测试的基础质量。 |
| Juggernaut XL v9 · 1024×1536 · 30步 | 66.55秒 | 3.76GB | 在 offload 方案下稳定完成高清竖图。 |
说明：这里的“峰值显存”来自 PyTorch 记录，不代表驱动、桌面和其他程序的全部显存占用；不同驱动、模型精度和运行方式会产生差异。
六、三种爆显存报错，含义完全不同
“爆显存”在报错里长着好几张脸，而它们指向的修法不一样。先认清楚是哪一种，比盲目降分辨率有效得多。
- CUDA out of memory. Tried to allocate 2.00 GiB 最典型的一种，字面意思：这一步要一块 2GB 的连续显存，拿不出来。修法是降低这一步的开销——降分辨率、降批量、开分块。报错里给出的 “Tried to allocate” 数值很有用，它告诉你还差多少。
- 能加载、能采样，最后一步崩 几乎一定是 VAE 解码。开启 VAE 分块（tiled decode / tiling）能把这一步的峰值压下来一大截，代价只是最后几秒慢一点，画质几乎无损。这是性价比最高的一个开关。
- 不报错，但整机卡成幻灯片 这不是显存不足，是显存正好不够而驱动启用了共享内存回退，把一部分权重放到了内存里，靠 PCIe 来回搬。表现是没崩但慢十倍。这种情况下你要做的不是继续等，是主动降参数——回退状态下跑完的结果，和你正常参数下跑出来的并不等价。
第三种最坑，因为它不报错，你会以为是模型本身慢。判断方法：看 nvidia-smi 的显存占用是不是死死贴着上限，同时 GPU 利用率却上不去。这个组合就是回退的指纹。
七、省显存的开关，各自要付什么代价
省显存的手段不是免费的。下面按“性价比从高到低”排，前两个基本可以无脑开，后面的要想清楚再用。
- VAE 分块解码 峰值降幅明显，速度损失通常在 5% 以内，画质差异肉眼不可见。可以默认开着。
- 注意力切分 / 低显存注意力 把注意力计算拆成小块。速度损失 10%～20%，画质无损。显存紧张时第二个该开的。
- 权重精度降级（fp16 → fp8 / 量化） 显存降幅很大，但画质是真的会变——细节变软、皮肤质感变塑料的情况我们遇到过。做草图和构图阶段完全可以用，出成片前建议切回来重跑一遍。
- CPU offload（模型分层搬到内存） 最后的手段。它能让本来跑不动的模型跑起来，但速度惩罚极重，实测能到三到五倍。只在“必须用这个模型、别无选择”的时候用。
一个容易被忽略的点：这些开关的收益不叠加。分块解码已经把 VAE 峰值削掉之后，再开 offload 并不会让你多出等量的空间，因为瓶颈已经换到采样阶段了。所以每开一个，就重新量一次峰值，别一口气全打开——那样你只是把速度赔光，换来一点点用不上的余量。
八、模型放在哪个盘，也会被当成显存问题
这一条不涉及任何参数，却是我们花掉最多冤枉时间的地方。把模型权重放在机械硬盘上，冷启动加载一次能多花一两分钟；而在你眼里，它的表现是“点了生成之后没反应”，和显存不足导致的回退卡顿几乎无法区分。
区分方法很简单：加载阶段看磁盘占用，采样阶段看显存和 GPU 利用率。如果卡在前一段、磁盘读满而显存还是空的，那是 I/O，不是显存。
- 模型权重、缓存目录、输出目录，都放固态盘。这不省显存，但能砍掉一半的“怎么这么慢”。
- 路径里尽量不要有中文和空格。多数框架能处理，但一旦某个组件处理不了，报错信息通常和路径毫无关系，非常难查。
- 同一个模型不要在多个工具里各存一份。除了浪费几十 GB，还容易出现“你改了 A 目录的配置，跑的却是 B 目录的权重”这种查半天的问题。
- 第一次跑一个新模型时，故意用最小尺寸跑一张。目的不是看画质，是把加载路径、缓存、显存全都走通一遍——这一张失败的成本，远低于在成片参数下失败。
一句话总结这篇的排错顺序：先看是不是别的程序占着显存，再看是不是 VAE 那一步，再看是不是回退了，最后才考虑换模型。顺序反过来做，你会删掉一堆本来能用的模型。