KTransformers：单 GPU 跑 671B MoE 模型的清华方案

6710 亿参数的 DeepSeek-V3 跑在单张 RTX 4080（16GB VRAM）上，解码速度超过 20 tokens/s——这是清华大学 MADSys 实验室开源的 KTransformers 项目给出的成绩。该项目于 2025 年 10 月在 SOSP（ACM 操作系统原理研讨会）发表，迄今 GitHub 收获 18,800+ stars，已成为本地部署超大 MoE 模型的事实标准工具之一。

问题：MoE 模型的内存墙

Mixture-of-Experts（MoE）架构通过每个 token 只激活一小部分专家网络来实现计算稀疏性。DeepSeek-V3 总参数 671B，但每次推理只激活约 37B 参数。这种稀疏性带来一个工程矛盾：模型的计算量不大，但权重体积庞大。671B 参数在 BF16 精度下需要约 1.3 TB 内存，远超任何单张 GPU 的 VRAM 容量。

云端的解决方案是大规模集群推理——数万请求汇聚成一个 batch，GPU 利用率拉满。但本地部署场景（单用户、batch size = 1）无法走这条路。GPU 太小放不下，CPU 内存够大但太慢，成了死结。

KTransformers 论文测量了使用 Fiddler（此前的 CPU/GPU 混合推理方案）在一张 A100 + 双路 Intel Xeon 8452Y 上跑 DeepSeek-V3 的性能：预填充阶段 70.02 tokens/s，解码阶段仅 4.68 tokens/s，GPU 利用率低于 30%。CPU 成了瓶颈，GPU 大量时间在空转。

三层优化：从 7% 到 100% 的利用率

KTransformers 的核心创新可以拆解为三个技术层级，逐层消除性能瓶颈。

第一层：AMX 感知的 CPU 内核

在 MoE 混合推理中，路由到 CPU 的专家计算是最耗时的部分。PyTorch 虽然集成了 Intel oneDNN 的 AMX 内核，但实测性能仅达到理论峰值的 7%。根因在于内存布局不够友好——AMX 指令集要求特定形状的数据 tile（16 行 × 64 字节），而 PyTorch 默认的行优先布局与 AMX 的 tile 结构不匹配，导致频繁的缓存未命中和内存带宽浪费。

KTransformers 重新设计了内存布局。它采用 tiling-aware 的数据排列，让权重矩阵预先按 AMX tile 形状组织，加载时直接从 L2 缓存填充到 tile 寄存器，最大限度减少 DRAM 访问。微基准测试显示，这套优化后的 AMX 内核在 DeepSeek-V3 的 MoE 层上达到 21.3 TFLOPS，比 vendor 优化的 PyTorch oneDNN 基线快 3.98 倍。

但 AMX 并非万能。解码阶段每次只处理一个 token（或极少 token），每个专家分到的 token 数很少，算术强度（Arithmetic Intensity，每字节内存访问完成的浮点运算数）极低。此时 AMX 强行处理整个 tile 反而浪费。KTransformers 的解法是混合指令集：当每个专家分配到的 token 数 ≤ 4 时，自动切换到更轻量的 AVX-512 内核，避免 AMX 的 tile 加载开销。这一策略在解码阶段带来 1.20 倍加速，在预填充阶段对比纯 AVX-512 则有 10.81 倍优势。

在此基础上，KTransformers 还做了算子级融合（Operator Fusion）：将 MoE 层中多个小矩阵乘法（Gate、Up、Down 投影）合并为两个批次执行，减少线程同步开销。动态任务调度则确保同一专家的计算被合并处理，进一步提升缓存命中率。

第二层：异步 CPU-GPU 协调

混合推理的一个固有开销是 CPU 和 GPU 之间的同步延迟。传统方案中，每层 MoE 和 Attention 的执行都需要 CPU→GPU 的同步等待，GPU 内核启动本身就有可观的延迟，累积下来造成 GPU 利用率低下。

KTransformers 用 CUDA Graph 封装整个解码阶段的计算图。与标准用法不同（标准 CUDA Graph 要求固定张量形状，且每个 batch size 需要单独实例，VRAM 开销大），KTransformers 利用 CUDA spinning 技术，将动态形状的 CPU/GPU 混合前向传播封装进单个 CUDA Graph 实例。这一优化将 GPU 调用开销从 20% 以上降到接近零，解码阶段提速 1.23 倍。

第三层：Expert Deferral——让 CPU 和 GPU 真正并行

即使有了前两层优化，DeepSeek-V3 在 A100 + 双路 Xeon 配置下的解码速度仍只有 5.87 tokens/s。性能分析显示：CPU 利用率 74%，GPU 利用率仅 28%——两者交替执行，大量时间在互相等待。

