DeepInfer 生产系统的 KV Cache 存储：块缓存、SWA 状态槽与 3FS 命中重算

和 HBM 块池比，3FS 块多付了什么

同样一条 128-token 的块，放在 HBM 里是一个由 block table 指向的物理页；放在 3FS 上，它至少多出四样东西：

这四样开销里，前三样是每次命中都要付的，第四样是后台付的。它们共同决定了 3FS 块不适合被当作「更便宜的 HBM」来用：

• 元数据放大：一条 1M token 的前缀有 8192 个块，每个块都要在 kvcache-store 里有一条记录；如果元数据不能全部驻留内存，CHECK 就会退化成多次小读。
• 小对象问题：111 KiB 的块对 3FS 来说不算大对象，块级读写会放大小文件/小 IO 的开销；这也是为什么落盘要按块批量写、读回要按前缀批量取，而不是一块一块地随机读。
• GC 与 TTL 的耦合：3FS 的 GC 是批量触发的，TTL 决定池子水位；水位越高，GC 尖峰越频繁。块缓存不能像 HBM 那样「引用计数归零立刻回收」，它必须接受「过期后还可能被读到、读到时发现已失效」的语义。

理解了这四样开销，就能理解为什么官方要把「匹配」和「取回」分成两个阶段：匹配只付第一、二样（元数据），取回才付第三样（网络与存储）。如果匹配也要读数据，那么每次未命中都会先付一遍取回成本，缓存的意义就被抵消了。

这也解释了为什么块缓存的字节数不能简单按「主 KV 的 890 B/token」来估。890 B/token 是技术报告给出的全局 KV 口径，索引器 K 的每 token 字节数没有在公开材料里单独给出。按 128 token 一块计算，主 KV 的下限是：

实际落盘的块还要加上索引器 K，所以 111.25 KiB 只能当作下限。这个细节在容量规划时很重要：如果按 890 B/token 乘上下文长度去估算 3FS 占用，会系统性低估；低估的比例取决于索引器维度与共享策略，公开材料不足以给出精确系数。

块缓存按 128 token 分页还有一层工程含义：落盘、命中、换入三件事共享同一套块号。引擎内的 block table 把逻辑位置映射到物理块号；落盘时以块为单位写；命中时以块为单位算长度；换入时以块为单位做 H2D。只要有一处不是 128 对齐，就会出现「半块」——半块无法单独命中，也无法单独换入，最后只能退化成一整块重算。官方在启动阶段要求块数为偶数、落盘位置向下对齐到 128，本质上都是在避免半块进入这条链路。

为什么是前 20 层

V4.1-Flash 的注意力不是一种，而是好几族：一部分层是普通的全注意力/SWA 注意力，一部分是压缩器（compressor），一部分是索引器，还有解码器层的 YoCo 消费层。前文拆过两本账与 YoCo 截断，模型层的装配与超连接主干 拆过解码器里 YoCo 层为什么只读不写。

「只保存前 20 层」对应的正是编码器侧需要被后续请求直接复用的 SWA 窗口。解码器侧的 YoCo 消费层用的是另一套机制：它的 block KV 由最后一层编码器的 hidden state 投影而来，SWA 部分则可以依赖重算恢复。如果把解码器的 SWA 也存下来，每序列字节数会翻倍，而能省下的只是「重算 128 token × 层数」这一点。

ca_state 和 ica_state 放在丢弃段是同一逻辑的延伸。它们是压缩边界的累加器，记录「窗口压到哪、下一个压缩边界从哪开始」。由于压缩窗口边界被设计成 128 token 的整数倍，累加器在请求结束后其实不需要保留：下一次命中时只要重新从边界算起，累加器的值就能被重建。「天然对齐」这四个字换来的是「不必存盘」——这是设计阶段就把存储粒度写进算法的一个典型例子。

每序列到底存多少字节

官方把落盘量算成了一行乘法：

进 store 的只有 state_size_to_disk = 20 层 × 134 token × 528 B = 1,415,040 B/序列。528 B/token 是 MXFP8 的 SWA KV 格式。

逐项解释：

