企业官网建设流程全解析

1. 多任务学习的账，乱在“权重”这一关

做过多任务深度学习的人，基本都经历过同一个噩梦：任务A的loss收敛得很好，任务B的loss反而一路飘高；或者任务B终于咬紧牙关往下走了，任务A又原地爆炸。你盯着tensorboard里的曲线，开始怀疑是不是数据有问题、网络结构不对，最后才如梦初醒——原来是loss加权那几行代码在搞鬼。

但麻烦在于，loss的“权重”不是你想加就能加对。任务A的损失是0.1量级，任务B的损失是1000量级，如果你直接把两个数加起来，梯度基本被任务B垄断，任务A成了“陪跑选手”。手动调权重，可能光在[0.1, 10]这个区间里试就试掉一周时间，还不一定能调出一个让所有任务同时满意的平衡点。而且就算在某一个epoch调好了，训练到后面任务的学习速度发生变化，这个权重又会变得不合适。

GradNorm解决的就是这件事。它的全称是Gradient Normalization，翻译过来叫“梯度归一化”，是在多任务网络训练过程中自动调整每个任务损失权重的算法。不需要你手动给每个任务定权重，也不需要在损失函数外面接一堆开关，它自己会在每个step根据当前各任务梯度范数的相对大小，自动把权重修正到“让所有任务都以大致相同速度被训练”的状态。

这篇博文我会从一个实际使用者的角度来拆GradNorm，包括它的核心直觉、数学原理、代码实现、实测效果，以及我在不同数据集上跑出来的那些坑。适合正在做多任务学习、被loss权重折磨得不行的朋友，也适合那种刚入坑、想理解“为什么多任务训练这么别扭”的读者。

2. 为什么手动调loss权重本质上是在“猜一个动态答案”

2.1 一个任务最后的效果，取决于“训练速度”而不只是“loss数值”

很多人的直观想法是：loss大的任务权重调大一点，loss小的任务权重调小一点，这样损失函数里各项的量级就平衡了。但实际跑两轮就会发现，这个逻辑有个漏洞——loss的绝对大小不代表训练难度，也不代表梯度质量。

举一个身边的例子。假设有两个任务，任务A是图像分类，初始loss是1.2；任务B是深度估计，初始loss是5.0。按照“谁大谁多给权重”的思路，任务B应该拿到更高的权重。但真实情况可能是：任务B的backbone层已经学到了足够好的特征，5.0的loss里很大一部分是最后输出层的“噪声误差”，梯度方向在大方向上其实是对的；而任务A的1.2，背后是模型完全没学会某个类别，梯度信号本身很弱，需要更多“推力”。

如果简单地按loss大小分配权重，你会发现任务A越学越慢，任务B却很早就过拟合了。因为决定一个任务能不能被充分训练的关键指标不是loss的绝对值，而是这个任务的梯度对整个共享网络参数的更新贡献有多大——也就是训练速度。GradNorm想做的，就是动态检测每一个任务的梯度范数，把不同任务的训练速度校准到一条线上。

2.2 手动方案的两大硬伤：耦合性与滞后性

经典的“手动调权重”工作流是这样的：你先给每个loss配一个标量权重，比如total_loss = w1 * loss1 + w2 * loss2，然后训练几个epoch，看效果，不够好就改权重，再训练。这是我在早期做多任务项目时最常用的方案，也是见效最痛苦的方案。

第一是耦合性太强。损失总梯度等于各个任务梯度乘上权重后的求和，如果你调高了任务A的权重，任务B的梯度分量在total gradient里的占比就会被压下去，任务B的有效学习率就下降。但任务B的学习率下降反过来会影响共享层的特征表达，这些特征又是任务A也要用的。牵一发而动全身，这就是为什么你改了w1之后发现w1本身改对了，但任务B的指标也变了，最后你得重新去调w2。

