我们应该赞美岩石的坚定。我们应该学习岩石的坚定。我们应该对革命有着坚强的信念。——陶铸

https://github.com/kvcache-ai/ktransformers

KTransformers：让大模型在 CPU 与 GPU 之间学会更聪明地奔跑

大模型的世界里，性能从来不是一句简单的“跑起来了”就能概括的事。尤其当模型越来越大、结构越来越复杂、显存和内存的边界越来越紧时，推理与微调就像一场精细的调度艺术：谁该待在 GPU，谁该去 CPU，哪些路径该被加速，哪些资源该被压榨到极致。这种时候，KTransformers 这样的项目就显得格外有意思。

它给自己的定义很明确：A Flexible Framework for Experiencing Heterogeneous LLM Inference/Fine-tune Optimizations。这不是一句泛泛而谈的介绍，而是把它的核心气质直接亮了出来——它关心的是异构计算，关心的是大语言模型的推理与微调优化，而且强调一种可体验、可落地的框架形态。

项目地址：https://github.com/kvcache-ai/ktransformers

它想解决的，不是单点提速，而是异构计算下的整体效率问题

README 开篇就点明了方向：KTransformers 是一个研究项目，聚焦于通过 CPU-GPU heterogeneous computing 来提升大语言模型的高效推理与微调能力。这个表述很重要，因为它没有把优化理解成“只在 GPU 上卷得更狠”，而是把 CPU 和 GPU 放进同一张资源调度图里考虑。

也正因为如此，KTransformers 的重点并不是单纯展示某一项局部技巧，而是试图围绕异构推理和异构微调搭建出一套完整的用户可见能力。按照当前 README 的组织方式，项目现在主要向用户呈现两大能力：

  • Inference
  • SFT

这两个部分一个负责“跑得更好”，一个负责“调得更稳”，彼此呼应，也构成了这个项目最清晰的主轴。

两大能力被拆得很清楚：Inference 与 SFT

Inference：高性能 kt-kernel Serving

README 将第一块能力明确命名为 Inference - High-Performance kt-kernel Serving。它的核心定位是：面向异构大模型推理的 CPU 优化 kernel 操作。

这里的重点不只是“推理”，而是“异构推理”与“kernel 级优化”一起出现。它关心的不是把模型粗暴塞进单一设备，而是让 CPU 与 GPU 在推理路径中各尽其职。

README 列出了这部分的几个关键特性：

  • AMX/AVX Acceleration：针对 INT4/INT8 量化推理提供 Intel AMX 以及 AVX512/AVX2 优化 kernel
  • MoE Optimization：针对 Mixture-of-Experts 推理进行优化，并结合 NUMA-aware memory management
  • Quantization Support：支持 CPU 侧 INT4/INT8 量化权重，以及 GPU 侧 GPTQ 支持
  • Easy Integration：提供简洁的 Python API，用于 SGLang 和其他框架集成

这四条放在一起，已经能很清楚地看出 KTransformers 的推理部分在做什么：它既处理底层算力指令级别的加速，也在关注 MoE 模型这种结构复杂、资源调度敏感的场景，还兼顾量化与上层框架接入。

SFT：与 LLaMA-Factory 联动的微调能力

第二块能力是 SFT - Fine-Tuning with LLaMA-Factory。README 直接说明，这是 KTransformers × LLaMA-Factory 的集成，用于超大规模 MoE 模型的微调。

这部分的关键特性包括：

  • Multi-Backend Support：支持 CPU/GPU 混合微调，并支持 INT8/INT4 量化
  • Ultra-Large MoE Support：可以在受限 GPU 显存下微调像 DeepSeek-V3/R1 这样的模型
  • Faster than ZeRO-Offload：在基准测试的 MoE SFT 负载下，训练速度可达到 6-12x
  • Lower CPU Memory：在基准环境中，CPU 内存约为此前 KT SFT 路径的一半
  • LLaMA-Factory Integration：与常见微调框架进行无缝集成

这部分给人的感觉很像是：KTransformers 并不满足于“模型能训”，它更在乎“模型在受限资源下还能不能训得动、训得快、训得省”。

一个研究项目，但已经把“用户入口”整理得相当明确

