OCP2026｜KV缓存池化进入验证
收益取决于复用与搬运成本
截至 2026 年 10 月 17 日
OCP 2026 把上下文缓存的建设推进到三个更具体的问题：容量能否随需求分配，缓存能否及时取回，收益能否一致衡量。三星通过动态容量设备的语义仿真（DCD Emulation），演示实例之间的弹性内存分配；XCENA 展示预取与热点固定；Micron 则提出容量感知的复用模型。这些分别属于方案演示、软件协同和初步模型验证，尚未形成统一的 KV 服务标准。[1][2]
相比单纯增加内存容量，本届更值得关注的是软件开始管理缓存的去向和使用时机。对 Token 工厂，外部内存或 SSD 能带来多少价值，要由它实际省下的重算、取回成本和服务目标共同决定。理解这组发布，先要区分它们服务的三类缓存需求。
先区分活跃会话 暂停会话和共有前缀
模型生成后续内容时，需要反复利用此前上下文计算出的键和值，通常称为 KV Cache。它是推理中间状态，与用户原文、向量数据库或 Agent 长期知识的用途不同。保存得当，可以避免重复计算；保存的位置不合适，也可能把计算等待换成数据搬运等待。
第一类是正在生成内容的活跃 KV，每个输出步骤都可能需要访问，对带宽与时延最敏感。第二类是暂停会话留下的历史 KV，例如 Agent 等待工具返回或用户批准时的上下文，价值取决于会话多久回来。第三类是多个请求共有的前缀，如重复使用的系统提示，价值取决于能被多少请求真正复用。
这三类需求不能只按字节数比较。同样大小的缓存，活跃会话需要持续读取，暂停会话需要在恢复时及时就绪，共有前缀则可能反复省下昂贵的输入计算。被多会话共享的一份前缀只占一份物理空间；反过来，文本相同却出现在不同前文之后，KV 也不能默认直接复用，因为表示已包含上文影响。容量公式及其模型差异见技术附页。
第一组进展让容量随实例需求流动
动态容量机制已有协议基础。CXL 3.0 原始规范已经包含 Dynamic Capacity Device 相关机制，本届增量是把这种容量调整思路接到具体推理软件上。[11] 三星的 Pangaea v3 负责通过 Kubernetes 编排内存池，LMCache 负责衔接推理缓存，两者共同演示了随实例需求调整主机可见容量的路径。
固定分配下，一个实例可能不断驱逐长上下文，另一个实例的容量却闲置。只增加全池总容量，可以缓解压力，但仍可能留下无法被繁忙实例利用的空闲切片。弹性分配尝试把这部分资源交给需要它的实例，让容量管理随工作负载变化。对多模型、多租户平台，问题由“给每台服务器配多少内存”，进一步变成“哪些请求应占用哪一段容量，以及何时收回”。
三星 OCP 官网报告，在该代理工作负载演示中，弹性分配相对静态分配最高降低 38% 的首 Token 等待时间（TTFT），满足服务目标的有效吞吐 goodput 最高达到静态基线的 3.3 倍。[3] 这一结果说明特定负载下减少闲置容量和重算的潜力；联合演讲仍明确标注 DCD 语义仿真。另一组 DRAM 基线结果和实验硬件集中列在技术附页，不能与这里的倍率互换。
从演示走向服务，还要回答容量回收的代价。某实例拿到空闲容量以后，如果原租户突然返回，平台应当迁移缓存、等待释放，还是让请求重算？调整完成前，调度器能否准确知道容量与数据是否已就绪？这些不是本次结果已经保证的功能，而是采用弹性池后必须新增的验收问题。动态分配解决了静态切分的浪费，也把资源争用和控制时延带入产品边界。
第二组进展让缓存赶在使用之前就绪
及时取回要同时解决“提前知道要读什么”和“以合适粒度搬运”。预取让系统在请求真正使用缓存之前开始读取；热点固定则把高频共享前缀保留在快层，减少反复读回。XCENA 的 Maru 与 LMCache 集成，展示了在 CXL 与 SSD 混合路径中利用这两种提示，让设备 DRAM 承接即将发生的访问。[2]
这里接近 DRAM 的访问表现，来自数据提前就绪和命中快层的条件，不能理解为 NAND 本身获得了 DRAM 时延。对产品团队，能够传入访问意图、预取期限和热点策略的接口，比单独强调统一地址空间更能说明软件需要做什么。访问不可预测时，仍应允许未命中，并根据时限及时重算。
三星的另一项本届演示，把灵活数据放置（FDP）与更大的 NVMe 最大传输大小（MDTS）接入 LMCache，分别针对写放大和主机 CPU 开销。[3] 它们让数据布局和 I/O 粒度配合缓存生命周期。具体耐久性与 CPU 收益还取决于固件、放置策略、请求大小和回收行为，不能从一块盘的峰值带宽直接推得。
这两条路径对应不同的软件改造位置。FDP 和 MDTS 主要影响 SSD 的数据放置与 I/O 组织；预取和固定则要求上层调度器把未来访问意图传递下去。平台团队因此不能只比较容量单价：同样的存储硬件，软件是否知道哪些块即将被读取、哪些共享前缀值得保留，可能决定缓存层能否兑现推理收益。对应用不能准确预测的访问，还需要保留普通未命中与及时重算的路径。
第三组进展让缓存收益可以被一致衡量
Micron 本届提出的建模框架，把工作负载产生的工作集、各层容量和取回成本连接起来。核心概念是“有效复用”：某段上下文理论上会再次被访问，只有届时仍保留在可及时取回的位置，复用机会才可能兑现。容量不足会触发驱逐和重算，因此增加容量的收益可能在越过工作集门槛时突然出现，之后再增加未必同样有效。[1]
这为前两组演示提供了共同的评价问题。动态分配是否把容量给了真正能复用的实例，预取是否在期限之前完成，热点固定是否挤掉了更有价值的数据，都要回到真实请求分布。Micron 已完成初步 GH200 稠密模型验证，更多内存层与 MoE 仍待验证；该框架可以帮助寻找容量拐点，不能替代实际业务回放。
验收指标应是满足 TTFT、token 间隔及端到端时限的有效请求量，并同时观察质量、错误率和恢复行为。总体命中率很高，仍可能因为命中的都是廉价短前缀而收益有限；反之，少量昂贵长前缀的复用就可能释放大量 GPU 时间。因此应同时记录 token 加权命中、节省的 prefill 时间、回填队列尾延迟、每会话驻留字节秒和设备写入量，最终计算完成一次合格会话的总成本。
共同接口和评测方法仍在形成
不同产品要进一步互换，还需要共同的操作语义。XCENA 在联合演讲第19页提出，OCP 的可组合内存系统社区 CMS 可以讨论并标准化策略接口 policy API，具体动机就是让调度器与设备对预取、热点固定等操作形成相近理解。当前证据支持一项标准化建议，尚不能据此宣称统一接口已获批准。[2]
评测方法也有相应缺口。Micron 在第16页列出尚缺厂商中立的工作负载描述、容量感知复用指标、内存层级比较方法和结果格式，建议成员对齐范围、共拟 v0.1、伙伴验证并共同审阅。已完成的是分析框架与初步验证，多厂商、多内存层的共同测试仍有待推进。[1]
这两类议程互相补充。操作接口决定系统能否协同，评测方法决定协同是否真的有效。即使两套产品都有“预取”操作，如果一个返回表示任务被接受，另一个表示数据已可消费，上层就不能互换使用；即使都报告命中率，若一个按块、一个按 Token、一个只计成功请求，比较结果也可能失真。这些是需要在未来接口和测试中澄清的语义，不应被当成任何厂商已作出的保证。
对采购方，标准仍在讨论并不意味着只能等待。可以先固定引擎、连接器和后端版本，用可回放轨迹验证局部收益，并把预取完成、容量拒绝、删除、故障回退等行为写成自己的验收要求。但采用某个可运行实现，与承诺未来能无缝更换厂商之间，仍隔着接口稳定性和互操作测试。产品合同不宜提前把这种潜在可替换性当成已经实现的能力。
采用顺序应从真实会话轨迹开始
第一步应当用真实会话轨迹建立无复用、本地复用、外部缓存三组对照，在相同 GPU 预算和 SLO 下回放长短请求、租户突发与故障恢复。只有当省下的重算和释放的昂贵容量，持续覆盖存储、搬运、软件运维与风险成本，增加一层缓存才是一项好投资。Token 工厂最终需要的，是知道哪段计算值得记住、应当记多久，以及来不及取回时如何可靠重算的系统。
OCP 2026 的信号，并非所有 KV 方案已经成熟到同一阶段。弹性池化开始验证容量随需求流动，存储路径开始理解缓存的生命周期，接口和评测的共同语言也进入讨论。下一阶段更值得观察的，是这些演示能否形成有稳定版本、清楚失败语义和多厂商验证的系统。对经营者，判断投入的核心仍是：在既定响应目标下，有多少计算确实被省下，以及为此增加的状态和故障责任能否被持续承担。
技术附页
以下集中保留实验口径、容量与时延推导、数据路径以及服务正确性要求，便于把本届方案放入同一套验证流程。
一 实验配置与比较基线
三星联合演讲第10、12页把动态池化明确称为 DCD Emulation，即在现有硬件上复现动态容量语义，为原生 CXL 3.x DCD 平台预演。第11页另报告相对 96GB DRAM 基线的 TTFT 降低52%、goodput 达到7.1倍，门槛为 TTFT 不超过60秒。该组数字与官网相对静态分配的38%和3.3倍使用不同基线，不能拼成统一结论。[2]
同一演讲第7页实验配置列出 MD220 模组与 RTX PRO 6000 的96GB GDDR7显存。展台列出的 MD310 产品，不能自动写成这套实验所用模组；一般层次图中的 HBM，也不能替换具体平台的 GDDR7。[2]
Micron 的初步验证使用 GH200 NVL2、Llama 3.1 70B FP16、张量并行 TP=2，并包含30K输入、128输出、完全可复用前缀的配置。它首先验证稠密模型和这一类工作集下的趋势；MoE、新的 KV 优化以及更多内存层仍列为后续工作。[1]
二 容量公式与回填时间怎样计算
对普通稠密注意力模型，未压缩 KV 总量可按“2 × 层数 × KV 头数 × 头维度 × token 数 × 每元素字节数”估算，再计入并发、分块浪费和副本。这里必须使用 KV 头数，而非笼统的注意力头数；分组查询注意力、滑动窗口和潜变量注意力都会改变容量模型。参数量相同的模型，不能直接套用同一张缓存容量表。
对于一个已经命中的块，取回时间应包括查目录、排队、实际搬运、解压或格式转换，以及恢复到引擎可消费状态的时间。只有它在关键路径上的代价小于重新计算这段前缀，命中才有意义。有效带宽应取整个路径的实测瓶颈，不能把 SSD 顺序读取标称值直接代入 GPU 恢复时间。若传输与计算可以重叠，则比较未被遮蔽的部分；若很多请求同时恢复，则还要计算共享链路上的排队。
进一步决定“要不要保存”时，要乘上未来复用的概率和次数，再扣除写出成本、驻留时间成本，以及让其他有价值缓存被驱逐的机会成本。一个长达数小时却不再返回的会话，可能不如一个短而高频的系统前缀值得保留。LRU 可以作为起点，但生产策略应学习各类业务的重访间隔、可复用 token 数和重算代价，并设置写入准入，避免把一次性上下文全部倾倒到外部存储。
例如，纯作说明，某段缓存为 2GiB，完整路径有效带宽为 20GiB/s，数据搬运本身就需要约 100ms。若查找、排队和转换另需 150ms，而重算只需 180ms，这个“命中”反而更慢；如果重算需要两秒，取回就很有价值。这里没有通用的长上下文阈值：模型更小、预填充算力更强，或者共享链路更拥塞，都会移动边界。调度器必须允许放弃一个已命中的远端块，并把及时重算作为正常路径。
这里有一条容易混淆的边界。预填充与生成分离（Prefill/Decode）的 KV 交接，是同一次请求在两个执行阶段之间传递必要状态；跨请求复用，才是在未来请求中省下原本要重新做的 prefill。前者即使完全没有重复请求也需要发生，不能用“缓存命中率”替代交接带宽与时延评估。vLLM 文档把 PD 分离的重点放在独立调节 TTFT 和 token 间隔，并控制尾部干扰；它并不承诺单凭拆分就提升吞吐。[6]
三 数据路径和存储寿命的部署边界
GPU 高带宽内存 HBM 适合活跃解码工作集，但容量还要与模型权重、激活和运行时缓冲竞争。主机 DRAM 可承接短暂停顿和热前缀，代价取决于 跨处理器内存位置（NUMA）、用于稳定传输的固定页内存、CPU 至 GPU 链路及复制引擎。CPU 与 GPU 之间有高速一致性互联的平台，不能与普通 PCIe 服务器使用同一条恢复曲线。Micron 的五层模型提供了从近端内存、主存、扩展内存到上下文存储的分类，但图中的带宽和驻留区间是架构描述，不是所有产品都能保证的服务等级。[4]
CXL 池能扩大主机可见容量，并让分配更有弹性，却不会自动把远端内存变成 HBM。必须逐项确认 CPU 根端口、交换层级、内存交错、操作系统映射，以及 GPU 如何读取这些数据。一个很具体的反例是 LMCache 的 DAX 后端：文档明确描述读取时把数据复制回 CPU 内存对象；其 MP 实现当前还不保证重启后索引恢复。于是“可寻址”“GPU 可直接消费”“跨进程存活”“断电持久”是四种不同能力，采购和 API 都不应把它们合并。[5]
还必须区分两种“卸载”：把暂时不用的缓存保存到下层，等待下一轮恢复；与让活跃解码在每一步都从下层获取注意力数据。前者主要影响恢复时间，后者可能把每个输出 token 都绑定在较慢链路上。若不能把传输隐藏在计算之后，再大的外部容量也无法保证流式输出速度。采用近内存计算或压缩可以改变这个边界，但应单独验证质量、计算能力和软件兼容，不能算成普通容量扩展的默认收益。
共享池同样有边界。两个主机从同一池分配容量，不代表它们已经拥有正确的跨主机共享语义；即使消除了网络上的 KV 副本，GPU 侧也仍然有访问、传输或计算代价。池化节省的是闲置容量和重复持有，交换上行带宽、控制器排队与故障域则可能变成新的集中瓶颈。
容量池还需要保留头部空间。若把设备容量全部出售，瞬时回填、迁移和副本重建就可能无处落脚。缓存感知路由也存在反作用：为追求命中而把请求都送往同一节点，会让 GPU 或网卡排队恶化；把请求送往空闲节点又要支付搬运。较好的路由决策应同时估计目标节点的计算队列、缓存就绪时间和剩余输出长度，而不是简单选择命中 token 最多的节点。这也是缓存从库函数变为基础设施服务后新增的系统责任。
SSD 适合容纳更长时间跨度、更大容量的可复用状态，但“便宜且能存”并不足以形成推理收益。缓存块大小、合并 I/O、并发队列、预取提前量和回填带宽共同决定恢复时间。太小的请求浪费 CPU 和协议开销；太大的传输又可能堵住急需恢复的小请求。共享 SSD 池还要承受跨租户的突发恢复，不能仅凭单盘峰值规划服务规模。
评估 SSD 寿命，应从每天准入多少 KV 字节出发，加上设备写放大、重写和副本成本，再与具体型号的耐久指标比较。冷数据多不等于写流量小；FDP 的实际收益仍需在固件、放置策略和回收行为配合下验证。SSD 层还要承受共享恢复的突发，单盘顺序读写峰值不足以代表整个服务的持续能力。
四 跨实例复用的正确性和租户隔离
跨实例复用先要解决“这块 KV 是否属于当前计算”。缓存身份应绑定模型权重版本、token 序列与前缀、适配器，以及会改变表示的分词、位置编码、注意力和量化设置；布局还必须与引擎、并行切分兼容。版本升级应切换命名空间，不能只按一个人类可读模型名继续命中。vLLM 已在前缀哈希中纳入父块、token 及 LoRA、多模态输入和隔离 salt 等额外信息，这说明缓存身份本来就比文本内容复杂。[7]
工程上更稳妥的方式，是先完整写入不可变块，再发布“可读取”的元数据；读取期间用租约或引用计数阻止回收，失败时按未命中处理，并给重算设置预算，防止池故障触发全群重算风暴。租户隔离还要覆盖鉴权、目录可见性、配额、删除和审计。salt 用于划分复用范围，不应替代访问控制；落盘加密也不能替代生命周期管理。若 KV 保留了敏感输入的派生信息，用户删除会话时，副本与索引是否一并失效必须有明确承诺。
一致性之外还要定义失效后的行为。目录声称命中但数据已回收时，应当能识别对象代际，避免读到被复用地址中的另一块内容；分片跨多张 GPU 时，需要确认所需分片全部可用，再进入消费阶段。模型升级、租户删除和池节点故障的演练，至少与正常命中测试同等重要。缓存可以是可丢弃的派生状态，但服务不能在缓存丢失后失去完成请求的能力。
五 接口状态与会话计费契约
对 CTO，较合理的边界是集成引擎连接器、成熟传输和存储后端，自主掌握业务特有的准入、路由、优先级、容量定价和 SLO 控制。产品 API 应提供带命名空间的查询、预取、固定、释放和删除，并返回容量拒绝、超时及未命中等可恢复状态；不要把“已接受预取”包装成“数据已就绪”。LMCache 已提供缓存操作与配额接口，但软配额和异步执行的具体语义仍须由上层服务正确处理。[8]
会话计费也不宜直接照搬磁盘容量计费。活跃时占用 GPU 显存，等待工具时占用外部缓存，两者承担的资源成本不同；把所有等待时间都按最高级内存保留，会掩盖产品本身的低效率。更可行的是按服务等级约定恢复时限和保留窗口，再在内部选择介质。企业可以购买更长的可恢复会话窗口，但不能把缓存命中承诺等同于数据永久保存；业务记录仍应由独立的持久系统保存。
资料与口径说明
本篇的会场核心证据为 [1]与 [2]，均为 OCP 2026 公开材料。标准化议程分别见前者第16页、后者第19页；不是已发布的统一 KV 规范。
三星官网演示、DCD 仿真、XCENA 混合路径及 Micron 分析模型分别保留其平台和基线，不将结果拼接为统一性能结论。Micron 2026年9月的分层文章、vLLM 与 LMCache 动态文档仅用于架构与实现背景；软件语义读取于2026年10月17日。2GiB/20GiB/s 为说明性算例，服务接口与采购建议为作者分析。
参考资料与配图出处
[1] Tiered Memory for LLM Inference — A Modeling Framework for KV-Cache Offload — Khayam Anjam | Micron / OCP Global Summit 2026 | 2026-10。
https://drive.google.com/file/d/1ML8XjdPeXdkdUAUNmOPIInQwKR718cRq/view
[2] Disaggregated CXL Memory Architecture for Agentic AI: Dynamic Pooling, Sharing, and PNM Offloading — Samsung、XCENA、Tensormesh、Marvell / OCP 2026 | 2026-10。
https://drive.google.com/file/d/1iK-aymMCRgd_qHZaWzRTVz1NENAW5yK9/view
[3] OCP Global Summit 2026 — Samsung Semiconductor | 2026-10。
https://semiconductor.samsung.com/events/ocp-2026/
[4] Unlocking the Token Economy: Micron Powers AI's KV Cache — Micron | 2026-09-04。
https://www.micron.com/about/blog/memory/dram/unlocking-the-token-economy-micron-powers-ais-kv-cache
[5] Device-DAX (/dev/dax) — LMCache | Live documentation retrieved 2026-10-17。
https://docs.lmcache.ai/kv_cache/storage_backends/dax.html
[6] Disaggregated Prefilling (experimental) — vLLM | Live documentation retrieved 2026-10-17。
https://docs.vllm.ai/en/latest/features/disagg_prefill/
[7] Automatic Prefix Caching — vLLM | Live documentation retrieved 2026-10-17。
https://docs.vllm.ai/en/latest/design/prefix_caching/
[8] HTTP API — LMCache | Live documentation retrieved 2026-10-17。
https://docs.lmcache.ai/mp/http_api.html
[9] Architecture Overview — LMCache | Live documentation retrieved 2026-10-17。
https://docs.lmcache.ai/developer_guide/architecture.html
[10] Optimizing KV Cache Offloading to CMM-D in a CXL Switch-based Memory Pool — Samsung | 2026-06。
https://download.semiconductor.samsung.com/resources/white-paper/Optimizing_KV_Cache_Offloading_to_CMM-D_in_a_CXL_Switch-based_Memory_Pool.pdf
[11] Compute Express Link Specification r3.0 v1.0 — CXL Consortium | 2022-08-01。
https://computeexpresslink.org/wp-content/uploads/2024/02/CXL-3.0-Specification.pdf