定長(zhǎng)無(wú)損 INT8 壓縮與 Triton 融合解碼)
MiniCPM5-1B 驗(yàn)證: 4.7× 壓縮, 44ms 推理, 1.3GB 顯存, INT8 無(wú)損還原摘要INT8 量化將大語(yǔ)言模型 (LLM) 權(quán)重壓縮 2× (16→8 bit/w), 但 INT8 字節(jié)流本身仍存在顯著冗余 — 全局信息熵僅 4.66 bit/w?，F(xiàn)有無(wú)損壓縮方案 (Huffman, ANS) 雖可逼近熵極限, 但變長(zhǎng)編碼導(dǎo)致 GPU 上無(wú)法高效并行解碼。我們提出 INT8-X (3,5,8): 一種基于嵌套 bitmap 的三級(jí)定長(zhǎng)編碼方案, 通過(guò)將 INT8 權(quán)重按絕對(duì)值分為三級(jí) (3-bit / 5-bit / 8-bit), 在保持完全并行的前提下實(shí)現(xiàn) 5.50 bit/w 的有效位寬。關(guān)鍵創(chuàng)新是將 bitmap 前綴掃描 (cumsum)、位流提取和權(quán)重重建融合進(jìn)單個(gè) Triton 內(nèi)核, 利用tl.cumsum在內(nèi)核內(nèi)完成變長(zhǎng)流定位。在 MiniCPM5-1B (1B 參數(shù), 168 層) 上, INT8-X 實(shí)現(xiàn) 463MB 存儲(chǔ) (4.7× vs bf16)、1.3GB GPU 顯存 (省 41%)、44ms 推理 (僅 1.26× bf16 開銷), 且 INT8 權(quán)重 100% 無(wú)損還原。關(guān)鍵詞: 模型量化, 無(wú)損壓縮, Triton, bitmap 編碼, LLM 部署1. 引言INT8 量化是 LLM 部署的標(biāo)準(zhǔn)壓縮手段, 將 bf16 權(quán)重 (16 bit/w) 壓縮為 INT8 (8 bit/w), 實(shí)現(xiàn) 2× 存儲(chǔ)/顯存節(jié)省。然而, INT8 量化后的權(quán)重分布高度集中在零附近 (圖 1), 其 Shannon 熵僅 4.66 bit/w — 意味著 INT8 字節(jié)流本身仍有 42% 的冗余空間。進(jìn)一步無(wú)損壓縮 INT8 數(shù)據(jù)的現(xiàn)有方案存在根本性矛盾:變長(zhǎng)編碼 (Huffman/ANS): 可逼近熵極限 (4.66 bit/w), 但每個(gè)符號(hào)的碼長(zhǎng)不同, 解碼時(shí)元素間存在數(shù)據(jù)依賴, GPU 無(wú)法高效并行化。實(shí)測(cè)塊并行 Huffman 解碼需 442ms (12.6× bf16)。定長(zhǎng)塊編碼: GPU 友好, 但每塊需覆蓋塊內(nèi)最大值, 導(dǎo)致位寬浪費(fèi)。實(shí)測(cè)最優(yōu)塊方案僅達(dá) 6.5 bit/w。我們提出 INT8-X, 通過(guò)多級(jí)定長(zhǎng) 嵌套 bitmap架構(gòu)解決這一矛盾, 并通過(guò)Triton 內(nèi)核融合實(shí)現(xiàn)接近零開銷的實(shí)時(shí)解碼。2. 方法2.1 三級(jí)定長(zhǎng)編碼將 INT8 權(quán)重按絕對(duì)值分為三級(jí):Level 1 (3-bit): |v| ≤ 3 → 55.5% 權(quán)重 ← 主體 Level 2 (5-bit): |v| ≤ 15 → 40.4% 權(quán)重 Level 3 (8-bit): |v| 15 → 4.1% 權(quán)重 ← 稀疏離群點(diǎn)每級(jí)使用定長(zhǎng)編碼, 存儲(chǔ)為三個(gè)獨(dú)立的位打包流:L1 流: n1 × 3 bits (打包成 int32 位流) L2 流: n2 × 5 bits (打包成 int32 位流) L3 流: n3 × 8 bits (原始 uint8 字節(jié))2.2 嵌套 Bitmap 定位三級(jí)元素的全局位置通過(guò)兩層 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解碼時(shí), 通過(guò) cumsum(bitmap) 計(jì)算每個(gè)元素在其級(jí)別流中的位置, 實(shí)現(xiàn)精確定位。2.3 有效位寬計(jì)算flag (bitmap): 1.445 bit/w data (L1L2L3): 0.555×3 0.404×5 0.041×8 4.013 bit/w ──────────────────────────────────────────────── 總計(jì): 5.46 bit/w → 2.93× vs bf16 (純權(quán)重) 含 scale 共享: 5.50 bit/w → 4.7× vs bf16 (含 embedding)2.4 Triton 融合內(nèi)核核心創(chuàng)新: 將以下操作融合進(jìn)單個(gè) Triton 內(nèi)核: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. 塊內(nèi) cumsum → 計(jì)算 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關(guān)鍵:tl.cumsum在 Triton 3.7 中原生支持, 允許內(nèi)核內(nèi)完成前綴掃描, 避免了 PyTorch 層面的多次 cumsum 調(diào)用和臨時(shí)數(shù)組分配。塊間前綴和 (block-level prefix sum) 在編碼時(shí)預(yù)計(jì)算, 存儲(chǔ)為 int32 數(shù)組 (每 1024 元素 1 個(gè)值 0.001 bit/w 開銷)。2.5 編碼流程 (離線, 一次性)bf16 權(quán)重 → INT8 量化 (per-tensor scale) → 按絕對(duì)值分級(jí) (L1/L2/L3) → 打包: L1(3b stream) L2(5b stream) L3(raw) B1(bitmap) B2(bitmap) → 預(yù)計(jì)算: 塊級(jí)前綴和 (b1_blk, b2_blk)3. 實(shí)驗(yàn)3.1 實(shí)驗(yàn)設(shè)置參數(shù)值模型MiniCPM5-1B (168 層, 679M Linear 權(quán)重)量化INT8 per-tensor symmetricGPURTX 4090 24GB框架PyTorch 2.13 Triton 3.7.1基線bf16 原始模型3.2 推理性能模式FwdGPU 顯存存儲(chǔ)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), 但存儲(chǔ)壓縮 4.7×、顯存節(jié)省 41%。3.3 無(wú)損驗(yàn)證INT8-X 對(duì) INT8 量化值實(shí)現(xiàn) 100% 精確還原:原始 INT8 → INT8-X 編碼 → Triton 解碼 → 還原 INT8 匹配率: 100.0% (679M 權(quán)重逐元素驗(yàn)證)端到端質(zhì)量等價(jià)于 INT8 量化 (bf16 → INT8 的量化誤差不在本文范圍內(nèi))。3.4 版本演進(jìn)版本技術(shù)FwdGPU關(guān)鍵改進(jìn)v7Python 逐 bit 解包676ms1.6GB基線v8PyTorch 向量化解包446ms1.8GB消除 Python 循環(huán)v9Triton PyTorch cumsum175ms1.6GBTriton bit 提取v10Triton 融合 (tl.cumsum)44ms1.3GB全融合單 kernelv10 相比 v7 加速15.4×, 核心來(lái)自tl.cumsum的內(nèi)核內(nèi)前綴掃描。3.5 方案對(duì)比方案bit/wFwdGPU無(wú)損?GPU 解碼bf161635ms2.2GB——BF16X (bf16無(wú)損)12.4105ms2.0GB? bf16快 (Triton)INT8 plain8.0———極快DG 4-bit (QAT)4.550ms1.2GB? (可恢復(fù))快 (Triton)INT8-X (3,5,8)5.544ms1.3GB? INT8快 (Triton融合)Huffman4.66442ms1.5GB? INT8慢 (串行)INT8-X 在速度 (44ms)、壓縮 (4.7×) 和無(wú)損性 (INT8) 之間取得最優(yōu) Pareto 平衡。4. 級(jí)別選擇分析4.1 窮舉搜索對(duì) 2~5 級(jí)嵌套 bitmap 的所有 bit 組合進(jìn)行窮舉搜索:方案bit/wvs bf16備注(3,4,5,6,8) 5級(jí)5.333.00×最優(yōu)但復(fù)雜(3,4,5,8) 4級(jí)5.402.96×(3,5,8) 3級(jí)5.502.93×Pareto 最優(yōu)(2,4,6,8) 4級(jí)5.702.81×2b 覆蓋太少4.2 第一級(jí)位寬的甜點(diǎn)分析第一級(jí) bit 數(shù) 覆蓋率 bitmap開銷 數(shù)據(jù)位寬 總計(jì) 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 ← 最優(yōu) 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 是甜點(diǎn): 覆蓋過(guò)半 (55.5%) 權(quán)重, 同時(shí)數(shù)據(jù)位寬足夠低 (3b), bitmap 二次查詢開銷適中 (44.5% 需查 B2)。5. 討論5.1 為什么不定長(zhǎng)更低位?定長(zhǎng)方案的天花板在 ~5.3 bit/w (5 級(jí))。低于此需變長(zhǎng)編碼 (Huffman 4.66 bit/w), 但 GPU 串行解碼代價(jià)高昂 (442ms vs 44ms)。INT8-X (3,5,8) 在 5.50 bit/w 處取得速度-壓縮最優(yōu)平衡。5.2 與 DFloat11 的關(guān)系DFloat11 [Zhang et al., 2025] 對(duì) bf16 指數(shù)做 Huffman 編碼, GPU 解碼需分層 LUT 塊內(nèi)串行掃描。INT8-X 改用定長(zhǎng)多級(jí) bitmap 定位, 避免了變長(zhǎng)解碼的串行依賴, 實(shí)現(xiàn)全并行 Triton 內(nèi)核。5.3 局限僅驗(yàn)證 MiniCPM5-1B, 需擴(kuò)展到 7B/13BL3 (8-bit raw) 未進(jìn)一步壓縮, 占 4.1% 但貢獻(xiàn) 0.33 bit/w塊級(jí)前綴和預(yù)計(jì)算增加編碼復(fù)雜度6. 結(jié)論我們提出 INT8-X (3,5,8): 一種基于多級(jí)定長(zhǎng) 嵌套 bitmap 的 INT8 無(wú)損壓縮方案, 配合 Triton 融合內(nèi)核實(shí)現(xiàn)接近零開銷的實(shí)時(shí)解碼。在 MiniCPM5-1B 上實(shí)現(xiàn) 4.7× 壓縮、1.3GB 顯存、44ms 推理, 且 INT8 權(quán)重 100% 無(wú)損還原。tl.cumsum內(nèi)核內(nèi)前綴掃描是關(guān)鍵加速技術(shù), 將解碼從 676ms 降到 44ms (15.4× 加速)。開源代碼: https://www.modelscope.cn/models/dfytensor/MiniCPM5-1B-DG-INT4參考文獻(xiàn)[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: 多級(jí)定長(zhǎng)無(wú)損 INT8 壓縮與 Triton 融合解碼
MiniCPM5-1B 驗(yàn)證: 4.7× 壓縮, 44ms 推理, 1.3GB 顯存, INT8 無(wú)損還原摘要INT8 量化將大語(yǔ)言模型 (LLM) 權(quán)重壓縮 2× (16→8 bit/w), 但 INT8 字節(jié)流本身仍存在顯著冗余 — 全局信息熵僅 4.66 bit/w?，F(xiàn)有無(wú)損壓縮方案 (Huffman, ANS) 雖可逼近熵極限, 但變長(zhǎng)編碼導(dǎo)致 GPU 上無(wú)法高效并行解碼。我們提出 INT8-X (3,5,8): 一種基于嵌套 bitmap 的三級(jí)定長(zhǎng)編碼方案, 通過(guò)將 INT8 權(quán)重按絕對(duì)值分為三級(jí) (3-bit / 5-bit / 8-bit), 在保持完全并行的前提下實(shí)現(xiàn) 5.50 bit/w 的有效位寬。關(guān)鍵創(chuàng)新是將 bitmap 前綴掃描 (cumsum)、位流提取和權(quán)重重建融合進(jìn)單個(gè) Triton 內(nèi)核, 利用tl.cumsum在內(nèi)核內(nèi)完成變長(zhǎng)流定位。在 MiniCPM5-1B (1B 參數(shù), 168 層) 上, INT8-X 實(shí)現(xiàn) 463MB 存儲(chǔ) (4.7× vs bf16)、1.3GB GPU 顯存 (省 41%)、44ms 推理 (僅 1.26× bf16 開銷), 且 INT8 權(quán)重 100% 無(wú)損還原。關(guān)鍵詞: 模型量化, 無(wú)損壓縮, Triton, bitmap 編碼, LLM 部署1. 引言INT8 量化是 LLM 部署的標(biāo)準(zhǔn)壓縮手段, 將 bf16 權(quán)重 (16 bit/w) 壓縮為 INT8 (8 bit/w), 實(shí)現(xiàn) 2× 存儲(chǔ)/顯存節(jié)省。然而, INT8 量化后的權(quán)重分布高度集中在零附近 (圖 1), 其 Shannon 熵僅 4.66 bit/w — 意味著 INT8 字節(jié)流本身仍有 42% 的冗余空間。進(jìn)一步無(wú)損壓縮 INT8 數(shù)據(jù)的現(xiàn)有方案存在根本性矛盾:變長(zhǎng)編碼 (Huffman/ANS): 可逼近熵極限 (4.66 bit/w), 但每個(gè)符號(hào)的碼長(zhǎng)不同, 解碼時(shí)元素間存在數(shù)據(jù)依賴, GPU 無(wú)法高效并行化。實(shí)測(cè)塊并行 Huffman 解碼需 442ms (12.6× bf16)。定長(zhǎng)塊編碼: GPU 友好, 但每塊需覆蓋塊內(nèi)最大值, 導(dǎo)致位寬浪費(fèi)。實(shí)測(cè)最優(yōu)塊方案僅達(dá) 6.5 bit/w。我們提出 INT8-X, 通過(guò)多級(jí)定長(zhǎng) 嵌套 bitmap架構(gòu)解決這一矛盾, 并通過(guò)Triton 內(nèi)核融合實(shí)現(xiàn)接近零開銷的實(shí)時(shí)解碼。2. 方法2.1 三級(jí)定長(zhǎng)編碼將 INT8 權(quán)重按絕對(duì)值分為三級(jí):Level 1 (3-bit): |v| ≤ 3 → 55.5% 權(quán)重 ← 主體 Level 2 (5-bit): |v| ≤ 15 → 40.4% 權(quán)重 Level 3 (8-bit): |v| 15 → 4.1% 權(quán)重 ← 稀疏離群點(diǎn)每級(jí)使用定長(zhǎng)編碼, 存儲(chǔ)為三個(gè)獨(dú)立的位打包流:L1 流: n1 × 3 bits (打包成 int32 位流) L2 流: n2 × 5 bits (打包成 int32 位流) L3 流: n3 × 8 bits (原始 uint8 字節(jié))2.2 嵌套 Bitmap 定位三級(jí)元素的全局位置通過(guò)兩層 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解碼時(shí), 通過(guò) cumsum(bitmap) 計(jì)算每個(gè)元素在其級(jí)別流中的位置, 實(shí)現(xiàn)精確定位。2.3 有效位寬計(jì)算flag (bitmap): 1.445 bit/w data (L1L2L3): 0.555×3 0.404×5 0.041×8 4.013 bit/w ──────────────────────────────────────────────── 總計(jì): 5.46 bit/w → 2.93× vs bf16 (純權(quán)重) 含 scale 共享: 5.50 bit/w → 4.7× vs bf16 (含 embedding)2.4 Triton 融合內(nèi)核核心創(chuàng)新: 將以下操作融合進(jìn)單個(gè) Triton 內(nèi)核: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. 塊內(nèi) cumsum → 計(jì)算 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關(guān)鍵:tl.cumsum在 Triton 3.7 中原生支持, 允許內(nèi)核內(nèi)完成前綴掃描, 避免了 PyTorch 層面的多次 cumsum 調(diào)用和臨時(shí)數(shù)組分配。塊間前綴和 (block-level prefix sum) 在編碼時(shí)預(yù)計(jì)算, 存儲(chǔ)為 int32 數(shù)組 (每 1024 元素 1 個(gè)值 0.001 bit/w 開銷)。2.5 編碼流程 (離線, 一次性)bf16 權(quán)重 → INT8 量化 (per-tensor scale) → 按絕對(duì)值分級(jí) (L1/L2/L3) → 打包: L1(3b stream) L2(5b stream) L3(raw) B1(bitmap) B2(bitmap) → 預(yù)計(jì)算: 塊級(jí)前綴和 (b1_blk, b2_blk)3. 實(shí)驗(yàn)3.1 實(shí)驗(yàn)設(shè)置參數(shù)值模型MiniCPM5-1B (168 層, 679M Linear 權(quán)重)量化INT8 per-tensor symmetricGPURTX 4090 24GB框架PyTorch 2.13 Triton 3.7.1基線bf16 原始模型3.2 推理性能模式FwdGPU 顯存存儲(chǔ)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), 但存儲(chǔ)壓縮 4.7×、顯存節(jié)省 41%。3.3 無(wú)損驗(yàn)證INT8-X 對(duì) INT8 量化值實(shí)現(xiàn) 100% 精確還原:原始 INT8 → INT8-X 編碼 → Triton 解碼 → 還原 INT8 匹配率: 100.0% (679M 權(quán)重逐元素驗(yàn)證)端到端質(zhì)量等價(jià)于 INT8 量化 (bf16 → INT8 的量化誤差不在本文范圍內(nèi))。3.4 版本演進(jìn)版本技術(shù)FwdGPU關(guān)鍵改進(jìn)v7Python 逐 bit 解包676ms1.6GB基線v8PyTorch 向量化解包446ms1.8GB消除 Python 循環(huán)v9Triton PyTorch cumsum175ms1.6GBTriton bit 提取v10Triton 融合 (tl.cumsum)44ms1.3GB全融合單 kernelv10 相比 v7 加速15.4×, 核心來(lái)自tl.cumsum的內(nèi)核內(nèi)前綴掃描。3.5 方案對(duì)比方案bit/wFwdGPU無(wú)損?GPU 解碼bf161635ms2.2GB——BF16X (bf16無(wú)損)12.4105ms2.0GB? bf16快 (Triton)INT8 plain8.0———極快DG 4-bit (QAT)4.550ms1.2GB? (可恢復(fù))快 (Triton)INT8-X (3,5,8)5.544ms1.3GB? INT8快 (Triton融合)Huffman4.66442ms1.5GB? INT8慢 (串行)INT8-X 在速度 (44ms)、壓縮 (4.7×) 和無(wú)損性 (INT8) 之間取得最優(yōu) Pareto 平衡。4. 級(jí)別選擇分析4.1 窮舉搜索對(duì) 2~5 級(jí)嵌套 bitmap 的所有 bit 組合進(jìn)行窮舉搜索:方案bit/wvs bf16備注(3,4,5,6,8) 5級(jí)5.333.00×最優(yōu)但復(fù)雜(3,4,5,8) 4級(jí)5.402.96×(3,5,8) 3級(jí)5.502.93×Pareto 最優(yōu)(2,4,6,8) 4級(jí)5.702.81×2b 覆蓋太少4.2 第一級(jí)位寬的甜點(diǎn)分析第一級(jí) bit 數(shù) 覆蓋率 bitmap開銷 數(shù)據(jù)位寬 總計(jì) 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 ← 最優(yōu) 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 是甜點(diǎn): 覆蓋過(guò)半 (55.5%) 權(quán)重, 同時(shí)數(shù)據(jù)位寬足夠低 (3b), bitmap 二次查詢開銷適中 (44.5% 需查 B2)。5. 討論5.1 為什么不定長(zhǎng)更低位?定長(zhǎng)方案的天花板在 ~5.3 bit/w (5 級(jí))。低于此需變長(zhǎng)編碼 (Huffman 4.66 bit/w), 但 GPU 串行解碼代價(jià)高昂 (442ms vs 44ms)。INT8-X (3,5,8) 在 5.50 bit/w 處取得速度-壓縮最優(yōu)平衡。5.2 與 DFloat11 的關(guān)系DFloat11 [Zhang et al., 2025] 對(duì) bf16 指數(shù)做 Huffman 編碼, GPU 解碼需分層 LUT 塊內(nèi)串行掃描。INT8-X 改用定長(zhǎng)多級(jí) bitmap 定位, 避免了變長(zhǎng)解碼的串行依賴, 實(shí)現(xiàn)全并行 Triton 內(nèi)核。5.3 局限僅驗(yàn)證 MiniCPM5-1B, 需擴(kuò)展到 7B/13BL3 (8-bit raw) 未進(jìn)一步壓縮, 占 4.1% 但貢獻(xiàn) 0.33 bit/w塊級(jí)前綴和預(yù)計(jì)算增加編碼復(fù)雜度6. 結(jié)論我們提出 INT8-X (3,5,8): 一種基于多級(jí)定長(zhǎng) 嵌套 bitmap 的 INT8 無(wú)損壓縮方案, 配合 Triton 融合內(nèi)核實(shí)現(xiàn)接近零開銷的實(shí)時(shí)解碼。在 MiniCPM5-1B 上實(shí)現(xiàn) 4.7× 壓縮、1.3GB 顯存、44ms 推理, 且 INT8 權(quán)重 100% 無(wú)損還原。tl.cumsum內(nèi)核內(nèi)前綴掃描是關(guān)鍵加速技術(shù), 將解碼從 676ms 降到 44ms (15.4× 加速)。開源代碼: https://www.modelscope.cn/models/dfytensor/MiniCPM5-1B-DG-INT4參考文獻(xiàn)[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.