盒子看一段视频就卡，问题多半不在模型大小
一个常见的落差
识别单张图，盒子很快。把同样的模型换成「看最近三十秒的画面，判断这个人有没有把商品放进包里」，同一台机器开始不对劲：帧率掉下来，风扇转起来，延迟从稳定变得忽高忽低，跑久了偶尔整个进程重启。
模型没有换，图也没有变大。变的是输入的长度。
装进去的是常数，跑起来的是变量
模型文件的大小是装配时就定死的。压到几十兆的模型，装进盒子之后占多少内存，大致是个常数。
但推理过程中还有另一类数据：注意力要保留的历史、每层要缓存的中间结果、多帧的特征。这些东西的大小和输入长度成正比。十帧和三百帧，不是一个量级。
所以盒子的内存预算其实是分两半的：一半给模型，一半给运行中的上下文。压模型压的是前一半。前一半做得再小，后一半照样按长度长。
arXiv 上 2026 年 10 月有一篇工作（编号 2610.34824，方法名 SPARTA）把这个落差写在了摘要第一句：端侧模型受内存和带宽限制，1.58 位三元权重虽然大幅降低了模型存储，长上下文推理仍然有自己的约束。它给出的方向是把注意力做得更稀疏、把稀疏注意力和低位宽矩阵乘放到同一条数据通路上。
对我们选设备的人来说，值得记住的不是方法细节，而是这句话背后的判断：权重压缩和长上下文是两笔账，不能互相抵。
什么情况下门店会撞上这件事
不是所有门店应用都吃长上下文。撞上它的通常是这三类：
行为判断，而不是单帧分类。 计价是看一眼就出结果；防损要看的是一段——从货架前停留、拿起、放到哪里、有没有经过收银台。这段越长，判断越准，也越吃内存。
多轮交互。 语音导购、自助问答这类，用户问到第五轮时，前面几轮的内容还在上下文里。轮数越多，占用越大，响应越慢。
多路同时看。 一台盒子接四个摄像头，每路都在跑一段窗口。内存占用是路数乘时长，不是加法。
提前判断的三个动作
不用等上线才发现。选型阶段可以做三件事：
看内存曲线，不看内存数字。 让供应商把一段完整业务跑满一小时，给内存随时间的曲线。要看的是：是否单调上升、跑完有没有回落到起点、峰值离上限还有多少。一条只报「占用 800MB」的参数表说明不了任何问题。
按路数翻倍测。 一路跑得动，四路不一定。每加一路，观察延迟和内存的边际变化。如果第二路就让 P95 翻倍，说明预算已经贴着天花板。
看最慢的那几次。 平均延迟是给汇报用的。顾客感知的是排到他那一单时等了多久，值班的人感知的是夜里盒子重启了几次。跑满一个午高峰，看 P95 和最大值。
一个更便宜的思路
在掏钱换更贵的盒子之前，先问一句：模型真的需要看完整段吗？
很多场景里，先用轻量的检测器或规则挑出候选片段（有人靠近货架、有手伸进画面、有商品从画面消失），只对候选片段跑重模型。这样上下文自然就短了，内存和延迟一起下来，而且更容易解释——出了问题能说清是哪一段判错了。
代价是漏检：候选没被挑出来，后面的模型再准也没用。所以这条路的前提是，候选筛选那一层的召回率要单独测，不能只看端到端总数。
什么时候这件事不用管
- 业务本身是单帧的：称重计价、扫码、单张图片的品类识别。这些场景里上下文只有一两帧，长上下文不是瓶颈。
- 盒子上只跑一个模型、一路视频，内存余量充足。这时候该盯的是端到端链路，不是模型。
- 瓶颈在别处。如果顾客从放下商品到看见价格要等两三秒，而识别只占几十毫秒，那时间花在摄像头曝光、图像传输、计价服务的往返、打印小票上。先量一遍每一段，再决定要不要为上下文买单。
该问供应商的四句话
- 这个模型处理一段连续输入时，内存占用随长度怎么变？跑满一小时会回到起点吗？
- 一台盒子最多支持几路同时开？四路的时候 P95 是多少？
- 长输入是怎么处理的：滑窗、抽关键帧，还是整段进模型？抽帧的策略会不会漏掉短时动作？
- 峰值内存离设备上限还有多少余量？我们盒子上还要跑别的进程。
第四问最容易被跳过。盒子出问题的方式，往往不是算不动，而是几个进程一起把内存吃到顶，系统杀掉一个，重启，业务断几十秒。