vLLM如何为Qwen3.8-2.4T打造PD分离式推理方案

2026年9月21日阅读约 3 分钟

导语

Qwen3.8-2.4T采用大规模混合架构，对推理服务的显存规划和并行策略提出了更高要求。vLLM最新测试聚焦GB300 NVL72集群上的Prefill-Decode（PD）分离服务，在输入长度8K、输出长度1K的场景中，同时考察高吞吐与低延迟两类目标。

在高吞吐配置下，vLLM报告每GPU约5000个总Token的吞吐；在偏向交互性的配置下，则达到每用户180个生成Token。与只追求吞吐曲线左侧的做法不同，这次测试尝试覆盖完整的性能前沿，说明同一模型需要针对业务目标设计不同的PD配方。

KV缓存首先决定并发上限。 Qwen3.8-2.4T包含92层，其中69层为GDN、23层为Full-Attention，并在每层配置MoE。Full-Attention状态随Token增长，而GDN状态按请求保存，因此单请求的固定状态成为显存规划中的关键因素。
块大小受到GDN状态支配。 按文中的估算，GDN状态约为4.125MiB，单个KV块可容纳2112个Token。对于8K输入、1K输出的请求，Full-Attention和GDN分别占用不同数量的块，最终共同决定单请求的缓存开销。
显存预算不能只看模型权重。 驱动、CUDA上下文、NCCL缓冲区、分配器、激活峰值以及CUDA Graph都会占用空间。vLLM还会依据gpu_memory_utilization预留一部分余量，因此实际可用于KV缓存的显存要经过多轮扣减。
PD两端需要协调块配置。 Prefill与Decode可以独立计算块大小，但KV缓存传输要求双方匹配。如果不一致，就需要手动设定足够大的--block-size，代价是部分显存空间被浪费。
吞吐和交互性对应不同拓扑。 素材列出了TP8、TP4DP4以及不同并发和批处理上限下的测试配置，显示调优不是简单增加并发，而是要结合激活峰值、CUDA Graph容量和KV缓存余量反复权衡。

这份结果的价值不只在于5000和180两个指标，更在于给出了可复用的排查路径：先估算每请求状态，再核对权重和运行时内存，随后测量激活峰值，最后围绕并发、批大小与并行拓扑构建吞吐—延迟曲线。对于采用混合注意力、递归状态或MoE结构的模型，传统只按参数量估算显存的方法可能并不充分。

同时，PD分离服务的优化重点已从单纯的算力利用，扩展到Prefill与Decode之间的缓存布局、传输兼容性和资源隔离。vLLM将这些步骤整理为可复现实验配方，有助于用户针对自身模型和服务目标重新进行测量，而不是直接照搬某一个最佳配置。