Expert Deferral 是 KTransformers 论文的核心创新。在标准 MoE 推理中，每一层的路由专家全部计算完成后，才会进入下一层的 attention 模块。Expert Deferral 打破了这个顺序：在每层 MoE 中，只立即处理一部分专家（immediate experts），将其余专家（deferred experts）推迟到与下一层的 attention 计算并行执行。

关键在于确定推迟多少专家。推迟太少，CPU 和 GPU 的重叠不足；推迟太多，模型行为可能改变。论文的策略是：在不饱和 CPU 利用率的前提下推迟尽可能少的专家，同时确保至少 2 个 immediate expert 保持稳定。对于 DeepSeek-V3，BF16 模型推迟 3 个专家，量化模型推迟 6 个。

效果显著：CPU 利用率从 74% 提升到接近 100%，GPU 利用率从 28% 提升到 37%，解码吞吐量额外提升 33%（最高达 45%）。叠加前两层优化后，总体解码加速达到 1.66-4.90 倍。

准确性代价：≤0.5% 的精度波动

推迟部分专家意味着改变了模型的原始执行结构。论文在多个基准测试上验证了精度影响：

每项分数波动均在 2 分以内，部分任务甚至有所提升。平均精度下降不超过 0.5%。

端到端性能：消费级硬件跑 DeepSeek-V3

以下是论文报告的端到端基准数据。测试硬件为双路 Intel Xeon Platinum 8452Y（每路 36 核），1TB DDR5 内存，搭配 NVIDIA A100（40GB）或 RTX 4080（16GB）。

预填充阶段（prompt 处理速度），KTransformers 在所有 prompt 长度上均领先：

解码阶段（生成速度），对比最接近的 Llama.cpp 基线：

BF16 模型在完整精度下，KTransformers 对比 Fiddler 实现了 2.42-4.09 倍的解码加速。量化模型场景下，由于 CPU 和 GPU 内核执行时间更短，同步优化的收益被进一步放大，KTransformers 对比 Llama.cpp 有 1.77-1.93 倍解码加速。

SGLang 集成与生态扩展

KTransformers 的能力已通过 SGLang 集成进入生产部署链路。SGLang 将 KTransformers 作为后端库接入，实现 GPU Tensor Parallelism 与 CPU/GPU Hybrid Expert Parallelism 的组合，使万亿参数模型可以在单机有限 VRAM 环境下部署。

在 8×L20 GPU + Xeon Gold 6454S 配置上，DeepSeek-R1-0528（FP8）的总吞吐达到 227.85 tokens/s，输出吞吐 87.58 tokens/s（8 路并发）。

微调能力

除了推理，KTransformers 还与 LLaMA-Factory 集成提供 SFT 微调能力。核心卖点是让超大 MoE 模型在有限 GPU 上完成 LoRA 微调：

论文报告在 MoE SFT 基准测试中，KTransformers 的训练速度比 ZeRO-Offload 快 6-12 倍，同时 CPU 内存占用约为此前 KT SFT 路径的一半。

模型支持

截至目前，KTransformers 已实现 Day0（发布当天）支持的主流模型包括 DeepSeek-V3/V4 系列、Kimi K2/K2.5/K3、GLM-5/5.2、MiniMax-M2.1/M2.5/M3、Qwen3-Next 等，覆盖了当前几乎所有头部 MoE 架构。

实用意义与适用场景

KTransformers 的价值在于让三类用户受惠：

注重隐私的本地部署。医疗、金融、法律等领域的数据不能上传云端 API，但本地又没有 GPU 集群。KTransformers 让一台配好 CPU + 单张消费级 GPU 的工作站就能跑 671B 模型。

模型研究。需要在模型内部插入探针、修改注意力机制、追踪专家激活模式的研究者，本地部署比远程 API 有天然优势。KTransformers 保持与 HuggingFace Transformers 的完全兼容，现有代码无需改动。

成本敏感的推理服务。在低并发场景下，一台 CPU+GPU 混合服务器比多卡 GPU 集群的硬件成本低一个数量级。KTransformers 论文指出，该项目目前已在数百台机器上运行，服务于需要本地部署安全审计或模型内部研究的团队。

KTransformers 用 11,000 行 C++ 扩展和 2,000 行 Python 脚本，把"万亿参数模型跑在消费级硬件上"从实验室原型推进到了可复现的工程系统。对于一个 MoE 推理框架来说，SOSP 这个操作系统顶会的发表也意味着学术界对"大模型系统软件"这个方向的正式认可。