文章核心观点 - 超大模型开源带来性能跃升，但多数研究者与开发者只能调用API，无法在资源受限条件下微调，限制了前沿模型特性探索与业务适配 [1] - 传统CPU/GPU搭配卸载范式虽能降低显存门槛，但微调速度慢，效率难以达到使用预期 [1] - 清华大学MADSys实验室与趋境科技主导提出KTransformers-FineTune（KT-FT），联合LlamaFactory团队打造开源生态 [1] - KT-FT通过CPU与GPU协作，吞吐达到传统卸载范式的2.5～21.2倍，提供低成本微调-推理方案闭环，实现LoRA微调和推理在同等硬件条件下一键执行 [1] 传统卸载范式的局限 - 已有工作围绕搬运权重范式优化，希望用GPU计算时间掩盖PCIe搬运，但MoE稀疏计算耗时短，根本盖不住大规模权重传输 [2] - 单机有限显存场景下，即使传输与计算完美重叠，权重搬运仍决定微调吞吐上限，传统范式优化权重搬运方式徒劳 [2] - 卸载范式中专家前向和反向矩阵运算仍在GPU完成，CPU仅作为更大容量存储库，带来经PCIe反复搬运权重的代价 [6] - 密集模型负载下，卸载范式优化依赖GPU计算时间足够长以覆盖PCIe传输与同步时间 [6] - 当前主流MoE稀疏负载下该前提失效，MoE将token分配给不同专家，许多专家一次只收到少量token，很快完成计算，但所需专家权重仍都要传到GPU [7] - 测试发现ZeRO-Offload通信与任务同步占94%单步时间，APTMoE采用专家级流水调度后权重传输与同步仍占执行时间86% [7] - 预取和流水调度能调整搬运时机，却省不掉权重传输，低算术强度下计算本身也不足以掩盖传输时间 [7] - 理想情况下以每单位1B（10亿）个BF16参数为例，前向与反向共需传输4GB数据，PCIe 5.0×16理论峰值带宽64GB/s下传输仍需62.5ms，而RTX 5090完成相应前向与反向计算只需2.8ms，传输耗时超过计算22倍 [7] - 仅搬运专家权重就比CPU完成专家计算耗时更长，使CPU/GPU Co-Computation范式成为更合适选择 [8] KT-FT的CPU/GPU协同计算范式 - KT-FT发现当前前沿MoE模型微调负载下，把权重搬到GPU的耗时甚至长于在CPU上直接计算 [3] - 提出CPU/GPU协同计算（Co-Computation）范式，直接利用CPU计算能力，把CPU从存储库转为协同执行专家计算，GPU继续负责计算密集的注意力模块 [3] - KT-FT在CPU上利用AVX-512/AMX指令集完成MoE部分计算，在GPU上完成Attention部分计算 [8] - 仅通过Co-Computation范式让CPU参与计算还不足以带来足够有效的微调方案 [3] - KT-FT提出语义感知主动布局引擎提前转换布局，并优化路由倾斜的动态线程调度，使Co-Computation范式吞吐达到传统卸载范式（如ZeRO-Offload）的2.5倍以上 [3] 布局引擎与线程调度优化 - 选择由CPU执行专家后，需控制布局转换与线程同步代价，CPU专家计算耗时与布局、同步开销之和必须低于原先权重传输时间 [10] - 用PyTorch (OneDNN)实现相同CPU/GPU分工时发现，较长序列下甚至比卸载更慢，因此KT-FT必须解决布局冲突和线程负载不均两个问题 [10] - 推理只需前向计算，微调还增加反向传播和优化器更新，同一份参数在不同设备、不同阶段访问方式不同，临时转换布局会使计算停下来等待 [11] - 设计语义感知主动布局引擎，在分配内存时就按张量用途和执行阶段选择合适的布局 [11] - 前向和反向之间仍需切换权重布局，之前实现要么使用非最佳计算布局、要么需多存一份参数副本占用双倍内存 [11] - KT-FT利用跨层执行顺序，让后台线程提前、原地完成转换，并与GPU计算重叠，既能使用最优计算布局，把转换开销移出关键路径，也只需保留一份参数副本 [11] - KT-FT将各专家LoRA参数及优化器状态统一放入连续缓冲区，让优化器顺序访问、批量更新；前向和反向通过无需复制的张量视图访问各专家自己的参数 [11] - MoE路由会把大量token分给少数热门专家，冷门专家工作量很小，如果只在单个专家内部组织并行计算，部分线程就会等待 [12] - KT-FT动态线程调度器将各专家工作拆成细粒度任务，放入共享队列，再通过工作窃取在CPU线程间分配，减少派发停顿与同步等待 [12] 协同计算收益评估 - 在DeepSeek-V3.1-671B、Qwen3.5-397B和Qwen3-235B-2507三款数千亿参数MoE模型上评估，实验覆盖Intel AMX和AMD AVX-512平台单卡与多卡配置，使用双路服务器CPU，主存容量1–2TB [14] - KT-FT标准LoRA微调吞吐达到卸载基线的2.5–21.2倍，短序列时优势更明显 [14] - 随着序列增长，每次权重传输对应计算量增加，卸载更容易利用计算掩盖传输，相对差距随之缩小 [14] - 单卡DeepSeek吞吐测试采用FP8/INT8；BF16、2K序列下使用16GB GPU显存完成微调的结果来自另一项配置 [14] - 比较采用相同CPU/GPU分工的PyTorch (OneDNN)实现，在2K设置下该实现只有12.1 tokens/s，KT-FT则达到166.8 tokens/s [17] - 让CPU参与专家计算只是起点，布局引擎和线程调度器进一步降低执行开销，才使这套分工获得端到端吞吐收益 [17] 系统算法Co-Design与LoRA Expert - GPU主要工作集分配完成后通常还会留下少量可用显存，需进一步考虑如何利用这部分资源 [19] - 仅采用系统层面优化，动态迁移专家方法会增加PCIe传输和布局转换开销；静态放置方法只能容纳少量专家，还依赖稳定热点，两种方法对达到目标质量所需时间改善都不到10% [19] - 提出系统算法Co-Design方式LoRA Expert（LE），作为独立于布局和调度优化的可选设计 [19] - LE在每个MoE层增加一条常驻GPU的共享适配路径，正好适配KT-FT的GPU/CPU Co-Computation范式 [19] - 算法层面，该设计回应微调中的更新不均问题，下游数据分布变化时路由可能集中到少数热门专家，许多冷门专家只能获得很少更新 [21] - LE共享分支由所有token共同训练，即使某个token被分配给冷门专家，也能利用这条共享路径学到的适配信息 [21] - LE接入位置和计算方式不依赖具体LoRA更新规则，因此能分别与不同LoRA算法变体组合使用 [23] - 用Time-to-Quality（TTQ）衡量该设计：微调达到可比较质量目标实际需要多长时间 [23] - 通过两种对照分别检验不同参数分配方式，验证把这部分显存预算交给LE是否比继续扩大原有适配路径更有效 [23] KT-FT生态与实际场景部署 - KT-FT已作为执行后端接入LlamaFactory，开发者可沿用熟悉的微调流程，并通过官方指南完成硬件检查、配置选择和微调 [25] - KTransformers由此从本地推理延伸到微调，让已有CPU/GPU资源能够支持更大规模模型适配与探索 [25] - 企业适配场景：海信将下游适配模型从30B扩展到397B，用8张RTX 4090完成LoRA微调，相比16张A100上的基线框架，平均端到端耗时从22.4小时缩短至14.3小时，每次迭代直接计算成本降低81.5% [26] - 模型研发场景：Joy AI研究员通过KT-FT在RTX 4090上，以65K token上下文对约700B MoE进行LoRA微调，充分利用闲置开发机试验和迭代新算法 [26] - 实验室研究场景：KT-FT让实验室利用有限本地GPU直接开展超大模型实验，团队能够用RTX 4090微调Qwen3.5-397B等最前沿模型的记忆机制、生成多样性等问题 [27]