本地加载 FLUX 3 Image Klein 时提示显存不足，通常是三档变量同时偏高：加载精度、输出分辨率、批大小与并发。更稳的顺序是先把问题拆成“加载阶段就爆”还是“采样阶段才溢”，再按精度、分辨率、批大小逐项回退，每次只动一个变量并留下记录。这样做的目的不是把参数调到最低，而是找到你这台机器上能稳定出图的一组配置，并且下次启动不必重头再试。

先看启动日志判断爆显存发生在加载权重还是采样过程：加载阶段爆，优先降精度档位；加载成功、采样中断，优先降输出分辨率。每改一项都用同一条提示词、同一个种子复跑，并记录加载后占用、峰值占用、耗时和是否中断。精度降到 fp16 或开启 CPU offload 会增加等待时间与内存占用，属于换取可用性的取舍，不是性能优化；回退到哪一档要以本机日志为准，不建议照搬他人配置。

在启动日志里定位显存被吃满发生在哪一步

先把“加载就爆”和“采样才爆”分开，否则容易一上来就把分辨率和精度一起调低，结果既看不出是哪一项起作用，又白牺牲了画质。判断依据是启动日志里出现到哪一行之后中断。

• 看到 Loading checkpoint shards 进度走完、紧接着报 CUDA out of memory，或进度条走到一半就断，说明卡在权重加载和显存分配阶段。
• 看到 Loading pipeline components 完成、日志出现模型就绪或开始采样（出现 step 进度条），然后才 OOM，说明卡在采样阶段的中间激活值上。
• 如果采样到固定步数才断，把步数也一并记下来，这是后面判断“分辨率上限”的参照点。

峰值出现位置建议用轮询记录，而不是凭印象。另开一个终端执行：

nvidia-smi `--query-gpu`=timestamp,memory.used,memory.total `--format`=csv -l 1 > vram.log

然后正常启动一次推理，中断后查看 vram.log，把显存抬升的时间点和终端日志的时间戳对齐，就能看出峰值是出现在“加载权重”区间还是“采样”区间。Windows 下没有这条命令习惯的，可以用 nvidia-smi -l 1 看滚动输出，或对着任务管理器性能页观察。这一步只做记录，不改任何参数。

把精度档位往下调一级，用同一条提示词重跑

如果定位结果是加载阶段就爆，优先动精度。模型权重的显存占用基本由参数量和权重数据类型决定，降一档 dtype 的影响通常比降分辨率更直接，代价是采样速度可能变慢、极少数情况下出图细节有轻微差异。

精度设置一般出现在三个位置之一，需要结合你实际使用的加载脚本确认字段名：

• 加载脚本里的 torch_dtype 参数，常见写法是 bfloat16 改成 float16。
• 模型目录下配置文件中的 dtype 或 torch_dtype 字段。
• 启动参数或环境变量，例如命令行开关、WebUI 设置页的精度下拉项。

# 通用接入骨架，参数名按实际加载器替换
pipe = Pipeline.from_pretrained(
    model_path,
    torch_dtype=torch.float16,   # 原为 bfloat16 时先只改这一项
    local_files_only=True,
)
# 若加载阶段仍爆，再考虑顺序 offload（更省显存但更慢）
# pipe.enable_sequential_cpu_offload()

对比方式：固定提示词、随机种子、采样步数和调度器，只改 dtype，各跑一次，记录加载完成后的静态占用、采样峰值、单张耗时、出图是否完整（检查有没有糊块或噪点残留）。两次记录放在一起，就能确认精度这一档到底值不值得降。

固定提示词只改输出分辨率，观察占用变化

如果加载正常、采样中途断，问题基本在分辨率和批大小上。先捏住其他变量：提示词、种子、步数、cfg 全部不动，只改宽高，从低到高逐档加，每档跑一次并记录。下面这张表建议直接抄成自己的记录模板，数值留空，跑一次填一次。

判断方式：第一次出现中断的前一档，就是当前精度和批大小组合下的可用上限；如果 S3 成功但 S4 中断，稳定出图就压到 S3，或者把 S4 拆成生成后放大。注意宽高最好保持模型推荐的边长档位（常用 64 的倍数），非标准尺寸有时会带来额外的对齐开销。

用批大小和并发数压住显存峰值

单张能出、连续出图就崩，多半是批大小或并发把峰值叠在了一起。批大小指一次前向里同时生成几张，并发指同时有多少个请求在跑，两者在显存上的效果相似，所以一次只能改一个。

• 接口调用侧看 num_images_per_prompt 或 batch_size，WebUI 侧要区分 batch count（跑几轮）和 batch size（每轮几张），压峰值的是后者。
• 服务化部署时限制 worker 数量，把并发先压到 1，确认单请求能连续多次成功，再放到 2 观察。
• 操作顺序建议：batch 设为 1、并发设为 1 跑通连续多次 → 只把 batch 提到 2 再跑 → 记完后再试并发 2。任何一步出现中断就退回上一档，不要同时调整。

把验证通过的组合写成一份本地配置档

试出来的结果如果只留在聊天记录里，下次启动还是从头试。把这一组值写成文件放在模型同级目录，启动时直接读取。

# local-profile.yaml（字段名按你的加载器调整）
model_path: /path/to/flux3-image-klein
precision: float16        # 已验证的精度档位
width: 1024
height: 1024
num_inference_steps: 28
batch_size: 1
max_concurrency: 1
cpu_offload: false        # 或 sequential，按验证结果填写

配置档里同时写清硬件条件，否则换机器就失去参考价值：显卡型号与显存容量、驱动与 CUDA 版本、系统、内存大小（开启 offload 时内存会被占用），以及这套配置验证通过时用的是哪条提示词和哪个种子。

复跑验证只要三步：结束所有占用显存的进程并确认显存回落到空闲水平；用配置档启动一次，在日志里核对实际生效的 precision、分辨率和 batch；用记录中的同一条提示词和种子出图，比对耗时、峰值占用以及图片是否完整。三项都对得上，这组配置才算可复用；任何一项不一致，说明配置没有真正被读取，需要先排查加载入口。