首页 / 知识库 / 长上下文首 token 延迟为什么高？
知识库
长上下文首 token 延迟为什么高？
长上下文会话的首 token 延迟高，多半是因为这段上下文的 KV 缓存已被挤出显存，模型要先把历史内容重算一遍才能输出。上下文越长，这一步越久。
首 token 延迟由哪几段时间组成？
首 token 延迟主要由排队时间和 prefill 时间组成。prefill 是模型读完全部输入并建立 KV 缓存的过程，输入越长算得越久；缓存如果还在，这一步几乎可以跳过。
所以同一个请求，缓存命中和不命中的体验差别很大。R2 和 R3 记录的一组读数是：同一前缀的第二次请求，首字延迟从 29.15 秒降到 0.37 秒。
三种处理办法实测差多少？
R2 在 480B 模型、并发 16 的条件下对比了三种办法：现场重算，首 token 延迟中位数 149.48 秒；缓存放本地 NVMe 单盘，17.31 秒；缓存放 FX100，11.85 秒。
| 办法 | 首 token p50 | 吞吐 | 特点 |
|---|---|---|---|
| 现场重算 | 149.48 秒 | 4.1 tok/s | 不需要额外存储，但 GPU 在重复计算 |
| 本地 NVMe 单盘 | 17.31 秒 | 53.6 tok/s | 便宜，但缓存不能跨节点共享 |
| FX100 外部全闪 | 11.85 秒 | 74.9 tok/s | 可跨实例共享，容量大 |
并发升高以后会怎样？
并发从 8 升到 32，三种办法的首 token 延迟都会变长，但差距一直存在：FX100 的中位数是 7.53 到 26.35 秒，本地 NVMe 单盘是 10.17 到 35.73 秒，降幅保持在 26% 到 32%。
吞吐在并发 16 时最高，再往上加并发基本持平，说明这台机器的最优工作点在并发 16 附近。选并发档位时，可以用同样的方法在自己的负载上找这个点。
我该从哪里开始优化？
先确认问题是不是出在重算上：统计会话恢复请求的占比和它们的首 token 延迟。如果恢复请求明显更慢，再评估缓存分层；否则瓶颈可能在别处。
分层方案的组成见 KV Cache 分层加速方案，原理见 KV Cache 分层是什么。
常见问题
TTFT 是什么意思？
TTFT 是 Time To First Token 的缩写，中文叫首 token 延迟或首字延迟，指从请求发出到模型吐出第一个 token 的时间，是在线推理的关键指标。
加显存能解决首 token 延迟吗？
能缓解，但成本高。显存越大，能留住的缓存越多；可是会话数一多还是会被挤掉。R5 的论证是：把 KV 缓存放到外部存储层，可以替代 128GB 级别的显存驻留。