权重

之前微调中的GPU/CPU协作的工作主要都在围绕搬运权重的范式来思考怎么进一步优化，希望用GPU计算时间更多的掩盖PCIe搬运。

要真正提速，就必须改变专家的执行位置，让CPU用留在主存中的权重直接完成专家计算，与GPU协同工作。

为降低GPU显存需求，之前的工作把CPU和GPU搭配起来，用容量更大的CPU内存存储专家权重，再通过PCIe搬到GPU上计算。

MoE会把token分配给不同专家，许多专家一次只收到少量token，很快便能完成计算，但是所需的专家权重却仍都要传到GPU上。

如图1(b)所示，已有方法采用的卸载范式（offloadparadigm）中，专家的前向和反向矩阵运算仍在GPU上完成，CPU侧负责存储专家权重、梯度和优化器状态，仅作为一个更大容量的“存储库”被使用。

换言之，仅搬运专家权重，就比CPU完成专家计算耗时更长，这使CPU/GPUCo-Computation范式成为更合适的选择。

在单机有限显存的场景下，即使传输与计算完美重叠，权重搬运仍然决定了微调的吞吐上限，传统范式无论如何优化权重的搬运方式都是徒劳。

如果大部分时间仍在等待权重搬运，微调依然难以高效运行。

前向和反向之间仍然需要切换权重布局。

可MoE的稀疏计算耗时很短，根本盖不住大规模权重的传输。

APTMoE采用专家级流水调度后，权重传输与同步仍占执行时间的86%。

按上述负载的成本分析，CPU专家计算耗时与布局、同步开销之和，必须低于原先的权重传输时间。

预取和流水调度能够调整搬运时机，却省不掉这些权重的传输，而且在低算术强度下，计算本身也不足以掩盖传输时间。

这保留了GPU在计算能力上的优势，但也带来了经PCIe反复搬运权重的代价。

为降低GPU显存需求，之前的工作把CPU和GPU搭配起来，用容量更大的CPU内存存储专家权重，再通过PCIe搬到GPU上计算。

MoE会把token分配给不同专家，许多专家一次只收到少量token，很快便能完成计算，但是所需的专家权重却仍都要传到GPU上。

如图1(b)所示，已有方法采用的卸载范式（offloadparadigm）中，专家的前向和反向矩阵运算仍在GPU上完成，CPU侧负责存储专家权重、梯度和优化器状态，仅作为一个更大容量的“存储库”被使用。

换言之，仅搬运专家权重，就比CPU完成专家计算耗时更长，这使CPU/GPUCo-Computation范式成为更合适的选择。