• 20 层：上面说的保存段层数；
• 134 token：窗口长度 128，加上 6 个回退位置。前文已经论证过这个 6 的来历——投机解码回滚最多需要 6 个位置，decode 阶段 store 拷贝最多越界 5 个位置，取两者最大值。存储层要存的是「完整窗口 + 回退历史」，否则命中后无法直接用于变长验证；
• 528 B/token：MXFP8 格式。MX（Microscaling）是块级共享指数的格式，FP8 元素加一个很小的 scale，平均每个元素不到一个字节的额外开销。528 这个数不是元素宽度 1 字节乘某个维度得到的整数，而是层内 K/V 打包后的实际字节数；
• 乘积 1,415,040 B ≈ 1.35 MiB：这是一个可被 400G VLAN 一次低开销回拉的量级。

这条乘法也说明了 SWA 缓存和块缓存的量级差异：一条 128K 序列的块缓存约 111 MiB（下限），而它的 SWA 缓存只有约 1.35 MiB。前者需要存得久、存得全；后者只需要在当前序列的窗口边界上「续上」。这个 80 倍的差距，直接决定了为什么两者的介质、冗余与 TTL 完全不同。

槽的物理形态：环形缓冲与多出的 6 个位置

前文拆过 StateBlock 的三段布局与 ring 长度，这里补存储侧的视角。存进槽的窗口不是一段连续的「0 到 133」，而是一个环形缓冲：窗口右端不断向前推进，左端不断被覆盖。为什么可以覆盖？因为 SWA 注意力只读最近 128 个位置，更早的位置在计算上已经不再被引用。

但存储需要的是「某一种对齐位置上的快照」。环形的优势是增量写入：每生成一个 token，只写一个位置；劣势是「快照」不是现成的，需要知道当前窗口在环上的起点。副本区机制就是为此存在的（后面一节会讲）。那 6 个多余位置的意义也在这里体现：拷贝触发有粒度，可能越过边界最多 5 个 token；多出的 6 个位置让「越过边界的那一段」仍然留在环里，不会被提前覆盖。

用公式描述环形缓冲的索引：

其中 $p$ 是 token 的绝对位置，$p_{\text{start}}$ 是当前窗口的起点，$L_{\text{ring}}$ 是环长度（窗口 + 回退余量）。对 V4.1 的保存段，$L_{\text{ring}} = 134$。这个取模只在 GPU 侧写入与读取时使用；落盘时需要的是逻辑位置，而不是环上的物理位置，所以 copy 到副本区时还要把逻辑起点一起记下来。

128 边界的存储状态机

官方对 SWA 的写入时机给了一段几乎逐状态机式的描述，值得完整拆开：

Prefill 结束后：

存储位置取序列末尾留出一个 token 后向下对齐到 128 所得的位置；若不足一个完整 128 token 单元，则本轮不存储；chunked prefill 中途不存储，只有最后一个 chunk 存储。

三个动作对应三个判断：

1. 位置计算 $p_{\text{store}} = \lfloor (L-1)/128 \rfloor \times 128$。留一个 token 是为了保证锚点处已经产生过该位置的 token；向下对齐保证落在块边界。
2. 长度判断 $L \le 128$ 时 $p_{\text{store}} = 0$，没有完整窗口可存，直接跳过。短 prompt 不占 SWA 存储。
3. 分块判断 chunked prefill 只在最后一个 chunk 写入。一个请求一次写，把 IO 次数与 chunk 数解耦。

Decode 阶段：

另开一块副本区，每跨过一个 128 tokens 边界就把该请求当前的窗口在显存内拷入副本区；请求结束时从副本区中最近一次完成拷贝的位置存储，附着点向下对齐到 128 边界；拷贝位置最多越过边界 5 个 token，由 ring 比窗口多出的 6 个位置吸收。

这段机制前面已经拆过，这里只保留一个存储侧的观察：Decode 的存储时间点是「请求结束」，而不是「每跨一次边界」。跨边界时的动作只是一次显存内的拷贝（copy 到副本区），真正的落盘发生在请求结束、且取的是副本区里最近一次完成的拷贝。这样做的直接收益是写放大可控：一条生成 3000 token 的请求会跨过大约 23 个边界，但在 host memory 里只写一次；如果每次跨边界都直接写主 ring，就会在环被覆盖之前拷出不一致的状态。

slot_mapping_store_swa 这个张量名可以从源码侧印证这条链路：前文引用过 prepare_tensor_input 里的 slot_mapping_store_swa 与 state_block_idx_out，它们正是把「哪些位置需要写入 SWA 存储」和「写到哪个 state slot」编码进前向输入的两个张量。也就是说，SWA 的存储写入本身是由模型前向携带的 kernel 完成的，而不是请求结束后由 host 侧逐层拷出来。这一点在性能上很重要：每层前向本来就要写主 KV，顺手把需要保留的那一段也写到 slot 里，边际成本只是多一个目的地址。

