1. 从"等最慢的那个"说起：我为什么盯上了异步联邦学习

异步联邦学习这个方向，我最早是被一个特别朴素的场景逼进去的：几十台边缘设备，网络状况参差不齐，有的十分钟能跑完一轮本地训练，有的卡在下载参数上能耗掉半小时。用最经典的同步聚合思路，服务端每轮都得等所有人交卷，结果就是"80%的设备空等20%的设备"，整体墙钟时间被最慢的那个节点死死拖住。后来我开始系统性地翻异步方案，FedASMU 是其中让我觉得"设计得有脑子"的一个——它没有假装异步是免费的，而是正面承认了异步带来的核心代价：陈旧度（staleness），然后围绕这个代价做了两处针对性设计。

先把话说清楚，这篇讲的 FedASMU 是什么。它是一套面向异步联邦学习的模型更新机制，核心主张是：服务端聚合时不能只看"谁先交卷"，还要看"这份卷子是在多老的教材上答的、答得准不准"；客户端训练时也不能拿着一个过期的全局模型闷头跑到底，得知道自己的起点已经落后，主动往最新全局模型那边靠一靠。它解决的是异步联邦学习里最要命的那个矛盾——吞吐量和模型质量之间的取舍。适合谁来读？我的判断是：已经跑通过至少一次联邦学习同步流程、手上有多台异构设备或者模拟器、并且正在被"训练轮次上不去"或者"异步之后精度掉得厉害"这两件事之一折磨的人。如果你是纯新手，也能看，但建议先把联邦平均那套基本流程走一遍再回来，很多细节会突然变得有意义。

这是这个系列的第一篇，我打算把 FedASMU 这套东西从设计动机、公式直觉、代码落地到踩坑记录完整过一遍，尽量做到你拿着这篇文章能自己搭出一个能跑的版本，而不是看完只知道几个名词。

2. FedASMU 的整体设计思路拆解

2.1 异步到底省了什么，又亏了什么

先把账算明白，不然调参全是玄学。同步联邦学习的一轮是这样：服务端把当前全局模型分发给选中的 K 个客户端，等所有人训练完上传，聚合，进入下一轮。墙钟时间 T_sync ≈ max(各客户端训练+通信时间) + 聚合时间。这个 max 就是命门，只要有一个客户端在弱网或者低算力设备上，整轮就被它锁死。

异步改成了流水线：服务端不等，谁交了就用谁的，立刻更新全局模型并推进版本号。理想情况下服务端永远在干活，吞吐量由"平均到达速率"决定而不是"最慢的那个"。代价有三层：第一层是陈旧度，某个客户端是拿着版本 t-5 的全局模型训练的，它交上来的时候全局模型已经走到 t 了，这份更新是基于过时信息算出来的，方向可能已经偏了；第二层是梯度/参数冲突，多个客户端基于不同版本的全局模型各自往不同方向走，简单平均容易互相抵消，表现为 loss 曲线锯齿；第三层是收敛性分析变复杂，理论保证需要额外假设，这一点在工程上意味着"你没法靠理论直接推出该用多大学习率"。

FedASMU 的切入点很清楚：既然陈旧度是结构性的、消不掉的，那就把它显式建模成一个可以参与计算的量，让聚合和训练都根据它来调整力度。

2.2 两条主线：服务端算权重，客户端做锚定

我把 FedASMU 拆成两个可以独立实现的模块，这样你调试的时候能分别验证，不至于一出问题就抓瞎。

服务端侧：陈旧度感知的动态聚合权重。传统异步方案（比如最朴素的异步平均）要么等权平均，要么只按陈旧度做一个指数衰减系数。FedASMU 加了一层：不仅看这份更新有多老，还看这份更新本身的质量。质量怎么衡量？一个非常实用的近似是——客户端在本地留一小份验证集，训练完算一下损失，把这个损失连同陈旧度一起报上去。损失低说明这个客户端在本地数据上拟合得好，它的参数方向相对可信；损失高说明它自己都没收敛，权重就该压一压。这个"质量因子 × 陈旧度衰减因子"的组合，是整套方法里我觉得最有工程味道的一笔，因为它把"信任"这件事量化了。

