简介：本文对比MoE微调中“权重卸载到GPU”与“CPU就地协同计算”两类范式，解析二者在架构、性能瓶颈、显存与内存利用、调度复杂度及适用场景上的核心差异，帮助开发者在有限显存条件下判断何时应继续优化搬运、何时应让CPU直接参与专家计算，并给出选型依据与迁移注意事项。
随着超大规模MoE模型不断开源，模型参数规模持续攀升，多数研究者与开发者却只能通过API调用，难以在资源受限条件下进行微调。为了让模型“装得下”，业界常见做法是把CPU内存与GPU显存搭配使用：用容量更大的主存存放专家权重，再通过PCIe按需搬运到GPU上计算。这类方案统称为卸载范式（Offload），其代表思路包括将优化器状态、参数分片卸载到CPU内存等。
问题在于，“装得下”不等于“跑得快”。MoE的稀疏计算特性决定单次专家计算的耗时很短，而专家权重规模巨大，PCIe传输时间往往无法被计算时间掩盖。当权重搬运成为吞吐上限时，继续优化搬运方式收益有限。由此引出了另一类思路：CPU/GPU协同计算范式（Co-Computation），即让CPU直接使用留在主存中的权重完成专家计算，GPU专注计算密集的注意力模块。
本文对比的对象就是这两类范式：传统权重卸载范式与CPU–GPU协同计算范式。前者以“内存换显存、搬运后计算”为核心，后者以“计算位置前移、就地计算”为核心。
卸载范式：把CPU内存当作GPU显存的扩展池。训练或微调时，专家权重常驻主存，按路由结果将所需专家权重经PCIe搬到GPU，计算完成后再释放显存。其优化目标通常是“让传输与计算尽可能重叠”，例如通过预取、流水线、分块调度来掩盖传输延迟。
协同计算范式：承认搬运本身可能比计算更慢，于是改变执行位置——专家计算直接在CPU上完成，GPU负责注意力等计算密集部分，二者按层或按模块协同。其优化目标从“掩盖传输”转为“减少无效搬运、均衡两端算力”。
两者的共同点是都依赖CPU大容量内存来突破显存门槛；差异在于权重是否必须离开主存。
卸载范式的系统边界是“CPU作存储后端、GPU作唯一计算端”，权重必须跨越PCIe总线；协同计算范式把CPU升级为“第二计算端”，权重留在主存直接参与矩阵运算，总线只承载激活值、梯度等小体量数据。这一位置变化是两者最根本的区别。
卸载范式的瓶颈在传输带宽与延迟：即使传输与计算完美重叠，吞吐上限仍由权重搬运量决定。协同计算范式的瓶颈转移到CPU算力与内存带宽，以及CPU与GPU之间的任务均衡。原文指出，在前沿MoE微调负载下，把权重搬到GPU的耗时甚至长于在CPU上直接计算——这正是协同计算范式成立的动机。
卸载范式侧重预取与流水线设计；协同计算范式需要更精细的调度：例如提前转换权重布局以避免计算时再做格式转换，以及针对路由倾斜做动态线程调度，让热点专家在CPU侧获得更多线程资源。调度不当会抵消就地计算的优势。
两者都能降低显存占用，但卸载范式显存中仍需容纳搬运窗口与中间激活；协同计算范式显存压力更小，但主存带宽和容量成为新的容量规划重点。
卸载范式在专家计算耗时较长、权重传输可被较好掩盖时仍有价值；协同计算范式在“稀疏计算短、权重大、传输成为瓶颈”的MoE微调场景更具优势。若CPU算力过弱或主存带宽不足，协同计算的收益会收窄。
| 维度 | 传统权重卸载范式 | CPU–GPU协同计算范式 |
|---|---|---|
| 计算位置 | 仅GPU计算，CPU作存储 | CPU与GPU分别承担专家与注意力计算 |
| 主要瓶颈 | PCIe权重传输 | CPU算力、内存带宽、任务均衡 |
| 显存占用 | 较低但仍需搬运窗口 | 更低，权重常驻主存 |
| 调度重点 | 预取、流水线、传输重叠 | 布局预转换、路由倾斜下的动态线程调度 |
| 优化上限 | 受限于搬运量 | 受限于两端算力配比 |
| 适用场景 | 计算耗时可掩盖传输 | 稀疏计算短、传输主导的MoE微调 |
选型时可先回答三个问题：专家单次计算耗时是否显著大于权重传输耗时？CPU是否具备可用的向量/矩阵运算能力与足够内存带宽？团队是否愿意承担更复杂的调度调优？若传输主导且CPU资源可用，协同计算范式更值得评估；若计算占主导或CPU较弱，卸载范式仍是稳妥选择。
迁移时需注意：权重布局需提前转换以匹配CPU计算内核；路由倾斜会导致线程负载不均，需要动态调度策略；CPU与GPU的同步点增多，需关注稳定性与故障恢复；监控指标应从“传输带宽”扩展到“CPU利用率、内存带宽、两端等待时间”。建议先在单机小规模LoRA微调上验证吞吐与收敛，再逐步扩大。
两类范式的核心差异不在“是否用CPU内存”，而在“权重是否必须搬到GPU”。卸载范式围绕搬运做优化，协同计算范式则通过改变执行位置绕开搬运瓶颈。理解这一区别，结合自身硬件配比与负载特征做条件化选择，才能在有限显存下获得可预期的微调效率。