RTX 4060 Ti · 8GB 显存
8GB 显存本地生图
怎样避免爆显存
“显卡是 8GB，为什么模型还是说显存不够？”我们在同一台 RTX 4060 Ti 上经历过只剩 1.85GB 空闲、模型拒绝启动，也完成过 1024×1536 的稳定出图。这篇把中间真正有效的排错顺序完整记录下来。
一、先看“空闲显存”，不是显卡型号
第一次检查时，电脑虽然识别到 8188MiB 显存，但剪辑、图形和浏览器程序已经占用了约 5665MiB。模型真正能用的只剩约 2GB。此时继续加载并不会“慢一点”，而是很可能在加载权重或解码图片时直接失败。
我们因此给启动程序加了一道保护：生成前读取显卡真实空闲显存，低于 5.5GB 就停止，不让用户等到最后才看到 OOM。关闭剪辑和图形软件后，空闲显存回到约 6GB，FLUX.2 klein 4B 的第一张图才顺利完成。
关键判断：任务管理器里“GPU 利用率 0%”不代表显存已经释放。有些程序没有在计算，但仍把模型、预览缓存或硬件加速缓冲区留在显存里。
二、按这个顺序排错，别一上来删模型
- 保存正在编辑的项目。先保存剪映、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 记录，不代表驱动、桌面和其他程序的全部显存占用；不同驱动、模型精度和运行方式会产生差异。
实用结论：8GB 显卡不是不能做高清图，而是不能把所有组件、最大尺寸和其他 GPU 软件同时塞进去。先保证至少约 5.5GB 空闲，从小尺寸验证，再逐级提高，成功率远高于反复盲试。