客户端侧：陈旧度感知的本地训练修正。这一步经常被忽略。想象一个客户端拿到的是 8 轮之前的全局模型，它本地训练 5 个 epoch，跑得越久，离当前全局模型越远。等它上传的时候，这份参数可能已经把全局模型往一个过时的方向拽了一大截。修正手段有两类：一是参数锚定，限制本地参数偏离起点的幅度，偏离惩罚的强度随陈旧度增加；二是起点刷新，陈旧度特别大的时候，干脆让它重新拉一次最新的全局模型再训。前者温和、通信零成本，后者激进、要多一次下行传输。我在实际项目里是两者结合用的，后面第 4 章会讲具体怎么定阈值。

2.3 和几个常见方案摆在一起看

光说设计意图不够直观，我拉个表把差异摆出来，这张表是我自己选型时真正用到的判断依据。

这张表里我最想强调的是最后一行。FedASMU 相对朴素异步方案，额外付出的通信量其实只有两个数字，代价极小，但换来的是聚合权重有了判断依据。这种"低开销换决策质量"的设计，在我看过的方案里性价比算高的。

还有一个选型上的提醒：如果你手上的场景里客户端算力其实比较均匀、网络也稳定，那异步带来的收益有限，反而引入了调参负担，老老实实用同步方案更省心。异步是给"长尾明显"的场景准备的药，不是万能补药。

3. 服务端：把"陈旧度"和"可信度"揉进一个权重里

3.1 权重公式的直觉推导

我不打算一上来甩公式，先讲我要这个东西满足什么性质。设客户端 i 上传时，它的起始全局版本号是 t_i，服务端当前版本号是 t，那陈旧度 τ_i = t - t_i。我要的权重 w_i 应该满足三条：

第一，τ_i 越大，w_i 越小，而且是平滑衰减不是硬截断，因为硬截断会让"刚好卡在阈值外"的更新白白浪费。第二，本地损失 l_i 相对全局损失 l_g 越高，w_i 越小，但如果所有客户端损失都偏高（训练早期正常现象），权重的相对排序不应该被破坏。第三，权重最后要归一化，且整体更新步长要有一个全局的"刹车"参数，防止某一次聚合直接把模型拽飞。

基于这三条，我用的是两个因子的乘积再归一化：

• 陈旧度衰减因子 d_i = exp(-τ_i / λ)，λ 是尺度参数，控制"多老算很老"。
• 质量因子 q_i = exp(-β · max(0, l_i - l_g))，β 控制对质量差异的敏感度，用 max(0, ·) 是因为本地损失比全局损失还低的情况很常见（本地数据少、过拟合），这时候不该额外奖励，只给个中性值 1。

最终权重 p_i = q_i · d_i / Σ_j (q_j · d_j)。服务端更新写成：

w_g ← (1 - η) · w_g + η · Σ_i p_i · w_i

这里的 η 就是那个刹车，我叫它有效步长。注意它和 p_i 的归一化是两件事：p_i 决定"这次更新内部各客户端的相对配比"，η 决定"这次更新整体对全局模型的影响幅度"。很多实现把这两个混在一起，结果就是调一个参数牵动两处行为，非常难调。

为什么用指数而不是幂律（(1+τ)^(-a)）？我两种都试过。指数衰减在 τ 小的区间下降得比较平缓，τ 大的区间下降很快，适合"大部分更新是轻微陈旧、少数是严重陈旧"的分布，而这恰好是真实边缘场景的典型形态。幂律的尾巴更厚，对极端陈旧更宽容，我在客户端数量少（比如 10 台以内）、偶尔出现极端延迟的场景里用过，效果也行。这个选择没有绝对对错，看你数据的陈旧度分布，建议先把 τ 的直方图打出来看一眼再定。

3.2 用什么近似"本地模型质量"，以及为什么能近似

严格来说，衡量一份本地更新的价值，应该看它在全局数据分布上的表现。但全局数据不可得，这是联邦学习的前提。于是只能用代理指标。FedASMU 的思路是用本地验证集损失作为代理，这个近似成立的理由是：如果本地数据是全局数据的一个（哪怕是有偏的）采样，那么一个在本地验证集上损失很低的模型，它在同分布的其它数据上大概率也不会太差；反之，一个自己都没收敛的模型，它的参数方向基本是噪声。

但这里有三个坑，我必须提前说：

坑一：验证集必须和训练集分开。有些实现图省事，直接用训练集最后一批数据算损失，结果算出来的是训练损失，几乎恒低，质量因子完全失效，等于退化成只按陈旧度加权。

