DeepSeek V3/R1 推理效率分析（3）：Decode 配置泛化讨论

正文

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

2.4 不同设备数与batch尺寸对 Router Expert Gemm计算的影响

可组合参数太长，这里放部分数据示意：

可以看到一些趋势：当设备数越小时，需要较大的per GPU 才有足够per expert token数把 group gemm 打到计算bound。当总GFLOPs一样时， 越大计算密度越高，TFLOPS越高。

2.5 不同batch 对 Memory Ops 的影响

这里直接拿prefill的经验值来使用。理想情况下对不同的卡型，可以用带宽比来折算延时。然而这部分的计算还是小量切琐碎，之后估计的时候会逐渐忽略掉这些算子（后面的数据证明，是否考虑这些 memory-bound op 对数量级的影响非常微小）。

2.6 整合算子组件，构建 Pipeline

将各个部分的耗时wrap up在一起，我们可以得到下面的表格。

于是该如何组建pipeline呢？

2.6.1 Two-mircobatch overlapping

第一种沿用deepseek采用的overlap方案。这个方案的前提假设是ATTN 占据了整个计算部分的主要耗时：

模块	GFLOPs	浮点计算量占比
MLA Attention	1.39b_{mla}	50%
O Projection	0.234 b_{mla}	8%
Routed Up&Gate	0.47 b_{mla}	17%
Routed Down	0.235 b_{mla}	8%

并且Combine 的时间开销也比较长。于是我们希望较长的ATTN可以和Combine overlap起来，而自然地，Dispatch 和QKV + Shared 这些小算子进行overlap。

案例1： ：

单层microbatch forwad 时间为250+88+88=426us，不包含通信开销为41.3+250+25.1+88+4.67=409 us，TPOT = 51.9ms，单卡吞吐2468 tokens/s

2.6.2 Single-batch compute-communication overlapping

双microbatch带来的副作用是：

• 拆分microbatch降低了计算密度

• TPOT 需要等双microbatch 完全算完，延迟上并不是非常占优。

这里可以考虑的另一个overlap方法是在单batch内做Down gemm+combine的overlapping。

案例2：

如果做单microbatch呢？

假设通过合适的tiling 使得Combine的计算与Down Gemm的通信overlap，（O+Gate 和Dispatch的overlap 算子不好写先假设无法overlap），这个work的前提是Combine与Down Gemm计算相仿。比如这个配置下Down gemm 56us，Combine 64us，能overlap不少 ，这样通信也能被隐藏，单层microbatch forwad 时间为

这里根本的原因在于： 由于Dispatch/Combine的耗时并不算特别大，引入部分可以接受的bubble，避免了2-batch的计算密度降低与延迟上的牺牲。如果Combine较长，我们将会明显看到吞吐下降。

2.6.3 一般性规律

通过对流水排布的分析，我们很容易总结出下述公式：

1) two-mircobatch overlapping

单层同步时间

2) Single-batch compute-communication overlapping

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