一、项目背景

这个需求来自一家做社区生活服务的连锁品牌，八百多家门店，每家店有一到两台收银一体机。他们想在收银台上加两个能力：一是商品识别，店员把散装商品放到摄像头下自动识别品类和称重计价；二是本地问答，新店员遇到"这个券能不能叠加""临期怎么处理"这类问题，直接在收银机上问。

原本的方案是全部走云端。测下来问题很明显。商品识别一次往返平均八百多毫秒，收银高峰期店员根本等不起，一单要识别三四样东西，顾客队就排起来了。更要命的是网络。他们的门店分布在县城和乡镇，宽带质量参差，我们抽了五十家店做了一周监测，日均断网超过五分钟的有十九家，最夸张的一家一天断了四十多分钟。断网期间收银机上的智能功能全废。

硬件这边也没什么余地。收银一体机是三年前统一采购的，八核 ARM 处理器，八 G 内存，没有独立显卡，全国八百多台，换机成本客户不接受。

二、落地场景

方案定的是端云协同：常用能力下沉到端侧，复杂能力留在云端，断网时端侧兜底。

云端这边用 AI 私有化部署底座里已有的模型作为教师模型，商品识别用的是视觉模型，问答用的是文本模型。我们在底座上搭了蒸馏流水线，把教师模型的能力压缩到能在门店硬件上跑的学生模型里。

端侧部署的是量化后的学生模型，商品识别模型压到三十多兆，问答模型压到一百八十兆左右，两个加起来内存占用控制在一点二 G 以内，剩余内存留给收银软件本身。推理框架选的是支持 ARM 的轻量运行时，用上了处理器的向量指令集。

云端兜底的逻辑是：端侧模型给出结果时带一个置信度，置信度低于阈值且网络可用，就把请求转发到云端大模型，拿更准的结果；网络不可用就用端侧结果并打标，事后可以复核。

模型更新走灰度分发。云端训练出新版本后先推给五十家试点店，跑一周观察指标，没问题再全量。分发用的是增量包，只传变化的权重块。

三、关键技术挑战与解决思路

蒸馏的效果保持是核心难题。商品识别这块相对好办，品类是封闭集合，客户 SKU 加起来一千二百多个，散装生鲜类常用的也就三百来个。我们用教师模型对门店历史摄像头图片做批量标注，生成了四十多万张软标签样本，学生模型用知识蒸馏加上少量真实标注数据混合训练，Top-1 准确率从直接训练小模型的百分之八十一提到百分之九十三点五，教师模型是百分之九十六点二。这个差距在业务上可以接受，因为有低置信度转云端兜底。

问答就难多了。开放域问答想用小模型达到接近的效果基本不现实。我们做了取舍：不追求全能，只覆盖高频场景。分析了三个月的历史问答日志，发现百分之七十三的提问集中在券规则、退换货、临期处理、称重操作、交接班这五类。我们把这五类的知识做成结构化条目，学生模型的任务从"什么都答"退化成"在这五类知识里做检索加改写"，难度骤降。超出这五类的直接转云端。这个思路上的退让，我认为是这个项目能成的关键。一开始技术团队里还有人坚持要做通用端侧问答，被现实教育了两周才放弃。

量化裁剪的精度损失需要细调。我们试过直接 INT8 全量化，商品识别的准确率掉了近四个百分点，掉的主要是那些外观相近的品类，比如不同品种的青菜。后来改成混合精度，对量化敏感的层保留 FP16，其余走 INT8，模型体积略大一点，准确率只掉一点一个百分点。哪些层敏感是逐层做消融测出来的，跑了两天。

断网兜底的状态一致性容易被忽略。端侧离线期间产生的识别记录、问答记录、异常标记，恢复网络后要能同步回去，而且不能重复。我们给每条记录生成本地唯一标识，同步走幂等接口，重复提交直接忽略。有一次试点店的收银机被强制断电，本地队列的写入没落盘，丢了十几条记录，后来加了 WAL 才解决。

