清华大学MADSys实验室与趋境科技（Approaching.AI）联合研发了一个系统KTransformers，一张消费级显卡就能跑一个万亿级参数模型。
该系统的论文正式入选了计算机系统领域的顶级会议SOSP 2025。
混合专家（MoE）模型的稀疏性，特别适合混合CPU/GPU推理，尤其是在低并发场景下。
这种混合方法利用了CPU/DRAM的大而经济高效的内存容量和GPU/VRAM的高带宽。
现有的混合解决方案仍然受到CPU计算限制和CPU-GPU同步开销的瓶颈，严重限制了它们高效运行最先进的大型MoE模型（例如671B DeepSeek-V3/R1）的能力。
KTransformers，正是专为各种MoE模型的高效异构计算而设计的高性能推理系统，用来解决混合专家模型（Mixture-of-Experts，简称MoE）在个人电脑或小型服务器上部署的难题。
现在的MoE模型，参数量动辄几千亿甚至上万亿，性能强，但对硬件的要求也高得离谱。一个671B参数的模型，需要超过1TB的显存才能装下，而市面上顶级的游戏显卡RTX 5090也才24GB显存，专业级的NVIDIA A100也不过40GB。
KTransformers通过一系列技术创新，让CPU和GPU紧密配合，共同承担推理计算任务。
在预填充阶段（也就是模型理解你的长篇输入时）最高能加速19.74倍，在解码阶段（模型一个词一个词往外蹦字时）最高加速4.09倍。还把CPU的利用率从过去常见的75%左右，几乎拉满了到接近100%。这让优先考虑安全性或打算深入研究模型内部的用户，能本地部署大型MoE模型。
这套系统不仅学术上得到了认可，还已经在开源社区和行业中被广泛采用。
主流的高性能推理框架SGLang宣布，将深度集成KTransformers作为其后端。
KTransformers把CPU和GPU捏合到了一起
KTransformers的算术强度感知的混合推理内核，会根据计算任务的算术强度（Arithmetic Intensity，简称ARI）来分配工作。算术强度可以通俗理解为计算量和访存量的比值。比值高，说明这个任务需要大量的计算，但数据搬运不多，是计算密集型任务。比值低，说明计算不复杂，但需要频繁读写数据，是访存密集型任务。
当处理预填充阶段的长文本时，比如你扔给模型几千个字的文章让它总结，这时候激活的专家数量多，计算量巨大，属于高ARI任务。KTransformers就会调用CPU里的Intel AMX（英特尔先进矩阵扩展）指令集。
为了让AMX吃得饱、跑得快，团队还专门设计了配套的内存布局，比如分块量化、64字节对齐、分块感知子矩阵访问等等，减少数据搬运的瓶颈，让数据能像流水一样顺畅地喂给AMX。
而当模型进入解码阶段，一次只生成一个词，计算量小，激活的专家也少，属于低ARI任务。于是，KTransformers会切换到更轻量级的AVX-512内核来处理。
光有好的工人（计算内核）还不够，还得有好的流水线管理（任务调度）。
传统方案里，CPU和GPU的协作模式很笨拙。CPU给GPU派个活，然后就站着等GPU干完。GPU吭哧吭哧算完了，再告诉CPU，然后CPU才派下一个活。这中间的等待和通信时间，造成了大量的资源浪费，特别是在解码阶段，每一步只处理一个token（词元），这种启动延迟的开销占比能超过20%。
KTransformers设计了一套异步CPU-GPU任务调度机制，彻底改变了这种低效的合作模式。
它引入了CUDA Graph技术，可以把一系列GPU要干的活预先编译成一张图。这样一来，GPU每次执行任务时就不用再听CPU一步步指挥了，直接照图施工就行，内核启动的开销从20%以上几乎降到了零。
同时，它实现了真正的流水线并行。CPU在计算一部分专家任务的时候，GPU也没闲着，它在处理另一部分比如注意力机制的计算。两者互不等待，像两条平行的生产线，极大地提升了整体的吞吐效率。为了进一步优化，系统还做了NUMA（非统一内存访问架构）感知的张量放置，确保数据尽可能在离计算单元最近的内存区域，避免了昂贵的跨节点数据传输。
还有专家延迟（Expert Deferral）技术。既然CPU和GPU的速度不匹配，总有一个会等另一个，那能不能在不严重影响最终结果的前提下，策略性地让某些计算插队或者延后？
Expert Deferral机制会实时监控硬件的负载情况，动态决定某个专家的计算任务是立刻在GPU上执行，还是先放一放，交给相对空闲的CPU去处理。
通过这种灵活的腾挪，系统可以最大限度地填满CPU和GPU的每一个计算空隙，把硬件的潜力榨干。
这让CPU的利用率从之前的75%以下，飙升到接近100%，带来了额外的1.45倍吞吐提升。
这种延迟计算可能会带来微小的精度损失，但根据团队的测试，平均模型精度损失不超过0.5%，在各种基准测试中几乎可以忽略不计。
KTransformers的惊人表现
基于KTransformers已经跑通了的部署示例：
本地236B DeepSeek-Coder-V2。运行Q4_K_M版本，仅使用21GB VRAM和136GB DRAM，可在本地台式机上实现，得分甚至高于BigCodeBench中的 GPT4-0613。
本地671B DeepSeek-Coder-V3/R1。仅使用14GB VRAM和382GB DRAM，就能运行Q4_K_M版本。
KTransformers在配备Intel Xeon Platinum 8452Y CPU（36 核 × 2、1 TB DDR5）的双路服务器上的吞吐量性能，配备NVIDIA A100 （40 GB）用于全精度模型和NVIDIA RTX 4080（16 GB）用于量化模型。对DeepSeek-V3-0324（DS-3）、DeepSeek-V2.5-1210（DS-2）和Qwen2-57B-A14B（QW-2）进行了评估，在预填充和解码阶段将KTransformers与Llama.cpp和Fiddler进行了比较：
在预填充阶段，KTransformers在所有提示长度上始终优于两个基线。虽然Llama.cpp通过积极的运算符融合在短提示场景中显示出优势，而Fiddler则受益于长提示的AMX加速，但KTransformers通过利用AMX优化的CPU内核和改进的CPU/GPU协调来超越两者。例如，CPU MoE内核在DS-3上实现了21.3 TFLOPS，比PyTorch基线提高了3.98倍。
在解码阶段，KTransformers（没有专家延迟）比Fiddler实现了2.42–4.09倍的加速，在全精度模型上比Llama.cpp实现了1.25–1.76倍的加速。使用量化模型，增益甚至更大（1.77–1.93倍于Llama.cpp），这主要是由于内核执行时间的减少和基于CUDA图的高效调度，将GPU启动开销从20%以上降低到几乎为零。
这不是替代，是注入
KTransformers的易用性设计，没有要求开发者学习一套全新的框架。它选择了一种注入的模式。
用户不需要大改代码，只需要通过一个YAML配置文件，用一行代码就能把原始PyTorch模型中的模块，替换成KTransformers优化过的高性能版本。这种设计极大地降低了使用门槛，开发者可以像搭积木一样，自由组合不同的优化技术，比如Marlin量化内核、Llamafile CPU内核等。
所以，KTransformers并非要去替代Transformers这样生态强大的通用框架，而是作为其增强插件，专注于解决MoE模型在本地混合推理这个垂直且痛点的场景。
KTransformers还和SGLang合作，强强联手。
SGLang本身就是一个高性能的大语言模型服务框架，在全球范围内已经部署在超过30万块GPU上，是业界公认的标杆之一。它自身就有很多黑科技，比如RadixAttention前缀缓存、零开销CPU调度器、推测解码等，都是为了把推理速度推到极致。
KTransformers整个集成到SGLang的后端体系里，意味着SGLang的服务能力将得到一次重要的扩充。它将不仅仅能在GPU集群上做张量并行，还能支持CPU和GPU混合的专家并行。
当SGLang在调度一个巨大的MoE模型时，它可以把模型中那些计算密集的非专家层（dense layers）放在GPU集群上做张量并行，同时把专家层（experts）灵活地分配到CPU和GPU上进行混合计算。这种海陆空一体的作战方式，能最大化利用所有硬件资源。
这次集成还将扩展对更多模型和权重格式的支持，比如Qwen3、GLM4.5等新模型，以及GPTQ、AWQ等不同的量化格式。
KTransformers的论文入选SOSP，同时宣布与SGLang合作，更大的模型也能在资源受限的场景里流畅跑起来了。
