一个很常见的判断错误
选设备的时候，很多人会拿模型文件大小去对设备的存储和内存：模型几十兆，盒子有 4G 内存，看起来绰绰有余。
装上去跑起来，两路摄像头还行，加到第四路开始掉帧；或者白天客流少的时候正常，一到高峰期识别就慢半拍。
这类问题经常不是算力不够，而是搬运跟不上。模型文件小，只说明静态权重小；运行时真正占内存、占带宽的，是网络内部一层一层流动的中间数据。
计算和搬运是两件事
一个算子算完，结果要写回内存，下一个算子再从内存里读出来。这条链路上，权重只在用到时读一次，中间数据却是每个算子都写一遍、读一遍。
后果有三个，都跟门店现场对得上：
- 峰值内存不由模型大小决定。 输入分辨率越高、通道越宽，中间张量越大。同一套模型，换成 4K 摄像头，内存占用立刻上一个台阶。
- 带宽是共享的。 盒子上同时跑检测、识别、属性几个模型，几路视频一起抢同一条内存总线。抢不过来，表现出来就是延迟抖动，而不是平均速度变慢。
- 尾部延迟先坏。 平均值可能还好看，但排队时顾客感受到的是最慢的那几次。
所以「模型不大」和「设备跑得动」之间，隔着一层内存带宽。这一层不在配置表上。
什么情况下会撞上这堵墙
不是所有门店都会遇到。下面几种情况风险明显更高：
- 多路视频进同一台设备。 尤其是四路以上、或者分辨率不统一的时候。
- 一台设备上叠了好几个模型。 检测框、商品识别、属性判断分开跑，每个模型的中间数据都要占地方。
- 设备是 ARM 盒子，内存和显存共用。 算得再快，数据搬不过来也没用。
- 现场还在跑别的程序。 收银软件、广告屏、远程运维工具，都在同一块内存里。
如果门店只是单路、低分辨率、只跑一个模型，这层开销通常还撑得住；一旦往上加，问题就出来了。
在现场怎么看出来
不用看跑分，看拐点。
- 逐路加负载。 一路、两路、三路、四路分别跑一段真实客流，记录每路的单次耗时。哪一路开始明显变差，那台设备的实际上限就在那里。
- 看延迟分布，不看平均值。 要 P95 这类尾部数据。平均值掩盖的正是顾客最不舒服的那几次。
- 看内存峰值。 营业高峰时段的内存最高点，比开机时空转的数字有用得多。
- 在满路数下连续跑。 跑一个完整的高峰时段，而不是演示五分钟。
这四件事都不需要专业知识，需要的是把设备放到真实负载下。
选型时该问的问题
把问题从「算力多少 TOPS」换成下面这组，更容易问到点上：
- 推理过程中有没有做算子融合，中间结果是不是尽量留在片上、少往内存里写？
- 多路视频是不是共用一份预处理和内存池，还是每路各拷贝一份？
- 满路数运行时，能不能提供延迟分布和内存峰值，而不是单路演示？
- 换摄像头分辨率、加一个模型，需不需要重新调优？
这四个问题背后是同一件事：这套东西在设计时有没有考虑过搬运成本。考虑过的方案，回答会很具体；没考虑过的，通常只能回到「我们算力很大」。
门店这边能做的事
中间张量怎么压、编解码算子放在计算图的哪个位置，是推理引擎和模型侧的工作，门店改不了。门店能做的是三件：
- 不要用模型大小反推设备够不够，用满负载实测代替估算。
- 把「加一路会怎样」写进验收条件，而不是等开业后才发现上限。
- 给设备留余量。 按计划路数买设备、再指望它撑住旺季，是最常见的失误。
小结
模型文件小，不等于运行时省内存。层与层之间搬的数据，往往才是端侧设备真正的开销所在——它不出现在配置表上，只在加路数、上分辨率、叠模型的时候暴露出来。选型时多问一句「满路数下的延迟分布和内存峰值是多少」，比对比参数表有用。