很多研究项目容易停留在论文、原型或者概念说明阶段，而 KTransformers 的 README 在结构上显得相当务实。它没有把所有内容混成一团，而是明确把当前用户可接触的能力归到两个入口：

  • kt-kernel
  • 与 LLaMA-Factory 集成的 SFT 路径

这让整个项目的形象更像一套可操作工具链，而不只是论文配套代码。

推理部分的味道很浓：它在乎 CPU 端能力，也在乎大模型结构特点

AMX / AVX 加速

README 直接写到，KTransformers 的推理内核对 Intel AMX 以及 AVX512/AVX2 做了优化，用于 INT4/INT8 量化推理。这透露出一个很鲜明的倾向：它不是单纯盯着 GPU，而是认真对待 CPU 在异构推理中的角色。

MoE 优化

对于 Mixture-of-Experts，README 特别强调了高效推理与 NUMA-aware memory management。这意味着项目并不仅仅关心算子跑得快，还在关心跨节点内存访问、专家分布这类更接近系统层的问题。

量化支持

在量化上，它写得很直接：

  • CPU 侧：INT4 / INT8 量化权重
  • GPU 侧：GPTQ 支持

这种表达很清楚地勾勒出它对异构路径的理解：CPU 和 GPU 并不是做同样的事，而是在不同精度方案和不同执行职责之间分工。

易于集成

README 还强调提供用于 SGLang 和其他框架的 Python API。这说明 KTransformers 并不想把自己困在“只能单独运行”的孤岛里，它更像一个可以接入上层推理系统的性能基础层。

推理场景里，它明确点出了三类用法

README 在 Use Cases 中列出了三种典型使用场景：

  • CPU-GPU hybrid inference for large MoE models
  • Integration with SGLang for production serving
  • Heterogeneous expert placement（hot experts on GPU, cold experts on CPU）

第三点尤其有画面感：热点专家放在 GPU，冷门专家放在 CPU。这不是一句抽象的“资源调度”，而是把异构推理中非常具体的一种布局方式点了出来。它让人一下就能明白，这个项目所关注的不是静态部署，而是一种更聪明的模型部件安置方式。

README 也给出了推理性能示例

在 Inference 部分，README 给出的性能表里有这样一个例子：

Model Hardware Configuration Total Throughput Output Throughput
DeepSeek-R1-0528 (FP8) 8×L20 GPU + Xeon Gold 6454S 227.85 tokens/s 87.58 tokens/s (8-way concurrency)

这条数据虽然只有一行，但已经能看出项目在展示什么：它不是只说“支持某模型”，而是把模型、硬件配置、总吞吐和输出吞吐放到同一张表里，强调的是异构配置下的实际推理表现。

推理部分的上手方式也非常简洁

Inference 的 Quick Start 只有两步：

1
2
cd kt-kernel
pip install .

这段命令很短，但也传递出一个信号：推理模块本身已经被整理成一个相对独立、可直接安装的入口。

SFT 部分更像是“在有限资源里把大模型微调这件事往前推一步”

如果说 Inference 强调的是高性能 serving，那么 SFT 更像是在挑战一个现实问题：显存并不总是充裕，但大模型微调需求已经越来越真实。

README 中提到，KTransformers 与 LLaMA-Factory 的集成面向 ultra-large MoE model fine-tuning。它不是在谈小模型轻量玩具，而是在说超大模型的微调路径。

多后端支持

SFT 这部分同样延续了异构路线：支持 CPU/GPU hybrid fine-tuning，并提供 INT8/INT4 量化支持。这一点和 Inference 的思路保持一致，说明 KTransformers 在推理和微调两个方向上，并不是各说各话，而是在统一贯彻异构优化的框架。

超大模型支持

README 明确写到，它可以在有限 GPU memory 下微调像 DeepSeek-V3/R1 这样的模型。这个表述很克制，但已经足够有力量。因为这里强调的不是“某模型能运行”，而是“在资源受限条件下依然有操作空间”。

比 ZeRO-Offload 更快

README 还给出一个明确表述：在基准测试的 MoE SFT 负载下，训练速度达到 6-12x。这说明项目在微调路径上不仅追求“能跑”，也在追求“跑得值”。

