正文
2.4 不同设备数与batch尺寸对 Router Expert Gemm计算的影响
可组合参数太长，这里放部分数据示意：
可以看到一些趋势：当设备数越小时，需要较大的per GPU
才有足够per expert token数把 group gemm 打到计算bound。当总GFLOPs一样时，
越大计算密度越高，TFLOPS越高。
n=4096, k=7168 不同(num_group、m_per_group) 下的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 占据了整个计算部分的主要耗时：
并且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带来的副作用是：
这里可以考虑的另一个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
