文章总结： 清华大学MADSys实验室开源ktransformers项目，通过异构计算将大模型权重存于系统内存，GPU负责attention和热专家计算，利用AMX加速和专家延迟机制，实现单张24GB显存显卡运行671B参数模型，解码速度超30tok/s，成本从百万级降至十万级。 综合评分： 85 文章分类： 产品介绍,解决方案

377GB权重塞不进24GB显存，清华这个项目让一张4090跑出了30 tok/s

原创

林00 林00

SecureNexusLab

2026年7月19日 12:14 江西

在小说阅读器读本章

去阅读

最近这两天，AI圈子里有个消息传得很热闹。

清华大学MADSYS实验室在GitHub上开源了一个项目，说用一块24GB的消费级显卡就能跑DeepSeek-V3和R1这种体量的大模型，而原本这活儿得上百万的H100集群才能干。

GitHub上已经超过17000个Star，Apache 2.0协议，2024年8月开源到现在迭代了快两年。

消息传出来，有人兴奋，有人质疑。

质疑的点很直接，671B参数，按4.5位宽量化之后大约377GB，一块24GB的显卡怎么可能装得下。

两边其实都没说错，关键在于KTransformers到底在做什么。

先看硬件配置。

KTransformers官方文档给出的运行DeepSeek-V3/R1满血版的硬件要求是，GPU用一张24GB显存的显卡，RTX 4090或者L20都行。CPU需要x86架构，支持AVX512指令集，最好是Intel第四代至强及以上。

「内存至少382GB的DDR5。」

论文里的实验配置是一台双路服务器，每颗Intel Xeon Platinum 8452Y配1TB DDR5，单路内存带宽220GB/s，跨路125GB/s。

这就是推主算的那笔账，671B参数按4.5位宽量化约377GB，382GB的下限就是这么来的。

「模型确实没有装进24GB的显存里，它装进了系统内存」，GPU只负责其中一部分计算。

那为什么还说用24GB显卡跑？因为推理过程中Attention机制、路由网络、高频调用的专家权重、还有KV Cache，这些确实跑在GPU上。其余大部分专家权重在CPU内存里待命，需要的时候再调出来算。

异构计算

KTransformers的核心思路是异构计算。MoE架构天然提供了这个机会，每次推理只激活一小部分专家，其他专家闲着也是闲着。

「GPU这边放的是Attention计算、路由网络、高频调用的热专家、还有KV Cache。CPU内存这边放着所有冷专家的权重，INT4或INT8量化压缩过。」

每次推理路由器决定激活哪些专家，GPU只算被激活的那些。需要切换专家的时候，从CPU内存里拿权重过来算。

这个思路不复杂，但工程实现上有几个关键点。

算子替换

KTransformers做了一个很轻量的注入框架，直接搭在HuggingFace Transformers上。你不需要改模型代码，只需要写一个YAML配置文件，指定哪些模块替换成什么实现。

以DeepSeek-V3为例：

• 匹配到MoE模块，替换成CPU上跑的FusedMoE，用AMX加AVX512后端，Int4量化，延迟6个专家
• 匹配到Attention模块，替换成GPU上跑的FlashInferMLA

「所有的优化逻辑都写在YAML里，切换模型只需要改一行类名，剩下的全自动完成。」

AMX算子

MoE的专家计算主要是矩阵乘法。这类运算在GPU上跑很顺，但在CPU上跑很慢。KTransformers专门针对Intel AMX指令集开发了高吞吐的计算核，配合自定义的tile-aware内存布局，「在单路Xeon上比PyTorch原生实现快了近4倍。」

论文里的对比数据是，相比现有的混合推理系统Fiddler和llama.cpp，KTransformers的预填充速度提升了4.62到19.74倍，解码速度提升了1.25到4.09倍。

AMX是第四代至强开始支持的矩阵乘法加速指令，专门为INT8推理设计。这就是那个供应商锁定的由来，用AMD或者ARM CPU性能会差一截。但官方文档也写了AVX2和AVX-512作为备选方案，性能没那么好但也能用。

专家延迟（核心创新）

这是论文里最核心的创新。

传统的MoE推理严格按层顺序走，GPU算完Attention之后等CPU算完专家，再把结果拿回来继续下一层。这是一个串行依赖，CPU干活的时候GPU在空等。

KTransformers的研究团队发现了一个有意思的事，「Transformer的残差连接对延迟有一定的容忍度。」 也就是说，部分中间结果不需要严格同步，可以稍微晚一点算。

