Nunchaku Diffusers 支持降低显存占用，但硬件仍决定适用范围
- Sophie Larsen
- 2天前
- 讀畢需時 12 分鐘
Nunchaku Diffusers 支持现已上线，可原生加载 4 位检查点，从此前需要专门配置的工作流中移除了独立推理引擎。Hugging Face 表示，新的 Nunchaku Lite 路径最多可将峰值显存占用降低 50%，同时加速推理。
这项重要变化并非只是增加了另一种量化选项。Diffusers 现在可以识别 Nunchaku 检查点、替换指定的线性层、下载兼容内核，并通过 from_pretrained() 加载流水线。
这种便利性给现有的仅权重量化低显存推理方案带来了压力。bitsandbytes、GGUF、torchao 和 Quanto 等后端已经能在 Diffusers 内压缩权重。然而，它们通常会在计算过程中将这些权重恢复至更高精度，因此内存节省并不会自动转化为更低的延迟。
相比之下，Nunchaku 在 transformer 中计算开销最高的操作上同时采用 4 位权重和 4 位激活。Hugging Face 报告称，在其基准测试中，未经编译即可实现约 30% 的速度提升，同时显著降低内存占用。
代价则是硬件覆盖范围。速度最快的 NVFP4 检查点需要 NVIDIA Blackwell GPU，而受支持的较旧显卡则需要 INT4 变体。部分数据中心架构仍不受支持。
Nunchaku Diffusers 支持改变了加载路径
核心变化体现在操作方式上：Nunchaku 检查点现在的行为与常规 Diffusers 仓库相同，不再需要并行运行时。
开发者可以安装较新版本的 Diffusers、Transformers、Accelerate、kernels 和 bitsandbytes。随后，兼容的流水线便可使用其标准流水线类和 from_pretrained() 加载。
Hugging Face 的 Nunchaku Lite 示例使用了 ERNIE-Image-Turbo 检查点。该流水线将模型发送至 CUDA，并生成一张 1024 × 1024 的图像，无需在本地编译 CUDA 代码。
首次运行时，系统会通过 kernels 包从 Hugging Face Hub 下载所需的 GPU 内核。这使部署从引擎安装问题转变为检查点选择问题。
量化仓库会在 transformer 配置中包含一个 quantization_config 块。该配置块标识每个目标模块及其量化方案、精度、分组大小和任何低秩校正。
Diffusers 会在加载检查点权重之前读取配置。它将普通的 torch.nn.Linear 模块替换为正确的 Nunchaku Lite 运行时层，然后把量化值放入这些替代层中。
两种主要层类型分别服务于扩散 transformer 的不同部分。SVDQ W4A4 层对计算开销较高的注意力投影和多层感知机投影使用 4 位权重与激活。
AWQ W4A16 层则结合了 4 位权重与 16 位激活。它们面向对精度敏感但计算量较低的调制投影和自适应归一化投影。
这种划分非常重要，因为统一量化可能损害质量或浪费优化工作。Nunchaku Lite 将更激进的执行路径分配给低精度最能节省时间的操作。
加载后的模型会保留 Diffusers 所期望的模块结构。因此，调度器、LoRA 钩子、卸载函数和编译工具都能通过熟悉的接口与其交互。
这正是原生支持的实际价值所在。团队可以保留外围流水线代码，同时将密集型 transformer 替换为兼容的量化检查点。
原生加载也让分发变得更加容易。发布者可以将 transformer、其量化元数据以及其余流水线组件打包到常规 Hub 仓库中。
用户仍然需要正确的软件和 GPU。不过，他们在测试模型之前不再需要将应用迁移到特定于引擎的流水线。
这降低了个人开发者和平台团队的集成成本，也让 Nunchaku 能够使用位于去噪 transformer 之外的 Diffusers 功能。
仅降低内存占用已不再足够
Nunchaku Lite 将推理速度和内存使用视为同一个问题，从而提高了量化技术的标准。
大型文生图流水线往往还未生成第一张图像，就已经让消费级 GPU 不堪重负。Hugging Face 表示，现代 BF16 流水线可能需要 20 至 30 GB 显存。
BF16（即 bfloat16）使用 16 位存储每个值。它在数值范围与计算效率之间实现了良好平衡，但其内存占用限制了本地部署。
仅权重量化解决了这一限制的一部分。它以较低精度（通常为 4 位或 8 位）存储模型权重，同时让激活和计算保持较高精度。
这种方法可以显著缩小存储模型和驻留权重的体积。然而，在推理过程中反量化权重会增加额外工作，而激活仍可能占用大量内存。
延迟可能保持不变，甚至略有增加。用户得到的是一个能够装入显存的模型，但并不一定响应得更快。
Nunchaku 的 W4A4 路径改变了这一计算方式。W4A4 意味着指定 transformer 操作的权重和激活都使用 4 位表示。
在内存中传输的数据更少，而且受支持的内核能以压缩形式完成更多工作。因此，去噪循环可以在更快完成的同时消耗更少显存。
这种方法以扩散 transformer 为目标，因为其注意力投影和前馈投影主导了执行过程。这些重复层为专用低位矩阵乘法路径创造了巨大的优化空间。
该方法不会以完全相同的方式量化每个组件。文本编码器、归一化层和调制投影可能有着不同的性能与准确性需求。
Nunchaku Lite 可以将其 transformer 与 bitsandbytes NF4 文本编码器搭配使用。NF4 是一种为近似服从正态分布的值设计的 4 位格式。
Hugging Face 表示，在其基准测试中，量化文本编码器将峰值显存占用降低了约 22%。这部分节省是在 transformer 低精度路径的基础上进一步实现的。
这一结果在一个重要方面给仅权重量化后端带来了压力。内存缩减正在成为基础功能，而真正有用的速度提升则成为差异化因素。
这并不意味着现有后端已经过时。它们支持不同的模型、设备、精度选项和部署环境。其中一些目前提供的硬件兼容性比 Nunchaku Lite 更广。
当激活量化会损害输出质量时，仅权重量化方法也更容易应用。当让模型装入显存比最大化吞吐量更重要时，它们依然很有价值。
尽管如此，原生 W4A4 支持改变了开发者必须进行的比较。选择不再只是密集精度与压缩内存之间的权衡。
团队必须比较内存、去噪延迟、编译时间、硬件可用性、兼容性和图像质量。Nunchaku Diffusers 支持将这些维度整合进一个广泛使用的库中。
这种集成也提高了其可见度。即便从未采用原始 Nunchaku 引擎的开发者，现在也可能在浏览标准 Diffusers 检查点时接触到这种格式。
SVDQuant 将棘手数值移出 4 位路径
其速度和内存方面的优势取决于 SVDQuant 将数值离群值从以 4 位运行的工作中分离出来。
扩散 transformer 难以量化，因为其权重和激活中可能包含较大的离群值。单个粗粒度缩放因子必须同时表示常见值和异常极值。
当这一范围变得过宽时，普通的 4 位舍入就会丢失有用细节。图像结构、文本渲染、纹理或提示词对齐都可能劣化。
SVDQuant 通过将激活离群值转移到权重中来解决这一问题。随后，它使用一个小型 16 位低秩分支表示每个权重矩阵中最难处理的部分。
剩余残差则可以使用 4 位权重和激活。这样既能压缩计算开销较高的主路径，又能为难以量化的信息保留一条更高精度的路径。
SVDQuant 论文介绍了这种分解方式以及 Nunchaku 背后的系统设计。其目标并不仅仅是缩小检查点体积。
原始 Nunchaku 引擎会将低秩校正与周围的 4 位计算融合。内核融合会合并原本需要单独启动并通过内存传输中间值的操作。
低秩下投影与输入量化相结合，相应的上投影则与 4 位矩阵乘法相结合。
这些融合有助于防止 16 位校正分支抵消 W4A4 执行带来的优势。它们也解释了为什么专用内核与量化权重同样重要。
Nunchaku Lite 保留了核心 SVDQuant 层，但采用了更通用的集成路径。它会修补普通 Diffusers 模块，而不是用特定于架构的引擎替换整个流水线。
通用性会引入额外开销。原始引擎可以根据某一模型系列的精确结构来合并操作，而 Lite 路径则必须遵循标准 Diffusers 模块。
注意力机制就是一个明显的例子。某些优化实现会将查询、键和值投影合并为一个分组操作。
普通 Diffusers transformer 可能会将这些投影存储为独立模块。通用加载器并不总能推断出融合检查点如何映射到这种结构。
Nunchaku Lite 通过其量化配置处理结构简单的模块。结构性重写仍然需要特定于模型的目标配置和一个小型运行时适配器。
Hugging Face 将融合的查询、键和值投影列为此类情况之一。适配器必须指定张量顺序，以及分组参数如何映射到目标模块。
这一边界界定了该集成的真正贡献。原生加载使常见的 Nunchaku 风格检查点具备可移植性，但并未消除特定于架构的优化工作。
Lite 设计以损失部分速度为代价，换取更广泛的模型支持和熟悉的 API。Hugging Face 表示，即使没有特定于架构的融合，基础实现仍能带来约 30% 的性能提升。
编译可以通过合并重复的图操作来减少部分剩余开销。然而，它会增加一个准备步骤，并依赖稳定的计算图捕获。
这就是为什么 Nunchaku Diffusers 支持代表的是机制变化，而不是一种新的文件格式。量化值、运行时层、可下载内核和配置元数据共同构成了一个完整系统。
基准测试展示了性能提升，但并非普遍结论
Hugging Face 的数据令人鼓舞，但它们仅描述了一种流水线、一种分辨率和一款 Blackwell 工作站 GPU。
公开的基准测试使用了搭载 ERNIE-Image-Turbo 检查点的 NVIDIA RTX PRO 6000。图像生成分辨率为 1024 × 1024 像素。
BF16 基线完成整个流水线需要 3.00 秒。其去噪循环耗时 2.86 秒，峰值显存达到 31.1 GB。
采用 NVFP4 的 Nunchaku Lite 在 2.27 秒内完成了整个流水线。去噪循环耗时 2.13 秒，同时峰值显存降至 20.6 GB。
据报告，该配置实现了 1.35 倍加速。按百分比计算，整个流水线的完成时间比 BF16 基线缩短了约 24%。
应用 torch.compile 后，整个流水线的延迟降至 1.68 秒。去噪耗时 1.53 秒，峰值显存维持在 20.6 GB。
Hugging Face 报告称，该结果实现了 1.8 倍加速。因此，在这项测试中，编译解决了执行开销问题，但没有进一步降低显存占用。
另一个配置使用 bitsandbytes NF4 对文本编码器进行了量化。该配置在 2.29 秒内完成流水线，峰值显存占用为 16.0 GB。
这接近基线显存占用的一半。同时，它也保留了未编译 Nunchaku 配置所报告的 1.35 倍加速。
这些数据支持 W4A4 可以在降低显存占用的同时提升速度这一说法。但它们并不能证明所有扩散 Transformer 或 GPU 都能获得相同的收益。
在 Hugging Face 的示例中，ERNIE-Image-Turbo 使用八个推理步骤。具有更多去噪步骤的模型会以不同方式分摊固定的流水线开销。
分辨率也会改变 Transformer 计算、激活显存、文本编码和图像解码之间的平衡。批量大小可能再次改变这种平衡。
编译结果尤其需要谨慎看待。首次运行时的编译会产生额外开销，而这部分开销不会体现在稳态延迟测量中。
反复处理同一计算图的应用可以摊薄这项成本。频繁改变形状或设置的交互式工作流，实际获得的收益可能更小。
图像质量是另一个限制因素。Hugging Face 使用相同的随机种子和设置展示对比结果，并表示结果与 BF16 仍然较为接近。
在选定提示词中表现出视觉相似性，并不能替代系统性评估。文字排版、复杂人体结构、重复图案和精细空间关系可能暴露出宽泛场景所掩盖的误差。
模型发布者在生成量化检查点时还必须选择校准数据。校准样本会影响缩放因子和低秩校正对模型行为的表示方式。
因此，一个检查点可能在熟悉的提示词分布上表现良好，却在其他场景中呈现更明显的差异。开发者应先使用自己的提示词进行测试，再将已发布的基准测试视为保证。
更准确的解读范围较窄，但仍然具有意义。在 Hugging Face 选定的 Blackwell 配置上，Nunchaku Lite 无需独立推理引擎即可降低显存占用并改善实测延迟。
这足以成为开展测试的理由，但不足以预测其他架构、分辨率或服务工作负载的确切加速幅度。
硬件支持划分了最快路径与最广泛路径
主要限制并不在于 API，而在于检查点精度、内核支持与 GPU 代际之间是否匹配。
NVFP4 是 NVIDIA 面向 Blackwell 硬件推出的四位浮点格式。Nunchaku Lite 的 NVFP4 检查点需要 RTX 50 系列 GPU、RTX PRO 6000 或 B200。
受支持的 Turing、Ampere 和 Ada GPU 用户必须使用 INT4 检查点。Hugging Face 列出的受支持示例包括 RTX 30 系列、RTX 40 系列、A100 和 L40S 硬件。
这种划分会带来实际影响。针对 Blackwell 优化的检查点不能简单地迁移到旧款显卡上，同时继续使用相同的内核路径。
发布者可能需要同时分发 NVFP4 和 INT4 版本。用户必须先选择与其设备匹配的版本，再下载体积庞大的模型文件。
据 Hugging Face 称，四位内核目前不支持 Volta 和 Hopper。缺少 Hopper 支持尤其值得注意，因为 H100 和 H200 系统在 AI 基础设施中仍然十分常见。
这形成了一条不同寻常的部署边界。一些消费级 RTX 显卡可以使用 Nunchaku Lite INT4，而价格昂贵的 Hopper 服务器却无法使用当前的四位实现。
加载器会在启动时验证 CUDA 能力。不受支持的组合应当报错，而不是静默运行不兼容的内核。
这种验证可以防止产生错误输出，但无法解决硬件集群碎片化问题。在多个 GPU 代际上运行的云服务可能需要分别准备产物和路由规则。
当原始 Nunchaku 引擎针对特定架构的融合路径能够提供更高速度时，它仍然具有价值。Nunchaku Lite 则优先考虑与 Diffusers 抽象层和标准流水线行为的兼容性。
因此，开发者需要面对两种不同含义的支持。原生库加载解决了软件接口问题，而高性能执行仍然依赖专用内核。
这种区别也会影响新的模型家族。通用扫描器可以识别重复 Transformer 模块中的兼容线性层。
它可以对注意力和多层感知机投影应用 SVDQ W4A4，也可以识别某些调制层并对其进行 AWQ W4A16 处理。
结构简单的模型可以通过配套的量化工作流，从校准阶段转变为打包好的 Diffusers 仓库。涉及结构重写时，则需要额外的映射工作。
融合投影、拆分张量、自定义注意力处理器和非常规归一化模式都可能需要显式适配器。原生支持减少了这部分工作，但无法将其完全消除。
LoRA 兼容性是另一个需要验证的领域。标准模块结构使 Diffusers 加载钩子能够识别熟悉的模型。
然而，每一种检查点与适配器组合仍然需要测试。模型能够成功加载，并不意味着每个 LoRA 都会作用于预期的量化模块。
CPU 卸载可以通过在系统内存和显存之间移动组件来帮助显存较小的 GPU。这项技术可以缓解设备显存压力，但可能增加传输延迟。
因此，最佳配置取决于实际限制。工作站用户可能优先考虑让流水线能够装入显存，而服务运营者可能更重视稳态吞吐量。
Nunchaku Diffusers 让这些选项更容易组合使用。硬件支持仍然决定了哪些组合可用。
Nunchaku Lite 发布后值得关注的方面
接下来的考验在于，原生加载能否将一项前景良好的基准测试转化为受到广泛支持的检查点生态系统。
第一个信号是检查点覆盖范围。Hugging Face 目前重点介绍了 ERNIE-Image-Turbo、Krea 2 Turbo 和社区合集，将它们作为开箱即用的起点。
更广泛的采用需要为主要扩散 Transformer 家族提供持续维护的版本。NVFP4 和 INT4 版本都很重要，因为用户横跨多个 NVIDIA GPU 代际。
如果兼容检查点能够持续稳定发布，将进一步证明通用打包方案确实有效。发布数量稀少则意味着量化和适配器工作仍然是显著障碍。
第二个信号是内核覆盖范围。支持 Hopper 将实质性扩大可触达的数据中心市场，而支持更多消费级配置则会减少部署碎片化。
硬件支持范围扩大也会让基准测试对比更有价值。开发者可以在 Blackwell、Ada、Ampere 和常见服务器加速器上测量同一个检查点。
如果支持范围仍然狭窄，竞争性量化后端将凭借更广泛的部署覆盖保持优势。它们的延迟表现或许不那么理想，但可用性往往决定生产环境中的选择。
第三个信号是独立工作负载测试。Hugging Face 的测量结果确立了明确的参考点，但生产环境评估必须覆盖更多模型和运行条件。
有价值的测试应涵盖不同分辨率、去噪步骤数、批量大小、调度器、LoRA 适配器和提示词分布，并应将编译时间与重复推理延迟区分开来。
图像评估应超越视觉效果较为有利的示例。文字渲染、手部、重复物体、几何布局和精细纹理都可能暴露量化带来的变化。
开发者还应监控故障行为。随着社区检查点不断增加，针对不受支持的内核、不兼容的适配器或格式错误的配置文件提供清晰报错将变得十分重要。
更大的行业趋势非常明确。扩散模型正在转向以 Transformer 为主的架构，而这些架构所需的显存超过了许多本地 GPU 的承载能力。
量化正在从一种存储技术转变为一种执行策略。最终胜出的方案必须在保持输出可用的同时，兼顾显存、速度和集成成本的改善。
Nunchaku Lite 致力于实现上述四项目标，但在不同设备上的实现程度并不相同。它最重要的成就是将 W4A4 推理引入标准 Diffusers 工作流。
对于目前正在考虑使用 Nunchaku Diffusers 的开发者，合理的下一步是在目标硬件上使用具有代表性的提示词开展受控基准测试。在相同设置下比较密集 BF16、未编译的 Nunchaku Lite 和编译后的执行结果。记录峰值显存、首次运行延迟、重复运行延迟以及可见的输出差异。然后测试应用实际使用的适配器和卸载功能。这次发布让此类实验变得容易得多，但最终答案仍需由你的工作负载给出。
