模型压缩效果评估方法

可视化演示

动态演示模型压缩效果评估方法的核心机制，通过基础/核心/应用/扩展四种模式展示关键概念与交互流程。

评估维度概览

搬家验收从来不是只看「箱子少了几个」就完事。一个挑剔的房主会同时盯四件事：箱子数量、搬运时长、家具完好度、搬家报价。模型压缩的评估也一样，业界把这四件事固定成「四本账」：压缩率（省下的体积）、加速比（变快的倍数）、精度损失（智商的回落）、资源占用（运行时内存、显存和耗电）。把四本账摆整齐，评估就有了骨架。

有了骨架，接下来是流程。评估一般分五步：定目标（比如「手机端 100ms 内出结果」）→ 建基线（量原始模型的延迟和精度）→ 选指标（分类任务看准确率，生成任务看困惑度）→ 做测量（统一硬件环境）→ 出报告。评估原则有两条最要紧：控制变量（除了压缩方法不同，其余一切相同）和目标驱动（先定业务容忍度，再下结论）。工具方面，端侧常用 ONNX Runtime 和 MNN 的 benchmark，服务端常用 TensorRT 的计时工具。

一个压缩方案能不能用，最终要过一个「合格判定」：压缩率、加速比、精度损失三个条件必须同时满足，缺一个都不行。

评估的第一课，就是先立好验收标准再让搬家公司进场——否则你根本不知道什么叫「搬得好」。

压缩率计算

搬家时你会数箱子：20 箱变 5 箱，少装了 15 箱，省了 75% 的空间。这就是压缩率的第一层含义，按「省掉多少」来算。在模型语境里，箱子换成「存储体积」（MB）或「参数量」（百万参数），评估时先量原始模型，再量压缩后的模型。

这里藏着一个最容易踩的坑：压缩率的两种口径。「压缩后比例」是拿新体积除以原体积，回答「还剩多少」；「压缩率」是拿 1 减去这个比例，回答「省了多少」。200MB 压到 50MB，前者说还剩 25%，后者说省了 75%，一字之差，含义截然相反。写报告、做对比，口径必须统一并注明。

量化压缩还有一个理论算法：参数位宽从 32bit 压到 8bit，单个参数存储降为原来的四分之一，理论压缩率 75%。但这是理论值，实际文件还包含算子、常量表等附加开销，所以「实测体积」永远比「理论位宽」更可靠。

所以下次汇报「省箱子」的成果，先问自己一句：我报的是「还剩 25%」还是「省了 75%」？口径不同，领导的判断可能完全相反。

推理加速比

箱子少了，搬得也得快。搬家公司报价单上的时长对比很简单：原来 8 小时，现在 2 小时，就是快 4 倍——这就是加速比。模型推理加速比同理：用原始模型的单次推理延迟除以压缩后的延迟，得到「快了几倍」。

测量延迟不能上来就跑。第一，要先 warmup 预热，让算子和缓存就绪；第二，要跑几十次取中位数或平均值，排除系统波动；第三，要排除文件 IO 等无关耗时。延迟的单位是毫秒，一次推理的耗时通常记作 p50（中位数）和 p99（最慢的 1% 样本），后者更能暴露卡顿问题。

端侧和服务端看重的指标不同。端侧是单用户交互，用户感知的是「点一下到出结果」的等待时间，所以盯单次延迟；服务端常面对批量请求，还要看吞吐量（每秒处理多少请求）。测量环境必须写明：芯片型号、CPU/GPU 线程数、量化算子是否走硬件加速。同一模型在旗舰机和低端机上，加速比可以差出好几倍。

加速比永远绑定「在什么机器上测的」。脱离硬件谈加速比，就像脱离路况谈车速——实验室的 4 倍，到真机上可能只剩 1.2 倍。

精度损失评估

家具完好度是搬家验收的底线：柜子有划痕可以忍，电视屏幕裂了必须退货。模型压缩后智商也会「回落」，评估要回答两个问题：回了多少？能不能接受？测量方法是把压缩前后的模型放到同一套基准数据集上跑任务：图像分类用 ImageNet 的 Top-1 准确率，文本分类和问答用 GLUE、SQuAD 的准确率与 F1，生成任务看困惑度。

拿原始模型的得分减去压缩后模型的得分，就得到精度损失。它有两种报告口径：绝对损失的「百分点」（92% 变 90%，掉了 2 个百分点）之外，还有相对损失，要再除以原始准确率。测量时要用验证集而非训练集，并固定随机种子保证可复现。损失预算按业务定：通常分类任务允许 1%~2% 的绝对下降，但医疗、金融等关键场景会卡得更死。

精度损失就像搬家损坏清单——追求的不是零损坏，而是确保每项损伤都在可接受的预算内，超预算就退货。

综合对比方法

单本账看清了，还要合起来算总账。搬家公司 A 省箱子最多但砸了电视，B 毫发无损但慢悠悠，到底选谁？答案是把所有指标放在一起综合打分，再画一条「取舍曲线」。综合打分的第一步是归一化：压缩率、加速比、精度损失量纲不同——百分比不能直接和倍数相加，必须先把每个指标压到 0 到 1 之间。

归一化最常用的是 min-max 方法：用当前值减组内最小值，再除以组内最大值减最小值。之后按业务偏好加权：端侧产品更看重速度，就把加速比的权重调大；医疗场景更怕出错，就把精度损失的惩罚调高。加权评分 = 权重之和为 1 的线性组合，损失项用减号。

