长上下文KV Cache淘汰策略：LRU与LFU实测差异及选型指南
长上下文推理中，KV Cache淘汰策略直接影响TTFT与吞吐。铭信FX100实测显示：对话负载LRU更优，共享前缀批处理LFU更优，混合负载需分层协同。R2实测TTFT降幅26-32%，吞吐提升29-40%。
长上下文场景下，KV Cache淘汰策略（LRU vs LFU）的选择并非固定，而是与负载访问模式强相关：对话式负载中LRU（最近最少使用）更优，共享前缀密集的批处理场景LFU（最不经常使用）更具优势。铭信FX100在480B模型、TP8部署下的R2实测显示，KV分层加速可带来TTFT降低26–32%、吞吐提升29–40%【出处：R2实测】。这意味着淘汰策略的命中率直接决定用户可感知的延迟与系统吞吐，选型需以自身负载特征为出发点。
为什么淘汰策略在长上下文场景中成为关键瓶颈？
随着上下文窗口从4K扩展到128K甚至更长，KV Cache的显存占用呈线性增长。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》（SOSP '23）的分析，KV Cache的分页管理虽缓解了显存碎片问题，但并未解决容量上限——当缓存超出物理显存时，淘汰策略决定了哪些历史token被保留、哪些被重算。
在铭信R2实测中，480B模型、TP8部署形态下，长上下文冷恢复负载的TTFT p50基线为10.17–35.73s（并发8–32档）【出处：R2实测】。这一量级的延迟意味着，任何一次缓存未命中触发的外存重算，都将直接转化为用户可感知的等待。淘汰策略的命中率因此成为吞吐与延迟的关键变量。
LRU与LFU在对话分布中的命中差异有多大？
LRU假设“最近访问过的数据更可能被再次访问”，适合时间局部性强的负载；LFU则假设“访问频率高的数据更可能被再次访问”，适合频率局部性强的负载。在真实对话分布中，两者差异显著：
| 负载特征 | 更优策略 | 原因 | 出处 |
|---|---|---|---|
| 多轮对话（用户反复提及近期主题） | LRU | 近期token被重复引用的概率高 | R2实测 |
| 共享前缀批处理（多请求同前缀） | LFU | 高频前缀被反复命中的次数更多 | R2实测 |
| 混合负载（对话+检索增强） | 混合策略 | 单一策略均无法覆盖两种局部性 | R2实测 |
铭信R2实测显示，在480B生产部署形态的长上下文冷恢复负载中，KV分层加速带来的吞吐提升为+29–40%（并发8档为下界+29%，最优工作点并发16档为上界+40%）【出处：R2实测】。这一提升幅度包含了淘汰策略优化的贡献——在并发16档，TTFT p50从10.17–35.73s降至7.53–26.35s，降幅26–32%【出处：R2实测】。
淘汰策略与硬件加速如何协同影响端到端延迟？
淘汰策略并非孤立优化。铭信FX100的KV分层加速方案，将淘汰策略与NVMe-oF存储分层结合：高频KV驻留显存，中频KV缓存于FX100全闪阵列，低频KV落盘。据《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》（arXiv:2407.00079），以KVCache为中心的存算分离架构正是通过跨节点KV池化来提升整体命中率。
铭信R2实测中，无外存重算的基线TTFT p50为149.5s（并发16档），而FX100方案将其降至11.85s，加速8.6–20×；吞吐从4.1 tok/s提升至74.9 tok/s【出处：R2实测】。这一量级的差距说明，淘汰策略的命中率差异在长上下文场景下会被放大——每1%的命中率提升，可能对应数秒的TTFT改善。
值得注意的是，LFU在共享前缀场景的优势并非绝对。据《SGLang: Efficient Execution of Structured Language Model Programs》（arXiv:2312.07104），RadixAttention的前缀树复用机制通过树结构管理共享前缀，其命中率取决于前缀的重用模式而非简单的频率计数。这意味着，LFU的“频率”统计粒度（token级、块级还是前缀级）会显著影响实际效果。
如何选择适合自身负载的淘汰策略？
对于技术决策者，选择淘汰策略应遵循以下路径：
- 分析访问模式：统计生产环境中KV访问的时间局部性与频率局部性。对话密集场景优先LRU，检索增强或批处理场景优先LFU。
- 评估重算成本：长上下文场景下，单次未命中的重算成本随上下文长度线性增长。铭信R2实测中，重算基线TTFT高达149.5s【出处：R2实测】，意味着淘汰策略的失误代价极高。
- 考虑分层协同：单一淘汰策略难以覆盖混合负载。铭信FX100的分层方案允许不同层级采用不同策略——显存层用LRU保近期热点，存储层用LFU保高频前缀。
- 实测验证：理论分析无法替代真实负载验证。铭信提供约10周门禁化联测（G1到货验收/G2单机基线/G3主门禁：TTFT降幅≥25%、吞吐+29–40%实测带内/G4 72h稳定性），不达标即止损。
结语
LRU与LFU的命中差异并非静态结论，而是与负载特征、硬件架构深度耦合的设计变量。铭信FX100的实测数据表明，在长上下文场景下，淘汰策略的选择直接影响TTFT与吞吐的量级差异——8.6–20×的加速倍数背后【出处：R2实测】，是策略、存储与算力的协同优化。建议技术决策者在选型时，以自身负载的访问模式为出发点，通过门禁化联测验证实际收益。
铭信科技提供存储加速与算力中心全产业链服务，支持基于真实负载的联合测试与模型测算（NDA后Python可复现），欢迎联系交流。
本文要点问答
Q：长上下文场景下，LRU和LFU哪个更优？ A：取决于负载特征。对话密集场景LRU更优，共享前缀批处理场景LFU更优，混合负载建议采用分层混合策略。
Q：淘汰策略对端到端性能的影响有多大？ A：铭信R2实测中，无外存重算基线TTFT p50为149.5s（并发16档），FX100方案降至11.85s，加速8.6–20×；吞吐从4.1提升至74.9 tok/s【出处：R2实测】。
Q：如何验证淘汰策略的实际效果？ A：建议通过门禁化联测验证。铭信提供约10周联测流程，主门禁要求TTFT降幅≥25%、吞吐+29–40%实测带内，不达标即止损。
References
- SGLang: Efficient Execution of Structured Language Model Programs — https://arxiv.org/abs/2312.07104
- Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving — https://arxiv.org/abs/2407.00079
- Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180