第二是滞后性。训练早期是一个分布，训练中期是一个分布，收敛期又是一个分布。举个实际场景，我在做某个语义分割加深度估计的多任务模型时，刚开始深度估计任务梯度范数大约是分割任务的10倍，我按10:1给了权重。训练到第30个epoch时深度估计的梯度已经掉到和分割差不多的水平了，但我的代码里权重还是10:1。理论上我需要每过一段时间重新调一次，但真去做了就会发现，这个“不断手动重调”的过程本身就是在浪费算力和时间。

其实这种动态平衡问题，在别的领域是有成熟思路的。比如Batch Normalization，它做的是把每层的输入分布拉到一个稳定的尺度上；GradNorm的目标本质上和BN一样，只不过它拿去归一化的对象不是特征图，而是任务的梯度——把每个任务的“梯度分布”拉齐，让它们在共享网络上的影响力一致。

3. GradNorm怎么做：一种基于梯度范数的动态调度器

3.1 三个关键指标：梯度范数、相对反比训练速率、目标函数

GradNorm的设计思路并不复杂，核心是用梯度范数来度量每个任务当前的学习状态，然后定义一个“目标梯度范数”，让所有任务的梯度范数都朝这个目标靠拢。具体涉及三个核心量。

第一个是从共享层某个参数集合W上算出的梯度范数，每个任务算一份：

• 设第i个任务在总损失中的加权loss为L_i_total = w_i * L_i，其中w_i是当前权重。
• 该任务对共享层参数的梯度记为∇W L_i_total，对这个梯度取L2范数，得到G_i = ||∇W L_i_total||。
• G_i就代表任务i当前对共享参数的影响力大小。

第二个量是各任务的“相对反比训练速率”。这里要引入一个直觉：训练已经比较成熟的任务，loss下降得慢，它对继续更新的需求就低；训练还很吃力的任务，loss下降得快或者下降幅度大，它需要更多的“帮助”。GradNorm用一个比值来衡量：

r_i = L_i / L_avg

其中L_i是任务i当前未加权的原始loss，L_avg是所有任务原始loss的均值。再用这个比值做一次归一化，得到r̃_i = r_i / mean(r)，均值之后的r̃_i是围绕1波动的，大于1表示任务i比平均水平“跑得快”，小于1则表示它“落后了”。

第三个量就是目标函数了。GradNorm给每个任务设定一个目标梯度范数：

G_target_i(t) = G_avg(t) * (r̃_i(t))^α

其中G_avg(t)是当前所有任务梯度范数的均值，α是一个超参数，控制各任务间的平衡强度。

这个目标公式的含义值得仔细体会。G_avg是所有任务的平均梯度量级，相当于一个基准线；r̃_i越大，说明任务i训练得越快，目标梯度范数就越大——注意，这里不是让“慢的任务”目标梯度变高，恰恰相反，是让“快的任务”目标梯度变高。这看起来反直觉，但仔细想就通了：所有任务的梯度范数被拉向各自的G_target_i后，快的任务保持较大的梯度量级，慢的任务逐步变小，整体上不同任务的相对梯度差异在指数α的控制下被压缩或扩张，从而让训练速率趋于一致。这和“让差生多辅导”的直觉不同，GradNorm的提法是“让尖子和差生各自以适合的速度奔跑，并且方向一致”——它调整的是平衡，不是单方面偏向。

3.2 更新权重的完整流程

讲完指标，上流程。假设一个多任务网络有M个任务，共享网络位于W层，每个任务有各自的分支网络。GradNorm在每个训练step额外做几步操作。

第一步，初始化所有w_i = 1。第二步，前向计算每个任务的loss_i，再乘上当前的w_i得到加权loss，累加得到总loss，反向传播。第三步，在反向传播后读取每个任务对W层的梯度范数G_i。第四步，按公式算G_avg、r_i、r̃_i和G_target_i。第五步，通过一个梯度下降optimizer更新w_i，优化目标是让所有|G_i - G_target_i|的和最小化。第六步，每step对w_i做一次归一化：让所有w_i之和等于任务数M，这样权重的绝对大小不会无限膨胀。

