Cloudflare推出Unweight無損壓縮系統，將LLM模型大小壓縮15-22%

Cloudflare推出Unweight無損壓縮系統，將LLM模型大小壓縮15-22%，解決H100 GPU記憶體頻寬瓶頸。

Cloudflare開發「Unweight」，這是無損推論時壓縮系統，針對模型權重進行壓縮，實現最高22%模型足跡縮減，同時保持位元精確輸出，讓LLM推論在全球95%網際網路使用者50ms內回應更高效。

GPU記憶體瓶頸成關鍵

在Cloudflare的資料中心使用NVIDIA H100 GPU，張量核心處理資料速度比記憶體提供快近600倍，導致推論瓶頸不在運算而在記憶體頻寬。產生單一token需從GPU記憶體讀取所有模型權重，每位元組穿越記憶體匯流排皆是浪費，若權重更小即可避免此問題。

Unweight核心創新

Unweight僅壓縮MLP（多層感知器）權重，這些佔模型參數約三分之二，並主導token產生時的記憶體流量。壓縮在晶片上快取記憶體（shared memory）解壓，直接饋入張量核心，避免額外穿越慢速主記憶體的往返。依工作負載，執行階段從多種策略選擇，如優先簡易性或最小化記憶體流量，並由自動調優器依權重矩陣與批次大小挑選最佳者。

Cloudflare發布技術論文並開源GPU核心，促進此快速發展領域的創新透明。

為何壓縮難度高

常見量化為有損壓縮，將32或16位元浮點數轉為8或4位元整數，不同浮點值可能映射相同整數，影響回應品質不可預測。Unweight堅持無損，保留模型精確行為。

先前系統如Huff-LLM、ZipNN、ZipServ雖達顯著壓縮，但不符需求：ZipNN在CPU解壓用於儲存分發；Huff-LLM需自訂FPGA硬體；ZipServ針對消費級GPU，無法整合Cloudflare的Rust基推論引擎Infire與H100 Hopper GPU。

挑戰不在壓縮本身（BF16權重指數位元組高度冗餘，entropy coding有效），而在解壓速度：GPU運算單元無法同時執行解壓與矩陣乘法核心，因共享記憶體限制。任何未完美重疊的解壓延遲，直接加到token延遲。

BF16權重壓縮原理

每個AI模型數字存為16位元「brain float」（BF16），分三部分：

• 符號（1位元）：正負
• 指數（8位元）：大小
• 尾數（7位元）：大小內精確值

訓練LLM中，256種指數值僅少數主導，前16種最常見指數涵蓋典型層99%以上權重，資訊理論只需約2.6位元表示，遠少於8位元。

Unweight保留符號與尾數不變，僅用Huffman coding壓縮指數位元組（常見值短碼、稀有值長碼），因分佈極度偏態，達指數流約30%壓縮。僅選MLP權重矩陣（gate、up、down投影），Attention權重、嵌入與層規範不壓縮，整體MLP權重縮減約20%，詳見技術報告。

稀有指數處理：若64權重列中任一超出前16指數調色盤，整列verbatim儲存，避免熱路徑每元素分支，僅每列預先一判斷。

H100記憶體階層

H100有兩種記憶體：

• 高頻寬記憶體（HBM）：大容量但存取相對慢，模型權重存放處。
• 共享記憶體（SMEM）：極小但極快，GPU數學前暫存處。

推論中，每token需從HBM讀完整權重矩陣，此為瓶頸。壓縮減低匯流排位元組，但GPU無法直接運算壓縮資料，需先解壓。

多數先前工作將整矩陣解壓回HBM，再標準矩陣乘法，僅助儲存容量，不解頻寬問題，因每token仍讀完整未壓縮矩陣。

四種執行管道

Unweight提供四種壓縮執行管道，依批次大小、權重矩陣形狀與GPU時間平衡解壓努力與運算複雜度：

