人人都想有一個自己的DeepSeek，但并不是人人都有「一打」96GB顯存的H20。

雖然量化可以極大地降低模型對于顯存的需求，但它本質上是一種有損壓縮技術。

換句話說就是，量化模型的輸出分布不可避免地會受到影響，進而降低LLM的準確性和可靠性。

為此，來自萊斯大學等機構的研究人員提出了一種全新的無損壓縮框架——動態長度浮點數（DFloat11），它能夠將LLM的大小減少30%，同時確保輸出結果與原始模型逐位相同。

論文地址：https://arxiv.org/abs/2504.11651

為了支持使用動態長度編碼進行高效推理，團隊專門開發了一個定制的GPU內核，用于實現快速的在線解壓縮：

1. 將內存密集型的查找表 (LUT) 分解為更緊湊的LUT，使其能夠完全放入GPU的SRAM中；

2. 一個雙階段內核，利用輕量級的輔助變量來協調線程的讀寫位置；

3. Transformer Block級的解壓縮，從而最大限度地降低延遲。

在Llama-3.1、Qwen-2.5、Gemma-3等SOTA模型上的實驗表明， DFloat11除了能有效壓縮模型的大小之外，同時還能保持完全一致的輸出結果。

與將模型的部分數據卸載到CPU的方案相比，DFloat11在Token生成任務中實現了1.9到38.8倍的吞吐量提升。

在GPU顯存固定的情況下，DFloat11能夠支持比未壓縮模型長5.3到13.17倍的上下文長度。

特別值得一提的是，DFloat11成功地實現了Llama-3.1-405B（810GB）在單節點上（8塊80GB GPU）的無損推理。

Llama-3.1-405B擁有4050億參數，采用16位Brain Float（BFloat16）格式，需要約810GB內存才能實現完整推理，超過了典型GPU服務器的容量（如配備8×80GB GPU的DGX A100/H100）。

本文一作Tianyi Zhang，是萊斯大學計算機科學專業的博士生，之前在滑鐵盧大學獲得計算機科學學士學位。

為什么要對LLM進行無損壓縮？

在目前的有損量化技術中，模型通常被壓縮到更低的位寬度（如8位或4位）。

雖然部分基準測試表明，8位量化是一種相對「安全」的壓縮方案，但在實際體驗時終究不如無損的模型。

例如，LLM Arena上的人工評估顯示，Llama-3.1-405B-Instruct及其8位版本（Llama-3.1-405B-Instruct-FP8）之間的性能存在顯著下降，尤其是在編碼和長查詢任務中。

類似的，將DeepSeek-R1-Distill-Llama-70B從16位量化到8位會導致GPQA上的性能下降23.7%（從9.51%降至7.25%）。

此外，推理作為現代LLM的核心能力，似乎對壓縮損失特別敏感。

一些基準測試表明，使用8位SmoothQuant（用于權重、注意力和KV緩存）量化的DeepSeek-R1-Distill-Qwen-1.5B，會在AIME、MATH-500、GPQA-Diamond和LiveCodeBench等數據集上的推理性能，平均下降9.09%（從48.82%降至44.29%）。

有損壓縮降低質量，無損壓縮缺乏效率

相比之下，無損壓縮技術在有效減小大規模LLM大小的同時，能夠保留其精確的原始權重，確保模型的輸出分布與未壓縮表示（例如BFloat16）的輸出分布完全一致。

然而，現有的無損壓縮方法主要側重于提高LLM的存儲效率，例如縮小模型檢查點，或者優化諸如FPGA等專用硬件的性能。

這些方法雖然有利于訓練過程中的高效檢查點回滾，或者從Hugging Face等模型倉庫加速下載，但其優勢通常難以有效地擴展到基于GPU的LLM推理。

實驗方法

為了推動LLM權重的無損壓縮，團隊分析了最新LLM權重中BFloat16各個組成部分（符號、指數和尾數）的可壓縮性。

具體來說，團隊使用香農熵來量化LLM線性投影矩陣中參數的信息量。香農熵H(·)定義如下：

其中X是一個離散隨機變量，其所有可能取值的集合為χ，p:χ→[0,1]表示其概率質量函數。

如圖1所示，符號和尾數部分的熵值與其對應的位寬接近，說明它們的可壓縮空間不大。相比之下，指數部分的熵值明顯較低，只有約2.6位，但其分配的位數為8位，這意味著無損壓縮存在很大的機會。

