vLLM团队用16块H200部署GLM-5.3：单套服务支持100万Token上下文
vLLM团队公布GLM-5.3在16块H200（英伟达GPU）上的长上下文部署方案：一个预填充节点加一个解码节点。
预填充侧用PCP（预填充上下文并行）按Token切分查询，并用DCP（解码上下文并行）按Token分片KV缓存（键值缓存）； 解码侧用Hybrid HiSparse把缓存放到主机内存。
团队称这是其测试中唯一能服务100万Token上下文的配置，给出延迟与显存数据，可帮助读者定位长上下文智能体负载的瓶颈。
方案运行在两台8卡H200节点上，采用预填充/解码分离。 预填充引擎为PCP8 × DCP8 × EP8，配512 GiB CPU（中央处理器） KV卸载； 解码节点为8个DP（数据并行）rank、EP8与Hybrid HiSparse（每rank 48 GiB主机池加16 GiB卸载）。
测试使用SemiAnalysis AgentX基准（Claude Code轨迹回放、前缀复用、每档并发新起服务、运行一小时、MTP3固定合成接受长度2.99）。 c32以内、预填充为瓶颈时，PCP8 × DCP8预填充在同等吞吐下交互性为DP8的1.7–3.2倍，中位TTFT（首Token时间）从1.5–5.2秒降至0.8–0.9秒；
c64时解码侧HiSparse接近翻倍吞吐，达8,340 logical tok/s/GPU（图形处理器）、每用户29.6 tok/s，其他配置降至每用户1–2 tok/s。 单个100万Token请求需53.4 GiB FP8 KV缓存，每卡仅约15 GiB空间，DCP将每卡占用降至6.7 GiB。
DCP8在64K上下文内每步增加约6%开销，248K时升至15%。
这条发布的价值在于把“长上下文智能体”落到服务成本上：每一轮工具输出和文件内容都会进入预填充，预填充会成为整条部署的瓶颈，而KV缓存而非算力决定上下文上限。 PCP绕开MLA（多头潜在注意力）在张量并行下重复存储完整缓存与索引器的问题，DCP再按Token摊薄缓存，两者组合才让百万级上下文在16卡上成立；
代价是层间all-gather随上下文增长，且方案依赖特定内核开关（sparse_mla_force_mqa）。 所有性能数字均为作者自述、未独立复现，不能当作通用基准。
后续观察信号
- DCP8的all-gather开销在更大规模集群上如何变化
- 该配置对非GLM系列稀疏注意力模型的适用性