KV-Cache Offloading #

1. 主题缘起 #

KV-cache offloading 作为一个独立方向的形成，源于两股力量的碰撞：一方面，LLM 推理中 KV cache 随序列长度线性增长，直接成为 GPU VRAM 的首要瓶颈，限制可服务的 batch size 和最大上下文长度 [2506.03296]；另一方面，CPU DRAM 容量通常是 GPU HBM 的 10–100 倍，且 CPU 内存带宽与 GPU 的差距已收窄至约 3 倍（200 vs 600 GB/s），使得将 memory-bound 的 attention 计算卸载到 CPU 侧成为可行路径 [2506.03296]。

这一方向跨越了 framework（调度与执行编排）、kernel（CPU 侧 attention kernel 实现）以及 agent（agentic workload 下 KV cache 生命周期管理）三个维度。2024–2025 年间，随着 agentic 推理的兴起，KV cache 的管理从单纯的"GPU 内存优化问题"升级为"跨硬件层次的调度决策问题"——offload 不再是唯一选项，而是必须与 admission control、eviction policy、compute offloading 等策略在统一框架中权衡。

2. 覆盖的 category 分布 #

七篇 framework 主 category 论文中，APEX 在 kernel 层面做了实质贡献（自定义 CPU attention kernel 替代 ISPC paged-attention），ThunderAgent 和 Concur 则在 agent workload 调度层面重新定义了 KV cache offloading 的有效性边界；MORI (2606.00866) 主 category 为 agent，把 agentic tool-call 空闲窗口作为垂直分层的驱动信号。CLO 和 Tutti 则代表了"offloading 肯定"路线内部的两条系统工程分支——CLO 打通 CPU-light + PCIe 满载的 CPU 侧瓶颈 [2511.14510]，Tutti 则把 CPU 从 GPU↔SSD 的数据与 I/O 控制路径彻底移除 [2605.03375]。HBF Sucks? (2608.11668) 是本主题第一篇 far-tier 器件层面的反结论论文——用 device-agnostic 成本模型证伪"把 SSD 换成 package-local 闪存 (HBF)、运行时不变"的 drop-in 部署 [2608.11668]。

3. 时间线 #

4. Evolution timeline (技术谱系) #

核心演化分为两条路径：(1) compute offloading 路径从 FlexGen 的被动存储卸载，经 FastDecode/NEO 的 CPU 计算参与，演化到 APEX 的异步延迟同步 [2506.03296]；(2) offloading 否定 路径，Concur 和 ThunderAgent 在 agentic workload 下实测证明 PCIe offloading 不可行后，转向准入控制和程序感知调度 [2601.22705] [2602.13692]。两条路径在技术定位上互补而非对立——前者面向 constrained single-GPU 场景，后者面向 multi-GPU agent serving 场景。在这两条主线之外，MORI 走出第三条：它不否定 offload，而是用相对空闲度把"该 offload 谁"按 agentic tool-call 空闲窗口排序，只在长 idle 时下沉 [2606.00866]；HBF Sucks? 则从器件层给整条"再加一层更慢更大的存储"谱系钉下一块边界石——用成本模型证明 far-tier drop-in 何时不成立 [2608.11668]。

5. 技术线交错 #

Framework × Kernel 张力：APEX 的 deferred cross-iteration synchronization 是一个纯框架层设计，但其效果严重依赖 CPU attention kernel 的绝对性能。Llamafile kernel 在大 batch 下达到 2× speedup over ISPC，但小 batch 时反而更慢 [2506.03296]。这意味着框架调度决策（Asynchronous Overlap vs Asymmetric Pipelining）与底层 kernel 特性耦合——Inequality (6) 的 $T_{gatt}$ 参数直接由 kernel 性能决定 [2506.03296]。

