稀疏计算 (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年 | 数据截止日期视具体引用而定