GPT-4/o1级本地VSCode Copilot在仅有24GB VRAM的桌面上

• 总结
  • 展示案例环境
  • 基准结果
    • V0.2.1
      • 内存消耗:
      • 变更日志
      • 基准测试结果
    • V0.2
      • 设置
      • 内存消耗:
      • 基准测试结果
    • V0.3-预览
      • 设置
      • 内存消耗：
      • 基准测试结果
  • 如何运行
    • V0.2.2 更长的上下文和 FP8 核心
      • 更长的上下文
      • FP8内核
    • V0.2 & V0.2.1 展示
      • 单插槽版本 (32核)
      • 双插槽版本 (64 核心)
    • V0.3 展示
      • 双插槽版本 (64 核心)
  • 一些解释
  • 下一步
    • 更快
    • 更简单
  • 常见问题
    • R1 无思考
    • 更多常见问题

摘要

2025年2月10日: 支持单个（24GB VRAM）/多个GPU上的DeepseekR1和V3以及382G DRAM，最高可实现3~28倍加速。

嗨，我们是KTransformers团队（以前以与DeepSeek-V2一起进行本地CPU/GPU混合推理的开源项目而闻名）。

我们听到了你们对DeepSeek-R1/V3支持的要求——我们很高兴终于能够实现！抱歉让你们久等了，但我们一直在准备一些真正令人惊叹的东西！

今天，我们自豪地宣布我们不仅支持 DeepSeek-R1/V3，如下方视频所示：

https://github.com/user-attachments/assets/ebd70bfa-b2c1-4abb-ae3b-296ed38aa285

• [NEW!!!] Local 671B DeepSeek-Coder-V3/R1: Running its Q4_K_M version using only 14GB VRAM and 382GB DRAM.
  • Prefill Speed (tokens/s):
    • KTransformers: 54.21 (32个核心) → 74.362 (双插槽, 2×32个核心) → 255.26 (优化的基于AMX的MoE内核, 仅限V0.3) → 286.55 (选择性使用6个专家, 仅限V0.3)
    • 与在 llama.cpp 中使用 2×32 核心的 10.31 tokens/s 相比，达到了 27.79× 加速。
  • Decode Speed (tokens/s):
    • KTransformers: 8.73 (32 核心) → 11.26 (双插槽, 2×32 核心) → 13.69 (选择性使用 6 个专家, 仅限 V0.3)
    • 与在2×32核心的llama.cpp中实现的4.51 tokens/s相比，达到最高3.03×加速。

我们还展示了即将到来的优化预览，包括一个加速的Intel AMX内核和一种选择性专家激活方法，这将显著提升性能。随着V0.3-preview，我们在预填充方面达到了每秒286个令牌，使其在本地推理上速度提高了28× 比 llama.cpp 快。二进制分发现已可用，源代码将尽快发布！查看轮子包这里

2025年2月15日: KTransformers V0.2.1: 更长的上下文（从4K增加到8K，适用于24GB VRAM）和稍微更快的速度（+15%）（最高16个标记/秒），更新文档 这里 和 在线书籍。

我们稍微加快了解码和预填充的速度。性能改进有限的原因主要在于推理过程仍然受到CPU计算速度和内存带宽的限制。由GPU处理的MLA部分占比较小。

除了速度的提升，我们还大幅更新了文档以增强可用性，包括：

• 添加了多GPU配置教程。
• 综合安装指南。
• 添加关于使用ExpertMarlin注册额外GPU内存的详细教程；

展示案例环境

我们在以下环境下运行了最佳性能测试 (V0.2)
CPU: 英特尔 (R) 至强 (R) 金牌 6454S 1T DRAM (2 个 NUMA 节点)
GPU: 4090D 24G VRAM
内存: 标准 DDR5-4800 服务器 DRAM (1 TB)，每个插槽配有 8×DDR5-4800

基准结果

V0.2.1

• 模型：DeepseekV3-q4km (int4)
  
• CPU: cpu_model_name: Intel (R) Xeon (R) Gold 6454S，每个插槽32个核心，2个插槽，2个NUMA节点
• GPU: 4090 24G显存
• 我们在充分热身后进行测试

内存消耗：

• 单一插槽：382G DRAM，至少14GB VRAM
• 双插槽：1T DRAM，至少14GB VRAM

更改日志

