671B DeepSeek

今天要记录的是 671B DeepSeek 模型的本地部署，也就是所谓满血版，不是网络 API 调用，也不是 70B （含）以下蒸馏模型的本地部署（这个因为就是 llama/qwen 模型的结构不存在太多问题）。计划是在一台机器上部署，不是跨机器分布式运行。

首先，671B 模型，应该是用 fp8 精度下训练的，所以其全量模型理论值就是 671GB ，最常见的主流 A100 x8 的机器显存是放不下的。

刚好我手头有八卡 A100/A800 ，还有四卡 A6000，需要把它们用起来。

解决方案有

1.  **量化方案**，unsloth 的 gguf int8 模型磁盘占用空间是 665GB， int4 的模型是 377GB。考虑到部分冗余的话 int4 方案也还是可以在八卡 A100 下放得下的。
2.  GPU/CPU 异构推理，方案也有很多，比如 vllm 中的**按层卸载**（cpu\_offload\_gb）。
3.  针对 DeepSeek 中大量稀疏 MoE 的**专家卸载**方案，这比按层 offload 靠谱很多，因为 DeepSeek 模型 MoE 本来很多专家就不会去用。所以八卡 A100 外加一部分可配置的专家卸载（int4 都不需要卸载），是一个很不错的选择。
4.  八卡内的并行机制也是很重要的，一般需要采用张量并行，但是流水线串行虽然不是最优解但是可以解决有无也可以接受。

解决方案有了，代码仓库的选择其实是不多的，一个是章明星老师的 KTransformer，另外一个 vllm + 量化方案。还有一个方案，就是直接部署使用 llama.cpp 的专家卸载方案。

## **后边细节太长不看，简单结论就是：**

1）**ktransformer 不是 VRAM 富裕场景下的首选**，其设计理念就是**为了 VRAM 紧张场景设计和实现的**，大家不能苛责。富裕场景配置首先坑多其次没有专门优化，最严重的是和只用一部分 VRAM 的场景速度差不多。原因主要不是技术方案不好，而是设计初衷不是针对富裕场景，暂时优化不过来。

或者等官方优化好之后再用。共同成长。

2）llama.cpp 其实也能卸载参数到 cpu 跑，只不过是逐层卸载的，不妨试试看也，显存富裕的情况下可能比 ktransformer 好使。单机 int4 可以不用卸载直接跑。

3）单机 vllm int4 方案现在应该是单机 a100 x8 上最优方案。

4）若对量化有抵触，那么双机 a100 int8 依旧满血版的较优选择，或者单机 h20 x8 可以直接塞下去全部参数。但肯定还有很多优化空间和问题来做。

## KTransformer 方案：

