吞吐反超vLLM！ PD分离（Dynamo）实战：H100砍半、TTFT/TPOT双升的调优秘籍

在开源Dynamo框架原始吞吐弱于vLLM的背景下，PPIO推理加速团队通过分桶调度+内存重构+通信加速三大创新调整，首次实现PD分离架构在真实业务场景的经济性突破：

• 资源成本锐减40%：动态合并碎片请求、分桶调度长短文本，GPU利用率提升至临界点（batch≥14即反超vLLM）；
• 用户体验双向优化：TTFT缩短30%+TPOT加速18%，破解“降本必损性能”行业魔咒；
• 为长上下文而生：KV缓存连续化改造提升NVLink传输效率50-100%，奠定百万token推理基建；
  本文首度公开Dynamo超车vLLM的核心调优路径，为千亿模型低成本、高性能部署提供可复用的解决方案。

以下为原文：

首先感谢Dynamo的开源，否则PPIO推理加速团队也无法短期内完成PD分离的真正上线，我们针对近期在Dynamo上的工作，做一些总结与分享。

分享的内容主要是Dynamo在实际业务中，尤其是相对不理想的业务环境中，怎么做一些针对性的调整，去完成对比vLLM而带来的正向收益（官方Dynamo相比vLLM是大约-3%的吞吐表现）。可以简单的透露下，我们通过对Dynamo做一定的调整，在线上完成H100显卡40%的缩减，同时TTFT与TPOT指标还有不同程度的提升。

如下图所示，我们对比调整后的Dynamo与vLLM的性能对比测试，压测数据是接近用户输入的动态长度数据，结果表明：一旦单卡batchsize超过14，PD分离方案就会有比较明显的吞吐优势。

接下来，我们对Dynamo做的主要改动做一些分享：

调度优化

batch合并

Dynamo本身是一个串行的队列消费方式，即无论request中的prompt长短，Prefill节点都是执行完一个request，才会去队列中消费下一个request。而在实际的业务中，用户输入/输出的长度是变化不定的，如下图所示，这是用户输入/输出长度的分布：

从图中，我们可以明显看到用户有大量长度小于1024的请求，而针对用户输入较短的场景，采用串行的执行方式，往往会存在大量的GPU算力浪费，如下图所示，原始Dynamo的Prefill节点存在气泡与GPU整体算力使用率较低的情况。

我们根据用户的输入长度与实际的GPU负载，对Dynamo的队列消费机制进行调整，即将长度小于的1024的request，通过batch合并的方式，将多个小batch或者多个batch进行合并，从而提升GPU执行的并行度，并提升TTFT指标。

分桶调度

正如上文所说，用户的输入/输出长度是一个相对离散的分布，Dynamo当前采用的方式单队列生产消费，但这样就会带来一个问题，即TP的性能问题。

一般来说，TP越高，支持的prompt就越长，但因为带来额外通信的开销，推理的效率就会越低。如下图所示，我们测试TP=2/4在不同batchsize下的吞吐与TTFT表现，明显可以看出TP=2的效率会更优一点。

因而我们对Dynamo采用一种分桶策略，如下图所示，将原本对单队列拆成长队列（long queue）与短队列（short queue）两个队列，Decode 节点在生产时，将长度大于2048的数据塞入long queue，小于2048的数据塞入short queue；Prefill节点在消费时，TP=2的Prefill节点优先消费long queue，倘若long queue为null，则消费short queue，而TP=1的Prefill节点只消费short queue。通过这种方式，能将prompt较长的数据塞入TP较高的节点，prompt较短的数据塞入TP较低的节点，从而能降低因为TP带来的无效开销。

通信优化

vLLM本身的内存结构，并不是一种适合KV Cache传输的一种内存结构，我们适当的将vLLM的内存结构，从[layers,k/v,block_id,num_head,head_size,block_size]调整为[block_id,layers,k/v,num_head,head_size,block_size]。一般来说，网络传输中的数据块越大，整体的网络利用率就会越高，以llama3 8b为例，我们做以上的调整后，原本因为分层导致的32个非内存连续块，就可以转化为一个连续的数据块。
我们通过NXIL库进行KV Cache数据传输单元测试，在H100上进行Llama 3.3 70B的1024长度提示词测试，发现调整后的KV Cache内存结构，整体能带来50%-100%的nvlink传输效率提升。

总结

以上是我们针对Dynamo做的一系列优化与测试，目前线上能有TTFT和TPOT大约有30%和18%的提升，同时我们还做了seed（随机种子）、metrics（TTFT/TPOT/e2e）、v1/v1-chat、stream等功能上的支持，下一步会重点考虑集群调度、异构硬件、long context以及suffix decoding等方向上的优化，欢迎各位技术交流。