真正难的不是“把 KV 存下来”，而是让 prefix 复用、块化分配、调度器、跨 GPU 传输、分层存储 和 回收策略 在高并发下仍然像一个系统，而不是一堆优化补丁。
如果把高速推理系统拆开看，KV cache 不是附属功能，它本身就是 serving runtime 的内存主轴。
普通缓存命中后直接返回值；KV cache 命中后返回的是“可继续计算的中间状态”。所以它必须和 attention 布局、batch 形状、调度策略一起设计。
命中率高但搬运贵、碎片重、回收慢，整体吞吐照样差。真正看的指标是：命中带来的 prefill 减少，是否大于缓存系统自身的管理成本。
如果按连续大段分配 KV，显存碎片和迁移成本都会爆。高速系统几乎都会走 block / page / chunk 化，拿可组合性换高利用率。
HBM 最快但最贵；CPU DRAM 容量大但慢；NVMe 更大但更慢。真正能扛生产流量的系统，最终都会落到 hot / warm / cold 的分层设计。
要建立高速 KV 缓存基础设施，至少要有下面这些部件。少任何一个，系统都只能算“有缓存”，不算“有缓存基础设施”。
负责把 token 前缀映射到已有 KV 块，常见实现是 trie / radix tree / hash+block 索引。它解决的是“哪里可以复用”。
负责显存块分配、拼接、回收、引用计数和空闲链表管理。它解决的是“怎么存才不碎”。
把每个请求当前用到哪些 KV block 显式记录下来，供 decode、续写、迁移、回收时快速定位。
负责把请求 admission、prefill、decode、cache 命中、cache 失效、优先级和延迟目标统一起来。没有它，缓存命中只是偶然。
最终 kernel 需要能吃这种分块布局，比如 paged attention、paged KV、ragged / packed prefill。缓存设计如果 kernel 不支持，等于白做。
热数据留 HBM，次热数据下沉到 DRAM，冷数据清理或落盘。这里会牵扯 TTL、引用计数、访问频率、复制成本和重算成本。
包括 GPU↔GPU、GPU↔CPU、节点↔节点 的搬运通路，以及配套的压缩、DMA、零拷贝、RDMA / NVLink / PCIe 策略。
至少要能看到 hit rate、reused tokens、eviction、fragmentation、copy bytes、HBM pressure、TTFT / TPOT 的变化，否则你根本不知道缓存到底赚没赚。
拓扑不是画图好看，而是决定你把缓存放在哪里、谁来管理、请求如何路由，以及跨设备复制到底贵不贵。
单机单卡 / 单机多卡最小闭环 Client | Router / API | Scheduler | +-------------------------------+ | Req Table + Prefix Index | | Block Allocator + Eviction | | KV Blocks in GPU HBM | | Attention Kernels | +-------------------------------+
分层缓存拓扑
+---------------------+
| Prefix Index |
| Global Metadata |
+----------+----------+
|
+----------------+----------------+
| |
+------+-------+ +-------+------+
| GPU HBM hot | <----------> | CPU DRAM warm|
| low latency | | bigger pool |
+------+-------+ +-------+------+
| |
+----------------+----------------+
|
+------+------+
| NVMe / cold |
| spill tier |
+-------------+
分离式 serving 拓扑（Prefill / Decode / KV 服务拆开）
Client -> Router
|
+--> Prefill Cluster ----+
| |
+--> Decode Cluster <----+---- KV Transfer / Metadata Service
关键点：
- Prefill 负责高算力吞吐
- Decode 负责低延迟续写
- KV 必须可迁移、可定位、可校验
| 拓扑 | 优点 | 代价 | 适用场景 |
|---|---|---|---|
| 单机本地 KV | 最简单、最稳、延迟低 | 容量和弹性受限 | 中小流量、单模型服务 |
| 多卡共享元数据 + 本地 HBM | 吞吐高、可扩展 | 跨卡同步和调度更复杂 | 高吞吐单节点 |
| GPU + CPU 分层 | 容量更大、热冷分离 | promotion / demotion 策略难 | 长上下文、冷热差异明显 |
| PD 分离 / 跨机 KV | 资源利用率高、弹性强 | 网络和一致性成本高 | 大规模生产集群 |
高速 KV cache 不是单一算法，而是几条原理叠加后的工程结果。
多个请求共享前缀时，直接复用已有 K/V，跳过重复 prefill。上下文越长、共享比例越高，这件事越值钱。
把序列切成固定或半固定大小的块，降低大段连续内存依赖，改善分配和回收效率，同时让 kernel 更容易做 gather。
缓存命中不是离线事件，而是 scheduler 在 admission、merge、batch 构造时顺手制造出来的结果。调度错了，缓存也会失效。
热块放 HBM，次热块放 DRAM，冷块清理或下沉；关键不只是“放哪里”，而是 promotion 的触发阈值和异步搬运能否藏到计算后面。
NVLink、PCIe、RDMA 的成本差异极大。你能不能把请求路由到“缓存所在的地方”，通常比“把缓存搬过去”更划算。
淘汰策略不该只看最近访问时间，还要看重算这个前缀有多贵、恢复这个 block 有多慢、它是否正在被多个请求共享。
最容易被低估的一点：KV cache 的收益常常不是“减少一点延迟”，而是把 GPU 从重复 prefill 里解放出来，让更多算力流向新的真实工作负载。
真要从零搭，别一上来就做跨机缓存。先做出闭环，再把复杂性一层层加回去。
| 团队画像 | 适不适合 | 原因 |
|---|---|---|
| 有稳定高并发、重复前缀明显的推理团队 | 适合 | 缓存命中能直接换掉昂贵 prefill |
| 做长上下文、多轮对话、模板化 agent 的团队 | 适合 | 共享前缀和热会话很多，收益通常明显 |
| 请求分布极随机、上下文短、流量小的团队 | 未必适合 | 缓存系统的维护成本可能高于收益 |
| 基础设施能力弱但想直接做跨机 KV 服务的团队 | 不适合 | 会先被一致性、传输和观测性拖死 |