正文

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

假设的是单个expert gemm就能打满GPU 算力，显然忽略了当gemm尺寸较小时group gemm对SM利用率（从而对整体TFLOPS）表现的提升。这样算出来的结果会导致设备数 d 的估计偏大，无法实现很多同行最关心的问题——更少的卡数组EP是否能达到同样效果的讨论。

• 考虑Group Gemm， 应该是一个与 、 相关的值，与等式左边的 相关。

针对上述问题，本着自己挖坑自己埋的操守，本文希望结合DeepSeek放出来的所有公开信息： FlashMLA ^[1] 、 DeepEP ^[2] 、 DeepGemm ^[3] 、 Profile-data ^[4] ，及 DeepSeek V3/R1 推理系统概览 ，对DeepSeek EP144 做一个比较完备的逆向工程 ：D。笔者水平有限，如有错漏欢迎指出。

注：这里不再区分V3和R1，而是使用DeepSeek V3/R1 推理系统概览里的平均分布来统称“满血版”。既然要对齐官方，这里相对之前做估计的时候的粗糙假设修正了两个地方：

1. 考虑shared expert 每个设备都存放副本，而不是EP320 一样shared expert 冗余分布在独立节点

2. 考虑专家冗余，prefill与decode 都为 256 个路由专家+32个冗余专家

2. DeepSeek 满血版逆向工程分析

DeepSeek 官方放出来的关键数据

• • Prefill：路由专家 EP32、MLA 和共享专家 DP32，一个部署单元是 4 节点，32 个冗余路由专家，每张卡 9 个路由专家和 1 个共享专家
• • Decode：路由专家 EP144、MLA 和共享专家 DP144，一个部署单元是 18 节点，32 个冗余路由专家，每张卡 2 个路由专家和 1 个共享专家
• • 输入 token 总数为 608B，其中 342B tokens（56.3%）命中 KVCache 硬盘缓存。
• • 输出 token 总数为 168B。平均输出速率为 20~22 tps，平均每输出一个 token 的 KVCache 长度是 4989。
• • 平均每台 H800 的吞吐量为：对于 prefill 任务，输入吞吐约 73.7k tokens/s（含缓存命中）；对于 decode 任务，输出吞吐约 14.8k tokens/s。

2.1 平均 P/D 长度

这里按 @天阿西吧 在之前评论区提到的算法：

假设P代表sequence的平均输入长度，D代表sequence的平均输出长度，那对于每一个输出token的平均KVcache的长度约等于P+D/2=4989; 再加上P/D=608B/168B；P的取值大概为4383，D的取值大概为1210。

因此 ，attention kvcache平均长度为 = 4989 \approx 5000

2.2 平均 P/D 实例数

为了达到P/D 的消费均衡，来看一下4节点的Prefill instance和18 节点的Decode instance配比：

设prefill node 为 组，decode node 为 组，平均意义上 = 226.75

• • 从输入总吞吐量来反推，并发度约为
• • 从输出总吞吐反推， ，那么可以估计出平均意义上P/D组建的集群配置为

即平均 24组prefill实例与7组decode实例，能比较均衡地支持DeepSeek所需线上负载。

2.3 Prefill 分析

根据 prefill的 timeline ^[5] setting，prefill 用的4k的prompt，每卡16k tokens做2 microbatch。因此可以推断单个microbatch的b=2, s=4096。因为prefill overlap的方式两个microbatch 负载均衡，这里先只考虑单个microbatch的。

2.3.1 prefill 单microbatch 单层profiling

核心计算部分

给一个之前画的比较糙的prefill MLA 示意图， 符号和这里定义的不太一样，有一点abuse大家能看明白就行：

网络通信部分

由于只有4台机器，网络上限的估计符合我们之前谈到的intra-device deduplication的传输方式，这里总共4个节点，所以最多每个token往外发3个副本，因此通信量：

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