Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
KV cache 这个东西应用层要关心吗？感觉是推理框架内部的事。
不用实现，但要关心后果。上下文越长、并发越高，KV cache 压力越大。
应用层决定历史消息塞多少、RAG 片段塞多少、并发怎么排队，所以当然间接影响。
那我把历史都截短就行？
截短是手段，不是目标。要保留当前任务需要的状态，删掉重复闲聊和过期信息。
我们遇到过聊十几轮越来越慢，后来发现前端一直带全量历史。
这就是应用层问题，不是模型突然变笨。
KV cache 能不能落盘？
有些框架有缓存和复用思路，但别指望落盘解决所有问题。延迟和命中条件都要看。
生产上先做限制：单会话最大上下文、最大输出、超时、并发队列。
还要考虑隐私。缓存复用不能跨用户泄露上下文。
原来它和产品设计也有关。
对。聊天框无限历史是产品爽，推理服务痛。
这句可以贴在需求评审里。
你好！看起来您对这段对话很感兴趣，但您还没有一个账号。
厌倦了每次访问都刷到同样的帖子？您注册账号后，您每次返回时都能精准定位到您上次浏览的位置，并可选择接收新回复通知（通过邮件或推送通知）。您还能收藏书签、为帖子顶，向社区成员表达您的欣赏。
有了你的建议，这篇帖子会更精彩哦 💗
