突破三元LLM的1.58位存储壁垒

# 打破三元大语言模型的1.58位屏障
来源：https://arxiv.org/html/2609.16338

###### 摘要
三元大语言模型（LLM）将每个权重存储为三个符号之一：{−1, 0, +1}。因此，三元模型的成本通常参考信息论中的 log₂3 ≈ 1.585 位/权重。主流的部署格式将五个三元权重打包到一个字节中（*五三元位打包*），并且由于实践中使用的是2的幂次分组大小，这向上取整为 1.625 位/权重。这种有效的存储位宽将三个符号 {−1, 0, +1} 视为等概率。我们测量了29个三元大语言模型模型的实际符号分布，发现零值在所有权重中占比高达51.5%。基于这一发现，我们引入了 BITCOS，这是一种简单的分布自适应布局，由一个密集的位图和一个紧凑的符号向量组成，其成本为 2−z 位/权重元素，其中 z 是模型权重中的零值密度。在29个测试模型中，有26个模型，BITCOS 存储权重比五三元位打包更紧凑，在最稀疏的模型上达到 1.485 位/权重。BITCOS 适用于现代处理器和 GPU 上的高效解包，我们展示了针对 AVX-512、AVX2 和 Intel Xe2 GPU 优化的解包序列。在反映真实三元模型零密度的生产级最先进三元矩阵-向量乘法内核上测量，我们提出布局带来的实际增益高达 1.28倍。最后，我们展示了在5个不同平台（客户端和服务端 CPU，集成和独立 Xe2 GPU）上的端到端 LLM 推理结果，其中解码吞吐量在 CPU 上提高了高达 1.18倍，在 GPU 上提高了高达 1.27倍。

