基于KVCache的层次化存储方案还有未来吗？

Created on March 13, 2026

2026   ·   kvcache   llm   systems   storage   ·   research-notes

以Qwen3/Qwen3.5与A100/H100/H200/B100/B200为例的Analytical+Measured证据分析 日期：2026-03-12

证据分层：Analytical + Measured

范围：基于 notes/kvcacheProfit.md 的 Roofline / break-even 推导，以及本仓库对 Qwen3-14B 与 Qwen3.5-27B 的本地 Analytical 仿真、baseline 数据、以及单 GPU A100/H100/H200/B100/B200 官方 peak-spec sensitivity，回答四个问题：

  • KVCache 现在是否仍然值得做
  • Qwen3 与 Qwen3.5 这种 dense / hybrid 架构差异如何改变收益点
  • 最新 GPU 硬件世代会把 break-even 推到哪里
  • 对 HBFCache 这类分层存储系统，下一步最有价值的研究问题是什么

1. 一页结论

  • 重算不如取回。即便是考虑极慢的跨网络端场景。kvcache 卸载收益上限受限于互联带宽，具体收益下限取决于系统栈优化水平\存储介质延迟。
  • GPU 算力在不断进步，HBM 容量提升较慢。长上下文、agent、多轮对话、编程场景的token需求在不断增加,可能会长时间存在需求/系统之间的gap。 模型架构算法能够有效节省空间和算力，也能减少 kvcache 卸载/加载时的传输量。从仿真建模来看，moe/DSA/CLA 使得 kvcache 传输量减少，反而对于带宽的需求降低。
  • 层次化KVCache卸载能够减少Prefill的计算开销，但“大容量”不再是kvcache层次化存储系统的第一追求，“超高并发与极低延迟”才是。
  • 参数设置、模型假设均与 Gemini 讨论得到，个人暂时无法验证。关于卸载到闪存/RemoteBlock 层次的必要性，可能需要更准确实际的参数设置。以上均针对 prefill 阶段，decode 暂未考虑。

2. 我们到底在比较什么

我们关心的不是“KVCache 永远快”，而是一个更具体的问题：在给定上下文长度 $s$ 下，重新 prefill 一段历史上下文更快，还是从外部 tier 取回已经算好的 KV 状态更快。

最核心的判据只有一个：

\[t_{\mathrm{fetch}}(s) < t_{\mathrm{prefill}}(s)\]

如果这个不等式成立，说明当前 storage tier 的取回速度足以打赢重算，fetch cached KV 值得做；反之则说明当前介质太慢，还不如直接让 GPU 重算。

为了把这个问题落到系统参数上，我们把它拆成两个时间项：

\[t_{\mathrm{prefill}}(s)=\frac{P_{\mathrm{FLOPs}}(s)}{\mathrm{MFU}_{\mathrm{prefill}}\cdot \mathrm{FLOPS}_{\mathrm{peak}}}\] \[t_{\mathrm{fetch}}(s)=\frac{P_{\mathrm{KV}}(s)}{\mathrm{BW}_{\mathrm{util}}\cdot \mathrm{Bandwidth}_{\mathrm{peak}}}\]

这里最重要的直觉是：prefill 的主导项包含 attention 带来的二次项，而 fetch KV 的主导项是线性增长。因此上下文越长，fetch 相对重算越有希望；但 GPU 越强、MFU 越高，重算也会越便宜。

3. 公式推导：从模型结构到 dense 口径 break-even

参考 notes/kvcacheProfit.md 的口径，这里把推导直接对齐到脚本里的 ModelSpec.flops_prefill 与 kv_bytes_per_token 定义。关键是先从“每层、每 token”写出算力与状态，再汇总到序列长度 $s$。

3.1 Prefill FLOPs：为什么是 $2sN + 4s^2 n_q d L$

对长度为 $s$ 的 prefill，一阶主项分两块：

  1. 线性层/投影主项（$\mathcal{O}(s)$）

按 FMA 口径（乘+加记作 2 FLOPs），每个 token 经过一遍参数参与的 GEMM 近似为 $2N$ FLOPs，因此：

\[P_{\mathrm{linear}}(s)\approx 2sN\]
  1. Full-attention 主项（$\mathcal{O}(s^2)$）

