MiniCPM5-1B 驗證: 4.7× 壓縮, 44ms 推理, 1.3GB 顯存, INT8 無損還原摘要INT8 量化將大語言模型 (LLM) 權重壓縮 2× (16→8 bit/w), 但 INT8 字節流本身仍存在顯著冗余 — 全局信息熵僅 4.66 bit/w。現有無損壓縮方案 (Huffman, ANS) 雖可逼近熵極限, 但變長編碼導致 GPU 上無法高效并行解碼。我們提出 INT8-X (3,5,8): 一種基于嵌套 bitmap 的三級定長編碼方案, 通過將 INT8 權重按絕對值分為三級 (3-bit / 5-bit / 8-bit), 在保持完全并行的前提下實現 5.50 bit/w 的有效位寬。關鍵創新是將 bitmap 前綴掃描 (cumsum)、位流提取和權重重建融合進單個 Triton 內核, 利用tl.cumsum在內核內完成變長流定位。在 MiniCPM5-1B (1B 參數, 168 層) 上, INT8-X 實現 463MB 存儲 (4.7× vs bf16)、1.3GB GPU 顯存 (省 41%)、44ms 推理 (僅 1.26× bf16 開銷), 且 INT8 權重 100% 無損還原。關鍵詞: 模型量化, 無損壓縮, Triton, bitmap 編碼, LLM 部署1. 引言INT8 量化是 LLM 部署的標準壓縮手段, 將 bf16 權重 (16 bit/w) 壓縮為 INT8 (8 bit/w), 實現 2× 存儲/顯存節省。然而, INT8 量化后的權重分布高度集中在零附近 (圖 1), 其 Shannon 熵僅 4.66 bit/w — 意味著 INT8 字節流本身仍有 42% 的冗余空間。進一步無損壓縮 INT8 數據的現有方案存在根本性矛盾:變長編碼 (Huffman/ANS): 可逼近熵極限 (4.66 bit/w), 但每個符號的碼長不同, 解碼時元素間存在數據依賴, GPU 無法高效并行化。實測塊并行 Huffman 解碼需 442ms (12.6× bf16)。定長塊編碼: GPU 友好, 但每塊需覆蓋塊內最大值, 導致位寬浪費。實測最優塊方案僅達 6.5 bit/w。我們提出 INT8-X, 通過多級定長 嵌套 bitmap架構解決這一矛盾, 并通過Triton 內核融合實現接近零開銷的實時解碼。2. 方法2.1 三級定長編碼將 INT8 權重按絕對值分為三級:Level 1 (3-bit): |v| ≤ 3 → 55.5% 權重 ← 主體 Level 2 (5-bit): |v| ≤ 15 → 40.4% 權重 Level 3 (8-bit): |v| 15 → 4.1% 權重 ← 稀疏離群點每級使用定長編碼, 存儲為三個獨立的位打包流:L1 流: n1 × 3 bits (打包成 int32 位流) L2 流: n2 × 5 bits (打包成 int32 位流) L3 流: n3 × 8 bits (原始 uint8 字節)2.2 嵌套 Bitmap 定位三級元素的全局位置通過兩層 bitmap 編碼:Bitmap 1 (N bit): 0 Level 1, 1 檢查 Bitmap 2 Bitmap 2 (0.445N bit): 0 Level 2, 1 Level 3Bitmap 開銷: 1 0.445 1.445 bit/w解碼時, 通過 cumsum(bitmap) 計算每個元素在其級別流中的位置, 實現精確定位。2.3 有效位寬計算flag (bitmap): 1.445 bit/w data (L1L2L3): 0.555×3 0.404×5 0.041×8 4.013 bit/w ──────────────────────────────────────────────── 總計: 5.46 bit/w → 2.93× vs bf16 (純權重) 含 scale 共享: 5.50 bit/w → 4.7× vs bf16 (含 embedding)2.4 Triton 融合內核核心創新: 將以下操作融合進單個 Triton 內核:triton.jitdef_ix358_fused_kernel(out,b1,b2,l1,l2,l3,b1_blk,b2_blk,scale,N,BLK):# 1. 讀取 B1 bitmap 位is_l1_bit(b1[word]bit)1# 2. 塊內 cumsum → 計算 L1 流位置l1_local_ranktl.cumsum(is_l1_bit,axis0)-1l1_rankl1_beforel1_local_rank# 3. 從 L1 位流提取 3-bit 值 (跨字條件)valextract_bits(l1,l1_rank*3,3)# 4. 非 L1: 讀 B2 → cumsum → L2 流位置# 5. 從 L2 位流提取 5-bit 值# 6. L3: 直接讀 uint8# 7. 選擇: val where(is_l1, l1_val, where(is_l2, l2_val, l3_val))# 8. 重建: w val × scale關鍵:tl.cumsum在 Triton 3.7 中原生支持, 允許內核內完成前綴掃描, 避免了 PyTorch 層面的多次 cumsum 調用和臨時數組分配。塊間前綴和 (block-level prefix sum) 在編碼時預計算, 存儲為 int32 數組 (每 1024 元素 1 個值 0.001 bit/w 開銷)。2.5 編碼流程 (離線, 一次性)bf16 權重 → INT8 量化 (per-tensor scale) → 按絕對值分級 (L1/L2/L3) → 打包: L1(3b stream) L2(5b stream) L3(raw) B1(bitmap) B2(bitmap) → 預計算: 塊級前綴和 (b1_blk, b2_blk)3. 實驗3.1 實驗設置參數值模型MiniCPM5-1B (168 層, 679M Linear 權重)量化INT8 per-tensor symmetricGPURTX 4090 24GB框架PyTorch 2.13 Triton 3.7.1基線bf16 原始模型3.2 推理性能模式FwdGPU 顯存存儲vs bf16 速度vs bf16 壓縮bf1635ms2.2GB2161MB1.0×1.0×INT8 (per-tensor)——679MB—3.2×INT8-X (3,5,8)44ms1.3GB463MB0.80×4.7×Huffman-INT8 (block)442ms1.5GB389MB0.08×5.6×INT8-X 僅比 bf16 慢 26% (44ms vs 35ms), 但存儲壓縮 4.7×、顯存節省 41%。3.3 無損驗證INT8-X 對 INT8 量化值實現 100% 精確還原:原始 INT8 → INT8-X 編碼 → Triton 解碼 → 還原 INT8 匹配率: 100.0% (679M 權重逐元素驗證)端到端質量等價于 INT8 量化 (bf16 → INT8 的量化誤差不在本文范圍內)。3.4 版本演進版本技術FwdGPU關鍵改進v7Python 逐 bit 解包676ms1.6GB基線v8PyTorch 向量化解包446ms1.8GB消除 Python 循環v9Triton PyTorch cumsum175ms1.6GBTriton bit 提取v10Triton 融合 (tl.cumsum)44ms1.3GB全融合單 kernelv10 相比 v7 加速15.4×, 核心來自tl.cumsum的內核內前綴掃描。3.5 方案對比方案bit/wFwdGPU無損?GPU 解碼bf161635ms2.2GB——BF16X (bf16無損)12.4105ms2.0GB? bf16快 (Triton)INT8 plain8.0———極快DG 4-bit (QAT)4.550ms1.2GB? (可恢復)快 (Triton)INT8-X (3,5,8)5.544ms1.3GB? INT8快 (Triton融合)Huffman4.66442ms1.5GB? INT8慢 (串行)INT8-X 在速度 (44ms)、壓縮 (4.7×) 和無損性 (INT8) 之間取得最優 Pareto 平衡。4. 級別選擇分析4.1 窮舉搜索對 2~5 級嵌套 bitmap 的所有 bit 組合進行窮舉搜索:方案bit/wvs bf16備注(3,4,5,6,8) 5級5.333.00×最優但復雜(3,4,5,8) 4級5.402.96×(3,5,8) 3級5.502.93×Pareto 最優(2,4,6,8) 4級5.702.81×2b 覆蓋太少4.2 第一級位寬的甜點分析第一級 bit 數 覆蓋率 bitmap開銷 數據位寬 總計 1-bit 13.8% 1.86 b/w 3.91 b/w 5.77 b/w 2-bit 27.6% 1.72 b/w 4.14 b/w 5.86 b/w 3-bit 55.5% 1.49 b/w 4.01 b/w 5.50 b/w ← 最優 4-bit 82.8% 1.18 b/w 4.35 b/w 5.53 b/w 5-bit 95.9% 1.04 b/w 4.96 b/w 6.00 b/w3-bit 是甜點: 覆蓋過半 (55.5%) 權重, 同時數據位寬足夠低 (3b), bitmap 二次查詢開銷適中 (44.5% 需查 B2)。5. 討論5.1 為什么不定長更低位?定長方案的天花板在 ~5.3 bit/w (5 級)。低于此需變長編碼 (Huffman 4.66 bit/w), 但 GPU 串行解碼代價高昂 (442ms vs 44ms)。INT8-X (3,5,8) 在 5.50 bit/w 處取得速度-壓縮最優平衡。5.2 與 DFloat11 的關系DFloat11 [Zhang et al., 2025] 對 bf16 指數做 Huffman 編碼, GPU 解碼需分層 LUT 塊內串行掃描。INT8-X 改用定長多級 bitmap 定位, 避免了變長解碼的串行依賴, 實現全并行 Triton 內核。5.3 局限僅驗證 MiniCPM5-1B, 需擴展到 7B/13BL3 (8-bit raw) 未進一步壓縮, 占 4.1% 但貢獻 0.33 bit/w塊級前綴和預計算增加編碼復雜度6. 結論我們提出 INT8-X (3,5,8): 一種基于多級定長 嵌套 bitmap 的 INT8 無損壓縮方案, 配合 Triton 融合內核實現接近零開銷的實時解碼。在 MiniCPM5-1B 上實現 4.7× 壓縮、1.3GB 顯存、44ms 推理, 且 INT8 權重 100% 無損還原。tl.cumsum內核內前綴掃描是關鍵加速技術, 將解碼從 676ms 降到 44ms (15.4× 加速)。開源代碼: https://www.modelscope.cn/models/dfytensor/MiniCPM5-1B-DG-INT4參考文獻[1] Zhang et al. “70% Size, 100% Accuracy: Lossless LLM Compression for Efficient GPU Inference via Dynamic-Length Float (DFloat11).” NeurIPS 2025.[2] Frantar et al. “GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers.” ICLR 2023.[3] Lin et al. “AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration.” MLSys 2024.[4] Tillet et al. “Triton: an intermediate language and compiler for tiled neural network computations.” 2019. INT8-X: 多級定長無損 INT8 壓縮與 Triton 融合解碼
MiniCPM5-1B 驗證: 4.7× 壓縮, 44ms 推理, 1.3GB 顯存, INT8 無損還原摘要INT8 量化將大語言模型 (LLM) 權重壓縮 2× (16→8 bit/w), 但 INT8 字節流本身仍存在顯著冗余 — 全局信息熵僅 4.66 bit/w。現有無損壓縮方案 (Huffman, ANS) 雖可逼近熵極限, 但變長編碼導致 GPU 上無法高效并行解碼。我們提出 INT8-X (3,5,8): 一種基于嵌套 bitmap 的三級定長編碼方案, 通過將 INT8 權重按絕對值分為三級 (3-bit / 5-bit / 8-bit), 在保持完全并行的前提下實現 5.50 bit/w 的有效位寬。關鍵創新是將 bitmap 前綴掃描 (cumsum)、位流提取和權重重建融合進單個 Triton 內核, 利用tl.cumsum在內核內完成變長流定位。在 MiniCPM5-1B (1B 參數, 168 層) 上, INT8-X 實現 463MB 存儲 (4.7× vs bf16)、1.3GB GPU 顯存 (省 41%)、44ms 推理 (僅 1.26× bf16 開銷), 且 INT8 權重 100% 無損還原。關鍵詞: 模型量化, 無損壓縮, Triton, bitmap 編碼, LLM 部署1. 引言INT8 量化是 LLM 部署的標準壓縮手段, 將 bf16 權重 (16 bit/w) 壓縮為 INT8 (8 bit/w), 實現 2× 存儲/顯存節省。然而, INT8 量化后的權重分布高度集中在零附近 (圖 1), 其 Shannon 熵僅 4.66 bit/w — 意味著 INT8 字節流本身仍有 42% 的冗余空間。進一步無損壓縮 INT8 數據的現有方案存在根本性矛盾:變長編碼 (Huffman/ANS): 可逼近熵極限 (4.66 bit/w), 但每個符號的碼長不同, 解碼時元素間存在數據依賴, GPU 無法高效并行化。實測塊并行 Huffman 解碼需 442ms (12.6× bf16)。定長塊編碼: GPU 友好, 但每塊需覆蓋塊內最大值, 導致位寬浪費。實測最優塊方案僅達 6.5 bit/w。我們提出 INT8-X, 通過多級定長 嵌套 bitmap架構解決這一矛盾, 并通過Triton 內核融合實現接近零開銷的實時解碼。2. 方法2.1 三級定長編碼將 INT8 權重按絕對值分為三級:Level 1 (3-bit): |v| ≤ 3 → 55.5% 權重 ← 主體 Level 2 (5-bit): |v| ≤ 15 → 40.4% 權重 Level 3 (8-bit): |v| 15 → 4.1% 權重 ← 稀疏離群點每級使用定長編碼, 存儲為三個獨立的位打包流:L1 流: n1 × 3 bits (打包成 int32 位流) L2 流: n2 × 5 bits (打包成 int32 位流) L3 流: n3 × 8 bits (原始 uint8 字節)2.2 嵌套 Bitmap 定位三級元素的全局位置通過兩層 bitmap 編碼:Bitmap 1 (N bit): 0 Level 1, 1 檢查 Bitmap 2 Bitmap 2 (0.445N bit): 0 Level 2, 1 Level 3Bitmap 開銷: 1 0.445 1.445 bit/w解碼時, 通過 cumsum(bitmap) 計算每個元素在其級別流中的位置, 實現精確定位。2.3 有效位寬計算flag (bitmap): 1.445 bit/w data (L1L2L3): 0.555×3 0.404×5 0.041×8 4.013 bit/w ──────────────────────────────────────────────── 總計: 5.46 bit/w → 2.93× vs bf16 (純權重) 含 scale 共享: 5.50 bit/w → 4.7× vs bf16 (含 embedding)2.4 Triton 融合內核核心創新: 將以下操作融合進單個 Triton 內核:triton.jitdef_ix358_fused_kernel(out,b1,b2,l1,l2,l3,b1_blk,b2_blk,scale,N,BLK):# 1. 讀取 B1 bitmap 位is_l1_bit(b1[word]bit)1# 2. 塊內 cumsum → 計算 L1 流位置l1_local_ranktl.cumsum(is_l1_bit,axis0)-1l1_rankl1_beforel1_local_rank# 3. 從 L1 位流提取 3-bit 值 (跨字條件)valextract_bits(l1,l1_rank*3,3)# 4. 非 L1: 讀 B2 → cumsum → L2 流位置# 5. 從 L2 位流提取 5-bit 值# 6. L3: 直接讀 uint8# 7. 選擇: val where(is_l1, l1_val, where(is_l2, l2_val, l3_val))# 8. 重建: w val × scale關鍵:tl.cumsum在 Triton 3.7 中原生支持, 允許內核內完成前綴掃描, 避免了 PyTorch 層面的多次 cumsum 調用和臨時數組分配。塊間前綴和 (block-level prefix sum) 在編碼時預計算, 存儲為 int32 數組 (每 1024 元素 1 個值 0.001 bit/w 開銷)。2.5 編碼流程 (離線, 一次性)bf16 權重 → INT8 量化 (per-tensor scale) → 按絕對值分級 (L1/L2/L3) → 打包: L1(3b stream) L2(5b stream) L3(raw) B1(bitmap) B2(bitmap) → 預計算: 塊級前綴和 (b1_blk, b2_blk)3. 實驗3.1 實驗設置參數值模型MiniCPM5-1B (168 層, 679M Linear 權重)量化INT8 per-tensor symmetricGPURTX 4090 24GB框架PyTorch 2.13 Triton 3.7.1基線bf16 原始模型3.2 推理性能模式FwdGPU 顯存存儲vs bf16 速度vs bf16 壓縮bf1635ms2.2GB2161MB1.0×1.0×INT8 (per-tensor)——679MB—3.2×INT8-X (3,5,8)44ms1.3GB463MB0.80×4.7×Huffman-INT8 (block)442ms1.5GB389MB0.08×5.6×INT8-X 僅比 bf16 慢 26% (44ms vs 35ms), 但存儲壓縮 4.7×、顯存節省 41%。3.3 無損驗證INT8-X 對 INT8 量化值實現 100% 精確還原:原始 INT8 → INT8-X 編碼 → Triton 解碼 → 還原 INT8 匹配率: 100.0% (679M 權重逐元素驗證)端到端質量等價于 INT8 量化 (bf16 → INT8 的量化誤差不在本文范圍內)。3.4 版本演進版本技術FwdGPU關鍵改進v7Python 逐 bit 解包676ms1.6GB基線v8PyTorch 向量化解包446ms1.8GB消除 Python 循環v9Triton PyTorch cumsum175ms1.6GBTriton bit 提取v10Triton 融合 (tl.cumsum)44ms1.3GB全融合單 kernelv10 相比 v7 加速15.4×, 核心來自tl.cumsum的內核內前綴掃描。3.5 方案對比方案bit/wFwdGPU無損?GPU 解碼bf161635ms2.2GB——BF16X (bf16無損)12.4105ms2.0GB? bf16快 (Triton)INT8 plain8.0———極快DG 4-bit (QAT)4.550ms1.2GB? (可恢復)快 (Triton)INT8-X (3,5,8)5.544ms1.3GB? INT8快 (Triton融合)Huffman4.66442ms1.5GB? INT8慢 (串行)INT8-X 在速度 (44ms)、壓縮 (4.7×) 和無損性 (INT8) 之間取得最優 Pareto 平衡。4. 級別選擇分析4.1 窮舉搜索對 2~5 級嵌套 bitmap 的所有 bit 組合進行窮舉搜索:方案bit/wvs bf16備注(3,4,5,6,8) 5級5.333.00×最優但復雜(3,4,5,8) 4級5.402.96×(3,5,8) 3級5.502.93×Pareto 最優(2,4,6,8) 4級5.702.81×2b 覆蓋太少4.2 第一級位寬的甜點分析第一級 bit 數 覆蓋率 bitmap開銷 數據位寬 總計 1-bit 13.8% 1.86 b/w 3.91 b/w 5.77 b/w 2-bit 27.6% 1.72 b/w 4.14 b/w 5.86 b/w 3-bit 55.5% 1.49 b/w 4.01 b/w 5.50 b/w ← 最優 4-bit 82.8% 1.18 b/w 4.35 b/w 5.53 b/w 5-bit 95.9% 1.04 b/w 4.96 b/w 6.00 b/w3-bit 是甜點: 覆蓋過半 (55.5%) 權重, 同時數據位寬足夠低 (3b), bitmap 二次查詢開銷適中 (44.5% 需查 B2)。5. 討論5.1 為什么不定長更低位?定長方案的天花板在 ~5.3 bit/w (5 級)。低于此需變長編碼 (Huffman 4.66 bit/w), 但 GPU 串行解碼代價高昂 (442ms vs 44ms)。INT8-X (3,5,8) 在 5.50 bit/w 處取得速度-壓縮最優平衡。5.2 與 DFloat11 的關系DFloat11 [Zhang et al., 2025] 對 bf16 指數做 Huffman 編碼, GPU 解碼需分層 LUT 塊內串行掃描。INT8-X 改用定長多級 bitmap 定位, 避免了變長解碼的串行依賴, 實現全并行 Triton 內核。5.3 局限僅驗證 MiniCPM5-1B, 需擴展到 7B/13BL3 (8-bit raw) 未進一步壓縮, 占 4.1% 但貢獻 0.33 bit/w塊級前綴和預計算增加編碼復雜度6. 結論我們提出 INT8-X (3,5,8): 一種基于多級定長 嵌套 bitmap 的 INT8 無損壓縮方案, 配合 Triton 融合內核實現接近零開銷的實時解碼。在 MiniCPM5-1B 上實現 4.7× 壓縮、1.3GB 顯存、44ms 推理, 且 INT8 權重 100% 無損還原。tl.cumsum內核內前綴掃描是關鍵加速技術, 將解碼從 676ms 降到 44ms (15.4× 加速)。開源代碼: https://www.modelscope.cn/models/dfytensor/MiniCPM5-1B-DG-INT4參考文獻[1] Zhang et al. “70% Size, 100% Accuracy: Lossless LLM Compression for Efficient GPU Inference via Dynamic-Length Float (DFloat11).” NeurIPS 2025.[2] Frantar et al. “GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers.” ICLR 2023.[3] Lin et al. “AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration.” MLSys 2024.[4] Tillet et al. “Triton: an intermediate language and compiler for tiled neural network computations.” 2019.