引子：一张 4090 跑 671B 满血大模型，这事到底是怎么做到的

2025 年初，DeepSeek-R1 火遍全球的时候，几乎所有人都在问同一个问题：671B 参数的满血版模型，我自己能不能跑？

按照当时的常识，答案是不能。671B 参数，就算 FP8 存储也要 671GB 显存，8 张 A100 80G 都嫌紧张。个人开发者手里那张 24GB 的 RTX 4090？连模型的零头都装不下。

然后清华大学 MADSys 团队和 Approaching.AI 联合开源的 KTransformers（读作 Quick Transformers）站了出来：单张 4090D + 382GB 内存，跑满血版 DeepSeek-R1 671B，预填充速度最高 286 tokens/s，生成速度 14 tokens/s。显存需求砍到传统方案的十分之一以下，预填充速度比 llama.cpp 快 28 倍。

这不是量化到面目全非的阉割版，而是货真价实的满血模型。后来这套框架的论文《KTransformers: Unleashing the Full Potential of CPU/GPU Hybrid Inference for MoE Models》入选了被称为"计算机系统领域奥斯卡"的 SOSP，Qwen、Kimi、智谱 AI 等主流模型团队都把它列为推荐部署方案。到今天，它已经支持在单卡上跑万亿参数级别的模型。

这篇文章我想把 KTransformers 彻底拆开讲清楚：它凭什么能做到？架构上有哪些值得每个后端工程师学习的设计？以及，如果你想自己部署一套，路上有哪些坑。

这不只是一篇"怎么用"的教程。KTransformers 的价值远不止"省显存"这么简单——它代表了一种思路：当硬件资源不对称时，系统工程能榨出多少性能。这个思路对做任何高性能系统的人都有借鉴意义。

一、背景：为什么 MoE 模型给了"穷人推理"一线生机

1.1 稠密模型的死局

先说清楚问题的本质。传统稠密（Dense）模型推理时，每生成一个 token，所有参数都要参与计算。70B 的稠密模型，你就得让 70B 参数全部躺在显存里随时待命，没有任何讨价还价的余地。

参数放在哪，取决于两个硬指标：

• 容量：显存装不装得下
• 带宽：参数从存储介质搬到计算单元的速度

GPU 显存（HBM）带宽高达 13 TB/s，但容量小、价格贵；CPU 内存（DDR4/DDR5）容量可以轻松堆到 1TB，但带宽只有 100400 GB/s。稠密模型的每个参数每次推理都要被读一遍，放内存里就意味着每个 token 都要吃满内存带宽的延迟，速度会慢到没法用。

所以稠密模型的推理就是死局：要么砸钱堆显存，要么忍受蜗牛速度。

1.2 MoE 的稀疏性：天然的"分层存储"契机

MoE（Mixture of Experts，混合专家）架构改变了游戏规则。

以 DeepSeek-R1/V3 为例，它有 671B 总参数，但每次前向传播只激活约 37B。它的 FFN 层被拆成 256 个"专家"（expert），外加 1 个共享专家，每个 token 经过路由器（router）后只会被分发给其中 8 个专家处理。

这意味着什么？意味着参数天然分成了两类：

• 热参数：Attention 层、共享专家、embedding——每个 token 都要用，访问频率 100%
• 冷参数：256 个路由专家——每个 token 只用其中 8 个，单个专家的期望访问频率只有约 3%

这就是经典的数据局部性问题。任何写过缓存系统的工程师看到这个访问模式，第一反应都应该是：热数据放快存储，冷数据放慢存储。

KTransformers 做的第一个核心决策就是这个：

• 稠密部分（Attention、共享专家、LayerNorm 等）→ GPU 显存
• 稀疏 MoE 专家矩阵 → CPU 内存（DRAM）

671B 模型里，稀疏专家占了参数量的绝对大头。把它们卸到内存后，GPU 显存里只需要留稠密部分，再配合 4bit 量化，24GB 显存就够了。

1.3 为什么不是简单的 offload？

看到这你可能会说：参数卸载（offload）又不是新东西，HuggingFace Accelerate、DeepSpeed-Inference 早就有了，为什么它们跑不出这个速度？

区别在于卸载之后谁来算。

传统 offload 方案的思路是"参数存在内存里，用的时候搬回 GPU 算"。这样每次推理都要经过 PCIe 总线搬运数据，PCIe 4.0 x16 的带宽只有 32GB/s，比内存带宽还低一个量级，搬运本身就成了瓶颈。

