小张去健身房报到,第一件事就是站上体重秤。教练却提醒他:“体重只是最表层的变化,真正要看的还有体脂率、肌肉量、深蹲成绩、跑步配速和恢复心率。”三个月后,小张体重没掉多少,但穿衣显瘦、运动不喘,教练这才竖起大拇指:“训练效果,要看综合评估。” 模型压缩也是这样。把一个大模型从 128MB 压到 32MB,就像体重秤上数字跳水的瞬间快感。但“压缩效果评估”这门功课,要求的是一份完整的“体检报告”:精度有没有掉?推理够不够快?耗电大不大?放到手机、摄像头这些边缘设备上能不能跑起来?多个压缩方法叠加之后是 1+1>2 还是互相拆台?这些维度一个都不能少。 本文用“健身房减脂体检”作主线,带你建立模型压缩效果评估的完整认知框架:从核心压缩比、精度保持率、推理延迟、能耗能效、设备适配,到组合评测方法论和标准化度量体系。
对 AI 从业者来说,掌握压缩效果评估就是掌握模型的“验收标准”——它能帮你判断一次压缩是否真正可用,避免在开发和部署阶段反复返工,是边缘 AI 落地中不可或缺的硬技能。
可视化演示
展示模型压缩前后多维度指标对比、精度-压缩率Pareto前沿分析与四步评估闭环流程,交互切换查看压缩效果评估核心机制。
本节配有交互动效(进入视口后自动加载,约 3KB)。
多维对比:压缩前后指标变化 INT8量化体积从13MB降至3.5MB压缩率3.7x 结构化剪枝减少40%FLOPs但精度仅降1.6% CR = Size_orig / Size_comp 压缩率越高说明体积削减越显著
核心压缩指标
小张第一次去健身房,教练让他做的第一件事是称体重、量腰围、测体脂。这三个数字构成了训练的“基线数据”。模型压缩评估的开端同样朴素:你先要知道模型有多大、参数有多少、计算量有多高。这三个数字合起来,就是压缩的“基础体检三项”。
压缩比是最直观的指标,它回答“模型小了多少”:原始模型体积除以压缩后体积。参数量则像健身房的“骨骼肌重量”,反映模型的“内在规模”。而 FLOPs(浮点运算次数)减少率回答的是“算得省了多少”——这相当于一次深蹲消耗的热量,是衡量计算开销减少的关键。
1. $S_{\text{orig}}$(原始体积):压缩前模型的存储体积,通常是模型文件在磁盘上的大小,单位可以是 MB。
2. $S_{\text{comp}}$(压缩后体积):经过剪枝、量化或蒸馏等压缩操作后,模型文件的新体积。
3. $\text{CR}$(压缩比):两者相除得到的倍数。CR 越大表示压缩得越狠,但必须配合精度等指标一起看,才能判断压缩是否“健康”。
1. $\mathrm{FLOPs}_{\text{orig}}$(原始计算量):原始模型完成一次推理所需的浮点运算次数。
2. $\mathrm{FLOPs}_{\text{comp}}$(压缩后计算量):压缩模型完成一次推理所需的运算次数。剪枝会让这个数字显著下降,纯粹的量化则可能变化不大。
3. 分子(减少量):原始计算量减去压缩后计算量,得到被削减的运算量。
4. 除以原始值并乘 100%:将减少量相对化,得到“省了多少比例”的直观数字。例如 100G 降到 35G,减少率就是 65%。
回到健身房:体重秤告诉小张瘦了多少,体脂秤告诉他瘦的是脂肪而不是肌肉。压缩比和 FLOPs 减少率就是模型压缩的“体重秤”和“体脂秤”,两者互为补充,缺一不可。
精度保持评估
教练告诉小张,减脂期最怕的不是掉体重,而是掉肌肉。肌肉量一旦流失,基础代谢下降,后续更容易反弹,力量训练的表现也会断崖式下滑。对模型压缩来说,精度就是模型的“肌肉量”——压缩后模型在原任务上的表现就是“力量测试成绩”,它决定了这次压缩是健康减脂还是伤敌一千自损八百。
精度保持率是最核心的判断指标:压缩后模型精度除以原始模型精度。这个数字越接近 100%,说明压缩对模型“智力”的损伤越小。除了整体精度,还要针对具体任务对比指标:图像分类看 Top-1/Top-5 准确率,目标检测看 mAP,NLP 任务看 F1 或困惑度。不同的“考试科目”对应不同的计分方式。
1. $\mathrm{Acc}_{\text{orig}}$(原始精度):压缩前模型在验证集上的任务得分,作为对比基准。
2. $\mathrm{Acc}_{\text{comp}}$(压缩后精度):压缩后模型在同一条验证集上的得分,测试条件必须完全一致。
3. 相除并转化为百分比:得到保持率。实践中通常设定一个阈值(如 95%),低于阈值就判定压缩“不合格”。
就像小张每个月都要重新测一次握力和深蹲成绩一样,压缩后的模型也需要在每个任务指标上重新“考试”。如果精度保持率在可接受范围内(比如 ≥95%),这次压缩才算“肌肉量保住了”。如果跌破阈值,即便压缩比再高,这个模型也可能无法上线——毕竟,一个体重很轻但浑身肌肉衰退的“模特”,没法参加力量比赛。
推理性能评估
小张减脂三个月后,最直观的变化不是体重,而是跑 5 公里配速从 8 分钟进步到 6 分钟。对模型来说,“减脂成功”之后,跑得够不够快同样关键。推理性能评估回答的正是这个问题:压完之后的模型,在真实运行时到底快了多少。
推理延迟是最常用的性能指标:从输入进入模型到输出生成之间的耗时。测量时要特别注意“热身效应”——前几次推理可能因为缓存未命中而偏慢,应该预热若干轮后再多次测量取平均值,就像跑步前得先活动关节一样。除了单次延迟,高并发场景还关注吞吐量:单位时间内能处理多少个请求。而加速比则是压缩前延迟除以压缩后延迟,告诉业务方“用户体验提升了多少倍”。
1. $L_{\text{orig}}$(原始延迟):压缩前模型单次推理的平均耗时,单位通常为毫秒。
2. $L_{\text{comp}}$(压缩后延迟):压缩后模型在相同硬件、相同输入规模下的单次推理平均耗时。
3. $S_{\text{pu}}$(加速比):原始延迟除以压缩后延迟。大于 1 说明压缩后的模型更快,越大越好。
1. $N$(处理请求数):在测试窗口内模型成功完成的推理次数。
2. $t$(总耗时):测试窗口的持续时间,单位是秒。
3. $T_{\text{put}}$(吞吐量):两者相除得到“每秒处理多少个请求”。对于云端批量处理场景,这个指标通常比单次延迟更重要。
小张不再用“今天少吃了几碗饭”来评价自己,而是看“5 公里配速提了多少”。同样,推理性能评估把“模型缩了多少”转化为“用户等得快不快”——这是业务方真正感知得到的价值。
能耗与能效
健身房里小张注意到一个细节:同样是 40 分钟有氧,第一个月他累得气喘吁吁、心率飙升,第三个月却脸不红心不跳。身体在同样的工作强度下消耗的资源变少了,这就是“能效提升”。在边缘 AI 场景中,模型的“体力消耗”表现为功耗和能耗。
能耗评估最常见的做法是实测:在目标设备上运行模型,通过功率计读取推理期间的功耗(瓦特),再乘以运行时长得到总能耗(焦耳)。能效比则把能耗与性能结合起来,例如“每焦耳能完成多少次推理”,或者“每瓦特能支撑多少 FPS”。对于电池供电的设备——手机、可穿戴设备、传感器节点——能耗直接决定续航,这也是模型压缩在边缘端最重要的价值之一。
1. $E_{\text{orig}}$(原始能耗):压缩前模型完成固定任务(如处理 1000 张图片)消耗的总能量,常用焦耳计量。
2. $E_{\text{comp}}$(压缩后能耗):压缩后模型完成相同任务消耗的总能量。注意测试任务量必须相同,否则对比无意义。
3. $E_{\text{ratio}}$(能耗节约倍数):两者相除得到倍数。3.2 倍意味着同样的电池电量,压缩后模型能处理 3.2 倍的数据量。
小张在同样的跑步机上跑同样的配速,心率带显示的数值下降,说明身体效率提高了。同理,能耗评估必须在“相同的推理任务量”这个跑步计划下进行,否则就像小张跑 3 公里和跑 10 公里比心率,数字失去了可比性。边缘设备的续航焦虑,也正靠这份“体能报告”来缓解。
设备适配评估
小张办了健身房年卡,但出差两周,只能在酒店房间里用弹力带训练——器械不同,动作也得跟着改。模型压缩的最终目标往往也是“换场地”:从云端 GPU 服务器搬到手机芯片、摄像头、智能音箱这类边缘设备上。设备适配评估就是要回答:压缩后的模型,在目标设备上真的跑得起来吗?
适配评估的第一步是列清目标硬件的“家底”:芯片算力、内存容量、是否支持 INT8 或 FP16 的量化加速指令。然后是评估内存峰值——模型推理过程中占用内存的最大值,它由模型参数所占内存和中间特征图内存共同决定。如果内存峰值超过了设备可用内存,模型就会像小张在拥挤的酒店房间抡不开弹力带一样,根本无法顺利执行。
1. $M_{\text{param}}$(参数内存):模型权重在数值精度(FP32、INT8 等)下占用的内存。量化之所以有效,正是因为它把每个参数从 4 字节压到 1 字节。
2. $M_{\text{act}}$(特征图内存):推理过程中每一层产生的中间激活值占用的内存,在通道数大的层可能比参数内存还高。
3. 相加得到峰值:两者相加即为推理过程中的内存峰值。这个值必须小于目标设备的内存上限,否则推理会因内存不足而失败。
压缩效果好不好,不能只看模型自己的“体检单”,还得看它去了目标设备后能不能“练得开”。一个在云端跑得飞快的模型,如果压完之后还是超出手机内存,就像小张把健身房的大杠铃搬进酒店房间——再重、再专业,使不开就是白搭。设备适配评估,正是压缩落地的“最后一公里”验收。
组合方法评测
小张的教练后来调整了计划:不再只做有氧,而是“有氧 + 力量 + 拉伸”三管齐下。他很快发现,单独做有氧时掉肌肉,单独练力量时减脂慢,但组合起来效果出奇地好——这就是组合训练法的协同效应。模型压缩的实践中,剪枝、量化、蒸馏等方法也常常叠加使用,组合效果评测因此变得至关重要。
评估组合方法的核心工具是消融实验(Ablation Study):以一个完整方案为起点,逐个“拆掉”某个压缩方法,观察指标如何变化。每次移除一个方法后,当前结果与完整方案的差异,就是该方法的边际贡献。这样既能判断每个方法是否起了积极作用,也能发现方法之间是协同放大还是互相拖累。例如剪枝后参数变稀疏,量化时精度损失反而更小,这就是协同效应。
1. $S_{\text{all}}$(完整方案评分):所有压缩方法叠加后,模型在统一评估协议下得到的综合得分。
2. $S_{\text{without } k}$(移除某方法后的评分):在完整方案中单独去掉第 $k$ 个方法,其余条件完全不变时重新评估得到的得分。
3. $\Delta S_k$(边际贡献):两者相减。若 $\Delta S_k$ 明显为正,说明该方法在组合中不可或缺;若 $\Delta S_k$ 接近零或为负,则考虑删掉它以免引入额外复杂度。
组合方法评测的本质是用“拆解实验”理解“叠加效果”,就像小张通过分别停掉有氧、力量、拉伸各两周,来找出自己训练计划里真正起效的成分。组合压缩从来不是方法越多越好——有些方法叠加后收益增益极小,却在工程上显著增加部署难度,这时就该学会“做减法”。
标准化度量体系
小张换了一家健身房,新教练看着他的体检报告说:“这个体脂率的标准和上一家不一样,我看不懂。”原来,健身房 A 用的体脂秤型号、测量时间和计算模型都不同,两份报告完全没法横向比较。模型压缩评估也面临同样的困境:各家实验室用自己的数据集、自己的精度定义、自己的测试硬件,互相之间没法对话。
标准化度量体系就是为了让全行业“说同一种语言”。它包含三个层面:第一,统一基准数据集,所有压缩方法都在同一批公开数据集和任务上评测;第二,规范报告的实验配置,明确写出硬件型号、Batch Size、数值精度、预热轮次等,确保结果可复现;第三,定义综合收益指数,把多个指标归一化到同一尺度后按业务权重加权求和,形成单一可比较的总分。
1. $s_i$(指标原始值):第 $i$ 个评估维度的原始数值,例如压缩比、精度保持率、加速比、能耗节约倍数。
2. $s_{\min}$ 与 $s_{\max}$(指标的最小值/最大值):该指标在同类模型评测中已知的取值边界,用于确定缩放比例。没有上下界的归一化是没有意义的。
3. $\hat{s}_i$(归一化得分):原始值与最小值的差除以取值范围,得到 0 到 1 之间的无量纲分数。分数越接近 1,说明该维度表现越好。
标准化度量体系解决的是“苹果与橘子比较”的问题。只有当所有健身房用同一台体脂秤、同一个测量时间、同一套计算模型,小张跨店对比的体检报告才有意义。同样,只有当业界的基准数据集、实验配置和指标定义统一起来,不同团队产出的压缩模型才能真正放到同一张“排行榜”上分高下。
AI 应用场景
手机端 AI 摄影的精度-延迟权衡
阶段:模型压缩与部署评估
解决的问题:手机端美颜和夜景增强模型需要在 30ms 内完成单帧处理,同时保持皮肤纹理真实。传统方法直接在服务器上评估模型效果,忽视了手机 NPU 的实际性能,导致上线后卡顿、发热。
具体案例:某手机厂商在压缩自拍美颜模型时,将 80MB 的模型剪枝量化到 22MB。评估团队按标准化流程在真机上统计:精度保持率 96.5%,单帧延迟从 68ms 降到 23ms,功耗从 1.2W 降到 0.45W。正是这一套“精度 + 延迟 + 能耗 + 真机适配”的综合评估结论,让该模型顺利通过验收,成为当年旗舰机的宣传卖点。
智能音箱语音唤醒的能耗评估
阶段:边缘设备功耗预算评估
解决的问题:语音唤醒模型必须常驻内存、7×24 小时监听,功耗高会严重影响音箱的待机续航。传统评估只看唤醒率,不关注能耗,导致产品待机时间远低于规格要求。
具体案例:某智能音箱团队对唤醒模型做 INT8 量化压缩,唤醒率从 96% 微降到 94.5%,但待机功耗从 340mW 降到 105mW,预计电池续航从 18 小时延长到 52 小时。评估报告明确记录了同一台设备、相同音量环境下的实测功耗曲线,按标准格式输出能耗节约倍数 3.2 倍,管理层据此拍板量产。
自动驾驶边缘盒子的设备适配评估
阶段:目标设备部署前的内存与算力验收
解决的问题:自动驾驶边缘盒子内存仅 4GB,原始目标检测模型参数量 80MB,推理时峰值内存突破 5GB 直接崩盘。压缩评估必须回答“压到多少才能装进盒子还能实时跑”。
具体案例:某自动驾驶创业公司采用“剪枝 + 蒸馏 + INT8 量化”组合方案,将模型压到 18MB,在工规级边缘盒子上测得峰值内存 1.9GB、单帧延迟 31ms、mAP 保持率 93%。消融实验显示蒸馏贡献了 5.2% 的精度回升,证明组合方案存在显著协同效应,最终方案成功通过车规验收。
Python 演示
# -*- coding: utf-8 -*-"""模型压缩效果评估器示例: 输入原始与压缩后的五维指标, 输出综合评估报告""" class CompressionEvaluator: def __init__(self, name, orig_dict, comp_dict): self.name = name # 模型名称 self.orig_dict = orig_dict # 原始模型指标字典 self.comp_dict = comp_dict # 压缩后模型指标字典 self.scores = {} # 各维度归一化得分 def compression_ratio(self): """压缩比 = 原始体积 / 压缩后体积""" return self.orig_dict['size_mb'] / self.comp_dict['size_mb'] def accuracy_ratio(self): """精度保持率 = 压缩后精度 / 原始精度""" return self.comp_dict['acc'] / self.orig_dict['acc'] def flops_reduction(self): """FLOPs减少率: 计算量下降的比例""" return (self.orig_dict['flops_g'] - self.comp_dict['flops_g']) / self.orig_dict['flops_g'] def speedup(self): """推理加速比 = 原始延迟 / 压缩后延迟""" return self.orig_dict['latency_ms'] / self.comp_dict['latency_ms'] def energy_ratio(self): """能耗节约倍数 = 原始能耗 / 压缩后能耗""" return self.orig_dict['energy_j'] / self.comp_dict['energy_j'] def composite_score(self, weights=None): """综合评分 = sum(w_i * s_i), 默认权重: 压缩比30%, 精度30%, 加速20%, 能耗20%""" if weights is None: weights = {'cr': 0.3, 'ar': 0.3, 'su': 0.2, 'er': 0.2} cr = self.compression_ratio() ar = min(self.accuracy_ratio(), 1.0) su = min(self.speedup(), 3.0) / 3.0 er = min(self.energy_ratio(), 3.0) / 3.0 self.scores = {'cr': cr, 'ar': ar, 'su': su, 'er': er} total = (weights['cr'] * cr + weights['ar'] * ar + weights['su'] * su + weights['er'] * er) return total def report(self): """输出标准化评估报告文本""" lines = [] lines.append('模型: %s' % self.name) lines.append('压缩比: %.2fx' % self.compression_ratio()) lines.append('精度保持率: %.1f%%' % (self.accuracy_ratio() * 100)) lines.append('FLOPs减少率: %.1f%%' % (self.flops_reduction() * 100)) lines.append('推理加速: %.2fx' % self.speedup()) lines.append('能耗节约: %.2fx' % self.energy_ratio()) return '\n'.join(lines) if __name__ == '__main__': orig = {'size_mb': 128.0, 'acc': 0.92, 'flops_g': 100.0, 'latency_ms': 45.0, 'energy_j': 0.8} comp = {'size_mb': 32.0, 'acc': 0.89, 'flops_g': 35.0, 'latency_ms': 18.0, 'energy_j': 0.25} ev = CompressionEvaluator('MobileNet-魔改小模型', orig, comp) print(ev.report()) print('综合评分: %.3f' % ev.composite_score())
self.orig_dict['size_mb'] / self.comp_dict['size_mb']体积相除得到压缩比,本质是“体重秤读数之比”return self.comp_dict['acc'] / self.orig_dict['acc']压缩后精度除以原始精度,是“肌肉量保持率”(self.orig_dict['flops_g'] - self.comp_dict['flops_g']) / self.orig_dict['flops_g']计算量差值除以原始值,得到 FLOPs 减少率min(self.accuracy_ratio(), 1.0)精度保持率上限截断为 1.0,防止异常数据把综合评分推高min(self.speedup(), 3.0) / 3.0加速比超过 3 倍后归一化得分封顶,避免单个指标过度主导总分weights = {'cr': 0.3, 'ar': 0.3, 'su': 0.2, 'er': 0.2}业务权重配置,不同场景可以替换这组数字lines.append('压缩比: %.2fx' % self.compression_ratio())格式化输出,模拟标准化报告文本if __name__ == '__main__':代码入口,直接运行即可看到评估报告示例
常见误区
误区模型从 128MB 压到 16MB,压缩比高达 8 倍,这一定是一次成功的压缩。我只看到文件变小了,感觉部署就没问题了。
正解压缩比只是“体重秤上的数字”。如果精度从 92% 掉到 80%,模型就像减脂把肌肉也减没了,业务上根本不可用。即使精度保持住,如果推理延迟没有下降(例如只用低压缩率量化体积,但算子未走加速指令),用户也感受不到任何体验提升。每个维度都要体检,单项冠军不算赢。
为何常见:体积是最容易获取的数字,复制粘贴一个文件大小就能算出来,而精度测试和真机性能测试需要搭建环境、跑完整流程,付出成本高,人自然倾向于用最省力的指标做判断。
误区压缩比是 4 倍,那计算量一定也少了 4 倍吧?剪枝和量化不都是在压缩模型吗,效果应该差不多。
正解压缩比衡量的是“存储体积”,FLOPs 减少率衡量的是“计算量”。剪枝可以大幅降低 FLOPs,因为它直接删掉了多余的连接和通道;而权重量化只是把每个数值从 32 位变成 8 位,存储体积缩到 1/4,但浮点运算次数几乎没变——除非硬件对低精度计算有专门加速。评估时要分别报告这两个指标,就像体重和体脂率是两回事。
为何常见:两者都叫“压缩”,日常语言里含义模糊,初学者很容易默认它们是同一个概念的不同表述,直到在真机上测出延迟没下降时才恍然大悟。
误区我在开发服务器上跑了一次推理,延迟 18ms,那真机上也应该是 18ms,直接写进评估报告就行了。
正解延迟受硬件、Batch Size、数值精度、预热状态、输入尺寸等多种因素影响。正确的做法是:在目标设备(或同芯片开发板)上,用上线时的真实输入规格,先预热 10~20 次,再重复测量 100 次以上取平均。而且,单次延迟和端到端流水线延迟也不同,后者还要算上前后处理时间。
为何常见:实验室环境方便、GPU 性能好,测起来又快又好看;真机环境需要烧录、跑脚本、处理驱动问题,麻烦得多。但实验室数字漂亮,真机跑不动的情况在边缘部署中太常见了。
误区综合评分就是把几个指标加起来呗,压缩比、精度、速度、能耗各给一样的权重,或者干脆都取平均数,反正能算出个分数就行。
正解权重必须由业务场景反向推导。手机端美颜 App 用户对延迟极其敏感,延迟权重就要给高;智能音箱要求长时间待机,能耗权重才是主角;离线批量处理的服务器,吞吐量权重可以给高。权重设定后应该固化到评估协议里,并写清楚理由,否则换个项目就换一套权重,跨模型对比完全失去意义。
为何常见:权重的设定表面上看是“加减乘除”的算术问题,容易让人觉得随便选就行。实际上它承载了产品的优先级取舍,是业务决策的量化表达,马虎不得。
面试题
Q1. 原始模型体积 100MB,压缩后 25MB,压缩比是多少?
- A.0.25倍
- B.2倍
- C.4倍← 正确答案
- D.25倍
答案:C。压缩比定义为原始体积除以压缩后体积,即 100MB / 25MB = 4 倍。选项 A 是压缩后剩余比例,选项 D 是体积直接相减的口算错误,选项 B 则是误以为除以 2。
Q2. 原始模型精度 92%,压缩后精度 88.08%,精度保持率约为多少?
- A.约95.7%← 正确答案
- B.约91.4%
- C.约88.1%
- D.约97.8%
答案:A。精度保持率 = 压缩后精度 / 原始精度 × 100% = 88.08 / 92 ≈ 95.7%。这好比看肌肉量保留了多少,而不是简单比拼两个精度数字本身的大小。
Q3. 以下哪个指标专门衡量模型计算量的减少?
- A.压缩比
- B.FLOPs减少率← 正确答案
- C.参数量
- D.模型体积
答案:B。FLOPs 减少率衡量的是单次推理浮点运算次数下降的比例。压缩比和模型体积看的是存储大小,参数量只描述权重数量,不直接反映计算开销的变化。
Q4. 关于推理延迟测量,以下做法最合理的是?
- A.单次测量即可
- B.多次取均并预热← 正确答案
- C.延迟与硬件无关
- D.延迟只看模型大小
答案:B。延迟测量必须预热若干轮以排除缓存冷启动的影响,再多次运行取平均值,同时记录硬件型号和 Batch Size。单次测量偶然性大,硬件和输入规格更会显著影响延迟结果。
Q5. 能耗评估最适合应用于以下哪个场景?
- A.云端大模型训练
- B.边缘电池续航设备← 正确答案
- C.代码编译时间
- D.数据集下载耗时
答案:B。能耗评估对电池供电的边缘设备(手机、智能音箱、传感器)至关重要,直接决定产品续航能力。云端训练更多关注总算力成本,编译时间与推理能耗无关。
Q6. 设备适配评估中“内存峰值”主要指?
- A.模型参数总字节数
- B.参数加中间特征图峰值← 正确答案
- C.训练样本占内存
- D.GPU显存空闲量
答案:B。内存峰值是推理过程中参数内存与中间特征图内存之和的最大值。只看参数内存会低估压力,因为大通道层的中间特征图往往比权重更占内存;特征图内存是评估设备能否跑通的关键。
Q7. 关于综合评分中权重的设置,以下说法正确的是?
- A.权重必须全部相同
- B.权重由部署场景决定← 正确答案
- C.权重越大表示越好
- D.权重与业务无关
答案:B。权重应反映业务优先级:手机 App 重延迟,智能音箱重功耗,服务端重吞吐量。权重本身不是越大越好,而是越重要的维度分配越高的权重,且各权重之和应为 1。
Q8. 压缩效果评估应包含哪些维度?
- A.精度保持← 正确答案
- B.推理延迟← 正确答案
- C.能耗水平← 正确答案
- D.团队人数规模
答案:ABC。一个完整的压缩评估要覆盖“体检报告”的多个维度:精度保持率看模型能力,推理延迟和吞吐量看速度,能耗看续航与散热。团队人数属于工程管理范畴,与模型本身效果无关。
Q9. 关于消融实验的说法,正确的是?
- A.评估单一方法在组合中的贡献← 正确答案
- B.每次移除一个方法观察指标变化← 正确答案
- C.不需要基准模型
- D.可判断叠加是否有副作用← 正确答案
答案:ABD。消融实验从完整组合出发,逐个移除方法,通过对比完整方案与移除后方案的评分差异,判断每个方法的边际贡献,也能识别方法间的协同或副作用。它必须有统一的基准评分作为参照,因此选项 C 错误。
Q10. 关于标准化度量体系,正确的说法是?
- A.统一基准数据集← 正确答案
- B.注明硬件和batch配置← 正确答案
- C.各方法可用不同指标
- D.收益指数需定义权重← 正确答案
答案:ABD。标准化体系要求统一基准数据集、明确实验配置、定义综合收益指数并固定权重,保证不同团队的压缩结果可复现、可对比。选项 C 违背了“统一度量”的初衷,各用各的指标就无法横向比较。