上限为什么是 L − 134

命中意味着「前缀部分不再前向」。但命中之后紧接着要做的是 decode 或继续 prefill 剩余部分，而 decode 的第一步需要 SWA 窗口里的最近 128 个位置，以及投机解码可能回退的 6 个位置。如果命中长度取到 $L$，窗口末端落在输入的最后端，那么 SWA 缓存的锚点是 $L$ 本身——但 Decode 时还需要「从 $L$ 往后生成」的位置，环里必须留出余量。

官方选择让命中长度不越过 $L - 134$，等于强制把最后 134 个 token 留在重算范围内。这 134 个 token 会随剩余的 prefill 一起前向，顺带重建保存段的窗口。134 这个数在前文里被拆成 128 + 6；这里看到的是它在命中口径上的用途：不是 KV 池的物理尺寸，而是「命中最多到哪里」的逻辑上限。

L1 与 L1 − 128 的选择

命中决策分两步：

1. 在 $L - 134$ 上限内查块缓存，得到 $L_1$，它是 128 的整数倍；
2. 查 SWA 缓存是否覆盖 $[L_1 - 128, L_1]$ 这段窗口。

如果覆盖，命中 $L_1$；如果没有，命中长度退回 $L_1 - 128$，并把最后一个块纳入重算。

为什么一块 SWA 缺失要退回整整 128 个 token，而不是只重算「缺的那几个位置」？因为前向的最小执行单位就是块。如果一个块里的 SWA 窗口不完整，那么这一块的前向结果就不能被信任——注意力看到的 K 少了一截。退回一块并重算，让这一块的窗口完整重建，代价是 128 token 的前向；如果只补几个位置，则需要更细粒度的前向，反而会让 kernel 形状变得不规则。

1
prefix (L1) ----------------------------------------------------> 命中长度上限 L-134
2
            block cache 命中 L1        ├────────┤
3
            SWA 窗口覆盖 [L1-128, L1]? 是 -> 命中 L1
4
                                      否 -> 命中 L1-128，重算最后一个块

这个决策树还有一个隐含前提：SWA 缓存的存在与否不改变块缓存的命中长度。也就是说，块缓存被查到了，数据就已经在；SWA 缺失只是让最后一块重新前向一次，并不会让前面已经命中的块作废。这保证了「SWA 缺失」的代价是常数级，而不是随前缀长度线性增长——这是后面「有界重放」这一节的核心结论。

一个 128K 输入的具体账

把公式代进一个真实长度。设 $L = 131072$（128K token）：

块缓存查询只能返回 128 的整数倍，所以

此时未命中的后缀只有 $131072 - 130816 = 256$ 个 token。若 SWA 缓存覆盖 $[130688, 130816]$，命中长度就是 130816，Prefill 只需要算 256 个 token；若 SWA 缺失，命中长度退回 130688，需要算 384 个 token，并且重放 128 个 token 来重建窗口。

把这个例子换算成比例：

• 完全命中：$256 / 131072 \approx 0.20\%$ 的 token 需要前向；
• SWA 缺失：$(384 + 128) / 131072 \approx 0.39\%$ 的 token 需要前向。

两种情况下，prefill 的计算量都比全量重算低两个数量级以上。块缓存按主 KV 下限估算约 $130816 \times 890 \approx 116.4$ MB，按 40 GiB/s 峰值取回约 2.7 ms；而 13 万 token 的全量 prefill 在同样硬件上是百毫秒量级。这个对比说明：命中收益的上限由前缀长度决定，下限由取回带宽决定；在长前缀上，取回几乎总是划算的。

匹配为什么藏不掉，却又必须放在前面

假设把匹配挪到路由之后：请求先按负载被送到某台 Prefill，那台机器再查自己本地能命中多少。这能隐藏匹配延迟，但会失去「任意机器命中任意前缀」的能力——除非所有机器都能访问整个块缓存。而它们确实能访问 3FS 同一份数据，那么「匹配」就变成了「每台机器都对 3FS 查一次元数据」，查询量随机器数放大，且命中长度仍然要在调度器决定「这台机器该做多少 prefill」之前算出来。