更低 CPU 内存

它还提到，在基准环境中，CPU 内存约为之前 KT SFT 路径的一半。这一条读起来很安静，却相当重要：对于这类异构方案来说，CPU 端资源占用往往决定了整体可用性。

README 也给出了 SFT 的性能示例

SFT 部分的表格列出了三组例子：

Model GPU Memory Training Speed Hardware
DeepSeek-V3 ~80GB total 3.7 it/s 4x RTX 4090
DeepSeek-R1 ~80GB total 3.7 it/s 4x RTX 4090
Qwen3-30B-A3B ~24GB total 8+ it/s 1x RTX 4090

这张表有一个非常直观的价值：它把模型、总显存需求、训练速度和硬件配置一并摆出来，让人能迅速感知这套方案面对的目标场景。尤其是 Qwen3-30B-A3B 这一行，展示出在单张 RTX 4090 上也能形成一条明确的微调路径。

SFT 的启动命令，比想象中更有“工程落地感”

README 给出的 SFT Quick Start 是这样的：

1
2
3
4
5
6
7
cd /path/to/LLaMA-Factory
pip install -e .
pip install -r requirements/ktransformers.txt
CUDA_VISIBLE_DEVICES=0,1,2,3 accelerate launch \
  --config_file examples/ktransformers/accelerate/fsdp2_kt_int8.yaml \
  src/train.py \
  examples/ktransformers/train_lora/qwen3_5moe_lora_sft_kt.yaml

这段命令很能体现项目当前的实际使用方式：不是凭空发明一套全新训练世界，而是借助 LLaMA-Factory 作为上层框架，把 KTransformers 的异构优化能力嵌进去，让已有微调流程获得新的资源调度与性能路径。

更新列表很长，而且几乎像一部项目演进日志

KTransformers 的 README 有一个相当长的 Updates 区域，信息密度很高。它像一条时间轴，把项目近一段时间的重要推进全都摆了出来。

其中包括：

  • 2026-06-21：MiniMax-M3 Day0 Support
  • 2026-06-17：GLM-5.2 Day0 Support
  • 2026-05-02：DeepSeek-V4-Flash Support
  • 2026-04-30：v0.6.1 刷新 kt-kernel inference 与 SFT 文档，并拆分 Inference 与 SFT Quick Start
  • 2026-03-26：支持 AVX2-only CPU backend for KT-Kernel inference
  • 2026-02-13：MiniMax-M2.5 Day0 Support
  • 2026-02-12：GLM-5 Day0 Support
  • 2026-01-27：Kimi-K2.5 Day0 Support
  • 2026-01-22：支持 CPU-GPU Expert Scheduling、Native BF16、FP8 per channel Precision
  • 2025-12-24：支持 Native MiniMax-M2.1 inference
  • 2025-12-22：支持 RL-DPO fine-tuning with LLaMA-Factory
  • 2025-11-06：支持 Kimi-K2-Thinking inference 与 fine-tune
  • 2025-11-04：KTransformers Fine-Tuning × LLaMA-Factory Integration
  • 2025-10-27：支持 Ascend NPU
  • 2025-10-10：Integrating into SGLang
  • 2025-09-11：支持 Qwen3-Next
  • 2025-07-11：支持 Kimi-K2
  • 2025-06-30：支持 3-layer（GPU-CPU-Disk）prefix cache reuse
  • 2025-05-14：支持 Intel Arc GPU
  • 2025-04-29：支持 AMX-Int8、AMX-BF16 和 Qwen3MoE
  • 2025-04-09：实验性支持 LLaMA 4 models
  • 2025-04-02：支持 Multi-concurrency
  • 2025-03-15：支持 ROCm on AMD GPU
  • 2025-02-25：支持 FP8 GPU kernel for DeepSeek-V3 and R1
  • 2025-02-10：支持 Deepseek-R1 and V3 on single / multi GPU and 382G DRAM，速度提升 3~28x
  • 2024-08-28：将 DeepseekV2 所需 VRAM 从 21G 降到 11G
  • 2024-08-14：支持 llamfile as linear backend
  • 2024-08-12：支持 multiple GPU、mixtral 8×7B 与 8×22B、q2k/q3k/q5k dequant on GPU
  • 2024-08-09：支持 windows native