Framework × Hardware 约束：CPU-GPU 性能比 ($\rho_c$) 是 APEX 收益的决定性因素。T4 (16GB) 上 +96% 而 A10 (24GB) 上仅 +11–89%——更强的 GPU 使 offloading 收益缩小 [2506.03296]。这暗示 KV-cache compute offloading 有"硬件适用窗口"：它只在 mid-range/edge GPU 上显著有效，高端 GPU (A100/H100) 上可能退化 [2506.03296]。

Framework × Agent 范式冲突：当工作负载从 chatbot 转向 agentic 推理时，KV cache offloading 的假设基础被颠覆。ThunderAgent 实测表明 PCIe 带宽不足以支撑 agent 高频上下文切换 [2602.13692]；Concur 给出更精确的定量证据——在 DeepSeek-V3 上，高并发下 offload latency 超过 prefill 重算 [2601.22705]。这迫使 agent-serving 系统放弃 offload 路径，转而从调度层面控制并发数——本质上是承认"在 agent 场景下，KV cache 是一种需要准入控制的共享带宽资源而非可无限扩展的存储资源" [2601.22705]。MORI 则给出同一范式冲突下的另一个反应：与其整体放弃 offload，不如把 agentic workload 特有的 tool-call 空闲窗口本身变成放置信号——用连续相对空闲度 $\iota=T_{acting}/(T_{reasoning}+T_{acting})$ 把 program 排成谱线，只把长 idle（传输成本被 gap 掩盖）的 program 下沉 CPU DRAM，短 idle 留 GPU [2606.00866]。这把 ThunderAgent/Concur 的"offload 在 agent 下失效"细化为"reuse-blind 的整体 offload 失效，但 idleness-gated 的选择性 offload 仍可回本"——MORI 实测 80 并发下相对最强 offload 基线 TA+O 反而 +20–71% 吞吐、−18–43% TTFT [2606.00866]。其代价是需要 agent runtime 暴露 phase/idleness 语义（可在网关侧仅用每步 3 个时间戳重建），呼应 §7.3 "把语义状态暴露给调度器"这一跨 category 需求。

Framework × 存储器件层级（far tier 何时回本）：offloading 谱系的默认假设是"多加一层更便宜、更大的存储，系统一定更好"，HBF Sucks? 第一次系统性地给这个单调假设钉下边界。它把 far tier 的净收益写成一阶成本-收益恒等式 $\Delta_{\text{HBF}}=f\Delta t_{\text{media}}-C_{\text{move}}-C_{\text{pkg}}-C_{\text{var}}-C_{\text{life}}$——只有第一项是收益且被暴露分数 $f$ gate，其余全是被减去的成本——再拆成三个可证伪的必要条件 [2608.11668]：(C1) 读 I/O 必须在关键路径上——一次 $3.75\times$ 的介质延迟 sweep 只把端到端延迟动 <1%，反演出暴露分数 $f\approx1\%$，即便介质无限快也只能省 1%，而买它的 package 取舍却付出 2–5.5× 的延迟代价；(C2) 读必须多于写——四条生产 trace 上 reads-per-write $\rho=0.20$–$0.88$ 处处低于 break-even，因为两层层级把可复用的热块留在近端、只把 write-once 冷尾交给闪存（prefix hit 仍有 38–53%，说明复用存在但到不了 far tier）；(C3) 带宽必须可持续——3D-ICE 16-Hi TLC 模型在 80°C 结温上限只能撑 202.27 GB/s / 53.72 W（远低于接口峰值），而 trace 写量 48–140 TB/day 把寿命耗到容量匹配 SSD 池的 0.56× [2608.11668]。一个反直觉结果强化了 C2/C3 的耦合：把 KV block 从 16 token 粗化到 512 token 会抬高表观 prefix hit rate，却使闪存写量增加 1.38×（部分复用要整块重写）[2608.11668]。这条 far-tier 判据与本主题反复出现的"共享传输通道是稀缺资源"张力互补而非重复——Tutti/CLO 证明的是"当传输可被隐藏进 compute slack 时 offload 赢" [2605.03375]，HBF Sucks? 证明的是"当传输本就不在关键路径（$f\approx1\%$）时，再快的 far tier 也换不回被牺牲的近端容量（$C_{\text{pkg}}$ 主导，比收益大两个数量级）"。二者共同把胜负手从"far tier 多快"转到"目标对象是否落在 high-$f$/high-$\rho$ 角"：其 placement map 显示 transient decode KV 落在 low-$f$/low-$\rho$ 角三条件全败，而 weights/shared prefix 落在对角强区——论文的论点是"器件本身没问题，drop-in SSD-替换部署才是问题" [2608.11668]。