模型分发也踩过坑。第一次全量推送选在白天，八百台机器同时拉一百八十兆的包，把客户的专线带宽打满了，门店收银系统跟着卡。改成夜间分批加上增量包之后才正常。这事说起来很低级，但当时确实没想到。

案例片段（已脱敏）： 端侧商品识别的一条置信度兜底记录：本地识别=小白菜 置信度 0.62 低于阈值 0.75，网络可用，转云端；云端返回=上海青 置信度 0.94，采纳云端结果，本地记录标记为待学习样本。这类样本累计到一定量后回流进下一轮蒸馏训练集，三个月内小白菜与上海青的混淆率从 8.3% 降到 1.9%。 混合精度的层级选择结果（节选）：视觉模型共 34 层，其中前两层卷积与最后的分类头保留 FP16，中间 29 层走 INT8，模型体积 31.4MB，Top-1 准确率 93.5%；若全 INT8 体积降至 24.7MB，准确率跌到 90.1%，权衡后选了前者。

四、效果数据

全量推开三个月后的数据。端侧商品识别平均推理延迟一百四十毫秒，相比原来云端往返的八百多毫秒是数量级的改善，店员反馈"基本感觉不到等待"。端侧问答首字延迟三百二十毫秒左右。

准确率保持度方面，商品识别端侧百分之九十三点五，叠加云端兜底后整体百分之九十五点八，接近纯云端的百分之九十六点二。高频五类问答的准确率端侧百分之八十九，云端百分之九十四，整体百分之九十一点七。

离线可用率是提升最明显的指标。原来断网期间智能功能可用率是零，现在是百分之百可用（降级形态）。按那五十家监测门店的数据折算，全年因断网导致的智能功能不可用时长从人均约四十二小时降到接近零。

模型更新成功率百分之九十九点二，失败的主要是少数机器磁盘空间不足，加了预检之后基本清零。云端调用量下降了约百分之七十六，这块的推理成本节省相当可观。文中数据为项目复盘口径，已做脱敏。

五、可复用经验总结

端侧部署这件事，第一步不是选模型选框架，是先把场景边界砍窄。想让小模型干大模型的活，怎么优化都是死路。把高频场景切出来做深，剩下的交给云端，整体体验反而更好。我们在问答上的那次退让，事后看是最重要的一个决定。

蒸馏的样本来源可以很省。用教师模型给存量数据打软标签，比重新组织人工标注便宜得多，效果也够用。真实标注数据只需要少量，用来校准和验证。

量化不要一刀切，逐层消融的两天时间花得非常值。混合精度多出来的几兆体积，换回来三个百分点的准确率，这笔账很好算。

端云协同的置信度阈值要能远程调。我们最初把阈值写死在客户端，后来发现不同区域门店的光照条件差异会影响识别置信度分布，需要分区域调优，只好紧急加了下发能力。这种参数最好一开始就做成可配置。

模型分发要当成一次线上变更来对待，灰度、限速、预检、回滚一个都不能少。八百台设备的规模已经足够让任何粗糙的分发策略变成事故。

附：工程落地细节

端侧推理运行时用的是支持 ARM NEON 指令集的轻量框架，编译时开了针对目标处理器的优化。模型文件做了加密存储，防止被从设备上拷走。本地知识条目存 SQLite，全文检索用的 FTS5，配合向量检索做混合召回，纯本地环境下检索耗时在二十毫秒内。离线队列用 WAL 保证掉电不丢，队列上限设一万条，超出后按时间淘汰并告警。云端兜底的判定除了置信度还看网络探测结果，探测是被动的，用最近三次请求的成功率和延迟做判断，不额外发心跳。灰度分组按门店 ID 哈希，保证同一批次稳定，便于对比。回滚包常驻本地，新版本连续三次推理异常自动回滚到上一版。

附：一点实在的提醒

门店场景的硬件比机房恶劣得多。收银台温度高、灰尘大、供电不稳，我们在试点期见过因为散热不良导致处理器降频、推理延迟翻倍的情况。做端侧部署要给性能留足余量，实验室里跑一百四十毫秒的模型，到了夏天的门店可能就是三百毫秒。这一点在方案评估阶段最容易被高估自己。