这里我多强调一下两个容易被初学者忽略的细节。

细节一：更新w_i用的不是主训练循环的optimizer，而是单独的一个optimizer。因为如果你用同一个优化器去更新网络参数和权重，梯度会互相污染。实践中我一般给权重更新单独开一个小学习率，比如0.025或者0.01，主学习率是0.001这个量级。

细节二：权重归一化操作很重要。公式上如果所有w_i一起翻倍或缩小，总loss梯度也会变，但各任务间的相对比例没变。如果不做归一化，权重虽然是动态的，但可能越走越偏，最终导致整体学习率变形。GradNorm原文用的单位归一化是w_i = w_i * M / sum(w_i)，这里M就是任务数。

3.3 参数α：控制“平衡的强度”

α在整个GradNorm里的作用经常被低估。我理解它的本质是“你要多大程度地拉平各任务的训练速度”。

α = 0时，所有任务的G_target_i就等于G_avg，所有任务被拉向同一个梯度范数水平，这是最强力、最激进的平衡。快任务和慢任务之间的差异会被大大压缩。

α越大（接近1），(r̃_i)^α的差异越明显，快任务的目标梯度范数保持较大、慢任务的目标梯度范数较小，意味着GradNorm对训练速率差异的修正力度越弱。

初始实验一般推荐α = 0.5，这是折中值。我在实际测试中也试过α从0.1到0.8的范围，观察到的现象是：α过小会导致刚开始几个epoch各任务权重快速震荡，因为它们都被强制拉齐；α过大则整个机制接近“不干预”状态，效果和固定权重差不多。所以α更像是选择“一边倒均衡”还是“先保主要任务”的旋钮，不是越大约好，也不是越小越正确。

4. 从公式到代码：动手实现GradNorm并接入训练流程

4.1 最小可跑的实现版本

我以PyTorch为例写一个最简实现，方便你先跑通再根据自己的网络结构优化。先定义GradNorm的核心逻辑。

# gradnorm_minimal.py import torch import torch.nn as nn def gradnorm_step( task_losses, # list/tensor of raw task losses, shape [M] task_weights, # weights w_i, requires_grad=True shared_grads_norm, # list of ||∇W L_i_total|| for each task, shape [M] alpha=0.5, task_num=2, ): # L_avg and relative inverse training rate r_i L_avg = torch.mean(task_losses) r = task_losses / L_avg.detach() r_tilde = r / torch.mean(r).detach() # 当前所有任务梯度范数的均值 G_avg = torch.mean(torch.stack(shared_grads_norm)).detach() # 目标梯度范数 G_target = G_avg * (r_tilde ** alpha) # GradNorm loss: 把所有任务的 |G_i - G_target_i| 加总 gradnorm_loss = torch.sum(torch.abs( torch.stack(shared_grads_norm) - G_target.detach() * task_weights.detach().abs() )) return gradnorm_loss

等等，我这里要澄清一个容易写错的地方。上面这个版本为了让w_i参与梯度更新，通常会把G_i写成依赖w_i的表达式，也就是G_i = ||∇W (w_i * L_i)||。当网络反向传播完成后，你可以分别算出每个任务的分梯度范数。但在实现时有两种组织方式。

方式A：先关掉所有任务的分支，对每个任务单独反向传播一次，收集梯度范数，然后累积出总梯度。这种方式求G_i最准确，但要多做若干次反向传播，效率不高。

方式B：一次总前向和一次总反向，但对W层的参数梯度按“任务”分组不好分——因为PyTorch默认累加梯度时不会自动分类。实际项目里常用的是“任务分支层上做gradient tape”的方式，或者在自定义层里用torch.autograd.grad对特定任务loss求共享层参数的梯度。整体来说，每个step多花一次共享层的自动微分是值得的。

我实际项目里采用的方式是：先对各个任务的loss用torch.autograd.grad(loss_i, shared_params, retain_graph=True)单独求梯度范数，再回到主loss做统一的反向传播。这样一次前向，多次小范围反向，代价可接受。

