门店网络里那台盒子，夜里在跟谁说话
一台盒子接进网络之后
安装那天，工程把盒子插上网线，配好 IP，识别开始出结果。事情看起来完成了。
之后几周，值班的人开始注意到一些不对：夜里十一点到凌晨两点，门店出口带宽被占掉一截，正好和补货、对账、日结报盘撞在一起；IT 在出口设备的日志里看到几个不认识的域名，反复出现；有一次外网断了，收银照常能收，但那台盒子起不来，卡在启动界面几分钟。
这三件事的根源可能是同一个：设备在往外说话，而没人知道它在说什么。
模型文件不是纯数据
大多数人以为「模型」就是那个权重文件，几百万个数字，不会执行代码，所以不会联网。
实际部署出去的是一整套东西：权重、推理框架、预处理脚本、依赖库、模型下载器、许可校验模块。往外发起连接的通常是后面这几样：
- 遥测。 很多推理框架默认开着使用统计和崩溃上报，开关藏在环境变量或者配置文件深处，默认值是开。
- 许可校验。 商业引擎会定期回连核对授权，断网时退化成重试，重试期间启动被阻塞。
- 更新检查。 拉过依赖的安装脚本，往往保留着检查新版本的逻辑。
- 权重下载。 有些方案不在本地存模型，启动时按需拉取。断网就等于没有模型。
2026 年 10 月有一则公开报道：Cohere 在一次测试中发现，一个开源权重的 Qwen3-8 模型在运行时尝试回连其来源方的服务器。报道讨论的是企业引进第三方权重时该注意什么。这件事的重点不是哪家厂商，而是这一层默认行为平时几乎没人检查。
在门店里，这件事为什么比在机房更要紧
机房有出口防火墙、有流量监控、有专门的人看告警。门店没有。
具体到三个后果：
带宽。 门店出口是按套餐买的，白天被收银占着，夜里被补货和对账占着。一个每十分钟上报一次、每次几百 KB 的进程，单看不多，几百家店加起来就是一条持续的占用，而且它不会挑时间。
管控被绕过。 门店的流量策略通常只覆盖到 PC 和 POS 机。新加的盒子如果没有登记，就是一条没人管的通道。
断网时的行为。 这一条最要命。识别本身离线可用，这是端侧方案的核心卖点；但如果启动流程里有一道许可校验在等超时，断网那天盒子就是起不来。卖点还在，业务没了。
部署前能做的五件事
一、把开关全关掉，再看功能缺不缺。 配置文件里搜 telemetry、analytics、update、license 这几类关键词，先全关。关完跑一遍完整业务，看缺什么。缺的部分要么接受，要么单独放行。
二、隔离网络里冷启动一次，只看 DNS。 把设备放进一个能解析、不能出站的网络，抓冷启动和一次正常识别的域名查询。看域名和频率就够了，目的是知道它在跟谁说话，不是审查报文。
三、拔网线跑完整流程。 开机、识别、上报、升级检查，全走一遍。要看的不是「能不能出结果」，而是「有没有哪一步在等超时」。这一条最容易暴露问题，也最容易做——一根网线的事。
四、出网白名单，不是黑名单。 设备只允许访问明确列出的目标：更新通道、时间同步、自己的服务端。其余默认拒绝并记日志。默认拒绝的好处是，新增的连接不需要有人先发现。
五、把「可关闭」写进交付清单。 每一项外连行为对应一个关闭方法，外加关闭后功能缺失的说明。不能关的，写清为什么。
采购时该问的四句话
- 设备运行时会访问哪些外部地址？能列一份完整清单吗？
- 这些访问能不能关？关掉之后哪些功能会缺？
- 断网状态下，从开机到第一次识别出结果，需要多久？有没有阻塞式的校验？
- 模型更新走哪个通道？是我们自己的服务器，还是厂商的？
第三问的回答形式很重要。回答「支持离线运行」不算答案，要的是「拔掉网线，从通电到出第一笔结果，多少秒」。
什么时候不用为这件事花力气
- 盒子只连店内局域网，物理上不接外网。这时候问题变成「它在局域网里连谁」——会不会扫描网段、会不会连别的设备端口。范围小了，做法一样，别当成不存在。
- 用的是自己编译的运行时、自己训的权重、固定版本不再升级。外连面基本收敛到你自己写的那几个调用，审计一次就够。
- 设备数量只有个位数，且出口有统一策略。人工看一遍日志的成本低于建流程的成本。
最后
审计不是一次性的验收动作。推理框架升级、镜像换版、模型换批，默认配置都可能变，外连行为跟着变。把它当成一个每季度重跑一遍的检查项，比当成一个签过字的文件有用。