模型文件小了一半，店里的收银速度没变
一句常见的说法
谈识别方案的时候，供应商给的说法常常很直接：模型文件从 180MB 压到 92MB，参数少了一半，推理更快。
数字通常是真的。装到店里，称一台散装花生，从放上去到出价，时间和之前一样。换一台机器测，还是一样。
道理不复杂：少掉的那部分参数，本来就没占用时间。
少了参数，时间去哪了
端侧识别跑在收银台那台盒子上，这颗芯片的问题通常不是算不过来，而是等数据。算力和内存带宽不匹配的时候，算子算得再快，也得等权重从内存搬过来。
在这个前提下，"参数减半"能省多少时间，取决于三件事：
稀疏的形状。 如果删完的权重还是规整的块，搬运可以整块跳过，读的字节数真的少了一半。如果删得零零散散，每个非零值都要单独寻址，索引本身也要占带宽，省下的乘法被访存补回去，净值可能接近零。
推理框架认不认这种形状。 框架对稀疏的支持分两种：一种是真的按稀疏结构跳过计算，一种是老老实实按稠密矩阵算、乘上一堆零。后者在文件大小上照样好看，在时间上一分不省。这一层最容易被漏掉，因为它不在供应商的 PPT 里，在框架的算子实现里。
这颗芯片有没有对应的指令。 有的芯片支持按固定比例跳过的稀疏指令（比如每四个权重保留两个），有的没有。没有的话，编译器会把模型退回稠密执行，压缩率还在，加速没了。
稀疏在门店里什么情况下真的有用
不是为了"更快"这个笼统的目标，具体是这三种场景：
一套权重覆盖多档设备。 旗舰店的新盒子和三年前开的老店盒子，算力差好几档。如果同一个模型能按内存预算裁成两个档位下发，运维就少维护一套模型版本。这是 arXiv 上一类弹性压缩工作（编号 2610.31897，方法名 S-SALAAD）在解决的问题：训练时把低秩分量和结构化稀疏分量一起学出来，让一个 checkpoint 能裁到不同预算，配套算子保证裁完还是快的。
一台设备要同时跑好几个模型。 识别、称重、防损、语音提示挤在同一块内存里，装不下的时候，压缩是让它们共存的手段，不是为了提速。这种时候看的是内存峰值，不是延迟。
每次升级的下载量。 几百家店同时 OTA，模型小一半，下发窗口和失败率都跟着变。这一条和识别速度没关系，但值班的人会在意。
该追问供应商的五句话
- 稀疏是结构化的还是非结构化的？具体是什么模式，2:4、整块、还是整行整列？
- 加速比是在哪颗芯片、哪个推理框架、哪个版本上测的？我们准备采购的型号在不在里面？
- 这个稀疏模型是重新训的，还是在原模型上剪完补训的？训练成本算在谁的报价里？
- 如果一份权重裁成两档，两档的精度分别是多少？掉在哪几个品类上？
- 压缩后的内存峰值是多少？我们盒子上还要跑别的模型，余量够不够？
第五问最容易被忽略。压缩方案通常只报文件大小和平均延迟，不报峰值内存。而收银台出问题的方式，往往是高峰期几个模型一起把内存吃到顶，进程被杀掉重启。
门店自己要做的事
不用自己跑基准测试，但有三件事只能自己做：
- 用自己的图。 从自家货架、自家秤台、自己的灯光下取几百张，包含最难的几类：叠放、反光包装、散装称重、新换的包装。所有方案都在这批图上比。
- 在低配那台机器上测。 门店的故障大多发生在最便宜的那一档设备上。高配机跑得动，说明不了什么。
- 看最慢的那几次。 平均延迟是给汇报用的，顾客感知的是排到他那一单时等了多久。跑满一个午高峰，看 P95 和最大值。
什么时候这件事根本不用管
如果识别一次本来就只有几十毫秒，而顾客从放上商品到看见价格要等两三秒，那瓶颈不在模型上——在摄像头曝光、在图像上传、在计价服务的往返、在打印小票。先量一遍整条链路每一段的耗时，再决定压不压缩。
模型压缩是手段。手段要先对上瓶颈，否则压得再漂亮，顾客也不会少等一秒。