换句话说，匹配无法隐藏的根源不是「实现不好」，而是它决定了后续所有资源的分配量：命中长度决定这台 Prefill 要算多少 token，而算多少 token 又决定要选哪台机器、要不要分块、要不要跨实例。官方选择把这次决定性查询集中到 Entrypoint，用一次集中的小查询替代 N 次分散的查询。

fetch 与 swap-in：为什么分两个进程、两种技术

fetch 从 3FS 到 host shm，由独立进程异步完成。独立进程的意义在于隔离 CUDA 上下文与 Python GIL：搬运是纯 IO/SHM 操作，不需要碰 GPU 的代码，放在 engine 进程里会干扰调度线程的实时性。

swap-in 从 shm 到 HBM，在 engine 进程内的线程里做，并且要求「逐层 H2D 与前向重叠」。逐层是这里的核心：不是先把几百 MB KV 全部搬到 HBM 再开始前向，而是每算一层之前把这一层的 KV 搬进来。这样搬运时间被前向计算掩盖，前提是搬运速度快于该层前向的耗时。

官方还专门解释了为什么用 GDR（GPUDirect RDMA） 而不是 CUDA copy engine：

由于 CUDA copy engine 对 KVCache Block 的细粒度拷贝性能不佳，换入使用 GDR 实现，RDMA 网卡就能打满 PCIe 带宽，并且不占 SM。

这里有两层含义。第一层是细粒度：KV 块是 128 token 的小块，逐层换入会产生大量小块拷贝，copy engine 的启动开销与小块带宽利用率都不好。第二层是不占 SM：copy engine 的替代方案（例如 SM 内手写拷贝 kernel）会占用流多处理器，而这正是前向要用的资源。GDR 让网卡直接 DMA 写显存，既绕过 copy engine 的短板，又不抢计算资源。

对于 Decode 侧，官方明确说不做 KV offload：Decode 不受缓存容量约束，所以也不会使用 Hi-Sparse。但 Decode 阶段产生的 KV 仍然会写盘——目的是提高下一次的命中率。这是一个值得注意的取舍：Decode 的 KV 写盘是为了未来的命中，不是为了当前的复用；写盘开销被算进「长尾收益」而不是「当前请求延迟」。

一次命中的成本账

把三段成本写成近似式：

其中 $T_{\text{match}}$ 随前缀长度线性增长但常数很小；$T_{\text{fetch}}$ 与 $T_{\text{swap}}$ 都随字节数增长，二者可部分重叠；$T_{\text{prefix}}$ 是剩余后缀的 prefill，为 0 时表示完全命中。与「不命中」的对照式：

只有当 $T_{\text{prefix}}(L_1) > T_{\text{fetch}}(L_1)$ 时，命中才划算。对 V4.1-Flash 来说，这个条件在长前缀上几乎总是成立：111 MiB 的块缓存取回，按 40 GiB/s 的峰值算约 2.8 ms；而 128K token 的 prefill 在任何可用的 GPU 上都是数百毫秒量级。命中率的价值因此与前缀长度强相关——短前缀命中可能还不如重算，长前缀命中则收益巨大。这也解释了为什么路由要先按缓存长度分层（下一节）。

重放段为什么不写块缓存

前文有一个很重要的结论：重放段只重建 SWA 缓存，块缓存原样复用、不重算、不覆写。从存储角度看，这条约束是必须的：

• 块缓存是持久化、跨机、可能被其他请求命中的共享数据。一次局部重放如果顺手覆写它，就会污染其他请求的命中结果。
• 重放段只有 128 个 token，凑不出一个完整的压缩窗口（压缩需要 $m$ 个 token 的窗口累加），所以它根本没有能力重建块缓存。
• 块缓存本来就在缓存里，重算纯属浪费。

这条约束把两本账的「写入权限」分得很清楚：重放是状态账的修复操作，不是块账的修复操作。

两处重放的存储差异

KV 内存与 SWA 有界重放 拆过 Encoder 侧与 Decoder 侧两种重放，它们在存储策略上的差别值得单独强调：

Decoder 侧重放的产物不进缓存，是一个典型的「存储成本 > 复用收益」判断。它的覆盖范围只有 prompt 末尾 128 token，而且是「跨层投影之后的消费层状态」，这种状态与具体的层、具体的窗口强绑定，下一次请求能复用的概率极低。如果为了它设计一套跨机存储与 TTL，就会得到一张占用很大、命中极小的缓存。