Framework × 传输竞争（读写解耦 vs 并发带宽崩塌）：offloading 的传输通道不仅在多请求间被争用，其内部的读/写混合同样会引发带宽崩塌。Tutti 实测在 NVMe SSD 上混合 read/write 会因内部 cache 抢占导致带宽跌约 60%，因此采用 slack-aware 调度将 R/W 解耦——read 优先、write 延迟到后续 slack 或 decode 阶段填充，从而把 compute→I/O bound 的 crossover 点推至 98.3% hit rate、SSD-backed 逼近 DRAM-backed 性能 [2605.03375] [2605.03375]。这与本主题反复出现的"共享传输通道是稀缺资源"张力同源：Concur 面对的是 PCIe 在多请求间的争用 [2601.22705]，Tutti 面对的是同一 SSD 通道内 R/W 相位的争用，二者都指向"通过调度把互相干扰的传输相位在时间上错开"这一共性解法。CLO 则从另一端压缩传输开销——用 GDRCopy 零拷贝消除 CPU gather，仅 4 CPU 线程即满载 PCIe 4.0 峰值 21.21 GB/s（对比 InfiniGen/PQCache 64 线程仍不饱和），并用 GPU-centric polling 同步替代 cudaStreamSynchronize 消除 kernel launch 气泡 [2511.14510] [2511.14510]。这三者共同表明：在 offloading 可行的场景里，胜负手已从"是否 offload"转向"如何在共享通道上把传输相位调度到不互相踩踏"。

6. 共识与分歧 #

共识 #

1. KV cache 是 LLM 推理的首要内存瓶颈：三篇论文一致认同 KV cache 线性增长是限制 batch size 和吞吐的核心约束 [2506.03296] [2601.22705] [2602.13692]。
1. Request-level 调度在 agent workload 下失效：ThunderAgent 和 Concur 都证明 per-request 粒度的 KV 管理会导致 agent 前缀被错误驱逐。ThunderAgent 观测到 7.14× 端到端延迟放大 [2602.13692]；Concur 量化了 49% 的中间阶段延迟被 recomputation 消耗 [2601.22705]。
1. CPU 内存带宽与 GPU 的差距可承受：APEX 和 FastDecode 共识 CPU 带宽约为 GPU 的 1/3（200 vs 600 GB/s），对 memory-bound 操作而言这个差距允许有效利用 [2506.03296]。

分歧 #

