671B DeepSeek

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

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

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

解决方案有

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

解决方案有了，代码仓库的选择其实是不多的，一个是章明星老师的 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 方案：

KTransformer 中的流水并行

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

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

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

# === 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 仓库同步下来：

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，帮助大家避坑）

第三，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 这些新技术。。

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模型？中明确表示其定位本来就是实验平台，不是全栈应用工业平台，最近的可用性也不是很好，大家不能期望太高太苛责。

llama.cpp 直接跑：

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

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

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

./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，肯定能放下。因为量化损失太大了，暂时先不测了。这里有个例子，2xH100，14~15 tokens/s。

在 a100 x8 上（小吐槽，slurm 上装东西装出阴影了，反正最终是搞定了。如突出问题）

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，按他说的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 中的方法不变。

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 章节。

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

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

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

测试用的单请求的方法 python examples/online_serving/openai_chat_completion_client.py ，这个方法不好得到稳定系统服务结果
如果想大规模测试，需要用 python benchmarks/benchmark_serving.py 中的方法，但是因为，但是因为 API 接口问题，这个测试要跑非 openai 服务形式。
8 卡 A100 直接将前文中的 openai 服务形式改为普通服务的话，其他参数相同时，会显示显存不够，其实启动服务的流程都差不多，这里报错有点奇怪。解决方法是将 –gpu-memory-utilization 调小一点就好了。
测试时虽然可以通过 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，这是一个用 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 资料的链接
针对性的进行了内存预取和转换模式处理的优化，还有部分自定义注意力。
不过 machete 针对 H 系列芯片还有专门的优化，我们这里用不起来了。

vllm 双机方案

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

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

但是这个不是我们今天的讨论主题，双机的资源要求更高，除了机器 double 之外，就是需要较高的网络带宽，同时需要框架支持分布式方法。且一般的调度机制就是 pp 流水线调度。记录一下部分实践：曹宇：vLLM 0.7.1 DeepSeek R1 PP 部署踩坑指南，报告 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。）