deepseek v3为什么pd比例达到了1比10?

心中u你

Decoding 部分一个实例就消耗了 320 张 H800，Prefilling 部分一个实例是 32 卡，为什么啊

原文地址：https://www.zhihu.com/question/8531371805

感恩由您

看了下几个回答基本都没说到点上，首先在一般的PD分离里，用多个P节点对应1个D节点是为了去喂饱D节点，让D节点拼更大的batch_size提升计算强度。在mooncake的场景里，promot都很长导致prefill更加慢，所以P/D的比例就要调的更大。  
而Deepseek里，我不认为PD分离的场景下32卡的P节点能喂饱320卡的D节点。比如PDF对话之类的，prefill的计算量太大了，也不可能全部cache住。所以我认为这里实际部署应该是20*32 / 2*320 类似这样的比例，32和320应该就是1个实例的最小卡数，不是总卡数。

感恩由您

思路：

• 一个Request从开始到结束，分析Prefill和Decode分别Occupy了多少GPU time，对于deepseek v3这种大模型而言，长文本输出的前提下，Decoding所占时长会占主导地位；
  
• 如果Decoding对应的GPU replica数少，那么就会进入「雪崩击穿」模式，Request会在Decode stage越堆越多，因此目标是在一定的traffic下选择一个合理的Ratio;
  
• 在不同的QPS/traffic压力下，这个PD ratio是可能改变的，可行的计算方式：
  

• 通过offline profiling来grid search获得相对optimal的traffic->(ratio & num gpu replicas)的映射；
  
• 通过online adaptive的方式去tune这个值；
  

但这背后其实都需要infra针对LLM PD分离场景下的auto-scaling机制配合；

大力水手

补充 @菽陌松囿 的回答，其他这位老哥的思路是对的，不过可能不是bound 在显存空间大小，而是显存带宽。
我是通过搜索IBGDA搜到这个问题的，恰好之前自己也多少有些思考，在这里抛出来跟大家讨论。
先抛一个方向性的结论：如此夸张的PD比例其实就是为了在满足SLA的场景下降低总的推理成本。
为什么这么说？
无论是Dense 系列模型，还是MoE系列，在大模型推理场景下，往往是decode阶段的GPU占用时间更高，从而导致decode的成本一般会明显高于Prefill。这里的主要原因在于，传统的MHA、GQA的实现中KV cache 往往比较大，特别是在长文本的情况下，导致decode时过早出现显存容量或显存带宽的瓶颈，无法积攒更大的batch，从而将过长的GPU占用时间 转变为 实际的decode 成本。
众所周知，MLA的好处是可以减小 KV cache，属于以计算换显存的手段，在MoE的场景下其实在单次decode中，KV cache已经不一定是显存占用的大头了，每次激活的expert的参数量其实并不小。这里以DSV3为例，每次激活9个expert，光是这9个expert参数占用的显存就达到了22.15GiB，而1 K Sequence length下的KV cache 仅为 61*576*1024 = 34 MiB，所以对于decode阶段的计算来讲，expert参数引入的显存瓶颈会占据主流。
另外，MoE的一大特点就是其稀疏性，稀疏性导致计算不友好，容易造成算力的浪费。但在Prefill阶段由于Sequence length一般可以做到比较大（至少可以轻松到100-200吧，一些特定长文本的场景要到几十K），这样即便每次激活的experts只有8+1个，但每个expert的计算还能撑起算力；Decode阶段就不同了，激活9个expert的计算量在Sequence 阶段远小于1 TFLOPS，而H系列动辄几百上千T的算力无用武之地，MFU极低。
所以为了尽量降低稀疏性对算力利用的影响，尽量使用大的batch是首选。那么如何打开 max batch size的上限呢，经过上面的分析，显存会先于算力达到瓶颈点，而且是显存带宽，而非显存容量。这里的主要原因还是decode阶段的SLA要求，做chat类的LLM有一个潜在decode速度要求，一般最低是20-30 tokens/s。我们以最低20 t/s为例，就意味着TPOT是50ms(这里没有算Speculative decoding)，以H800为例，其显存为80GB，显存带宽为3350 GB/s，实际推理访问显存时由于碎片等原因 真正带宽利用率按照50%，那么假设50ms全部用于将数据从显存搬运到SM，即便按照1700 GB/s计算，仅能够搬运85GB数据。
85GB看似很多，实际仅意味着能够搬运34个expert的参数。假设采用EP8能放下整个模型(按照630GB显存空间计算)，且EP之间十分均衡，意味着由于显存带宽的限制，最大batch只能达到32(这里省略的计算过程，本质就是假设每个GPU上的显存全部用于存储expert权重，且 32个token就可以激活全部256个expert)。