每层 attention 的二次项来自两次核心矩阵乘：

  • $QK^T$：每个 head 约 $2s^2d$
  • $\mathrm{softmax}(QK^T)V$：每个 head 约 $2s^2d$

所以每层每个 head 合计约 $4s^2d$，再乘 query heads 数 $n_q$ 和 full-attention 层数 $L$：

\[P_{\mathrm{attn}}(s)\approx 4s^2 n_q d L\]

汇总得到 dense 口径 prefill FLOPs：

\[P_{\mathrm{FLOPs,dense}}(s)=P_{\mathrm{linear}}(s)+P_{\mathrm{attn}}(s)\approx 2sN+4s^2 n_q d L\]

3.2 KV 取回量：为什么是 token-linear

每个 token、每层都要保存 $K$ 和 $V$ 两个张量；每个张量大小是 $n_{kv}d\cdot \mathrm{bytes}_{\mathrm{elem}}$。因此：

\[\mathrm{KV\_bytes\_per\_token}=2\cdot n_{kv}\cdot d\cdot L\cdot \mathrm{bytes}_{\mathrm{elem}}\]

长度为 $s$ 的总取回量为：

\[P_{\mathrm{KV,dense}}(s)=2s n_{kv} d L\cdot \mathrm{bytes}_{\mathrm{elem}}\]

在 BF16/FP16（$\mathrm{bytes}_{\mathrm{elem}}=2$）下，可化成：

\[P_{\mathrm{KV,dense}}(s)=4s n_{kv} d L\]

3.3 代入时间表达式得到 break-even

\[t_{\mathrm{prefill}}(s)=\frac{P_{\mathrm{FLOPs,dense}}(s)}{\mathrm{MFU}_{\mathrm{prefill}}\cdot \mathrm{FLOPS}_{\mathrm{peak}}}\] \[t_{\mathrm{fetch}}(s)=\frac{P_{\mathrm{KV,dense}}(s)}{\mathrm{BW}_{\mathrm{util}}\cdot \mathrm{Bandwidth}_{\mathrm{peak}}}\]

令 $t_{\mathrm{fetch}}(s)<t_{\mathrm{prefill}}(s)$，可得到两种等价视角。

第一种视角是“给定上下文长度，storage 至少要多快才值得 fetch”：

\[\mathrm{Bandwidth}^{\star}(s)=\frac{P_{\mathrm{KV,dense}}(s)}{\mathrm{BW}_{\mathrm{util}}\cdot t_{\mathrm{prefill}}(s)}\]

第二种视角是“给定某个 storage tier，它从多长上下文开始值得 fetch”：

\[s^{\star}_{\mathrm{dense}}\approx \frac{\mathrm{MFU}_{\mathrm{prefill}}\cdot \mathrm{FLOPS}_{\mathrm{peak}}}{\mathrm{BW}_{\mathrm{util}}\cdot \mathrm{Bandwidth}_{\mathrm{peak}}} \cdot \frac{n_{kv}}{n_q} -\frac{N}{2 n_q d L}\]

这个式子对应了三个最关键的系统杠杆：

  • GPU 越强或 MFU 越高，$s^{\star}$ 越右移，意味着要更长上下文才值得 fetch。
  • storage 带宽越高，$s^{\star}$ 越左移，意味着更短上下文就可进入 fetch-wins 区域。
  • GQA 越激进（$n_{kv}/n_q$ 越小），KV 取回量越低，fetch 越容易占优。

4. 公式推导：Qwen3.5 这类 hybrid 架构为什么会改写边界

Qwen3.5-27B 的关键变化不是“没有状态”，而是 token-linear 状态显著变小。对 hybrid 模型，我们把 full-attention 层与 linear-attention 层分开写：

\[P_{\mathrm{FLOPs,hybrid}}(s)=2sN_{\mathrm{active}}+4s^2 n_q d L_{\mathrm{attn}}\] \[P_{\mathrm{state,hybrid}}(s)=2s n_{kv} d L_{\mathrm{attn}}\cdot \mathrm{bytes}_{\mathrm{elem}}+S_{\mathrm{linear}}L_{\mathrm{linear}}\]

这里的变化有两层：

  • 只有 $L_{\mathrm{attn}}$ 层会生成随上下文线性增长的 KV 状态。
  • 线性层的状态更像常数项 $S_{\mathrm{linear}}$，而不是随 $s$ 持续膨胀的 KV。

