AMD宣布收购MEXT那天，我第一反应不是“又一家存储初创团队上岸了”，而是长久以来悬着的一口气终于有人接住了——围绕KV Cache、SSD和IO Die的数据通路问题，终于有了一个从芯片层面往下打的系统性方案。MEXT这家团队做的事情，说白了就是三件事：CXL内存语义扩展、NVMe之上的KV对象存储，以及对底层让GPU和SSD直接对话的那个IO Die做定制化改造。放在两年前这个组合看起来有点杂，但在今天的大模型推理业务面前，这几乎是标准答案的第一页。
KV Cache有多大？一个70B级别的模型，按单token来算，KV Cache保守估计就有300KB以上，处理128K长上下文时，单条会话就要吃掉接近40GB。再乘上并发路数，这个数字会迅速进入TB级。任何单一种类的存储介质都接不住这个需求：显存太贵，内存不够大，SSD又太慢。于是KV Cache数据如何在HBM、本地DRAM、CXL扩展内存、SSD之间流动，就成了推理系统的生死线。而这条通路上的核心枢纽，恰恰就是IO Die。这篇文章我就顺着这条线，把这个架构里的来龙去脉和落地经验一次讲完。
1. 收购背后的技术信号：KV Cache把存储体系逼到了墙角
1.1 KV Cache是推理期的“动态负债”
很多人以为大模型推理吃显存主要是因为权重文件大，其实权重是静态的，加载一次就能长期复用。真正让显存发烫的，是运行期不断膨胀的KV Cache。Transformer做解码时，每生成一个新token，都要把当前token对应的K向量和V向量存下来，后续所有token的注意力计算都要回头去读之前存下的这些向量。这就是“缓存”的本义：它不是为了加速而设，而是注意力机制本身的必备物料。
KV Cache的累积速度是线性的，但上下文长度一拉长、并发路数一放大，它的总量就是灾难级的。我习惯用一个生活类比来解释这件事：模型权重好比老师提前做好的PPT，一节课从头到尾都是同一份；KV Cache则是课堂上不断增加的板书，老师每写一个字都得留着不能擦，因为后面的内容随时要回头引用前面的推导。PPT再厚也就那么多，板书却会随着进度只增不减。大模型推理也是同一个逻辑，请求越长，这个“动态负债”就越大。
具体算一笔账。假设一个70B级模型，层数80，KV头数因为用了GQA/MLA这类压缩方案降到8个，每个头的维度128，用FP16存储。每生成一个token，需要存的KV量是：
2（K和V） × 80层 × 8个KV头 × 128维 × 2字节 = 327680字节 ≈ 320KB这里还没算任何额外开销。如果一条请求的上下文长度是128K，那么这条请求的KV Cache就是320KB × 131072 ≈ 40GB。注意，这只是一条会话，线上推理服务通常要同时扛几十上百路并发，一个请求池的KV Cache总量分分钟破TB。
1.2 为什么必须让SSD和CXL扩展内存入场
面对这个量级，单纯的显存扩容已经走不通了。HBM的成本和产能决定了它只能作为最高层的快速缓存存在，不可能把TB级的KV Cache全部塞进去。本地DRAM容量稍微大一些，但有内存墙，单机内存通道和容量上限卡得很死。至于SSD，容量管够，但延迟和带宽又差了几个数量级。
在这个背景下，CXL扩展内存和KV型SSD加速被推到了前台。CXL的好处是能通过PCIe物理接口把内存池化，系统看到的是可统一寻址的内存地址空间，容量可以横向扩展，虽然延迟比本地DRAM高，但比SSD低得多。而SSD虽然慢，但容量/成本比最优，可以作为整个KV Cache体系的最底层“冷存储”。
所以真正的工程问题不是选哪种介质，而是怎么把KV Cache按访问频率和温度，聪明地分布在HBM、DRAM、CXL和SSD这四层里，同时保证推理延迟不崩塌。这个分级调度逻辑，才是MEXT这类团队最核心的价值。
1.3 IO Die：所有KV Cache跨级流动的必经关口
在传统CPU和GPU的chiplet架构里，IO Die是个容易被忽略的角色。它管着内存控制器、PCIe控制器、各种外部总线的汇聚，计算die之间通过片上互联交换数据，但一旦要访问系统内存、网卡、SSD、CXL设备，每一条外部数据通路都必须经过IO Die。换句话说，IO Die是整个芯片外部数据吞吐的咽喉。
KV Cache一旦发生缓存未命中，GPU要从CXL扩展内存或NVMe SSD里重新取数据，这个请求路径就需要穿越GPU内部的互联架构，到达GPU的IO Die，再通过PCIe或CXL链路抵达主机侧，主机再通过自己的IO Die把数据发到对应的存储设备。也就是说，一次KV Cache冷读可能要被两个IO Die各卡一次。
收购MEXT这类团队，技术意图也集中在这里：把KV检索、索引查找、地址翻译这些原本要消耗主机CPU的活，下沉到IO Die周边或者存储控制器里。数据通路上的控制权一旦集中到IO Die，整条链路的调度延迟、DMA效率和缓存替换策略就能被精细编排，而不是让GPU和CPU两边各管一段、互相踢皮球。
2. KV Cache、SSD与IO Die的数据通路拆解
2.1 一次KV Cache未命中的完整旅程
我拿一个具体的部署场景来拆这条数据通路。假设GPU正在做解码，某个attention头需要读取第37层的KV向量块，结果这组KV块不在GPU的显存缓存里。那么这次读取会经历这样一段旅程：
第一步，GPU内的SM核心发起访存请求，先查L1/L2，未命中后进入HBM控制器。HBM的命中延迟大约在100ns到200ns这个量级，这一层对KV Cache非常重要。如果HBM全命中，整个推理的延迟曲线会非常稳定。
第二步，HBM未命中，请求通过片上互联进入GPU的IO Die，再经过PCIe/CXL链路向主机方向发起跨设备访问。这里有个关键点：跨IO Die的每一次请求都有固定的协议开销和链路上行下行成本，单次访问的字节数如果太小，带宽利用率会惨不忍睹。
第三步，如果部署了CXL内存池，请求会在CXL交换机上被路由到远程内存节点，访问延迟大概在几百纳秒量级，比本地DRAM明显更高，但还在可接受范围内，适合放温数据。
第四步，如果这块KV块已经被换到SSD上，请求就得先穿透到主机侧IO Die，再由NVMe控制器查索引表、定位物理块、发起DMA读。从SSD上把数据读出来要几十微秒到上百微秒，这个数量级在推理流水线里已经算“不可忽略”的停顿了。为了摊平这个代价，SSD读取必须做成大块、预取、批量聚合的形态，绝不能指望GPU每次单点去拉一个小KV块。
把四个阶段连起来看，你就会发现，KV Cache数据通路优化的本质，就是尽量让大量请求停留在第一步和第三步，尽可能压住第四步的发生比例。因为从HBM到SSD，延迟相差了大约三个数量级，任何一次跨界都是性能上的伤痛。
2.2 带宽和容量的关系：别只盯着SSD有多大
很多人规划KV Cache存储时，第一反应是“SSD容量大，多买几块”。但真正跑起来你会发现，瓶颈往往不是容量，而是跨设备搬运KV Cache时的那条通路带宽。
先看数字。一条PCIe Gen5 x16链路，双向带宽大约在64GB/s这个级别，看着不少对吧？但HBM单颗堆叠的带宽动辄1TB/s以上，两者根本不是一个量级。如果你设计了一个方案，让大头KV Cache都放在SSD上，那么每次解码步骤都要把成百GB的KV数据往GPU侧搬，PCIe链路瞬间就会被打满，而那只是少数几个请求的量。
我习惯用引水管道来类比这件事。容量是水缸，带宽是水管。KV Cache需要的不是“存得下”，而是“取得出、取得多”。只计算容量的人，大概率会在第一次压测时发现GPU利用率一路走低，因为GPU永远在等数据从底层介质里爬上来。
所以正确思路是算清每一层的带宽预算。比如某次推理任务里，KV Cache读取的峰值需求是50GB/s，那么这条数据通路至少要提供50GB/s以上的有效读取带宽。如果SSD直连提供15GB/s，CXL扩展内存可以提供40GB/s，那就要想想让数据分散在哪一层，而不是把50GB全部砸在其中一个上。
2.3 缓存淘汰与预取策略：KV Cache不是普通缓存
KV Cache跟传统缓存最大的区别是，它不能随意丢弃。CPU或GPU的普通数据缓存丢一次，大不了去内存重读；KV Cache丢一次，整个序列的注意力历史就残缺了，推理结果直接错掉。所以这里没有“淘汰后重新计算”的兜底逻辑，只有“降级到更底层存储”的选择。
实际工程里，我推荐按层和序列双维度来管理。解码时，当前正在参与计算的层和最近活跃的序列，KV Cache固定留在HBM；有一段时间没被访问但可能再次被访问的层，下沉到CXL扩展内存；彻底冷下来的序列，打包写入SSD，并且记录好地址映射和索引。
预取也很有讲究。Transformer解码是自回归的，当前token生成完，下一步大概率访问相邻位置的KV块。所以可以基于块地址线性预取，提前把下一批KV块从SSD搬到CXL甚至HBM。这块逻辑做得好不好，直接决定KV Cache命中率。
MEXT这类方案里比较聪明的一点，就是把KV Cache索引表放在DRAM/CXL内存中，而不是跟着数据一起躺在SSD上。因为索引表通常只有KV数据的几百分之一大小，完全可以长驻在大容量内存里，避免每次寻找数据都要先做一次SSD读索引的动作。索引在内存、数据在分级存储，这才是一个可持续的架构。
3. 典型落地：四级存储架构与关键参数计算
3.1 HBM到NAND的分层设计
把KV Cache按访问频率和温度做四级分层，是我这两年在实际项目里验证过最靠谱的方案。
| 层级 | 容量规模 | 参考延迟 | 参考带宽 | 主要用途 |
|---|---|---|---|---|
| HBM显存 | 几十GB | 100-200ns | 1TB/s以上 | 当前解码层KV块、热点序列 |
| 本地DRAM | 几百GB | 80-110ns | 数百GB/s | 活跃序列、索引表 |
| CXL扩展内存 | 数TB | 300-500ns | 几十GB/s | 温数据、次活跃序列 |
| NVMe SSD | 数十TB | 50-100us | 10GB/s级 | 冷数据、历史长尾序列 |
这套分层的核心逻辑是，让带宽最高的介质处理最频繁的访问，让容量最大的介质兜底最冷的存量。HBM负责把注意力计算最需要的KV块保住，本地DRAM承接活跃但不在当前步的KV块，CXL扩出来的内存容纳大量“可能回头访问”的历史数据，SSD则只承接那些真正冷下来的序列。
Windows和Linux部署时，CXL扩展内存会被识别成独立NUMA节点，这一块如果你不在业务代码里做代理亲和性设置，系统调度会时不时把访问踢到远端路径，延迟抖动会非常明显。
3.2 上线前需要算清楚的几个关键参数
我拿一个具体配置来演示怎么算。假设你有一个70B级模型，目标上下文长度128K，计划支持32路并发推理，每路都跑满长上下文。
单路KV Cache大约40GB，32路同时满负载，KV Cache总量就是40GB × 32 = 1.28TB。如果全部放HBM，按当前主流单卡显存规模，至少需要十几张卡专门用于存KV Cache，成本完全不可接受。所以必须分层：
- 保留20%的KV Cache在HBM，约256GB，保证当前步的高频访问。
- 50%的KV Cache放CXL扩展内存，约640GB，覆盖绝大多数中频访问。
- 30%的KV Cache下沉到SSD，约384GB，应对最冷数据。
这个配比不是拍脑袋。注意力计算带有明显的时间局部性，靠近当前token的KV块访问概率高，远距离的历史KV块访问概率低。20/50/30是经验值，你需要用真实请求追踪数据来校准，但作为初始预算比例它是稳定的。
接着算带宽需求。假设解码速度目标为单路每步10ms，32路并发则每步需要读取的KV Cache总量近似等于单路KV Cache的60%左右（因为注意力覆盖的是全部历史token），也就是40GB × 60% × 32 ≈ 768GB要在10ms内读完。这个数字远超任何单条链路的带宽峰值，所以真实处理一定要依赖分块和稀疏化：FlashAttention的思路就是把注意力计算分块进行，只读取当前计算块需要的KV片段，而不是一股脑拉全量。KV Cache存储设计必须配合这个分块粒度，比如按4KB到64KB的KV block做存储单元。
这里我额外提醒一句，计算KV Cache量时千万不要只算权重显存和KV Cache的静态和，还要留出20%-30%的临时计算缓冲（激活、中间结果、梯度），否则跑起来会频繁OOM。
3.3 部署时对IO Die与底层驱动的设置细节
IO Die这块的配置非常容易被忽视，但它直接影响KV Cache跨层访问的成功率。
第一件事是打开系统的PCIe/CXL枚举和内存池化支持。很多主板出厂默认把CXL设备当普通PCIe外设，不把它的内存纳入系统内存管理，导致你明明插了CXL内存条，系统却只当它是个不透明设备。需要到BIOS里开启“CXL Memory Device”和“Volatile Memory”相关选项，然后让OS重新识别NUMA拓扑。
第二件事是绑定NUMA和中断亲和性。KV Cache的SSD和CXL扩展设备要尽量挂在和GPU同一颗CPU的IO Die下，否则跨Socket访问会让延迟再翻一倍。我遇到过实测数据差0.5倍的案例，原因只是把SSD插到了离GPU较远的PCIe槽位。
第三件事是绕过操作系统页缓存。SSD上的KV Cache读取如果走传统文件系统，数据会被拷贝进页缓存再返回，多余的拷贝会白占内存和带宽。建议用带DMA的异步IO，或者GPU直接访问存储设备的方式。这套机制让存储数据能够直接落到GPU显存或特定内存地址，绕开CPU复制，整条数据通路能省下很多延迟。
4. 部署与排查：实测中的问题与避坑记录
4.1 典型故障速查表
KV Cache分级存储看着简单，实际踩坑案例比想象中多。我把最常见的几类问题整理成一张表。
| 现象 | 根因 | 解决方案 |
|---|---|---|
| KV Cache命中率骤降 | 分块/预取窗口设得太小 | 按序列活跃度动态调整预取长度 |
| GPU利用率从90%掉到30% | PCIe链路被大块搬运打满 | 缩小单次DMA粒度，增加异步队列深度 |
| CXL内存访问延迟忽高忽低 | NUMA远端访问路径不稳定 | 绑定CPU亲和性并开启CXL内存池化策略 |
| 系统内存被索引表挤爆 | 索引表放错层级 | 索引表优先放DRAM，必要时压缩位图索引 |
| 冷数据被反复换入换出 | SSD层淘汰策略失效 | 给SSD层单独配LRU并加最小驻留时间 |
这里面最值得多说一句的是SSD冷热抖动。KV Cache从SSD搬到HBM需要跨通道传输，如果刚做完一次搬迁，这个序列又被判定为冷数据换出去，来回折腾会同时消耗SSD寿命和PCIe带宽。所以SSD层一定要设置最小驻留时间，比如至少保留几分钟，避免短时间内的升降级震荡。
4.2 实测中得出的几个硬结论
第一个硬结论是：KV Cache的HBM命中率提升1个百分点，往往比把SSD带宽翻倍更有价值。因为从HBM访问和从SSD访问的延迟差了三个数量级，任何一个额外的百分点命中，都意味着大量请求不用走那条又慢又堵的跨设备通路。所以优化顺序一定是先调HBM驻留策略，再去看底层存储吞吐。
第二个硬结论是：KV Cache的地址映射和索引表必须跟数据体分离。我在做压测时曾经把索引表直接放在同一个SSD命名空间里，结果每读一次KV块都要先读一次索引，SSD的随机读延迟瞬间把系统拖垮。把索引搬到内存后，同样的KV Cache读取请求，平均时延直接降了一个数量级，这个改造几乎不花硬件成本，见效却极其明显。
第三个硬结论是：回写KV Cache要用合并写而不是逐条写。KV Cache是个持续追加式增长的数据，每条请求产生的KV块比较小，如果每次落盘都直接写，写放大系数会非常难看。你应该在内存里先做合并，凑到较大的写单元再整块下放SSD。
4.3 几个能帮你少走弯路的避坑技巧
我再补充几个实操性的细节。
第一，上线前压测不要用固定长度的序列。有些人图省事，所有测试请求都生成一模一样的上下文长度，结果KV Cache的命中率曲线完全失真。真实线上请求的长度和话题是高度倾斜的，测出来才准。
第二，给TVM或推理框架设置KV Cache驻留显存量上限。不要把显存看起来空着的部分全部分配给KV Cache，否则一旦某个请求突然变成超长上下文，显存瞬间被挤爆，调度器根本来不及把KV块搬出去。一般我会设置一个占比阈值，比如不超过可用显存的70%，剩下留给算子和激活量。
第三，GPU侧对KV Cache的跨设备访问一定要走批量采集。如果GPU想从SSD上取KV块，不要让每个线程各自发起一次DMA，那样IO Die会被随机小请求淹没。正确做法是把一批KV块的读取请求收集成一个大列表，一次DMA任务批量搬运。这一步做完，IO Die的吞吐会显著改善。
第四，留意SSD的温度和功耗策略。KV Cache密集读取时，SSD的发热量比普通业务高很多，如果散热不到位，SSD会触发降频，那时延迟会在几微秒到几十微秒之间频繁跳动，排查起来非常难受。企业级盘虽然稳，但散热环境依然要单独评估。
结尾
我在实际项目中压过不少推理系统，最深的一个体会是：算力堆上去之后，真正的瓶颈永远是数据怎么走。AMD收购MEXT这类动作背后的技术逻辑，本质是把KV Cache存储从“外设”变成推理流水线的核心部件，把SSD、CXL内存和IO Die全部串成一条为注意力计算服务的专用数据通路。如果你正在搭自己的推理服务，建议别急着无脑堆显存，先把你当前部署里KV Cache的命中率、跨层级跳变次数、IO Die的带宽占用这三份数据拿到手，往往改造存储层级比加购硬件便宜得多，效果却来得更直接。
