你去档案室查一份旧材料，按理说应当比重新整理一遍更快。但如果档案放在远处，取件窗口又只有一个，结果可能恰好相反：人排起长队，办公室里的电脑却闲着。
这正是 Muhammad Ibrahim 在论文《When the KV Cache Is Slower Than the GPU》中观察到的问题。KV Cache——模型读过文字后留下的中间计算结果——通常被视为一种捷径。新请求如果与旧请求共享开头，系统可以直接复用缓存，不必让 GPU 再读一遍。但这篇工作提醒我们：缓存不是免费答案。把它搬到远端之后，网络传输、存储读取和引擎内部操作，都可能比 GPU 重算更慢。
论文的实验、模型和性能数字均来自作者团队单一信源，尚无独立复现。它的价值不在于证明“远端缓存都很慢”，而在于给出了一套判断何时值得读取、何时应该重算的账本。
缓存命中了，为什么反而更慢？
长提示送进模型后，系统要先完成 Prefill（预填充）——把全部输入读一遍，建立内部记录，然后才能生成第一个词。远端 KV 缓存层会把这些记录放进多台推理服务器都能访问的存储。这样，一台机器算过的内容，另一台机器也能复用。
这套部署使用 GLM-5.3，运行在配有八张 NVIDIA B300 GPU 的节点上。系统采用 PCP8，也就是把提示沿文本长度分给八个并行单元处理。八个单元必须步调一致：任何一个被缓存读取卡住，其余七个也得等。
作者报告，在一组 9k—200k token 的企业负载中，启用 LMCache 与 Valkey 组成的远端缓存层后，中位首词等待时间没有变化，但尾部体验明显恶化。对于 16k-token 请求，p99 从 3.96 秒升至 17.3 秒。p99 是第 99 百分位延迟，可以近似理解为：约 99% 的请求不会比它更慢。它比平均值更容易暴露少数请求的严重排队。
团队随后在隔离引擎上回放生产请求流。一个 16k-token 提示从远端命中缓存，耗时 0.88 秒；直接让 GPU 重算，只需 0.31 秒。捷径本身已经比原路更慢。
问题还会被同步加载放大。所谓同步加载，就是引擎停下来等缓存到齐，再继续处理。在缓存命中率很高的请求流中，上一项读取尚未完成，后续请求便不断排队。作者观察到 p99 达到 83.32 秒，而 GPU 忙碌率只有 7%。这不是 GPU 算不过来，而是 GPU 在等远端存储。
先算清楚，读取到底值不值
论文把选择压缩成两笔成本。设每个 token 的 KV 数据量为 ，GPU 每秒可预填充的 token 数为 ，那么远端缓存至少要达到下面的带宽，才有机会胜过重算：
对于论文使用的模型和 B300 节点，这条盈亏线是 2.53 GB/s。原来的单个 Valkey 实例达不到它。换句话说，GPU 已经快到一种程度：远端存储即使成功找到缓存，也未必来得及把数据送回来。
带宽之外，还有一笔躲不掉的固定费用。每次命中都要经过调度、查询、少量未缓存内容的计算，以及分块信息交换和广播。作者拟合出的固定引擎开销约为 秒。据其模型推算，在这套特定模型、GPU、PCP8 配置和实现下，短于约 17k tokens 的提示，无论远端带宽多高，都不能在中位延迟上胜过重算。
这不等于短提示的缓存毫无价值。命中缓存不占用 GPU 计算，在 GPU 已经饱和时仍可能腾出算力。它只是说明，“省算力”和“更快返回”并不是一回事。
把一个窗口拆成八个
作者的关键改动，是顺着 PCP8 原有的并行方式重新摆放缓存。原系统主要由 rank 0——八个并行单元中的第一个——负责存取 MLA KV。MLA 是一种把注意力所需信息压进共享低秩表示的方法。虽然八个单元都拥有相关 KV，缓存工作却集中在一个单元上，形成瓶颈。
新方案按 rank 分片：缓存块依据固定规则分给八个单元，各自只负责自己的部分。远端层也随之拆成八个彼此无须协调的 Valkey 实例。它像把一个取件窗口扩成八个，并让每位工作人员提前知道自己负责哪些箱子。
作者还证明，调度器原有的“取各 rank 查询结果中的最小值”规则，仍能找到最长的连续缓存前缀，不必增加新的查询消息。加载时，各 rank 先取回自己的块，再共同确认可用前缀，避免有人进入集体通信、有人跳过而造成死锁。
按论文报告，这种划分把 GET 带宽提高了 6.3 倍，达到 10.76 GB/s，越过了 2.53 GB/s 的盈亏线。团队又加入异步加载，让某个请求等待缓存时，引擎还能处理其他请求；同时修复三个可能造成无界停顿的客户端缺陷，包括完成信号丢失、缺失键读取不返回，以及异步 GET 使用错误键名。
尾延迟被救回来，但别混淆两组实验
在隔离引擎的高命中率回放中，98.5% 的 prompt tokens 来自远端层。采用分片、异步加载和全部客户端修复后，p99 从 83.32 秒降到 0.67 秒。这个前后对比属于同一套 450 请求回放，不能与生产部署里 16k-token 请求的 3.96 秒到 17.3 秒直接拼成一次“修复前后”实验。
中位数也揭示了另一层现实：完整优化后的远端命中为 0.40 秒，同批请求重算为 0.31 秒。缓存仍没有赢下中位延迟；但它把 p99 做到 0.67 秒，低于重算的 1.28秒，并且避免占用 GPU 计算。
分片还改善了写入侧。作者报告，只采用分片存储时，Prefill 吞吐量提高 14%。叠加一个与缓存优化不同的上游 kernel 修复后，总提升达到 34%。因此，34% 不能全部归功于远端 KV 方案。论文称相关改动均已提交至 LMCache 上游，但材料没有提供 PR、代码仓库或实验日志，暂时无法独立核验。
为什么值得现在看
这项工作的真正提醒，是硬件之间的相对速度正在改变。判断缓存是否划算，不能只问网络快不快，而要问：它能否比眼前这块 GPU 重算得更快。GPU 越快，远端缓存需要跨越的带宽门槛就越高。
分离式部署——把输入处理、生成和缓存交给不同资源池——便于各自扩容，却也把跨机器搬运变成关键路径。论文展示了一个很典型的失衡：存储层跟不上时，命中率越高，排队反而可能越严重。系统看起来拥有大量可复用数据，昂贵的 GPU 却在同步等待中闲置。
所以，缓存命中率不能单独代表成功。工程团队还需要同时观察实际读取带宽、固定命中开销、队列是否稳定，以及 p99 这样的尾延迟。远端 KV 缓存不是天然的加速器。它更像一笔交易：省下多少计算，必须与搬运和等待逐项结算。
局限与未知
- 各实验条件只运行一次。作者认为大幅变化明显超出运行波动，但约 10% 以内的差异尚不能坐实。
- 回放主要覆盖单个 Prefill 引擎和 14.7k—17.9k-token 提示，省略了向生成节点交接 KV 的过程；约 17k tokens 的门槛也是由单点拟合推得，尚未直接测量。
- 多客户端共享远端实例时的争用没有实测；五节点端到端部署与早期基线还同时改变了并行方式和节点安排，不能视为单纯的缓存消融实验。