因此 hybrid 时代并不是“KVCache 不重要了”，而是“要缓存的 token-linear 状态少了，应该更细粒度地决定什么状态放哪一层、什么时候取回”。在忽略常数级 linear state 的一阶近似下，临界点可写成：

\[s^{\star}_{\mathrm{hybrid}}\approx \frac{\mathrm{MFU}_{\mathrm{prefill}}\cdot \mathrm{FLOPS}_{\mathrm{peak}}}{\mathrm{BW}_{\mathrm{util}}\cdot \mathrm{Bandwidth}_{\mathrm{peak}}} \cdot \frac{n_{kv}}{n_q} -\frac{N_{\mathrm{active}}}{2 n_q d L_{\mathrm{attn}}}\]

需要强调一件事：本仓库当前脚本在图里实例化的是 token-linear 的 full-attention KV 主项（BF16/FP16 口径下等价于 $4s n_{kv} d L_{\mathrm{attn}}$）；linear state 目前只在理论分析里讨论，还没有被单独参数化进当前图表和 baseline summary。因此下面所有 phase diagram、tier line plot 和 storage pyramid 都应理解为 token-linear KV break-even 的 Analytical 结果，而不是已经完整覆盖 hybrid 所有状态的 Measured 结论。

5. 测试对象与证据口径

本次组会汇报分两层证据：

  • Analytical：用 Roofline / break-even 公式推导不同 tier 的收益点
  • Measured：用本地 vLLM baseline 的 TTFT、TPOT 与 GPU memory proxy 做校准对照

模型与硬件口径：

  • 主 baseline hardware：2x NVIDIA A100-SXM4-80GB
  • 最新硬件 sensitivity：1x NVIDIA A100-SXM4-80GB / 1x NVIDIA H100-SXM5-80GB / 1x NVIDIA H200-SXM5-141GB / 1x NVIDIA B100-SXM-192GB / 1x NVIDIA B200-SXM-192GB（均为官方 peak-spec Analytical profile；B100/B200 specs 来自 NVIDIA 官方 Blackwell platform 对比表，已通过 HGX 系统总规格交叉验证）
  • Qwen3-14B：dense attention，max_position_embeddings=40960
  • Qwen3.5-27B：hybrid attention，16 full_attention + 48 linear_attention，max_position_embeddings=262144

分层存储 tier 口径：

  • Local HBM = 4078 GB/s
  • CPU DRAM = 120 GB/s
  • RDMA Pool = 50 GB/s
  • Local SSD = 10 GB/s
  • Remote Block = 0.35 GB/s

6. 结果一：KV 增长与容量收益点

先看 token-linear KV 的增长速度，这决定“为什么一定需要 KV tiering”。

  • Qwen3-14B：1.526 GiB / 10k tokens
  • Qwen3.5-27B：0.610 GiB / 10k tokens

在 16 GiB KV budget 下，对应的容量阈值分别是：

  • Qwen3-14B：约 104,858 tokens
  • Qwen3.5-27B：约 262,144 tokens

解读：Hybrid attention 的确显著降低了 token-linear KV 压力，但这并不等价于“不再需要 KVCache”。它更像是把“必须做缓存”的压力从极短上下文推迟到了更长上下文，并把系统设计重点从“能不能放下”逐渐转向“什么 tier 值得放、何时放、如何取”。

Figure 1: Token-linear KV growth
Figure 1: Token-linear KV growth

7. 结果二：MFU=0.4 时，tier break-even 如何分层

在 MFU=0.4、BW_util=0.7 时，tier break-even 的主结论是：

  • HBM / CPU DRAM / RDMA Pool / Local SSD 全部在 <8K 之前就进入 fetch-wins 区域
  • Remote Block 的交点：
    • Qwen3-14B：165.6K
    • Qwen3.5-27B：31.7K

如果只看传统折线图，我们能知道哪条线高、哪条线低；但更适合组会讲故事的，其实是下面两张图：

  1. Phase diagram：直接把整个 context × bandwidth 平面染成 fetch-wins / recompute-wins 两个区域。
  2. Storage pyramid + break-even arrows：把 tier 层次和“从哪里开始值得 fetch”放在同一张图里。

先看最标准的 tier line plot，它回答“某个给定 tier 在什么上下文长度下跨过 break-even”。

