演示机和门店里那台，差在哪
同一套识别模型，A 门店半秒出结果，B 门店要一秒半。设备看起来是一个型号，配置表也差不多。这种差异经常出在中间一层软件上——推理引擎（也叫推理运行时）。
它做的事听起来很朴素：把训练好的模型翻译成设备上能执行的计算，再调度 CPU、GPU 或 NPU 把它跑完。但就这一层，决定了三件事：跑多快、能不能换模型、出问题好不好查。
为什么配置表看不出来
配置表上的算力数字（TOPS）是芯片的理论上限，不是你的模型的实测速度。中间有几道折损：
- 模型里的算子，在目标芯片上有没有专用加速实现？没有的会退回通用路径，慢几倍是常事。
- 数据在内存和芯片之间搬运的开销，很多时候比计算本身更贵。
- 多路摄像头同时请求时，引擎怎么排队、怎么分配资源，直接决定高峰期的延迟。
这些都不在配置表里，只有在真实模型上跑一遍才知道。
门店和连锁 IT 该问的四件事
选型时把问题从「算力多少」换成下面这组，更容易问到点子上：
- 模型用什么引擎跑？ 是成熟的开源引擎，还是厂商自研？自研不是问题，但要问它支持哪些后端、算子覆盖到什么程度。
- 转换链是否自动化？ 门店上新品类时要换模型。如果每换一次模型都要人工转一遍、还要工程师到场，后续的迭代成本会跑得比设备便宜的那点差价快。
- 升级会不会影响正在跑的业务？ 引擎本身也要升级。升级时能不能灰度、能不能回滚，决定了你敢不敢做这件事。
- 出了问题能看到什么？ 识别变慢了，是引擎退回了通用路径、是模型换了版本、还是摄像头脏了？没有日志和留样，就只能靠猜。
一个实用的验收动作
不要只看演示。要求在同一台设备上、用你自己的商品和真实客流节奏，跑一段完整的高峰营业时段，并记录两件事：
- 单次识别耗时的分布，而不是平均值——排队时顾客感受到的是最慢的那几次；
- 多路摄像头同时工作时的耗时。
如果对方只能提供单路演示、没有多路数据，那这份性能承诺就还没有经过验收。
换个引擎能救吗
不一定。如果你的问题是「模型认不准长尾品类」，那是模型和数据的问题，换一个更快的引擎只会让它更快地认错货。
引擎能解决的是另一类问题：同样的识别效果，能不能在便宜一点的设备上跑住、能不能跑得更稳、模型能不能换得更勤。判断清楚问题属于哪一类，再决定要不要动这一层。
小结
推理引擎是门店看不到、但每天都在影响收银速度的一层。它不适合放在宣传材料里讲，却适合放进选型提问清单：用什么引擎、怎么换模型、升级怎么回滚、出问题看什么。把这四条问清楚，比对比配置表有序得多。