vLLM如何让GLM-5.3在16张H200上处理百万Token上下文

导语

智能体每轮调用工具、读取文件并生成新输出，历史上下文会持续变长。对GLM-5.3这类采用稀疏注意力和混合专家结构的模型而言，长上下文部署面临两个瓶颈：GPU显存难以容纳不断增长的KV缓存，预填充阶段又需要处理越来越长的提示词。vLLM在最新实践中把两台8张H200的节点拆成预填充节点和解码节点，并组合三种并行与缓存技术，探索百万Token上下文的可行路径。

核心要点

• PCP拆分查询而非注意力头。 预填充上下文并行把一个提示词按Token分配给8张GPU，每张卡保留全部64个注意力头。为避免因因果注意力造成前后负载不均，系统将提示词切成16段，再把前后段配对分发。这样，索引器不再由每张卡重复计算，稀疏MLA的访存效率也得到改善。
• DCP进一步拆分持久化KV。 PCP虽然能分摊计算，却会让每张GPU保存完整KV缓存。DCP采用轮询方式分片，让每张卡只保留八分之一的Token。文中给出的例子显示，百万Token请求所需的53.4 GiB FP8 KV可降至每卡约6.7 GiB。
• PCP与DCP需要通信换容量。 在预填充过程中，每层都要临时聚合分片后的上下文，完成本地查询计算后再释放。测试显示，DCP在较短缓存上下文下增加约6%的单步开销，接近248K Token时升至约15%。这说明DCP不是免费扩容，但在超长上下文场景中，它可能是跨过显存限制的必要条件。
• 解码阶段依靠Hybrid HiSparse。 解码节点使用8个数据并行副本，并把部分KV放入主机内存，以提高长上下文下的并发能力。预填充节点还配置了CPU KV卸载，用于复用后续轮次的前缀。

为什么不用传统TP或DP

数据并行会把一个长提示词交给单张GPU，无法利用其他GPU降低首Token延迟；同时，该请求的KV必须塞进单卡。张量并行虽然拆分了注意力头，但MLA的潜变量KV对所有头共享，缓存仍会在各卡复制，负责筛选候选Token的索引器也会重复执行。PCP把查询工作按Token铺开，DCP则解决缓存复制，两者针对的是不同瓶颈。

意义与影响

这项实践的价值不只是把模型“塞进”更多显存，而是展示了长上下文服务中计算、缓存和通信的协同设计。vLLM在AgentX基准上报告，PCP8×DCP8预填充配合Hybrid HiSparse解码，相比相同吞吐的数据并行部署，单用户速度提升1.7至3.2倍；在测试配置中，它也是唯一能服务百万Token上下文的方案。

不过，结果并不意味着该架构适用于所有负载。DCP的全层聚合会消耗互联带宽，当前开销还可通过计算与通信重叠进一步降低；主机内存卸载也会把压力从HBM转移到系统内存和网络路径。对需要长历史、多轮工具调用的智能体应用而言，这种分层设计提供了更现实的部署思路：用PCP提升长提示词处理效率，用DCP扩大缓存容量，再用主机内存延伸解码并发边界。

来源：vLLM Blog