KTransformers 的思路完全不同：数据不动，计算移动。专家参数留在内存里，直接用 CPU 就地计算。CPU 虽然算力不如 GPU，但配合 AMX/AVX512 指令集和好的算子实现，处理稀疏激活的专家计算是够用的——因为每个 token 只需要算 8 个专家，计算量本身不大，瓶颈在于内存带宽，而这恰恰是 CPU 内存体系能提供的。

这就是"基于计算强度的任务划分"：

• 计算强度高、参数量小的算子（比如 MLA 注意力）→ GPU，吃满 GPU 算力
• 计算强度低、参数量大的算子（稀疏专家 FFN）→ CPU，吃满内存带宽

各干各擅长的事，这才是"异构计算"的正确打开方式。

二、核心架构：KTransformers 的四层设计

把 KTransformers 的代码翻开，可以看到它的性能来自四个层面的叠加，缺一不可。

2.1 第一层：YAML 模板注入框架——优雅的算子替换机制

KTransformers 最有工程美感的设计，是它的模板注入（Injection）框架。

它没有重新发明一套模型定义，而是站在 HuggingFace Transformers 的肩膀上：模型结构、权重加载、tokenizer 全部复用 HF 生态，然后通过 YAML 规则把模型中指定的模块热替换成优化实现。

一个典型的注入规则长这样：

- match:
    name: "^model\\.layers\\..*\\.mlp\\.experts$"   # 正则匹配模块路径
  replace:
    class: ktransformers.operators.experts.KTransformersExperts
    kwargs:
      generate_device: "cpu"        # 生成阶段在 CPU 上算
      generate_op: "KExpertsCPU"    # 使用 CPU 专家算子
      out_device: "cuda"            # 输出送回 GPU
- match:
    name: "^model\\.layers\\..*\\.self_attn$"
  replace:
    class: ktransformers.operators.attention.KDeepseekV2Attention  # MLA 优化实现

框架在加载模型时遍历整个 module 树，用正则匹配模块名，命中就把原始的 nn.Module 替换成优化版本。整个过程对上层代码透明——你还是在用 Transformers 的 API，但底下的算子已经全部换成了异构优化版。

这个设计的好处：

1. 策略与机制分离。哪些层放 GPU、哪些放 CPU、用什么量化格式，全部是配置，不用改代码。想实验新的放置策略，改 YAML 就行。
2. 渐进式优化。可以先只替换最关键的专家层，跑通后再逐步替换 attention、lm_head。每一步都可验证。
3. 生态兼容。对外暴露 Transformers 兼容接口、OpenAI/Ollama 兼容的 RESTful API，下游应用零成本接入。

这套"正则匹配 + 类替换"的注入模式，本质上是依赖注入（DI）思想在深度学习框架里的应用。写过 Spring 或者任何 IoC 容器的人都会觉得眼熟——好的架构思想是跨领域通用的。

2.2 第二层：CPU 侧算子——llamafile 内核与 AMX 指令集

参数卸到 CPU 内存之后，CPU 算得快不快就成了生死线。KTransformers 在 CPU 侧下了重本。

基础版：llamafile 内核。 KTransformers 集成了 llamafile 项目的高性能 CPU 内核作为基础实现，配合多线程、任务调度、负载均衡和 NUMA 感知优化。这一层保证了在普通消费级 CPU 上也有不错的吞吐。

进阶版：Intel AMX 指令集。 这是 28 倍加速的最大功臣。AMX（Advanced Matrix Extensions）是 Intel 从 Sapphire Rapids（第四代至强）开始引入的矩阵计算指令集，核心是 Tile 寄存器 + TMUL 矩阵乘单元：

• 每个核心有 8 个 Tile 寄存器（T0~T7），每个 1KB，可以装下一个 16×64 字节的子矩阵
• TMUL 单元一条指令完成两个 Tile 的矩阵乘累加，INT8 下单核单周期可完成 1024 次乘加运算

对比一下量级：AVX512 一条指令处理 512bit 向量，而 AMX 一条指令处理的是矩阵块。在 BF16/INT8 矩阵乘这个特定场景下，AMX 的理论吞吐是 AVX512 的 8 倍以上。

KTransformers 的 AMX 算子针对 MoE 场景做了几个关键优化：

