数据不出库，模型照样训：联邦学习在多仓库场景的实战

先说结论：联邦学习不是给单个仓库准备的。它唯一值钱的场景，是数据出不来、但模型又想学的地方——最典型的就是 3PL：手里管着好几个客户的仓，数据谁都不让动。2023 年我见过一家加州 Inland Empire 的 3PL 翻车：4 个仓、3 个大客户，光数据共享协议就谈了半年，最后模型一个没训出来。要是早知道有这条路，那半年本可以不用浪费。

这篇文章把联邦学习讲透：它到底在干什么、什么时候值得花钱、真要做先过哪几道坎。不吹不黑。

这两年问我联邦学习的人明显多了。十个里有九个是被 AI 供应商的销售忽悠的——PPT 上写着"数据不出库、隐私零风险、精度还更高"，三句话全是坑。精度更高？各仓数据不互通的情况下，联邦模型通常还不如单仓数据充足时的集中模型，它赢的是"能做"，而不是"更好"。这篇就是来祛魅的。

它到底在干什么：模型到处跑，数据原地不动

传统做法是把各仓的数据抽到一个中央库，再训练模型。联邦学习反过来：中央服务器只发"模型"，每个仓在本地用自己的数据训练，训完只把模型更新（梯度或权重）传回去，服务器把各家的更新加权平均，生成新一轮的全局模型，再发下去。如此往复。数据从头到尾没出过仓库的门。

这套思路是 2017 年 Google 的 McMahan 团队在论文《Communication-Efficient Learning of Deep Networks from Decentralized Data》里提出来的，核心算法叫 FedAvg。最早的应用场景是手机输入法预测——谁都不想把自己打了什么字上传出去，但大家又都想要更准的预测。仓库的处境一模一样：3PL 的客户 A 绝不会让自己的订单数据流进客户 B 的库里。

映射到多仓场景：每个仓库就是一个"客户端"，3PL 总部或集团 IT 就是协调服务器。各仓的订单、SKU 结构、拣选节拍留在本地，只有模型参数在流动。顺带说一句，本地训练需要算力——很多仓的"AI 服务器"就是角落里一台带显卡的工作站，跑小模型够用，跑大了就得正经配边缘服务器。

整个过程打个比方：总部先发一套"标准答案模板"下去，各仓拿自己的单子练，练完不把卷子交上去，只交"我改了哪些题"；总部把大家的修改汇总成新版模板，再发下去。几十上百轮下来，模板越来越准，但谁的卷子长什么样，总部永远看不到。

多说一句，联邦学习分两种：一种是手机端那种，几百万台设备、谁掉线都行，学术上叫 cross-device；仓库这种是 cross-silo——参与方就几个、长期在线、算力可控。好消息是 cross-silo 稳定得多，不用操心设备掉线；坏消息是，参与方个个都是"大爷"，数据分布差异大、话语权也大，协调成本全在人身上。

仓库角落的边缘服务器机柜，为本地模型训练提供算力

这钱什么时候该花，什么时候是交学费

先讲值得花的三种情况。第一，多个数据主体，协议谈不拢：3PL 的多客户仓、集团跨区域的多个法人仓、品牌方和代工厂之间。数据合规或商业机密卡死了集中训练这条路，联邦学习是唯一能吃到"别人家数据红利"的办法。第二，各仓任务相同、数据互补：比如都是做拣选异常检测、到货量预测，A 仓旺季、B 仓淡季，凑在一起模型见过的世面更大。第三，数据不能出境或出库：医药、食品、高货值品类，合规直接把集中训练判了死刑。

再讲三种别碰的情况。第一，就一个仓，数据全在自己手里——直接集中训练，又快又便宜，上联邦学习纯属脱裤子放屁。第二，数据量太小：单仓一天几百单，联邦的通信和管理开销根本赚不回来。第三，各仓干的根本不是一回事：A 仓做需求预测、B 仓做视觉质检，硬凑一个模型两边都不准。学术上这叫 non-IID（非独立同分布），2018 年前后研究者就指出这是 FedAvg 的头号坑：仓与仓之间货品结构差太多，平均出来的模型可能还不如各仓自己训的。

判断标准就一句话：你的数据是不是"非用不可、但又出不来"？是，再谈联邦；不是，先把数据集中起来再说。

再算一笔账：联邦学习贵在哪？贵在三处——协调服务器和调度系统要有人搭、每轮模型同步要占带宽和算力、各仓的本地训练环境要有人运维。这三笔钱，集中训练一分都不用花。所以我的判断很直接：数据能集中，就别谈联邦；IT 团队连 WMS 升级都忙不过来的，也别谈联邦。这东西是给"数据出不来但又必须用"的场景准备的，不是给"想显得很 AI"的公司准备的。

医药行业有个现成的参照：2019 年，Amgen、AstraZeneca、Novartis 等 10 家互相竞争的药企凑在一起搞了个 MELLODDY 项目，用联邦学习联合训练药物研发模型，动用的实验数据点超过 26 亿个、化合物超过 2100 万个（项目公开发表的论文数据），谁的数据都没交出来。连死对头都能合作，3PL 的几个客户理论上也没问题——但人家花了三年搭平台，你掂量掂量自己的预算和耐心。

真要做，先过这几道坎

第一道坎，数据口径。联邦学习救不了脏数据。各仓的 SKU 编码规则、订单状态定义、时间戳时区，先对齐再谈训练。我见过最多的翻车是这个：模型在 A 仓学得好好的，到 B 仓发现"已拣货"和"已复核"居然是同一个字段值，模型直接学歪。

第二道坎，先小步试点。选一个具体任务——拣选异常检测、到货预测都行，两个仓先跑起来。开源框架有现成的，Flower、NVIDIA FLARE 都是开源的，自己搭个原型验证效果，别一上来就买商业平台。试点跑顺了，再谈扩到全网。

第三道坎，把"谁说了算"写进协议。模型归谁所有、更新频率多高、某个仓数据质量差拖了全局后腿怎么办、退出机制是什么。技术问题都有解，人的问题最难解，协议先行。

还有三个坑得提前知道。一是 non-IID，上文讲过，先做数据分布摸底，差异太大就别硬上。二是通信和运维：每轮训练都要同步模型，仓里的网络和边缘算力得跟上；小仓往往没专职 IT，模型挂了谁去看，这事得提前安排。三是别把安全神话了："只传模型更新"不等于绝对安全，学术界早就讨论过从梯度反推原始数据的风险。真有高敏感数据，加上差分隐私或安全聚合，别听销售吹"数据零泄露"。

还有个实操建议：模型从小开始。别一上来就训大模型，先拿轻量模型（比如简单的异常检测分类器）验证整条链路通不通——数据对齐、本地训练、模型聚合、效果评估，链路通了再换大模型。链路不通，大模型只会让你死得更贵。