你让 AI 连续处理一批长对话，它不只要记住模型本身，还要保存每段对话已经算过的内容。前者是模型权重——训练后留下的大量数字参数；后者是 KV Cache——模型阅读上下文时记下的中间结果，后续生成可以直接复用。对话越长、同时处理的任务越多，这两类数据就越容易挤满昂贵的 GPU 显存。
Zack Yu、Chloe Wong 等人的论文研究了一种折中办法：在 GPU 的 HBM（高带宽显存）与主机内存之间，加入 HBF（高带宽闪存）。HBF 断电后仍能保存数据，容量也更大，可以被看作显存之外的“第二内存”。但它并不是更便宜、更大的 HBM：论文采用的参数中，HBF 写入很慢、能耗较高，而且闪存可承受的改写次数有限。
所以，问题不是“多加一层闪存有没有用”，而是模型权重和不断变化的 KV Cache 应该放在哪里，以及系统何时接纳新任务。论文提出 HBM—HBF—host 分层存储系统，并配套 buffered cache-aware scheduling，即“留出缓冲空间的缓存感知调度”。全部效果来自论文的 trace-driven simulations（按真实请求轨迹驱动的模拟），并非生产部署或 HBF 硬件实测。
把快而小的位置留给热点数据
计算机原本就会分层放数据：少而快的 GPU 显存靠近计算设备，较大但较慢的主存和存储放在后面。论文把 HBF 插入其中，让 HBM 保存频繁访问的权重和活跃数据，让 HBF 扩大设备侧可容纳的工作集；再放不下的状态才退到主机 DRAM 或 SSD。
新生成的 KV 状态和从主机重新载入的对话前缀，先进入 HBM。空间紧张时，系统按 LRU（最近最少使用）顺序，把较冷的 KV 状态移到 HBF，再移到主机。短命的激活数据仍写入 HBM，避免频繁改写闪存。已经结束的会话缓存也不会立刻删除，因为 agentic workload——会反复调用模型、工具并继续同一段上下文的智能体任务——可能在下一轮再次用到它。
这套设计同时比较了两种硬件布局。一种让 HBM 和 HBF 分享芯片周围有限的堆栈位置；另一种 H3 架构保留全部 HBM，再把 HBF 接在其后。后者容量和带宽更充裕，但论文也明确指出，它会使用更多 HBM 与 HBF，成本更高。
妙处不是多装缓存，而是少制造搬家
仅仅扩大容量仍可能适得其反。系统如果一次接纳太多请求，每个请求的上下文会在生成过程中继续增长，最终把刚保存好的旧会话缓存挤出去。下一轮需要这些内容时，系统又得从主机搬回来，或者重新做 prefill——也就是重新处理整段输入。缓存就在这种“写入、逐出、再载入”中反复搬家，既拖慢服务，也消耗闪存寿命。
论文的调度器先优先处理设备上已有较多可复用前缀的请求，再用 admission buffer 限制同时进入系统的活跃状态。可以把它理解为仓库不把每条过道都塞满：少接一点眼前的货，反而能保住下一轮马上要用的箱子。
实验中的 10% buffer 并不是永久划出一块不用的物理空间，而是在接纳请求时预留余量，给之后增长的 KV Cache 留位置。在 Qwen3-32B 的 H3 配置模拟中，相比没有缓冲的缓存感知调度，它让 HBF KV 写入量下降 69.33%，固定工作负载的完成时间也下降 4.68%。论文据所选容量、写入负载、10 万次 P/E cycle（闪存擦写周期）等假设估算，HBF 写入寿命由 4.77 年延长到 14.82 年。这个数字是模型外推，不是耐久性实测。
更大的设备侧空间，换来更大的批次
研究关注的是高吞吐场景，例如合成数据生成、异步智能体流程和强化学习 rollout。这里的目标是尽快做完一整批任务，可以接受单个请求等待更久。增加设备侧容量后，系统既能保留更多可复用前缀，也能组成更大的 batch（批次），让一份模型权重服务更多请求。
在论文评估的工作负载中，最快的 HBF 增强系统相对 HBM-only 系统，把整批任务的完成时间缩短了 36.1%—87.0%。更具可比性的一组结果是：在原始长度的 Llama-3.1-405B 与 GLM-5.2 轨迹上，采用 H3、把权重留在 HBM 的配置，完成时间分别降低 45.95% 和 56.29%，模型估算能耗分别降低 24.06% 和 14.41%。收益主要来自保留可复用 KV 状态、减少重复 prefill，以及用更大批次摊薄权重读取。
最长的 GLM-5.2 扩展轨迹中，论文报告的最高模型估算节能达到 55.8%。但 HBF 并不天然省电：它的读取和写入都有额外成本，部分轻负载反而增加能耗。权重放在哪里也很关键。GLM 的 TP16 配置把全部权重移到 HBF，完成时间几乎没有改善，能耗却比权重留在 HBM 时高 33.42%。这说明 HBF 更适合作为经过编排的扩展层，而不是把所有数据一股脑搬进去。
为什么值得关注
这项工作的意义，不是宣布闪存已经取代内存，而是把 LLM 服务的边界重新画了一遍。过去，显存不够常被理解成单纯的容量问题；论文显示，容量、缓存保留、批次大小、数据搬运和闪存磨损其实是同一个调度问题。
模型权重很少改变，KV Cache 却不断增长和更新，两者天然需要不同的摆放策略。若 HBF 同时承接它们，系统必须决定哪些数据值得占用 HBM、哪些可以下沉，以及什么时候宁可少接任务也要保护缓存。换句话说，HBF 能否成为“第二内存”，关键不只在介质带宽，也在服务软件是否从一开始就理解它的代价。
局限与未知
- 结果来自请求级模拟。模拟器虽用 NVIDIA H100 和 B200 的测量拟合部分内核延迟，但混合批次与 HBF 性能仍含外推，也没有实现生产级 HBF 控制器。
- 能耗没有计入静态功耗和完整封装功耗；写入寿命还假设磨损均匀、写放大为 1，并依赖论文选定的耐久度参数。
- 论文优化的是整批任务完成时间，而非单请求延迟。以 Llama 的 H3、权重驻留 HBM 配置为例，平均 TPOT（首个输出之后每生成一个 token 的时间）从 90.85 毫秒升至 438.61 毫秒。吞吐更高，不等于每位用户都等得更短。