1. Offload vs. 重算的根本路径选择：
2. APEX 坚持 offload + compute 路线——将 KV 传输到 CPU 并在 CPU 执行 attention，通过异步延迟同步掩盖传输和计算延迟 [2506.03296]。
3. ThunderAgent 和 Concur 则 否定 offload 路线——ThunderAgent 明确选择"接受重算代价 + 精选驱逐对象"的策略 [2602.13692]；Concur 用实验证明 HiCache 式 PCIe offloading 在高并发下比重算更慢（0.34×）[2601.22705]。
4. 根源：分歧源于目标场景不同。APEX 面向 single constrained GPU + 低并发 decode-heavy（chat/CoT），PCIe 单流传输可行；ThunderAgent/Concur 面向 multi-GPU + 高并发 agent batch，PCIe 成为共享瓶颈。
5. 补充视角（量化判据）：2601.19910 为这一路径分歧提供了一个统一的定量判据——当工作负载的 $\kappa_{\text{ratio}} = K/T$ 超过临界比 $\kappa_{\text{crit}}$ 时 offloading 退化为 memory-bound，此时重算/准入控制才占优；反之低 $\kappa_{\text{ratio}}$ 场景下 offload + compute 仍可行 [2601.19910]。实测 $\kappa_{\text{crit}}$ 仅 1–2，而 ShareGPT/document-QA 的 median $\kappa_{\text{ratio}}$ 高达 100–10000，超阈值 1–2 个数量级——这从带宽 roofline 角度印证了 ThunderAgent/Concur 在高复用场景否定 offload 的实测结论 [2601.19910]。
6. 补充视角（offload 肯定路线的可行域）：CLO 和 Tutti 从两个不同方向给出了"低并发 / 传输可隐藏"场景下 offload 仍占优的实证，与上述否定结论并列而非矛盾——它们精确勾勒了 offload 依旧有效的边界，而非推翻边界外的失败。CLO 面向单机单 GPU、BSZ≤64 的 decode-heavy 长上下文，通过 CPU-light 设计把 offloading 系统的 CPU 端瓶颈（缓存管理 36.2% + PCIe 利用不足 + 同步气泡）压至可忽略，decode 吞吐净增 9.3–66.6% [2511.14510]。Tutti 则证明只要用 GPU-centric I/O 把传输隐藏进 compute slack，即便下沉到比 DRAM 慢一档的 SSD，也能在 hit rate < 98.3% 的绝大多数工作负载下让 I/O 延迟被完全掩盖 [2605.03375]。两者共同细化了分歧的定位：offload 之争的关键不是 offload 本身对错，而是"目标场景的传输量能否被隐藏在可用的计算/带宽窗口内"。
7. 补充视角（agent 场景内的第三条路：idleness-gated offload）：MORI 直接站在 ThunderAgent/Concur 的对立面又不回到 APEX——它承认 agent 高并发下整体 offload 会失败，但主张失败的是 reuse-blind 的无差别 offload，而非 offload 本身。用相对空闲度把 program 排序、只对长 idle（tool-call gap 足以掩盖传输）的 program 下沉 DRAM，MORI 在 80 并发下相对最强 offload 基线 TA+O 取得 +20–71% 吞吐、−18–43% TTFT [2606.00866]。这与前一条 $\kappa_{\text{crit}}$ 判据同构——都是把"该不该 offload"从二元立场变成按对象/窗口逐一判定的条件问题，只是 MORI 的门控变量是 agentic 特有的 idleness 而非通用的 $\kappa_{\text{ratio}}$ [2606.00866]。
8. 补充视角（far tier 的器件层边界）：HBF Sucks? 把这场分歧下推到"再加一层比 DRAM/SSD 更慢更大的 package-local 存储值不值"，给出与上述场景判据平行的器件判据——far tier 净收益要求暴露分数 $f$、reads-per-write $\rho$、可持续带宽三者同时满足，而 drop-in HBF 在四条生产 trace 上三者全败（$f\approx1\%$、$\rho=0.20$–$0.88$、热限 202 GB/s），E2E 反而慢 2–5.5× [2608.11668]。它不否定"选择性 + reuse-aware"的 far tier（weights/shared-prefix 落在强区），只否定 reuse-blind 的 drop-in——与 CLO/Tutti"传输可隐藏时 offload 赢"是同一条边界的器件侧刻画 [2608.11668]。
1. 调度决策的驱动机制：
2. APEX 采用 解析不等式 (Inequality 6) 做逐 iteration 的策略选择 [2506.03296]。
3. Concur 采用 AIMD 反馈控制，用 KV usage + hit rate 双信号自适应调节并发 [2601.22705]。
4. ThunderAgent 采用 证明最优的指数衰减函数 做 cache 权重衰减 [2602.13692]。
5. 三种方法各自声称最优但假设不同：APEX 假设可准确离线 profiling；Concur 假设 hit rate 是可靠拥塞信号；ThunderAgent 假设工具延迟 memoryless。
1. PD 分离是否兼容：
2. ThunderAgent 明确承认与 PD 分离不兼容——拆分后 HBM 池变小，更早触发 thrashing [2602.13692]。
3. Concur 未讨论 PD 分离交互 [2601.22705]。
4. APEX 在单节点运行，不涉及 PD 分离 [2506.03296]。