4.2 接入主训练循环时的完整伪代码

直接给一套可以抄的流程。

# 伪代码：GradNorm接入训练循环 alpha = 0.5 M = len(tasks) # 任务数量 lr_gradnorm = 0.025 # 共享网络参数（用于计算梯度范数） shared_params = network.get_shared_parameters() # 初始化loss权重 task_weights = torch.ones(M, requires_grad=True) # 权重专用optimizer gradnorm_optim = torch.optim.SGD([task_weights], lr=lr_gradnorm) for step, batch in enumerate(loader): # 1. 前向计算 outputs = network(batch) raw_losses = [criterion_i(outputs[i], labels[i]) for i in range(M)] # 2. 计算每个任务的梯度范数 G_i shared_grad_norms = [] for i in range(M): grads = torch.autograd.grad( task_weights[i] * raw_losses[i], shared_params, retain_graph=True, create_graph=False # 注意这里 ) grad_norm = torch.norm(torch.cat([g.view(-1) for g in grads if g is not None])) shared_grad_norms.append(grad_norm) # 3. 计算GradNorm损失并更新权重 gn_loss = get_gradnorm_loss(raw_losses, task_weights, shared_grad_norms, alpha) gradnorm_optim.zero_grad() gn_loss.backward(retain_graph=True) gradnorm_optim.step() # 4. 重归一化权重 with torch.no_grad(): renormalize = M / sum(task_weights) task_weights *= renormalize # 5. 主训练loss并更新网络参数 total_loss = sum(task_weights[i] * raw_losses[i] for i in range(M)) optimizer.zero_grad() total_loss.backward() optimizer.step()

注意第2步里我用的是task_weights[i] * raw_losses[i]去求“加权损失对共享参数”的梯度。因为G_i本来就定义为加权后的梯度范数，这样才能把权重变化的直接影响传进去。第3步里gn_loss.backward()是在计算loss权重的梯度，这时候retain_graph=True是为了后续主训练loss继续使用同一张计算图。第5步主优化器更新网络参数，权重已经在这之前更新好了。

关于create_graph=False，我一开始踩过这个坑。一开始写成create_graph=True，因为在某些GradNorm实现里，如果G_target还要依赖更深的梯度路径就要保留计算图。但主训练后面还要走一次总loss的反向传播，两次反向如果都要求二阶梯度，会显著增加显存和计算量。实际跑下来发现，G_target里用的L_avg和r_tilde本来就应该detach，权重更新的梯度只从|G_i - G_target_i|的差值流向w_i即可，所以create_graph=False是通用选择。

4.3 用在哪一层算梯度范数，效果差异很大

GradNorm论文里说的是“shared layers W”，但共享层很多层，选哪些层作为W，会直接影响整个算法的行为。我和同事对比过两种情况。

第一种是拿“最后一个共享层”的参数，也就是紧挨着任务分支的那一层，英文一般叫last shared layer。这个位置的梯度范数能直接反映出任务分支收到的共享特征质量，对任务差异最敏感。

第二种是拿“整个backbone的参数”做总的梯度范数，也就是对backbone所有参数的梯度做平坦化后取L2范数。这一个全局范数反映的是任务对整体特征提取网络的影响，训练中更稳定，但会导致GradNorm更新权重的信号被大量层平均后“稀释”。

我实际用起来更推荐第一种。因为在大多数时序里，任务分支之间共享的就是backbone的高层特征，这一层特征的任务相关性最强，在这层上做梯度归一化，能让GradNorm更敏锐地感知到哪条任务分支在“抢资源”。第二种在任务数量较多、各任务网络结构差异较大的时候更稳，因为单个共享层的梯度噪声可能比较大，全局规范化之后更平滑。但如果你用的是标准Unet或者ResNet共享backbone加多头的结构，优先试last shared layer。

5. 实测复盘：我把GradNorm用在哪些任务上，效果如何

5.1 实验一：UCI多任务回归——梯度范数极不均衡的极端案例

