做过联邦学习项目的人基本都会撞上同一个问题全局模型训出来之后换到各个客户端上效果并不稳定。举一个我自己踩过的例子某个业务场景里模型在服务端评测分数不错推到几家数据差异很大的终端后准确率直接掉了十几个点。不是模型结构有问题是客户端的数据分布和全局平均差得太远。这时候你会发现单纯追求一个共享的全局模型并不是所有场景的最优解。个性化联邦学习pFL就是为了解决这个矛盾出现的。现在圈子里讨论比较多的方案是FedProx、FedBN、pFedMe以及大模型时代越来越常见的LoRA-Adapter。这四类方法经常被放在一张表里比较但它们的思路、适用场景、工程成本完全不一样。网上讲原理的文章很多但真正落地时怎么选、怎么做、参数怎么调讲清楚的很少。这篇就按我实际项目的经验把选型逻辑和实操细节一次说透。1. 先想清楚你的场景到底需要什么1.1 联邦学习里的“个性化”到底指什么很多人第一次接触pFL容易把“个性化”理解成“每个客户端训一个不一样的模型”。这个理解不算错但不够准确。联邦学习的基础设定是多个客户端在不共享原始数据的前提下协同训练一个全局模型。传统联邦平均FedAvg的假设是虽然数据不上传但大家的数据分布大体相近合并训练能获得一个各方面都能用的统一模型。可现实业务里数据分布往往是非独立的也就是常说的non-IID。不同客户端的数据不仅数量不一样类别分布、特征分布都存在明显差异。个性化联邦学习的核心目标是在保留联邦协作收益的同时为每个客户端提供一个更贴近本地数据分布的模型版本。它有两条典型技术路线一条是把个性化信息嵌入到训练过程中改善全局模型在本地数据上的表现另一条是显式地在客户端维护一个独立于全局模型的个性化参数副本让全局模型和局部模型各司其职。pFL并不要求抛弃全局模型更多是围绕“全局主体 局部适配”这个结构做文章。理解这一点后面再看FedProx、pFedMe这些方案思路会清晰很多。1.2 四种方案的一句话定位先说结论四种方案的核心思想差异其实很大。FedProx可以看作FedAvg的加强版。它没有改变模型的共享方式依然只维护一个全局模型但通过一个近端项约束本地训练的参数更新幅度让每个客户端在本地数据上优化时不至于和全局模型偏离太远。它解决的是数据异构带来的不稳定性问题。FedBN的思路很巧妙它发现很多视觉任务模型里BatchNorm层的统计量非常依赖客户端本地的数据分布。于是它把BN层的参数留在本地不参与服务端聚合其余层正常联邦训练。这样既保留了BN在该客户端上的归一化能力又不破坏整体的协作训练。pFedMe是另一个极端思路的代表。它引入了Moreau包络的概念在优化目标里显式地把“个性化模型”和“全局模型”分开。每个客户端不仅训练一个本地专属模型还在训练中用这个专属模型去影响全局模型的聚合方向。最终每个客户端手里既有全局模型也有自己的一套个性化副本。LoRA-Adapter则是大模型时代的产物。它基于低秩分解的思想在预训练权重上新增少量可训练的低秩矩阵或适配模块Adapter训练时只更新这些轻量参数。在联邦场景下客户端上传和下载的都是小体积参数通信量大幅降低而且每个客户端可以保留自己调整后的LoRA作为个性化版本。用一张表对照更直观维度FedProxFedBNpFedMeLoRA-Adapter核心机制近端项约束本地更新BN层参数不定制聚合Moreau包络解耦双模型低秩矩阵 适配模块主要对付的异构标签分布异构、数量异构特征分布异构多种异构 强个性化需求资源受限 大模型场景客户端是否保留本地模型否只有全局模型保留BN层本地状态是显式个性化副本是可保留本地LoRA/Adapter通信成本与模型大小一致略低于全量与模型大小一致显著降低工程复杂度低低中中这个对比先放这看完后面的选型逻辑再回来看你会更清楚自己该选哪个。2. 选型决策四选一的完整判据2.1 按数据异质性类型选选型的第一步是判断你的非独立同分布到底是什么类型。如果异构主要体现在标签分布上也就是不同客户端拥有的样本类别比例严重不同比如有的客户端全是正样本有的客户端几乎全是负样本FedProx是优先考虑的方案。它的近端项天然能抑制客户端在本地少数类别上过拟合让更新方向更加稳定。我也在实验中验证过当客户端标签分布差异很大、且每轮参与训练的客户端数量有限时FedProx相对FedAvg有明显优势。如果异构主要体现在特征分布上比如不同客户端采集的图像风格、光照条件、传感器数值范围不同FedBN往往效果最好。原因是这类场景下网络的高层语义特征是共享的但底层特征的均值、方差差异很大而这恰好是BN层负责建模的。把BN层留在本地等于给每个客户端保留了适合自己的特征归一化参数。如果异构同时包含标签和特征且你希望每个客户端最终能拿到一个真正独立的本地模型pFedMe是更匹配的选择。它有显式的个性化模型可以同时应对多种类型的分布偏移。当然代价是训练流程更复杂超参数更多。这里要提醒一点不要先把所有方案都试一遍再决定。正确顺序是先做数据分布分析统计每个客户端的标签分布、特征均值方差、样本数量你就能很快排除掉明显不适用的方案。2.2 按模型架构选模型本身的结构会在很大程度上限制你能用哪种pFL方案。如果模型以卷积神经网络为主而且带有BatchNorm层FedBN几乎是零成本的改进。你只需要在服务端聚合时把BN层参数排除掉其他代码不用动。如果是Transformer类模型包括各类大语言模型、视觉TransformerFedBN基本没有用武之地因为这类结构里面没有传统意义上的BN层。大模型场景下要考虑的第一件事往往不是效果而是通信和显存。一个几亿参数的模型完整参数每轮上传下载的开销极大。这时候LoRA-Adapter就是更合理的选择。它的训练只更新很低维度的低秩矩阵参数总量可能是原来的百分之一甚至更少通信效率提升非常多。我自己做过的项目里有个跨平台图像分类任务模型是百亿参数规模的视觉Transformer跑传统FedAvg根本不现实每次同步都要传好几个GB。改成LoRA方案后单轮通信压缩到十几MB而且每个客户端可以保留一套自己的低秩矩阵天然实现了个性化。2.3 按工程约束选有些时候你的场景限制已经帮你把选项缩小了。如果客户端设备数量巨大计算能力和网络带宽参差不齐FedProx和FedBN相对友好。因为两者的训练流程和FedAvg几乎一致只是在优化目标或聚合逻辑上做了小改动对客户端的要求很低。pFedMe需要每个客户端额外维护个性化模型会增加一定的本地计算和存储负担。如果业务明确要求每个用户都有一个属于自己的模型版本比如推荐场景、个性化健康管理那优先级很明确pFedMe或者LoRA-Adapter。FedBN虽然能让模型在本地表现更好但它最终交付的还是同一个全局模型谈不上真正的独立个性化。如果服务器和客户端之间的通信带宽很紧张LoRA-Adapter几乎碾压其他三种方案。它不只是省流量还能让训练过程更容易在受限网络环境下跑起来。2.4 一个我常用的决策清单最后给你一个我在项目里反复使用的判断清单依次回答这些问题你更看重全局模型的泛化能力还是每个客户端的个体效果客户端的异构主要是哪类标签分布、特征分布、还是两者都有你使用的模型是否含有BN层或类似结构单轮通信传输完整模型参数是否可行每个客户端是否有足够的资源维护一份独立的个性化模型回答完之后大多数情况下选项会收敛到一个或两个方案。如果还是不确定我建议从FedProx做起它的改动最小、稳定性最好可以作为baseline如果在baseline上发现特征偏移影响明显再叠加FedBN做AB测试往往能快速得出结论。3. 核心原理与实操要点3.1 FedProxμ怎么调、本地epoch怎么设FedProx的核心改动在客户端。标准FedAvg的本地目标是直接最小化本地损失函数FedProx在此基础上加了一个近端项本地目标 本地损失 (μ / 2) × 本地参数与全局参数之差的二范数平方这个近端项的作用是让本地训练的参数更新不要离全局模型太远。μ就是控制这个约束强度的超参数。μ太小近端项约束力弱本地训练容易在异构数据上发生漂移退化成FedAvgμ太大本地参数基本不动联邦训练失去意义收敛速度会变得很慢。我建议从μ 0.01开始做敏感度测试分别在0.01、0.1、1.0三档下对比收敛曲线。实际项目中0.1到1.0区间是最常见的有效值。本地epoch的设置也需要配套调整。FedProx的论文里提出过一个不完整本地求解的概念意思是本地不需要把目标优化到完全收敛执行有限的本地步骤即可。实操中我的习惯是把本地迭代轮数控制在1到5之间。如果本地数据量大可以适当增加如果μ值偏大本地轮数不宜过多否则近端项的约束会被反复的本地更新稀释掉。常见的一个错误是只把FedProx当作调参手段其他设置全部照搬FedAvg。实际上适配μ之后本地学习率也经常需要下调。因为加了近端项参数更新的有效步长变大学习率不降就容易震荡。3.2 FedBNBN层的聚合细节与适用边界FedBN的做法在实现上非常简单服务端聚合时只对网络主体参数做加权平均BN层的scale和shift参数不从客户端收集。每个客户端训练完一轮后保留自己的BN层状态只上传其他层的参数。为什么这样有效因为BatchNorm的核心作用是对当前批次的特征做归一化它内部维护的running mean和running variance记录的是该客户端本地特征的统计信息。在特征偏移明显的场景下这些统计信息本身就是“个性化知识”。如果强行把它们和其他客户端平均会把每个客户端的特征分布拉到一个平均状态反而破坏了归一化的效果。需要特别注意BN层“统计量漂移”问题。即使在FedBN框架下本地模型的BN统计量也可能受训练数据波动影响变得不稳定。我处理这个问题的时候会考虑在数据量较小的客户端上对BN层做额外的统计量平滑或者采用更保守的动量系数。FedBN的适用边界我也要说明一下如果特征偏移间接地体现在标签语义上比如同一类物体在不同客户端具有完全不同的纹理那BN层帮不了你。此时问题已经影响到高层语义特征需要更复杂的个性化策略。3.3 pFedMe双模型解耦怎么训练pFedMe的思想和其他三种完全不同。它不是去约束一个全局模型而是让每个客户端维护一个显式的个性化模型并和全局模型建立关联。在pFedMe中每个客户端的目标函数包含本地损失和一个与全局模型关联的范数项。由于使用了Moreau包络个性化模型可以视为一个“近端近似”它在优化时既贴近本地数据也受全局模型的约束。每次通信时客户端不是直接上传个性化模型参数而是上传对全局模型的更新贡献服务端再聚合更新全局模型。训练流程大致分三步服务端下发全局模型。客户端在本地数据上优化自己的个性化模型并计算对全局模型的更新量。服务端聚合所有更新量更新全局模型客户端保留自己的个性化模型。这样的好处是全局模型和个性化模型都有了明确定义。每次推理时可以直接使用本地个性化模型服务端也不会因为客户端各自跑偏而崩塌。pFedMe的超参数比FedProx多。最重要的两个是λ控制个性化模型和全局模型的联系强度和个性化学习率。我的经验是λ先取一个中等值比如0.1再根据全局模型收敛速度和本地模型效果做调整。如果全局模型收敛慢说明λ太大约束太强如果全局模型精度不错但本地个性化模型精度不理想说明λ太小个性化不足。3.4 LoRA-Adapter通信成本与个性化实现LoRA的核心是把权重更新矩阵限制在低秩子空间。假设预训练权重为W可训练的增量参数写作ΔW A × BA和B的维度远小于原始矩阵训练时只更新A和B预训练权重冻结。Adapter的思路则是在Transformer层之间插入一个瓶颈结构。输入先降维到小维度经过激活函数后再升维回到原维度这个夹层结构只占总参数的很小比例但能有效适配下游任务。在联邦学习场景下LoRA-Adapter有两种常见用法。第一种是服务端共享基础模型客户端在本地用自己的数据微调LoRA/Adapter参数然后上传小体积增量参数做联邦平均最终产生一个全局增量的LoRA版本。这种用法适合需要统一部署的场景。第二种是每个客户端保留自己训练出的LoRA矩阵不参与聚合或者只聚合一部分形成个性化版本。这种用法适合强个性化需求。LoRA的秩r是最关键的参数。r太小低秩空间的表达能力不足模型难以拟合复杂的数据分布r太大通信压缩的效果被削弱个性化能力虽然变强却也容易过拟合。我在实际训练中通常从r 8开始观察验证集表现再按2倍步长递增或递减。Alpha参数的设置一般默认是r的倍数关系缩放LoRA更新的强度。还有一个实操细节联邦场景下不同客户端的低秩矩阵初始化方式要保持一致否则第一轮聚合时方向会彼此抵消。实践上每个客户端从同一个随机种子生成A矩阵或者统一从服务端下发初始化后的LoRA参数开始训练。4. 实操记录一份可直接参考的流程4.1 数据异构模拟用Dirichlet划分逼近真实分布做联邦学习实验第一步通常是构造non-IID数据。很多人直接用随机划分那得到的是IID数据测不出方案差异。这里的关键是用Dirichlet分布来控制每个客户端上的类别比例偏移。具体做法是为每个类别生成一个基于Dirichlet分布的样本分配概率向量再按概率把样本分配到各客户端。Dirichlet分布的浓度参数alpha控制样本分布的均匀程度。alpha很小的时候每个客户端只拥有极少数类别的样本异构性非常强alpha越大分布越接近均匀。在我实验里alpha 0.1大致对应强异构场景alpha 0.5对应中等异构alpha 5以上基本可以视为IID。如果你想对比FedAvg和其他pFL方案的差异建议从alpha 0.1这种高异构设置开始否则很容易因为数据太平滑而看不出区别。下面是一个用PyTorch风格写的数据划分示意。每个类别的样本先汇总再用Dirichlet采样得到分配比例矩阵完成客户端样本的分组。这里的关键是固定随机种子保证多次实验的可复现性。import numpy as np def partition_non_iid(labels, num_clients, alpha, seed42): rng np.random.default_rng(seed) classes np.unique(labels) client_indices [[] for _ in range(num_clients)] for cls in classes: class_indices np.where(labels cls)[0] # Dirichlet分布决定该类别在客户端间的分配比例 proportions rng.dirichlet(np.repeat(alpha, num_clients)) # 按比例将样本分配到各客户端 idx np.split(class_indices, (np.cumsum(proportions)[:-1] * len(class_indices)).astype(int)) for client_id in range(num_clients): client_indices[client_id].extend(idx[client_id].tolist()) return [np.array(indices) for indices in client_indices]如果alpha设置过小会出现某些客户端完全没有某个类别的样本。这时要注意像FedProx这类方案并不怕缺少某些类别但pFedMe可能需要额外关注类别缺失时的个性化模型过拟合风险。4.2 框架选型单机模拟联邦环境的搭建要点联邦实验最方便的做法是在单机上模拟多个客户端而不是真的部署多台设备。这样能快速验证算法有效性也方便调试。我习惯用PyTorch配合一个简单的客户端-服务端抽象层。每个客户端持有一份数据子集训练过程在一个循环里串行完成各客户端的本地更新再在服务端做聚合。为了模拟真实场景每轮只随机抽一部分客户端参与训练。服务端聚合的核心代码很简单就是对参与者传来的模型参数做加权平均。需要注意的是FedBN在聚合时要跳过BN层pFedMe要区分全局模型和个性化模型的结构LoRA-Adapter要单独维护低秩矩阵的聚合逻辑。写一个简易的FedProx客户端更新逻辑便于理解近端项的实现def prox_local_update(model, global_params, optimizer, dataloader, mu, local_epochs): model.train() for _ in range(local_epochs): for x, y in dataloader: optimizer.zero_grad() loss criterion(model(x), y) # 近端项当前本地参数与全局参数的差异惩罚 prox_term 0 for (name, p), g in zip(model.named_parameters(), global_params): prox_term (mu / 2) * ((p - g) ** 2).sum() loss loss prox_term loss.backward() optimizer.step()这个实现会引入额外的前向计算开销主要是近端项需要访问全局参数。更高效的做法是分别记录梯度把近端项的梯度直接加到反向传播后的梯度上但小规模实验用上面这种直观写法问题不大。4.3 关键超参数配置表不同的方案需要关注的超参数差别很大。我整理了一份自己常用的初始配置适合在中等规模模型如ResNet、小型Transformer上做联邦实验。方案超参数初始建议值调参提醒FedProxμ0.1如果loss曲线震荡调低μ如果收敛慢调高μFedProx本地epoch3异构强时减少到1-2防止本地过拟合FedBNBN统计量动量默认0.1数据量少的客户端可降低到0.05pFedMeλ0.1全局模型收敛慢时调低个性化不足时调高pFedMe客户端学习率0.01一般小于FedAvg的客户端学习率LoRA-Adapter秩r8按验证集效果调节注意通信量和精度平衡LoRA-AdapterAlpha缩放8默认与r一致或者r的整数倍还有一个往往被忽略的全局配置客户端学习率的调度方式。联邦训练里我倾向于在后续轮次逐步降低学习率而不是全程固定。否则训练后期容易出现精度在某个水平来回抖动。4.4 评估方法全局和本地分开看pFL实验的评估不能只盯着服务端聚合出来的全局模型精度。你真正关心的是每个客户端在本地数据上的表现这需要区分两种评估。全局模型评估用所有客户端数据的混合但仅用于测试不参与训练。这个指标反映联邦协作的总体成果适合对比FedAvg和FedProx这类不强调个性化的方案。本地个性化评估分别用每个客户端自己的测试数据评测该客户端最终使用的模型表现。对pFedMe和LoRA-Adapter这两种方案来说你评测的对象是客户端保留的个性化模型而不是服务端全局模型。如果只评测全局模型看不到pFedMe的个性化收益很容易得出错误结论。实际项目中我通常会额外对比“全局模型在本地测试集上的精度”和“个性化模型在本地测试集上的精度”。两者的差值能直观反映个性化方案带来的增益。有个项目里这个差值达到6个百分点这就说明个性化确实有必要做。5. 常见问题与排查技巧实录5.1 精度上不去时的快速排查顺序联邦实验出问题的原因比单机训练多很多。我总结了几个高频问题形成了一张排查表。现象可能原因排查手法所有方案都比FedAvg差数据划分不合理客户端样本太少增加客户端本地数据量检查alpha设置FedProx loss曲线震荡μ过大或者学习率过大降低μ或学习率观察前20轮的loss变化FedBN本地效果好但全局模型奇怪BN层聚合逻辑有问题检查服务端是否真的跳过了BN参数pFedMe全局模型收敛慢λ偏大个性化约束过强降低λ并增加通信轮数LoRA训练后过拟合秩r过大参与聚合的客户端太少减小r增加每轮客户端采样数排查时要一条条验证不要同时改多个变量。我最常用的策略是固定其他超参数只动一个变量然后记录前50轮的曲线。这样定位问题的效率最高。5.2 FedProx不收敛的经典原因我遇到过最多的情况是μ和学习率的耦合问题。FedProx的近端项会使本地更新步长变长如果学习率还是按FedAvg的经验值设置优化过程很容易发散。如果出现这种问题先不要急着动结构把学习率打个对折试试再观察损失曲线。另一个原因是客户端本地epoch设得太长。FedProx的前提是本地只做部分优化如果每个客户端都迭代到局部最优近端项的约束虽然存在但连续多步局部更新之后参数依然会偏离全局模型较远。很多实验复现不出FedProx的效果问题多半出在这。5.3 BN层在non-IID下的统计量漂移即使用了FedBN也不能完全忽略BN层统计量在异构数据下的漂移。表现是训练早期精度正常越到后期本地模型在测试集上的表现反而不如全局模型。这是因为本地训练过程中BN统计量会随着数据不断更新如果客户端本地数据量太小统计量会带有较大噪声。我的做法是在建立BN统计量的阶段固定模型其他参数只在本地数据上做一次小的统计量校准效果比直接跟着训练过程更新要好。5.4 LoRA秩选择与通信量权衡LoRA的最大优势是通信量小但它依然存在一个隐含风险如果每个客户端的个性化LoRA差异太大服务端聚合出来的通用LoRA效果会不稳定。这个问题的本质和FedAvg在non-IID下遇到的一样。实操上我建议先在服务端做一个通用LoRA的预训练再让客户端基于这个通用LoRA做个性化微调。这样客户端之间的初始差异小个性化后的版本也更容易在聚合时保持稳定。如果rank值超过64在常规任务上我基本不建议继续加大除非你确实遇到容量瓶颈。5.5 单机模拟实验的可复现性问题复现联邦实验结果最常见的问题是随机种子控制不到位。单机模拟中数据划分、客户端采样、模型初始化、数据加载顺序任何一个环节随机种子不一致结果都会偏。我会用一个统一的配置对象管理所有随机种子包括服务端和客户端的采样逻辑都固定下来。内存和显存的问题也值得注意。模拟很多客户端时效率瓶颈往往是数据加载和本地模型的反复初始化。我会提前把所有客户端的数据子集准备好避免每轮训练前重新分割。对显存吃紧的情况可以适当缩小批次大小而不是降低模型复杂度这样对算法效果的影响更小。最后再提醒一个点pFL实验务必每次记录每个客户端本地的评估指标不要只记录平均精度。只有保存了每个客户端的详细结果你才能分析出个性化方案在哪些客户端上受益、哪些客户端上甚至掉点后续调优才有依据。我自己就吃过只看平均精度的亏最后发现某个方案对大部分客户端有效但对少数几个数据量很小的客户端完全失效平均之后数值被掩盖了。做pFL选型不用追求最前沿合适就好。先把业务数据分布跑清楚再挑改动最小的方案做基线一步步加复杂度这条路最稳。 
长河君 · 2026/10/17 16:59:15 · 阅读 1.2k 联邦学习模型效果不稳定？个性化联邦学习（pFL）四大方案选型与实战指南
做过联邦学习项目的人基本都会撞上同一个问题全局模型训出来之后换到各个客户端上效果并不稳定。举一个我自己踩过的例子某个业务场景里模型在服务端评测分数不错推到几家数据差异很大的终端后准确率直接掉了十几个点。不是模型结构有问题是客户端的数据分布和全局平均差得太远。这时候你会发现单纯追求一个共享的全局模型并不是所有场景的最优解。个性化联邦学习pFL就是为了解决这个矛盾出现的。现在圈子里讨论比较多的方案是FedProx、FedBN、pFedMe以及大模型时代越来越常见的LoRA-Adapter。这四类方法经常被放在一张表里比较但它们的思路、适用场景、工程成本完全不一样。网上讲原理的文章很多但真正落地时怎么选、怎么做、参数怎么调讲清楚的很少。这篇就按我实际项目的经验把选型逻辑和实操细节一次说透。1. 先想清楚你的场景到底需要什么1.1 联邦学习里的“个性化”到底指什么很多人第一次接触pFL容易把“个性化”理解成“每个客户端训一个不一样的模型”。这个理解不算错但不够准确。联邦学习的基础设定是多个客户端在不共享原始数据的前提下协同训练一个全局模型。传统联邦平均FedAvg的假设是虽然数据不上传但大家的数据分布大体相近合并训练能获得一个各方面都能用的统一模型。可现实业务里数据分布往往是非独立的也就是常说的non-IID。不同客户端的数据不仅数量不一样类别分布、特征分布都存在明显差异。个性化联邦学习的核心目标是在保留联邦协作收益的同时为每个客户端提供一个更贴近本地数据分布的模型版本。它有两条典型技术路线一条是把个性化信息嵌入到训练过程中改善全局模型在本地数据上的表现另一条是显式地在客户端维护一个独立于全局模型的个性化参数副本让全局模型和局部模型各司其职。pFL并不要求抛弃全局模型更多是围绕“全局主体 局部适配”这个结构做文章。理解这一点后面再看FedProx、pFedMe这些方案思路会清晰很多。1.2 四种方案的一句话定位先说结论四种方案的核心思想差异其实很大。FedProx可以看作FedAvg的加强版。它没有改变模型的共享方式依然只维护一个全局模型但通过一个近端项约束本地训练的参数更新幅度让每个客户端在本地数据上优化时不至于和全局模型偏离太远。它解决的是数据异构带来的不稳定性问题。FedBN的思路很巧妙它发现很多视觉任务模型里BatchNorm层的统计量非常依赖客户端本地的数据分布。于是它把BN层的参数留在本地不参与服务端聚合其余层正常联邦训练。这样既保留了BN在该客户端上的归一化能力又不破坏整体的协作训练。pFedMe是另一个极端思路的代表。它引入了Moreau包络的概念在优化目标里显式地把“个性化模型”和“全局模型”分开。每个客户端不仅训练一个本地专属模型还在训练中用这个专属模型去影响全局模型的聚合方向。最终每个客户端手里既有全局模型也有自己的一套个性化副本。LoRA-Adapter则是大模型时代的产物。它基于低秩分解的思想在预训练权重上新增少量可训练的低秩矩阵或适配模块Adapter训练时只更新这些轻量参数。在联邦场景下客户端上传和下载的都是小体积参数通信量大幅降低而且每个客户端可以保留自己调整后的LoRA作为个性化版本。用一张表对照更直观维度FedProxFedBNpFedMeLoRA-Adapter核心机制近端项约束本地更新BN层参数不定制聚合Moreau包络解耦双模型低秩矩阵 适配模块主要对付的异构标签分布异构、数量异构特征分布异构多种异构 强个性化需求资源受限 大模型场景客户端是否保留本地模型否只有全局模型保留BN层本地状态是显式个性化副本是可保留本地LoRA/Adapter通信成本与模型大小一致略低于全量与模型大小一致显著降低工程复杂度低低中中这个对比先放这看完后面的选型逻辑再回来看你会更清楚自己该选哪个。2. 选型决策四选一的完整判据2.1 按数据异质性类型选选型的第一步是判断你的非独立同分布到底是什么类型。如果异构主要体现在标签分布上也就是不同客户端拥有的样本类别比例严重不同比如有的客户端全是正样本有的客户端几乎全是负样本FedProx是优先考虑的方案。它的近端项天然能抑制客户端在本地少数类别上过拟合让更新方向更加稳定。我也在实验中验证过当客户端标签分布差异很大、且每轮参与训练的客户端数量有限时FedProx相对FedAvg有明显优势。如果异构主要体现在特征分布上比如不同客户端采集的图像风格、光照条件、传感器数值范围不同FedBN往往效果最好。原因是这类场景下网络的高层语义特征是共享的但底层特征的均值、方差差异很大而这恰好是BN层负责建模的。把BN层留在本地等于给每个客户端保留了适合自己的特征归一化参数。如果异构同时包含标签和特征且你希望每个客户端最终能拿到一个真正独立的本地模型pFedMe是更匹配的选择。它有显式的个性化模型可以同时应对多种类型的分布偏移。当然代价是训练流程更复杂超参数更多。这里要提醒一点不要先把所有方案都试一遍再决定。正确顺序是先做数据分布分析统计每个客户端的标签分布、特征均值方差、样本数量你就能很快排除掉明显不适用的方案。2.2 按模型架构选模型本身的结构会在很大程度上限制你能用哪种pFL方案。如果模型以卷积神经网络为主而且带有BatchNorm层FedBN几乎是零成本的改进。你只需要在服务端聚合时把BN层参数排除掉其他代码不用动。如果是Transformer类模型包括各类大语言模型、视觉TransformerFedBN基本没有用武之地因为这类结构里面没有传统意义上的BN层。大模型场景下要考虑的第一件事往往不是效果而是通信和显存。一个几亿参数的模型完整参数每轮上传下载的开销极大。这时候LoRA-Adapter就是更合理的选择。它的训练只更新很低维度的低秩矩阵参数总量可能是原来的百分之一甚至更少通信效率提升非常多。我自己做过的项目里有个跨平台图像分类任务模型是百亿参数规模的视觉Transformer跑传统FedAvg根本不现实每次同步都要传好几个GB。改成LoRA方案后单轮通信压缩到十几MB而且每个客户端可以保留一套自己的低秩矩阵天然实现了个性化。2.3 按工程约束选有些时候你的场景限制已经帮你把选项缩小了。如果客户端设备数量巨大计算能力和网络带宽参差不齐FedProx和FedBN相对友好。因为两者的训练流程和FedAvg几乎一致只是在优化目标或聚合逻辑上做了小改动对客户端的要求很低。pFedMe需要每个客户端额外维护个性化模型会增加一定的本地计算和存储负担。如果业务明确要求每个用户都有一个属于自己的模型版本比如推荐场景、个性化健康管理那优先级很明确pFedMe或者LoRA-Adapter。FedBN虽然能让模型在本地表现更好但它最终交付的还是同一个全局模型谈不上真正的独立个性化。如果服务器和客户端之间的通信带宽很紧张LoRA-Adapter几乎碾压其他三种方案。它不只是省流量还能让训练过程更容易在受限网络环境下跑起来。2.4 一个我常用的决策清单最后给你一个我在项目里反复使用的判断清单依次回答这些问题你更看重全局模型的泛化能力还是每个客户端的个体效果客户端的异构主要是哪类标签分布、特征分布、还是两者都有你使用的模型是否含有BN层或类似结构单轮通信传输完整模型参数是否可行每个客户端是否有足够的资源维护一份独立的个性化模型回答完之后大多数情况下选项会收敛到一个或两个方案。如果还是不确定我建议从FedProx做起它的改动最小、稳定性最好可以作为baseline如果在baseline上发现特征偏移影响明显再叠加FedBN做AB测试往往能快速得出结论。3. 核心原理与实操要点3.1 FedProxμ怎么调、本地epoch怎么设FedProx的核心改动在客户端。标准FedAvg的本地目标是直接最小化本地损失函数FedProx在此基础上加了一个近端项本地目标 本地损失 (μ / 2) × 本地参数与全局参数之差的二范数平方这个近端项的作用是让本地训练的参数更新不要离全局模型太远。μ就是控制这个约束强度的超参数。μ太小近端项约束力弱本地训练容易在异构数据上发生漂移退化成FedAvgμ太大本地参数基本不动联邦训练失去意义收敛速度会变得很慢。我建议从μ 0.01开始做敏感度测试分别在0.01、0.1、1.0三档下对比收敛曲线。实际项目中0.1到1.0区间是最常见的有效值。本地epoch的设置也需要配套调整。FedProx的论文里提出过一个不完整本地求解的概念意思是本地不需要把目标优化到完全收敛执行有限的本地步骤即可。实操中我的习惯是把本地迭代轮数控制在1到5之间。如果本地数据量大可以适当增加如果μ值偏大本地轮数不宜过多否则近端项的约束会被反复的本地更新稀释掉。常见的一个错误是只把FedProx当作调参手段其他设置全部照搬FedAvg。实际上适配μ之后本地学习率也经常需要下调。因为加了近端项参数更新的有效步长变大学习率不降就容易震荡。3.2 FedBNBN层的聚合细节与适用边界FedBN的做法在实现上非常简单服务端聚合时只对网络主体参数做加权平均BN层的scale和shift参数不从客户端收集。每个客户端训练完一轮后保留自己的BN层状态只上传其他层的参数。为什么这样有效因为BatchNorm的核心作用是对当前批次的特征做归一化它内部维护的running mean和running variance记录的是该客户端本地特征的统计信息。在特征偏移明显的场景下这些统计信息本身就是“个性化知识”。如果强行把它们和其他客户端平均会把每个客户端的特征分布拉到一个平均状态反而破坏了归一化的效果。需要特别注意BN层“统计量漂移”问题。即使在FedBN框架下本地模型的BN统计量也可能受训练数据波动影响变得不稳定。我处理这个问题的时候会考虑在数据量较小的客户端上对BN层做额外的统计量平滑或者采用更保守的动量系数。FedBN的适用边界我也要说明一下如果特征偏移间接地体现在标签语义上比如同一类物体在不同客户端具有完全不同的纹理那BN层帮不了你。此时问题已经影响到高层语义特征需要更复杂的个性化策略。3.3 pFedMe双模型解耦怎么训练pFedMe的思想和其他三种完全不同。它不是去约束一个全局模型而是让每个客户端维护一个显式的个性化模型并和全局模型建立关联。在pFedMe中每个客户端的目标函数包含本地损失和一个与全局模型关联的范数项。由于使用了Moreau包络个性化模型可以视为一个“近端近似”它在优化时既贴近本地数据也受全局模型的约束。每次通信时客户端不是直接上传个性化模型参数而是上传对全局模型的更新贡献服务端再聚合更新全局模型。训练流程大致分三步服务端下发全局模型。客户端在本地数据上优化自己的个性化模型并计算对全局模型的更新量。服务端聚合所有更新量更新全局模型客户端保留自己的个性化模型。这样的好处是全局模型和个性化模型都有了明确定义。每次推理时可以直接使用本地个性化模型服务端也不会因为客户端各自跑偏而崩塌。pFedMe的超参数比FedProx多。最重要的两个是λ控制个性化模型和全局模型的联系强度和个性化学习率。我的经验是λ先取一个中等值比如0.1再根据全局模型收敛速度和本地模型效果做调整。如果全局模型收敛慢说明λ太大约束太强如果全局模型精度不错但本地个性化模型精度不理想说明λ太小个性化不足。3.4 LoRA-Adapter通信成本与个性化实现LoRA的核心是把权重更新矩阵限制在低秩子空间。假设预训练权重为W可训练的增量参数写作ΔW A × BA和B的维度远小于原始矩阵训练时只更新A和B预训练权重冻结。Adapter的思路则是在Transformer层之间插入一个瓶颈结构。输入先降维到小维度经过激活函数后再升维回到原维度这个夹层结构只占总参数的很小比例但能有效适配下游任务。在联邦学习场景下LoRA-Adapter有两种常见用法。第一种是服务端共享基础模型客户端在本地用自己的数据微调LoRA/Adapter参数然后上传小体积增量参数做联邦平均最终产生一个全局增量的LoRA版本。这种用法适合需要统一部署的场景。第二种是每个客户端保留自己训练出的LoRA矩阵不参与聚合或者只聚合一部分形成个性化版本。这种用法适合强个性化需求。LoRA的秩r是最关键的参数。r太小低秩空间的表达能力不足模型难以拟合复杂的数据分布r太大通信压缩的效果被削弱个性化能力虽然变强却也容易过拟合。我在实际训练中通常从r 8开始观察验证集表现再按2倍步长递增或递减。Alpha参数的设置一般默认是r的倍数关系缩放LoRA更新的强度。还有一个实操细节联邦场景下不同客户端的低秩矩阵初始化方式要保持一致否则第一轮聚合时方向会彼此抵消。实践上每个客户端从同一个随机种子生成A矩阵或者统一从服务端下发初始化后的LoRA参数开始训练。4. 实操记录一份可直接参考的流程4.1 数据异构模拟用Dirichlet划分逼近真实分布做联邦学习实验第一步通常是构造non-IID数据。很多人直接用随机划分那得到的是IID数据测不出方案差异。这里的关键是用Dirichlet分布来控制每个客户端上的类别比例偏移。具体做法是为每个类别生成一个基于Dirichlet分布的样本分配概率向量再按概率把样本分配到各客户端。Dirichlet分布的浓度参数alpha控制样本分布的均匀程度。alpha很小的时候每个客户端只拥有极少数类别的样本异构性非常强alpha越大分布越接近均匀。在我实验里alpha 0.1大致对应强异构场景alpha 0.5对应中等异构alpha 5以上基本可以视为IID。如果你想对比FedAvg和其他pFL方案的差异建议从alpha 0.1这种高异构设置开始否则很容易因为数据太平滑而看不出区别。下面是一个用PyTorch风格写的数据划分示意。每个类别的样本先汇总再用Dirichlet采样得到分配比例矩阵完成客户端样本的分组。这里的关键是固定随机种子保证多次实验的可复现性。import numpy as np def partition_non_iid(labels, num_clients, alpha, seed42): rng np.random.default_rng(seed) classes np.unique(labels) client_indices [[] for _ in range(num_clients)] for cls in classes: class_indices np.where(labels cls)[0] # Dirichlet分布决定该类别在客户端间的分配比例 proportions rng.dirichlet(np.repeat(alpha, num_clients)) # 按比例将样本分配到各客户端 idx np.split(class_indices, (np.cumsum(proportions)[:-1] * len(class_indices)).astype(int)) for client_id in range(num_clients): client_indices[client_id].extend(idx[client_id].tolist()) return [np.array(indices) for indices in client_indices]如果alpha设置过小会出现某些客户端完全没有某个类别的样本。这时要注意像FedProx这类方案并不怕缺少某些类别但pFedMe可能需要额外关注类别缺失时的个性化模型过拟合风险。4.2 框架选型单机模拟联邦环境的搭建要点联邦实验最方便的做法是在单机上模拟多个客户端而不是真的部署多台设备。这样能快速验证算法有效性也方便调试。我习惯用PyTorch配合一个简单的客户端-服务端抽象层。每个客户端持有一份数据子集训练过程在一个循环里串行完成各客户端的本地更新再在服务端做聚合。为了模拟真实场景每轮只随机抽一部分客户端参与训练。服务端聚合的核心代码很简单就是对参与者传来的模型参数做加权平均。需要注意的是FedBN在聚合时要跳过BN层pFedMe要区分全局模型和个性化模型的结构LoRA-Adapter要单独维护低秩矩阵的聚合逻辑。写一个简易的FedProx客户端更新逻辑便于理解近端项的实现def prox_local_update(model, global_params, optimizer, dataloader, mu, local_epochs): model.train() for _ in range(local_epochs): for x, y in dataloader: optimizer.zero_grad() loss criterion(model(x), y) # 近端项当前本地参数与全局参数的差异惩罚 prox_term 0 for (name, p), g in zip(model.named_parameters(), global_params): prox_term (mu / 2) * ((p - g) ** 2).sum() loss loss prox_term loss.backward() optimizer.step()这个实现会引入额外的前向计算开销主要是近端项需要访问全局参数。更高效的做法是分别记录梯度把近端项的梯度直接加到反向传播后的梯度上但小规模实验用上面这种直观写法问题不大。4.3 关键超参数配置表不同的方案需要关注的超参数差别很大。我整理了一份自己常用的初始配置适合在中等规模模型如ResNet、小型Transformer上做联邦实验。方案超参数初始建议值调参提醒FedProxμ0.1如果loss曲线震荡调低μ如果收敛慢调高μFedProx本地epoch3异构强时减少到1-2防止本地过拟合FedBNBN统计量动量默认0.1数据量少的客户端可降低到0.05pFedMeλ0.1全局模型收敛慢时调低个性化不足时调高pFedMe客户端学习率0.01一般小于FedAvg的客户端学习率LoRA-Adapter秩r8按验证集效果调节注意通信量和精度平衡LoRA-AdapterAlpha缩放8默认与r一致或者r的整数倍还有一个往往被忽略的全局配置客户端学习率的调度方式。联邦训练里我倾向于在后续轮次逐步降低学习率而不是全程固定。否则训练后期容易出现精度在某个水平来回抖动。4.4 评估方法全局和本地分开看pFL实验的评估不能只盯着服务端聚合出来的全局模型精度。你真正关心的是每个客户端在本地数据上的表现这需要区分两种评估。全局模型评估用所有客户端数据的混合但仅用于测试不参与训练。这个指标反映联邦协作的总体成果适合对比FedAvg和FedProx这类不强调个性化的方案。本地个性化评估分别用每个客户端自己的测试数据评测该客户端最终使用的模型表现。对pFedMe和LoRA-Adapter这两种方案来说你评测的对象是客户端保留的个性化模型而不是服务端全局模型。如果只评测全局模型看不到pFedMe的个性化收益很容易得出错误结论。实际项目中我通常会额外对比“全局模型在本地测试集上的精度”和“个性化模型在本地测试集上的精度”。两者的差值能直观反映个性化方案带来的增益。有个项目里这个差值达到6个百分点这就说明个性化确实有必要做。5. 常见问题与排查技巧实录5.1 精度上不去时的快速排查顺序联邦实验出问题的原因比单机训练多很多。我总结了几个高频问题形成了一张排查表。现象可能原因排查手法所有方案都比FedAvg差数据划分不合理客户端样本太少增加客户端本地数据量检查alpha设置FedProx loss曲线震荡μ过大或者学习率过大降低μ或学习率观察前20轮的loss变化FedBN本地效果好但全局模型奇怪BN层聚合逻辑有问题检查服务端是否真的跳过了BN参数pFedMe全局模型收敛慢λ偏大个性化约束过强降低λ并增加通信轮数LoRA训练后过拟合秩r过大参与聚合的客户端太少减小r增加每轮客户端采样数排查时要一条条验证不要同时改多个变量。我最常用的策略是固定其他超参数只动一个变量然后记录前50轮的曲线。这样定位问题的效率最高。5.2 FedProx不收敛的经典原因我遇到过最多的情况是μ和学习率的耦合问题。FedProx的近端项会使本地更新步长变长如果学习率还是按FedAvg的经验值设置优化过程很容易发散。如果出现这种问题先不要急着动结构把学习率打个对折试试再观察损失曲线。另一个原因是客户端本地epoch设得太长。FedProx的前提是本地只做部分优化如果每个客户端都迭代到局部最优近端项的约束虽然存在但连续多步局部更新之后参数依然会偏离全局模型较远。很多实验复现不出FedProx的效果问题多半出在这。5.3 BN层在non-IID下的统计量漂移即使用了FedBN也不能完全忽略BN层统计量在异构数据下的漂移。表现是训练早期精度正常越到后期本地模型在测试集上的表现反而不如全局模型。这是因为本地训练过程中BN统计量会随着数据不断更新如果客户端本地数据量太小统计量会带有较大噪声。我的做法是在建立BN统计量的阶段固定模型其他参数只在本地数据上做一次小的统计量校准效果比直接跟着训练过程更新要好。5.4 LoRA秩选择与通信量权衡LoRA的最大优势是通信量小但它依然存在一个隐含风险如果每个客户端的个性化LoRA差异太大服务端聚合出来的通用LoRA效果会不稳定。这个问题的本质和FedAvg在non-IID下遇到的一样。实操上我建议先在服务端做一个通用LoRA的预训练再让客户端基于这个通用LoRA做个性化微调。这样客户端之间的初始差异小个性化后的版本也更容易在聚合时保持稳定。如果rank值超过64在常规任务上我基本不建议继续加大除非你确实遇到容量瓶颈。5.5 单机模拟实验的可复现性问题复现联邦实验结果最常见的问题是随机种子控制不到位。单机模拟中数据划分、客户端采样、模型初始化、数据加载顺序任何一个环节随机种子不一致结果都会偏。我会用一个统一的配置对象管理所有随机种子包括服务端和客户端的采样逻辑都固定下来。内存和显存的问题也值得注意。模拟很多客户端时效率瓶颈往往是数据加载和本地模型的反复初始化。我会提前把所有客户端的数据子集准备好避免每轮训练前重新分割。对显存吃紧的情况可以适当缩小批次大小而不是降低模型复杂度这样对算法效果的影响更小。最后再提醒一个点pFL实验务必每次记录每个客户端本地的评估指标不要只记录平均精度。只有保存了每个客户端的详细结果你才能分析出个性化方案在哪些客户端上受益、哪些客户端上甚至掉点后续调优才有依据。我自己就吃过只看平均精度的亏最后发现某个方案对大部分客户端有效但对少数几个数据量很小的客户端完全失效平均之后数值被掩盖了。做pFL选型不用追求最前沿合适就好。先把业务数据分布跑清楚再挑改动最小的方案做基线一步步加复杂度这条路最稳。