生成一个 token，GPU 要把整份模型权重从内存读一遍。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，不动 Attention
Unweight 选择性地压缩 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. 总结Unweight：Cloudflare 如何在不损失精度的情况下把大模型压缩 22%
生成一个 token，GPU 要把整份模型权重从内存读一遍。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，不动 Attention
Unweight 选择性地压缩 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/