• 更长的上下文（从4K到8K，适用于24GB VRAM）及稍快的速度（+15%）：
  集成了来自优秀的sglang项目的高效Triton MLA内核，使得上下文长度大幅增加，预填充/解码速度稍微加快
• 我们怀疑一些改进来自硬件平台的变化 (4090D->4090)

基准测试结果

"6 experts" 案例是 V0.3 预览的一部分

V0.2

设置

• 模型：DeepseekV3-q4km (int4)
  
• CPU: cpu_model_name: Intel (R) Xeon (R) Gold 6454S，每个插槽32个核心，2个插槽，2个NUMA节点
• GPU: 4090D 24G 显存
• 我们在充分热身后进行测试

内存消耗：

• 单一插槽：382G DRAM，至少14GB VRAM
• 双插槽：1T DRAM，至少14GB VRAM

基准测试结果

"6 experts" 案例是 V0.3 预览的一部分

最高加速达到3.03x在解码时和9.44x在预填充时。

V0.3-预览

设置

• 模型：DeepseekV3-BF16（在线量化为CPU的int8和GPU的int4）
• CPU: cpu_model_name: 英特尔 (R) 至强 (R) 金牌 6454S，每个插槽 32 核心，2 个插槽，2 个 NUMA 节点
• GPU: (1~4)x 4090D 24GVRAM（较长的提示需要更多的VRAM）

内存消耗：

• 644GB DRAM，至少14GB VRAM

基准测试结果

KTrans V0.3 的预填充速度比 KTrans V0.2 快了高达 3.45 倍，比 llama.cpp 快了高达 27.79 倍。 解码速度与 KTrans V0.2（6 专家版本）相同，因此省略。

主要加速来自于

• 英特尔AMX指令集和我们专门设计的缓存友好内存布局
• 专家选择策略，根据离线配置文件的结果选择更少的专家，基于域外数据

根据我们对DeepSeekV2、DeepSeekV3和DeepSeekR1的研究，当我们在推理中稍微减少激活专家的数量时，输出质量没有变化。但是解码和预填的速度加快了，这很令人振奋。因此我们的展示利用了这一发现

如何运行

V0.2.2 更长的上下文 & FP8 内核

更长的上下文

要使用此功能，请首先安装 flashinfer。

注意：FlashInfer中最新的MLA内核仍然存在一些小问题。他们正在主分支上持续修复这些问题。如果您正在使用FlashInfer，请从主源代码进行安装。

如果您想在预填充阶段使用较长的上下文（超过20K），请启用矩阵吸收MLA，这将显著减小kv缓存的大小。像这样修改yaml文件：

- match:
    name: "^model\\.layers\\..*\\.self_attn$"
  replace:
    class: ktransformers.operators.attention.KDeepseekV2Attention # optimized MLA implementation
    kwargs:
      generate_device: "cuda"
      prefill_device: "cuda"
      absorb_for_prefill: True # change this to True to enable long context(prefill may slower).

如果显存仍然不足，请尝试将 chunk_prefill_size 参数（默认值为 8192）降低，以进一步减少分块预填充期间的中间结果。

FP8内核

DeepSeek-AI团队为DeepSeek-R1/V3模型提供FP8安全张量。我们通过以下工作实现性能优化：

• FP8 GPU 内核集成: 集成在 KTransformers 中的 FP8 线性层加速内核
• Hybrid Quantization Architecture:
  • 注意和共享专家模块使用FP8精度（提高计算精度）
  • 专家模块保留GGML量化（GGUF格式，驻留在CPU中以节省GPU内存）

因此，追求最佳性能的用户可以对DeepSeek-V3/R1使用FP8线性内核。

详细指南在这里。

V0.2 & V0.2.1 展示

单插槽版本（32核）

我们的 local_chat 测试命令是：

numactl -N 1 -m 1 python ./ktransformers/local_chat.py --model_path <your model path> --gguf_path <your gguf path>  --prompt_file <your prompt txt file>  --cpu_infer 33 --max_new_tokens 1000
<when you see chat, then press enter to load the text prompt_file>

<your model path> 可以是本地路径或从在线 hugging face 设置，如 deepseek-ai/DeepSeek-V3。如果在线遇到连接问题，请尝试使用镜像 (hf-mirror.com)
<your gguf path> 也可以在线下载，但由于其较大，我们建议您下载并将模型量化到您想要的格式（请注意，这是目录路径）
--max_new_tokens 1000 是最大输出令牌长度。如果您发现答案被截断，您可以增加数字以获得更长的答案（但要注意 OOM，增加它会减慢生成速度）。

