对 GLM-5.2 NVFP4 在四个 DGX Spark 节点上运行的后续调查解决了之前的性能瓶颈问题，即在 128K 上下文时无法实现高接受率。

根本原因是 vLLM 的 `SpeculativeConfig.create_draft_parallel_config()` 中存在一个 bug，未能复制 `decode_context_parallel_size`，导致草稿层忽略了 DCP 分片。这致使注意力机制将本地缓存片段处理为全局数据，从而导致 MTP2 和 MTP3 的接受率崩溃。

  • 使用 DCP4 和 MTP3/MTP4 时，性能从 ~15 tok/s 提升至 128K 上下文下的 ~24 tok/s。
  • 每个位置的 MTP 接受率在前三次推测 token 上分别达到 0.90、0.79 和 0.67。
  • 修复方法包括添加缺失的配置行以镜像上游逻辑，并重新基于更新的 vLLM 分支。

此解决方案消除了之前上下文长度与速度之间的权衡，允许用户在此硬件配置下以高吞吐量运行完整的 128K 上下文。