坑二：l_g 不能用历史值。全局损失必须在当前全局模型上、用同一批客户端报上来的验证集数据重新算一遍，或者维护一个滚动估计。用旧值会导致训练早期质量因子全为 1、训练后期突然全部失效。

坑三：各客户端的验证集不能差太多。如果 A 的验证集全是简单样本、B 的全是困难样本，那 l_i 之间根本没有可比性。工程上可行的做法是让每个客户端固定一小份本人数据的随机子集作为验证集，并且要求规模相近（比如统一 200 条），不要动态变化。

3.3 服务端聚合的核心实现

下面这段是我实际用的服务端聚合逻辑，Python 写的，框架无关，你可以直接套到自己的调度器上。伪代码层面它足够完整，真实部署时把参数字典换成你框架的张量结构就行。

import math class AsyncAggregator: def __init__(self, global_params, lam=8.0, beta=2.0, eta=0.35): self.w = global_params # 全局参数字典 self.version = 0 # 全局版本号 self.lam = lam # 陈旧度衰减尺度 self.beta = beta # 质量敏感度 self.eta = eta # 有效步长（刹车） self.l_g = None # 全局损失估计 def submit(self, client_params, client_loss, start_version): # 1. 算陈旧度 tau = max(0, self.version - start_version) # 2. 陈旧度衰减因子，加一个下限防止数值下溢为 0 d = math.exp(-tau / self.lam) d = max(d, 1e-6) # 3. 质量因子，全局损失未知时退化为 1 if self.l_g is None: q = 1.0 else: q = math.exp(-self.beta * max(0.0, client_loss - self.l_g)) return d * q, tau def aggregate(self, pending): # pending: [(params, loss, start_version), ...] if not pending: return scored = [] for params, loss, sv in pending: raw, tau = self.submit(params, loss, sv) scored.append((params, raw, loss, tau)) total = sum(s for _, s, _, _ in scored) if total <= 0: return # 4. 归一化后按 eta 融合 new_w = {} for k in self.w: blended = 0.0 for params, s, _, _ in scored: blended += (s / total) * params[k] new_w[k] = (1 - self.eta) * self.w[k] + self.eta * blended self.w = new_w self.version += 1 # 5. 更新全局损失估计，用本批上传的损失做滑动平均 avg_loss = sum(l for _, _, l, _ in scored) / len(scored) if self.l_g is None: self.l_g = avg_loss else: self.l_g = 0.9 * self.l_g + 0.1 * avg_loss

有几个数值细节值得单独拎出来说。第一，d我加了一个 1e-6 的下限，这不是洁癖，是因为 exp(-τ/λ) 在 τ 到几十、λ 又设得小的时候会直接下溢成 0，一旦某个批次所有客户端的 d 全是 0，total就是 0，聚合会被静默跳过，你在日志里看到的是"训练卡住了"但没有任何报错，非常难查。第二，全局损失我用的是指数滑动平均而不是直接替换，因为单批次的损失噪声很大，尤其是 Non-IID 场景下不同客户端损失差异能到几倍，直接用会造成质量因子剧烈抖动。第三，eta我一开始设成 1.0（也就是完全替换），结果在客户端数据异构的时候模型直接发散，后来降到 0.35 才稳住，这个数后面第 5 章还会细讲怎么定。

4. 客户端：知道自己落后，就该主动往回靠

4.1 陈旧客户端的参数为什么会跑偏

这一点值得展开讲，因为它决定了客户端侧要不要做额外处理。设想一个极端的例子：客户端 C 在版本 3 的时候拉走了全局模型，然后本地跑了 10 个 epoch，中途网络断了，等它恢复并上传时全局已经到版本 40 了。这期间另外几十个客户端已经把模型推着走了很远。C 上传的参数是在"版本 3 附近的解空间"里优化出来的，它和当前全局模型很可能已经不在同一个"盆地"里。

这种情况下，等权聚合会发生什么？C 的参数会把全局模型往回拽。表现出来就是：一次聚合之后，全局 loss 突然跳一下，然后接下来几轮再慢慢降回去。如果你画 loss 曲线，会看到规律性的尖刺，尖刺的间隔和那种超长延迟客户端的上传周期一致。我第一次遇到这个现象时以为是学习率问题，调了两天才反应过来是陈旧度。

FedASMU 在客户端侧的思路是让客户端自己知道"我起点老了"，然后主动做补偿。具体两个手段，我按实施成本从低到高排。

4.2 手段一：参数锚定，用正则把本地模型拴住