Figure 3: Tier break-even at MFU 0.4
Figure 3: Tier break-even at MFU 0.4

再看 phase diagram。它最直观地告诉我们：在 10+ GB/s 的近端 tier 上，整个展示窗口几乎都在 fetch-wins 区域；真正贴着边界游走的是 sub-GB/s 的 Remote Block 这一层。

Figure 4: Context by bandwidth phase diagram at MFU 0.4
Figure 4: Context × bandwidth phase diagram at MFU 0.4

最后看 storage pyramid。它比折线图更适合组会讲“系统层次 + 调度逻辑”：同一层介质上，两种模型的箭头起点不同，意味着真正需要的是 cost-based scheduler，而不是静态的全局 offload 策略。

Figure 5: Storage pyramid with break-even arrows at MFU 0.4
Figure 5: Storage pyramid with break-even arrows at MFU 0.4

这里最重要的解释不是“哪条线更高”，而是架构差异如何改变远端慢介质的适用窗口：

  • Qwen3.5-27B 的 native max context 是 262K，因此在 Remote Block 这种慢 tier 上仍然有可见收益窗口。
  • Qwen3-14B 的 native max context 只有 40K，所以 165.6K 的交点已经落在当前模型支持窗口之外；如果不做 YaRN 或其他长上下文扩展，Remote Block 对它的现实价值非常有限。

8. 结果三：MFU=0.9 时，为什么边界整体右移

当 GPU compute 更强，也就是 MFU=0.9 时，远端慢介质的交点进一步右移：

  • Remote Block 的交点：
    • Qwen3-14B：414.3K
    • Qwen3.5-27B：239K

这说明 notes/kvcacheProfit.md 里的核心判断是成立的：GPU 越强、prefill 越快，远端慢 tier 越难打赢重算。也就是说，MoE / hybrid 时代不是 KVCache 没价值，而是对慢 tier 的要求更高，对 scheduler 的要求更严。

Figure 6: Tier break-even at MFU 0.9
Figure 6: Tier break-even at MFU 0.9
Figure 7: Context by bandwidth phase diagram at MFU 0.9
Figure 7: Context × bandwidth phase diagram at MFU 0.9
Figure 8: Storage pyramid with break-even arrows at MFU 0.9
Figure 8: Storage pyramid with break-even arrows at MFU 0.9

和 MFU=0.4 相比，这组三张图共同说明了一件事：不是 tier 层次变了，而是同样一套 tier，在更高的 GPU compute regime 下会变得“更像远端慢存储”。因此系统设计不能只写死一个 break-even，需要把实时 MFU、队列拥塞和上下文长度都放进调度器。

9. 结果四：GPU 代际 hardware sensitivity（含 Blackwell B100/B200）

为了回答“最新 GPU 世代会不会让 KV fetch 更不值得做”，我们补了一组完全独立于本地 measured baseline 的 Analytical peak-spec sensitivity，本次扩展至五代完整对比：

GPU Dense BF16 TFLOPS HBM BW (GB/s) HBM 容量
A100-SXM4-80GB 312 2039 80 GiB
H100-SXM5-80GB 989 3350 80 GiB
H200-SXM5-141GB 989 4800 141 GiB
B100-SXM-192GB 1750† 8000 192 GiB
B200-SXM-192GB 2250 8000 192 GiB

†B100 standalone datasheet 标注 1800 TFLOPS；此处取 HGX B100 口径（14 PFLOPS / 8 GPU = 1750 TFLOPS）作为保守值。B200 2250 TFLOPS 已通过 HGX B200 系统总规格（18 PFLOPS / 8 = 2250 TFLOPS/GPU）交叉确认。以上均为 Analytical/peak-spec 数值，非实测。

需要明确两点：

  • 这一节不是实测，而是把同一套 token-linear KV 模型代入 NVIDIA 官方单 GPU peak BF16 与 HBM 规格。
  • 这里的 A100 是单 GPU A100 80GB，不是前文 measured baseline 使用的 2x A100；因此这组数字不应直接和 31.7K / 165.6K 那组双卡结果一一对照。

Remote Block (0.35 GB/s) break-even 上下文长度（MFU=0.4, BW_util=0.7）

GPU Qwen3-14B Qwen3.5-27B
A100 80GB 66.1K <8K
H100 80GB 282K 128.7K
H200 141GB 282K 128.7K
B100 192GB 524.7K 330.9K
B200 192GB 684.1K 463.8K