7. Open challenges (根本性困难) #

7.1 PCIe 带宽墙：offloading 的物理极限 #

KV cache offloading 的根本困难在于 PCIe 是一个共享的、容量有限的传输通道。当多个 agent/request 同时触发 swap-in/swap-out 时，PCIe 带宽被争用，传输延迟劣化到超过 GPU prefill 重算 [2601.22705]。这不是工程可解的——PCIe Gen5 x16 约 64 GB/s 双向，而单个 DeepSeek-V3 请求的 KV cache 可达 6.67 GB [2601.22705]，10 个请求同时 swap 就耗尽带宽。CXL 或 NVLink-C2C 可能缓解但需要下一代硬件。

涉及 category 协作：framework（调度何时 swap） + hardware（更高带宽互联） + kernel（压缩后 swap 减少传输量）。

已知部分尝试：HiCache/LMCache 做了 CPU offloading 但在高并发下失败 [2601.22705]；APEX 绕过传输瓶颈选择在 CPU 原地计算 [2506.03296]。两者都未根本解决多流竞争问题。

预估难度：1–3 年（等待 CXL 成熟 + 框架适配）。

7.2 CPU-GPU 性能比的"适用窗口"问题 #

APEX 证明了 offloading 的收益 $S \approx \rho_c \cdot \rho_t$（CPU/GPU 计算力比 × decode 占比）[2506.03296]。在高端 GPU 上 $\rho_c$ 极小（H100 attention 远快于任何 CPU），offloading 收益可能为零甚至为负 [2506.03296]。但论文未测试 A100/H100，不清楚确切的"适用边界"。这不仅是实验缺失——它是一个根本性 trade-off：GPU 越强，CPU offloading 越无价值，但 GPU 越强也意味着部署成本越高，恰恰是需要 offloading 节约成本的场景。

涉及 category 协作：hardware（异构架构设计） + kernel（更高效 CPU kernel 扩大适用窗口） + framework（自动判断何时 offloading 有价值）。

预估难度：持续存在——与硬件代际演化绑定。

7.3 Agentic workload 的不可预测性 #

Agent 工作负载的核心困难在于上下文增长速度和工具等待时间都不可预测 [2602.13692]。ThunderAgent 的指数衰减函数依赖 memoryless 假设，但远程 API 实际呈重尾分布 [2602.13692]；Concur 的 AIMD 依赖 hit rate 信号，但在无共享前缀的异质 workload 下信号可能失真 [2601.22705]。任何基于假设的策略都可能在实际 agent 行为分布的尾部失效。

涉及 category 协作：agent（暴露语义状态给 runtime） + framework（自适应调度） + algorithm（学习型替代解析策略）。

已知部分尝试：Concur 的双信号 ($U_t \land H_t$) 设计减少了误判 [2601.22705]；ThunderAgent 的周期性检测 + global queue 允许动态迁移 [2602.13692]。但两者都无法处理分布突变。

预估难度：3–5 年（需要 agent 行为建模 + 在线学习调度的融合）。

7.4 $\kappa_{\text{crit}}$ 临界比：offloading 可行边界的量化框架 #