1. 权重预重排（weight repacking）：模型加载时就把专家权重按 Tile 友好的布局重排，推理时直接 load 进 Tile 寄存器，避免运行时转置开销。
2. 按专家分组的批处理：预填充阶段多个 token 可能命中同一个专家，把它们攒成 batch 一起算，把 GEMV（矩阵-向量乘）变成 GEMM（矩阵-矩阵乘），计算强度上去了，AMX 才能吃满。
3. NUMA 感知的专家放置：双路服务器上，把专家权重分布到两个 NUMA 节点，各自的核心算各自本地内存里的专家，避免跨 NUMA 访存（跨节点内存访问延迟大约是本地的 1.5~2 倍）。

结果就是官方测出来的数字：预填充 286 tokens/s，比 llama.cpp 的对应配置快 28 倍。注意这个 28 倍不是纯 AMX 的功劳，是"AMX 算子 + 专家批处理 + NUMA 优化 + 任务划分"的乘法效应。

2.3 第三层：GPU 侧算子——Marlin 与 MLA 的针对性优化

GPU 这边虽然只剩了稠密部分，但同样有讲究。

Marlin 算子：量化矩阵乘的天花板。 GPU 上的稠密权重用 4bit 量化存储，但 4bit 权重不能直接算，要先反量化。朴素实现（比如直接用 PyTorch）的反量化开销很大，导致量化模型反而比 FP16 还慢。

Marlin 是专为 4bit×FP16 混合精度矩阵乘设计的 CUDA 内核，核心技巧：

• 权重按 GPU warp 访问模式预重排，实现全程合并访存（coalesced access）
• 反量化和 Tensor Core 计算流水线化，反量化的开销被计算完全掩盖
• 精心设计的 shared memory 双缓冲，让访存和计算重叠

实测相比 PyTorch 的量化实现有 3.87 倍加速。这意味着 GPU 上那部分稠密计算几乎不为量化付出速度代价。

MLA 算子：DeepSeek 特供优化。 DeepSeek 系列用的注意力机制是 MLA（Multi-head Latent Attention），它通过低秩压缩把 KV Cache 压到极小。但 MLA 的计算图和标准 MHA 不同，通用 attention 内核跑不出它的理论性能。KTransformers 针对 MLA 写了专用内核，把压缩/解压缩融合进 attention 计算，避免中间张量物化（materialization）。KV Cache 小，意味着同样显存能撑更长的上下文——这也是 24GB 卡能跑长文本的关键之一。

2.4 第四层：CUDA Graph——消灭 Python 的最后开销

这一层最容易被忽视，但对生成（decode）阶段至关重要。

生成阶段每个 token 的计算量很小（batch=1 的 GEMV），此时性能瓶颈经常不在计算，而在每次内核启动的固定开销：Python 解释器调度、CUDA kernel launch、CPU-GPU 同步，每一项都是几微秒到几十微秒，几百个算子叠加起来，纯开销可能比计算本身还长。

CUDA Graph 的解法是：把一次完整前向传播的所有 kernel 启动序列录制下来，之后每个 token 直接重放整张图，一次提交，绕过 Python 和逐个 launch 的开销。

KTransformers 的难点在于它是异构执行——计算流里混着 CPU 算子。它的处理方式是把 CPU 专家计算封装成可以嵌入 graph 流程的节点，通过固定的内存地址交换输入输出，保证录制的图可以安全重放。这套工程细节做下来，decode 阶段的 GPU 空转时间大幅减少，4090 上 14 tokens/s、3090 上 9.1 tokens/s 的生成速度才成为可能。

三、代码实战：从零跑起来一个异构推理服务

说完原理，上手跑一遍。以下以 Linux + 单张 24GB 显卡 + 大内存（DeepSeek-R1 满血版需要 ~382GB，跑 Qwen 系列 MoE 则低得多）为例。

3.1 环境准备与安装

# 基础依赖：CUDA 12.x、gcc、cmake
conda create -n ktrans python=3.11 -y
conda activate ktrans

# 安装 PyTorch（CUDA 版本）
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

# 拉取源码编译安装（推荐，能吃到本机 CPU 指令集优化）
git clone https://github.com/kvcache-ai/ktransformers.git
cd ktransformers
git submodule update --init --recursive

# 双路 CPU（2 个 NUMA 节点）务必带上 NUMA 标志
export USE_NUMA=1
bash install.sh

编译时脚本会探测 CPU 能力（AVX512/AMX），自动启用对应的算子路径。可以用 lscpu | grep -E "amx|avx512" 先确认自己的 CPU 支持什么。

3.2 准备模型权重

KTransformers 直接吃 GGUF 格式的量化权重，配合 HF 的模型配置：

