LLM 推理的「动态剪枝」困局，终于有人用 Token 级宽度解决了

做 LLM 推理的人心里都有一本账：模型越大，每 token 越慢，但不可能让它每步都跑满全部参数——因为很多 token 其实「不值得」那么多计算量。于是剪枝（pruning）一直是条绕不开的路。

但这条路有个老毛病：快的方案太笨，聪明的方案跑不快。

静态结构化剪枝硬件友好，能真正压出吞吐，但它对每个输入一刀切——简单 token 和复杂 token 享受同等待遇，精度一高就扛不住。动态剪枝好一些，能根据输入自适应决定算多少，但过去基本只做到层级别（layer-level），粒度粗，而且在实际推理场景里很难转化成真实加速——理论省了算力，但硬件根本没跑满，甚至更慢。

最近 arXiv 上出现一篇论文叫 WIDE，来自 EIT-NLP 团队，瞄准的就是这个 gap。核心是：把动态剪枝的粒度干到 token 级，而且真的让它跑快了。

从层粒度到神经元块粒度

WIDE 的全称是 Token-level Dynamic Width Pruning，关键在「Width」。过去动态剪枝主要做 depth pruning——跳过某些层，或者让某些层不激活。WIDE 做的是宽度上的裁剪：每个 token 进来，动态选择要激活哪些 attention head 组和 FFN 通道组。一个 token 如果只是句尾的虚词，走小模型通路就够了；需要推理的核心词，就走大通路。每个 token 自己决定模型宽度。

这靠的是一个两阶段训练流程（two-stage training pipeline）来学习 token-wise 的稀疏执行模式。论文声称，在 50% 稀疏度下，WIDE 的精度保持显著优于已有的动态剪枝方法。

Kernel 不拖后腿才是真本事

动态剪枝一直被质疑的一个问题是：省了 FLOPs，但硬件不买账——不规则稀疏在 GPU 上跑不出理论加速。WIDE 的应对方式是做一个 pruning-kernel co-design，把加速拆成三段：mask 重排序、硬件无关的块级跳跃、硬件依赖的块内跳跃。

论文报告的数据是：在 50% 稀疏度下，prefill 阶段达到 1.98x 内核加速，decoding 阶段达到 4.95x 内核加速，端到端（end-to-end）分别为 1.68x 和 1.55x。

prefill 2x、decoding 接近 5x 的内核加速，放在实际部署场景里，同样一批 GPU 能撑住更多请求，或者把 TTFT（首 token 延迟）压下去一截。当然，端到端数字会受其他环节限制，1.5-1.7x 的整体加速更接近实际能感知到的提升。

代价和边界

这不是一个「开箱即用」的方案。WIDE 需要两阶段训练才能学会哪些 token 走哪条通路，没法直接把它塞进一个已经训好的模型然后一键加速。这个门槛决定了它更适合那些愿意在部署前做二次训练（fine-tune 或继续训练）的团队。

另外论文目前没有明确说在多大的模型上验证的、在哪种硬件上跑的 kernel benchmark——这些细节在 paper 正文里需要仔细看，arXiv 摘要和 HTML 版本会给出更多实验设置。代码已经开源在 GitHub 上（EIT-NLP/LLM-Pruning/tree/main/WIDE），有动手能力的可以直接拉下来在自己的场景里跑一把。

我的判断

动态剪枝一直是个「大家知道它好，但没人真用」的方向——学术论文里省了 50% FLOPs，部署时一测，延迟没降多少。WIDE 让我觉得有戏的地方，是它把 kernel 层面的 co-design 当成核心模块来推，没等到最后才来想加速的事。token 级宽度剪枝的思路也不极端，比层级别灵活，又比非结构化稀疏好加速。

但真正让它值得关注的，是这条思路未来如果能和 speculative decoding、量化、KV cache 压缩这些技术叠在一起，推理效率的优化空间可能比单独用任何一个都大得多。不是替换关系，是乘法关系。

代码已开源，值得拉下来试。别只看摘要里的加速比，自己跑一遍 prefill 的 wall time，比什么都实在。