Z-Image-Turbo-FP8 原理揭秘：如何吃透 torchao 动态激活量化机制？

Z-Image-Turbo-FP8 是基于torchao 动态激活量化打造的 Z-Image-Turbo 文生图模型量化仓库：它把 6B 参数的 Diffusion Transformer 以FP8 / INT8两种低精度方案重新打包，显存占用大幅减半，而同种子渲染的 LPIPS 误差仅 0.130（FP8）与 0.181（INT8），几乎无损逼近 bf16 原版。本文带你完整拆解其实现机制。

一、背景：大模型推理为何需要量化？

Z-Image-Turbo 是单流 DiT（S3-DiT）架构的高效文生图模型，仅需8 步 NFE即可出图，但 6B 参数以 bf16 存储仍需约 12GB 显存，对消费级显卡并不友好。

量化（Quantization）的核心思路：用更少的 bit 存下相同的权重，用低精度指令做矩阵乘法。代价是数值精度下降，收益是显存减半、带宽减半、推理更快。

本仓库正是 Unsloth 团队用 torchao 框架做的"低精度工程化"：官方模型卡（见 README.md 上半部分）保持原样，下半部分则追加了预量化 checkpoint 的完整说明。

二、核心概念：动态激活量化是什么？

理解本仓库的关键，是区分两类量化对象：

所谓"动态激活量化"，指的是激活值的缩放因子（scale）不依赖离线校准数据，而是在前向传播中根据当前 token 的实际幅值现场计算：

• 每个 token（行）独立求自己的最大幅值，独立确定 scale；
• 大动态范围的输入不会"拖累"小数值 token 的精度；
• 相比静态激活量化（一次校准定终身），动态方案对输入分布漂移更鲁棒，因此几乎不需要校准数据集。

这就是 torchao 中*DynamicActivation*系列 Config 的命名含义。

上图：FP8 量化版 Z-Image-Turbo 生成样张，提示词 "cute sloth typing on a computer"，与 bf16 原版观感几乎一致。

三、FP8 与 INT8：两条量化路线对比

仓库同时提供 FP8 和 INT8 两套 transformer checkpoint，二者机制各有特点：

3.1 FP8 路线（Float8DynamicActivationFloat8WeightConfig）

• 权重格式：e4m3（8 位浮点，4 位指数 + 3 位尾数），动态范围大、精度友好；
• 激活缩放粒度：PerRow（逐 token 行）；
• 底层调用torch._scaled_mm，在支持 FP8 张量核心的 GPU 上获得硬件加速；
• 一个容易踩的坑：动态 scale 由行内最大幅值决定，若某行 token 激活全为 0，scale 会变成 0 导致非法运算。因此加载器必须给激活 scale 设置下界activation_value_lb=1e-12（torchao 0.13+），保证零行也不会产生零 scale。

3.2 INT8 路线（Int8DynamicActivationInt8WeightConfig）

• 激活：per-token动态量化为 INT8；
• 权重：per-channel量化为 INT8；
• 底层调用torch._int_mm，走 GPU 整数矩阵乘法指令，在更广泛的硬件上可用（无 FP8 张量核心也能跑）；
• 另有Z-Image-Turbo-INT8-ConvRot.safetensors变体，在 INT8 权重之外叠加了卷积维度的旋转处理，用于改善量化误差分布（仓库未展开说明，可视为进阶变体）。

3.3 质量代价实测

同种子下与 bf16 原版的 LPIPS 对比（越低越接近原版）：

结论：两者都可用，追求质量优先选 FP8；显卡较老、没有 FP8 硬件支持时选 INT8。

上图：另一张 FP8 样张（seed 不同），细节与构图均保持高水准。

四、预量化 checkpoint：省掉最贵的"现场量化"

很多动态量化框架是"先加载完整 bf16 权重、加载时现场量化"。本仓库直接跳过这一步：

• Z-Image-Turbo-FP8.pt/Z-Image-Turbo-INT8.pt（各 6.3 GB）就是量化后 transformer 的成品权重；
• README 明确保证：加载 checkpoint 与"从密集 bf16 transformer 现场量化"逐位一致（bit-identical）；
• 收益：免去 bf16 权重加载与量化过程，启动更快、峰值内存更低。

对应文件可在仓库根目录找到：Z-Image-Turbo-FP8.pt、Z-Image-Turbo-INT8.pt，每个方案还额外提供.safetensors格式的等价容器文件（如 Z-Image-Turbo-FP8.safetensors）。

验证环节同样严谨：在 torch 2.12.1 + torchao 0.17 上，与同种子 bf16 渲染对比了SSIM、LPIPS-vgg、CLIP delta，并做非有限值（NaN/Inf）与黑帧检查（详见 README.md）。

上图：INT8 方案的样张，与 FP8 版同提示词、不同种子，误差略大但仍高度可用。

五、FP8 Text Encoder：再砍掉 3.6 GB 下载量

除了 transformer，本仓库还有一个配套组件：预转 FP8 的文本编码器。

• 文件：Z-Image-Turbo-text_encoder-FP8.pt（4.4 GB），是 Z-Image-Turbo 的text_encoder子模块（Qwen3-4B，Qwen3ForCausalLM）；
• 它把加载时逐层 fp8 存储转换"预先做完"：399 个 tensor 中 252 个转为 fp8 存储，而 tied 的lm_head/embedding保持密集（它们参与 token 嵌入语义，转低精度不划算）；
• 效果：文本编码器下载量从8.0 GB → 4.4 GB，且与"下载密集编码器后加载时现场转换"逐 tensor 位一致；
• 它是纯 tensor 的 state dict，可用torch.load(weights_only=True)直接加载。

注意这里的机制与前文不同：text encoder 用的是存储时静态 cast（加载即 fp8 存储），而非 transformer 的动态激活量化——不同模块采用最合适的量化策略，是工程上的典型取舍。

上图：INT8 方案另一张样张，展示低精度权重下的整体出图稳定性。

六、仓库文件速查表

七、适用场景与小结

适合你，如果：

• 显卡显存 12~16GB 左右，想流畅跑 Z-Image-Turbo 文生图；
• 希望跳过 bf16 权重的加载与现场量化，直接拿成品低精度 checkpoint；
• 需要更少的模型下载体积（FP8 transformer + FP8 text encoder 组合）。

一句话总结：Z-Image-Turbo-FP8 展示了 torchao 动态激活量化的一套完整落地范式——权重离线量化 + 激活运行时逐 token 动态缩放 + 成品 checkpoint 逐位一致，在 FP8 路线下把 6B 文生图模型的显存与带宽开销近乎减半，同时把与 bf16 原版的视觉误差压到 LPIPS 0.130 的极低水平。