这个提议是怎么来的
门店想上点新东西——本地跑个语音导购、同时分析六路摄像头、或者在后厨加行为识别——一算单台盒子的算力不够。这时候常听到一个方案：没事，多买两台，几台设备一起跑。
这个思路在数据中心里是常规操作，叫模型并行或者分布式推理。放到门店里，要先弄明白它的成本结构。
切开的代价：每一层都要说话
把一个模型分到几台设备上，有两种切法：按层切（前几层在 A，后几层在 B），按序列或者通道切（每台各算一部分，再合并）。
两种切法都绕不开一件事：中间结果要在设备之间来回传。 不是传一次，是每一层都要传。层数越多，往返次数越多，延迟一层层叠上去。
这就是所谓「通信受限」：算力是够的，时间花在等数据。
而门店的网络是什么样的？千兆内网算好的，很多店还在共用 WiFi。同一根网线上还跑着收银、监控回传、办公电脑、扫码支付。你没法为推理单独拉一张网。
所以这件事的判断标准很直接：设备之间的那次传输，比它省下的计算时间短还是长。 短，值得；长，不如买单台更强的设备。
学界在压这段通信
这段通信不是不能压。arXiv 上有一篇 TRACE: Transformer Residual Activation Codebook Encoding for Communication-efficient Distributed Edge Inference（编号 2610.22435），做的是把设备之间传的激活值换成「码本索引」。
思路是：提前学一本码本，把高维的中间结果映射成有限个代表向量，传输时只传编号，接收方按编号查表还原。更关键的是，它把接收方原本必须做的 key/value 投影提前算好、按索引存进表里——收到索引就能直接查，不用再算一遍。这样通信和计算可以重叠，不再一段等一段。
论文报告在 ViT-Base 和 ViViT-B 上，相对此前最好的同类框架精度高 1.89 个百分点、端到端快 1.27 倍；相对完全不做压缩的方案，通信量降到原来的两万两千多分之一。注意最后这个数字是通信量，不是速度——端到端只快 1.27 倍，因为算完还得算。
这个对比恰好说明问题：即便把通信压到极致，省下来的也只是那一段。如果门店网络本来就紧张，压过之后仍然可能不够。
三档方案，按门店规模选
与其纠结「能不能多机协同」，不如先把三档摆出来：
单店单机。 一台设备跑完所有模型，数据不出店。结构最简单，故障面最小，出了问题只需要排查一台。绝大多数门店的收银识别、单路或者双路监控，这一档就够。
店内多机。 一台负责收银识别，一台负责视频分析，各干各的，互不协作。注意这不是「合跑一个模型」，而是任务分开——这才是门店里多设备最常见的合理形态。它不需要设备之间传中间结果。
区域服务器或云端。 多家门店的数据汇到一处，跑重一点的模型。代价是上行带宽和断网时的降级方案，得提前设计。
真正需要「几台设备合跑一个模型」的场景，在门店里其实很少：单台设备实在装不下、又必须本地跑、还要求低延迟。三者同时成立才值得考虑。
如果对方坚持要多机方案，问这几句
- 模型怎么切？切在层上还是切在通道上？每层要传多少数据？
- 这套东西在门店的实际网络条件下测过吗？还是只在内网直连的实验室里测过？
- 网络被收银和监控占满时，端到端延迟是多少？有没有降级策略？
- 少一台设备会怎样？是整体停摆，还是降级运行？
- 多出来的那台设备，是买算力还是买布线？
最后一条经常被忽略：多机方案往往要多拉网线、多加交换机、多留电源位，这些改造费用在报价单外面。
验收怎么测
不要看单机演示，也不要看两台设备挨着摆在桌上、网线直连的演示。
- 端到端测。 从摄像头进画面到出结果的总时间，不是某一台的推理耗时。
- 在真实网络里测。 接在门店实际的交换机上，让收银和监控照常跑。
- 加并发。 多路视频同时进来，看延迟分布，不看平均值。
- 拔一根网线。 看系统是降级还是直接不可用——门店网络出故障是常态，不是意外。
一句话
「多买两台一起跑」在数据中心成立，在门店要先过网络这一关。多数门店更划算的做法是把任务分开、各跑各的；真需要合跑一个模型时，先让对方拿门店的真实网络条件跑一遍端到端延迟，再谈价格。