前述 7.1–7.3 从工程与场景角度描述了 offloading 的困难，2601.19910 则给出了一个可计算的 roofline 判据，把"何时 offloading 会失效"从经验判断变成解析预测。其核心是把 prefill 从 compute-bound 转 memory-bound 的临界点分解为模型因子与硬件因子的乘积：$\kappa_{\text{crit}} = \kappa_M \times \kappa_{HW} = \frac{F_{\text{pf}}}{B_{\text{kv}}} \cdot \frac{\text{BW}_{\text{PCIe}}}{C_{\text{eff}}}$，当工作负载 $\kappa_{\text{ratio}} = K/T$（缓存 token 数 / 新 prefill token 数）超过 $\kappa_{\text{crit}}$ 时进入 memory-bound 区 [2601.19910]。乘法结构使模型侧优化（MLA/量化增大 $\kappa_M$）与硬件侧优化（NVLink/统一 HBM 增大 $\kappa_{HW}$）可独立推进。

这一框架带来三个此前小节未量化的新结论：(1) 传输而非计算主导延迟——实测 PCIe 有效带宽仅 15 GB/s（峰值的 23%），使 $\kappa_{\text{crit}}$ 实测只有 1–2（远低于按峰值带宽推算的 7.8–14.3），Qwen3-235B 在 $K=65$K、$T=64$ 时 99% 执行时间花在 PCIe 传输上 [2601.19910]；(2) GPU 严重欠载——offloading workload 下 GPU 平均功耗仅达 TDP 的 22–28%，意味着数据中心电力/散热基础设施大量过剩 [2601.19910]；(3) 临界比随硬件代际恶化——$\kappa_{\text{crit}}$ 关于 $C_{\text{eff}}$ 单调递减，GPU 算力增速快于互联带宽，越新的 GPU offloading 越受限；NVLink C2C 仅将 $\kappa_{\text{crit}}$ 提升 5.3×、统一 HBM 提升 48×，但 document-QA（$\kappa_{\text{ratio}}=5000$）仍超出阈值 [2601.19910]。这为 7.1 的"PCIe 带宽墙"和 7.2 的"CPU-GPU 性能比适用窗口"提供了统一的解析度量。

涉及 category 协作：framework（VRAM-aware / $\kappa$-aware 调度） + hardware（NVLink C2C、统一 HBM 提升 $\kappa_{HW}$） + kernel（KV 压缩降低 $B_{\text{kv}}$ 提升 $\kappa_M$）。

8. 成熟度判断 #

整体成熟度：Research-frontier，正在向 Production-ready 迁移。

• Compute offloading（APEX 路线）：Frontier。代码未开源，仅在 T4/A10 上验证，尚无社区集成 [2506.03296]。但 AIConfigurator (NVIDIA) 已将 APEX 纳入参考系统 [2506.03296]，说明工业界已关注。Llamafile kernel 选型也暗示可在 llama.cpp/ktransformers 生态落地。
• Agent-aware KV 管理（ThunderAgent/Concur 路线）：Research-frontier → Early adoption。ThunderAgent 已开源（GitHub），Concur 作者团队与 InternEvo/verl 重叠，预计进入 agentic-RL 训练栈 [2601.22705]。Program-aware scheduling 概念正被 vLLM/SGLang 社区吸收 [2602.13692]。
• 传统 storage offloading（FlexGen/LMCache/HiCache 路线）：Declining for agent workloads。Concur 和 ThunderAgent 都实测证明其在高并发 agent 场景下失效 [2601.22705] [2602.13692]。但对低并发 long-context chat 场景仍有价值。

趋势方向：加速分化——constrained GPU 场景继续深耕 compute offloading，multi-GPU agent 场景转向准入控制 + 程序感知调度。两条路线可能在"compute offloading + admission control"的组合方案中收敛 [2506.03296]。

9. 邻接 topic #