# 模型配置（config.json、tokenizer 等，不含大权重）
huggingface-cli download deepseek-ai/DeepSeek-R1 --local-dir ./DeepSeek-R1 \
    --include "*.json" "*.py" "tokenizer*"

# GGUF 量化权重（Q4_K_M 约 400GB）
huggingface-cli download unsloth/DeepSeek-R1-GGUF --local-dir ./DeepSeek-R1-GGUF \
    --include "*Q4_K_M*"

3.3 本地对话与 API 服务

# 本地交互式对话
python -m ktransformers.local_chat \
    --model_path ./DeepSeek-R1 \
    --gguf_path ./DeepSeek-R1-GGUF \
    --cpu_infer 32 \          # CPU 计算线程数，建议设为物理核数减 2
    --max_new_tokens 4096

# 启动 OpenAI 兼容的 API 服务
python -m ktransformers.server.main \
    --model_path ./DeepSeek-R1 \
    --gguf_path ./DeepSeek-R1-GGUF \
    --cpu_infer 32 \
    --port 10002

服务起来之后，任何支持 OpenAI 协议的客户端都能直接对接：

from openai import OpenAI

client = OpenAI(base_url="http://localhost:10002/v1", api_key="anything")

resp = client.chat.completions.create(
    model="DeepSeek-R1",
    messages=[
        {"role": "user", "content": "用 Go 写一个带超时控制的 worker pool"}
    ],
    stream=True,
)
for chunk in resp:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

3.4 自定义注入规则：把优化策略捏在自己手里

真正体现 KTransformers 灵活性的是自定义 YAML 规则。比如你有两张卡，想把部分专家也放到 GPU 上加速：

# custom_rules.yaml —— 前 10 层的专家放 GPU1，其余留 CPU
- match:
    name: "^model\\.layers\\.([0-9])\\.mlp\\.experts$"
  replace:
    class: ktransformers.operators.experts.KTransformersExperts
    kwargs:
      generate_device: "cuda:1"
      generate_op: "KExpertsMarlin"     # GPU 上用 Marlin 量化算子
      out_device: "cuda:0"

- match:
    name: "^model\\.layers\\.([1-9][0-9])\\.mlp\\.experts$"
  replace:
    class: ktransformers.operators.experts.KTransformersExperts
    kwargs:
      generate_device: "cpu"
      generate_op: "KExpertsCPU"        # 其余专家仍在 CPU
      out_device: "cuda:0"

python -m ktransformers.local_chat \
    --model_path ./DeepSeek-R1 \
    --gguf_path ./DeepSeek-R1-GGUF \
    --optimize_config_path ./custom_rules.yaml

这种"资源放置策略完全配置化"的设计，让你可以针对自己的硬件组合（显存大小、内存带宽、CPU 代际）细粒度调优，而不是被框架的默认假设绑死。

3.5 验证异构执行是否生效

部署完别急着跑分，先确认计算真的按预期分布了：

# GPU 侧：显存占用应显著低于模型体积，利用率在 decode 阶段波动
watch -n 1 nvidia-smi

# CPU 侧：htop 应看到 cpu_infer 个线程接近满载（预填充阶段）
htop

# NUMA 命中率：numastat 查看跨节点访存是否过多
numastat -p $(pgrep -f ktransformers)

如果 GPU 显存占用异常高，大概率是注入规则没匹配上（正则写错是高频事故），专家层被默认加载到了 GPU。

四、性能优化：从"能跑"到"跑得好"的清单

自己部署过几轮之后，总结一些实打实影响性能的点。

4.1 CPU 线程数不是越多越好

--cpu_infer 建议设置为物理核心数减 1~2，给系统和 GPU 驱动留出调度余量。开满逻辑核（超线程）通常是负优化：专家计算是内存带宽瓶颈型任务，两个超线程共享同一个物理核的访存端口，互相踩踏反而降低吞吐。

4.2 内存通道决定生成速度上限

Decode 阶段的速度上限约等于 内存总带宽 / 每 token 激活参数量。同样的 CPU，8 通道 DDR5 和 2 通道 DDR4 的表现天差地别。装机时优先级：插满内存通道 > 上更高频内存 > 换更多核 CPU。这也是为什么官方测试机用的是至强平台——不是为了核多，而是为了 8 通道内存。

4.3 双路平台务必开 NUMA 编译

USE_NUMA=1 编译后，专家权重会在两个 NUMA 节点各放一份副本（空间换时间），彻底消除跨节点访存。代价是内存占用近乎翻倍，所以 R1 满血版官方建议 1TB 内存的双路配置。内存不够的话宁可只用单路。