Full-HBM-as-KV 理论容量上界

GPU Qwen3-14B Qwen3.5-27B
A100 80GB 512K 1280K
H100 80GB 512K 1280K
H200 141GB 902.4K 2256K
B100 192GB 1228.8K 3072K
B200 192GB 1228.8K 3072K

关键结论

  1. Remote Block 交点随代际算力线性抬升：从 Hopper 到 Blackwell，Dense BF16 FLOPS 从 989 增长到 1750/2250 TFLOPS，$t_{\mathrm{prefill}}$ 缩短，Remote Block 的 break-even 跟着右移——B200 对 Qwen3-14B 的交点推至 684K，对 Qwen3.5-27B 推至 464K。这意味着在 Blackwell 世代，需要更长的上下文才能证明 Remote Block 的取回值得做。
  2. H100 和 H200 的外部 tier 交点几乎重合：因为两者 dense BF16 FLOPS 相同（同为 989 TFLOPS），$t_{\mathrm{prefill}}$ 一样长，所以 Remote Block 的 break-even 近似。H200 相对 H100 的主要优势是本地 HBM 容量（141 GB vs 80 GB），体现为更大的 KV 理论上界（902.4K vs 512K）。
  3. B100 与 B200 都显著提高了外部 tier 门槛：B100（1750 TFLOPS）和 B200（2250 TFLOPS）将 Remote Block 交点推至 500K-700K 以上。对大多数实际部署（上下文 < 128K），Blackwell 机器上 Remote Block 已经显著慢于重算，系统设计需要重点关注 RDMA / Local SSD 这类更快的外部 tier，或依赖 KV 的语义 reuse 来摊薄取回成本。
  4. HBM 容量跃升（192 GB）是 Blackwell 最明显的新蓝海：B100/B200 的 192 GB HBM 将 Qwen3-14B 的本地 KV 上界从 H200 的 902.4K 提升至 1228.8K，Qwen3.5-27B 从 2256K 提升至 3072K。这意味着更多的上下文可以“全量放在 HBM 里”，从而绕过外部 tier 门槛问题。
Figure 9: Latest GPU hardware sensitivity A100-B200
Figure 9: Latest GPU hardware sensitivity A100-B200

MFU=0.9, BW_util=0.6 的统一 tier line plot：A100/H100/B100/B200

为了补一张更贴近“高计算利用率 + 保守带宽利用率”的单图，我们将同一张多硬件 tier line plot 重新生成为：

  • 假设：MFU_prefill=0.9、BW_util=0.6、max_context=1024K
  • 证据属性：Analytical sensitivity，不代表线上真实可达利用率
  • 图中仍含两条模型曲线簇（Qwen3-14B 与 Qwen3.5-27B），每簇叠加 A100/H100/B100/B200 四代 GPU
  • 当前文件路径仍沿用历史目录名 kvcache_profit_qwen3_vs_qwen35_hardware_tier_upper_mfu10/，但图内和摘要参数已经更新为 0.9/0.6

Remote Block（0.35 GB/s）在这组参数下的交点继续右移：

Hardware Qwen3-14B Qwen3.5-27B
A100 80GB 227.8K 83.5K
H100 80GB 794.5K 555.8K
B100 192GB >1024K >1024K
B200 192GB >1024K >1024K

这张图最值得讲的不是“哪条线最高”，而是两件事：

  1. 在 MFU=0.9, BW_util=0.6 下，A100 仍保留可见的 Remote Block 窗口，但 H100 已经把窗口推到 555K-795K；到了 B100/B200，0.35 GB/s 的 Remote Block 在 1024K 展示窗内已经完全失去竞争力。
  2. 10 GB/s 的 Local SSD 依然足够快，但对 Qwen3-14B 的 crossing 也被推高到了 B100=17.9K、B200=32.5K。这意味着随着 GPU 代际继续上升，原本“闭眼可取”的近端 tier 也开始需要更精细地看上下文长度与模型结构。

因此，这张新图给 HBFCache 的直接启发是：未来调度器不能只区分“本地快层 vs 远端慢层”，而要进一步区分“在当前 MFU/BW regime 下，这个 tier 对这个模型、这个上下文长度是否仍值得 fetch”。