最轻量的做法，是在本地训练的损失函数里加一项对参数偏移的惩罚：

L_local = L_task(θ) + (ρ / 2) · ||θ - θ_start||²

θ_start 是这轮训练开始时从服务端拿到的全局参数。ρ 越大，本地模型越不敢偏离起点。关键是 ρ 不能固定，要随陈旧度变：起点越老，越要拴紧，因为它偏离的方向越不可信。

我用的映射是 ρ = ρ_0 · (1 + τ / λ_c)，λ_c 是客户端侧自己的尺度参数，和服��端的 λ 分开设。这样 τ = 0（完全新鲜）时 ρ = ρ_0，是一个很小的基础约束；τ 很大时 ρ 线性增长。选线性而不是指数，是因为指数增长太快，稍微陈旧的客户端会被拴得完全学不动，等于白跑一轮。

这个手段的优点是零额外通信，只在本地损失里加一项。实现上要注意：如果你用的是自适应优化器，正则项的梯度会和任务损失的梯度一起被自适应缩放，效果不像理论分析那么线性。我的处理是把正则项的梯度单独算、单独用固定学习率更新，或者干脆在每步更新后做一次向 θ_start 的软收缩：θ ← θ - γ · (θ - θ_start)，γ 和 ρ 对应。后一种做法更可控，实测收敛行为也更好预测。

4.3 手段二：起点刷新，陈旧度超阈值就重拉

锚定能缓解跑偏，但缓解不了"起点本身已经错了"这个事实。所以还得有一条硬规则：陈旧度超过某个阈值 Θ 的时候，客户端不再用手上这份老模型，而是重新从服务端拉一份最新的，从头开始本地训练。

Θ 怎么定？我的经验公式是 Θ ≈ 2λ 到 3λ。理由是：按 exp(-τ/λ) 的衰减，τ = 2λ 时陈旧度因子已经掉到 0.135，τ = 3λ 时掉到 0.05，也就是说这个客户端的更新在聚合里基本没话语权了，那它交上来的东西价值已经很低，不如花一次下行带宽换一份有意义的新起点。

但 Θ 不能太小，否则会出现"客户端永远在重拉、永远训不完"的活锁，特别是当全局版本推进速度快于客户端训练速度的时候。这个现象我在一个模拟环境里真实遇到过：全局每 2 秒更新一版，客户端本地训练要 30 秒，Θ 设成 5 的话，客户端每训到一半就发现自己超阈值，重拉，然后又超，循环往复，一台设备一晚上一个有效更新都没交上来。解决办法是把 Θ 和"预期训练时长对应的版本推进量"挂钩，也就是 Θ ≥ (本地训练时长 / 全局平均更新间隔) × 安全系数，安全系数取 1.5 左右。

4.4 客户端训练的完整流程

def client_train(global_params, start_version, server_version_now, loader, val_loader, cfg): theta = clone(global_params) theta_start = clone(global_params) # 1. 判定是否需要刷新起点（由调度器在派发前判断更合适，这里作为兜底） tau = max(0, server_version_now - start_version) need_refresh = tau > cfg.theta_refresh if need_refresh: theta = clone(fetch_latest_global()) theta_start = clone(theta) tau = 0 # 2. 锚定强度随陈旧度增长 rho = cfg.rho0 * (1.0 + tau / cfg.lam_c) for epoch in range(cfg.local_epochs): for x, y in loader: loss = task_loss(theta, x, y) # 3. 锚定项：软收缩形式，避免和自适应优化器打架 anchor_grad = rho * (theta - theta_start) theta = theta - cfg.lr * (grad(loss, theta) + anchor_grad) # 4. 在固定验证集上算损失，回传给服务端 val_loss = evaluate(theta, val_loader) return theta, val_loss

我在实现时踩过的一个细节坑：theta_start必须是深拷贝，不能是引用。早期图省事直接赋值，结果本地训练是原地更新参数的，theta_start跟着一起变了，锚定项恒等于 0，等于完全没生效，但代码看起来一点问题没有。这个 bug 藏了整整两天，最后是靠打印锚定项的范数发现它一直是 0 才定位到的。类似的问题在任何"保存初始状态做对比"的场景里都会出现，值得写进自己的检查清单。

5. 从零跑通：我的实操配置与调参记录

5.1 实验环境和数据划分