4.4 预填充与生成的优化方向完全不同

• 预填充（prefill）：吞吐瓶颈，计算密集。长 prompt 会被 CPU 批量处理，AMX 平台在这里优势最大。RAG、长文档摘要这类"长输入短输出"场景收益最明显。
• 生成（decode）：延迟瓶颈，带宽密集。CUDA Graph、内存带宽、量化位宽是关键变量。

评估自己的业务场景属于哪种，再决定硬件预算往哪投。

4.5 量化位宽的权衡

Q4_K_M 是社区验证下来质量/体积平衡最好的档位。更激进的 Q2/Q3 能进一步压内存，但 MoE 模型的路由器对量化误差敏感，专家选择错了，输出质量会断崖式下跌——这比稠密模型量化的风险更高。生产环境建议 Q4 起步，用自己的评测集做回归验证。

4.6 冷启动很慢，是正常的

几百 GB 的权重从磁盘加载进内存，NVMe SSD 也要好几分钟。建议：权重放在读取速度快的盘上；服务化部署，保持常驻，避免反复加载；用 vmtouch 之类的工具做页缓存预热可以显著改善重启速度。

五、冷静的边界：KTransformers 不是银弹

吹了这么多，也要说清楚它不适合什么。

1. 它是"单机低并发"的王者，不是吞吐机器。 KTransformers 的设计目标是本地/桌面级部署（官方叫 local deployments desktop-grade hardware）。14 tokens/s 是 batch=1 的数字，高并发服务场景下，CPU 端会迅速成为瓶颈。如果你要给几百人提供服务，vLLM/SGLang + 多卡才是正解。KTransformers 的战场是：个人工作站、数据不能出内网的企业内部工具、算法团队的实验环境。

2. 硬件挑食。 想吃到最大收益，需要 AMX（第四代至强及以后）+ 多通道大内存。消费级平台（如 i9 + 双通道 192GB）也能跑中型 MoE，但满血 671B 就别想了。硬件成本虽然远低于 8 卡 A100，但"一台双路至强 + 1TB 内存"也不是白菜价，按需评估。

3. 只对 MoE 模型有魔法。 整套方法论建立在稀疏激活的前提上。拿它跑 70B 稠密模型，专家卸载策略无用武之地，性能不会比 llama.cpp 好多少。好消息是行业趋势明确偏向 MoE——DeepSeek、Qwen3-MoE、Kimi 系列都是，这条技术路线的适用面会越来越宽。

4. 生态成熟度与 vLLM 有差距。 功能迭代快但文档相对粗糙，自定义 YAML 调优需要理解模型结构，遇到问题翻 issue 是常态。团队里最好有人愿意读源码。

六、总结：系统工程的胜利，以及它预示的未来

回头看 KTransformers 的 28 倍加速，你会发现没有任何一项"黑科技"是全新发明的：

• MoE 稀疏性卸载——缓存分层的老思想
• AMX/Marlin 算子——针对硬件特性的算子工程
• CUDA Graph——消除调度开销的标准手段
• YAML 注入框架——依赖注入的经典模式

它的厉害之处在于把每一层的优化都做到位，然后让它们相乘。任何一层掉链子——CPU 算子慢一点、任务划分粗一点、Python 开销没消掉——最终数字就会差一个量级。这是典型的系统工程的胜利：没有魔法，只有对每一微秒的较真。

更值得琢磨的是它预示的方向。过去两年，大模型推理的默认答案是"堆 GPU"；KTransformers 证明了 CPU + 内存这套被忽视的资源，在 MoE 时代可以承担真正的生产负载。SOSP 论文的入选、主流模型厂商的官方推荐，说明学术界和工业界都认可了这条路线。

对个人开发者，这意味着桌面级硬件跑千亿模型从段子变成了配置清单；对企业，这意味着私有化部署的成本模型被重写——一台大内存服务器加一张消费级显卡，就能把满血模型关进自己的机房。

推理成本每下降一个量级，就会解锁一批原来不可行的应用。KTransformers 这类异构推理框架，正在把这个量级的下降变成现实。作为工程师，这种"用系统设计对抗硬件稀缺"的项目，值得认真读一遍源码——它教的不只是怎么跑大模型，而是怎么做性能工程。

参考资料：kvcache-ai/ktransformers（GitHub）、SOSP 论文《KTransformers: Unleashing the Full Potential of CPU/GPU Hybrid Inference for MoE Models》、清华 MADSys 团队公开技术资料。