## I 引言
三元权重量化将每个权重限制为 {−1, 0, +1}，并由一个分组因子缩放[1 (https://arxiv.org/html/2609.16338#bib.bib1), 2 (https://arxiv.org/html/2609.16338#bib.bib2)]。三个等概率的符号携带 log₂3 ≈ 1.585 位信息，这个理论界限是三元存储的参考。然而，在实践中，实际存储成本取决于这些符号的打包方式。五个三元位（trits）可以放入一个字节（3⁵=243 ≤ 256），这以 8/5 = 1.6 位/权重接近该界限。然而，部署的实现以2的幂次权重块（如128）进行量化，而128不是5的倍数：一个块需要 ⌈128/5⌉=26 个有效载荷字节，因此实践中存储的速率为 26 × 8 / 128 = 1.625 位/权重。尽管如此，这种有效的存储位宽仍然将三个符号 {−1, 0, +1} 视为等概率。

图1：三元大语言模型模型家族的有效位宽，比较了五三元位打包和提出的 BITCOS 布局。斜线代表 BITCOS 位宽 2−z，而平台表示固定的五三元位位宽 1.625 位/权重。每个标记对应于表I (https://arxiv.org/html/2609.16338#S1.T1) 中的一个模型，放置在其测量的零密度处。零密度 z 高于 0.375 的模型受益于 BITCOS 布局（绿色绘图区域），因此29个模型中有26个使用 BITCOS 实现了更低的有效位宽。

表I：最先进三元大语言模型模型的有效位宽。“% 0”是测量的零密度 z。“Symbols”列仅计算三元代码，“++scale”列添加了测量的16位缩放开销。仅符号的速率对于 BITCOS 为 2−z，对于每个模型，2位打包和五三元位打包分别为 2.000 和 1.625 位/权重。“red.”是 BITCOS 相对于包含缩放的相应格式的大小减少量。值 > 1 表示 BITCOS 存储模型更紧凑。

| BITCOS 三元模型 | % 0 | Symbols | ++scale red. | ++scale | 2位打包 red. | ++scale | 五三元位每字节 red. | ++scale |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| ∙ BitNet b1.58 2B | 42.19 | 1.578 | — | 2.000 | 1.27× | 1.625 | 1.03× | 1.625 |
| ■ Bonsai 1.7B | 39.89 | 1.601 | 1.726 | 2.125 | 1.23× | 1.750 | 1.01× | 1.750 |
| Bonsai 4B | 37.71 | 1.623 | 1.748 | 2.125 | 1.22× | 1.750 | 1.00× | 1.750 |
| Bonsai 8B | 38.25 | 1.618 | 1.743 | 2.125 | 1.22× | 1.750 | 1.00× | 1.750 |
| Bonsai 27B | 29.66 | 1.703 | 1.828 | 2.125 | 1.16× | 1.750 | 0.96× | 1.750 |
| ▲ CAT-Q Qwen3-1.7B | 51.48 | 1.485 | 1.610 | 2.125 | 1.32× | 1.750 | 1.09× | 1.750 |
| CAT-Q Qwen3-8B | 46.70 | 1.533 | 1.658 | 2.125 | 1.28× | 1.750 | 1.06× | 1.750 |
| CAT-Q Qwen3-30B-A3B | 32.88 | 1.671 | 1.796 | 2.125 | 1.18× | 1.750 | 0.97× | 1.750 |
| CAT-Q Qwen3-32B | 47.11 | 1.529 | 1.654 | 2.125 | 1.28× | 1.750 | 1.06× | 1.750 |
| CAT-Q Qwen3-235B-A22B | 34.07 | 1.659 | 1.784 | 2.125 | 1.19× | 1.750 | 0.98× | 1.750 |
| ⧫ ParetoQ 125M | 41.07 | 1.589 | 1.613 | 2.023 | 1.25× | 1.648 | 1.02× | 1.648 |
| ParetoQ 350M | 41.58 | 1.584 | 1.598 | 2.014 | 1.26× | 1.639 | 1.03× | 1.639 |
| ParetoQ 600M | 43.27 | 1.567 | 1.579 | 2.012 | 1.27× | 1.637 | 1.04× | 1.637 |
| ParetoQ 1B | 44.18 | 1.558 | 1.569 | 2.010 | 1.28× | 1.635 | 1.04× | 1.635 |
| ParetoQ 1.5B | 47.10 | 1.529 | 1.537 | 2.008 | 1.31× | 1.633 | 1.06× | 1.633 |
| ▼ TriLM 99M | 40.97 | 1.590 | 1.618 | 2.027 | 1.25× | 1.652 | 1.02× | 1.652 |
| TriLM 190M | 40.67 | 1.593 | 1.611 | 2.018 | 1.25× | 1.643 | 1.02× | 1.643 |
| TriLM 390M | 40.79 | 1.592 | 1.606 | 2.014 | 1.25× | 1.639 | 1.02× | 1.639 |
| TriLM 560M | 40.73 | 1.593 | 1.604 | 2.011 | 1.25× | 1.636 | 1.02× | 1.636 |
| TriLM 830M | 40.54 | 1.595 | 1.604 | 2.009 | 1.25× | 1.634 | 1.02× | 1.634 |
| TriLM 1.1B | 40.39 | 1.596 | 1.605 | 2.009 | 1.25× | 1.634 | 1.02× | 1.634 |
| TriLM 1.5B | 40.21 | 1.598 | 1.606 | 2.008 | 1.25× | 1.633 | 1.02× | 1.633 |
| TriLM 2.4B | 39.70 | 1.603 | 1.610 | 2.007 | 1.25× | 1.632 | 1.01× | 1.632 |
| TriLM 3.9B | 38.70 | 1.613 | 1.618 | 2.005 | 1.24× | 1.630 | 1.01× | 1.630 |
| ★ Maple 20B-A1B | 40.67 | 1.593 | 1.609 | 2.016 | 1.25× | 1.641 | 1.02× | 1.641 |
| ◀ BitCPM-CANN 0.5B | 37.67 | 1.623 | 1.636 | 2.012 | 1.23× | 1.637 | 1.00× | 1.637 |
| BitCPM-CANN 1B | 38.39 | 1.616 | 1.623 | 2.006 | 1.24× | 1.631 | 1.01× | 1.631 |
| BitCPM-CANN 3B | 38.06 | 1.619 | 1.624 | 2.005 | 1.23× | 1.630 | 1.00× | 1.630 |
| BitCPM-CANN 8B | 39.30 | 1.607 | 1.610 | 2.003 | 1.24× | 1.628 | 1.01× | 1.628 |

我们测量了29个最先进（SOTA）三元大语言模型模型的实际符号分布，发现零值在所有权重中占比高达51.5%；表I (https://arxiv.org/html/2609.16338#S1.T1) 列出了每个模型的测量零密度。更具体地说，我们基准测试了七个三元模型家族：i) *BitNet* [1 (https://arxiv.org/html/2609.16338#bib.bib1), 2 (https://arxiv.org/html/2609.16338#bib.bib2)]，一个在4T个令牌上从头训练的2B参数模型，确立了1.58位的参考点；ii) *Bonsai* [3 (https://arxiv.org/html/2609.16338#bib.bib6)]，从1.7B到27B的四个密集检查点；iii) *CAT-Q* [4 (https://arxiv.org/html/2609.16338#bib.bib15)]，五个从1.7B到235B的Qwen3后训练量化模型，包括两个混合专家模型；iv) *ParetoQ* [5 (https://arxiv.org/html/2609.16338#bib.bib3)]，来自低比特量化感知训练研究的五个小检查点（125M–1.5B）；v) *TriLM* [6 (https://arxiv.org/html/2609.16338#bib.bib4)]，九个模型的Spectra套件（99M–3.9B），以三元方式预训练；vi) *Maple* [7 (https://arxiv.org/html/2609.16338#bib.bib7)]，一个20B-A1B三元混合专家推理模型；以及vii) *BitCPM-CANN* [8 (https://arxiv.org/html/2609.16338#bib.bib8)]，从头训练的四个三元检查点（0.5B–8B）。基于许多三元模型的零密度显著高于另外两个代码 {−1, +1} 中任何一个的密度这一发现，我们引入了 BITCOS（BITmap and COmpactedSigns，位图与压缩符号）：一种用于三元张量的简单分布自适应布局。给定一个零密度 z，BITCOS 在每个权重条目上花费一个存在位，仅在非零权重上花费一个符号位，因此该布局有效实现了 2−z 位/权重。一旦 z > 0.375，这种布局就改善了相对于部署的五三元位打包的有效位宽，并且对于所有零密度，严格优于广泛采用的2位打包。图1 (https://arxiv.org/html/2609.16338#S1.F1) 将表I (https://arxiv.org/html/2609.16338#S1.T1) 中的每个模型放置在其测量的零密度处，放置在其首先满足的两种速率之一上：当 BITCOS 稀疏布局更高效时，为斜线 2−z；或者当五三元位固定速率打包具有更低的位宽时，为 1.625 平台。零密度 z 高于 0.375 的模型受益于 BITCOS 布局（绿色绘图区域），因此29个模型中有26个使用 BITCOS 实现了比五三元位打包布局更低的有效位宽。然而，有效位宽只是整体推理的一个方面。三元模型在推理期间的实际性能还取决于打包权重在矩阵-向量乘法内核中解包和利用的效率。小批量大小下LLM推理的解码阶段是带宽受限的，因此每个令牌的时间与权重数据类型的位宽成正比[9 (https://arxiv.org/html/2609.16338#bib.bib17)]，这正是设备上和智能体部署所应用的场景[10 (https://arxiv.org/html/2609.16338#bib.bib12)]。BITCOS 不仅降低了存储成本，而且适用于现代CPU和Intel GPU上的高效解包和计算。在7个三元LLM检查点和五个平台上进行端到端测量，解码吞吐量在64核服务器CPU上提高了高达1.18倍，在24核客户端CPU上提高了高达1.15倍，在独立Xe2 GPU上提高了高达1.27倍，在集成Xe2 GPU上提高了高达1.22倍。然而，性能提升并非普遍：在一个8核、带宽丰富的客户端平台上，每个核心有足够的带宽使得解包序列暴露出来，较小的有效载荷并未转化为性能优势。因此，我们开发了一个简单的两参数屋顶线模型来评估基于BITCOS的内核的局限性。

本文做出以下贡献：
1. 1. 一种新颖的三元稀疏布局（我们命名为 BITCOS），包含一个存在位图和一个压缩符号向量，对于零密度 z，其成本为 2−z 位/权重，适用于现代CPU和GPU上的高效解包。
2. 2. 优化的指令序列，用于解包提出的 BITCOS 布局，并在现代x86 CPU（具有性能和效率核心的客户端CPU，以及具有高核心数的服务器CPU）和Intel Xe2 GPU（集成和独立GPU）上高效执行矩阵乘法操作。
3. 3. 一个屋顶线模型，用于评估我们CPU微内核的有效性和局限性。
4. 4. 使用微基准测试和端到端LLM推理对提出的布局进行性能评估，涵盖七个三元LLM检查点，在现代服务器/客户端CPU和集成/独立GPU上进行，展示了解码吞吐量在CPU上提高了高达1.18倍，在GPU上提高了高达1.27倍。

## II BITCOS 布局：BITmap + COmpactedSigns

### II-A 布局定义和存储成本
我们提出 BITCOS 布局，利用三元权重固有的*非结构化*稀疏性，将三元张量存储为两部分：
1. 1. 一个*存在位图*，每个权重一位，在权重非零时设置；
2. 2. 一个*符号向量*，每个*非零*权重一位，按张量顺序排列。

图2 (https://arxiv.org/html/2609.16338#S2.F2) 在一个小的8×8张量上展示了这两部分。位图具有完整的张量长度；符号向量压缩到位图中设置位的个数。假设零密度为 z，则每个权重的成本为：
B(z) = 1 + (1 - z) = 2 - z 位
(1)

图2：在8×8张量上的BITCOS布局。BITCOS的每一列是一个掩码，其位 r 记录行 r 是否非零，因此解码器可以在一次加载中读取整个块的存在信息。压缩的符号向量仅针对非零元素携带一位，保持相同的 (k,r) 顺序，因此第 j 个符号位属于位图的第 j 个设置位。零值消耗一个位图位且不消耗其他东西，这就是为什么有效速率是 2-z。在这个例子中，64个权重中有30个是零（z=0.469），因此张量成本为64个存在位加34个符号位，即1.531位/权重（低于 log₂3）。

每个权重的成本随 z 线性下降，因此在零值密集的分布上，BITCOS 格式相比2位或五三元位打包带来显著优势。表I (https://arxiv.org/html/2609.16338#S1.T1) 比较了在29个测量的检查点上不同格式的每权重成本。“% 0”列是测量的零密度 z，“Symbols”列仅计算三元代码，“++scale”列添加了相应模型的测量的16位缩放开销。“red.”列报告了 BITCOS 相对于2位打包和五三元位每字节打包的大小减少量；值大于1意味着 BITCOS 存储模型比该格式更紧凑。我们得出结论：一旦 z > 0.375（29个三元大语言模型模型中的26个），BITCOS 相对于部署的五三元位打包改善了有效位宽，并且对于所有零密度，严格优于广泛采用的2位打包。

### II-B 使用x86 AVX-512指令的BITCOS解包序列
BITCOS 布局在支持掩码的目标ISA上，在一个短的掩码驱动序列中重建16位权重。在图3 (https://arxiv.org/html/2609.16338#S2.F3) 中，我们使用AVX-512指令展示了这样一个示例序列。两个向量每128个归约元素准备一次，然后在其每次迭代中重用：zmm3 保存32个fp16分组缩放因子，每行一个；zmm4 保存一个符号位设置的副本，通过一次 `vporq` 与广播的 `0x8000` 获得。因为IEEE半精度的符号位于最高有效位，并且分组缩放因子构造为非负，该OR是精确的取反，所以 zmm3 和 zmm4 分别为32行保存 +s 和 -s。每次迭代的工作是：
1. 1. 加载存在掩码。将32个位图位读入通用寄存器，然后读入 k1。
2. 2. 放置符号。从符号流中获取接下来的32位，并通过 `pdep` 散射到 k1 标记为存在的位位置。符号向量是压缩存储的，因此其第 j 位属于该组位图的第 j 个非零元素。`pdep` 正是撤销压缩的散射操作（见图4 (https://arxiv.org/html/2609.16338#S2.F4)）。
3. 3. 选择。在 k1 下对 zmm3 进行零掩码移动，在存在的通道上放置 +s，在其他位置放置精确的 +0；在沉积掩码下对 zmm4 进行合并掩码移动，覆盖负值。

图4 (https://arxiv.org/html/2609.16338#S2.F4) 说明了该沉积操作的作用：`pdep` 将其源的低位按顺序放置到掩码选择的位置，每个未选择的位置留零。在AVX-512汇编中，r13 遍历位图，r9 是符号流的基地址，r8 是其内的运行位位置，r14 遍历激活值，zmm2 是融合乘加（FMA）操作的一个累加器。总共我们得到17条指令，其中权重解包部分对应于3条指令：一条 `pdep` 和2条掩码移动。其余14条不是解包指令：一条加载位图字，5条计算符号窗口的数据相关地址，一条 `shrx` 在单个操作中执行未对齐的64位读取及其对齐，2条是...