無損LLM壓縮框架，實現高效GPU推理

為了解決LLM權重在BFloat16表示中存在的巨大信息冗余問題，團隊提出了一種利用熵編碼來對浮點參數進行編碼的無損壓縮框架——DFloat。

首先，基于LLM線性投影矩陣中所有BFloat16權重的指數分布構建一個Huffman樹。

然后，使Huffman編碼壓縮指數部分，同時保留原始的符號位和尾數。

指數被編碼后，緊密地打包到EncodedExponent字節數組中，而符號位和尾數則保持未壓縮狀態，存儲在另一個PackedSignMantissa字節數組中。

動態長度浮點數格式可以緊湊地表示浮點模型參數

使用緊湊LUT實現高效解碼

由于Huffman編碼可以通過機遇查找表（Lookup Table，LUT）的方法有效地解碼，于是團隊構建了一個大小為2^L的LUT，其中L是碼本中任何Huffman編碼的最大位長度。

為了進行解碼，團隊從編碼的位流中讀取接下來的L位，并將它們作為LUT的索引來獲取下一個解碼后的符號。

為了解碼DFloat11格式的指數，限制每個模型的最大代碼長度L為32位。

對于那些L大于32的模型，團隊通過將最不常見的指數的頻率降低到1并重新構建Huffman樹來強制滿足長度約束。

如此，便會在Huffman樹的尾部產生一個更加平衡的結構，為最稀有的指數分配相同長度的代碼，并將最大代碼長度縮減到3位。

然而，當L=32時，直接使用查找表將需要2³²≈42.9億個條目，這將消耗巨大的內存。

為了解決這個問題，團隊提出將這個龐大的LUT分割成四個互不相交且節省內存的查找表——LUT₁、LUT₂、LUT₃和LUT₄。

這樣一來，內存占用就可以完全放在GPU SRAM中，從而實現快速訪問。

兩階段Kernel和輕量級輔助變量

為了能夠對DFloat11格式中經過熵編碼的指數進行大規模并行解碼，團隊為每個線程分配一段固定長度的、來自編碼序列的字節來進行處理。

然而，這種方法會帶來兩個主要的挑戰：

1. 由于Huffman編碼的位寬是可變的，并且編碼后的數據是被緊密地打包在一起的，因此每個線程開始解碼的起始位位置并不明確。

2. 除了第一個線程之外，其他線程所要解碼的元素的索引是未知的，這導致難以確定用于存儲解碼結果的正確輸出位置。

為了解決第一個問題，團隊使用一個間隙數組來確定每個線程的起始位位置。

這個間隙數組Gaps為每個線程包含一個條目，每個條目都指定了相對于該線程所分配的起始字節，第一個有效Huffman編碼的位偏移量。由于最大代碼長度為32位，因此每個偏移量的值都在[0,31]范圍內。為了保證內存效率，團隊使用5個位來編碼每個條目。

為了解決第二個問題，最直接的方法是維護一個數組，用于存儲每個線程所解碼的第一個元素的輸出位置。然而，這種方法會帶來巨大的存儲開銷。

為了減少存儲開銷，團隊只存儲每個線程塊中第一個元素的輸出位置，而不是存儲每個線程的輸出位置。

為了能夠使用塊級的輸出位置信息進行解碼，團隊采用了一種兩階段的Kernel設計。

在第一階段，一個線程塊內的所有線程并行地解碼分配給它們的那部分編碼序列，但是并不將任何輸出結果寫入到全局內存中。取而代之的是，每個線程會計算它將要解碼的元素的數量。

完成這一步之后，團隊同步同一個線程塊內的所有線程，并通過計算前綴和來確定每個線程的輸出位置，計算前綴和的起始位置是該線程塊的已知輸出位置。

在第二階段，每個線程會重新解碼相同的那部分編碼序列，這一次會將解碼后的結果寫入到HBM中正確的輸出位置。

為了避免在這兩個階段中重復訪問HBM，團隊將編碼后的指數數據加載到SRAM中。

兩階段Kernel的偽代碼

Transformer Block級解壓縮

至此，就有了一套完整的方法，可以對經過熵編碼的指數進行大規模并行解壓縮。

LLM的權重以DFloat11格式存儲，同時還包含輕量級的輔助數據：線程級的間隙偏移量以及塊級的輸出位置，這些數據用于確定每個線程的讀取和寫入位置。