于是他们搞了个专家延迟机制：

• 原来的顺序：GPU算Attention → 等CPU算专家 → GPU拿结果继续
• 改完之后：「GPU算Attention的同时，CPU在算上一层的专家」

两件事并行推进，互不等待。

代码层面通过--kt-max-deferred-experts-per-token这个参数控制，设成1或2就能开启延迟执行。

「效果是CPU利用率从不到75%拉到了接近100%，整体吞吐提升了约1.45倍。单卡解码速度最高超过30 tokens/s，模型精度变化低于0.5%，几乎无损。」

专家调度策略

专家的冷热不是固定的。KTransformers提供了四种专家放置策略：

• 「uniform」：均匀分布，每层放一样多的专家在GPU上，默认选项，不需要任何先验信息
• 「frequency」：根据激活频率统计，把最常被调用的专家放在GPU上，性能最好但需要提前跑统计数据
• 「front-loading」：从第一层开始填GPU，适合特定测试场景
• 「random」：随机选，作为对照基线

实测数据来自Qwen3-Next-80B-A3B，4×RTX 4090的配置：

| GPU专家比例 | random | uniform | frequency | 动态更新 | | — | — | — | — | — | | 10% | 56.63 | 56.57 | 58.60 | 70.22 | | 30% | 62.86 | 62.08 | 66.50 | 75.55 | | 50% | 70.38 | 65.25 | 76.19 | 81.17 |

「frequency策略比uniform高出10个tokens/s以上。」 而开启了动态更新的frequency，10%专家比例就能达到70 tokens/s，接近静态策略50%专家比例的水平。

「这说明选对专家放GPU上，比多放几个专家更重要。」

多并发与连续批处理

2025年4月发布的v0.2.4版本加入了一个重要特性：多并发支持。

这个版本参考SGLang的架构做了重构，三层结构：

• 「Server层」：处理用户请求，兼容OpenAI API
• 「Inference Engine层」：执行推理，支持chunked prefill
• 「Scheduler层」：做任务调度，用FCFS方式做continuous batching

实现上用了自定义的FlashInfer算子库，配合可变batch size的CUDA Graph，减少了内存和填充开销。

「实测数据是4路并发下整体吞吐提升了约130%。」 在Intel最新的Xeon6加MRDIMM-8800平台上，总输出吞吐从17 tokens/s提升到了40 tokens/s。

「这个更新意味着KTransformers从单用户调试工具走向了轻量级服务框架。」

量化方案

KTransformers用了两套独立的量化方案：

• 「CPU侧」：冷专家权重用INT4或INT8，通过convert_cpu_weights.py工具转换。在AMX上跑INT8精度更高，INT4更快但某些模型精度损失较大（比如Qwen3-30B-A3B用INT4会有明显掉点）
• 「GPU侧」：热专家和Attention用GPTQ量化，支持W4A16和W8A16。FP8原生精度也在逐步支持，2025年已经实现了FP8 per-channel的AMX MoE算子

「两套独立的权重，一套放CPU内存一套放GPU显存，各用各的量化方式互不干扰。」

现在可以重新看那个推主的账了。

他说671B参数约377GB，模型活在系统内存里，这是对的。他说需要Intel AMX，这也是对的，AMX确实是性能加速的关键。

但这不意味着KTransformers是虚的。

它做的是一个系统工程，「把原本全放GPU的东西拆成GPU算Attention和热专家、CPU算冷专家」，然后用AMX把CPU算力提上来，用专家延迟把并行度拉满。

「它没让一张卡装下377GB，它让一张卡加上几百GB内存，完成了原本需要多张H100才能完成的计算任务。」

成本上，一台双路Xeon服务器配1TB DDR5，加一张RTX 4090，全新的话十万往上。对比八张H100的百万级成本，降了一个数量级。

性能上，单用户14到30+ tokens/s，跟数据中心级的几百tokens/s没法比，但个人开发者做调试、实验甚至轻量级部署，够用。

KTransformers从2024年8月开源到现在，支持了DeepSeek-V3和R1、139K超长上下文、FP8精度、AMX加速，还陆续对GLM-5、MiniMax-M3做了Day0支持。2025年10月被集成进SGLang生态，论文发在SOSP 2025上。

「技术没有魔法，但系统工程可以改变成本结构。」

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：SecureNexusLab 林00 林00《377GB权重塞不进24GB显存，清华这个项目让一张4090跑出了30 tok/s》