Cloudflare推出Unweight，无损压缩LLM权重达22%
Cloudflare AI··作者 Chris Branch
关键信息
Unweight仅选择性压缩解码时使用的参数，单独对MLP权重实现约30%的压缩率，整体模型尺寸缩小15–22%。它使用自动调优器为每个权重矩阵和批处理大小选择最佳执行策略，避免张量核心闲置。
资讯摘要
Cloudflare推出的Unweight是一种新颖的无损压缩系统，可将LLM模型权重减少最多22%而不影响输出质量。主要挑战不仅在于压缩数据，还在于快速完成压缩以避免拖慢推理——尤其是在NVIDIA H100 GPU上，张量核心常因显存带宽限制而闲置。Unweight通过在高速片上内存中解压缩权重而非慢速主内存来解决此问题，从而无缝叠加矩阵乘法操作。
它支持多种针对工作负载特性的执行策略，并包含自动调优器动态选择最优方案。初步结果显示Llama-3.1-8B模型显存节省高达3GB，使每块GPU能运行更多模型。Cloudflare还开源了GPU内核并发布了技术论文，以促进该领域的透明度和创新。
资讯正文
运行推理时，要在50毫秒内服务全球95%的联网人口，意味着必须对GPU内存使用做到极致高效。去年，我们通过基于Rust开发的推理引擎Infire提升了内存利用率，并借助模型调度平台Omni消除了冷启动问题。现在，我们正着手解决推理平台中的下一个关键瓶颈：模型权重。
从大型语言模型（LLM）生成单个token需要读取所有模型权重到GPU内存中。在我们数据中心广泛使用的NVIDIA H100 GPU上，张量核心处理数据的速度几乎比内存传输速度快600倍，这导致瓶颈不在计算能力，而在于内存带宽。每一条跨越内存总线的数据都是可以避免的——如果权重更小的话。
为了解决这个问题，我们开发了Unweight：一种无损压缩系统，能在不依赖特殊硬件的前提下，使模型权重缩小15%至22%，同时保持逐位精确的输出结果。这一突破的核心在于，将权重在高速片上内存中解压后直接输送给张量核心，从而避免了额外的、耗时的主内存往返操作。根据不同的工作负载，Unweight的运行时会从多种执行策略中选择最优方案——有些侧重简单性，有些则最小化内存流量——并由自动调优器为每个权重矩阵和批处理大小选择最佳策略。
本文深入探讨Unweight的工作原理，但为了促进更大程度的透明度并鼓励在这个快速发展的领域中推动创新，我们也发布了技术论文，并开源了GPU内核代码。
我们在Llama-3.1-8B模型上的初步结果显示，仅多层感知机（MLP）权重就实现了约30%的压缩率。由于Unweight仅针对解码所需的参数进行压缩，这带来了15%至22%的模型尺寸缩减以及约3GB显存节省。如下方图表所示，这使得我们能够在单个GPU上部署更多模型，从而在Cloudflare网络上让推理变得更便宜、更快。
得益于Unweight，我们可以在一块GPU上容纳更多模型。
为什么压缩比看起来容易实际很难
目前已有大量研究探索以创造性方式压缩模型权重，以加速推理或在更小的GPU上运行。最常见的方法是量化，即通过将较大的32位或16位浮点数转换为较小的8位或4位整数来减少模型权重和激活值的大小。这是一种有损压缩形式：不同的16位浮点数值可能被映射为相同的4位整数。这种精度下降会对响应质量产生不可预测的影响。对于服务于多样化应用场景的生产级推理任务，我们知道我们需要一种无损压缩方案，确保模型行为完全一致。
Unweight：如何在不牺牲质量的情况下将大语言模型压缩22%
一些最近的系统（Huff-LLM、ZipNN 和 ZipServ）已经证明，大语言模型的权重可以被显著压缩，但这些方法解决的问题与我们的不同。ZipNN 旨在压缩权重以用于分发和存储，解压缩过程发生在 CPU 上。Huff-LLM 提出使用定制的 FPGA 硬件进行解码。而 ZipServ 将解压缩与 GPU 推理融合，但目标是消费级 GPU，无法兼容我们使用的 H100 GPU。以上方案都没有满足我们的需求：在 Hopper GPU 上实现无损推理时解压缩，并能与我们基于 Rust 的推理引擎集成。
核心挑战并非普通的压缩——BF16 权重中的指数字节高度冗余，因此熵编码对其效果很好。真正的难点在于解压缩速度足够快，以免拖慢推理过程。在 H100 上，张量核心大部分时间都在等待内存读取而处于空闲状态——但这种闲置能力并不能简单地重新分配给解压缩任务。每个 GPU 计算单元只能运行解压缩内核或矩阵乘法内核之一，无法同时执行两者，这是由于共享内存资源的限制所致。任何未能与矩阵乘法完美重叠的解码延迟都会直接增加单个标记的延迟。Unweight 的解决方案是在高速片上共享内存中快速解压缩权重，并将结果直接输送给张量核心——但要在不同批量大小和权重形状下高效运行，这正是工程实现的关键所在。
模型权重如何有效压缩
AI 模型中的每个数字都以 16 位的“脑浮点”（BF16）格式存储。每个 BF16 值包含三个部分：
符号位（1 位）：正或负
指数（8 位）：表示数值的幅度
尾数（7 位）：在该幅度内的精确值
以下是一个权重的具体分解示例：
符号和尾数在权重之间变化无常——它们看起来像随机数据，无法有意义地压缩。但指数则呈现出不同的情况。
指数出人意料地具有可预测性
先前的研究表明，在训练好的大语言模型中，256 种可能的指数值中，仅有少量占据主导地位。典型的层中，最常见的 16 个指数覆盖了超过 99% 的权重。信息论指出，仅需约 2.6 位即可表示这一分布——远少于分配的 8 位。如果你观察典型 LLM 层中指数值的分布，可以看到前 16 个最常用的指数占所有模型权重的 99%。
这是Unweight所利用的冗余。我们保留符号和尾数不变，仅对指数字节使用霍夫曼编码进行压缩——这是一种经典技术，为常见值分配短码，为罕见值分配长码。由于指数分布极度不均衡，这种方法在指数流上实现了大约30%的压缩率。我们选择性地对多层感知机（MLP）权重矩阵（门控、上投影和下投影）应用此方法，这些矩阵约占模型参数的三分之二，并且在生成token时主导内存流量。注意力权重、嵌入层和层归一化则保持未压缩状态。总的来说，这些优化使多层感知机（MLP）权重的整体大小减少了约20%，具体细节请参见我们的技术报告。
对于那些指数极为罕见的少量权重，我们采取单独处理方式：如果一行64个权重中任意一个的指数不在前16种常用指数范围内，整行都会原样存储。这种方法消除了热路径中的逐元素分支判断——不再需要逐一检查每个权重是否存在特殊情况，而是提前为每行做出一次决策。
GPU内存瓶颈
一块NVIDIA H100 GPU有两种相关类型的内存：
高带宽内存（HBM）：容量大，但访问速度相对较慢。模型权重就存放在这里。
共享内存（SMEM）：容量很小，但速度极快。GPU会在执行计算前将数据暂存到此处。
在推理过程中，生成每个token都需要从HBM读取完整的权重矩阵。HBM与SMEM之间的内存总线是性能瓶颈——不是计算本身。通过总线传输的数据越少，token生成就越快。
在推理阶段，生成每个token都要通过内存总线从HBM读取整个权重矩阵——这正是瓶颈所在。H100的张量核心运算速度远超HBM提供数据的速度。压缩之所以有效，是因为需要穿越总线的数据变少了。但有一个限制：GPU无法直接对压缩后的数据进行数学运算，必须先解压。
大多数先前的工作会将整个权重矩阵解压回HBM，然后再执行标准矩阵乘法。这种方式有助于提升存储容量，却无助于缓解带宽问题，因为每次token生成仍需从HBM读取完整未压缩的矩阵。
使用压缩权重的四种方式
在推理过程中并没有一种最优的压缩权重使用方法。正确的方式取决于工作负载——包括批处理大小、权重矩阵的形状以及可用于解压的GPU时间。Unweight提供了四种压缩执行管道，每种在解压努力和计算复杂度之间有不同的平衡：完全霍夫曼解码、仅解码指数、调色板转码，或完全跳过预处理步骤。
四个处理流程构成一个连续谱系。一端是完整解码，它完全重构原始的BF16权重，并将其交给NVIDIA的cuBLAS库进行标准矩阵乘法运算。这是最简单的路径，cuBLAS在普通数据上以全速运行，但预处理步骤会将最多字节写回主内存。这种方案在小批量场景下表现良好，因为此时矩阵乘法计算量很小，自定义内核的开销占据主导地位。另一端是直接调色板策略，完全跳过预处理步骤。权重在模型加载时就被预先转码为紧凑的4位格式，矩阵乘法内核则从这些索引中实时重建BF16值。预处理成本为零，但每个元素的内核工作量增加。
中间存在两条独立路径：一条仅解码指数字节（预处理流量减半），另一条在运行时将数据转码为4位调色板索引（预处理流量降至四分之一）。两者都使用重构型矩阵乘法——一种自定义内核，它加载压缩数据，在高速共享内存中重建BF16值，并直接输入张量核心，无需经过主内存往返。
为何没有单一流程始终最优
较少的预处理意味着更少的数据写入高带宽内存（HBM），从而更快释放内存总线。但这也把更多重建任务转移到了矩阵乘法内核上。这一权衡是否值得，取决于具体情境。
在小批量情况下（例如1到64个token），矩阵乘法规模很小，无法有效重叠计算任务，因此自定义内核的固定开销占主导地位。此时完整解码配合cuBLAS通常胜出，因为cuBLAS的开销更低。而在大批量情况下（例如256个token以上），矩阵乘法持续时间足够长，可以吸收额外的重建工作量。轻量级预处理更快完成，释放的总线带宽和计算重叠带来收益，调色板或指数流程便开始领先。同一层内的不同权重矩阵可能偏好不同的流程。例如，“门控”和“上投影”矩阵与“下投影”矩阵维度不同，这改变了矩阵乘法内部的操作顺序，需要不同的性能权衡。
吞吐量与流程策略的关系
这正是Unweight不硬编码单一策略的原因。运行时会根据目标硬件上的实际端到端吞吐量测量结果，为每个权重矩阵和每种批量大小选择最佳流程——这一过程由自动调优机制驱动（详情见下文）。
重构型矩阵乘法如何实现
四个流程中有三个使用一种自定义矩阵乘法内核，该内核将解压缩与计算融合在一起。此内核从HBM加载压缩数据，在共享内存中重建原始BF16值，并直接输入张量核心——整个过程一步完成。重建后的权重永远不会存在于主内存中。
传统解压缩 vs Unweight
使用Unweight后，MLP权重矩阵的内存总线传输字节数减少约30%。
在此内核中，GPU的线程组被分为两个角色：
Unweight：如何在不牺牲质量的情况下将大语言模型压缩22%
生产者组使用专用的内存复制硬件（TMA）从高带宽内存（HBM）加载压缩输入到共享内存中。它会暂存符号+尾数字节、指数数据（或调色板索引），以及对于指数稀有值的行，还会暂存原始指数行。该组运行在消费者之前，填充一个环形缓冲区，确保数据在需要时已准备就绪。
消费者组通过将指数与符号+尾数字节结合来重建BF16数值，并立即将结果送入Hopper架构的WGMMA张量核心指令。重构后的权重直接从组装阶段进入计算过程，无需离开共享内存。
重构矩阵乘法有不同的变体，区别在于每个计算单元处理多少输出块，以及环形缓冲区的深度。更宽的输出块在大批量情况下提升数据复用效率；更深的缓冲区在小批量情况下隐藏内存延迟。自动调优器会根据工作负载选择最佳变体。
在解码和计算之间共享GPU
在这两个融合管道中，一个独立的预处理内核（霍夫曼解码器或调色板转换器）与重构矩阵乘法并发运行。但这些内核会争夺GPU资源。
在Hopper架构上，每个计算单元（SM）拥有228 KB共享内存。重构矩阵乘法需要约227 KB用于其流水线缓冲区和累加块。而一个解码内核需要约16 KB用于霍夫曼查找表。由于227 + 16 > 228，这两个内核无法共享同一个计算单元。分配给解码的每个SM都会减少可用于矩阵乘法的SM数量。
这就形成了一种平衡：更多的解码SM意味着更快的预处理，但会减慢矩阵乘法速度，反之亦然。最优分配是另一个可调参数——这也是自动调优器测量实际吞吐量而非依赖启发式方法的原因之一。
跨层流水线处理
即使存在SM分区限制，Unweight仍通过利用Transformer模型的结构来隐藏大部分解压缩成本。
并非每层在运行时都需要霍夫曼解码。Unweight将层分为“困难”（需霍夫曼预处理）和“简单”（使用预转换的调色板数据，可被矩阵乘法直接消费）。运行时会在两者之间交替执行：
在启动、注意力机制和简单MLP计算期间，解码在独立的CUDA流中运行。当困难层的MLP开始时，其预处理权重早已就位。
当GPU正在计算一个简单层（无需预处理）时，另一组CUDA流正在后台解码下一个困难层的权重。等到简单层完成、轮到困难层时，其预处理数据也已等待就绪。双缓冲预处理槽确保了一个困难层的解码输出不会在其仍在被消费时被覆盖。
下投影层最受益于这种重叠：它在MLP序列中最后被使用（在门控、激活和上投影之后），因此它的解码有最长的时间窗口可以完成。
Unweight：如何在不牺牲质量的情况下将大语言模型压缩22%
通过四个管道、多种矩阵乘法内核变体，以及解码和计算之间可调的SM分配，配置空间非常庞大。与其硬编码单一策略，Unweight采用自动调优器，在目标硬件上测量实际端到端推理吞吐量。它会先固定上行和下行投影，对门控投影候选配置进行扫描；然后依次扫描上行、下行，重复此过程直到无法再提升性能为止。最终得到一个针对每个模型的配置文件，告诉运行时在每种批量大小下应使用哪个管道、哪种矩阵乘法变体以及SM分配方式来执行每个投影——所有决策都基于实测性能，而非启发式规则。
编码格式、执行管道和调度是独立选择。同一个Huffman压缩的模型包可以同时用于分发和推理：
在分发场景中，Huffman编码最大化压缩效果（总模型尺寸减少约22%），从而在网络传输模型时缩短时间。
在推理场景中，Huffman编码的投影可以在加载模型时转换为中间格式（palette format），从而实现最高效的运行时执行，而不会限制分发格式。
单个模型包无需在打包时就锁定一种策略。运行时会根据每个投影和每种批量大小动态选择最佳执行路径。
我们的实验结果
在Llama 3.1 8B模型（我们主要测试平台）上，Unweight实现了：
推理包模型体积减少约13%（仅压缩门控/上行MLP投影），或分发包减少约22%（压缩全部MLP投影，包括下行）。所有压缩均为100%位级无损。若扩展至Llama 70B模型，这可能对应节省约18–28 GB存储空间，具体取决于配置。
当前优化级别下，吞吐量增加30–40%的开销（在H100 SXM5上端到端测量）。该开销在批量大小为1时最大（约41%），在批量大小为1024时缩小至约30%。三个已知原因正在积极优化：小批量固定成本、冗余权重块重建，以及未包含的下行投影。
这些是在单一模型上的初步结果。压缩比应适用于其他SwiGLU架构（不同规模模型的指数统计保持一致），但吞吐量数据依赖于当前内核实现，随着进一步优化而变化。目前尚未压缩注意力权重、嵌入层或层归一化参数，这些因素降低了整体压缩比例。
为什么这很重要
GPU在多个维度都很昂贵：显卡本身的价格、高带宽内存需求，以及显著的功耗。
Unweight：如何在不牺牲质量的情况下将大语言模型压缩22%
为了应对这一挑战，一些研究人员已经展示了在完整模型上实现约30%压缩率的系统，但这些方法主要面向消费级GPU和研究框架，无法在生产环境中规模化使用。Unweight开发的核心洞察在于，多层感知机（MLP）构成了模型权重的大部分，并且在推理负载中占用了相当大的计算成本。Unweight仅压缩MLP权重（避免在压缩收益有限的层上引入开销），专为数据中心H100 GPU设计，充分利用其计算与内存高度平衡的特点，并提供了四种可根据批量大小自适应执行的流水线，而非采用单一固定方案。
不过我们想明确说明：Unweight并非免费午餐。片上重建会增加原本不存在的计算负担。以Llama 3.1 8B为例，在典型的服务批量大小下，该配置可节省约13%的总模型内存，但吞吐量会下降约30%。随着批量增大（预处理重叠改善），这一差距将进一步缩小；我们预计通过优化还会进一步改进——特别是目前尚未压缩每个MLP层中的下投影部分（约占可压缩权重的三分之一），同时多项内核优化正在积极开发中。
对Cloudflare网络而言，Unweight带来了更好的容量：它让我们能在每个实例中用更少的GPU内存部署最先进的模型，从而降低运营成本，并支持在更多地点部署更多模型。对于模型分发来说，节省效果更大：经过霍夫曼压缩后的模型包体积减少了约22%，大幅缩短了向全球边缘节点传输模型所需的时间。
下一步计划
展望未来，我们确定了三个具体的研究方向，有望进一步提升我们的效率优势：
下投影压缩。当前Unweight已压缩门控和上投影MLP，但下投影约占可压缩权重的三分之一。由于其维度转置特性，这需要不同的内核变体，我们预计这将进一步减少整体模型大小，超过22%的压缩率。
内核优化。当前30–40%的吞吐量开销有三个已知来源：小批量时重建矩阵乘法的固定成本、大批量时冗余的权重重建，以及缺失的下投影压缩。每项问题都有明确的缓解路径，我们在技术论文中详细列出了这些方案。
支持更多模型。我们的结果基于Llama 3.1 8B，但底层指数统计规律在所有规模的SwiGLU架构中保持一致。我们正在努力将Unweight扩展到Workers AI服务的更大模型。
从长远看，我们正在研究Unweight架构对专家混合（Mixture-of-Experts）模型的影响，因为冷专家必须按需加载，而存储空间的减少将进一步降低成本。
这是一个快速发展的领域，因此我们很高兴开源这项工作，为压缩与GPU效率研究的不断增长的文献库贡献力量。Unweight只是拼图的一块，但我们希望其他研究人员能将其作为有价值的范式继续推进！
来源与参考
收录于 2026-04-18