# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Cloudflare (@Cloudflare) · 平台：X (Twitter) · 日期：2026-04-18

> 原始來源：https://x.com/cloudflare/status/2045399611766878352

## 中文摘要

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更大模型。

## 標籤

LLM, 新產品, 產業趨勢, Cloudflare, NVIDIA