稀疏計算 (Sparse Compute)
3 秒看懂
一句話定義：跳過資料中大量”零值/近零值”的計算，用更少算力完成相同任務。
核心公式：
理論加速比 ≈ 1 / (1 - 稀疏度)
稀疏度 90% → 理論 10× 加速關鍵認知：稀疏計算是”用資訊密度換計算密度”——不是所有零都值得算。
3 分鐘產業解釋
為什麼稀疏計算成為焦點？
大型模型時代的核心矛盾：模型規模指數增長 vs 算力線性增長。
稀疏計算提供了一條”不增加硬體就獲得加速”的路徑——
| 稀疏來源 | 機制 | 典型稀疏度範圍 |
|---|---|---|
| 權重稀疏 | 剪枝(Pruning)去除冗餘引數 | 50%-90%+ [依任務而定] |
| 啟用稀疏 | ReLU/GeLU等啟用函式天然產生零值 | 50%-80% [估算] |
| 注意力稀疏 | 稀疏注意力模式(區域性/塊狀) | 依序列長度而變 |
| 路由稀疏 | MoE只啟用部分專家 | 每token通常只啟用1-2個專家 |
產業痛點
傳統稠密計算：
┌─────────────────────────────────────┐
│ [0.5] [0.0] [0.0] [0.3] [0.0] [0.0] │ ← 每個元素都參與乘加
│ [0.0] [0.0] [0.8] [0.0] [0.0] [0.1] │
└─────────────────────────────────────┘
實際有用資料可能僅 20-30%
稀疏計算目標：
┌─────────────────────────────────────┐
│ [0.5] [ ] [ ] [0.3] [ ] [ ] │ ← 只算非零元素
│ [ ] [ ] [0.8] [ ] [ ] [0.1] │
└─────────────────────────────────────┘
理論可節省 70-80% 計算量但現實挑戰：稀疏資料的儲存/訪問模式不規則，硬體利用率往往遠低於理論值。
15 分鐘專家深入
稀疏計算的三個層次
第一層：模型壓縮視角（權重稀疏）
核心思想：訓練後/訓練中移除”不重要”的權重
典型流程：
預訓練模型 → 重要性評估 → 剪枝 → 微調 → 稀疏模型
↓
評估標準：
• 權重絕對值大小 (Magnitude Pruning)
• 梯度/敏感度分析
• 結構化評估 (整行/整列/整個通道)結構化 vs 非結構化稀疏：
| 型別 | 定義 | 硬體友好度 | 精度保持 |
|---|---|---|---|
| 非結構化 | 任意位置為零 | ★☆☆☆☆ | ★★★★★ |
| 結構化(通道/塊) | 整行/整列/塊為零 | ★★★★☆ | ★★★☆☆ |
| N:M結構化 | 每M個元素有N個為零 | ★★★★★ | ★★★★☆ |
關鍵進展：NVIDIA Ampere架構引入的 2:4 結構化稀疏 是工業界重要里程碑——每4個連續元素必須有恰好2個為零，硬體可直接利用此規則實現約2倍加速 [NVIDIA官方技術文件]。
第二層：執行時視角（啟用稀疏）
ReLU的”免費午餐”：
# ReLU啟用天然產生稀疏性
x = torch.randn(1024) # 假設標準正態分佈
activated = torch.relu(x)
sparsity = (activated == 0).float().mean()
# 典型值約 50% (理論: 正態分佈過零點恰好一半)啟用稀疏的利用挑戰：
- 啟用值是執行時動態產生的，無法預先確定稀疏模式
- 需要執行時動態跳過計算，帶來控制流開銷
- 與權重稀疏結合時，“雙稀疏”矩陣乘法的最佳化更復雜
第三層：演算法架構視角
稀疏注意力 (Sparse Attention)：
標準注意力複雜度: O(n²) (n為序列長度)
稀疏注意力目標: O(n·k) (k << n, 為區域性視窗大小)
稀疏模式示例：
┌───────────────────────────┐
│ ■ □ □ □ ■ □ □ □ ■ │ ← 區域性視窗 + 全域性token
│ □ ■ □ □ □ ■ □ □ □ │
│ □ □ ■ □ □ □ ■ □ □ │
│ □ □ □ ■ □ □ □ ■ □ │
│ ■ □ □ □ ■ □ □ □ ■ │
└───────────────────────────┘
(■ = 參與注意力計算, □ = 跳過)代表性工作方向包括：Longformer的區域性+全域性注意力、BigBird的隨機+視窗+全域性混合模式等 [原始論文]。
混合專家 (MoE) 中的稀疏路由：
輸入 token → 路由器(Router) → Top-K專家選擇 (通常K=1或2)
↓
只計算被選中專家的輸出
(其他專家完全不參與計算)MoE的稀疏性體現在：雖然總引數量很大，但每個token實際使用的啟用引數(共享層+被選中的專家引數)遠小於總引數 [具體比例視架構而定，未充分揭露]。
技術原理
核心機制：稀疏矩陣儲存與計算
1. 稀疏儲存格式
CSR (Compressed Sparse Row)：
原始矩陣: CSR 三陣列:
[0 0 3 0 ] values: [3, 5, 1, 4, 2]
[0 0 0 0 ] col_idx: [2, 1, 3, 0, 2]
[0 5 0 1 ] row_ptr: [0, 1, 1, 3, 5]
[4 0 2 0 ]
儲存節省: 僅儲存非零元素 + 索引
稀疏度 70% 時: 約節省 50-60% 儲存 [估算,視具體實現]2:4 結構化稀疏儲存 (NVIDIA方案)：
原始 (4元素): [A B C D]
2:4 稀疏後: [A 0 C 0] + indices=[0, 2]
(壓縮為2個值 + 2bit索引)
硬體實現:
• 稀疏張量核心直接識別 2:4 模式
• 索引編碼極簡 (每4元素僅需4bit)
• 理論矩陣乘法吞吐翻倍 [NVIDIA官方文件]2. 稀疏矩陣乘法 (SpMM)
稠密 GEMM: C = A × B (標準矩陣乘法)
複雜度: O(m·n·k)
稀疏 SpMM: C = A_sparse × B_dense
複雜度: O(nnz · n) (nnz = 非零元素數量)
關鍵挑戰:
┌─────────────────────────────────────────────────────┐
│ 稠密GEMM │ 稀疏SpMM │
│ ───────────────── │ ──────────────────────────── │
│ 規則記憶體訪問 │ 不規則記憶體訪問(依賴索引) │
│ 高硬體利用率 │ 記憶體頻寬常成為瓶頸 │
│ 成熟最佳化 │ 負載均衡困難 │
└─────────────────────────────────────────────────────┘3. 稀疏加速的實際瓶頸
Roofline分析視角：
效能
(ops/s)
↑
│ ┌─────────────────────── 計算上限
│ ╱
│ ╱
│ ╱ ← 稠密GEMM (在計算密集區)
│ ╱
│ ╱
│ ╱ ← 稀疏SpMM (常在記憶體密集區,受限於頻寬)
│ ╱
└───┴──────────────────────────────→ 算術強度 (ops/byte)關鍵洞察：稀疏計算省了乘加，但索引讀取/不規則訪存消耗頻寬。真正加速需要：
- 高稀疏度 (通常 > 80%)
- 結構化稀疏模式 (減少索引開銷)
- 硬體原生支援 (專用稀疏單元)
4. 軟體棧
應用層: PyTorch / TensorFlow / JAX
↓
稀疏庫: torch.sparse / DeepSparse / SparTA
↓
編譯器: XLA / TVM / BladeDISC (稀疏最佳化pass)
↓
硬體庫: cuSPARSE / CUTLASS (NVIDIA)
↓
硬體: Tensor Core (稀疏模式) / 專用稀疏加速器技術演進史
1960s-2000s 2015-2019 2020-2022 2023-至今
───────────────────────────────────────────────────────────────────────
科學計算 深度學習剪枝 硬體原生支援 LLM時代
稀疏線性代數 ───────── ───────── ─────────
(傳統數值計算) • Lottery Ticket • Ampere 2:4稀疏 • MoE成為主流
• Structured Prune • Google Sparsity • 萬億引數
• 稀疏正則化 Engine 模型稀疏推論
• SNIP/GRASP • DeepSparse引擎 • 稀疏注意力
• 推測解碼結合里程碑事件：
| 時間 | 事件 | 意義 |
|---|---|---|
| 2019 | ”Lottery Ticket Hypothesis” [Frankle & Carlin] | 證明子網路可達到原網路精度 |
| 2020 | NVIDIA Ampere釋出2:4稀疏Tensor Core | 首次硬體原生稀疏加速 |
| 2021-2022 | DeepSparse等推論引擎最佳化 | 稀疏模型部署進入實用 |
| 2023+ | MoE架構大規模應用 (如Mixtral等) | 稀疏啟用成為擴充套件定律新範式 |
技術路線對比
| 維度 | 剪枝後稀疏 | 啟用稀疏 | MoE路由稀疏 | 稀疏注意力 |
|---|---|---|---|---|
| 稀疏位置 | 權重 | 啟用值 | 專家選擇 | 注意力矩陣 |
| 確定性 | 訓練後固定 | 執行時動態 | 執行時動態 | 架構預定義 |
| 硬體需求 | 稀疏矩陣乘法支援 | 動態跳過能力 | 高頻寬+快速路由 | 定製注意力核 |
| 典型稀疏度 | 50-90% [估算] | 50-80% [估算] | 每token啟用1-2個專家 | 取決於視窗設計 |
| 精度影響 | 需微調恢復 | 天然存在，影響小 | 需平衡負載/訓練穩定性 | 需驗證長程依賴 |
| 代表硬體 | NVIDIA 2:4稀疏核心 | 通用GPU/CPU | GPU叢集+互聯 | GPU/定製硬體 |
| 成熟度 | ★★★★☆ | ★★★☆☆ | ★★★★☆ | ★★★☆☆ |
| 核心瓶頸 | 非結構化硬體利用低 | 動態索引開銷 | 通訊/負載均衡 | 區域性性假設限制 |
量化對比(粗略估算，視任務/實現差異大)：
實際加速比 (相對於稠密基線)
┌─────────────────────────────────────┐
2:4結構化 │████████████████████ ~1.5-2× │ [NVIDIA官方資料]
MoE路由 │█████████████████████████████ ~2-5× │ [視專家數/啟用比]
啟用稀疏 │█████████████ ~1.2-1.5× │ [估算,實現依賴]
非結構化 │████████ ~1.0-1.3× │ [GPU上常受限]
└─────────────────────────────────────┘
注: 以上為典型場景估算,實際效果高度依賴稀疏度/硬體/實現上下游
上游 (稀疏計算的輸入)
┌─────────────────────────────────────────────────────────────┐
│ 上游產業 │
├─────────────────┬─────────────────┬─────────────────────────┤
│ 模型架構 │ 訓練方法 │ 壓縮工具 │
│ ───────── │ ───────── │ ───────── │
│ • Transformer │ • 稀疏訓練 │ • 剪枝庫 │
│ • MoE設計 │ (RigL等) │ • 量化+稀疏聯合 │
│ • 稀疏注意力 │ • 後訓練剪枝 │ • 蒸餾輔助 │
└─────────────────┴─────────────────┴─────────────────────────┘中游 (稀疏計算執行)
┌─────────────────────────────────────────────────────────────┐
│ 中游產業 │
├─────────────────┬─────────────────┬─────────────────────────┤
│ 硬體層 │ 編譯器/庫 │ 推論引擎 │
│ ───────── │ ───────── │ ───────── │
│ • GPU稀疏核心 │ • 稀疏編譯最佳化 │ • DeepSparse │
│ • 專用加速器 │ • CUTLASS │ • TensorRT-LLM │
│ • 記憶體(HBM) │ • XLA sparse │ • vLLM (MoE支援) │
└─────────────────┴─────────────────┴─────────────────────────┘下游 (稀疏計算應用)
┌─────────────────────────────────────────────────────────────┐
│ 下游應用 │
├────────────────────────┬────────────────────────────────────┤
│ 雲端端推論 │ 邊緣部署 │
│ ───────── │ ───────── │
│ • 大型模型API服務 │ • 手機端模型 │
│ • 搜尋/推薦 │ • 車載/機器人 │
│ • 企業私有化部署 │ • IoT裝置 │
└────────────────────────┴────────────────────────────────────┘關鍵指標
| 指標 | 定義 | 重要性 | 說明 |
|---|---|---|---|
| 稀疏度 (Sparsity) | 零值元素佔比 | ★★★★★ | 稀疏度越高，潛在加速越大 |
| 實際加速比 | 實測吞吐/稠密基線 | ★★★★★ | 遠低於理論值時說明實現瓶頸 |
| 精度保持率 | 稀疏後精度/原精度 | ★★★★★ | 加速無意義若精度大幅下降 |
| 記憶體節省 | 壓縮後儲存/原儲存 | ★★★★☆ | 包含索引開銷的實際值 |
| 稀疏模式規則性 | 結構化程度 | ★★★★☆ | 決定硬體可利用程度 |
| 負載均衡度 | (MoE)各專家使用均勻度 | ★★★★☆ | 負載不均導致計算資源浪費 |
關鍵比率：
理想加速比 = 1 / (1 - 稀疏度)
實際加速比 = 理想加速比 × 硬體效率因子
硬體效率因子:
• 2:4結構化 + 原生硬體: ~0.8-1.0 [NVIDIA文件]
• 非結構化 + 通用GPU: ~0.1-0.3 [估算]
• 專用稀疏加速器: ~0.5-0.8 [視架構而定]供需與市場資料
需求側驅動
LLM引數規模增長趨勢 (示意):
┌─────────────────────────────────────────────────┐
│ 引數量 │
│ ↑ │
│ │ ┌──────┐ │
│ │ ┌────┤ MoE │ │
│ │ ┌────┤ │ 萬億+│ │
│ │ ┌────┤ │ └──────┘ │
│ │ ┌────┤ │ │
│ │ ┌────┤ │ │ │
│ │ │ │ │ │ │
│ └─────┴────┴────┴────┴───────────────────→ 時間
│ 2019 2020 2021 2022 2023 2024 │
└─────────────────────────────────────────────────┘
注: 精確數字未充分揭露,趨勢為定性描述核心需求場景：
- 大型模型推論成本最佳化（推論成本已是訓練成本的數倍 [行業共識]）
- 邊緣裝置部署（算力/記憶體受限）
- 長序列處理（注意力計算量與序列長度平方成正比）
供給側現狀
NVIDIA稀疏支援路線 [公開技術文件]：
- Ampere (A100): 首代2:4稀疏Tensor Core
- Hopper (H100): 增強稀疏支援
- 後續架構: 預計持續強化
第三方加速方案：
- DeepSparse (Neural Magic): CPU稀疏推論引擎
- 各AI晶片廠商: 部分在探索稀疏硬體支援
市場規模：
- 稀疏計算作為整體AI加速的一部分，獨立市場規模資料未充分揭露
- 間接參考：AI推論市場整體快速增長，稀疏最佳化為重要技術方向 [行業報告]
代表公司與資本對映
公司矩陣
| 型別 | 代表公司/產品 | 稀疏相關版面配置 | 上市狀態 |
|---|---|---|---|
| GPU巨頭 | NVIDIA | 硬體原生2:4稀疏，cuSPARSE庫 | NVDA |
| GPU巨頭 | AMD | ROCm稀疏支援(發展相對滯後) | AMD |
| CPU最佳化 | Intel | AMX等矩陣擴充套件，稀疏支援 | INTC |
| 稀疏推論 | Neural Magic | DeepSparse引擎，專注CPU稀疏推論 | 非上市 |
| AI晶片 | TPU上的稀疏最佳化 | GOOG | |
| AI晶片 | Graphcore | IPU對稀疏有原生設計考慮 | 非上市 |
| 雲端廠商 | AWS/Google/Azure | 提供稀疏最佳化的推論服務 | — |
資本對映邏輯
稀疏計算的資本暴露:
直接標的 (稀疏技術是核心賣點):
└─ Neural Magic (非上市) — 稀疏推論引擎
間接標的 (稀疏是產品特性之一):
├─ NVIDIA — 硬體稀疏加速是CUDA生態一部分
├─ 各AI晶片公司 — 稀疏支援作為差異化特性
└─ 雲端廠商 — 稀疏最佳化降低推論成本
上游受益:
├─ 模型壓縮/最佳化工具公司
└─ 高頻寬儲存 (HBM) 供應商 [稀疏可降低頻寬需求]投資邏輯
看多邏輯
- 成本驅動：推論成本已成為LLM商業化核心瓶頸，稀疏計算直接降低成本
- 效率提升：相同硬體預算下，稀疏可服務更多使用者/更高吞吐
- 技術趨勢：MoE等稀疏架構被主流模型採用（如Mixtral等），需求剛性化
- 硬體迭代：每代GPU都在強化稀疏支援，軟體生態逐步成熟
看空/風險因素
- 實際加速有限：非結構化稀疏在通用硬體上加速遠低於理論值
- 精度-速度權衡：高稀疏度往往伴隨精度下降，商業應用敏感
- 替代方案競爭：量化(INT8/INT4)、投機解碼等技術同樣有效
- 硬體鎖定：最佳效果依賴特定硬體支援，生態碎片化
核心判斷架構
稀疏計算投資判斷:
Q1: 目標場景稀疏度是否 > 70%?
└─ 否 → 稀疏收益有限，考慮其他最佳化
Q2: 是否有原生硬體支援?
└─ 是 → 加速比可達 1.5-2× (2:4結構化)
└─ 否 → 實際加速可能 < 1.3×
Q3: 精度要求是否嚴格?
└─ 是 → 稀疏度受限，收益降低
└─ 否 → 可激進使用高稀疏度
結論:
• 最佳場景: MoE推論 + GPU + 精度容忍度中等
• 次優場景: 2:4結構化 + 邊緣部署
• 收益有限: 非結構化 + CPU + 嚴格精度要求常見誤讀糾偏
❌ 誤讀一：「稀疏計算能帶來數倍加速」
現實：
- 理論加速比 vs 實際加速比差距巨大
- 2:4結構化稀疏在NVIDIA硬體上約1.5-2× [官方資料]
- 非結構化稀疏在GPU上通常僅1.0-1.3× [估算]
- 瓶頸在於記憶體頻寬/索引開銷，而非計算量減少
正確理解：稀疏計算是有條件的加速，高稀疏度+結構化+硬體原生支援三者缺一不可。
❌ 誤讀二：「MoE的稀疏啟用只是把引數量變小了」
現實：
- MoE的總引數量很大（所有專家引數之和）
- 但每個token的啟用引數僅為：共享層引數 + Top-K個專家引數
- 這是一種”計算稀疏”而非”引數儲存稀疏”
- 總引數量決定了模型容量/儲存需求，啟用引數量決定了計算量
正確理解：MoE稀疏計算 = 大容量（總參）+ 低計算量（啟用參）+ 高通訊要求（路由/分發）。
❌ 誤讀三：「剪枝到90%稀疏度精度不會下降」
現實：
- 非結構化剪枝90%後，精度下降幅度取決於任務/模型/剪枝方法
- “Lottery Ticket”假設表明存在”中獎彩票”子網路，但找到它需要大量搜尋
- 實際中高稀疏度常需：逐步剪枝 + 重訓練 + 蒸餾等配合
- 聲稱”無損90%稀疏”的結果需審慎對待 [評估基準/任務範圍可能有限]
正確理解：稀疏度-精度權衡是核心trade-off，不存在免費午餐。
❌ 誤讀四：「2:4稀疏的2倍加速適用於所有矩陣乘法」
現實：
- 2:4稀疏加速僅適用於支援此模式的Tensor Core操作
- 要求權重矩陣滿足2:4模式（每4個元素恰好2個零）
- 不滿足此模式的層/操作無法獲得加速
- 實際模型中各層稀疏度不均勻，整體加速低於2×
正確理解：2:4稀疏是”有條件的倍增”，需要模型結構與硬體模式匹配。
學習路徑
入門階段 (1-2周)
Level 1: 概念理解
├─ 閱讀: 稀疏矩陣基礎 (線性代數教材)
├─ 閱讀: NVIDIA "Structured Sparsity" 技術部落格
└─ 實驗: torch.sparse 基本操作進階階段 (2-4周)
Level 2: 深入機制
├─ 論文: "The State of Sparsity in DNNs" (Gale et al.)
├─ 論文: "To Prune or Not to Prune" (Frankle & Carlin)
├─ 程式碼: 實現簡單剪枝實驗
└─ 工具: 嘗試 DeepSparse / torch.ao.pruning專家階段 (1-3月)
Level 3: 系統視角
├─ 論文: "Optimizing Sparse Matrix-Matrix Multiplication" (CUTLASS)
├─ 實踐: 稀疏模型部署/效能分析
├─ 擴充套件: MoE架構原理 (GShard/Switch Transformer)
└─ 前沿: 關注新硬體稀疏支援/新稀疏訓練方法推薦資源：
- NVIDIA Developer Blog: “Accelerating Inference with Sparsity”
- Neural Magic 稀疏計算技術部落格
- Hugging Face 模型壓縮/稀疏相關文件
- 會議: MLSys, OSDI (系統視角) / NeurIPS, ICML (演算法視角)
一句話總結
稀疏計算是AI大型模型時代的”減法哲學”——通過跳過資訊密度低的計算來逼近更優的算力效率曲線，但其價值實現取決於稀疏度水平、結構化程度與硬體原生支援三者的共振。
延伸閱讀與來源
核心論文
- Frankle & Carlin (2019): “The Lottery Ticket Hypothesis”
- Gale et al. (2019): “The State of Sparsity in DNNs”
- NVIDIA: “Ampere Architecture In-Depth” (2:4稀疏技術細節)
技術文件
- NVIDIA cuSPARSE Documentation
- PyTorch Sparse Tensor Tutorial
- Neural Magic DeepSparse Documentation
行業報告
- 各AI晶片/推論市場分析報告 [未充分揭露具體來源]
- 各大雲端廠商AI推論服務技術部落格
資料來源說明
- 本文中具體效能資料標註來源：[NVIDIA官方文件] / [行業估算] / [未充分揭露]
- 無明確來源的數字為定性估算，不代表精確性能承諾
- 建議讀者參考具體硬體/軟體版本的技術白皮書
最後更新: 2024年 | 資料截止日期視具體引用而定