模型压缩为什么要考虑硬件支持？
简化版
模型压缩减少参数或理论 FLOPs，不等于真实加速。硬件必须支持对应位宽、稀疏模式、矩阵形状和 Kernel；否则会发生反量化、格式转换或回退 Dense，延迟甚至更高。
选方案要从目标设备反推：确认 Tensor Core/CPU 指令、内存带宽、编译器与推理引擎支持，再比较质量、TTFT/TPOT、吞吐、峰值内存、功耗和单位成本。
详细版
INT4 Weight-only 常降低 Decode 权重带宽，但 Activation 仍用 FP16；W8A8 需要硬件高效 INT8 GEMM；非结构化稀疏只有专用稀疏 Kernel 才能兑现。
| 压缩 | 依赖 | 常见陷阱 |
|---|---|---|
| INT4 权重 | 高效解包/GEMM | 反量化开销 |
| FP8 | 新架构 Tensor Core | 老卡回退 |
| N:M 稀疏 | 指定硬件模式 | 任意零值不加速 |
| 剪枝小矩阵 | 合适形状 | 对齐后仍占满 |
因此基准必须在目标硬件和真实长度/Batch 上执行，不以文件大小或理论 TOPS 代替端到端结果。
完整版教学
1. 压缩收益分哪几层
文件更小、显存更少、带宽更低、计算更快是不同收益。某方案可能只改善存储与加载，不改善 Token 延迟。
先写清目标，再选择量化、剪枝或蒸馏。
2. 位宽支持为何关键
硬件对 FP16、BF16、FP8、INT8、INT4 的吞吐不同；部分位宽只支持特定矩阵路径。
speedup depends on supported kernel
not merely original_bits / compressed_bits不支持时可能先解压到高精度再计算。
3. Weight-only 与 W8A8
Weight-only 减少权重读带宽，适合 Decode；W8A8 同时量化激活，可使用整数矩阵单元，但校准与质量风险更大。
Prefill 计算密集，W8A8 可能更有优势；Decode 需结合 Batch 和带宽实测。
4. 对齐与形状有什么影响
Tensor Core 常要求维度按 8、16 或更大粒度对齐。剪到奇怪宽度可能触发 Padding 或低效 Kernel。
结构设计时选择硬件友好 Rank、Head 和块大小，而不是只追求最少参数。
5. 稀疏为何不一定快
任意非结构化稀疏需要索引和不规则访存。硬件通常只加速固定 N:M 或块稀疏模式。
| 稀疏类型 | 通用加速可能性 | 原因 |
|---|---|---|
| 任意稀疏 | 低 | 索引与不规则访问 |
| N:M | 中/高 | 专用硬件模式 |
| 块稀疏 | 中 | 规则块可向量化 |
| 结构化删层/头 | 高 | 可直接跳过计算 |
6. 内存带宽与算力怎么判断
用 Roofline 看算术强度。Decode 常受权重/KV 带宽限制，压缩字节有益；Prefill 大 Batch 更可能受算力限制。
arithmetic_intensity = FLOPs / bytes_moved同一压缩在两个阶段收益可能不同。
7. Kernel 融合的作用
量化若每层单独反量化并写回显存，会抵消节省。融合反量化与 GEMM，让数据留在寄存器或片上存储。
检查推理引擎是否对目标模型结构提供融合 Kernel，不能只看论文支持。
8. 编译器和运行时兼容
模型导出格式、算子集、动态 Shape、KV 布局和驱动版本都会影响是否命中优化路径。
部署前建立兼容矩阵；版本升级重新基准，避免 Silent Fallback 到慢速实现。
生产监控记录实际算子实现、数据类型和引擎版本；若编译器分段导致频繁 Host/Device 切换，即使核心 GEMM 很快，端到端仍可能退化。
9. CPU 与边缘设备怎么选
CPU 更依赖 AVX/VNNI/AMX 等指令、缓存容量和线程调度；移动 NPU 可能只支持特定算子与量化粒度。
边缘场景还要测功耗、内存和模型加载，云 GPU 结论不能直接移植。
CPU 量化还要控制 NUMA、线程数和内存带宽；NPU 则需确认不支持算子是否回退 CPU，因为跨设备拷贝可能成为主要延迟。
10. 多卡通信会怎样
压缩权重不一定减少张量并行通信，激活或 All-Reduce 仍可能保持高精度。计算加快后，通信占比反而上升。
端到端 Profile 要分别看计算、通信和同步，必要时调整并行度。
11. 如何设计 Benchmark
固定模型、硬件、引擎和质量门槛，覆盖真实输入/输出长度、Batch 与并发，预热后报告分位数。
记录 TTFT、TPOT、Tokens/s、峰值显存、功耗、加载时间和单位成功成本，并与未压缩基线比较。
每个配置重复多轮并报告 P50/P95，区分冷启动和稳态；基准期间锁定频率、并发和 NUMA，避免环境噪声掩盖小幅收益。
12. 质量与性能如何共同决策
画质量—延迟—成本 Pareto 前沿。更快但关键任务退化的点不可用；质量相同但运行时不支持的压缩也无工程价值。
上线灰度按硬件型号分桶，保留高精度版本回滚。
压缩方案只有在目标硬件、目标运行时和目标流量上兑现收益，才算真正完成。
13. 常见误区与追问
- 误区：位宽减半就能加速两倍。 还取决于 Kernel、形状和反量化。
- 误区：零值越多越快。 硬件可能不能利用不规则稀疏。
- 误区：显存下降就代表延迟下降。 可能只改善容量。
- 误区：单卡结果可直接推到多卡。 通信占比可能改变。
- 误区：论文硬件结果适用于所有设备。 架构和运行时支持不同。
- 追问：先看什么？ 先确认目标硬件的原生数据类型与推理引擎 Kernel。
- 追问：如何防止慢速回退？ 记录实际执行 Kernel，并做版本化性能回归。
14. 加强记忆
- 先定收益层：存储、显存、带宽、计算还是功耗。
- 再查硬件：位宽、稀疏、指令与对齐。
- 再查运行时：导出、Kernel、动态 Shape 和版本。
- 再分阶段：Prefill 看算力，Decode 常看带宽。
- 再看系统：通信、加载与缓存。
- 再做实测：真实长度、Batch 和目标设备。
- 最后守质量：用 Pareto 和灰度决定上线。