Z-Image SD.Next 集成与动态量化完全指南：SDNQ 自动量化技术
当 WebUI 老将遇上 Z-Image
Stable Diffusion WebUI 用户对 SD.Next（vladmandic 开发，GitHub 7.2k+ Star）并不陌生——这个 Automatic1111 WebUI 的现代化分支以「全平台、全模型」著称：支持所有 GPU、iGPU、CPU 甚至 NPU，内置模型下载器，还集成了自研的 SDNQ 量化引擎。
2026 年 1 月 20 日发布的 SD.Next 首个 2026 版本带来了一项对 Z-Image 用户意义重大的更新：原生集成 Nunchaku 优化的 Z-Image Turbo（INT4 量化推理），以及 SDNQ 动态量化方法——系统可以自动为模型的每一层选择最佳量化方案。本文基于 SD.Next 官方发布说明、SDNQ Quantization Wiki（164 次修订）与社区实践，完整解析这套「一键量化」工作流。
为什么量化对 Z-Image 至关重要
Z-Image 是 6B 参数的 S3-DiT 扩散 Transformer，BF16 权重约 12GB+，FP16 推理在消费级显卡上显存吃紧。量化是低显存部署的核心手段：
| 方案 | 显存占用 | 说明 |
|---|---|---|
| BF16 原生 | 12GB+ | 基准线 |
| FP8 | ~6GB | 画质几乎无损 |
| INT8 | ~6GB | SDNQ 默认方案，速度快、画质接近 |
| INT6 | ~4.5GB | 略省显存，画质损失小 |
| UINT4 | ~3.5GB | 最省显存，画质与速度有所下降 |
SDNQ 的目标：让用户不需要理解这些细节——告诉引擎你的显存预算，它自动决定每层怎么量化。
SDNQ：从固定量化到动态量化
传统量化的问题
固定量化（如全部 INT8）把所有层一刀切：对冗余高的层浪费了精度，对敏感层又损失了质量。不同层对量化的敏感度差异巨大——注意力层、FFN 层、归一化层的容错能力各不相同。
动态量化（Dynamic Quantization）
SD.Next 2026-01-20 版本新增的 SDNQ 动态量化方法：
SDNQ 可以动态地为每个模块层确定最佳量化方法。逐层即时量化较慢，但能以最小的资源占用获得更好的质量。
工作机制：
- 基于 Dynamic loss threshold（动态损失阈值）逐层评估
- 当前设置的
Quantization type作为允许的最低量化精度（即各层只能量到「不低于」该精度的水平） - 对每一层测试不同量化类型，选择满足质量阈值的最优方案
- 代价：模型加载时量化更慢；收益：质量更高、整体资源占用更小
量化类型库
SDNQ 支持 1-bit 到 16-bit 的量化，涵盖整数、无符号整数、浮点、无符号浮点四大类，总计 176 种量化方案（33 种整数 + 143 种浮点）。UI 出于简洁只暴露常用项，API 和脚本可以使用全部类型。
常用类型参考：
| 类型 | 打包方式 | 取值范围 |
|---|---|---|
| int8 | int8 | -128 ~ 127 |
| int6 | 4×int6 → 3×uint8 | -32 ~ 31 |
| int4 | 2×int4 → 1×uint8 | -8 ~ 7 |
| uint4 | 无符号对称/非对称 | 0 ~ 15 |
| float8_e4m3fn | FP8 主流格式 | 约 ±448 |
对称 vs 非对称：无符号（unsigned）量化无法直接存负数，依赖 zero-point，较慢；对称量化无需 zero-point，通常更快。8-6 bit 时两者质量差异极小；5 bit 以下建议使用非对称。
安装与配置指南
安装 SD.Next
git clone https://github.com/vladmandic/sdnext.git
cd sdnext
./webui.sh # Linux/macOS；Windows 使用 webui.bat
首次启动后，在 Settings → Quantization Settings 下找到 SDNQ 菜单。
加载 Z-Image 模型
- 从 HuggingFace 下载 Z-Image 权重（BF16 safetensors 或社区预量化版本）
- 放入
models/Stable-diffusion/目录（SD.Next 自动识别） - 或在 UI 的模型列表中直接选择 Z-Image 参考模型自动下载
SDNQ 关键设置
1. 量化目标（Quantization enabled） — 默认 none，推荐 Model + TE：
| 选项 | 目标 | 说明 |
|---|---|---|
Model |
扩散模型 | 主要显存消耗点，必开 |
TE |
文本编码器 | 推荐开启 |
LLM |
Prompt Enhance 用的 LLM | 按需 |
Control |
ControlNet | 按需 |
VAE |
VAE | 不推荐（VAE 对精度敏感） |
⚠️ 若开启 VAE 量化且使用 FP16，必须将 VAE Upcast 设为 false；SDXL 出现黑图时使用 FP16 Fixed VAE。
2. 量化模式（Quantization mode） — 默认 auto：
| 模式 | 行为 | 适用 |
|---|---|---|
auto |
自动为每个模型选择 pre/post | 推荐 |
pre |
加载过程中量化，降低系统 RAM 占用 | DiT/视频模型（Flux、Z-Image） |
post |
加载到 RAM 后再量化 | 旧式 UNet 模型（SDXL 仅兼容此模式） |
Z-Image 是 DiT 架构，pre 模式完美兼容——加载时直接量化，RAM 占用最小。
3. 量化类型（Quantization type） — 默认 int8：
| 类型 | 画质 vs 16-bit | 显存节省 |
|---|---|---|
| INT8 | 非常接近 | 2× |
| INT6 | 接近 | 2.7× |
| UINT4 | 较低 | 3.6× |
| FP8 (float8_e4m3fn) | 接近 INT6 | 同 INT8 |
4. 动态量化：勾选 Dynamic Quantization，设置 Dynamic loss threshold——启用后每层自动选择最优量化类型，当前量化类型作为最低允许精度。
5. 性能选项（强烈推荐）：
Dequantize using torch.compile：Triton 可用时大幅提升性能（NVIDIA/AMD/Intel Linux 内置；Windows 需手动安装）Use Quantized MatMul：在支持 INT8/FP8/FP16 的硬件上显著加速
SDNQ vs 固定量化：性能对比
| 维度 | 固定量化（INT8 全层） | SDNQ 动态量化 |
|---|---|---|
| 加载时间 | 快 | 较慢（逐层评估） |
| 生成质量 | 取决于最敏感层 | 更好（每层最优） |
| 显存占用 | 固定 | 最小化（按需分配精度） |
| 使用难度 | 需手动调参 | 一个开关 |
SD.Next 官方宣称：SDNQ 可实现最高 4× 显存缩减，且几乎无质量与性能损失。
Nunchaku Z-Image Turbo：另一条加速路径
2026-01-20 版本还集成了 Nunchaku Z-Image Turbo——使用 SVDQuant（ICLR 2025 Spotlight）的 4-bit 量化推理，面向 NVIDIA Blackwell 及前代硬件。SD.Next 提供：
- Nunchaku 优化版 Z-Image Turbo（INT4/NVFP4 预量化变体）
- 与 SDNQ 互补：Nunchaku 侧重特定硬件加速，SDNQ 侧重通用全平台量化
- 注意：Nunchaku 模型需要预发布版
transformers，启动参数加--experimental
常见问题
Q1：为什么我改了量化设置但没生效？
设置只对之后加载的模型生效——改完设置后重新加载模型（Reload）。
Q2：SDXL 模型量化后出黑图？
SDXL 仅兼容 post 模式；若仍异常，检查 VAE Upcast 设置，或换用 FP16 Fixed VAE。
Q3：Windows 上性能提升不明显？
Triton 在 Windows 需要手动安装；安装后勾选 Dequantize using torch.compile 和 Use Quantized MatMul。
Q4：动态量化加载太慢怎么办？
动态量化逐层评估确实更慢——如果模型较大且频繁切换，可先用固定 INT8 起步，需要极致质量时再开动态。
Q5：Z-Image Turbo 与 Base 用哪个量化类型？
Turbo 建议 INT8 或 FP8（保留蒸馏质量）；Base 可放心用 INT6 甚至 UINT4。
总结
SD.Next 的 SDNQ 动态量化把「每层选择最优精度」这一专家级优化自动化了：176 种量化方案、1-bit 到 16-bit、pre/post 双模式、最高 4× 显存缩减——而 Z-Image 作为 DiT 架构模型，正好吃满 pre 模式 + 动态量化的全部红利。加上 Nunchaku Z-Image Turbo 的集成，SD.Next 已成为 Z-Image 用户在 WebUI 生态中的首选入口：一句「开启动态量化」，剩下的交给引擎。