1. 联邦学习里的“异构”到底卡在哪
这几年做分布式机器学习的人，几乎人手一个逃不开的话题就是联邦学习。大家一开始接触它，多半是被“数据不动模型动”这个理念吸引——数据留在本地，只把模型参数或者梯度传到中心，既能做联合建模，又不用把原始数据集中起来。听起来很完美，但真上手跑过几轮实验的人都知道，理想和现实之间隔着两座大山：一座叫数据异构，一座叫模型异构。
数据异构是大家最先遇到的。每个参与方的数据分布不一样，有的客户端样本多、有的样本少，有的类别分布偏得厉害。这种情况下，如果强行让大家共享一个全局模型，效果往往不理想——本地数据长得跟别人不一样，凭什么用一个统一的模型去适配所有人？所以后来有了个性化联邦学习，大意是每个客户端在共享知识的基础上，保留一部分自己专属的参数，这样就兼顾了“全局共性”和“本地个性”。
但模型异构这个问题，很多人是一开始没意识到的。它说的是：每个客户端能不能用不同的模型结构？有的客户端设备算力强，跑得动大模型；有的客户端就是嵌入式设备或者手机，只能塞下一个小网络。传统联邦学习的基本前提是“大家模型结构一致”，否则参数怎么聚合？这一下就把模型异构这条路堵死了。
我最初看到pFedES这个标题的时候，心里第一反应是：总算有人把“模型异构”和“个性化”放在一起认真做了。全称拆开来看，Generalized Proxy Feature Extractor Sharing，广义的代理特征提取器共享。核心思路很明确——你们各自的模型结构可以不一样，但大家想办法共享一层“代理特征提取器”，用它来做知识交流，然后再各自组装自己的模型。这个概念有点像不同国家的人说的语言不同，但大家约定好一个统一的“翻译中转站”，先把各自的意思转成标准格式，再进行沟通。这样一来，模型结构不一样，也不影响信息交换。
这篇文章适合谁看？如果你正在做联邦学习相关的项目，或者你被“模型异构”这个问题困扰过——不管你是刚入门的算法工程师、研究生，还是已经有一定经验的分布式机器学习从业者，这篇文章都能帮你把pFedES的脉络理清楚。我会从问题拆解、方案设计、核心机制、实现细节到应用场景，一层层剥开讲，尽量用工程化的语言说人话。
2. 为什么模型异构是个“硬骨头”
2.1 传统联邦学习隐含的“同构假设”
联邦学习最经典的框架，大家都很熟了：中心服务端下发一个全局模型，各客户端在本地用自身数据训练，然后把更新后的模型参数传回服务端，服务端做加权平均（典型的就是FedAvg），再下发新一轮的全局模型。整个闭环能跑起来，隐含着一个非常关键的前提——所有客户端的模型结构必须完全一致。因为参数聚合的本质是“相同位置参数相加取平均”，如果你的网络是四层卷积，我的是两层全连接，参数根本对不上，FedAvg就直接崩掉了。
这个“同构假设”在实验室环境里很方便，大家用同一个模型跑通流程就行。但放到真实业务场景里，问题就来了。举个例子，假设你在做一个移动端的用户行为预测任务，用户的手机型号五花八门。高端机跑得动ResNet这种大网络，中低端机跑起来就卡得不行。你不可能强制所有设备都用同一个大模型，那样低端设备根本跑不动；你也不可能为了迁就低端设备，让所有客户端都退化到小的模型结构，那样高端设备的算力就白白浪费了。
这就是模型异构的诉求：允许每个客户端根据自己的硬件条件、数据特点，选择不同的模型结构，同时还能从整个联邦协作中获益。模型异构和前面说的数据异构还不一样。数据异构是说大家用的模型一样，但数据分布不同；模型异构是说大家的模型结构本身就不一样。两者可以同时存在，也可以单独出现，但处理起来难度完全不同。
2.2 模型异构为什么比数据异构更难搞
数据异构的解法相对成熟，核心思路是“一部分共享，一部分个性化”。比如你可以在模型前面几层用共享层，后面几层留给客户端自己微调；也可以用正则化手段约束本地模型和全局模型不要偏离太远。这些方法背后的逻辑都是：模型结构还是统一的，只是参数在“共性与个性”之间做分配。
但模型异构一出现，连“共享”这个动作都变得困难了。你的网络层数、卷积核大小、通道数都和我不同，我们俩之间根本没有能直接对应的参数。从数学上讲，两个不同结构的模型分布在不同参数空间里，空间都不一样，你怎么做平均？
有人可能会想，那我不做参数聚合了，改成“知识蒸馏”那种思路行不行？确实，有一类方法就是走这条路的——利用公共数据集或者生成的数据，让不同结构的模型之间相互学习。通过蒸馏的方式传递知识。但这又带来了新的问题：公共数据集从哪来、谁来生成、数据质量和隐私怎么保证？而且蒸馏过程如果控制不好，容易传递噪音知识，客户端之间的“个性”也容易被抹平。
pFedES走的路线，其实是把“参数聚合”和“知识蒸馏”搭了个桥。它不直接聚合模型参数，也不依赖公共数据集，而是引入一个可学习的、结构统一的“代理特征提取器”，承担知识交流的职能。这个代理特征提取器相当于一个通用的特征表示空间，每个客户端都把自己的数据映射到这个空间里，提取出“标准格式”的特征，再交给各自不同的本地模型去处理。这样一来，知识共享发生在特征层面，而不是参数层面，模型结构的不一致就被“绕过去”了。
3. pFedES的设计思路：代理特征提取器到底在做什么
3.1 用一个共享的“代理”解决结构不一致
pFedES的核心，是引入了一个称作“代理特征提取器”的模块。这个模块从结构上看，本身是一个统一的神经网络——如果你搞过ResNet、MobileNet这类特征提取网络，大概能猜到它的形态：一堆卷积层加池化层，输出是一个低维的特征向量。关键是，这个提取器是所有客户端共享的、全局维护的，每个客户端都依赖它把原始输入转换成特征表示。
我拿生活里的例子打个比方。假设你是一家跨国公司的员工，你在本地部门用自己习惯的方式干活，但需要跟总部和其他分公司沟通时，必须把工作报告翻译成统一的英文格式。这个“英文格式”就是代理特征提取器，它保证大家递交上来的材料都是同一套规范。至于你拿到这个标准报告之后，是用Excel分析还是用Python分析，那就是你本地的事情了。
放到pFedES里，客户端画像大概是这样的：输入数据先经过代理特征提取器，得到一份“标准特征”；然后这份特征进入客户端自己的本地模型，由本地模型完成最终的预测。代理特征提取器在中心维护，本地模型在各自客户端维护。这就形成了一个“共享特征底座 + 私有任务头”的组合。
这里有个容易混淆的点，需要特别说明一下。很多人一听“特征提取器共享”，会误以为它和传统联邦学习的全局模型是一回事。差得远。传统全局模型是完整模型，直接做预测；代理特征提取器只是一个中间层，它不输出最终结果，只负责生成特征。本地模型的预测结果和代理特征提取器本身是没有直接对应关系的，两者各司其职。
3.2 客户端到代理，再到客户端：信息流通的路径
要理解pFedES，最关键的是想清楚知识在客户端和代理之间的流动路径。我梳理完整流程之后发现，它的信息流并不复杂，大致可以分成三条线：
第一条，客户端到代理的“特征上传”线。每个客户端在自己的数据上训练时，会把输入数据投喂给代理特征提取器，产出特征表示。这个过程可以被理解为“用全局共享的透镜来看本地数据”，透镜是同一个，看到的东西却带有本地色彩。
第二条，代理聚合更新的“全局修正”线。代理特征提取器不只是一个静态模块，它也会在联邦训练中被迭代更新。客户端在本地训练时会产生梯度，这些梯度会回传到服务端，服务端用它们来更新代理特征提取器。这一步保证代理特征提取器不只反映某一家的数据偏好，而是融合了所有客户端的知识，成为一个真正的“公共底座”。
第三条，代理到客户端的“特征反馈”线。代理特征提取器更新完之后，新一轮训练中客户端继续用它来处理本地数据。这实际上是间接地让所有客户端共享了其他参与方的知识——你处理特征的方式，已经包含了别人带来的信息。
这三条线绕成一个循环，跟传统联邦学习的“下发全局模型、上传本地更新”逻辑有点类似，但聚合的对象从“完整模型”变成了“特征提取器”，传递的东西也从“参数”变成了“特征表示”。这种设计的高明之处在于：它把知识共享压缩到了一个相对小的模块上，不需要客户端的模型结构对齐，自然就兼容了模型异构。
3.3 本地模型和代理特征提取器是怎么配合的
前面说了信息流的大框架，接下来要落到具体结构上。pFedES中每个客户端的完整模型，可以拆成三块看：特征输入部分、代理特征提取器、本地专属模型。
实际实现中，本地完整的前向传播是：原始输入 → 代理特征提取器 → 本地专属模型 → 预测输出。这里的代理特征提取器对所有客户端都用同一个参数复本。本地专属模型就五花八门了，你可以这边用两层全连接，那边用三层卷积加注意力，完全不受限制。
我画过一遍数据流就意识到，这个结构的自由度其实很高。代理特征提取器可以选得很小——甚至可以只是两三层卷积或者一个中型全连接网络。本地模型可以选得很大——你可以在资源允许的情况下堆很深的网络。关键是，代理特征提取器和本地模型之间的接口一定要对齐。接口是什么？就是特征向量的维度。你的代理提取器输出的特征向量是多维的，本地模型的输入就必须匹配这个维度。
这里有个设计上的细节值得注意：为了不让代理特征提取器的结构成为客户端模型结构的瓶颈，它的输出维度最好设得适中，既别太大导致通讯开销失控，也别太小导致信息瓶颈严重。我见到的一些实践里，这个维度设在64到256之间比较常见，具体要看数据集的复杂度。数据丰富、类别多的任务，特征瓶颈卡太小的话，信息会损失得很厉害。
4. 训练流程逐段拆解：pFedES是怎么跑起来的
4.1 服务端和客户端各自要干什么
把pFedES的训练流程摊开看，其实边界很清楚：服务端只负责任务调度和代理特征提取器的聚合更新，客户端负责本地模型和代理提取器相关的梯度计算与局部更新。
整个联邦训练是分轮进行的。每一轮开始，服务端把最新的代理特征提取器参数发给所有被采样的客户端。每个客户端接收到之后，先做本地初始化：把代理特征提取器参数加载到本地，然后和本地已有的专属模型拼接成一个完整的网络。这时候你就可以正常在本地数据上做前向传播和反向传播了。
我在本地复现这个流程的时候，最直观的感受是：pFedES的本地训练过程和普通深度学习训练几乎没有区别。它不需要像FedAvg那样处理参数平均的步骤，因为你本地网络的反向传播是完整的，梯度可以直接从损失函数一层层传回来。唯一需要注意的是，反向传播到代理特征提取器那一段时，产生的梯度是会被收集起来的——因为这个梯度要送回服务端，用来更新全局的代理特征提取器。
等到本地训练完若干轮之后，客户端把两部分东西传回服务端。一部分是代理特征提取器的梯度（或者更新后的参数），另一部分是本地模型的更新信息。服务端拿到梯度后，对所有参与的客户端做加权平均，更新全局代理特征提取器。但本地模型呢？这里是个关键决策点——服务端不会去聚合本地模型，因为大家结构都不一样，根本没法聚合。本地模型只更新、只本地保留，下一轮训练时继续沿用。
我不是论文作者，但根据该方法的命名和这类工作的通用做法，我推测完整训练流程大致可以总结如下：服务端维护代理特征提取器；每轮挑一部分客户端参与；客户端本地联合训练代理提取器和本地模型；回传代理提取器的梯度；服务端聚合更新代理提取器；循环往复。如果你觉得这个流程还不够细，我建议你结合自己的任务画一个流程图，边画边想每一步的输入输出，会清晰很多。
4.2 损失函数和优化的关键思考
损失函数这一块，不同论文在具体实现上会有差异，但pFedES这类方法通常会考虑两部分：一部分是常规的监督学习损失，比如分类任务用交叉熵；另一部分是知识蒸馏或者特征对齐相关的损失，用来拉近本地模型和代理特征提取器之间的表示。
为什么要加这部分损失？原因也很实际——如果只靠监督损失训练，代理特征提取器可能更偏向于“服务”当前这批客户端的本地模型，而忽略了对全局知识的建模。加上对齐损失之后，等于加了条约束：代理特征提取器提炼出来的特征表示，不能只在单一模型上好用，必须在不同结构的本地模型上都有效。这就逼着它学那些更通用、更本质的特征。
本地模型的更新逻辑也要多说一句。因为本地模型不参与服务端聚合，它完全是在本地数据上优化出来的。数据充足的客户端，本地模型会更“自信”；数据量少的客户端，本地模型会更依赖代理特征提取器输出特征的表达力。从某种意义上说，代理特征提取器对弱势客户端是一种补充，“你本地数据不够没关系，特征提取的部分我们大家帮你学好了”。
优化器这块，服务端和客户端可以分开设置。客户端推荐用SGD或者Adam，带动量更好，本地训练多少轮之后梯度会更稳定。服务端更新代理特征提取器时，通常直接用简单的加权平均就行，也可以用带学习率的聚合方式，类似FedAvg的动量更新，防止代理提取器参数在早期震荡太厉害。
4.3 一轮完整训练的时间线
为了方便新手理解，我按时间顺序给一轮完整的pFedES训练画个清单，你照着这个顺序去实现，基本不会乱：
- 服务端广播最新的代理特征提取器参数给本轮参与客户端。
- 客户端收到参数后，加载代理提取器，和本地专属模型拼接。
- 客户端在本地数据上跑若干个batch，每个batch都计算监督损失和对齐损失，反向传播更新本地模型参数，同时保存代理提取器对应的梯度。
- 本地训练结束后，客户端把代理提取器的梯度打包上传，本地模型参数留着自己用。
- 服务端收集所有参与客户端的代理提取器梯度，加权平均后更新全局代理特征提取器。
- 新一轮开始，服务端把更新后的代理提取器广播给下一批客户端。
整个流程里最核心的点就一句话：共享模块（代理特征提取器）参与服务端聚合，私有模块（本地模型）完全不参与聚合。只要把握住这个原则，后面的实现细节都好说。
5. 复现过程中的关键细节与避坑经验
5.1 模型结构选择：代理提取器不是越大越好
复现pFedES，第一步卡住你的多半是网络结构怎么选。我踩过的第一个坑就是把代理特征提取器设计得太大。当时我的直觉是，共享模块越大，表达力越强，学到的特征肯定更好。结果跑起来发现通讯开销剧增，而且由于代理提取器本身是全局共享的，它一旦太大，更新所需的客户端梯度就多，收敛速度反而变慢。
后来我把代理特征提取器缩小，只保留基本的卷积层加池化结构，问题立刻缓解了很多。我也理解了这个设计的本质：代理特征提取器的定位是“通用翻译器”，它不是最终任务的承担者，没必要做大。真正负责任务精度的，是每个客户端的本地模型。资源充足的客户端完全可以把本地模型做大做深，不影响别人。
这里给一个我在实验里觉得比较合理的配置参考：在CIFAR-10这类中等规模图像数据集上，代理特征提取器可以用两三层卷积加一个全局池化，输出特征维度设为128。本地模型可以是一个更深的卷积网络或者简单的MLP，取决于你想模拟的异构程度。
注意：代理特征提取器的输出维度需要和所有客户端本地模型的输入维度对齐。这个维度是一个全局统一约定，改的时候要同步改所有端。
5.2 客户端采样率和异构程度的平衡
联邦学习的训练效率跟每轮参与客户端数量强相关。pFedES因为共享的是特征提取器，对客户端采样率其实还挺敏感的。采样率太低，代理特征提取器每轮看到的客户端太少，学到的“公共知识”容易被少数客户端带偏。采样率太高，通讯压力又上来了。
我的经验是，如果客户端总量在100左右，每轮采样20到30个是比较稳的区间。这个数值不是拍脑袋定的，它要保证代理特征提取器每次更新都能看到足够多样的数据分布。如果不同客户端的数据分布差异很大，采样率保守一点反而更好，因为每次更新引入的噪声会小一些。
异构程度也要控制。我见过一些同学第一次做模型异构实验，直接把各客户端的模型设计得形态差异极大——有的是纯卷积、有的是纯全连接、有的是Transformer结构。理论上模型异构是允许这样的，但实际上如果代理特征提取器的输出特征被喂给差异过大的下游结构，本地模型的优化难易程度会差很多，整体收敛会变慢。建议异构程度循序渐进，先做“结构类似但深度不同”的异构，再做“结构差异明显”的异构。
5.3 通信成本：传梯度还是传参数，怎么选
pFedES中，客户端传回的代理特征提取器更新，有两种常见形式：传梯度或者传参数。从带宽角度看，两者量级差不多，但传梯度的好处是服务端可以用累积梯度的方式做更平滑的聚合，不会直接受客户端参数值噪声影响。
实际工程中，如果代理特征提取器本身不大，传参数也完全可以。传参数更简单，服务端直接加权平均就行。但如果你追求更稳的收敛表现，建议传梯度，并且在服务端对聚合梯度做一次clip，防止个别客户端上传的梯度范数太大，把共享特征提取器带飞。
压缩和稀疏化技术也可以用在通讯上。比如传梯度时可以只传幅度最大的5%的位置，其余丢弃，这对训练效果影响很小。这也是工业界落地联邦学习常用的小技巧——通讯开销大，能省一点是一点，代理特征提取器这种小模块尤其适合。
5.4 一个容易忽略的细节：特征分布标准化
联邦学习里最隐蔽的坑，就是特征分布不一致。客户端A的数据整体偏亮，客户端B的数据整体偏暗，代理特征提取器对A学到的特征统计量和B差异很大。这种情况下，即便模型结构没问题，共享特征提取器的优化也会很挣扎。
应对办法很简单，也很有用：在代理特征提取器输出到本地模型输入之间，加一个标准化层。BatchNorm效果不一定好，因为客户端样本量小，统计量不准；更推荐用LayerNorm或者InstanceNorm这种和样本batch大小无关的归一化方式。
我自己在复现时，就在接口处加了一个可学习的LayerNorm，效果立竿见影，尤其客户端数据分布差异明显的场景，收敛稳了很多。这种做法在论文里不一定会给你大讲特讲，但工程落地时几乎必备。
6. pFedES和几个经典方案的血缘与分歧
6.1 与FedPer、FedBN、FedMD这些方案摆在一起看
既然pFedES解决的是模型异构下的个性化联邦学习，就有必要把它和几个相似的经典思路摆在一起对比，不然光看孤立的方法容易搞不清它的位置。
先看FedPer。FedPer的思路是“共享特征提取层 + 个性化分类层”，客户端之间的特征提取层是共享的，分类层是各搞各的。它和pFedES的相似之处是都有“共享 + 私有”的结构，但FedPer要求共享的特征提取层在所有客户端结构完全一致，本质上还是同构联邦，只不过保留了头部个性化。pFedES则连特征提取器的结构都不要求一致，只要大家都往代理特征提取器上靠就行。
再看FedBN。FedBN是在BachNorm层上做文章，把BN层的统计量保留在本地，不参与聚合，用来缓解客户端数据分布差异。它解决的核心是数据异构，模型架构也还是同构的。
还有一类比较接近的是FedMD，利用公共数据集做知识蒸馏，让学生模型学习教师模型输出的软标签。它不需要客户端结构一致，但需要额外的公共数据。pFedES不依赖公共数据集，共享信息完全通过代理特征提取器这个载体流动，这是两者最大的差别。
6.2 pFedES的独到之处在哪
综合对比下来，pFedES的定位很清晰：它属于“模型异构 + 个性化 + 无额外数据依赖”这一类。它不需要客户端结构一致，不需要公共数据集，也不需要传输异构模型的原始参数，知识共享发生在代理提取器的特征空间内。
还有个容易被忽略的优势，是它的“广义”特性。代理特征提取器作为一个独立模块，理论上是跟具体任务解耦的——你可以在图像任务上用卷积型代理提取器，可以在文本任务上用BERT型代理提取器（只要资源允许），甚至可以在多模态任务上搞一个跨模态的代理特征编码器。这种“可插拔”的设计，给了上层任务很大的自由度。
我在实际复现中体会最深的一点是：pFedES这类方案真正解决了“异构场景下如何定义全局知识”的问题。传统方法里，全局知识一定长成“一个完整的模型参数”；pFedES告诉你，全局知识可以抽象成“一个特征表示空间的参数”。后者显然更灵活，也更符合真实场景中“模型结构本来就是各家私事”的直觉。
7. 适用场景梳理：什么时候该用pFedES
7.1 最适合的场景清单
从方法论特性出发，pFedES适合的场景其实是可以归纳出来的。我列几个典型的：
第一，端侧设备异构，资源差异大。这是最直接的应用场景。比如你在做手机端的用户行为模型，有的设备可以跑复杂模型，有的设备只能跑轻量模型。pFedES让高算力设备充分发挥，低算力设备也能通过共享代理提取器获得帮助。
第二，参与方有“模型自治”诉求。在真实的多机构协作中，每个参与方都有自己的开发框架和模型习惯——有的用PyTorch，有的用TensorFlow，有的用自家推理引擎。要把它们强行统一到同一个模型结构，合作成本极高。pFedES允许各家保留自己的模型，只管好代理提取器这一层就可以协作。
第三，数据分布差异大且本地样本量不均衡。代理特征提取器相当于“集体的知识底座”，数据少的客户端能借助底座提升表征能力，数据多的客户端则贡献更多底座知识，形成互补。
7.2 不太适合的场景
有适合就有不适合。pFedES对以下场景并不友好：
一是特征本身信息量很低的任务。如果输入数据简单到用一个浅层MLP就够，引入代理特征提取器这种中间层纯属多余，只会增加通信和训练复杂度。
二是客户端极其海量且都只参与极少数训练轮次。代理特征提取器的更新依赖参与客户端回传梯度，如果每个客户端只出现过一两次，聚合出的代理提取器很难学到稳定的全局知识。
三是强隐私约束到“中间特征都不可传”的场景。pFedES虽然不传原始数据，但代理特征提取器输出的特征也会被共享训练，如果监管要求严格到特征级都不能交互，那这个方案就不适用了。
8. 落地时不可回避的工程问题
8.1 通讯协议和序列化设计
联邦学习系统落地，通讯协议的设计是躲不开的。pFedES的通讯消息不算复杂，主要是两类：服务端下发代理提取器参数、客户端回传代理提取器梯度。但要注意的是，不同客户端可能运行在不同框架里，你需要定义一套统一的序列化格式。
最省事的做法是用标准张量序列化。比如PyTorch的state_dict()、TensorFlow的SaveModel格式，都能把提取器参数转成字节流。只要约定好字段名和维度，两端就能对接。但如果你有多框架混合的部署，建议在序列化之外再加一层字段映射，避免PyTorch的命名和TensorFlow的命名不一致导致解析错误。
我踩过的坑是：本地模型也打包进通讯消息里了。完全没必要，本地模型只在本地存在，服务端永远不会解析它。所有通讯消息里只有代理提取器的相关数据，这个设计要在一开始就写清楚，不然很容易越传越臃肿。
8.2 异常客户端怎么处理
真实系统里，一定会有客户端中途掉线、上传异常数据、或者梯度爆炸的情况。pFedES由于只接收梯度，服务端可以做很多容错处理。
最简单的是做梯度裁剪，限制上传梯度的二范数。这个操作非常有效，几乎不会对正常训练产生副作用，但能极大提升训练稳定性。其次是做参与筛选，掉线客户端直接排除出本轮更新即可。再进阶一点，可以做梯度统计异常检测——如果某个客户端上传的梯度分布明显偏离其他客户端，可以怀疑它遇到了严重的数据污染问题，去掉它对全局模型更安全。
8.3 训练稳定性和超参调优
pFedES的训练稳定性主要受三个超参影响：本地训练轮数、学习率、以及对齐损失和监督损失的权重比。
本地训练轮数太多，客户端本地模型会过拟合，回传的代理提取器梯度也会带偏；轮数太少，代理提取器学不到足够信息。我在CIFAR-10上常用的配置是本地训练1到2个epoch就回传。
对齐损失的权重不宜设太大。权重太大，代理提取器会变成“复读机”——只顾着让特征跟本地模型对齐，忽略了特征本身的判别力。我常用的范围是0.1到0.5之间，配合网格搜索微调几次就能找到比较稳的点。
学习率方面，服务端聚合更新的学习率可以设得比客户端低一个数量级，缓解代理提取器的震荡。这个细节在实际训练中非常重要，很多方法跑不收敛，大概率不是思路问题，而是服务端学习率没调好。
9. 从pFedES延伸到更广的联邦学习思考
9.1 特征空间共享可能是联邦学习的通用范式
把pFedES的方法抽象一层来看，它其实指向了一个更深的问题：在异构分布式系统里，什么是适合做“全局共识”的最小单元？传统答案是完整模型参数，pFedES给出的答案是特征提取器的参数。
顺着这个思路想，这个“最小共识单元”其实可以选得更灵活。如果你做的是多模态任务，代理模块可以设计成多模态编码器；如果做的是序列任务，代理模块可以设计成序列编码器；甚至可以设计多个代理模块并存，分别对应不同的数据模态或者任务类型。这些扩展听起来复杂，但核心机制和pFedES是一样的——共享一个可插拔的中间模块，做特征级知识交换。
9.2 模型异构和个性化，未来只会越来越重要
我做联邦学习实验越久，越觉得模型异构不是“边缘场景”，而是常态。真实世界里的设备差异、数据分布差异、参与方开发习惯差异，天然就是异构的。过去的联邦学习框架统一模型结构，实际上是把复杂问题简化成了方便研究的形式，但在落地时总要去处理“统一模型”带来的各种妥协。
pFedES这种方案让我看到了一条更务实的路线：不追求形式上的统一，而是专注于构建一个所有参与方都能对得上的“中间桥梁”。这个桥梁可以很小、很轻、很通用，但它的存在，让异构的参与者有了协作的基础。
从更长远看，我觉得联邦学习会往“基础模块共享”的方向发展。参与方不再关心别人的模型长什么样，只需要约定一个很小的接口，比如一个特征表示层的规范，就能互通有无。这种模式不仅适用于机器学习模型，也适用于数据服务、算法组件等更广泛的AI基础设施。
10. 复现和实验设计的一些个人建议
如果有朋友想亲自上手复现pFedES的效果，我给几条实操建议。
先从标准数据集起步，不要一上来就搞复杂业务数据。CIFAR-10或者Fashion-MNIST这种中等规模数据集就够了，关键是做可控实验。在做数据异构模拟时，可以按狄利克雷分布把样本分配到各客户端，让不同客户端的数据分布明显不同步，同时配置不同结构的本地模型。
基线要配齐。最基础的基线是每个客户端独立训练自己的模型——记住这个基线，它代表的是“不协作下的上限”。如果pFedES在这个基线上提升不了几个点，说明任务本身协作价值不大，问题就不在方法上。再配合一个同构联邦的基线（比如FedAvg换成个性化版本），通过对比就能看出模型异构带来的实际性能损失。
实验记录要详细，尤其是每个客户端的数据量、本地模型结构、训练轮次、每个客户端独立训练时的精度。这些信息越细，你分析结果时就越容易定位问题。
在实际跑实验时，我遇到过的最头疼问题是特征对齐导致的“假收敛”。具体表现是损失下降很快，但测试精度上不去。原因就是代理特征提取器只顾着对齐，忽略了和分类任务的关系。遇到这种情况，调整对齐损失权重、降低代理提取器的学习率，通常都能缓解。
最后再分享一个我个人的小习惯：复现这类方法是，把代理特征提取器单独拎出来做可视化分析。比如把中间特征投影到二维平面上观察。你会发现，随着训练的推进，不同客户端的特征分布在慢慢靠拢，这就是共享表征形成的直观证据。看到这一步，你才算真正理解了pFedES这类方法的本质。
