Prefix Cache 命中率如何影响 TTFT？

开启前缀缓存后，面板显示命中率提高了，用户却仍然觉得首字慢。该先怀疑缓存没有生效，还是请求在其他地方等得更久？

假设两次请求都算“命中”：一次只复用了很短的系统指令，另一次复用了大段文档。它们省掉的计算显然不同。即使复用了很长的前缀，请求还可能在队列里等待。Prefix Cache 保存的是兼容前缀的 KV，要判断它有没有改善首字延迟，需要看复用了多长、准备缓存花了多久，以及省下的时间是否被其他等待抵消。

TTFT 的计时边界

TTFT（Time To First Token）是请求开始到首个输出 token 可见的间隔。客户端计时通常包含网络与流式返回；服务端计时可能从接收请求开始。比较结果前应统一起止时刻，不把不同口径的数值混在一起。

在同一口径下，TTFT 可能包含排队、缓存查找与准备、未复用部分的计算，以及首 token 的采样和返回。

命中后还需要做什么

宽图可横向滚动。查看原图查看原图

完全相同的文本不一定能复用 KV。系统还需要确认 token 序列、模型与相关配置兼容；具体缓存键、块边界和共享范围取决于引擎。未命中的部分仍需处理，后续输出也仍需生成。

观察情况	可能减少的工作	仍需确认
命中较长前缀	该前缀的重复 Prefill	首 token 所需的剩余计算、缓存准备成本
仅命中短前缀	少量输入计算	节省是否足以覆盖查找和调度开销
未命中	没有可复用的前缀计算	处理输入，并承担缓存机制的相关开销

前缀 KV 复用主要减少 Prefill；它不会直接减少新输出 token 需要执行的 Decode 步数。答案很长时，TTFT 的改善占总时延的比例也可能较小。

不只看请求命中率

回到开头的两次命中，如果面板只给每条请求记一个“是”，就会把短系统指令与长文档当成同样的收益。还应记录实际复用的 token 数，或采用按 token 加权的命中口径，再分别看命中、部分命中和未命中请求的延迟。

稳定的 system prompt、重复的文档前缀和模板化输入有机会复用缓存。能否获益取决于前缀实际重复且兼容，不由“Agent”或“RAG”这个应用名称保证。跨 worker 时，还要确认请求是否被路由到可访问该缓存的位置，以及路由是否造成排队热点。

用对照实验区分收益与成本

用固定的请求数据比较缓存关闭、开启但冷缓存、开启且预热相同前缀的情况，同时单独控制模型与内核 warmup。记录 p50/p95/p99 TTFT、吞吐、复用 token 数、缓存容量与驱逐情况，再扫描并发度。

如果同一批请求只有部分变快，其余完全不变，延迟分位数不会升高。因此，平均 TTFT 改善而 P99 变差时，必须继续找额外等待或负载变化，不能用“分成命中与未命中两组”结束解释。多 worker 的取舍见缓存局部性与路由，统计口径见推理压测。