Figure 9b: Tier line plot A100 H100 B100 B200 at MFU 0.9 and BW util 0.6
Figure 9b: Tier line plot A100/H100/B100/B200 at MFU 0.9 and BW util 0.6

如果把详细 tier 表展开，会看到和前文一致的结构：这张四硬件对比图里，HBM / CPU DRAM / RDMA / Local SSD 大体仍落在 <8K 的 fetch-wins 区域，真正被代际算力显著推右的仍然是 Remote Block 这类 sub-GB/s 慢层；只是对 Qwen3-14B 而言，Blackwell 上的 Local SSD 已经开始出现 10K-30K 量级的 crossing。这进一步说明调度器不能只按“tier 名称”做静态判断，而必须把模型结构、上下文长度和当前资源利用率一起纳入代价模型。

10. 结果五：Measured baseline 校准

为了避免报告只停留在 Roofline 推导，我们用本地 baseline 做了 Measured 对照：

  • Qwen3-14B@40,960：TTFT=5.130s，TPOT=13.187 ms/token
  • Qwen3.5-27B@262,144：TTFT=103.607s，TPOT=23.731 ms/token

Measured resource proxy 也显示：

  • Qwen3-14B 的 avg GPU memory slope 约 4.681 GiB / 10k tokens
  • Qwen3.5-27B 的 avg GPU memory slope 约 1.638 GiB / 10k tokens

Measured 数据和 Analytical 趋势是一致的：Qwen3.5 的 token-linear KV 更小，但更大的模型和 runtime overhead 仍让它在长上下文上体现出很高的 prefill 与 decode 成本。因此，“KV 更小”并不意味着“取缓存不再重要”，而是意味着系统必须更精细地区分近端 tier 与远端 tier。

11. 为什么 KVCache 仍然有优势，而且未来更有必要

第一，长上下文和 Agent memory 正在把状态规模持续推高。只要上下文和交互轮数继续增长，HBM 容量墙就不会消失，KVCache / state tiering 就仍然是刚需。

第二，prefix reuse 与共享会话缓存会把 KV 访问模式从“一次性取数”变成“多次复用”。一旦 workload 中存在共享前缀、热门 system prompt、跨请求共享会话状态，fetch cached KV 的价值就会显著提高。

第三，分层存储的经济性和容量优势不会消失。HBM 的每 GB 成本、容量扩展难度和部署规模都决定了我们必须引入 DRAM / RDMA / SSD / remote block 这样的外部 tier。

第四，未来系统的关键不再是“是否缓存”，而是“把什么状态放到什么 tier、什么时候拉回来、什么时候直接重算”。这正是 HBFCache 这类系统论文真正可以发力的地方。

12. 对 HBFCache 的直接启发

  • 对 HBM / CPU DRAM / RDMA / Local SSD 这类近端 tier，主要问题不是峰值带宽不够，而是软件路径、队列开销和尾延迟。因此重点应放在 GPU-initiated IO、零拷贝和 prefetch。
  • 对 Remote Block 这类远端慢 tier，关键是“是否值得取缓存”已经强依赖模型结构和 MFU。这里更需要 cost-based scheduler，而不是静态策略。
  • 对 hybrid 模型，系统不能只建模 full-attention KV，还要同时考虑 linear state 的冷热分层与预取。
  • 如果目标 workload 是 Agent / long-lived session，那么 KVCache 的价值不仅体现在降低 prefill，还体现在让状态生命周期可以跨请求、跨时间片管理。

13. 下一步建议

  1. 把当前只看带宽上界的 Analytical 模型扩展成 latency + bandwidth + queueing 联合模型。
  2. 用真实 host DRAM / SSD / RDMA 路径补一组 Measured latency tail 数据。
  3. 加入 prefix reuse / shared prompt / multi-session Agent workload，评估 KV reuse 对收益点的影响。
  4. 在 HBFCache 原型中实现 cost-based recompute-or-fetch scheduler，验证调度收益是否和公式预测一致。

14. 组会汇报时可以直接说的一句话

今天这组结果想说明的核心不是“KVCache 永远比重算好”，而是：在 Qwen3 与 Qwen3.5 这类架构差异下，KVCache 的收益点已经强依赖 GPU 算力、模型结构和 storage tier，因此未来真正值得做的是语义感知、代价模型驱动的分层 KVCache 系统，而不是单一介质上的静态 offload。