到这里，其实大家基本就能理解，EP越大，每个GPU上加载的expert 越小，那么在decode计算时需要从显存读取参数的量就越少，越是可以把宝贵的显存带宽给到跟请求相关的空间（如KV cache，中间计算结果等），这样batch就越大，整体的成本就越低。

所以本质上并不是pd比例达到了夸张的1比10，而是decode本身在EP极大的时候才能有最佳的性价比。当然，其背后的代价是请求的总量要达到一定程度才能支撑起"高性价比"
以上是最近的一些思考，一家之言，请大佬们斧正。

清风寡欲

这个主要是decoding显存局限和prefill的qps决定的， decoding因为要处理多个prefill实例过来的请求的kvcache（单次decode请求100M-1G左右，看max tokens），只要decoding显存不爆，然后ep320，搞那么大就是要尽可能多的把decoding batchsize做大，但配比需要实际压测出来……其实decoding适合大显存低算力的卡， 这样成本低啊。
补充：还有很多人从计算角度考虑这个配比问题，其实不对， 单个请求prefill大概是几百ms(不考虑超长prompt)，decode持续几十s（看max tokens /eos,  单次iter 20ms），prefill算完直接释放kvcache显存(没有显存压力)，decode在计算过程中不断累加增量kvcache,  prefill处理并发远高于decode(可以认为prefill是短链接,  decode是长链接),  所以decode集群自然要更多卡,  否则prefill跑的过快,  decode不就炸了, 当然肯定有限流的，所以decode本质上要靠很多卡来解决显存问题， 把batch size做大，llm推理从来不是计算问题(prefill)，是kvcache问题(decode)，这就是mla的价值啊
总之一句话,  谁能把decode batchsize做大,  谁才是王者......尽可能把decode 集群tensor core跑满数据,  吞吐就会越大, 成本就越低,  毕竟tensor core才是最贵的,  搁着空转划不来.

检验医师

这个问题是个好问题，关于LLM PD分离架构P和D应该分配多少算力问题，我也很想知道答案，所以抛砖引玉，给一些我的不成熟看法。
这个问题对应DeepSeekV3技术报告的Sec 3.4，希望各路大佬一起前来解谜。
在采用PD分离Mooncake中，Prefill的算力配置通常大于Decode的，Mooncake实验中Prefill实例和Decode实例比例，按照3-1或者2-2配置。
按照文中描述，DeepSeekV3的Prefill实例用32卡，Attention TP4+DP8，MoE EP32；Decode实例，变成用320卡，Attention TP4+DP80，MoE EP320。我们假设一个Prefill实例配合一个Decode实例。Decode实例的算力显著大于Prefill实例。这是什么原因的呢？
Decode用更多卡有几个缺陷：

• 从Prefill卡搬运KVCache到Decode卡的通信量变大，从32卡搬运到320卡有很多重复数据搬运，但是集合带宽也变大了，所以KVCache搬运的延迟没有受影响。这点并不是大问题。
  
• 过大DP degree导致Decode每张卡能组的batch size变小，GPU的计算效率可能收到影响。原文说每个Expert通常小于256个tokens。这点可能有些严重。
  
• 部署门槛太高了，无需赘言，这也是提问者的潜在台词。
  

也有两个好处：

• Decode阶段，Attention到MoE之间dispatch的集合带宽变大了。用了320个GPU间点对点互联的link。避免了dispatch这块通信延迟过高，成为瓶颈。实际实现中，dispatch的All2All使用一种比较tricky的P2P实现，原文如下，似乎也正是暗示dispatch需要一些特殊优化。
  

For the MoE part, each GPU hosts only one expert, and 64 GPUs are responsible for hosting redundant experts and shared experts. All-to-all communication of the dispatch and combine parts is performed via direct point-to-point transfers over IB to achieve low latency. Additionally, we leverage the IBGDA (NVIDIA, 2022) technology to further minimize latency and enhance communication efficiency.

2. 每个GPU的需要计算的batch size变小了，更容易保证Decode阶段的SLO。这个比较显而易见。但是如果Batching得当，增大batch size不一定会增大多少延迟。所以我猜测还是第一条更关键。
Decode阶段不得不需要320张GPU之巨的配置，而且降低GPU数会影响SLO的话，我倾向于认为是为了让Decode阶段增加GPU间通信带宽的无奈之举。
也有大佬从PD的计算负载角度来解答，认为Decoding阶段负载相比Prefill阶段相对大很多，所以需要尽可能的算力(内存带宽)分配给Decode，那最多算力的配置就是320卡，一卡一专家。我也很认同这个“相对负载说”，不过为什么mooncake没有给Decode分配更多实例呢？这又是另一个谜团了。
相信DeepSeekV3的推理侧会有很大优化空间。鉴于各路主流引擎都已经支持了V3的部署，本问题估计很快会有真实答案。