缓存不该困在一台服务器里

一份AI存储榜单，人们通常先看速度。 InfoQ注意到，在日前公布的MLPerf Storage v3.0评测结果中，焱融科技F9000X三节点集群在3D U-Net训练数据供给测试中实现了544GiB/s的聚合带宽，并在Checkpoint 70B测试中取得读、写带宽双项第一。 但比成绩本身更值得注意的，是这一轮评测开始考察什么。 MLPerf Storage v3.0新增了KVCache测试项，模拟多轮会话中的 KV Cache 整体写入与回读，并报告模拟输出 Token 吞吐、读写带宽和 P95 读取时延。这意味着，存储要处理的对象，从预先准备好的数据集，延伸到了推理过程中产生的运行时状态。 过去，AI存储的核心任务是持续、稳定地为GPU供数——它服务于计算开始之前。而现在，它被要求让一次已经完成的计算继续发挥作用，也就是进入推理过程内部。 焱融从训练存储起步，到推出AI 原生推理存储系统 YRCache，再到发布共享缓存一体机ContextBox，恰好为观察这一变化提供了一个具体样本。 一、那些不该有的等待，和“重新算一遍”的浪费 在训练阶段，存储的核心矛盾始终是数据通路。 一方面，数据供给跟不上，GPU就会被迫空转；另一方面，训练中需定期写入用于容灾的 Checkpoint，写得慢拖累有效算力，读得慢则拉长恢复时间。 高带宽、高并发和低延迟的吞吐性能，因此成为 AI 存储的基本功。 焱融全闪存储 F9000X 跑出的成绩，印证的正是这种极致的数据通路能力，其解题思路也足够清晰：尽可能减少计算对数据的等待。 推理同样需要这些基本功，但它引出了一类性质完全不同的问题。 大模型处理请求时，需先解析输入上下文完成预填充（Prefill），随后逐 Token 生成答案。输入越长、提示词越复杂、对话轮次越多，预填充消耗的算力和时间就越惊人，往往成为推理成本和响应延迟的主要瓶颈。 在 Transformer 架构中，已计算的 Key 和 Value 会被保留为 KV Cache，供后续 Token 生成时直接复用，避免反复计算上下文。若不同请求之间存在相同的上下文前缀（如系统提示词、长文档背景），理论上这部分计算状态也能跨请求复用，省去重复的预填充开销。 但要从“单次生成内部的缓存”走向“跨请求的全局复用”，中间隔着的并非一次简单的数据读取，而是三重相互牵连的系统工程挑战： 首先，内容相同，不等于缓存可用 同一份文档，只要系统提示词微调、Prompt 模板改动或 Token 序列微移，复用前缀就会失效；模型版本、KV Cache 精度格式哪怕稍有不一致，缓存也无法通用。系统复用的是严苛匹配的物理计算状态，而非文本本身。 其次，显存有限，缓存未必留得住 GPU 显存既要容纳模型权重，又要承载并发任务的运行时上下文。未被即时命中的缓存，只能在显存中被动淘汰，或被迫换出至主机内存与本地 SSD，面临更高的二次装载开销。 最后，节点孤立，留得住也未必用得上 首个请求由 A 节点计算并生成了缓存，后续带相同前缀的请求却可能被调度至空闲的 B 节点。若缺少跨节点共享机制与缓存感知的调度能力，缓存留在 A 节点的本地磁盘上便如同孤岛，B 节点依然只能“从头再算一遍”。 至此，推理侧的存储问题已超越单纯的读写速度，转变为一套系统级的权衡：哪些缓存值得存、存在哪里、存多久；后续请求如何高效命中；以及取回缓存的代价，是否真正低于重新计算。 训练的目标是让 GPU 少等数据，推理的目标则是让 GPU 少做重复计算。 单纯提高读写带宽只能加快数据搬运，但若无法解决状态匹配、跨机共享与全局调度，便无法真正释放上下文复用的价值。 二、将 Kv Cache管起来之后，还要跨节点 将 KV Cache 从显存卸载，是留存更多上下文的最直接手段。 在单机架构中，焱融采用了三级分层：G1 为 GPU 显存，G2 为主机内存，G3 为本地 SSD。层级越往下，容量越大、单位成本越低，但回读到计算端的延迟与搬运开销也越高。YRCache 的首要任务就是统筹这套单机分层：通过内存配额、资源隔离与多盘 NVMe 聚合，在保障低延迟的同时实现缓存的高效换入换出。 但单机内的分层调度跑通，并不意味着问题就此解决。推理系统绕不开的真正瓶颈，是跨节点复用。 设想一个典型场景：A 节点刚完成一次长文档问答，并将生成的 KV Cache 写入了本地 SSD；数分钟后用户追加提问，此时 A 节点正忙，请求被调度器分配给空闲的 B 节点。 系统随即陷入两难： 1、要么把请求重新塞回 A 节点：虽然省去了缓存搬运，但必须忍受排队延迟； 2、要么把缓存从 A 节点拉取到 B 节点：看似合理，却缺乏一条专用的低延迟传输通路。 指望单机本地 SSD 解决跨机共享并不现实。即使持续堆砌单机硬盘容量，也无法提供集群级的服务能力——其他节点既缺乏全局发现与索引机制，也无法规避单机故障、离线导致的缓存丢失。 那么，直接把缓存写入既有的分布式共享存储是否可行？ 这笔账同样不划算。传统共享存储面向模型权重、训练数据和 Checkpoint 设计，强调强持久化、高可靠与全局一致性；而 KV Cache 是一种允许丢弃、可重新计算的瞬态中间状态，具有高频访问、毫秒级延迟敏感、生命周期短等特点。传统共享存储的问题不在于“能不能存”，而在于无法以合理成本满足这种短生命周期的低延迟访问。 F9000X 这类高性能存储提供了极致的数据通路，但通用存储并不等同于专用的缓存管理与跨节点复用体系。ContextBox 瞄准的，正是本地 SSD 与传统持久化存储之间的系统空白。 作为一台独立的共享缓存一体机，ContextBox 在焱融的体系中被定义为 G3.5 层。它与计算节点解耦，提供了一个由多个推理节点并发访问的全局缓存池： 硬件协同：搭载最多 26 块 U.2 NVMe SSD 提供高并发容量池，配置 4 块 NVIDIA BlueField-3 双口 200Gb DPU 卸载数据路径以释放主机 CPU，并通过 RDMA/RoCE 网络提供 120GB/s 实测带宽，单台可支撑 8 节点集群的高并发吞吐。 软硬配合：硬件负责打通高吞吐的共享数据通道，上层则由 YRCache 负责缓存匹配、生命周期管理与跨级流动，同时兼顾兼容 LMCache、Mooncake 等生态。 至此，整套分工与层级逻辑严密闭环： G1 ~ G3（计算节点内）：显存、内存与本地 SSD，消化单机内的高速命中与分层卸载； G3.5（独立共享层）：ContextBox 提供多节点共享的高性能缓存池，打通跨机流转； G4（持久化共享层）：通用分布式存储，继续承载模型、数据集、Checkpoint 以及需永久沉淀的业务数据； YRCache：作为中枢软件贯穿 G1 至 G3.5 各层，完成全局缓存的寻址、调度与生命周期编排。 回到长文档问答的场景：只要 A 节点生成的缓存已下沉至 G3.5 共享层且尚未失效，B 节点就能以远低于重算的代价直接拉取前缀状态，仅针对用户的新增追问进行计算。 焱融所谓“全栈 AI 存储”在推理侧的意义，正是将这条跨节点的复用链路彻底接通。 三、以存换算，账要算在整套系统上 把计算状态存下来