上下文达到百万 Token 时，如何控制响应延迟？介绍预填充分片、并行解码、上下文压缩，以及请求和租户两级预算。
处理百万 Token 的请求，不能直接照搬短请求的方式。随着上下文变长，延迟可能突然升高，导致下游接连超时。下面介绍三种优化方法，用于在上下文增长时控制 P99 延迟。
拆分预填充，分设备并行处理
长上下文处理的主要开销在预填充阶段，这一阶段也适合并行计算。我们按语义边界拆分提示词，把各个分片交给不同设备同时处理，再在解码前合并 KV 缓存。上下文超过 20 万 Token 时，这种方式可以将首 Token 响应时间缩短约 60%。
并行解码
解码需要按顺序进行，可以用小型草稿模型先预测一批 Token，再让目标模型一次性验证，以减少等待时间。在结构化输出任务中，草稿 Token 的接受率超过 70%。
上下文压缩
- 请求发往上游前，先去除不同文档中重复的模板内容。
- 检索结果只保留达到相关性阈值的片段，不为凑满固定的 k 值而加入无关内容。
- 长对话保留最近二十轮，更早的内容用摘要代替。
很多百万 Token 请求，其实并不需要这么长的上下文。客户请求中，可压缩冗余的中位比例为 23%。与其想办法更快地处理冗余，不如先去掉它们，既省时间，也省成本。
同时限制单次请求和租户用量
除了限制单次请求的 Token 数量，还需要设置每个租户的小时预算。只设其中一项都不够：失控的 Agent 循环，可能在二十分钟内用掉一天的容量。这也是我们在长上下文场景中最常遇到的问题。