我第一次跑GradNorm用的数据集是多任务回归的经典benchmark，包含两个回归任务，特征维度50左右，任务loss量级差异高达20倍。这就非常适合观察GradNorm的威力，因为固定权重方案必然出现“大任务压制小任务”的严重情况。

初始固定权重方案我选了w=[1,1]和w=[20,1]两个对照组。w=[1,1]的结果正如所料，小任务（损失量级大的那个）几乎完全被压制，大任务（损失量级小但梯度大的）收敛到不错水平，小任务指标差得离谱。w=[20,1]呢，刚开始小任务确实被强行拉了回来，但训练到第50个epoch时，大任务权重虽然固定为1，小任务的影响却在收益递减后开始干扰大任务的训练，导致大任务最终指标反而不如“不干预”方案。

换成GradNorm后，训练过程的权重曲线很有规律：前5个epoch，权重自动从小任务的初始1往下调整，大任务的权重从1上探到3左右；到第30个epoch后两者稳定在一个小范围内波动。最终结果上，GradNorm方案的两个任务指标都超过了手动调参得到的“最佳折中”，而且全程我只需要设定α=0.5和权重学习率0.025，没有再人工干预。这里我的实际经验是，如果你的任务数量和任务loss量级差异很大，GradNorm往往比手动调参省下的时间更多，因为手动方案可能需要尝试的组合数是指数级的。

5.2 实验二：语义分割+深度估计的多任务——踩过的三个关键坑

第二个实验是我最常用的组合场景：一个共享Unet-like encoder，上面挂两个head，一个是语义分割、一个是深度估计。图像输入512x512，batch size 16。

第一次跑，我直接把GradNorm接上去，结果训练到第10个epoch时loss权重开始疯狂抖动，从0.5到5来回震荡，网络根本稳定不下来。排查后发现三个问题。

第一个问题：批次样本质量差异导致的梯度噪声。我的数据里深度图有不少区域是无效值，mask掉的区域如果还参与梯度计算，深度任务的梯度范数会忽高忽低，导致权重震荡。解决办法是在计算每个任务的loss时先乘以一个任务内部的mask；如果某些图里任务B的mask有效区域非常少，这一个batch的任务B梯度范数就天然偏低。这个波动是数据层面的，GradNorm会当成“任务B学得好了”从而减小权重，其实只是这次的batch不包含有效信息。后来我加了一个滑动平均滤波：计算当前时刻的权重变化时，用前N个step的平均梯度偏差来做，N取20，效果稳定很多。

第二个问题：torch.autograd.grad的retain_graph=True在一次iteration里多次保留计算图，显存开销很大。512x512输入、batch 16，多任务loss下这一步直接多占掉了约35%的显存。解决办法是减少同时retain的图数量：先逐个任务用torch.autograd.grad(..., allow_unused=True)算梯度范数，同时把一部分梯度范数的求取放到主loss的backward之后用保存的梯度张量来算，而不是再单独反向。这样能省掉一半的额外开销。

第三个问题：权重的初始值。GradNorm论文里建议w全部初始化为1，我一开始照做了。但在多任务差距极大的场景，比如masked depth任务，深度任务的初始loss比分割任务大了一个量级，w从1开始会让第一个step的weight更新非常大，有可能直接导致训练发散。解决方案是给权重更新也配一个warmup，前100步用更小的学习率让权重慢慢从1变化，然后再切回正常的学习率。这算是我自己的补充经验，论文里没写，但实测下来非常有效。

5.3 几种常见对照：GradNorm和它的“兄弟们”

学GradNorm的时候，最好把常用的几个多任务loss加权方法放在一起对比，这样才能理解各自的边界。

第一种是uncertainty weighting，也叫“同方差不确定性加权”。它的做法是把每个任务的损失前面乘上1/(2σ_i²)，其中σ_i是数据噪声相关的可学习标量，更新时用log(σ_i)做正则，避免σ_i变成0。这个方法的优点是实现简单，每个任务只需要额外加一个参数；但它的问题是它假设任务间的差异可以用“同方差不确定性”来解释，实际碰到任务梯度方向冲突严重时不怎么有效，而且σ_i和梯度的关系比较间接。

