05. Pensieve — 多轮对话 KV 复用与跨会话调度

元数据

论文标题:Pensieve: Retrospect-then-Compare for Multi-turn LLM Serving (具体题目以最终发表为准)
出处:OSDI 2024(部分版本在 EuroSys’25)
关键词:multi-turn dialogue、KV reuse、conversation-aware scheduling

⚠️ 本笔记为基于公开摘要 / 工程二次资料的初步整理——精确数字以原文为准。

一句话精髓

多轮对话场景下,把”会话历史”作为一等公民放进调度器,KV 复用从被动 cache 升级到主动调度。

解决的问题

聊天 / Agent 类长会话的特点:

同一 session 的轮次之间 KV 高度相关
不同 session 的复用率极低,但调度器经常把同一 session 切到不同 GPU,KV 全丢
已有 prefix cache 命中后还是要把 KV 拷回当前实例,搬运不是免费的

Pensieve 的视角:调度器应该感知会话亲和性,让同一 session 尽量回到原 GPU,而不是事后再补救。

关键 idea

设计	内容
会话亲和路由	维护 session→GPU 映射,新轮次优先回原 GPU
KV 漂移容忍	原 GPU 满了允许”温迁移”——把 KV 同步到新 GPU 再开 decode
跨轮 prefix 重排	会话历史里高复用片段(system prompt、固定文档)单独打 tag
调度与放置耦合	调度决策直接依赖 KV 当前所在层级,而不是只看 GPU 利用率

关键架构图

        新轮次请求(session_id)
                │
                ▼
        ┌──────────────┐
        │ Affinity LB  │── 查 session→{GPU, KV 在哪一级}
        └──────┬───────┘
               │
       ┌───────┼────────┬─────────┐
       ▼       ▼        ▼         ▼
     GPU#1   GPU#2    迁移      回退到 prefill
     hit     近旁     (DRAM     (cache miss)
             pool     →HBM)

关键数据(公开报告)

多轮长对话场景下,KV 命中率显著优于 hash-based prefix cache
端到端首 token 延迟改善取决于会话长度——越长,收益越大
集群尾延迟 P99 改善明显(因为减少了”切实例后重 prefill”的尖刺)

局限

强亲和性带来负载不均,极端情况下少数 hot session 把某个 GPU 拖死
跨实例迁移本身有开销,小会话场景反而不划算
调度器复杂度上升,故障切换时容易把 session 状态搞丢

对本项目的启示

🌟 存储层与调度层的耦合是项目第一模块的关键问题之一——Pensieve 给了一个具体范例:

多类型数据的亲和路由:不只是 KV,用户的向量记忆库 / RAG 文档块也要做亲和(同一用户的所有数据放近一点)
会话与层级联动:活跃会话进 HBM,睡眠会话退 DRAM,长期不活跃退 SSD——把 Pensieve 的 session→GPU 扩展到 session→{GPU, mem level}
温迁移的成本模型:迁移本身不是免费,需要建模”迁移收益 vs 重 prefill 代价”,这正是项目”token 单位成本”问题的子问题
结合容错:亲和路由失败时(GPU 故障),容错协议怎么和会话状态对接?——这跨到第三模块

横向对比

系统	KV 复用粒度	调度感知	多类型
vLLM prefix cache	hash-based 块	❌	❌
AttentionStore	session 级	部分(预取)	❌
Pensieve	session + 路由	✅ 强亲和	❌
本项目目标	session + 多类型 + 三级	✅ + 成本驱动	✅

待精读

论文具体的亲和性策略(纯 sticky?加权?如何处理热点?)
故障切换协议
与 LMCache 跨实例池的协同 / 冲突

05. Pensieve — 多模态 Agent 长记忆系统设计

搜索