DeepSeek V3/R1 推理效率分析（1）：关于DeepSeek V3/R1 Decoding...

正文

请到「今天看啥」查看全文

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权重 7168*2048*3 = 44M，61层中3层非moe，58层moe，257*58+3*9个expert = 657 B，dense部分参数量为 671-657 = 14B，14B 在MLA部分占11.4B，其余部分是embedding、linear等权重。详细计算公式参考： ZihaoZhao：DeepSeek-V3 (671B) 模型参数量分解计算 ( https://zhuanlan.zhihu.com/p/21455638257)

从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 的最佳设备数配置

DeepSeek V3/R1最基本的实现是单机内做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，基本的假设是

请到「今天看啥」查看全文