扩缩容时的长尾请求迁移

Decode 侧的弹性扩缩容有一个不常见的机制：Decode 引擎（CE）收到关闭通知后进入 1 分钟宽限期；仍在处理的请求连同它们的 KV 缓存会被一次性转发到其他 CE 继续解码。

这个机制的直接目的，是解决「大规模 EP 部署下长尾请求造成的资源浪费」：一个 CE 上可能只剩下几条很慢的请求，如果让整个 CE 等它们跑完，整组 GPU 都被低利用率地占用。官方没有给出迁移的协议细节，但从存储层看，迁移至少要带走三样东西：

• 该请求的分页块表与块缓存（可以从 3FS 命中，不必点对点搬）；
• SWA 状态槽（必须点对点搬，因为不在 3FS）；
• 调度侧的请求元数据与采样状态（在确定性采样模式下必须保持一致）。

三样东西里，只有 SWA 状态槽是「搬不动就得重算」的。这也解释了为什么宽限期是分钟级而不是秒级：迁移要经过调度、网络、目标引擎的准入，中间还可能有排队。

另外，官方披露部署会保留冗余配额：一部分机器留在池中不占负载作为扩容库存；并且在配额利用率高于 0.8 时禁止缩容。这两条与 KV 存储的容量规划直接相关——缩容意味着 CE 数量的下降，也就意味着能被命中的「本机 SWA 缓存」分布发生变化；保留一定冗余，是为了让宽限期迁移不至于触发连锁迁移。

和 vLLM：本地优先 vs 远端优先

vLLM 的前缀缓存是本地优先的典型：块哈希表在引擎进程内，命中在本机 HBM 完成，未命中就重新算。它的扩展方式是通过 KV connector 把 KV 搬到其他介质或其他实例，但「是否命中」仍然由引擎自己判断。这种设计的优点是命中延迟极低、实现简单；缺点是跨节点命中需要额外的连接器与路由策略，默认不保证任意前缀可命中。

DeepInfer 反过来，把块 KV 的主位置放在远端 3FS，HBM 只保留 in-flight 部分。代价是每次命中都要取回；收益是命中不依赖请求落在哪台机器。两者不是「谁更先进」的关系，而是对「缓存容量 vs 命中延迟」的不同取舍。vLLM 适合单机/小集群、命中以本地热前缀为主的场景；DeepInfer 适合大规模、跨机前缀复用价值高的场景。

和 SGLang HiCache：分层缓存的两种形态

SGLang HiCache 是最接近 DeepInfer 的对标物：它把 KV 缓存分成 HBM、host memory、L3 三层，用分层 radix tree 维护命中，并做异步预取与写回。站内 SGLang HiCache 拆解 已经拆过它的分层前缀树与搬运流水线。

两者的关键差异有三点：

1. DeepInfer 的块缓存没有「本地 HBM 层」作为持久缓存。 HBM 只放 in-flight KV；跨请求复用的块缓存从 3FS 直接取。HiCache 则优先在 HBM/host 命中，L3 是兜底。前者把网络放在更前面，后者把本地层级放在更前面。
2. DeepInfer 把 SWA 缓存从块缓存里拆出来，单独放 host memory。 HiCache 的层级是「同一份 KV 的不同介质」，DeepInfer 的层级是「不同性质的状态用不同介质」。这是模型结构（SWA/YoCo/CED）带来的特化，不是通用缓存设计。
3. DeepInfer 的命中判定在 Entrypoint，HiCache 的命中判定在引擎侧。 前者让路由知道命中长度，后者让缓存感知调度在引擎/路由器之间协调。两者都在解决「前缀亲和 vs 负载均衡」，只是把决策点放在了不同位置。

和 TensorRT-LLM、llama.cpp：块管理相似，系统边界不同

TensorRT-LLM 的 KV 池、分页块、KV offload 与 DeepInfer 的块管理在单机层面很像：都是分页块表、块粒度写入、按层换入。区别在系统边界：TensorRT-LLM 的 KV 复用主要在实例内，跨实例要靠 disaggregated serving 的 KV 传输；DeepInfer 则把「跨实例复用」做成了默认能力，块缓存从一开始就放在共享存储里。