我用的是一套模拟环境：单机多进程模拟 20 个客户端，数据是一个公开的图像分类数据集，按标签做 Non-IID 划分（每台客户端只拿 2 到 3 个类别），每台客户端的样本量在 400 到 1200 之间随机。这个设置不是为了刷指标，而是为了复现"数据异构 + 算力异构"这两个异步场景最典型的困难。

算力异构怎么模拟？给每个客户端进程加随机延迟，让本地训练耗时在一个区间内随机分布，同时给少数几个客户端加上"偶发超长延迟"，模拟那种断网重连的设备。这一步很关键，如果你的模拟环境里所有客户端耗时都差不多，异步和同步的区别根本体现不出来，你也调不出有意义的结果。

客户端角色分工：每个客户端固定划出 200 条本地数据作为验证集，不参与训练，只用于算上传前的那份损失。全局损失估计用的是服务端聚合后、在当前全局模型上跑一批"探针数据"的结果。这个探针数据在真实场景里不可得，模拟环境里我留了 500 条全局数据专门干这个，你要落地到真实场景，就得退回到"用各客户端上传损失做滑动平均"的方案，也就是第 3.3 节代码里那段。

5.2 三组对照，看清每个模块到底值多少

调参之前先做对照实验，不然你不知道自己在调什么。我跑了四组配置，每组固定随机种子跑三次取中位数，指标是达到目标精度所需的墙钟时间和总通信轮次。

这组数字里最能说明问题的是 B 和 D 的对比。朴素异步确实快，但震荡程度高得没法用，而且在大延迟客户端上传的那几轮会出现明显的精度回退。加上质量因子和客户端锚定之后，墙钟时间反而更快了——这一点我一开始没预料到。后来想明白了：震荡少了意味着模型不会白白往回走，每一轮更新的有效信息更多，所以虽然单轮成本高了点，达到同样精度需要的总轮次少了。

C 和 D 之间的差距比我预期的小，说明在这个数据划分下，陈旧度是主要矛盾，质量因子是次要增益。但在我把客户端数据异构程度调高（每台客户端只拿 1 个类别）之后，C 的精度出现明显下滑，D 还能维持，这时候质量因子的价值就显出来了。所以我的结论是：数据异构越严重、客户端质量差异越大，质量因子越重要；反之可以省掉它，代码还简单些。

5.3 关键参数怎么定，我给一张查表

下面这张表是我在自己场景里试出来的，不同场景肯定要重调，但至少给你一个起点，省掉从 0 开始瞎试的时间。

关于 η 和 E 的配合，我有一条经验：总有效学习量 = η × E，这两个参数要一起动。如果你把 E 从 3 降到 1，就得把 η 适当提上去，否则模型推进速度会明显变慢，你会误以为是算法不行。反过来，E 调大时必须把 η 压下来，因为一次聚合会灌进去更多本地过拟合的信息。

5.4 一个容易被忽略的实现问题：版本号和并发

异步最恶心的工程问题是并发。服务端在聚合一批更新的同时，可能又有新客户端来拉模型、或者又有新更新到达。如果版本号和参数不是原子地更新，就会出现"客户端拉到了新版本号但拿到的是旧参数"这种错配，然后它的陈旧度计算全错。

我的处理是把"读参数+读版本号"打包成一个原子操作，并且聚合时用一份参数快照做混合，而不是在聚合过程中直接改全局参数。具体是：聚合开始时snapshot = clone(self.w)，所有混合都基于 snapshot 计算，算完一次性替换。这样即使聚合计到一半有新请求进来，读到的也是完整的一版，不会读到半成品。这一条在单线程模拟环境里完全看不出问题，一上多线程就开始随机失败，属于典型的"模拟环境测不出来的坑"。

6. 问题排查实录：那些让我熬夜的现象

6.1 精度不升反降，或者剧烈锯齿

这是异步方案最常见的第一现场。排查顺序我固定成三步：先看陈旧度分布，再看聚合权重分布，最后看单次聚合的参数变化幅度。

陈旧度分布怎么打？每轮记录所有上传的 τ，画直方图。如果发现有一批客户端的 τ 常年在 30 以上，而 λ 还设着 8，那 d 因子全在 0.02 以下，这批客户端的更新基本是噪声，得先把它们的刷新阈值 Θ 调低或者直接踢出候选池。