这一长串更新特别能体现项目的演进节奏：它既持续增加模型支持，也不断扩展硬件后端和优化能力，还在推理、微调、缓存、多并发、长上下文等方向上持续推进。整个项目像一台不停加挂新组件的异构引擎。

它和 SGLang、LLaMA-Factory 的关系，也揭示了项目的生态姿态

从 README 可以看出，KTransformers 并不试图封闭成一个完全自洽但孤立的世界。相反，它在两个方向上都明确选择了外部集成：

  • 推理方向：SGLang
  • 微调方向：LLaMA-Factory

这很说明问题。它不是要替代一切，而是想把自己的核心价值——CPU/GPU 异构优化能力——嵌入到更成熟的上层框架与工作流中。这样一来，KTransformers 更像一个“性能基础设施层”，而不是一个必须单独使用的全栈平台。

项目还把旧时代的自己收进了 archive

README 最后还有一个值得注意的部分：KT original Code。它说明，原始的一体化 KTransformers framework 已经被归档到 archive/ 目录，供参考使用。当前项目则将重点整理为前面那两项能力，并从 kt-kernel 及相关文档入口组织起来。

这意味着 KTransformers 并不是静态不变地向前堆功能，而是在重构自己的表达方式。它像是把早期的一体化形态收进仓库深处，然后把现在最核心、最面向用户的两块能力重新摆到台面上。

这种整理动作很重要。因为它说明项目不仅在做技术推进，也在做产品化与模块化上的自我修整。

它还是一篇论文背后的工程实践

README 中给出了 citation，对应论文标题是：

KTransformers: Unleashing the Full Potential of CPU/GPU Hybrid Inference for MoE Models

论文发表于 Proceedings of the ACM SIGOPS 31st Symposium on Operating Systems Principles，年份是 2025。

这让整个项目又多了一层气质：它不是从纯工程实用主义出发随手搭建的工具，也不是只有论文没有入口的原型，而是处在研究与工程之间的交汇点。它既有论文表达，也有相对清晰的安装入口、集成路径和性能展示。

背后的团队也被写得很清楚

README 中列出的开发与维护方包括：

  • MADSys Lab @ Tsinghua University
  • Approaching.AI
  • 9#AISoft
  • Community contributors

这部分信息虽然简短，却能帮助理解项目的背景：它是一项带有明显研究色彩、也吸纳社区参与的持续性工作。

为什么 KTransformers 会让人觉得“有意思”

KTransformers 的有趣之处，不只是它支持了很多模型，也不只是它列出了一串更新日志。它真正耐人寻味的地方在于：它把大模型推理与微调这件事，看成了一场跨 CPU 与 GPU 的系统级编排问题。

在它的世界里：

  • CPU 不是配角
  • GPU 也不是唯一答案
  • 量化不是孤立技巧
  • MoE 不是简单模型标签
  • 推理和微调不是两条互不相干的支线

它试图把这些因素揉成一个整体，让资源、模型结构、框架集成与性能目标彼此对齐。于是你看到的就不再只是某个“快一点”的 patch，而是一整套围绕异构大模型工作流展开的实践路径。

这不是在追求花哨，而是在认真处理大模型落地时最硬的现实

很多关于大模型的讨论，容易停留在参数量、榜单和概念展示里。但 KTransformers 关心的问题更具体，也更“硬”：

  • 显存够不够
  • CPU 怎么用
  • MoE 专家怎么放
  • INT4 / INT8 / FP8 怎么协同
  • 不同硬件后端能不能接进来
  • 推理能不能进 serving
  • 微调能不能接进既有框架

这些问题都很现实，甚至带点工程现场的粗粝感。而 KTransformers 的价值，恰恰就在于它没有绕开这些麻烦，反而主动钻进这些麻烦里，试图把它们梳成一套更有秩序的方案。

如果只用一句话来形容这个项目，那大概可以说：它像一位很懂资源调度脾气的工程师，站在 CPU 和 GPU 中间，努力让超大模型在并不宽裕的现实世界里，依然有办法跑起来、训起来，而且尽可能跑得更像样。