• 完整Huffman解碼：重建原BF16權重，交NVIDIA cuBLAS標準矩陣乘法。簡易，cuBLAS全速，但預處理寫最多位元組回主記憶體。小批次（1-64 token）佳，因自訂核心固定成本主導。
• 僅指數解碼：僅解碼指數位元組，減半預處理流量。用重建矩陣乘法核心，在共享記憶體重建BF16，直接饋張量核心。
• 調色盤轉碼：運行時轉4位元調色盤索引，減低四分之一預處理。用重建矩陣乘法。
• 直接調色盤：模型載入時預轉4位元格式，矩陣乘法核心即時從索引重建BF16。零預處理，但每元素多工。

無單一管道全勝：小批次cuBLAS低開銷勝出；大批次（256+ token）輕預處理釋放匯流排與運算重疊，調色盤或指數管道領先。同層不同矩陣（如gate/up與down投影維度異）偏好不同。

重建矩陣乘法核心運作

三管道用自訂矩陣乘法核心，融合解壓與運算：從HBM載壓縮資料，在共享記憶體重建BF16，直接饋Hopper WGMMA張量核心指令，重建權重不經主記憶體。

GPU執行緒群分兩役：

• 生產者群：用專用記憶體複製硬體（TMA）從HBM載壓縮輸入至共享記憶體，暫存符號+尾數、指數資料（或調色盤索引）與稀有指數verbatim列。領先消費者，填充循環緩衝確保資料就緒。
• 消費者群：組合指數與符號+尾數重建BF16，即時饋入張量核心。

解壓與運算資源共享

融合管道中，獨立預處理核心（Huffman解碼器或調色盤轉碼器）與重建矩陣乘法並行，但爭奪GPU資源。每Hopper運算單元（SM）有228 KB共享記憶體：重建matmul需227 KB緩衝與累加器；解碼需16 KB Huffman查表。227+16>228，无法同SM。

此需平衡：多解碼SM加速預處理但減matmul SM，反之亦然。最佳分割為可調參數，自動調優器測量真實吞吐決定。

跨層管道化

利用Transformer結構隱藏解壓成本：分類層為「hard」（需運行時Huffman）或「easy」（預轉調色盤，直接供matmul）。運行階段交替，減少連續解壓。

自動調優機制

四管道、多matmul變體與SM分割，配置空間大。Unweight自動調優器測量目標硬體端到端推論吞吐：掃描gate投影（固定up/down），再up、再down，重複至無改善。產生每模型配置檔，指定每投影每批次大小的最佳管道、matmul變體與SM分配，依實測而非啟發式。

Llama 3.1 8B測試結果

• 推論bundle壓縮gate/up MLP投影，模型足跡減13%。
• 分發bundle壓縮全MLP含down，減22%。
• 皆100%位元精確無損。
• 推斷Llama 70B，可省18-28 GB依配置。
• H100 SXM5端到端吞吐開銷30-40%：批次1達41%，批次1024降至30%。

開銷來源：小批次固定成本、重複權重磚重建、排除down投影，正積極優化。

Unweight重要性與限制

GPU昂貴：卡片成本、高頻寬記憶體需求、功率消耗。先前研究達全模型30%壓縮，但限消費GPU與研究框架，非生產規模。

Unweight聚焦MLP（多數權重與推論運算成本），僅壓縮效益層，避免邊際層開銷；專為資料中心H100設計，四管道適應批次大小。

但非免費午餐：晶片上重建增運算，在Llama 3.1 8B推論配置省13%模型記憶體，代價典型批次30%吞吐。大批次開銷縮小（預處理重疊改善），預期優化後更佳，尤其是down投影（可壓三分之一權重）與核心改善。

對Cloudflare網路，提升容量：每實例少GPU記憶體，降低成本、更多地點部署更多模型。分發bundle省22%，加速全球邊緣傳輸。

未來方向

• Down投影壓縮：目前僅gate/up，down佔可壓三分之一，因轉置維度需新核心，預期總大小超22%。
• 核心優化：30-40%開銷三源（小批固定成本、大批重複重建、缺down），技術論文列緩解路徑。
• 擴大模型：結果限Llama 3.1 8B，指數統計一致SwiGLU架構所有規模，正引入Workers AI更大模型。