第二种是Dynamic Weight Average，也叫DWA。它直接观察每个任务loss的下降速度，动态调整权重。具体做法是计算相邻epoch的loss比，如果这个epoch任务i的loss下降得多，就给这个任务更大权重。这个方法很直观、计算量很小，但它只依赖loss曲线，不直接看梯度，所以对“loss下降但梯度冲突严重”的情况会误判。

第三种是PCGrad，全称是Project Conflicting Gradients。它不调整权重，而是修改梯度方向：当两个任务的梯度方向夹角大于90度时，把其中一个任务的梯度往另一个的正交方向投影，去掉冲突的部分。这个方法适合任务目标有天然冲突的场景，比如“推荐准确率”和“推荐多样性”这种方向性不兼容的任务。它的局限在于计算量会随任务数增加，阻尼系数还要自己调。

对比下来，GradNorm的优势在于它直接观察“梯度范数”这个最底层的量，而且算法本身不需要预训练，不需要额外的网络结构，只是多了一组标量权重和一个小的优化器。局限性在于它假设任务之间可以共享特征并且训练过程中梯度方向没有根本冲突——如果两个任务走到后期梯度方向完全相反，光靠调整权重解决不了问题，这时候更好的做法是GradNorm配合PCGrad一起用。

6. 常见问题排查：GradNorm训练不收敛时，我都做了什么

6.1 权重震荡到无法收敛

我之前提到过梯度噪声导致权重震荡，这里再细说。如果你在tensorboard里看到task_weights呈现出明显的“锯齿形”波动，幅度很大，最先要检查的是batch数据量是否太小。我遇到过batch size 4下面权重每10步从0.2跳到5的情况，换成batch size 16后震荡幅度明显下降。如果必须用小batch，就给每个任务的梯度范数加EMA，比如G_i_ema = 0.9 * G_i_ema + 0.1 * G_i，用这个平滑值去计算GradNorm。

另外，检查一下你是否对每个任务的原始loss做过min-max归一化。有的任务loss天然分布在几百到几千，有的是0到1，不归一化时r_i的计算L_i / L_avg会严重偏向一个任务，导致权重emoji剧烈变化。我在代码里加的是每个任务除以它自己的初始loss，这样L_i_ratio = L_i / L_initial_i，然后再用L_ratio去算r_i，效果比直接用原始loss好很多。

6.2 GradNorm对主任务效果反而不如固定权重

这个现象我遇到过不止一次。原因是GradNorm的“均衡”哲学是平均主义——它会给慢任务更多权重，但如果“慢任务”本质上是个不可能学好、噪声极大的任务，GradNorm会持续把权重分给它，导致主任务被拖累。

解决思路有两种。第一种是加权命令里加一个“主任务强制下限”：比如主任务权重不能小于0.8或者其他自定义阈值。做法很简单，每次更新权重后overwrite一下：task_weights[main_task] = max(task_weights[main_task], 0.8)。第二种是给GradNorm加上“限制任务梯度范数的上限”：如果某个任务的梯度范数已经超过其他任务平均值的3倍，就把它对应的G_target截断，不让它的权重继续增加。这相当于人工加了最大推力上限，避免GradNorm无限“偏袒”某个死磕任务。

6.3 权重负值和零除问题

w_i作为可学习参数，直接用optimizer更新时有可能会变成负值或非常接近0，这在数学上不致命但会带来训练不稳定。重归一化步骤w_i = w_i * M / sum(w_i)如果sum非常小或接近0，就会产生极大的数值。我习惯在每个step更新后加一个clamp，比如w_i = clamp(w_i, 0.001, 100)，防止出现这种边界问题。