命令 numactl -N 1 -m 1 的目的是避免在NUMA节点之间传输数据
注意！如果你正在测试R1，它可能会跳过思考。因此你可以添加参数: --force_think true。这在 FAQ 部分中有解释

双插槽版本（64 核心）

在安装之前，请确保通过 export USE_NUMA=1 设置环境变量 USE_NUMA=1（如果已经安装，请在设置此环境变量后重新安装）。您可以在 这里 查看安装细节。

测试命令：

# ---For those who have not installed ktransformers---
# git clone https://github.com/kvcache-ai/ktransformers.git
# cd ktransformers
# git submodule init
# git submodule update
# export USE_NUMA=1
# make dev_install # or sh ./install.sh
# ----------------------------------------------------
python ./ktransformers/local_chat.py --model_path <your model path> --gguf_path <your gguf path>  --prompt_file <your prompt txt file>  --cpu_infer 65 --max_new_tokens 1000
<when you see chat, then press enter to load the text prompt_file>

参数的意思是相同的。但由于我们使用双插槽，我们将 cpu_infer 设置为 65

V0.3 展示

双插槽版本（64 核心）

我们的 local_chat 测试命令是：

wget https://github.com/kvcache-ai/ktransformers/releases/download/v0.1.4/ktransformers-0.3.0rc0+cu126torch26fancy-cp311-cp311-linux_x86_64.whl
pip install ./ktransformers-0.3.0rc0+cu126torch26fancy-cp311-cp311-linux_x86_64.whl
python -m ktransformers.local_chat --model_path <your model path> --gguf_path <your gguf path>  --prompt_file <your prompt txt file>  --cpu_infer 65 --max_new_tokens 1000
<when you see chat, then press enter to load the text prompt_file>

参数的含义与 V0.2 相同。但由于我们使用双插槽，我们将 cpu_infer 设置为 65

一些说明

1. 我们还希望进一步利用我们在Xeon Gold CPU上的两个NUMA节点。为了避免节点之间的数据传输成本，我们在两个节点上“复制”了关键矩阵，这将占用更多内存，但加快了预填充和解码过程。但这种方法占用巨大的内存，并且在加载权重时速度较慢。因此，在加载时请耐心等待并监控内存使用情况。我们将优化这种巨大的内存开销。敬请期待~
   

2. 命令参数 --cpu_infer 65 指定要使用多少个核心（超过物理核心数量是可以的，但并不是越多越好。可以稍微调低到实际的核心数量）
   

3. 为什么使用CPU/GPU混合推理？ DeepSeek的MLA操作员计算密集型很高。虽然在CPU上运行一切是可能的，但将重计算转移到GPU会带来巨大的性能提升。

4. 加速来自哪里？

   • 专家卸载：与传统的基于层或KVCache的卸载（如在llama.cpp中所见）不同，我们将专家计算卸载到CPU，将MLA/KVCache卸载到GPU，完美地与DeepSeek的架构对齐，以实现最佳效率。
   • 英特尔 AMX 优化 – 我们的 AMX 加速内核经过精心调优，运行速度比现有的 llama.cpp 实现快几倍。我们计划在清理后开源此内核，并考虑对 llama.cpp 的上游贡献。

5. 为什么选择英特尔CPU？ 英特尔目前是唯一一个支持AMX类似指令的CPU供应商，这提供了比仅支持AVX的替代方案显著更好的性能。

下一个

更快

• FlashInfer (https://github.com/flashinfer-ai/flashinfer) 项目正在发布一个更高效的融合 MLA 操作符，承诺进一步提高速度
• vLLM已经在DeepSeek-V3中探索了多标记预测，支持将是我们路线图上的重要一环，以提供更好的性能
• 我们正在与英特尔合作，以增强 AMX 内核 (v0.3) 并针对 Xeon6/MRDIMM 进行优化

更简单

• 官方Docker镜像以简化安装
• 修复服务器集成以便访问Web API
• 修复本地聊天只能接受单行提示（当前 \n 开始生成提示）
• 支持更多量化类型，包括备受欢迎的来自unsloth的动态量化

请保持关注以获取更多更新！

常见问题

R1 无需思考

注意！如果您正在测试R1，它可能会跳过思考。您可以添加参数：--force_think true。详情请参见FAQ部分

更多常见问题

查看详情