关于DeepSeek V3/R1 Decoding吞吐极限的估计
经历了一周DeepSeek的打脸活动后，周六 DeepSeek终于开大放出来了自身的推理系统水平，DeepSeek：DeepSeek-V3 / R1 推理系统概览 。在这个结论放出来之前，没有300多卡做充分实验（公司内部之前没有预判到大型分布式MoE推理的需求，社区的SGLang/vLLM引擎的scale out能力也还在建设中）的我们也做过一些不成熟的理论估计，为了对deepseek 的部署进行一定逆向工程的反推。
今天和同行朋友们交流的时候也帮忙纠正了很多计算上的错误得到更合理的答案。这里整理一下发出来供网友讨论一下，不预设正确立场，鼓励同行继续抓抓bug，也方便对DeepSeek当前的水平做一个理解。
评论区合理的纠错会及时更新。
Acknowledge：
BatchSize的初版讨论由我和快手团队大模型推理的两个同学(Changcheng Tang & Xiangcheng Liu)讨论得到，Yuliang Liu review 了部分结论，计算和通信部分的上限预估经过了sambanova 的@mingran wang老师的review 和公式纠正，参考了@zarbot 老师的网络上限方法。
DeepSeek V3 的网络结构参数
参数配置
MLA
• • KV压缩维度 , Query压缩维度 。
Expert
• 3个Gemm：Up gemm, Down gemm, Gate gemm: d_h = 7168, d_{expert} = 2048
DeepSeek-V3 总共包含 671B 个参数，其中每个 Token 激活了 37B；61层transformer layer，前3层非MoE，后58层FFN 拓展为 MoE，每个 MoE 层由 1 个共享专家和 256 个路由专家组成，h=2048。routered expert 每个token 激活8个expert，训练时每个token最多发送4个node以减少节点间通信。
推算Dense 部分和Sparse MoE部分参数
单个Expert权重 716820483 = 44M，61层中3层非moe，58层moe，25758+39个expert = 657 B，dense部分参数量为 671-657 = 14B，14B 在MLA部分占11.4B，其余部分是embedding、linear等权重。详细计算公式参考：ZihaoZhao：DeepSeek-V3 (671B) 模型参数量分解计算[1]
DeepSeek-V3 参数分布
从per token 激活 37B 反推：37B - 44M x 61 x 9/1000 = 12.8B 差不多能和14B对上。
所以一个近似的权重值
• per expert 权重为44M=42MB• dense 部分权重按14B=13GB• expert 权重总量为 657B = 612GB。
平均Sequence 长度
输入/输出sequence length 分布假设：
• DeepSeek V3 的平均输入/输出长度为：1k+1k （对齐 NVIDIA 官方测试标准）• DeepSeek R1 的平均输入/输出长度为：1k+5k （与今天官方放出来的平均输出“平均每输出一个 token 的 KVCache 长度是 4989。” 基本吻合）
尽量达到compute bound 的最佳设备数配置
MLA 最基本的实现是单机内做8卡TP，需要625GB 存放权重，因此入门门槛一般是H20 96Gx8 或者H800 80G x16。在这两种配置下，可用的kvcache容量非常小，导致attention QKV gemm的batchsize以及MoE部分的batchsize都非常低，MoE部分expert完全是memory bound乃至latency bound的，这对decoding做continous batching来提高硬件利用率来说非常不友好。因此，打高batch size是一个提升吞吐的基本需求，而scale out到多机使得单卡权重降低是一个基本的提升batch size的手段。
TP对MLA部分的KVCache 非常不友好，因为MLA将多个head 压缩到了同一个hidden向量，因此无法在TP节点内做head切分，意味着KVCache 各个卡的存储是冗余的。因此为了做scale out，基本的假设是Attention DP + MoE 部分TP/EP。考虑跨卡通信效率，Attention DP + MoE EP 是比较可行的。
DeepSeek V3论文中decode node采用的是40*8 H800， Attention 4-way TP+SP + 80 way DP，MoE部分320-way EP。由于TP+SP一般在机内发生，不会是bound batch 或通信的主要瓶颈，为了简单我们后文都假设并发配置为Attention DP+ MoE EP。
现在想回答一个最基本问题：
为了让MoE 部分的expert 达到计算bound，我们最少需要多少张 H800？
避免估算复杂，假设无冗余expert，先不考虑shared expert 和前3层是dense的情况。
1. 先考虑显存约束
• 单卡sequence length： （decoding场景下往往是1）• 单请求平均序列长度： • 单卡MLA batchsize： • 单expert batchsize： • GPU 卡数：• expert 数目： • 激活单卡占用：当 > 1000 时，基本上近似某个正比于 的常量倍 （主要跟MLA激活有关）。但现在SGLang激活显存管理做的不好，实测下假设s分布在1k~8k之间，激活不超过8G。注：激活的量更小不会在数值上影响后续估算的量级。• 单token 的MLA kvcache storage size：（） （注：SGLang等框架目前只支持BF16 的kvcache size，上限推算还是按FP8 存）• 假设 ，平均每卡放置 个expert。
于是权重守恒等式：
，
带入激活的经验假设8G。
来看一下d的取值范围：
• 首先这个公式假设了expert无冗余存储（612G），因此 • 其次需满足 ，单卡存放token数需满足 （即使激活为0，上限也是 ）
对于DeepSeek V3: 平均 ， ，
对于DeepSeek R1: 平均 ， ，
可以得到
结论1：对于Q/K/V projection 矩阵，如果sequence length 比较长，在当前无论怎么scale H800设备，QKV 也无法达到FP8算力的饱和点。（从DeepEP[2]的结果来看H800 当前矩阵乘法 规模下的FP8 经验饱和点m > 4096），而H200 141G 和MI300X 192G的大显存更能使QKVproj 逼近饱和点）
2. 考虑MoE 达到Compute bound的约束
再看MoE部分，MoE部分的总接收token数是 ，假设均衡，平均到每个expert的token数为 。假设 moe gemm batchsize 的饱和点记为 时，需满足
于是 。
对于DeepSeek V3: 平均 ，还按4096算饱和点，
对于 ，
对于DeepSeek R1: 平均 ，
对于 ， ，说明不可能达到理想饱和点了，此时若 ，，当， 。
结论2：对于H800来说，moe expert 设备数在V3 情况下，不需要特别大，d=128 和d=256 可能都是一个合理的设备配置。对于R1，d=256更有利于把moe 打饱和。对H20来说，由于 足够小，设备数d可以比256小挺多就能达到compute bound；对于H200和MI300X，由于 比较大，也可以调小设备数d达到理想的compute bound。
吞吐上限预估
吞吐导向，我们希望batchsize 够大达到计算bound，那么整体极限不太可能bound在memory 带宽上，那么会bound在计算或者通信上：
根据计算bound 假设计算上限：
估计decoding 部分的 FLOPs：
对于decoding来说，非MLA的部分FLOPs数可以通过2*N 方法来估计。MLA部分额外由于context window带来的Q@K和P@V的计算在s较大时也应该考虑在内：
一般decoding MLA 进行矩阵吸收：
flops计算公式为 ，带入MLA的参数为
因此 Decoding部分计算量约为
H800 FP8 聚合算力 1978d TFLOPS, H20 FP8聚合算力 296d TFLOPS
对DeepSeek V3 , 则total FLOPs 为 ，H800 单卡吞吐上限为18300 tokens/s, H20单卡吞吐上限为2740 tokens/s
对R1 s = 1, s' = 6000, 则total FLOPs为 ，H800 单卡吞吐上限约为11000 tokens/s, H20单卡吞吐上限为1681 tokens/s
2. 根据网络 bound 假设计算上限：（zarbot算法）
单token 通信量 7168B，50GB/s 跨机RDMA 带宽，单次dispatch 61层+9expert 一共通信量～4MB。zarbot在这里考虑了allreduce ，得到通信总量8MB所以单卡最大吞吐6000的结论，但实际上DP+EP的并行DP部分没有通信，dp阶段不需发送，实际上是 dispatch + combine 也是 8MB，如果combine为BF16，为12MB，因此50GB/s（实际达到40GB/s）的RDMA带宽最多能打单卡5000(FP8)/3333(BF16) 左右tokens/s 。
讨论：
zarbot这里9个expert的算法考虑是decode为了极致的latency需求做了EP320，那么单node 只有8 experts，通信量可能还是按9 experts去估计更合适（减少hop数，考虑均衡性）
考虑如果按最省节点间带宽的做法来通信，如训练一般可以假设per token最多发给4个node，这里可以先通信再在设备内duplicate，因此这里只需要考虑4个node的传输量，再精确一点，前3层transformer不是MoE，那么单次dispatch通信量为58层*4 expert 约1.6MB。如果combine也是FP8，为3.2MB，如果combine为BF16，为4.8MB，50GB/s的RDMA带宽（按40GB/s实际带宽算），combine（FP8）上限单卡12800 tokens/s，combine (BF16) 8500 tokens/s。这种情况下可以提高通信带宽的上限。
因此联合考虑计算和通信两者，在不开启MTP的情况下，R1的 EP256 H800 FP8单卡吞吐的上限在3300(combine BF16)-5000(combine FP8) tokens/s，H20 的上限在1600 tokens/s 左右。
满足 latency约束
假设latency 约束为10ms，按expert 单iter极限访存量与聚合带宽来估算， 需满足 ， 因此一个基本的要求就是，极限的latency需求需要靠多台机器降低expert访存压力。
考虑业界MaaS普遍的output per user 20tokens/s的SLO，当打满batch时，等价访存为80GB全load一次的时间，最小为80GB/3350 = 24ms。如果bs较大到达到计算bound区，这个时间会往上涨。考虑到bs较小时， expert 矩阵单次访存只有 7168*2048 = 14M，经验上 MBU最多达到50%，估计load完一次也需要24ms～50ms（我们实测单机或两机不同长度bs=1的TPOT介于35ms～50ms之间）。
这里就会有一个访存bound - 计算bound之间的tradeoff，先通过scale out把bs=1的latency打的足够低，然后再找到一个甜点区的设备数，使得在TPOT latency 满足50ms 约束下，batch打的尽可能高。
总结
回顾一下DeepSeek 推理系统的水平，
输出 token 总数为 168B。平均输出速率为 20~22 tps，平均每输出一个 token 的 KVCache 长度是 4989。
平均每台 H800 的吞吐量为：对于 prefill 任务，输入吞吐约 73.7k tokens/s（含缓存命中）；对于 decode 任务，输出吞吐约 14.8k tokens/s。
平均单卡吞吐达到了1.85k tokens/s，达到我们刚才算的3300(combine BF16，根据DeepEP所述) tokens/s的56%，同时保证平均输出20-22 tokens/s，考虑我们上一节说的latency 约束， 在延迟约束下能达到理论吞吐的56%，我认为已经是一个非常好的系统水平了（如果没有做MTP的话）！
而在设计中去tradeoff 延迟和吞吐还有很多的细节可以去讨论，比如是否可以让单卡的expert更多一些从而提升network bound的上限，也许还有更多的调参可能性。
