模型变小，速度为什么没跟上
模型压缩项目很容易出现一种误判：权重文件已经缩小，端侧响应却没有明显变快。
原因并不复杂。压缩率主要反映权重占用，首字延迟、逐 Token 延迟、峰值内存和持续功耗，还会受到内存访问、算子实现与运行时调度影响。INT4、INT8 可以降低权重存储和数据搬运压力，但如果芯片缺少匹配的低精度算子，或者运行时发生回退，纸面收益很难完整兑现。
2024 年 1 月，《智能系统学报》刊发的《神经网络压缩联合优化方法的研究综述》已经指出，模型层数和参数量增加会推高计算复杂度与运行功耗。模型长期依赖服务器或数据中心，还会带来网络延迟、隐私安全和硬件成本问题。这也是端侧压缩一直受到关注的直接原因。
2026 年 6 月 19 日，openEuler 社区页面发布的压缩技术介绍，仍把量化、剪枝和蒸馏并列为三条主要路线。工程上更实用的做法，是先分清它们各自改了什么。
三种办法，动的不是同一层
| 方法 | 主要动作 | 更直接的收益 | 部署前要核对的问题 |
|---|---|---|---|
| 量化 | 把权重或激活转换为 INT8、INT4 等低精度格式 | 降低存储与数据搬运压力 | 芯片、算子和后端是否真正支持，精度是否回落 |
| 知识蒸馏 | 用教师模型的输出或中间表征训练学生模型 | 得到独立、规则的小模型 | 学生模型容量、训练数据和蒸馏目标是否合适 |
| 剪枝 | 删除单个权重或完整网络结构 | 减少参数，并可能降低计算量 | 稀疏结构能否被运行时和硬件利用 |
“压到原体积的 1/10”听起来直观，却常把几件事混在一起：参数是否真的删除，权重是否同时量化，稀疏文件加载后是否还原成原矩阵，KV Cache 和运行时工作区有没有计入。缺少这些口径，单个压缩数字很难说明端侧表现。
结构化剪枝真正改了什么
非结构化剪枝通常删除零散权重，最终得到一张带有大量零值的矩阵。它有利于降低有效参数量，但数据分布不规则。通用 CPU、GPU 或 NPU 如果没有匹配的稀疏内核，仍可能按照原矩阵尺寸执行计算。
结构化剪枝处理的是完整单元，例如通道、注意力头、前馈网络维度或层块。模型图完成重建后，矩阵尺寸会真实缩小，剩余部分仍保持规则、连续的形状。对只擅长密集矩阵计算的硬件来说，这类模型通常更容易部署和优化。
这里有一个容易被忽略的前提：给原模型乘上掩码，不代表结构已经缩小。剪枝之后还要重建网络、导出新图，并检查后端实际调用的算子。只看到权重中出现大量零值，无法证明推理已经加速。
剪哪些结构，同样需要依据。重要性评分可以来自权重幅值、梯度或 Hessian 近似，但没有一种指标能脱离任务直接给出答案。删除结构之后，还要通过微调或蒸馏恢复能力，并在目标任务上重新评测。
动态稀疏激活也不宜和结构化剪枝混为一谈。前者根据输入决定运行时激活哪些模块，依赖调度和专用算子；后者直接修改模型结构。两者都涉及稀疏，却对应不同的部署条件。
蒸馏仍然有它的位置
知识蒸馏的作用，是把教师模型的输出分布或中间表征传给更小的学生模型。学生模型可以保持规则的密集结构，因此在通用硬件上往往更容易执行。
它的边界也很明确。学生模型的容量确定后，蒸馏只能在这个容量内重新分配能力，不能保证教师模型的所有任务表现都被保留。训练数据覆盖不足、蒸馏目标不合适，也可能让学生模型在某些能力上出现明显回落。
蒸馏与结构化剪枝并不冲突。常见的组合方式包括：
- 已经确定目标模型尺寸时，先训练较小的学生模型，再做量化；
- 希望复用现有检查点时，先做结构化剪枝，再通过蒸馏或微调恢复能力；
- 存储、带宽和计算量都受限时，把蒸馏、剪枝和量化放进同一条压缩流程，但每一步都保留独立对照实验。
“先蒸馏、再剪枝、最后量化”可以作为一条工作流，却不适合写成固定答案。真正决定顺序的，是现有模型、训练预算、目标硬件和精度要求。
端侧验收不能只看模型文件
比如评估 Qwen2.5-3B-Instruct 是否适合 iPhone 13 或 Redmi Note 12 Pro+，模型文件能否装入只是第一关。至少还要记录以下指标：
- 权重、KV Cache 与运行时工作区共同产生的峰值内存；
- 首字延迟、逐 Token 延迟和持续运行后的速度；
- 设备温度、功耗以及降频后的表现；
- 压缩前后的任务质量；
- 是否存在算子回退、数据格式转换或重复拷贝。
如果目标是数学推理和常识问答，可以继续用 GSM8K、MMLU 做前后对照，但业务数据也要单独测试。公开评测集上的平均分，无法代替真实输入分布。
面对骁龙 8 Gen 4、天玑 9400 等端侧平台，也要查看具体 SDK、算子列表和运行日志。芯片带有 NPU，并不能直接证明它支持任意稀疏结构。规则通道剪枝、非结构化稀疏和动态激活，所需的后端能力并不相同。
工具链名字不能替代实测
Hugging Face Transformers 可以承担训练、模型修改和导出，vLLM 更偏向云端推理服务，MindSpore Lite、TFLite 则常用于端侧运行。把这些工具写进方案，并不意味着结构化剪枝已经自动生效。
项目文档如果只写“新版后端原生支持通道级剪枝”，信息仍然不够。还要说明版本、模型格式、目标设备、实际算子以及是否发生回退。结构化剪枝后的模型，有时会以更小的密集模型运行；有时则需要自定义算子。两种路径的性能差别，只能通过部署日志和实测确认。
先找瓶颈，再决定压缩顺序
权重装不下或加载过慢，可以先看量化；需要一个尺寸明确、结构规则的小模型，蒸馏更合适；现有模型存在可删除的通道或层块，且硬件偏好规则矩阵，结构化剪枝值得优先验证。
面对 7B 级模型，还应先计算权重、KV Cache 和运行时缓存是否超过设备承载范围。如果基础内存账没有算清，后续讨论压缩比例和评测分数都很难落到实际产品上。
从 2026 年 6 月 19 日那篇 openEuler 社区材料的编排也能看出，量化、剪枝和蒸馏仍被并列讨论。结构化剪枝补上了“可执行形状”这一层，量化和蒸馏则各自处理位宽与模型容量。模型文件只是第一张成绩单；目标设备上的质量、延迟、内存和功耗，才决定压缩方案是否成立。