llama.cpp 的 prompt cache 更简单：把一段会话的 KV 状态存到文件，下次相同前缀时读回。它是单机、单进程的缓存，没有全局目录，也没有跨机命中。把它放进这张表，是为了说明「KV 落盘」本身不新鲜；新鲜的是落盘之后如何被全局匹配、如何在路由前算出命中长度、如何在多租户集群里淘汰。

未公开的实现细节

kvcache-store 的文件布局、块键的编码、元数据的索引结构、并发写入的一致性协议，都没有公开。官方只说了「hash-chain 前缀匹配」「CHECK 角色」「无过期逻辑」。这意味着：

• 不能从公开材料推断它是「每个前缀一个文件」还是「所有块写进一个大文件」；
• 不能推断多台 Prefill 同时写同一前缀时的去重/覆盖策略；
• 不能推断 CHECK 的元数据是全部驻留内存，还是按需读 3FS。

这些细节会显著影响尾延迟与扩展性，但在没有源码的情况下，只能把它们当作「待验证的实现问题」，而不是设计结论。

匹配在关键路径上的成本

hash-chain 匹配的复杂度与前缀块数成正比。一条 1M token 的输入有 8192 个 128-token 块；即使只读元数据，一次匹配也要处理八千多条记录。Entrypoint 要为每个请求做这件事，并且要在路由前完成。官方没有披露元数据缓存策略与批量查询优化，因此「匹配会不会成为 Entrypoint 的瓶颈」是一个合理的工程疑问，而不是可以忽略的细节。

从系统设计上看，这条路径有几个可能的缓解手段：按块批量读元数据、在 Entrypoint 本地缓存热前缀的匹配结果、把匹配拆成「粗粒度段匹配 + 细粒度块匹配」。但官方材料没有确认任何一种，所以这里只能把它们列为「可预期的优化方向」。

存储集群的依赖与故障域

块缓存依赖 3FS 的可用性。3FS 用 10+2 纠删码，每个 EC 组容忍两个节点同时故障；读请求向 11 个节点并发发出，任意 10 个返回即可解码。这套冗余让「存储节点故障」不至于直接丢缓存，但它不能消除网络分区、元数据服务故障、GC 尖峰带来的尾延迟。

官方说计算节点故障率比存储节点高一个数量级以上，这是把缓存放到存储集群的理由之一；但反过来说，存储集群一旦抖动，影响的是所有 Prefill 的命中率与取回延迟，而不是一台机器。这是集中式缓存的固有风险，需要用存储侧的冗余与限流来吸收。

SWA 缓存的单副本风险

SWA 缓存只存在产生它的那台机器的 host memory，单副本、不落 3FS。机器重启或故障，这部分缓存就丢了。丢失的后果是有界重放：重算最后 128 token，代价近似常数。这个设计之所以成立，是因为「重算便宜」；如果 SWA 窗口更长、层数更多，单副本策略就会变得不可接受。

跨机命中时，SWA 缓存走 400G VLAN 回拉。这里有一个隐含的容量问题：SWA 缓存是按「每序列 1.35 MiB」算的，如果一台机器上同时驻留几千条序列的 SWA 缓存，host memory 的占用会达到几 GiB；官方没有给出 host memory 的容量上限与淘汰策略，只说了「单副本、留在产生它的机器」。这意味着 SWA 缓存的容量规划需要按「并发序列数 × 1.35 MiB」单独算，不能混进 HBM 的 KV 账。

没有 Decode offload，也不代表 HBM 不紧张

官方明确说 Decode 不做 KV offload，也不使用 Hi-Sparse，因为 Decode 不受缓存容量约束。这句话容易被误读成「Decode 的 KV 不占显存」。实际上 in-flight block KV 与 state KV 仍然在 HBM 里，只是不需要把「历史的、非当前的」KV 搬到远端。890 B/token 让单条序列的 KV 变小，但 Decode 的并发序列数、MoE 的专家权重、CUDA Graph 的私有池仍然在争同一块 HBM。启动时的显存 profiling 的启动账本已经说明：在 V4.1-Flash 上，KV 池通常不是最先见底的那一项。

多租户与安全边界

公开材料没有描述 KV 缓存的租户隔离、访问控制与加密。共享存储意味着不同请求的 KV 可能落在同一套 3FS 集群上；如果业务是多租户的，键空间隔离、元数据访问控制、缓存命中是否可能跨租户，都是需要额外确认的问题。本文不假设官方实现了某种隔离机制，只把它标为「公开材料未覆盖」。