把一段视频当输入，门店要多付哪些账

逐帧识别和看一段视频，不是一回事

同样一个问题——「这格货架是不是空了」——两种做法差别很大。

逐帧识别是：取一张图，跑检测，输出框和类别，再按规则判断。算力与帧数成正比，逻辑简单，出错也容易定位。

视频理解是把一段连续画面整体交给多模态模型，让它自己描述发生了什么。麻烦在 token 数：按 448×448 的输入、16 像素一个 patch 粗算，一帧约 780 个视觉 token；30 秒、每秒 2 帧就是 60 帧、四万多个 token。这些 token 要过视觉编码器、过 projector、进语言模型做 prefill，还要在解码时留在显存里。开销不是「多看 60 倍」，而是按序列长度的方式长。

所以门店要判断的第一件事不是模型好不好，而是这个问题的答案在不在一帧里。

答案在一帧里的：价签读没读对、商品是什么、货架这一格有没有货。这类用逐帧就够，上视频是浪费。

答案在一段动作里的：自助收银有没有漏扫（手部动作有先后）、称重时是不是先放托盘再放商品、员工有没有按规定扫码、顾客拿了又放回。这类问题单帧看不出来，只能看序列。

省在哪一步，决定你丢了什么

arXiv 上有一篇综述（2610.36327）把「不改权重、只改推理路径」的加速方法按干预位置分成了五段，这个分法比方法清单有用，因为它直接对应「你可能丢掉什么」：

• 输入抽帧：省得最多，也最不可逆。没进的帧永远补不回来，一次两秒的遮挡如果正好落在抽掉的区间里，事件就没了。
• 视觉编码阶段剪 token：在编码器内部合并相似的 patch。省得多，但判断依据只有图像本身，模型还不知道你要问什么。
• projector 处压缩：编码器之后、语言模型之前。位置靠后，可以带一点问题的信息，压缩更有针对性。
• prefill 阶段稀疏注意力：不减少 token，只减少它们之间的两两计算。对精度影响小，省的是算力不是显存。
• 解码阶段少生成：限制输出长度、提前退出。省时间，但回答会变短。

论文的两个判断值得记住。第一，越靠前的压缩越省算力，也越容易把细小但关键的信息（小字、手部动作、短暂遮挡）和冗余一起扔掉。第二，局部的效率提升不自动变成端到端加速——如果瓶颈在数据搬运、算子启动或者解码，编码阶段省下的算力只让总时延动一点。

门店侧要算的三笔账

显存。 视觉 token 和 KV 缓存都要常驻。一路摄像头 30 秒的四万 token 与四路并发的四万 token 完全不是一回事。盒子上还要跑收银软件、打印服务、其他识别任务。

带宽。 如果视频要上传到区域服务器或云端，一路 1080p、2 Mbps 的摄像头一天就是二十多个 G。多路乘起来，专线费用往往比设备贵。

时延。 门店的场景对时延的要求分两档：交互类（顾客站在收银台前）要亚秒级首字；巡检类（夜里走一遍货架）可以分钟级。用交互类的标准去要求巡检，会白花钱；反过来，把交互类做成分钟级，没人会用。

什么情况下值得上视频理解

• 判据本身是顺序的：先扫码后装袋、先放托盘后放商品、拿了之后有没有放回。
• 事件短、但结果重要：漏扫一次可能就是几十块，靠人工回看录像成本更高。
• 单帧信息不足：遮挡、背身、手部动作被身体挡住。

反过来，如果只是数货、读价签、认商品，逐帧加规则更便宜、更好验收，也更容易解释。

验收时看五件事

1. 事件级指标，不看平均分。 标十段真实视频，标出事件发生的时间点，看模型有没有在那个时间窗里报出来。平均准确率对短时事件几乎没有意义。
2. 端到端时延的 P95。 首字时间、整段处理时间分开测，按门店最忙的时段测。
3. 时长退化曲线。 30 秒、1 分钟、3 分钟各跑一遍，看精度和时延怎么变。很多方案在短视频上正常，长一点就开始丢中间段。
4. 换抽帧策略要重测。 从每秒 2 帧改成每秒 1 帧，省了一半算力，也可能正好丢掉关键的两秒。这是最容易在升级时被忽略的一项。
5. 断网跑一遍。 本地盒子上的视频理解如果不能离线工作，等于把门店的巡检绑在了网络上。

一句话

视频理解贵不在「看」，在于把画面展开成 token 之后的显存、带宽和时延。先问答案在不在一帧里——在，就用逐帧；不在，再谈视频，并且按事件而不是按平均准确率验收。