SD.cpp新版本：三款新模型本地出图与编辑实战

最近把 Stable Diffusion.cpp 拉到最新版之后我发现自己手里的“本地出图工具箱”又变厚了一层。这次更新直接把三款新模型的跑法并进了主仓库Z-Image、FLUX.2-dev、Qwen-Image-Edit。对于一直想把生成和编辑都留在本地的玩家来说这是三个方向同时补强——轻量级高速出图、新架构大模型推理、以及真正的指令式图像编辑。这篇文章不聊套话我把这三款模型在 SD.cpp 里的支持情况、资源占用、实测参数和踩过的坑一次性整理清楚。先说结论如果你之前只用 SD.cpp 跑 SD1.5/SDXL这次升级的收益很大如果你已经在用 FLUX.1-dev 但嫌速度慢FLUX.2-dev 和 Z-Image 值得分别尝尝口味如果你经常做局部重绘、物体替换这类活Qwen-Image-Edit 的接入方式会改变你的图像编辑工作流。下面按模型逐个拆。1. 新版本整体变化与编译准备1.1 一次支持三款模型的底层原因Stable Diffusion.cpp 一直以来的定位很明确用 GGUF 量化把这些吃显存的图像模型压到普通消费级硬件能跑的程度。这次更新的底层逻辑也没有变但技术上有一个明显的转向——它不再只是处理 UNet 架构的模型而是对 DiTDiffusion Transformer和多模态输入做了更完整的适配。Z-Image 是典型的流匹配 DiTFLUX.2-dev 也是 Transformer 路线Qwen-Image-Edit 还需要同时解析“参考图 文本指令”两类输入。这三者在同一版本里落地说明 SD.cpp 的模型加载层和采样调度层都做了通用化重构。说白了之前跑 FLUX.1 那种“一个模型一个适配器”的做法已经撑不住了新版本的代码更像一个通用运行时只要你把模型转成 GGUF喂给它正确的文本编码器和 VAE它就能按格式跑起来。这给用户带来的直接好处是以后新模型出来适配速度会比以前快很多不需要等太久就能在本地尝鲜。1.2 编译细节与二进制选择如果你是从源码编译的老手这次基本还是老三样git clone https://github.com/ggml-org/stable-diffusion.cpp cd stable-diffusion.cpp cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j$(nproc)需要提醒的是新版对 CMake 版本和编译器有最低要求建议用 CMake 3.20macOS 上记得 Xcode Command Line Tools 保持新版。我编译时遇到过老版本编译器在 OpenMP 汇报环节直接崩掉的情况后来升级了 gcc 版本就正常了。如果你不想编译直接用 GitHub Releases 里的预编译包也可以。Windows 用户注意区分 CPU 版本和带 CUDA 的版本新版 release 页面会同时给出带 vulkan、cuda、metal 后缀的二进制按你机器实际情况选。注意这次新模型对文本编码器的依赖很重FLUX.2-dev 和 Z-Image 都建议同时下载对应的 CLIP-L/T5 编码器 GGUF 文件只装主模型文件会在加载阶段直接报错。不同硬件的显存或内存占用不同但编码器文件通常只有几百 MB不要省这个空间。2. Z-Image轻量高速出图的新选择2.1 模型定位与架构特点Z-Image 是阿里系开源社区近期重点推的扩散模型主打的就是“低步数出图 高效推理”。它和 SD3.5、FLUX.1 一样走 transformer 路线但在采样步骤上做了优化——官方推荐最少的推理步数可以压到个位数这对于本地实时出图或者批量抽卡场景非常友好。我实际用下来的体感是Z-Image 对真实摄影、游戏原画、产品渲染三类题材的掌控力比 SDXL 好得多构图稳定性和光影一致性明显更强。它不像 FLUX.1 那种“用力过猛”的厚重质感整体画面更干净清爽和小尺寸提示词的理解能力也算同档位第一梯队。当然它的定位不是面面俱到的全能王。如果你需要超精细的复杂场景Z-Image 的高频细节和 FLUX.2-dev 比还是有一点差距。但绝大多数日常需求它已经完全够用而且速度快到可以让你的迭代焦虑大幅缓解。2.2 在 SD.cpp 里跑 Z-Image 的配置与采样参数SD.cpp 里跑 Z-Image 需要三类文件Z-Image 主模型转好的 GGUF 格式比如 fp16、q8_0 或 q4_k_m文本编码器 GGUF一般用 CLIP-L 和 T5-XXLVAE 文件部分 GGUF 合包里已经内嵌了 VAE不需要额外指定核心命令大致长这样sd -m z-image-q8_0.gguf \ --clip-l clip_l.gguf \ --t5xxl t5xxl_fp16.gguf \ --vae vae.gguf \ -p a cinematic photo of a samurai walking through neon-lit tokyo street, rain reflections, 35mm \ --cfg-scale 2.5 --steps 8 -H 1024 -W 1024 \ --sampling-method euler --seed 42几个关键参数我实测下来的取值区间参数推荐范围说明steps6~12低步数就能出图追求速度用 6质量优先用 10~12cfg-scale2~3.5Z-Image 对 CFG 偏敏感太高容易过饱和采样器euler / dpmpp_2m低步数下 euler 更稳定分辨率128 倍数从 768x768 到 1024x1024 都能稳定发挥这里有个容易误解的点低步数不等于可以乱关 CFG。很多人看到官方说“低步数”就把 cfg-scale 拉到 1.0结果出图发灰、结构松散。CFG 该给还要给只是 Z-Image 不像 SD1.5 那样需要 7~9 的激进值2.5 左右基本是最稳的比例。另外负面提示词的写法对这个模型同样有效。虽然 FLUX 系模型对负面提示词基本无感但 Z-Image 和 SD 系列的兼容度更高加“low quality, blurry, distorted”这类词确实能少出废卡。2.3 实测速度参考在我一台 4090 24GCUDA 版 SD.cpp上用 q8_0 量化、1024x1024、8 steps、batch 1单张出图时间大约在 1.5~2.5 秒。同样的参数换到纯 CPU32 线程大概需要 20 秒左右已经完全可以接受。16GB 内存的 MacBook Pro 上走 Metal 加速单张大约 6 秒。如果要用它大量出图建议把--batch-count加上去比如一次跑 8 张整体耗时比起逐张生成能省下 20% 左右因为算 VAE 和采样器的固定开销被摊薄了。3. FLUX.2-dev本地跑 22B 级大模型的优化实践3.1 FLUX.2-dev 与 FLUX.1 的核心变化FLUX.2-dev 是 Black Forest Labs 的下一代开源模型dev 版本在权重开放和可商用授权上有明确目标。相比 FLUX.1 系列FLUX.2-dev 在几个维度做了明显升级更强的指令遵循能力长提示词的语义切分和组合关系更准对排版、文字渲染有改进但本地量化后效果要打折采样步数需求降低官方流程推荐步数比 FLUX.1 少支持图像编辑输入这也是 SD.cpp 里它能和 Qwen-Image-Edit 形成互补的原因架构上它依然属于多模态混合的 transformer 扩散模型参数量到了 22B 级别。这比 FLUX.1-schnell 的 12B 大了一圈本地推理压力确实上来了但 GGUF 量化的意义也正在这里只要量化策略得当16GB 内存设备依然可以流畅运行。3.2 显存占用分析与量化选择FLUX.2-dev 最大的争议点是“本地到底能不能跑”。我用不同量化做了组测试数据如下量化格式主模型体积CPU 内存占用生成速度4090/CUDA生成速度32线程 CPUfp16约 44GB48GB不推荐不推荐q8_0约 23GB约 27GB6s/it极慢q4_k_m约 12.5GB约 16GB3s/it25s/itq4_0约 12GB约 15GB3.2s/it23s/it我这里说的生成速度是按“单次采样迭代”估算的实际一张图要乘总步数。用 q4_k_m、30 步、1024x10244090 上大概 60~90 秒出图。听起来确实不快但注意这期间显存占用可以控制在 13GB 左右显卡压力并不算极限。如果你把步数降到 20出图时间可以压缩到 50 秒内画质损失在可接受范围内。建议内存 16GB 的机器用 q4_0 或 q4_k_m内存 32GB 的可以尝试 q8_0。内存 8GB 的机器不建议硬跑 FLUX.2-dev这个模型的主模型文件加文本编码器就已经把内存吃满了即使勉强加载也会因为内存交换导致速度骤降。3.3 提示词写法和采样参数建议FLUX.2-dev 延续了 FLUX 世代的特点对负面提示词不敏感关键在正向提示词的结构。一个高质量的正向提示词通常包含“题材主体 场景环境 光线材质 镜头语言 风格限定”五层信息。我习惯的模板[主体描述], [环境与背景], [光线与氛围], [镜头与构图], in [风格/媒介], high detail, sharp focus具体例子a small cozy cabin in snowy pine forest, warm yellow light glowing from windows, gentle snowfall, blue hour, cinematic composition, viewed from across the lake, photorealistic, high detail, sharp focus采样方面FLUX.2-dev 用 euler 采样器配合 20~30 步比较稳妥。cfg-scale 推荐 1.0~4.0 之间。注意 FLUX 系列训练时大量使用了无分类器引导所以 cfg-scale 为 1.0 也能出合理结果想在构图上更“用力”一点就拉高。这里有一个很多人忽略的点FLUX.2-dev 在 SD.cpp 里跑的时候文本编码器加载方式可能让 CPU 满载一次第一次生成会特别慢。这个不是模型出问题而是 T5-XXL 编码器权重在初始化跑完第一张后速度就正常了。4. Qwen-Image-Edit把图像编辑的主战场搬进命令行4.1 图像编辑模型与重绘模型的本质差异以前我们在本地做图像编辑最“传统”的方式是 SD 的 inpaint 模型你把图像送进去给它一张 mask告诉它“这里换成什么”。这种做法的问题是你得先备好蒙版而且模型只能改你遮住的区域改完的区域和周围环境经常融合得不好。Qwen-Image-Edit 不一样它的核心是“指令式编辑”。你不用做蒙版直接把一张图和一句“把背景里的车换成红色的卡车”喂给它它会自己理解位置、区域和编辑目标然后输出一张改好的完整图像。这种交互方式更接近日常和助手对话非常适合快速改图、替换物体、调整风格等场景。它本质上是从 Qwen-Image 续训练出来的编辑模型保留了生成质量同时加入了多模态输入理解能力。SD.cpp 里对它的支持意味着这些能力全部可以跑在本地不需要上传图片数据隐私这块的顾虑也少了很多。4.2 命令行实际操作与提示词思路在 SD.cpp 里使用 Qwen-Image-Edit基本命令和图像生成很像但输入部分多了图像路径。sd -m qwen-image-edit-q5_k_m.gguf \ --clip-l clip_l.gguf \ --t5xxl t5xxl_fp16.gguf \ --image input.png \ -p 把图片里的黑色手提包替换成棕色皮质公文包保持光影一致 \ --cfg-scale 3.0 --steps 25 \ --sampling-method euler -H 1024 -W 1024 \ --seed 777实际跑的时候注意几个问题输入图像分辨率不要强行拉到 2048编辑模型训练时一般以 768/1024 为主输入过大容易产生重复纹理提示词建议用完整的指令句式而不是单纯的关键词堆砌。比如“把猫从沙发上移到窗台上”这种带动作地点描述的方式比写“猫 沙发 窗户”更不容易翻车如果你想保持画面其他部分不变编辑指令尽量只描述需要改变的部分不要大范围描述背景不然模型可能顺手把背景细节重画成功率方面单物品替换、服装换色、背景替换这三类场景最可靠。如果是多个物体同时编辑或要求精准保持原物体形态模型偶尔会出现结构漂移属于正常现象重抽几次就能选到满意结果。4.3 结合其他模型做复合流程Qwen-Image-Edit 的另一个用法是和其他模型联动。比如我用 Z-Image 抽了一批底图然后挑出一张构图满意的再用 Qwen-Image-Edit 把画面里的杂物清理掉最后用 FLUX.2-dev 做放大和细节增强。整个过程全在命令行里完成批量处理非常顺手。这也是我最近最推荐的本地图像工作流Z-Image 快速出图找构图Qwen-Image-Edit 做局部修改和元素替换FLUX.2-dev 出最终的精细版本三个模型侧重点不同互相之间互补性很强。如果你想把它们串成一个自动化流程SD.cpp 的命令行特性也适合写脚本批量调用后面甚至可以接一个简单的 API 层让本地工具变成团队内可用的图片工作台。5. 三款模型的横向对比与硬件调优5.1 同硬件环境下的表现对比为了照顾不同机器的情况我先给一个相对通用的对比维度。这里以 16GB 显存、32GB 内存的中等配置为基准模型量化推荐主流出图分辨率单张耗时量级关键词优势适合场景Z-Imageq8_0 / q4_k_m768~1024秒级低步数高速批量抽卡、快速迭代FLUX.2-devq4_k_m / q8_0768~1024几十秒级细节、指令遵循最终成品、复杂构图Qwen-Image-Editq5_k_m / q8_0768~1024十几秒级指令编辑、局部修改改图、物体替换如果你主要追求数量和速度Z-Image 无疑是最佳选择如果你追求单张图的画质和精确度FLUX.2-dev 更合适如果核心需求是“把一张已有的图改明白”那就直接用 Qwen-Image-Edit。很多人会纠结“我到底该下载哪个模型”我建议干脆三个都下反正 GGUF 体积可控硬盘里不至于装不下。不同模型对应不同任务按需切换比只留一个大而全的模型聪明得多。5.2 不同硬件的推荐配置与启动参数这里把常见硬件分成三档给出实际可用的启动参数建议第一档8GB 显存 / 16GB 内存这一档跑 FLUX.2-dev 会很紧张建议只跑 Z-Image 和 Qwen-Image-Edit主模型都用 q4 量化。同时把文本编码器尽量放显存之外SD.cpp 会自动做 offload你只需要在启动时通过--threads控制 CPU 线程数防止编码器和采样器争抢资源。sd -m z-image-q4_k_m.gguf --clip-l clip_l.gguf --t5xxl t5xxl_q8_0.gguf --threads 8第二档16GB 显存 / 32GB 内存这是目前性价比最高的一档。三款模型都能跑FLUX.2-dev 用 q4_k_m 量化后可以流畅操作。建议在运行 FLUX.2-dev 时加--vae单独指定 VAE不要依赖合包里的内嵌 VAE部分合包的 VAE 精度偏低最后出图会偏肉。用--raw这个标志位也可以配合做后处理但不是必须。第三档24GB 显存 / 64GB 内存这一档基本什么都不缺FLUX.2-dev 可以用 q8_0 量化细节保留更好速度也够快。如果你主要用 Z-Image 做高并发批量出图可以把--batch-count 32加上配合--init-img和种子控制做一套稳定出图流水线。注意无论哪一档第一次加载 T5-XXL 编码器时都会有明显的等待时间这是正常现象。建议在正式出图前先跑一条短提示词预热把编码器加载的内存页缓存好后续生成速度会稳定得多。6. 使用过程中的常见问题与避坑经验6.1 常见问题速查表现象可能原因解决方案加载模型时报“failed to load model”主模型 GGUF 与当前 SD.cpp 版本不兼容更新 SD.cpp 到最新版确认下载的是专为 SD.cpp 转换的 GGUF出图全是灰度或噪点VAE 丢失或不匹配单独指定正确 VAE 文件并使用--vae参数提示词写了但画面完全不执行cfg-scale 过低或步数太少提高到 2.0 以上Z-Image 至少 6 步FLUX 至少 20 步显存占用比预期高文本编码器被同时加载到显存检查是否有--clip-on-cpu或--t5-on-cpu参数把编码器 offload 到内存同一张图隔很久重跑效果不一致缺少固定种子加--seed 固定数值Qwen-Image-Edit 编辑时把整张图重绘了提示词描述了全局信息边界被模型扩展精简提示词只描述需要修改的位置和内容FLUX.2-dev 第一次生成特别慢T5-XXL 编码器初始化先跑一条短提示词预热后续恢复低步数出图出现色彩断层采样器选择不当改用 dpmpp_2m 或调高步数到 10 以上6.2 几个值得单独说说的坑第一个坑不要盲目追求最高量化档位。很多人想当然觉得 q8_0 一定比 q4_k_m 好但在 FLUX.2-dev 这种超大模型上q8_0 不仅占更多内存单张出图时间也比 q4_k_m 长一倍多而画质提升肉眼几乎看不出来。除非你内存非常充足且对画质有极致要求否则 q4_k_m 是性价比最高的选择。第二个坑相同参数下不同采样器的结果差异比想象中大。我拿 Z-Image 专门测过同一提示词、同种子、8 步euler 和 dpmpp_2m 的构图会差很多dpmpp_2m 在低步数下容易出破碎线条而 euler 稳得多。所以如果你对某个采样器跑出的结果不满意先别急着改提示词换成 euler 或 ancestral比如 euler_a再说。第三个坑Qwen-Image-Edit 的输出尺寸最好和输入图保持一致或接近。如果你给它一张 2048x2048 的大图却把输出参数写成 512x512模型会重新构图而不是做编辑画面里的物体位置、大小全部会乱。编辑任务里输出分辨率尽量沿袭输入分辨率。第四个坑很多人不知道 SD.cpp 会缓存已加载的模型。如果你同时切换多个模型比如先跑了 FLUX.2-dev 再跑 Z-Image内存可能不会立刻释放干净导致第二次加载时报内存不足。最稳妥的方法是每个模型跑完直接重启进程或者在命令里加--skip-load相关参数按需加载。最后再分享一个我日常最常用的小技巧给每条生成命令都固定写一个注释文件或者用 shell 脚本批量跑多组种子和提示词。SD.cpp 的 CLI 天然适合这种批量模式我会把提示词、种子、模型路径、参数写进一个 yaml 或 txt然后循环调用命令最后用简单脚本把结果图和参数合并输出。这套方法用顺手之后无论是抽卡、修图还是换风格效率都能上涨一大截。