百万token上下文挤进16块H200：GLM-5.3把KV缓存按token切开，单用户速度提至3.2倍
核心概要
GLM-5.3的长上下文服务在16块H200上受KV缓存显存与预填充速度双重限制。预填充端把每个提示按token切到8块GPU（PCP），再把KV缓存按token分片（DCP），使100万token请求每卡只需6.7 GiB；解码端用Hybrid HiSparse把KV放到主机内存。在AgentX基准上，PCP8×DCP8预填充配HiSparse解码在同等吞吐下给出DP8部署1.7–3.2倍的单用户速度，也是所测配置中唯一能服务100万token上下文的方案。
深度剖析
长上下文智能体负载下，GLM-5.3的权重占去H200大部分显存，留给KV缓存的空间很小，预填充引擎在负载下还会成为整个部署的瓶颈。 此前在单台8×H200节点上，Hybrid HiSparse已能让长上下文装进聚合式部署；预填充/解码分离部署还需要额外手段。 一个100万token的GLM-5.3请求需要53.4 GiB FP8 KV缓存，而每块GPU只有约15 GiB可用空间。
预填充端把每个提示按token而非按注意力头分到8块GPU，每块GPU计算八分之一提示的全部64个注意力头。 DP8把每个提示放在单块GPU上，注意力用不到其余七块；TP8按头切分，但MLA的潜KV被全部64个头共享，每块GPU仍存完整缓存，且索引器完全不切分。 按token切分后，每行KV读出服务全部64个头，稀疏MLA从约26提升到约191 FLOPs每字节搬运，接近H200在BF16下的计算受限点。
DCP把KV缓存本身按token轮转分片，每块GPU只存每八个token中的一个，使100万token请求的每卡缓存降到6.7 GiB。 PCP虽然分摊了查询计算，但每层新KV都要all-gather，每块GPU最终仍存完整缓存，限制上下文长度的正是这份复制缓存。 在相同缓存上下文下，DCP8在64K token以内每步增加约6%开销，到248K时升到15%；超过约250K token后，仅靠PCP8已装不下KV缓存。
整套部署跑在两台8×H200节点上，预填充端为PCP8×DCP8×EP8引擎，解码端为八个DP rank配EP8与Hybrid HiSparse。 对比对象是DP8预填充（八个DP rank各带64 GiB CPU KV卸载，合计同样512 GiB）与纯CPU KV卸载的解码端，所有配置使用相同的16块GPU、主机内存和vLLM构建。 在SemiAnalysis AgentX基准上，c32以内预填充主导，PCP8×DCP8预填充在同等吞吐下给出DP8的1.7–3.2倍交互性，中位TTFT从1.5–5.2 s降到0.8–0.9 s；c64时HiSparse解码接近翻倍吞吐，达8,340 logical tok/s/GPU、29.6 tok/s/user。
启示与展望
结果来自两台8×H200节点上的预填充/解码分离部署，使用FP8 KV缓存与MTP3投机解码，并在SemiAnalysis AgentX基准上以固定合成接受长度2.99回放Claude Code轨迹测量；所有配置共用相同的16块GPU、主机内存和vLLM构建。
DCP每层都要all-gather整个已缓存上下文，其开销随上下文长度增长，在64K以内约6%、248K时约15%；这一开销可通过把每层all-gather与上一层计算重叠来降低，相关工作仍在进行中。