别再让计算等着搬权重了！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 参数及优化器状态统一放入连续缓冲区，让优化器顺序访问、批量更新；前向和反向则通过无需复制的张量视图，访问各专家自己的参数。

图 2｜PyTorch-AMX 与 KT-FT 的布局引擎对比。来源：论文图 5。

其次是线程调度。MoE 路由会把大量 token 分给少数热门专家，而冷门专家的工作量很小。如果只在单个专家内部组织并行计算，部分线程就会等待。KT-FT 的动态线程调度器将各专家的工作拆成细粒度任务，放入共享队列，再通过工作窃取在 CPU 线程间分配，减少派发停顿与同步等待。

协同计算到底带来了多少收益

我们在 DeepSeek-V3.1-671B、Qwen3.5-397B 和 Qwen3-235B-2507 三款数千亿参数 MoE 模型上进行了评估，实验覆盖 Intel AMX 和 AMD AVX-512 平台的单卡与多卡配置，使用双路服务器 CPU，主存容量为 1–2TB。

在这些配置下，KT-FT 的标准 LoRA 微调吞吐达到卸载基线的 2.5–21.2 倍，短序列时优势更明显。随着序列增长，每次权重传输对应的计算量增加，卸载更容易利用计算掩盖传输，相对差距也随之缩小。单卡 DeepSeek 吞吐测试采用 FP8/INT8；前文 BF16、2K 序列下使用 16GB GPU 显存完成微调的结果，来自另一项配置。

图 3｜不同序列长度下的微调吞吐。

为了区分范式变化与具体系统优化的作用，我们还比较了采用相同 CPU/GPU 分工的 PyTorch (OneDNN) 实现。在图 3 (a) 平台的 2K 设置下，这一实现只有 12.1 tokens/s，KT-FT 则达到 166.8 tokens/s。可见，让 CPU 参与专家计算只是起点；布局引擎和线程调度器进一步降低执行开销，才使这套分工获得端到端的吞吐收益。

System-Algorithm Co-Design：把剩余显存用于更快达到质量目标

上述系统设计解决了标准 LoRA 的执行效率问题。不过 GPU 的主要工作集分配完成后，通常还会留下少量可用显存，我们进一步考虑如何利用这部分资源。如果仅采用系统层面的优化，动态迁移专家方法会增加 PCIe 传输和布局转换开销；静态放置方法则只能容纳少量专家，还依赖稳定的热点，两种方法对达到目标质量所需时间的改善都不到 10%。

为此，我们提出系统算法 Co-Design 的方式， LoRA Expert（LE），作为独立于布局和调度优化的可选设计。LE 在每个 MoE 层增加一条常驻 GPU 的共享适配路径，也正好适配了 KT-FT 的 GPU/CPU Co-Computation 范式。

图 4｜KT-FT 在有限显存中保留少量热门专家。

算法层面，这一设计也回应了微调中的更新不均问题。下游数据分布变化时，路由可能集中到少数热门专家，许多冷门专家只能获得很少的更新。LE 的共享分支由所有 token 共同训练：即使某个 token 被分配给冷门专家，也能利用这条共享路径学到的适配信息。

图 5｜四种 LoRA 方法的验证损失随归一化微调时间变化。

同时，LE 的接入位置和计算方式不依赖具体的 LoRA 更新规则，因此能够分别与不同的 LoRA 算法变体组合使用。我们用 Time-to-Quality（TTQ）衡量这项设计：微调达到可比较质量目标，实际需要多长时间。另外，我们也通过两种对照分别检验不同的参数分配方式，来验证把这部分显存预算交给 LE，是否比继续扩大原有适配路径更有效。

KT-FT 生态与实际场景部署

我们已将 KT-FT 作为执行后端接入 LlamaFactory。开发者可以沿用熟悉的微调流程，并通过官方指南完成硬件检查、配置选择和微调。KTransformers 也由此从本地推理延伸到微调，让已有的 CPU/GPU 资源能够支持更大规模的模型适配与探索。

KT-FT 的三类核心应用场景举例：

（1）企业适配：业务需要更大的模型，本地算力却跟不上。企业的私有数据需要留在本地，但显存和微调成本限制了能用的模型规模。借助 KT-FT，海信将下游适配的模型从 30B 扩展到 397B，并用 8 张 RTX 4090 完成 LoRA 微调。相比 16 张 A100 上的基线框架，平均端到端耗时从 22.4 小时缩短至 14.3 小时，每次迭代的直接计算成本降低 81.5%。

（2）模型研发：新算法要反复验证，试验成本直接影响迭代速度。前沿模型规模越大，验证一个新想法所需的训练资源和时间就越多。Joy AI 研究员通过 KT-FT 在 RTX 4090 上，以 65K token 上下文对约 700B MoE 进行 LoRA 微调，充分利用闲置开发机试验和迭代新算法。

（3）实验室研究：算力有限，也要能在前沿大模型上验证算法。对很多高校的研究团队来说，缺少高显存 GPU，只能在较小的模型上进行研究。KT-FT 让实验室利用有限的本地 GPU 直接开展超大模型实验：团队能够通过用 RTX 4090 微调 Qwen3.5-397B 等最前沿模型的记忆机制、生成多样性等问题。

• 论文：https://github.com/kvcache-ai/ktransformers/blob/main/papers/kt-ft/ktransformers-finetune.pdf

• 官方微调指南：https://github.com/kvcache-ai/ktransformers/blob/main/doc/en/SFT/KTransformers-Fine-Tuning_Cookbook.md