![](https://pic2.zhimg.com/v2-fd9d83684df13862eb495525ad8eb2bb_r.jpg)

KTransformer 中的流水并行

这两天集中跑了一下 KTransformer。章老师团队当前发布的 0.2 版本是针对单卡 4090 24G 来实现的，int4 和 int8 都能跑。因为 DeepSeek 这热点太热了，需求太高了，是只支持了这个配置就先放出来了。现在有这样几个问题：

1.  而我们直接把默认配置放到 A6000 上，它也是按 24G 的显存来的，一般就是占 13G 左右，其他空间冗余出来，是需要自己按照 KTransformer 的方法来进行额外配置的。肯定得把空闲的显存加载参数进来，能在 GPU 上跑的都在 GPU 上跑。
2.  默认的配置下多卡也是默认都卸载的，即便是 80\*8 的空间放得下全部 int4 的参数也是只放最少的。
3.  多卡的并行按当前配置是逐层流水的，如上面图示，这显然不是最优，但是合理配置下是可以让全部显存都用起来的。并且更重要的是，瓶颈根本不在这里。
4.  参数加载时快时慢，慢的时候模型加载，只 13G 的时候需要一个小时的时间都有，应该是和我的 NFS 磁盘挂载有关系。
5.  目前默认的 ktransformer 的运行环境是 12.+ cuda 的，不过我阴差阳错的用 11.7 环境跑起来了一个版本。
6.  unsloth 预量化好的模型，似乎有精度问题，这不是 ktransformer 的问题，不过章老师他们这段时间应该在集中精力解决。所以其实最优选择确实是用 int8 加卸载方案。
7.  Q1、Q2 的方案，量化后参数理论上可以放进 48G x4 或者 24G x8 的架构中的，但是目前 ktransformer 还不支持这些量化方案，当然就是支持精度也会是很感人的，不会太实用。

解决方法**一开始**我认为是比较明确的，学习一下 ktransformer 中的 optimize rule，把中间部分层改为不卸载的就好。项目中没有直接对应的配置文件，通过摸索，最简单的就是将 [DeepSeek-V3-Chat-multi-gpu-4.yaml](https://link.zhihu.com/?target=https%3A//github.com/kvcache-ai/ktransformers/blob/c515cc49a595696fedaca6032e100951c42ad36f/ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat-multi-gpu-4.yaml) 配置文件中 # === MLP Experts Replacement === 中的代码取消注释再刚刚层数配置就好了。而现在其实能用的 GPU Expert 注入 injection 算子只有 KExpertsMarlin ，这是一个量化库，所以一定要留意这里的注释（熬了两个夜，血泪的教训）。

```text
# === MLP Experts Replacement ===
# replace with marlin expert. Open and modify layer-num as needed.
# Each layer of malin experts takes about 6GB of GPU memory.
# !!!Do remember 'close' cuda graph if you are using marlin expert.!!!
# !!!KExpertsTorch is untested, we don't have enough VRAM.!!!
```

另外小 tip 安装时一定要记得把依赖关系 git 仓库同步下来：

```text
git submodule init; git submodule update
```

第一 marlin expert 一层大概占 6G 显存，这个提前计算好就好。

第二它和 KTransformer 框架中的 CUDA GRAPH 冲突，可以加载模型但是运行时会报错（RuntimeError: CUDA error: operation not permitted when stream is capturing）的话，需要在命令行下关闭这个配置，**要在 python 语句最后加入 --use\_cuda\_graph=False** 。（切记切记！这个问题卡了我很久，因为那天晚上搞太晚，一直把 close 理解为 graph 闭环了，没有意识到是 close config）（专门提交了一个 issue，[issues 434](https://link.zhihu.com/?target=https%3A//github.com/kvcache-ai/ktransformers/issues/434)，帮助大家避坑）

第三，KExpertMarlin 的加载速度很慢，一层大概要两分钟，还好较新的版本这个层加载给出了进度条，外加其他层也要加载， 24 层模型加载大概要 35 分钟时间在四块 a6000 48G 上，显卡占用到 40G 左右。

最后，**速度方面，只要还留有参数卸载到 cpu 上，就不会有很大的速度提升！因为瓶颈在那个 cpu operator 上。有一个 cpu operator，和全都是 cpu operator 速度是一样的。**

**同时 cpu operator 的速度总体就在 10 tps 这个量级，并且不同的 cpu 配置还比较复杂，与算子、内存带宽都有关系。**比如我手头这台机器则只有 3tps。

a100 的机器在我全跑通之后暂时没空闲了，这两天我测试完再来更新一波，我现在有点不确定即便是八卡 a100 全部能放得下 int4 参数之后，是不是能跨越这个瓶颈。因为这里还有一个很重要的问题，评论区作者目前不建议将 experts 弄到 GPU 上，因为与 CUDA graph 冲突。因为**在 GPU 不带 CUDA graph 跑比在 CPU/GPU 异构算 experts 带 CUDA graph 要慢**，而作者他们已经在写专用的支持 CUDA graph 的 kernel 了。

需要真实测试一波。

**更新来了！**八卡 a100，原本是个单机现在是个 slurm 下的机器了。换环境外加下载模型，就花了好几天时间，不过也不耽误，[中间学习了整个 NSA、MoBA 这些新技术](https://www.zhihu.com/question/12616022631/answer/105115736289)。。

slurm 环境下配环境费了老劲了，只能在登录节点安装，也只能在运行节点跑程序。现在很多 JIT 机制下都要 runtime 去编译一个 cuda triton attention 的模块，因为是在运行节点上，一开始没法编译，需要 slurm 管理员给权限就好了。

另外就是八卡环境下的参数加载时间会更长，因为所有的 marlin expert 参数都需要载入并且需要进行“必要的”反量化和量化操作，我这边大概是**一个小时到两个小时不等**，并且越往后载入速度越慢。**但是，其实显然八块卡是可以并行载入的**。。再进一步，**这部分反量化量化操作是否完全可以离线先做完**？这些都**再次印证 ktransformer 最开始不是为了这种富裕场景来进行设计的**。

实测结果也很感人，**和 experts 不载入 GPU ，基本没有加速**。**甚至还慢些**。

这里 embedding layers 还是放在 cpu 了，因为放到 gpu 暂时会报错还。。这个应该不是瓶颈，因为主要应该还是 cuda graph 造成的？

总之，整体来说不卸载 MoE experts 这个技术方案是没有问题的，但是当前项目开发优先级等问题，暂时没有把这些针对性的优化做了。

另外，一个题外话，KTransformer 在多请求服务封装方面和 vllm 这些框架还有一定差距，比较适合在小显存的单机本地部署，**且需要小并发**，其实也是为什么先去集成 4090 24G VRAM + 1T DRAM 方案的原因。以上几个问题不是说 KTransformer 问题太多不好，其实章老师也在 [如何评价Ktransformers 支持单卡4090推理全量deepseek-R1模型？](https://www.zhihu.com/question/12061570517/answer/101984796945) 中明确表示其定位本来就是**实验平台**，不是全栈应用工业平台，最近的可用性也不是很好，**大家不能期望太高太苛责**。

## llama.cpp 直接跑：

但是是逐层卸载，在大显存的情况下，会比 ktransformer 要快很多。

在 a6000 x4 上，int4 的量化模型，我们 24 层 gpu ，其速度比相同环境下跑 ktransformer 的专家卸载要**快一倍左右**。大约 5tps，虽然也不是非常快。

另外就是参数载入速度非常快，一分钟以内吧，Q4 377G 参数。

```text
./llama.cpp/build/bin/llama-cli \
  --model models/DeepSeek-R1-Q4_K_M/DeepSeek-R1-Q4_K_M-00001-of-00009.gguf \
  --n-gpu-layers 24 \
  --cache-type-k q4_0 \
  --threads 15 --prio 2 \
  --temp 0.6 \
  --ctx-size 8192 \
  --seed 3407 
```

在 a6000 x4 上，单机还有一个可以尝试的点就是用 q1 q2 的量化方案去做，1.58bit 的 q1\_s 133G，肯定能放下。因为量化损失太大了，暂时先不测了。这里有个[例子](https://link.zhihu.com/?target=https%3A//huggingface.co/unsloth/DeepSeek-R1-GGUF/discussions/9)，2xH100，14~15 tokens/s。

在 a100 x8 上（小吐槽，slurm 上装东西装出阴影了，反正最终是搞定了。如 [突出问题](https://link.zhihu.com/?target=https%3A//github.com/ggml-org/llama.cpp/issues/10978)）

24 层在 GPU （对齐一下 a6000 的实验），2.83 tokens per second，比 a6000 慢，可能是 cpu 性能问题，没有深究。

全部在 8x GPU： 8.45 tokens per second

只用 6x GPU： 8.33 tokens per second

以上速度都不是很多次的平均测试，定性看看。

**llama.cpp 直接跑的比 ktransformer 要好总结**：1）大部分层直接在 gpu 中，本身快，2）llama.cpp 的简洁性，包括自身实现的量化方法。3）多卡间使用张量并行方式。

llama.cpp 如果是在显存不富裕的情况下，会比 ktransformer 弱。

## vllm 方案（已更新）：

vllm + int4 的张量并行方案。[https://huggingface.co/cognitivecomputations/DeepSeek-R1-AWQ](https://link.zhihu.com/?target=https%3A//huggingface.co/cognitivecomputations/DeepSeek-R1-AWQ)，按他说的8x A100，38 TPS，接下来复现一下。

只不过我们手头的机器是在变的，下面的测试结果都是在 A800x8 机器上完成的，见谅。

复现过程，还是 slurm 上面配置环境花了很多时间，安装没有太多问题。依旧是运行态 JIT 在 HPC 这个环境下麻烦一些，LD\_LIBRARY\_PATH 和 LIBRARY\_PATH 都要单独指定。运行态还依赖 NCCL 的 libnccl.so 库（我在 slurm 没法装系统库的情况下装了个 pip nvidia-nccl-cu12），nccl 在安装 vllm 时是不需要的，应该是 JIT 的逻辑。不过**整体来说安装和运行比前面两个项目丝滑很多**。

测试方法上和前面两个项目不同，vllm 是先启动的 server，然后用 example 里面的 client 去访问。

server 就是用的前面 hf 中的方法不变。

```text
VLLM_WORKER_MULTIPROC_METHOD=spawn python -m vllm.entrypoints.openai.api_server \
        --host 0.0.0.0 \
        --port 12345 \
        --max-model-len 65536 \
        --max-num-batched-tokens 65536 \
        --trust-remote-code \
        --dtype float16 \
        --served-model-name deepseek-reasoner \
        --tensor-parallel-size 8 \
        --gpu-memory-utilization 0.97 \
        --model your_model_name
```

client 暂时用的 examples/online\_serving/openai\_chat\_completion\_client.py 进行访问，在 server 端读取 Avg generation throughput 结果。返回的文本量和时间匹配度是可信的，但暂时不确定是否完全可信。

复现结果：

**单请求约 28 TPS**，比 hf 项目作者的 38 TPS 有一定差距，后续我们也复现了。

评论区小伙伴指出，差距可能是出在 vllm 不支持 deepseek mla 的 awq 方案。而作者自己搞了一个编译好的版本可以达到 34 TPS ，这个是有 whl 和源码的，后边我们也复现了一波，详见 moe wna16 cuda kernel 章节。

这里简单分析一下其速度达成的可能性，猜测居多，没有对两个项目的模块进行严格拆分和消融实验对比，只是分析而已。

1.  因为测试的 KVCache 长度极短，且为单请求测试，我认为 vllm 优势的 PagedAttention 在这里起到的作用不大。
2.  张量并行方案，使用了 NCCL 优化过的多卡通信，而 llama.cpp 没有接入 NCCL 库。
3.  异步执行机制可能有帮助，也就是计算、数据传输、内存加载异步加速，内存加载我感觉影响不大，计算和数据传输优化的肯定是比 llama.cpp 要好
4.  量化库的 kernel 实现，我认为这部分性能贡献度很高，vllm 的集成成熟度比 llama.cpp 手撸的要好。

现在还遇到几个额外的问题：

1.  测试用的单请求的方法 python examples/online\_serving/openai\_chat\_completion\_client.py ，这个方法不好得到稳定系统服务结果
2.  如果想大规模测试，需要用 python benchmarks/benchmark\_serving.py 中的方法，但是因为，但是因为 API 接口问题，这个测试要跑非 openai 服务形式。
3.  8 卡 A100 直接将前文中的 openai 服务形式改为普通服务的话，其他参数相同时，会显示显存不够，其实启动服务的流程都差不多，这里报错有点奇怪。解决方法是将 --gpu-memory-utilization 调小一点就好了。
4.  测试时虽然可以通过 num\_prompts 来设置请求的数量，但是似乎默认这些请求会一起让 vllm 调度器调度，所以比较诡异的是，显存不够时候它并不预先排队部分请求，而是直接爆显存。这时需要额外指定 max\_concurrency 来限定最大的并发量，不指定就是 和 num\_prompts 相同。但是具体选择多大，不好说，要看经验了。当然也可以理解代码逻辑之后通过计算的方式来获得。不过实际使用中应该是个 tradeoff ，追求极致的 throughout 的话，每个请求的 tps 影响还挺大的。

另外一个大问题，这个模型的精度还待测试。。

### moe wna16 cuda kernel 方案

需要更新 vllm 这个 pr，[GitHub - jinzhen-lin/vllm at moe\_wna16\_cuda\_kernel](https://link.zhihu.com/?target=https%3A//github.com/jinzhen-lin/vllm/tree/moe_wna16_cuda_kernel)，这是一个用 triton 写的专门的 moe cuda kernel，在 num\_seqs \* top\_k / num\_experts 这个数值更小时效果更好。

不过这个方案对 torch、cuda 等等依赖关系都比较高，torch 要高于 2.5.1，cuda 要高于 12.4，vllm 也要高于 0.7.4，甚至操作系统用 ubuntu20 都会有问题。我们在 slurm 下更是非常困难，不过小伙伴帮我配好了环境，也是要自己编译的。是可以跑起来的。

**38.3 tokens/s**，这是我们最后在 A800x8 机器上的测试结果。

摘录几条核心优化点：

-   基于 machete 这个**混合精度 GEMM 优化库**，应该对 **w4a16** 这种情况优化的很好，对 AWQ 支持的也相对较好。[搜到的 machete 资料的链接](https://link.zhihu.com/?target=https%3A//neuralmagic.com/blog/introducing-machete-a-mixed-input-gemm-kernel-optimized-for-nvidia-hopper-gpus/)
-   针对性的进行了内存预取和转换模式处理的优化，还有部分自定义注意力。
-   不过 machete 针对 H 系列芯片还有专门的优化，我们这里用不起来了。

### vllm 双机方案

vllm 双机部署方案（a100 x8 x2）是当前能搜到最多的解决方案。单机张量并行加双机流水对于 vllm 属于基本操作。

对 INT4 量化方案精度有质疑的，还是有双机无损部署需求的。

但是这个不是我们今天的讨论主题，双机的资源要求更高，除了机器 double 之外，就是需要较高的网络带宽，同时需要框架支持分布式方法。且一般的调度机制就是 pp 流水线调度。记录一下部分实践：[曹宇：vLLM 0.7.1 DeepSeek R1 PP 部署踩坑指南](https://zhuanlan.zhihu.com/p/21064432691)，报告 20 TPS。

## 话说回来

**不一定非要跑 671B 的模型。**

**想想是不是刚需。**

**不是就没必要跑。**

相比 671B 这么大尺寸的 MLA+MoE 版本，DeepSeek 同步推出的蒸馏版本模型即可以直接兼容 llama/qwen 又可以复刻部分 R1 能力，就显得非常没有部署压力。

所以我的一个感受就是，与各种模型卡着显卡大小设计模型背道而驰的是，671B 在设计的时候思路就是跨过去低门槛去，提高最大模型的使用门槛，让更多本地部署的机构采用蒸馏版的 70B 以下的无压力版本。从这次部署的过程来看，相信 DeepSeek 内部是一整套足够强的大尺寸模型的推理架构的，以在 671B 甚至更大的模型下提供服务。

从商业的角度看，虽然全开源了，但是通过推理服务的优化难度形成了一个短时间内难以被追赶的“代差”，妙啊。（这个代差主要表达门槛，来自软件和硬件，相对很高，同时需要维护的东西也多，对可用性挑战很大。）

另外，在这段时间 DeepSeek 热度过去之后，大部分人本地部署时对 671B 的需求会减弱，70B 已经可以满足大部分人的需求了，除非有强烈的对满血的执念。甚至，有可能第三方的新尺寸模型实现会变成新的趋势和主流，比如这两天新出来的 open-r1 类似的。

（我后来突然发现，其实 671B 其实也是卡着显存设计的啊，因为现在有 96G H20 8卡，140G H200 8卡这样的主机啊，凭什么 deepseek 就非得跟我一样非得用 A100 呢。呵呵呵呵。要知道，在这次有这机会能天天用八卡 A100 的机会之前，井底之蛙的我是不敢抬眼看一眼这些高端显卡的。贫穷才是限制我眼界的因素，它悄无声息地划定了我的边界。感谢 deepseek。）