别再让计算等着搬权重了！KTransformers让CPU直接参与MoE微调计算
从 DeepSeek-V4 到 Qwen-3.8、Kimi-K3、GLM-5.3，每⼀次超⼤模型的开源都带来性能上的巨⼤跃升。然⽽，随着模型规模越来越大，多数研究者与开发者只能尝试调用 API，无法在资源受限条件下进行微调，这进一步限制了大家探索前沿模型的特性，也难以把他们适配到自己的业务任务中。为降低 GPU 显存需求，之前的工作把 CPU 和 GPU 搭配起来，用容量更大的 CPU 内存存储专家权重，再通过 PCIe 搬到 GPU 上计算。这种办法能够让模型装得下了，但是微调速度很慢，效率难以达到大家的使用预期。
这次， 在清华大学 MADSys 实验室、趋境科技主导下，我们提出 KTransformers-FineTune（KT-FT），并联合知名开源项目 LlamaFactory 团队一起，打造用户友好、易用的开源生态 。KT-FT 通过 CPU 与 GPU 协作，吞吐达到传统卸载范式的 2.5～21.2 倍。同时，我们也坚持全面开源，为社区、学界和业界提供了低成本微调 - 推理方案闭环，实现 LoRA 微调和推理可以在同等硬件条件下一键执行。
之前微调中的 GPU/CPU 协作的工作主要都在围绕搬运权重的范式来思考怎么进一步优化，希望用 GPU 计算时间更多的掩盖 PCIe 搬运。可 MoE 的稀疏计算耗时很短，根本盖不住大规模权重的传输。 在单机有限显存的场景下，即使传输与计算完美重叠，权重搬运仍然决定了微调的吞吐上限，传统范式无论如何优化权重的搬运方式都是徒劳。 要真正提速，就必须改变专家的执行位置，让 CPU 用留在主存中的权重直接完成专家计算，与 GPU 协同工作。
KT-FT 发现，在当前前沿 MoE 模型的微调负载下，把这些权重搬到 GPU 的耗时，甚至长于在 CPU 上直接计算。并因此提出 CPU/GPU 协同计算（Co-Computation）范式，直接利用 CPU 的计算能力，把 CPU 从一个 “存储库” 转为协同执行专家计算，GPU 则继续负责计算密集的注意力模块。然而，仅仅通过 Co-Computation 范式让 CPU 参与计算，还不足以带来足够有效的微调方案。KT-FT 提出语义感知主动布局引擎提前转换布局，并优化路由倾斜的动态线程调度。这些设计使 KT-FT 的 Co-Computation 范式吞吐达到传统卸载范式（如 ZeRO-Offload）的 2.5 倍以上。
KT-FT 的核心 Motivation：当搬运权重比 CPU 就地计算更慢
图 1｜卸载范式与 CPU–GPU 协同计算范式的区别。 显存装不下时，已有方法通常也会利用 CPU 内存，用 “内存换显存”，降低微调的显存门槛。但模型装得下、微调跑得起来，只说明容量足够；如果大部分时间仍在等待权重搬运，微调依然难以高效运行。
如图 1 (b) 所示，已有方法采用的卸载范式（offload paradigm）中，专家的前向和反向矩阵运算仍在 GPU 上完成，CPU 侧负责存储专家权重、梯度和优化器状态，仅作为一个更大容量的 “存储库” 被使用。这保留了 GPU 在计算能力上的优势，但也带来了经 PCIe 反复搬运权重的代价。在之前密集（dense）模型的负载下，卸载范式的优化通常依赖于 GPU 计算时间足够长，能够覆盖 PCIe 传输与同步的时间。
但是在当前主流 MoE 的稀疏负载下，这一前提会失效。MoE 会把 token 分配给不同专家，许多专家一次只收到少量 token，很快便能完成计算，但是所需的专家权重却仍都要传到 GPU 上。我们测试发现，ZeRO-Offload 的通信与任务同步占去了 94% 的单步时间；APTMoE 采用专家级流水调度后，权重传输与同步仍占执行时间的 86%。预取和流水调度能够调整搬运时机，却省不掉这些权重的传输，而且在低算术强度下，计算本身也不足以掩盖传输时间。
更进一步，哪怕是理想情况下，以每单位 1B（10 亿）个 BF16 参数为例，前向与反向共需传输 4GB 数据。哪怕能够达到 PCIe 5.0 ×16 的理论峰值带宽 64GB/s，传输仍需要 62.5ms，而 RTX 5090 完成相应前向与反向计算只需 2.8ms，传输耗时超过计算的 22 倍。也就是说，即便 GPU 能更快完成矩阵乘法，微调仍要等待权重到达。 卸载所依赖的 “用计算掩盖搬运” 因此失效。
换言之， 仅搬运专家权重，就比 CPU 完成专家计算耗时更长， 这使 CPU/GPU Co-Computation 范式成为更合适的选择。因此 KT-FT 在 CPU 上利用 AVX-512/AMX 指令集完成 MoE 部分的计算，而在 GPU 上完成 Attention 部分的计算。
让协同计算范式真正带来微调提速
选择由 CPU 执行专家之后，我们还需要控制布局转换与线程同步的代价。按上述负载的成本分析， CPU 专家计算耗时与布局、同步开销之和，必须低于原先的权重传输时间。 我们用 PyTorch (OneDNN) 实现相同的 CPU/GPU 分工时发现，在较长序列下，它甚至比卸载更慢。因此，KT-FT 必须要解决布局冲突和线程负载不均这两个问题。
首先是内存布局。推理只需要前向计算，微调还增加了反向传播和优化器更新。同一份参数在不同设备、不同阶段的访问方式不同，临时转换布局会使计算停下来等待。为此，我们设计了 语义感知主动布局引擎 ，在分配内存时就按张量的用途和执行阶段选择合适的布局。
前向和反向之间仍然需要切换权重布局。之前的实现方式要么会使用非最佳的计算布局、要么会需要多存一份参数副本而占用双倍内存，KT-FT 利用跨层执行顺序，让后台线程提前、原地完成转换，并与 GPU 计算重叠。这样既能使用最优的计算布局，并把转换开销移出关键路径，也只需保留一份参数副本。KT-FT 将各专家的 LoRA 参数及优化器状态统一放入连续缓冲区，让优化器顺序访问、批量更新；前向和反向则通过无需复制的张量视图，访问各专家自己的参数。