另一把武器是帕累托前沿。把所有方案画在「精度-速度」坐标图上，找出那些「没有任何一个方案能在所有指标上比它更好」的点，连成一条曲线。曲线上的方案各有取舍，都是候选；曲线下方的方案因为存在全面碾压它的对手，可以直接淘汰。

综合打分不是在算一个「数」，而是在逼你把业务优先级讲明白——到底要箱子还是保电视，先想清楚，权重自然就有了。

基准测试体系

各家搬家公司都喊自己又快又稳，怎么比才公平？搞一次「搬家公司挑战赛」：所有公司搬同一套房、同一批家具、同一条路线，用同一把秒表计时。模型压缩的基准测试，就是把这套统一规则固定下来：大家在同一个环境、同一批数据、同一套指标下对比，出来的成绩单才可信。

服务端推理的主流基准是 MLPerf Inference，移动端可以看 MLMark、AI-Benchmark，语言模型压缩还会用业务自建评测集兜底。评测环境要写清硬件、框架版本（TensorRT 8.0 和 8.4 的结果都可能不同）、输入规模和批大小。公平对比的三条铁律：统一硬件和框架、统一输入规模和批大小、多次运行取中位数并报告方差。

结果复现同样重要：随机种子、预热轮数、量化校准数据都要写明。为了横向对比多个方案，业界常把各指标做 min-max 归一化后求平均，得到「基准得分」。归一化就是把不同尺子上的刻度换算到同一把尺子上。

基准测试的核心就一句话：比赛条件一致。否则成绩单再漂亮，也只是自说自话，换台手机就翻车。

评估报告撰写

搬家结束要交验收单：住了几箱、几小时完工、坏了几件、花了多少钱，清清楚楚写明白。给老板看的压缩评估报告，就是模型的「验收单」。报告结构遵循金字塔原则：结论先行——推荐哪个方案、为什么；再给证据——指标对比表和图表；最后附细节——环境配置和复现步骤。

报告必有的三要素：评估环境（芯片型号、框架版本、量化工具）、指标口径（压缩率是「剩余比例」还是「节省比例」、精度是相对还是绝对损失）、对比基线（和谁比，基线模型是什么、原始指标多少）。缺了任何一样，结论都无法被复核。

可视化是报告的脸面：柱状图比体积和延迟最直观，折线图画精度-速度取舍曲线，散点图画帕累托前沿。最后给出选型建议和风险提示，比如「INT8 量化在低端机上精度下降 2.3%，超预算，不建议部署」。一个方案能不能写进结论，要落回业务预算检验：

写报告的最高境界是「让决策者五分钟内做决定」——数据讲实话，风险讲清楚，建议给明白。报告是评估的最后一公里，写不好，前面的努力都白费。

AI 应用场景

Python 演示

def calc_compression_ratio(orig_size, new_size):    # 体积减少率口径: 省掉了多少体积    return 1 - new_size / orig_size def calc_speedup(orig_latency, new_latency):    # 加速比: 快了多少倍    return orig_latency / new_latency def calc_relative_acc_loss(orig_acc, new_acc):    # 相对精度损失: 在原有水平上退步的比例    return (orig_acc - new_acc) / orig_acc def evaluate(method_name, orig_size, new_size, orig_latency, new_latency,             orig_acc, new_acc, weights=(0.4, 0.3, 0.3)):    cr = calc_compression_ratio(orig_size, new_size)    sp = calc_speedup(orig_latency, new_latency)    loss = calc_relative_acc_loss(orig_acc, new_acc)    # 加速比归一化, 封顶 4 倍视为满分    sp_norm = min(sp / 4.0, 1.0)    score = weights[0] * cr + weights[1] * sp_norm - weights[2] * loss    return {        'method': method_name,        'compression_ratio': round(cr, 4),        'speedup': round(sp, 2),        'relative_acc_loss': round(loss, 4),        'composite_score': round(score, 4)    } def compare_methods(methods):    results = []    for name, kw in methods.items():        results.append(evaluate(name, **kw))    return sorted(results, key=lambda x: x['composite_score'], reverse=True) if __name__ == '__main__':    methods = {        '结构化剪枝': dict(orig_size=500, new_size=250, orig_latency=120,                        new_latency=80, orig_acc=91.0, new_acc=90.2),        'INT8量化': dict(orig_size=500, new_size=125, orig_latency=120,                      new_latency=45, orig_acc=91.0, new_acc=90.6),        '知识蒸馏': dict(orig_size=500, new_size=180, orig_latency=120,                      new_latency=65, orig_acc=91.0, new_acc=89.8),    }    for item in compare_methods(methods):        print(f"{item['method']}: 压缩率={item['compression_ratio']:.1%}, "              f"加速比={item['speedup']:.2f}x, 相对精度损失={item['relative_acc_loss']:.2%}, "              f"综合得分={item['composite_score']:.3f}")

1. return 1 - new_size / orig_size用「1 减剩余占比」算出省掉的比例，对应正文的压缩率口径。
2. return orig_latency / new_latency两个延迟相除，得到快了几倍，小于 1 说明反而变慢。
3. return (orig_acc - new_acc) / orig_acc先算掉了几点，再除以原始值，得到相对损失比例。
4. sp_norm = min(sp / 4.0, 1.0)把加速比压到 0~1，超过 4 倍算满分，防止单个指标霸榜。
5. score = weights[0] * cr + weights[1] * sp_norm - weights[2] * loss加权求和，损失项用减法，对应综合评分公式。
6. return sorted(results, key=lambda x: x['composite_score'], reverse=True)按综合得分降序排序，第一名就是综合最优方案。

常见误区

面试题