为什么仅凭 Decode Batch=16 推不出 P:D 配比？

为什么仅凭 Decode Batch16 推不出 P:D 配比Decode batch16 只告诉你“一个 Decode 工作节点同时处理 16 个请求”但完全没有揭示系统整体的负载产生速率Prefill 压力与请求滞留时间Decode 周期。要精准计算 Prefill 节点数与 Decode 节点数的比例Npre:NdecN_{pre} : N_{dec}Npre​:Ndec​必须补齐以下四大关键变量长度分布Prompt / Output Length Distribution核心影响决定算力重心的倾斜方向。短 Prompt 长生成如Lpre100,Ldec2000L_{pre}100, L_{dec}2000Lpre​100,Ldec​2000请求会在 Decode 节点滞留很久需要大量 Decode 卡来消化积压的 Batch此时 P:D 配比可能低至 1:8。长 Prompt 短生成如 RAG 场景Lpre8000,Ldec100L_{pre}8000, L_{dec}100Lpre​8000,Ldec​100Prefill 阶段计算量剧增且传输巨大的 KV Cache需要大量 Prefill 卡砸算力此时 P:D 配比可能高达 4:1。到达率Arrival Rate / QPS与稳态流量到达率λ\lambdaλ决定了系统单位时间内产生的新 Prefill 任务总量。根据 Little’s Law利特尔法则系统中的平均并发请求数Nˉλ×平均响应时间\bar{N} \lambda \times \text{平均响应时间}Nˉλ×平均响应时间。只有知道λ\lambdaλ才能算出要维持 Decode 侧满载 Batch16 运转时上游 Prefill 节点需要以多大的吞吐不断向 Decode 池“输送”算完 KV Cache 的新请求。稳定吞吐Steady State Throughput必须知道单张 Prefill GPU 的实际处理吞吐如TpreT_{pre}Tpre​tokens/s/GPU与单张 Decode GPU 在 Batch16 下的实际吐字吞吐如TdecT_{dec}Tdec​tokens/s/GPU。只有拿到单卡真实吞吐上限才能把 Token 级的负载映射为物理 GPU 数量。SLA 约束Service Level AgreementTTFT首字延迟上限如果 SLA 要求 TTFT 特别严苛如100ms100\text{ms}100msPrefill 节点就不能采用大 Chunk 或高 Batch 运行必须牺牲利用率、留出算力冗余Over-provisioning这会导致需要配置更多的 Prefill 卡。TPOT/ITL逐字延迟上限虽然设定了 Batch16但为了满足 TPOT SLA可能需要为 Decode 节点开启更高的 TP张量并行以降低单步延迟从而改变硬件卡的物理配比。系统平衡的物理直觉在系统达到稳态时Prefill 池产出 KV Cache 的速率必须严格等于 Decode 池消耗/接管 KV Cache 的速率Prefill 池总供给∝Npre×Capacitypre\text{Prefill 池总供给} \propto N_{pre} \times \text{Capacity}_{pre}Prefill池总供给∝Npre​×Capacitypre​Decode 池总需求∝QPS×Lˉpre\text{Decode 池总需求} \propto QPS \times \bar{L}_{pre}Decode池总需求∝QPS×Lˉpre​没有流量到达率λ\lambdaλ、上下文长度Lˉ\bar{L}Lˉ和 SLA 带来的利用率折损仅靠一个静态的 Decode Batch Size 无法列出方程自然推不出唯一的物理节点配比。