Unweight：Cloudflare 如何在不损失精度的情况下把大模型压缩 22%

生成一个 tokenGPU 要把整份模型权重从内存读一遍。Cloudflare 的答案是让权重在上路之前就变小。一、真正的瓶颈不是算力是内存带宽在 NVIDIA H100 GPU 上张量核心处理数据的速度比内存传输数据的速度快将近 600 倍——瓶颈不在算力而在内存带宽。每一个跨内存总线传输的字节如果权重更小本可以完全避免。这是大模型推理中一个常被忽视的事实GPU 大多数时间不是在算而是在等数据从显存里爬过来。Cloudflare 构建了 Unweight——一套无损压缩系统能在保留逐位精确输出的前提下将模型权重缩小 15–22%且不依赖任何特殊硬件。核心突破在于在片上高速共享内存中完成权重解压并直接送入张量核心避免了一次经由慢速主存的额外往返。二、压缩为什么比听起来更难量化是有损的生产环境不能用最常见的压缩方案是量化——把 32 位或 16 位浮点数转换为 8 位或 4 位整数。这是有损压缩不同的 16 位浮点值可能映射到同一个 4 位整数。这种精度损失会以不可预测的方式影响输出质量。对于服务多样化用例的生产推理Cloudflare 需要的是能保留精确模型行为的无损方案。现有研究方案各有局限已有若干研究系统展示了 LLM 权重可以被显著压缩但它们针对的问题与 Cloudflare 的需求不同ZipNN 在 CPU 上解压面向分发和存储Huff-LLM 依赖定制 FPGA 硬件ZipServ 虽然将解压与 GPU 推理融合但针对的是消费级 GPU无法适配 H100。没有一个方案能满足 Cloudflare 的需求在 Hopper GPU 上实现推理时无损解压并与基于 Rust 的推理引擎集成。核心难题解压不能拖慢推理挑战不在于压缩本身——BF16 权重中的指数字节高度冗余熵编码效果很好。难点在于解压速度要快到不拖慢推理。在 H100 上张量核心大多数时间处于等待内存的空闲状态——但这部分空闲算力无法简单地挪用于解压。每个 GPU 计算单元在同一时刻只能运行解压核函数或矩阵乘法核函数之一无法同时运行原因是共享内存的约束。任何未能与矩阵乘法完美重叠的解码延迟都会直接叠加到 token 生成延迟上。三、BF16 权重藏着一个规律模型中的每个数字以 16 位脑浮点BF16格式存储包含三个部分符号位1 bit正负指数8 bits数量级尾数7 bits精确值符号位和尾数在权重之间变化不可预测看起来像随机数据无法有效压缩。但指数讲述的是另一个故事。指数的惊人规律已有研究表明在训练好的 LLM 中256 个可能的指数值里只有少数几个占据主导。最常见的 16 个指数值覆盖了典型层中 99% 以上的权重。信息论告诉我们表示这种分布只需约 2.6 位——远少于分配的 8 位。这是 Unweight 得以成立的根基。四、Unweight 的压缩策略哈夫曼编码只压指数Unweight 保持符号位和尾数不变仅使用哈夫曼编码压缩指数字节——这是一种经典技术对常见值分配短编码对稀有值分配长编码。由于指数分布极度偏斜这在指数字节流上实现了约 30% 的压缩率。只压 MLP不动 AttentionUnweight 选择性地压缩 MLP 权重矩阵门控、上投影和下投影这部分权重约占模型参数的三分之二在 token 生成过程中主导内存访问流量。注意力权重、嵌入层和层归一化保持不压缩。综合来看整体 MLP 权重体积减少约 20%。稀有指数行整行存储消除热路径分支含有稀有指数的少量权重单独处理如果某行 64 个权重中有任何一个的指数不在前 16 名的调色板内整行就以原始格式存储。这种方式消除了热路径中的逐元素分支判断——不需要对每个权重逐一检查异常而是在行级别提前做一次决策。五、GPU 内存架构为什么传统解压方案白费力气H100 GPU 有两种关键内存HBM高带宽内存容量大但访问相对慢模型权重存在这里共享内存SMEM容量极小但极快GPU 在做数学运算前在此暂存数据大多数已有方案将整个权重矩阵解压回 HBM再执行标准矩阵乘法。这有助于减少存储容量占用但对带宽毫无帮助——因为每次生成 token 时你仍然要从 HBM 读取完整的未压缩矩阵。Unweight 的不同之处在于在片上 SMEM 中完成解压解压后的权重从未出现在主存里直接送进张量核心参与计算。六、四条执行管道而非一刀切没有单一最优的压缩权重使用方式。正确的方案取决于工作负载——批量大小、权重矩阵形状以及 GPU 可用于解压的时间。Unweight 提供四条压缩执行管道各自在解压开销与计算复杂度之间取得不同平衡。四条管道形成一个谱系完整哈夫曼解码 cuBLAS完全重建原始 BF16 权重后交给 NVIDIA 标准库做矩阵乘法。预处理写回内存最多但 cuBLAS 开销最低适合小批量场景。仅解码指数字节预处理流量减半使用重建式矩阵乘法核函数。运行时调色板转码预处理流量降至四分之一适合中等批量。直接调色板零预处理模型加载时预先转码为紧凑的 4 位格式推理时矩阵乘法核函数在飞行中重建 BF16预处理开销为零但核函数每个元素要做更多工作。减少预处理意味着写入 HBM 的数据更少内存总线更早释放。但这把更多重建工作压到了矩阵乘法核函数上。这个权衡是否值得取决于具体情况。批量较小时1–64 个 token矩阵乘法规模很小完整解码加 cuBLAS 往往胜出批量较大时256 个 token调色板或指数管道的优势开始显现。七、重建式矩阵乘法生产者-消费者架构在融合解压与计算的核函数内部GPU 线程组被分成两个角色生产者组利用专用内存拷贝硬件TMA从 HBM 加载压缩输入到共享内存领先于消费者运行填充循环缓冲区确保数据提前就绪消费者组将指数与符号尾数字节重新组合还原出 BF16 值随即直接送入 Hopper 的 WGMMA 张量核心指令。重建好的权重从组装到计算全程不离开共享内存。这正是 Unweight 节省带宽的本质所在约 30% 更少的字节跨越 MLP 权重矩阵的内存总线。八、跨层流水线把解压藏进计算间隙Unweight 将层分类为困难层需要运行时哈夫曼预处理和简单层使用预转码的调色板数据矩阵乘法核函数可直接消费。运行时交替处理两者在 GPU 计算一个简单层时——它不需要预处理——独立的 CUDA 流在后台解码下一个困难层的权重。等到简单层计算完毕、困难层轮到执行时其预处理数据已经准备好了。下投影down projection从这种重叠中获益最大——它在 MLP 序列中最后被消费留给解码的时间窗口最长。九、自动调优器没有银弹只有测量面对四条管道、多种矩阵乘法核函数变体以及解码与计算之间可调的 SM 分配比例Unweight 使用一个自动调优器在目标硬件上实际测量端到端推理吞吐量。它依次对门控投影、上投影、下投影扫描候选配置重复迭代直到没有进一步提升。最终产出一个每模型配置文件明确记录每种投影在每种批量大小下应使用哪条管道、哪种核函数变体、如何分配 SM——全部由实测数据驱动而非依赖启发式规则。十、当前结果与已知代价在 Llama 3.1 8B 上Unweight 实现了推理包约 13% 的模型体积缩减仅压缩门控/上投影分发包约 22% 的缩减压缩全部 MLP 投影所有压缩均为 100% 逐位精确无损。推算到 Llama 70B可节省约 18–28 GB 显存。代价是在 H100 SXM5 上端到端测量的约 30–40% 吞吐量开销批量为 1 时开销最大约 41%批量 1024 时收窄至约 30%。三个已知来源正在优化中小批量下重建式矩阵乘法的固定成本、大批量下的冗余权重块重建以及尚未压缩的下投影。这不是免费的午餐但对于 Cloudflare 的场景用 13% 的内存节省换取 30% 的吞吐量开销意味着同一块 GPU 上可以同时承载更多模型整体容量和成本效益反而是正向的。十一、下一步三个具体的研究方向将进一步提升效率下投影压缩约占可压缩权重的三分之一因转置维度需要不同的核函数变体核函数优化三个已知开销来源均有明确的解决路径更多模型底层指数统计规律在 SwiGLU 架构的各种规模上都是一致的将把 Unweight 带到 Workers AI 服务的更大模型上。更长远来看Cloudflare 正在研究 Unweight 架构对混合专家MoE模型的意义——冷专家需要按需加载更小的存储体积将进一步降低成本。十二、总结Unweight 回答的是一个底层问题当内存带宽是瓶颈时最有效的优化不是堆算力而是让数据变小、并在离算力最近的地方完成还原。其核心洞察链条非常清晰LLM 权重的指数字节极度冗余 → 哈夫曼编码可以把它们压缩约 30% → 在片上共享内存解压直送张量核心跳过一次 HBM 往返 → 四条管道加自动调优适配不同批量 → 跨层流水线把解压成本藏进计算间隙。Cloudflare 已将技术论文和 GPU 核函数代码全部开源链接见原文。对于关注大模型推理效率的研究者和工程师这套架构思路值得深入研读。*原文链接https://blog.cloudflare.com/unweight-tensor-compression/*内容已读取完毕下面是结构概览和正文。内容结构概览1. 引言GPU 内存大模型推理的真正瓶颈 2. 为什么压缩比听起来更难做 2.1 量化的局限有损压缩不适合生产环境 2.2 现有方案的缺口CPU 解压、FPGA 硬件、消费级 GPU 2.3 核心难题解压速度必须跟上推理速度 3. BF16 权重的结构性秘密 3.1 三段式符号位、指数、尾数 3.2 指数的惊人规律256 个值中16 个覆盖 99% 4. Unweight 的压缩方案 4.1 哈夫曼编码只压指数符号和尾数不动 4.2 只压 MLP 权重不碰 Attention 和嵌入层 4.3 稀有指数行单独处理消除逐元素分支 5. GPU 内存架构与瓶颈所在 5.1 HBM vs 共享内存SMEM 5.2 传统方案解压回 HBM带宽浪费依旧 5.3 Unweight 的关键在片上 SMEM 解压直送张量核心 6. 四条执行管道适配不同场景 6.1 完整哈夫曼解码 cuBLAS小批量优先 6.2 仅解码指数字节 6.3 运行时调色板转码 6.4 直接调色板零预处理 7. 重建式矩阵乘法生产者-消费者架构 8. 跨层流水线让解压藏进计算间隙 9. 自动调优器没有银弹只有测量 10. 当前结果与已知代价 11. 下一步下投影压缩、核函数优化、更多模型 12. 总结UnweightCloudflare 如何在不损失精度的情况下把大模型压缩 22%生成一个 tokenGPU 要把整份模型权重从内存读一遍。Cloudflare 的答案是让权重在上路之前就变小。一、真正的瓶颈不是算力是内存带宽在 NVIDIA H100 GPU 上张量核心处理数据的速度比内存传输数据的速度快将近 600 倍——瓶颈不在算力而在内存带宽。每一个跨内存总线传输的字节如果权重更小本可以完全避免。这是大模型推理中一个常被忽视的事实GPU 大多数时间不是在算而是在等数据从显存里爬过来。Cloudflare 构建了 Unweight——一套无损压缩系统能在保留逐位精确输出的前提下将模型权重缩小 15–22%且不依赖任何特殊硬件。核心突破在于在片上高速共享内存中完成权重解压并直接送入张量核心避免了一次经由慢速主存的额外往返。二、压缩为什么比听起来更难量化是有损的生产环境不能用最常见的压缩方案是量化——把 32 位或 16 位浮点数转换为 8 位或 4 位整数。这是有损压缩不同的 16 位浮点值可能映射到同一个 4 位整数。这种精度损失会以不可预测的方式影响输出质量。对于服务多样化用例的生产推理Cloudflare 需要的是能保留精确模型行为的无损方案。现有研究方案各有局限已有若干研究系统展示了 LLM 权重可以被显著压缩但它们针对的问题与 Cloudflare 的需求不同ZipNN 在 CPU 上解压面向分发和存储Huff-LLM 依赖定制 FPGA 硬件ZipServ 虽然将解压与 GPU 推理融合但针对的是消费级 GPU无法适配 H100。没有一个方案能满足 Cloudflare 的需求在 Hopper GPU 上实现推理时无损解压并与基于 Rust 的推理引擎集成。核心难题解压不能拖慢推理挑战不在于压缩本身——BF16 权重中的指数字节高度冗余熵编码效果很好。难点在于解压速度要快到不拖慢推理。在 H100 上张量核心大多数时间处于等待内存的空闲状态——但这部分空闲算力无法简单地挪用于解压。每个 GPU 计算单元在同一时刻只能运行解压核函数或矩阵乘法核函数之一无法同时运行原因是共享内存的约束。任何未能与矩阵乘法完美重叠的解码延迟都会直接叠加到 token 生成延迟上。三、BF16 权重藏着一个规律模型中的每个数字以 16 位脑浮点BF16格式存储包含三个部分符号位1 bit正负指数8 bits数量级尾数7 bits精确值符号位和尾数在权重之间变化不可预测看起来像随机数据无法有效压缩。但指数讲述的是另一个故事。指数的惊人规律已有研究表明在训练好的 LLM 中256 个可能的指数值里只有少数几个占据主导。最常见的 16 个指数值覆盖了典型层中 99% 以上的权重。信息论告诉我们表示这种分布只需约 2.6 位——远少于分配的 8 位。这是 Unweight 得以成立的根基。四、Unweight 的压缩策略哈夫曼编码只压指数Unweight 保持符号位和尾数不变仅使用哈夫曼编码压缩指数字节——这是一种经典技术对常见值分配短编码对稀有值分配长编码。由于指数分布极度偏斜这在指数字节流上实现了约 30% 的压缩率。只压 MLP不动 AttentionUnweight 选择性地压缩 MLP 权重矩阵门控、上投影和下投影这部分权重约占模型参数的三分之二在 token 生成过程中主导内存访问流量。注意力权重、嵌入层和层归一化保持不压缩。综合来看整体 MLP 权重体积减少约 20%。稀有指数行整行存储消除热路径分支含有稀有指数的少量权重单独处理如果某行 64 个权重中有任何一个的指数不在前 16 名的调色板内整行就以原始格式存储。这种方式消除了热路径中的逐元素分支判断——不需要对每个权重逐一检查异常而是在行级别提前做一次决策。五、GPU 内存架构为什么传统解压方案白费力气H100 GPU 有两种关键内存HBM高带宽内存容量大但访问相对慢模型权重存在这里共享内存SMEM容量极小但极快GPU 在做数学运算前在此暂存数据大多数已有方案将整个权重矩阵解压回 HBM再执行标准矩阵乘法。这有助于减少存储容量占用但对带宽毫无帮助——因为每次生成 token 时你仍然要从 HBM 读取完整的未压缩矩阵。Unweight 的不同之处在于在片上 SMEM 中完成解压解压后的权重从未出现在主存里直接送进张量核心参与计算。六、四条执行管道而非一刀切没有单一最优的压缩权重使用方式。正确的方案取决于工作负载——批量大小、权重矩阵形状以及 GPU 可用于解压的时间。Unweight 提供四条压缩执行管道各自在解压开销与计算复杂度之间取得不同平衡。四条管道形成一个谱系完整哈夫曼解码 cuBLAS完全重建原始 BF16 权重后交给 NVIDIA 标准库做矩阵乘法。预处理写回内存最多但 cuBLAS 开销最低适合小批量场景。仅解码指数字节预处理流量减半使用重建式矩阵乘法核函数。运行时调色板转码预处理流量降至四分之一适合中等批量。直接调色板零预处理模型加载时预先转码为紧凑的 4 位格式推理时矩阵乘法核函数在飞行中重建 BF16预处理开销为零但核函数每个元素要做更多工作。减少预处理意味着写入 HBM 的数据更少内存总线更早释放。但这把更多重建工作压到了矩阵乘法核函数上。这个权衡是否值得取决于具体情况。批量较小时1–64 个 token矩阵乘法规模很小完整解码加 cuBLAS 往往胜出批量较大时256 个 token调色板或指数管道的优势开始显现。七、重建式矩阵乘法生产者-消费者架构在融合解压与计算的核函数内部GPU 线程组被分成两个角色生产者组利用专用内存拷贝硬件TMA从 HBM 加载压缩输入到共享内存领先于消费者运行填充循环缓冲区确保数据提前就绪消费者组将指数与符号尾数字节重新组合还原出 BF16 值随即直接送入 Hopper 的 WGMMA 张量核心指令。重建好的权重从组装到计算全程不离开共享内存。这正是 Unweight 节省带宽的本质所在约 30% 更少的字节跨越 MLP 权重矩阵的内存总线。八、跨层流水线把解压藏进计算间隙Unweight 将层分类为困难层需要运行时哈夫曼预处理和简单层使用预转码的调色板数据矩阵乘法核函数可直接消费。运行时交替处理两者在 GPU 计算一个简单层时——它不需要预处理——独立的 CUDA 流在后台解码下一个困难层的权重。等到简单层计算完毕、困难层轮到执行时其预处理数据已经准备好了。下投影down projection从这种重叠中获益最大——它在 MLP 序列中最后被消费留给解码的时间窗口最长。九、自动调优器没有银弹只有测量面对四条管道、多种矩阵乘法核函数变体以及解码与计算之间可调的 SM 分配比例Unweight 使用一个自动调优器在目标硬件上实际测量端到端推理吞吐量。它依次对门控投影、上投影、下投影扫描候选配置重复迭代直到没有进一步提升。最终产出一个每模型配置文件明确记录每种投影在每种批量大小下应使用哪条管道、哪种核函数变体、如何分配 SM——全部由实测数据驱动而非依赖启发式规则。十、当前结果与已知代价在 Llama 3.1 8B 上Unweight 实现了推理包约 13% 的模型体积缩减仅压缩门控/上投影分发包约 22% 的缩减压缩全部 MLP 投影所有压缩均为 100% 逐位精确无损。推算到 Llama 70B可节省约 18–28 GB 显存。代价是在 H100 SXM5 上端到端测量的约 30–40% 吞吐量开销批量为 1 时开销最大约 41%批量 1024 时收窄至约 30%。三个已知来源正在优化中小批量下重建式矩阵乘法的固定成本、大批量下的冗余权重块重建以及尚未压缩的下投影。这不是免费的午餐但对于 Cloudflare 的场景用 13% 的内存节省换取 30% 的吞吐量开销意味着同一块 GPU 上可以同时承载更多模型整体容量和成本效益反而是正向的。十一、下一步三个具体的研究方向将进一步提升效率下投影压缩约占可压缩权重的三分之一因转置维度需要不同的核函数变体核函数优化三个已知开销来源均有明确的解决路径更多模型底层指数统计规律在 SwiGLU 架构的各种规模上都是一致的将把 Unweight 带到 Workers AI 服务的更大模型上。更长远来看Cloudflare 正在研究 Unweight 架构对混合专家MoE模型的意义——冷专家需要按需加载更小的存储体积将进一步降低成本。十二、总结Unweight 回答的是一个底层问题当内存带宽是瓶颈时最有效的优化不是堆算力而是让数据变小、并在离算力最近的地方完成还原。其核心洞察链条非常清晰LLM 权重的指数字节极度冗余 → 哈夫曼编码可以把它们压缩约 30% → 在片上共享内存解压直送张量核心跳过一次 HBM 往返 → 四条管道加自动调优适配不同批量 → 跨层流水线把解压成本藏进计算间隙。Cloudflare 已将技术论文和 GPU 核函数代码全部开源链接见原文。对于关注大模型推理效率的研究者和工程师这套架构思路值得深入研读。原文链接https://blog.cloudflare.com/unweight-tensor-compression/