零除问题还有一个来源：如果某个任务的loss为0（比如一个batch里这个任务恰好没有有效样本），r_i算出来就是0，r̃_i会变成很大的负数或者除零。我在实现里加了一个兜底：所有任务的loss都加一个非常小的epsilon，例如1e-7，再参与计算。

6.4 显存和数据维度不匹配引发的隐蔽错误

最后说一个比较隐蔽的坑：torch.autograd.grad在计算共享层梯度时，如果你的共享层输出被多个计算路径复用，第一次求梯度后如果retain_graph=False，后面再对总loss做backward会报“graph already freed”的错。如果你在网络上测试过下面的报错：RuntimeError: Trying to backward through the graph a second time，那就是这个情况。

我的全局做法是：把任务loss的分梯度计算放在主loss backward之后再做，利用torch.autograd.grad直接读取主loss对各任务的梯度缓存，这样能避免一次iteration里两次反向。具体写法是：先total_loss.backward(retain_graph=True)，然后用task_weights[i].grad作为间接信息推导各任务权重更新；但这样对你代码结构约束比较大。如果你只是想把GradNorm作为第一版跑通，更省心的方案是老老实实在主backward之前逐个任务用torch.autograd.grad，同时保留计算图，并确保batch size相对小、显存预留充分。代价是多花一点显存，但代码结构好读好调试。

7. 什么时候该用GradNorm，什么时候不如不用

用的场景，我总结为三个条件同时成立时优先考虑。

条件一：你的多个任务共享一个网络主干，而且这个主干占了模型参数的绝大部分。如果每个任务是完全独立的网络，GradNorm没有任何必要，各个任务早就隔离开互不干扰了。

条件二：任务间的梯度存在“数量级差”，但方向没有根本对立。数量级差是多任务训练最常见的现象，GradNorm正是为这个场景设计的。

条件三：你有预算也想付出一点额外显存来换取“不手动调权重”的省心。GradNorm对多任务训练确实有收益，但它不会把一个“本来就是垃圾组合”的任务集合变成完美组合。

不适合用的场景也有。任务数量很多、超过10个的时候，w的优化空间会变得很大，GradNorm对每个w_i的更新可能会互相干扰，需要更复杂的优化策略；当任务间有共同梯度但目标函数里还有大量不可导的loss时（比如强化学习里用REINFORCE估计的reward），梯度范数的含义会变得很模糊，GradNorm的效果会打折扣。在这些场景下，简单可靠的方式还是先用固定权重尝试，等确实需要的时候再引入GradNorm。

实操中还有一种贴合的用法：先随机初始化权重跑50个epoch，观察各任务的梯度范数曲线，再用GradNorm从那批权重继续训练。我试过这种两段式方案，比从w=1直接开始GradNorm在最终效果上并没有更好，只是在训练初期更稳。不过如果你的任务差异极大，比如一个是有监督分类、一个是GAN loss，我确实推荐先固定权重跑热身后再接GradNorm，因为GAN loss的梯度范数非常不稳定，GradNorm在这种大量级噪声下会学到偏离直觉的权重分布。

8. 结尾：一个值得记住的小经验

我个人做了多次GradNorm实验后，最大的体会是：GradNorm不是银弹，它的价值在于把“调loss权重”这个玄学步骤变成“制定平衡策略”这个可解释过程。你不需要再盯着一堆loss曲线猜测哪个任务在挨饿，而是可以直接看task_weights的变化来解释为什么某个任务的精度上升了好几组。调试时的第一个问题不再是没有过程线索的“模型崩了”，而是有明确信号的“GradNorm认为任务A学得太快，降低了它的梯度贡献”。

最后分享一个小技巧：如果你在一次训练里用了GradNorm，后期发现任务A的效果不理想，想重新训练，不要只改任务A的权重——那样GradNorm下一次训练时又会自动生成另一边的新权重。正确做法是同时把任务A的head学习率降低一点，让GradNorm有更多空间去协调。任务分支学习率和权重是两个互补的维度：GradNorm管横向平衡，学习率管纵向收敛速度，两者配合好了，多任务训练的体验会完全不一样。