1. 四层状态,四种正确性条件

若把三类缓存混用,隐私、性能和正确性都会出问题。下表先固定本文的用语。

层级公开例子可观察语义禁止外推
模型 runtime KVvLLM/SGLang、Kimi/DeepSeek self-host 文档prefix reuse、block/page、迁移或 P/D 的实现可被复现。某厂托管 API 的物理 cache layout。
托管 prompt cacheOpenAI prompt_cache_key、xAI x-grok-conv-id、Gemini cache、MiniMax automatic cachestable prefix / TTL / routing hint / usage 行为。缓存一定命中或持久保存用户数据。
会话/Agent 状态tool call、thread/conversation、context compaction请求间如何恢复业务语义。与 KV block 一一对应。
逻辑隔离DeepSeek user_id 的 content safety / KVCache / scheduling isolation账户/租户语义上的隔离规则。物理存储位置、网络隔离实现。

2. Runtime KV:它是每层、每 token、按模型配置定义的计算状态

自回归 decoder 在 prefill 后为每层保存 K/V;后续 decode 对新 query 读取这个历史。PagedAttention 将连续 token 地址映射到物理 KV blocks,使不同 sequence 的块可以独立分配、共享、copy-on-write、换出或释放。模型 identity 不是仅 prompt bytes:它至少包括 checkpoint/revision、tokenizer、position/rope policy、精度、模型并行布局以及可能的 multimodal processor。

safe KV reuse key (conceptual) = model revision + tokenizer/template + token ids + position policy + KV precision/layout + relevant adapter/processor state prompt text 相同但模板、tokenizer 或图像 resize 改变时,复用旧 KV 可能语义错误。

MoE 并不直接改变每层 K/V 的定义,但它会让一个 token 的计算/通信路径更复杂;MLA、DSA、CSA、MSA 可能引入压缩表示或 index state,因此不应使用单一 KV 字节公式覆盖所有模型。

3. 托管 prompt cache:这是一个性能机会,不是持久化数据库

OpenAI、xAI、Gemini、MiniMax 等平台公开不同的 prompt/context cache 机制。客户端应保证可重用的系统提示、工具描述、文档前缀、模型 ID 和模板前置稳定,将频繁变化的用户 tail 放在后面;同时必须为完全 miss 建立性能/费用基线。

TTL、cache key、会话 ID、区域、模型更新、请求形状和平台容量都可能改变命中。cache hit 不可被当作一致性保证:更新一个工具 schema、变更图片缩放或切换模型 revision 时,应主动使旧 key 失效,而不是期待系统‘自己懂’。

安全边界:不要把 provider cache 当作跨用户共享记忆。多租户系统必须将 tenant、权限、敏感数据版本和请求身份放进自己的缓存身份/访问控制设计中。

4. Agent 生命周期:模型暂停时,KV 只是状态的一部分

Agent 请求经常是 LLM → tool → LLM → tool → ...。工具运行可能花秒到分钟,期间 LLM KV 是否继续占 HBM、迁到 DRAM/远端、被丢弃后重算,是 runtime 决策;业务上还要保存 tool input/output、文件版本、权限、planner DAG、预算、checkpoint、幂等 key 和审计记录。

Agent checkpoint = conversation / normalized messages + model & template version + tool DAG and completed results + authorization / tenant / budget + optional runtime KV locator (not the only durable truth)

Agent 会暂停、分叉、回滚、重试,还可能长期持有外部资源,把它当成一个长 chat session 会漏掉这些状态。Agentic serving研究页继续讨论调度后果。

5. P/D、跨节点 KV 与逻辑隔离:正确性先于搬运速度

prefill 与 decode 分离后,已有计算状态要交给 decode worker。目录必须记录 state location/validity,传输要携带 revision/precision/layout,receiver 负责完整性检查。abort、timeout 和 retry 不能留下不可达的孤儿 state,eviction 与 refcount 也不能回收仍在使用的 prefix。Mooncake、Jenga、DroidSpeak 分别研究了 disaggregated KV、异构 allocator 和跨 fine-tune KV reuse。

DeepSeek API 中 user_id 的 KVCache/scheduling isolation 说明了逻辑 namespace,可用于设计客户端 tenancy;它没有声明远端 KV 的物理地址。这样表述既符合接口文档,也不会把控制面误画成数据中心拓扑。

6. 缓存与 Agent 状态的验收测试

  1. 测试 identical prefix、one-token delta、template revision、adapter/processor change 和 cross-tenant,验证命中/失效是否符合预期。
  2. 记录 cache hit/miss 的 TTFT、TPOT、字节、KV blocks 与 p99,保留 miss 基线。
  3. 工具调用中断后,验证重复执行是否幂等、是否从正确 checkpoint 恢复、是否泄漏前一用户状态。
  4. P/D 传输测试 timeout、worker restart、目录失效、block refcount 和多副本竞争。
  5. 长 context 比较 cache reuse 与全量 prefill 的输出,防止 position/rope/quantization 不一致带来的隐蔽质量问题。

7. 多模态和 adapter:cache identity 的隐藏维度

同一段文字配上不同的图像 resize、抽帧、音频采样率、vision processor、LoRA/adapter 或 reasoning template,会得到不同的 embedding / token sequence。因此共享 KV 时必须把这些输入规范纳入 identity。多模态服务更要记录 preprocessor 版本、原始媒体 hash、抽样规则与媒体 token count;只用文本 prompt hash 会造成难以发现的错误复用。

8. 缓存策略应以正确性和 tail cost 一起评估

平均命中率本身说明不了收益。缓存节省的是 prefill 计算、HBM、跨节点传输和 TTFT,比较策略时应报告每租户 hit/miss、公平性、eviction、cold-start p99、内存碎片、迁移失败与重算成本。热点租户若挤掉其他会话,或过期工具结果仍在影响模型,再高的命中率也没有意义。

9. 一手来源

一手来源使用范围
OpenAI prompt cachingprefix cache 与 sticky routing 的公开 API 语义。
xAI prompt caching / compactionxAI cache / conversation 控制面。
Gemini cachingGoogle explicit / implicit cache。
DeepSeek rate limit / user_id逻辑隔离边界。
PagedAttention / Mooncakeruntime block KV 和 P/D/disaggregated KV 的论文基础。