Prefix caching：相同的开头，只算一次

复用成立的条件，是同一个计算状态

相同文本只是起点。缓存池必须绑定模型版本、数值格式和位置/attention 配置；请求身份还可能包括 LoRA、图像内容与隔离域。

字段可以由池边界固定，也可以进入 key；关键是不同计算状态不能落到同一可复用身份。

命中 H 个 token，省掉的是哪些张量？

普通 GQA：每层前缀 K、V 各为 [H, Hkv, d]。对于后缀 query，仍需把命中前缀与新后缀的 K、V 一起读取。

对前缀的投影、attention、MLP 不再重算；后缀仍经过全部层。因果掩码必须保留原来的绝对位置，不能把后缀重新编号为从 0 开始。

共享前缀也共享物理 KV 块，活跃请求持有引用；执行 attention 时按各自的 block table 访问。

用规范序列化，把“前面是谁”写进 key

parent = sha256(serialize(namespace, salt))
for block in complete_token_blocks:
    payload = serialize(parent, block.token_ids, extras)
    key = sha256(payload)
    parent = key
    yield key

不要直接拼接字符串：("ab", "c") 与 ("a", "bc") 会变成相同字节串。带类型和长度的稳定序列化能避免这种歧义。

SHA-256 降低碰撞风险，但字段遗漏、错版本、缓存越权都不是换 hash 算法能修复的。

共同开头长 5，块大小 4，为什么只省 4？

按从 0 开始的位置编号，两条 13-token prompt 在位置 5 首次不同。共有位置 0–4，但完整相同块只有 [0,1,2,3]。

第二块即使前三个 token 相同，块身份仍不同。后面 token 值即使完全一样，parent hash 已改变，也不能直接复用后续块。

一个 token 改动，沿哈希链把后面一起改掉

继续向后找“局部相同块”会破坏因果语义。查找的是从起点连续命中的前缀，遇到第一个 miss 就停止。

整段 prompt 都在缓存里，首字 logits 在哪？

KV 保存了注意力需要的历史，并不自动保存最后一层 hidden state 或下一 token 的 logits。

若接口只按完整块复用，N=12、B=4 时，可把前 8 个 token 直接接上，再处理最后 4 个。N=13 时可复用 12 个，再处理最后 1 个。

支持更细粒度边界，或另外缓存最终状态的实现，可以有不同处理方式。评估“100% 命中”时先看它统计的是已有块还是实际跳过的计算位置。

命中以后，先保护块，再把地址交给请求

hits = longest_contiguous_cached_prefix(keys)
needed = blocks_for_new_suffix(request, hits)
if not enough_reclaimable_blocks(needed):
    wait_or_preempt()
else:
    pin(hits)                  # 引用 +1，从空闲队列取走
    tail = allocate(needed)
    request.block_table = hits + tail
    schedule_uncached_suffix(request)

生产实现需要把“检查、pin、分配”协调起来，防止刚命中的块被另一条请求驱逐。CPU 返回一个 hash 命中还不等于 GPU 上的 KV 已可用。

三条相同长前缀请求，真正省了多少显存？

每 token KV=128 KiB，块大小 16。三条请求各有 1,024-token 公共前缀与 128-token 私有后缀；所有长度都恰好对齐块。

省 2,048 × 128 KiB = 256 MiB。物理 KV 从 432 MiB 降至 176 MiB；每个请求自己的逻辑长度仍是 1,152。

共享比例算的是物理块，不能只把各请求 block table 的长度加起来。表中多个条目可能指向同一物理块。

缓存隔离的边界，要和服务的信任边界一致

同一公共文档可在授权用户组内共享；不同私有租户使用不同 namespace 或由服务端管理的 salt。

图像占位 token 相同，不代表图像相同；多模态缓存必须包含真实输入内容或其稳定摘要。LoRA 变化也必须失效。

refcount 为 0，说明可驱逐，不说明必须立刻擦掉

若需要两块，先使用 P3，再驱逐 P2。用 P2 写新数据前，必须从旧 hash→块映射中移除它，否则下一次“命中”会读到别人的内容。

LRU 一类策略只在可回收块集合上选择。活跃请求正在读的块，哪怕很久没被新请求命中，也不能直接覆盖。

后面的块还在，为什么也可能省不了计算？

请求有块链 A→B→C。A 被驱逐了，B 与 C 还在池中。新请求不能从 B 开始跳过前缀：计算前面的 query 时，缺少所需的前序 KV。

重算 A 以后，系统可以重新评估后续复用；简单的入场查找通常在第一个 miss 就停止。本实验采用这个明确的规则。

驱逐策略可考虑共同前缀的覆盖价值。大量只命中冷门长后缀的块，可能不如一个大家都使用的短公共前缀有用。

省 76.8% 输入 token，TTFT 不会自动快 4.3 倍

教学模型：N=4,000，命中 H=3,072；prefill 每 token 成本 0.05 ms，排队、tokenization、网络等合计固定 55 ms。

prefill token 减少 76.8%，TTFT 只缩短 60.24%，加速比约 2.515×。固定开销越大，省掉计算对首字延迟的影响越小。

这是线性近似；真实 prefill 成本与长度、batch、attention 类型、硬件有关。用模型解释趋势，再用实测替换系数。

把固定开销和可省的计算分开看

如果队列已经堆积，缓存还可能通过减少总工作量降低其他请求的排队；这个系统效应要在同样到达率下测。

后缀仍要读前缀：attention 工作量这样数

N=4,096，H=3,072：完整 8,390,656 对；剩余 3,670,528 对。跳过 75% 的 query token，只省约 56.25% 的 query-key 对。

后面的 query 更长，每一个都要看之前的前缀。投影/MLP 的成本更接近按跳过的 token 数下降，整体收益要按各算子占比加权。

命中率高，可能只是命中了很多很短的请求

100 条 10-token 请求全命中，加上一条 10,000-token 请求全 miss：请求命中率约 99%，token 命中率仅约 9.1%。

看起来相同的 prompt，为什么一次也没命中？

打印首个不同 token 的位置与块边界，核对 namespace，再看驱逐日志。不要先把 key 里的字段删掉来追求命中率。

完整前缀长 35，块大小 16，能省多少？

缓存值得多占 100 MiB 吗？

同样的图像占位 token，能不能共用 KV？

改变一个位置，观察整条 hash 链

下载代码后，在保存代码的目录运行：

python3 lab.py
python3 lab.py --change-position 9
python3 lab.py --block-size 8

默认改位置 5：reused=4，recompute=9。改位置 9：reused=8，recompute=5。B=8、改位置5：reused=0。

先预测每种情况的命中边界。代码测试跨租户和跨模型失效、前缀缺块停止、整段命中时的末位置处理。再实现有限容量 LRU，重放重复与独有文档混合的轨迹，比较请求命中率和 token 命中率。