大模型推理的瓶颈一半在解码：batch 为 1 的自回归生成是访存受限的，每吐一个 token 都要把全部权重读一遍显存。Hessian 引导的免训练剪枝是老牌解法——把不重要的权重置零，要读的参数少了，解码自然变快。但西湖大学与蚂蚁 10 月 8 日提交 arXiv 的 SparseDecoding 论文（arXiv:2610.12327）指出一个被忽视的错位：剪枝时校准用的数据，和模型实际解码时吃的数据，根本不在一个分布上。
校准数据错在哪
传统做法（SparseGPT 一系）用预收集自然语料（如 C4）算 Hessian 评估权重重要性。问题是：解码阶段模型输入的是自己生成的 token，不是自然语料。论文实测发现，剪枝后模型的激活分布偏差在解码最初几步快速增长，所有层在第 12 步左右就达到平台期的 90%——剪枝时对齐的分布与真实解码时的分布脱节，长文本生成质量随之崩坏。
SparseDecoding 的解法直白：校准激活不再取自固定语料，而是让 dense 模型在任务提示上自回归生成，只收集 decode 步的激活、丢弃 prefill 部分。两种配置都用 1M 校准 token、同一个 SparseGPT 后端，唯一变量是校准数据来源。
内核是另一半答案
只改校准还不够。论文的第二个观察更扎心：现有能真正提速的稀疏 kernel（如 cuSPARSELt 的 2:4 Sparse Tensor Core 路径）主要优化稀疏矩阵-矩阵乘（SpMM），适合 prefill 和大 batch；而 batch-1 解码的核心运算是稀疏矩阵-向量乘（SpMV）。实测该路径 prefill 提速 1.31-1.46 倍，解码阶段却只有 dense 吞吐的 0.85-0.87 倍——比不剪枝还慢。
团队因此自己写了 N:M SpMV kernel：用 bitmask 索引（每 32 列打包成一个 32 位掩码词，50% 稀疏下每词恰好 16 个置位位）替代逐非零元的列索引，配合固定步长遍历。效果是 2:4 到 16:32 四种 N:M 模式吞吐几乎一致，A100 上端到端解码提速 1.34-1.48 倍（GPT-Fast 框架，context 512，50 次预热 + 50 次测量取中位）。
数字说话
质量侧的增益比速度侧更醒目。WritingBench 长文基准（1-10 分）上，2:4 稀疏下 C4 校准的 Qwen3-14B 只剩 1.85 分，SparseDecoding 校准拉回 4.18 分；Qwen3-32B 从 2.99 涨到 5.31。Llama 系增益温和（Llama-3.1-8B 从 1.34 到 1.52），Qwen 系是断崖式修复。代码生成 ClassEval 上，2:4 稀疏的 Qwen3-32B Pass@1 从 9.0% 涨到 24.0%，八个模型-稀疏组合全部领先 4 到 15 分；C4 校准在 Llama-3.1-8B 和 Qwen3-14B 上直接归零，SparseDecoding 都能救回非零分。
所以呢
这篇论文的价值不在 1.48 倍这个数字，而在它把「剪枝校准的分布偏移」这个盲区摆上了台面：社区调了几年的剪枝算法，校准数据却一直停留在静态语料，与部署时模型自回归生成的真实分布脱节。对要长文本输出又要压部署成本的团队（客服、写作助手、代码补全），「让模型先自己写一段，再拿这段去剪」是个几乎零成本的正确动作。而 SpMV 内核那半则提醒另一件事：半结构化稀疏的收益从来不是剪完就自动到账，Tensor Core 的 2:4 神话只覆盖 prefill——解码阶段的稀疏红利，得自己写 kernel 去拿。
参考：arXiv:2610.12327