Stable Diffusion 3.5 本地出图能开多大分辨率，通常不取决于显卡型号的名字，而取决于加载完主模型、文本编码器和 VAE 之后还剩多少可用显存。同一张卡，换精度、换文本编码器的加载方式、换批次数，能跑的分辨率会明显不同。判断顺序建议是：先在终端确认实际可用显存，再确认权重文件完整，然后用最小分辨率拿到一个确定能跑通的基线，之后每次只改一个变量往上试。

本地 SD3.5 的分辨率上限由「总显存减去模型常驻占用后的余量」决定。建议先按单张、512 边长、20 步左右跑通基线，再逐步加分辨率或批次。爆显存时按代价从低到高回收：先降批次、再降分辨率，最后才清进程重启。每一步都用同一提示词和 seed 复跑一张，确认出图正常；具体上限需结合自己的精度设置和显卡确认。

在终端确认显卡型号、驱动版本与当前可用显存

这一步的目的是排除「卡没问题但显存被别的东西占着」以及「驱动没被识别」这两种假故障。直接跑下面的命令：

nvidia-smi
nvidia-smi -L
nvidia-smi `--query-gpu`=name,driver_version,memory.total,memory.used,memory.free `--format`=csv
python -c "import torch;print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))"

nvidia-smi 的默认输出分上下两块。上块每张卡一行，最左侧是显卡型号（Name），右上角标题行里带 Driver Version 和 CUDA Version，右侧的 Memory-Usage 是「已用 / 总量」。下块是进程表，每个进程一行，PID、Type、Process name 和占用的显存，Type 为 C 表示计算进程、G 表示图形进程。读的时候要同时看这两块：如果 Memory-Usage 已用明显偏高，而进程表里找不到你自己要跑推理的 python 进程，说明显存被别的残留进程占着；如果进程表里就是你自己上一次没退干净的 python，先把它结束掉再判断。

如果 nvidia-smi 直接报 could not communicate with the NVIDIA driver，或者 torch.cuda.is_available() 返回 False，那先别急着调分辨率，这属于驱动或运行库没被识别，需要先把这部分修好。也可以另开一个终端用 watch -n 1 nvidia-smi 持续观察占用变化，后文记录峰值还会用到。

把主模型、VAE、文本编码器按目录归位并核对文件大小

SD3.5 一般不是单文件，主模型、VAE 和多个文本编码器分开存放居多。加载阶段报错，往往是文件没放对位置或缺文件，而不是显存不够。

以常见的节点式界面为例，目录组织通常长这样：

models/
  checkpoints/        sd3.5_large.safetensors
  vae/                sd3.5_vae.safetensors
  text_encoders/      clip_l.safetensors
                      clip_g.safetensors
                      t5xxl_fp16.safetensors

如果是 diffusers 目录格式，则是一个文件夹里放 model_index.json 以及 transformer/、text_encoder/、text_encoder_2/、text_encoder_3/、vae/、tokenizer/ 等子目录。加载报错里出现的文件名，直接对应到上面的文件：报 t5xxl_fp16.safetensors not found 就是文本编码器没放或名字不对；报 no file named diffusion_pytorch_model.safetensors in directory 通常指向 diffusers 目录里 transformer 子目录不完整；报 VAE 相关文件名则说明 VAE 目录为空或路径没被扫描到。核对方式用 ls -lh 或 du -sh 看文件是否为零字节、是否被浏览器下成半截文件。

用最小分辨率跑通一张图，记录显存峰值

在调高分辨率之前，先拿到一个确定能出图的基线。建议的起步组合是：单张、512 边长、20 步左右、固定一个采样器、批次数 1，文本编码器先用较低精度的那份权重。参数写好后跑一张，只看能不能出图，不看画质。

跑的过程里用另一个终端执行 watch -n 1 nvidia-smi，观察 Memory-Usage 的已用值，记下出图前后的最高值，这就是你这套配置的显存峰值基线。界面自身的控制台日志通常也会打印加载和推理相关的行，可以对照着看是哪一步涨上去的。把「分辨率、批次数、步数、峰值」记成一行，后面每次改动都往这张表里加一行。

逐步提高分辨率与批次数，每次只改一个变量

基线跑通后，先只动分辨率：512、640、768 这样一档一档加，每次出图前固定同一个提示词和 seed，其他参数一律不动，出图成功才进下一档。分辨率摸到边界后再单独测批次数，1 张、2 张这样加，不要同时改分辨率和批次，否则爆显存时无法判断是谁导致的。

显存不足的报错通常出现在控制台的标准错误输出里，形式是 torch.cuda.OutOfMemoryError: CUDA out of memory，后面跟着 tried to allocate 的字节数和当前已分配量。界面式工具会在执行到具体节点时抛出并中断，命令行脚本则是整条 traceback 打到终端。报错里 tried to allocate 的那一行，就是当时正在申请显存的动作，配合你的对照表可以判断是分辨率涨的、还是批次涨的。

爆显存后按顺序回收：先降批次、再降分辨率、最后清进程

调整的代价从低到高排：

• 降批次。画质不变，只是单位时间出图数量下降，速度损失最小，所以放在第一位。
• 降分辨率。画面的细节和构图空间会一起变小，可能得重写提示词补构图；速度反而更快，属于用画幅换显存。
• 清进程重启。结束残留的 python 进程或重启界面，代价是要重新加载模型、等一次加载时间。这是止血手段，不是提速手段，不要把它当成性能方案。

每次调整后，用出问题时的同一提示词和同一个 seed 再跑一张，看是否能正常出图、画面是否正常（不是黑图、不是纯色块、没有明显破损）。能复现出正常结果，再继续往上试探；如果降到批次数 1、512 边长仍然报显存不足，那需要回头看文本编码器的精度选择和权重加载方式，而不是继续压分辨率。