DeepSeek 昨天开源了推理框架 DeepInfer，官方公布的数据全部来自 8 卡和 64 卡集群，而且每台机器都必须配备 GPUDirect RDMA 网卡。我们把部署门槛直接降到 4 张 B200、不要 RDMA 网卡。实测在每条请求携带 128k 上下文、1024 并发请求的场景下，4 卡总输出约 6.2 万 token/s，平摊到每个用户约 61 token/s；如果希望交互体验更跟手，把并发限制在 256 时，每个用户能拿到约 110 token/s。
背景
2026 年 10 月 20 日，DeepSeek 开源了支撑 V4.1 Flash 线上服务的推理框架 DeepInfer。官方 README 给出的性能数据是：整集群 64 张卡、每卡 256 条请求、全集群约 1.6 万并发，每条请求带 131,072 token（128k）上下文，nextn=3 投机解码，按 75% 接受率折算，每个用户约 103 token/s，每卡约 2.63 万 token/s，全集群约 168 万 token/s。
原方案对硬件的门槛相当高。V4.1 的 Engram（n-gram 嵌入表）体积约 197 GB，按 rank 分片存放在主机内存里，每一步前向都由 GPU 通过 RDMA 网卡直接读取，走的是 NCCL GIN / GDAKI 路径。连读本机分片也要经网卡回环，没有 NVLink 或本地拷贝的旁路。结果就是：没有 InfiniBand / RoCE 网卡、或者网卡没有透传进实例的机器根本启动不了。这也意味着大部分容器云环境和 GPU 虚拟机都没法直接跑起来。
我们的方案：EP4、去掉 RDMA 依赖
目标很明确：把门槛压到一台 4 卡 B200 就能跑。
- 4 卡 EP4：权重 510 GB，B200 每卡 183 GB 显存，4 卡放下权重后每卡还剩约 90 GB 给 KV cache 和激活。专家按 EP4 切分，attention 按 DP4 切分。
- 去掉主机 RDMA 依赖：用一个兼容接口实现替换 Engram 的 RDMA 取数。表仍然放在主机内存中，各 rank 的分片拼进同一块共享内存，GPU 通过 PCIe 直接读取。用一个环境变量开启，不开时完全走上游原始路径。细节和正确性验证放在文末附录。
测试机是一台 4×B200 容器实例（NVLink 全互联，驱动 595，2 TB 内存）。框架版本为 commit 774ce24，测试脚本用的是官方自带的 examples/benchmark.py、run_sweep.sh 和 eval/。
Decode 性能
测试配置与官方 decode 图保持一致：每条请求带 131,072 token 上下文，nextn=3 投机解码，逐档增加每卡并发。官方图的纵轴先按"草稿全部接受"计步数，再乘以假设的每步平均 token 数 τ = 3.25（即每个草稿 75% 接受）。我们按同样口径换算，同时给出按真实负载接受率（τ = 2.58，来自下文 GPQA 测试）换算的结果。
| 4 卡总并发 |
每卡并发 |
每步耗时 |
每用户 tok/s（τ=3.25） |
每用户 tok/s（τ=2.58） |
每卡 tok/s（τ=3.25） |
4 卡合计 tok/s（τ=2.58） |
| 32 |
8 |
18.1 ms |
179 |
142 |
1,434 |
4,552 |
| 64 |
16 |
19.8 ms |
164 |
130 |
2,620 |
8,320 |
| 128 |
32 |
20.9 ms |
155 |
123 |
4,971 |
15,785 |
| 256 |
64 |
23.4 ms |
139 |
110 |
8,888 |
28,222 |
| 512 |
128 |
28.9 ms |
112 |
89 |
14,380 |
45,663 |
| 1,024 |
256 |
42.4 ms |
77 |
61 |
19,604 |
62,252 |
和官方数据放在一起看：官方 EP8、EP64 用了更多卡做专家并行，每张卡只需读取更少的专家权重，所以同样每卡并发下速度更快。官方 EP8 在每卡 64 并发时每用户约 198 token/s，我们 EP4 是 139，约为它的 70%；每卡 256 并发时约 98 对 77。用 4 卡换来的是显著降低的部署门槛，代价是单卡吞吐大约少了 25%。
点旁数字为每卡并发。官方数值读自官方 README 和部署问答中的图，误差约 ±2%。
单请求延迟：同样 4 卡、32k 上下文，关闭投机解码时每步 7.6 ms，即 131.7 token/s。开启 nextn=5 投机解码后每步 11.2 ms，按真实接受率计算每用户约 230–250 token/s。在 AIME 测试最后只剩一条长推理时，实测单路约 304 token/s。
真实负载：GPQA 与 AIME
基准扫描用的是合成输入。为了看真实推理负载下的表现，我们用官方评测脚本跑了 GPQA Diamond（198 题）和 AIME 2026（30 题），温度 1.0、最大思考强度，每题 1 次采样。
| 评测 |
Pass@1 |
平均输出 |
最长输出 |
投机解码接受率 |
每步 token |
耗时 |
| GPQA Diamond |
91.4% |
15,686 |
134,799 |
49% |
2.58 |
23 分钟 |
| AIME 2026 |
30 / 30 |
15,643 |
118,022 |
57% |
2.80 |
18 分钟 |
两项在长思考模式下都正常跑完，没有出现截断。GPQA 总共生成了 310 万 token，4 卡平均约 2,900 token/s；这个平均值被最后十来分钟只剩一两条长推理的尾段拖低了，下一节会细说。投机解码在真实负载上每步约产出 2.6–2.8 个 token，比官方作图假设的 3.25 低了约 20%，所以上文同时给出了两种口径。
GPU 被用满了吗
测试全程每 5 秒用 nvidia-smi 采一次利用率、功耗和频率。B200 的功耗上限是 1000 W，SM 频率全程稳定在 1965 MHz，没有降频。
- prefill 基本打满算力：扫描时 GPU 忙碌的样本里，利用率 100%，功耗中位数 920–930 W，接近 1000 W 上限。
- 高并发 decode 接近打满：GPQA 开始时每卡约 30–45 个并发，利用率 93–99%，功耗约 800 W。
- 低并发时 GPU 明显还有余力：只剩一两条请求时，nvidia-smi 仍显示 80–88% 的利用率，但功耗只有约 490 W。这个"利用率"只说明有内核在跑，并不代表算力被用足；单条请求的 decode 主要受访存和内核启动延迟限制。
结论很明确：要让 4 张 GPU 跑满，需要足够的并发支撑。扫描数据显示每卡 64 条（总 256）时每用户仍有 100 token/s 以上；加到每卡 256 条（总 1,024），总吞吐还能再涨一倍以上，代价是单用户速度降到 60–77 token/s。
Prefill
官方 prefill 曲线本来就是 4 卡测的，我们用完全相同的配置原样复现。实测数据比官方低 2–11%，batch 越大差距越明显。原因在于我们的 Engram 取数改成了同步的 PCIe 读：65,536 token 时每步要多花约 61 ms，而上游的取数是异步发出、与前面层的计算重叠的。把这部分开销扣掉之后，与官方的差距缩小到 -1.3% 到 +2.2% 之间，最大 batch 一档也只差 4.4%。
容器镜像
为了方便复现，我们把编译好的 DeepInfer（commit 774ce24）连同全部算子、Engram 本机取数补丁、测试脚本一起打成了镜像。权重不打进镜像，首次运行时下载到挂载目录。
| 仓库 |
地址 |
| Docker Hub |
docker.io/zstackai/deepinfer:774ce24-r1 |
| Quay |
quay.io/zstackai/deepinfer:774ce24-r1 |
| 华为云 SWR |
swr.cn-southwest-2.myhuaweicloud.com/zstackai/deepinfer:774ce24-r1 |
# 1. 下载权重（510 GB）
docker run --rm -v /data/models:/models zstackai/deepinfer:774ce24-r1 download
# 2. 没有 RDMA 网卡的单机：打开本机取数补丁，/dev/shm 需约 400 GB
docker run --rm --gpus all --network host --ipc host \
--ulimit memlock=-1 --ulimit stack=67108864 \
-e DEEPINFER_ENGRAM_LOCAL_FETCH=1 -e EP_DISABLE_GIN=1 \
-v /data/models:/models -v /data/out:/out \
zstackai/deepinfer:774ce24-r1 selfcheck # 官方正确性测试
# 3. 复现本文的 decode 扫描（每卡并发 8 → 256，上下文 128k）
docker run ...同上... zstackai/deepinfer:774ce24-r1 \
sweep decode ep4-decode-128k 131072 3 0.75
# 有 GPUDirect RDMA 的机器：去掉两个 -e，加 --privileged，即走上游原路径
镜像入口还提供 preflight（检查 GPU、RDMA 和权重）、offline、bench、eval 和 all（完整测试队列）。DeepInfer 开源版没有 HTTP 服务，镜像也只提供离线推理与测试能力。如果你需要的是开箱即用的在线模型 API，而不是自行部署推理集群，RouteFast.ai 这类模型 API 中转服务可能更省事。镜像里的依赖版本和补丁与本文实测环境一致，但镜像本身还没有在 GPU 上完整跑过一遍。
附录：去掉主机 RDMA 依赖做了什么
1. 问题在哪
V4.1 的两张 Engram 表共 7.68 亿行，每行 256 B（FP8），合计约 197 GB，另有约 6 GB 缩放因子。上游在 NVIDIA 上默认把表按 rank 分片放在主机内存；每次前向时，DeepEP 的 engram_fetch 内核在 GPU 上直接发起 NCCL GIN 读请求，经 RDMA 网卡把每个 token 需要的行取进显存。这个内核只有 GIN 一条路径。设置 EP_DISABLE_GIN=1 只能跳过初始化时的检查，第一次前向就会报非法地址。
2. 替代实现
| 环节 |
做法 |
| 存储 |
同一台机器上各 rank 把自己的分片写进同一块 POSIX 共享内存，拼成完整的表。表仍在主机内存，不占显存。 |
| 映射 |
每个进程对整块区域调用 cudaHostRegister，得到 GPU 可以直接访问的地址（UVA）。 |
| 取数 |
每层一次 index_select，按全局行号读取；缩放因子按 DeepEP 的列主序、4 元素对齐布局输出。形状固定，可被 CUDA Graph 捕获，不需要集合通信。 |
| 接口 |
实现 DeepInfer 用到的 set_config / write / fetch / destroy，在 userbuffer.allocate_engram 里由 DEEPINFER_ENGRAM_LOCAL_FETCH=1 切换。 |
代价是取数从"网卡读远端内存、与计算重叠"变成了"PCIe 读本机内存、同步执行"。单卡实测随机 256 B 行的读取约 13 GB/s：decode 每步只取几百个 token，耗时不到 0.1 ms；prefill 在 65,536 token 时每步约 61 ms。这个方案只适用于单机，跨机仍需上游的 RDMA 路径。
3. 顺带修掉的部署问题
- 编译需要 README 没写的
pciutils（lspci 判断平台）和 libdw-dev。
- DeepEP 用
ibstat 探测网卡带宽，探测不到会直接报错，单机也会触发，需要安装 infiniband-diags。
- FlashMLA 构建后会做寄存器溢出检查；在 nvcc 13.2.1 下一个解码内核多出 16 字节栈帧（没有溢出到 local memory），需要设
FLASH_MLA_SKIP_REG_SPILL_CHECK=1。
- 虚拟机里 PCI 设备的 NUMA 节点常为 -1，上游会把 -1 直接传给 libnuma 导致段错误；补丁让它在这种情况下跳过绑核。
4. 正确性检查
新的取数路径必须和原来逐字节一致。我们做了三类检查：
| 检查 |
结果 |
官方正确性测试 tests/models/test_offline_inference.py：在 4 卡 EP4/CP2 上生成，与仓库里 NVIDIA 4 卡的 PPL 基线逐样本比较 |
文本样本逐位一致，例如 1.1140757133689614、1.0515240811470559、1.1911854135516924、1.0817939673659587，16 位有效数字全部相同 |
| 换一种并行方式（EP4/DP4）再生成同一批样本 |
输出与 EP4/CP2 逐位相同，说明批次不变性与确定性采样在补丁下仍然成立 |
| 结构化输出：regex / JSON schema / EBNF 约束生成 |
4 个 rank 全部生成合法结果，并正常结束 |
| 端到端评测：GPQA Diamond、AIME 2026 |
91.4% 与 30/30，长推理全部正常结束 |
发表于 前天 05:11
|
查看: 13|
回复: 0