聚合权重分布看什么？看有没有"一家独大"。如果某一轮的 p_i 有 0.8 集中在单个客户端上，那基本就是那个客户端的 d 和 q 都异常高，可能是它的验证集太简单导致 l_i 特别低。这种情况要检查验证集划分是不是随机、规模是不是一致。

单次聚合的变化幅度怎么算？我一般直接算 ||w_new - w_old|| / ||w_old||，这个比值如果单轮超过 5%，就要警惕了。我遇到过一次，某客户端上传的参数里有一层 bias 数值异常大（本地学习率发散了），虽然它的权重被压得很低，但因为数值本身大，乘上去仍然造成了明显扰动。后来的处理是在聚合前加一道筛查：单份参数和全局参数的相对差超过阈值的，直接丢弃并记一条日志，而不是靠权重去压制。

6.2 模型在某几轮之后完全不动了

这个现象比锯齿更让人懵，因为 loss 不涨不跌，就是平的。原因是第 3.3 节提过的那个数值下溢：所有 d 因子都下溢成 0，total为 0，聚合被静默跳过，模型停在原地，而客户端的 version 还在涨（因为客户端那边可能自己加了版本号），于是差值越来越大，下溢越来越严重，形成死锁。

我的排查手法：在聚合函数里加一行断言，total > 0不成立就打印所有 τ 和 d 值并抛异常。宁可崩，不要静默。异步系统里"静默地什么都不做"是最难查的一类故障。

根治办法是给 d 加下限，以及给 τ 设上限截断，比如 τ 超过 4λ 就按 4λ 算，这样 d 永远不会低于 exp(-4) 左右，也就不会集体下溢。

6.3 客户端活锁：一直在刷新，一直没成果

前面提过一次，这里展开说。症状是客户端日志里不停地出现"刷新起点"，但服务端几乎收不到有效更新。根因是 Θ 设得小于客户端训练期间的正常版本推进量。

怎么判断是不是这个原因？统计一下"客户端训练开始时版本号"和"训练结束时版本号"的差，这个差就是它天然的陈旧度。如果这个天然陈旧度的中位数已经接近或者超过 Θ，那说明你的阈值设得不合理，必然活锁。

修正方式有两种，选一种就行：一是按前面说的把 Θ 提高到天然陈旧度的中位数的 1.5 到 2 倍，代价是允许更陈旧的更新进来，需要靠权重压制；二是减少客户端本地训练时长（降 E 或者减数据量），让天然陈旧度本身降下来，代价是每轮信息量变少。我在实测里选的是第一种，因为第二种会让收敛变慢，得不偿失。

6.4 速查表

下面这张表是我从自己日志里整理出来的，基本覆盖了我在这个方案上遇到的大部分现象，遇到问题可以先对一遍。

7. 落地层面的几句实话

这套方案我前后调了小半年，最后想说的几个体会都不在论文里。

第一，别迷信参数，先看分布。异步系统里所有参数（λ、β、Θ）都是针对某个陈旧度分布而言的，换个场景数值全变。养成先打日志看分布、再定参数的习惯，比抄任何一套推荐值都管用。我现在动手之前一定要跑一遍空转，把所有客户端的 τ 和 l_i 分布打出来，看完再开始调。

第二，质量因子的收益高度依赖场景。如果你的客户端数据分布比较接近、算力也比较均匀，那这个模块可以砍掉，代码能少三分之一，效果差不了多少。它真正发光的地方是客户端之间差异很大的情况。别为了"用上完整方案"而给自己增加维护负担。

第三，工程健壮性比算法优雅更重要。我在这套东西上花时间最多的不是推公式，是处理下溢、并发、异常参数、日志可观测性。异步系统天生是分布式的、时序乱的，任何一个静默失败都会让后面几天的调试全白费。所以我现在写这类代码，第一件事是把断言和日志铺满，宁可多打点日志占点磁盘。

第四，锚定项的系数宁小勿大。锚定太强，客户端本地根本学不动，你看到的是"训练轮次上去了但精度上不去"，很容易误判成异步本身不行。我的做法是从一个非常小的值起步（比如 1e-4 量级），确认有效果了再往上加。

后面几篇我打算把这个系列往下推：怎么在资源受限的边缘设备上控制这套方案的额外开销，怎么处理客户端随时上下线导致的状态不一致，以及怎么把质量因子的估计做得更稳一些。这篇里关于参数的取值和对照实验的结果都来自我自己搭的模拟环境，跟你手上的具体场景肯定有出入，拿来当起点可以，别当标准答案用。