在推理過程中，壓縮后的權重數據和這些輔助變量都完全駐留在GPU上。

當需要使用某個權重矩陣進行矩陣乘法運算時，該矩陣會被動態地解壓縮為原始的BFloat16格式。一旦矩陣乘法運算完成，這個BFloat16格式的矩陣會立即被丟棄，以節省GPU顯存。

在實際應用中，由于單個權重矩陣的尺寸通常相對較小，因此單獨解壓縮一個權重矩陣往往無法充分利用GPU資源。

在DFloat11解壓縮Kernel中，將每個線程處理的字節數設置為n=8，每個線程塊中的線程數設置為T=256，線程塊的數量設置為B=?|EncodedExponent|/(nT)?，其中|EncodedExponent|表示編碼后的指數數據所占的總字節數。

隨著DFloat11格式的權重數據尺寸的增加，會有更多的線程塊被利用起來，從而可以提高整體的解壓縮吞吐量。

圖6展示了這種現象，它表明解壓縮的吞吐量會隨著矩陣尺寸的增加而顯著提升。為了充分利用這一特性，研究團隊建議將多個矩陣的解壓縮操作進行批處理，以此來提高吞吐量并隱藏延遲。

更具體地說，可以將單個Transformer Block內的所有DFloat11格式的權重矩陣的解壓縮操作進行批處理。

在Transformer Block中執行任何計算操作之前，團隊首先解壓縮與其相關聯的所有權重數據。這種方法能夠顯著降低解壓縮的延遲，并提高整體的推理效率。

圖5展示了在不同的批處理大小下，使用DFloat11壓縮的Llama-3.1-8B-Instruct模型的延遲細分情況。

實驗結果

DF11將LLM壓縮至70%大小

表2展示了DF11對多種最新LLM的壓縮比率。

壓縮的模型包括LLaMA3/3.1/3.3、Qwen2.5、QwQ、Mistral Nemo/Small/Codestral、Gemma2/3以及DeepSeek-R1-Distilled。

實驗結果顯示，DF11對所有模型的壓縮比約為70%，相當于大約11位的有效位寬。

DF11壓縮完全無損

研究團隊通過一系列標準基準測試驗證了DF11壓縮的無損特性。

評估使用lm_evaluation_harness工具進行，報告了MMLU和TruthfulQA的準確率，以及WikiText和C4的詞級困惑度。

如表3所示，壓縮模型的準確率和困惑度與原始BF16模型完全一致。

為了進一步驗證無損特性，他們將DF11解壓后的BF16權重矩陣與表2中各模型的原始權重矩陣進行比較，確認兩者在比特級上完全相同。

DF11在推理效率上超越CPU卸載

研究團隊比較了DF11和BF16模型在不同硬件平臺上的推理效率。

未壓縮的BF16模型通常會超出單個GPU的顯存限制，而無損壓縮的DF11模型則不會超出。

對于BF16模型，團隊將模型的大部分內容和計算保留在GPU上，同時將部分組件及其相關計算卸載到CPU上。

如圖3所示，DF11模型始終優于采用CPU卸載的BF16模型，延遲降低了1.85至38.83倍或吞吐量更高。

DF11支持更長的生成長度

DF11壓縮帶來的顯存節省不僅減少了推理所需的GPU數量，還支持更長的生成長度。

在推理過程中，KV緩存會隨著解碼token數量的增加而線性增長，很快成為GPU顯存的瓶頸。

圖4展示了在批大小為1時，DF11和BF16模型在推理過程中隨著解碼token數量增加的GPU顯存消耗情況。

如圖所示，DF11壓縮顯著延長了token生成長度，與BF16模型相比，在達到GPU顯存限制前能解碼5.33至13.17倍的token數量。

結論

在這項工作中，研究人員提出了動態長度浮點（DFloat）作為一種針對LLM權重的無損壓縮數據格式。DFloat是目前唯一一種既能減少顯存占用又兼容高效GPU推理的數據格式。

具體來說，他們使用11位的DFloat格式（DF11）評估了多個熱門LLM，并為此格式開發了定制的GPU內核。

實驗結果表明，基于DF11的壓縮顯著降低了服務LLM的硬件需求，而且在大多數實際應用場景下，它所增加的額外計算負擔也是可以接受的。