邻接 topic	边界交叉点	潜在融合方向
agent-serving / agent-scheduling	ThunderAgent 和 Concur 本质上是 agent-serving 系统，KV cache 管理是其核心子问题	KV-cache-offloading 可能被纳入更广义的 agent-scheduling topic
heterogeneous-inference	APEX 的 CPU-GPU 混合推理是异构计算的一个实例 [2506.03296]	若更多 NPU/DPU 参与推理，compute offloading 将泛化为异构计算调度
attention-optimization	KV cache 压缩（量化、稀疏化）与 offloading 正交互补 [2506.03296]	CPU 侧 INT4/INT8 KV + compute offloading 可组合加速
PD-disagg	ThunderAgent 明确证明 PD 分离与 program-aware 调度不兼容 [2602.13692]	两个 topic 存在范式张力，短期内不会融合

建议：若 agent-scheduling topic 积累足够实体，可考虑将 ThunderAgent/Concur 从本 topic 分出，本 topic 聚焦于"跨硬件层次的 KV 数据移动"。当前三篇论文中 APEX 是纯 offloading 工作，ThunderAgent/Concur 更多是"offloading 否定 + 替代方案"。

10. 参考 #

Entity	Categories	Role in topic	Key contribution
[2506.03296]	framework, kernel	core technique	Asynchronous Overlap + deferred sync：统一 batch 消除双倍 linear ops，跨 iteration 延迟同步扩展 CPU 计算窗口
[2506.03296]	framework, kernel	cross-paper positioning	定位 APEX 为异构计算第二波最精细调度工作；建立与 NEO/FastDecode/FlexGen 的演化关系
[2602.13692]	framework, agent	negative evidence + alternative	证明 PCIe offloading 在 agent 高频切换下失败；提出 program-aware scheduling 替代路径
[2601.22705]	framework, agent	negative evidence + alternative	量化 PCIe offloading 的失败条件（HiCache 0.34× on DeepSeek-V3）；引入 AIMD agent-level admission control
[2601.19910]	framework	quantitative bottleneck analysis	$\kappa_{\text{crit}} = \kappa_M \times \kappa_{HW}$ 临界比框架：解析预测 offloading 下 prefill 何时从 compute→memory-bound；实测 99% 时间在 PCIe 传输、GPU 仅 22–28% TDP、临界比随 GPU 代际恶化
[2511.14510]	framework	CPU-light offloading（正面路线）	Head 粒度近似缓存 + speculative prefetch + persistent cache 消除 CPU 缓存管理开销；GDRCopy 零拷贝 4 线程满载 PCIe 4.0（21.21 GB/s）+ GPU-centric 同步消除气泡，decode 吞吐 +9.3–66.6%
[2605.03375]	framework	GPU-centric SSD-backed offloading（正面路线）	GPU-native object store + GPU io_uring 把 CPU 移出数据与 I/O 控制路径；slack-aware 读写解耦避免并发带宽崩塌，SSD-backed 达 DRAM-like（crossover 98.3%），TTFT −78.3%、RPS ×2、成本 −27%
[2606.00866]	agent, framework	idleness-gated 垂直分层（agent 场景第三条路）	连续相对空闲度 $\iota$ 把 agentic program 排谱线做 GPU↔CPU 垂直分层 + 双层准入 + 多副本亲和（churn 14–15%→0.3–2.9%）；80 并发 +20–71% 吞吐、−18–43% TTFT，DP=3 维持 99%+ GPU 利用率；分界线随 GPU:CPU 容量比自适应，零重调
[2608.11668]	framework	first negative result + far-tier cost model	device-agnostic 恒等式 $\Delta_{\text{HBF}}=f\Delta t_{\text{media}}-C_{\text{move}}-C_{\text{pkg}}-C_{\text{var}}-C_{\text{life}}$ 拆成 C1/C2/C3 三必要条件证伪 far-tier drop-in：SSD→HBF 运行时不变致 E2E 慢 2–5.5×、$f\approx1\%$、$\rho=0.20$–$0.88$、热限 202.27 GB/s、寿命 0.56× SSD；block 16→512 token 抬高 hit 却增写 1.38×；结论"器件没问题、drop-in 部署有问题"