1. 从TraCT的结论说起KV Cache为什么必须离开网络1.1 TraCT到底证明了什么TraCT这个工作我前前后后读了三遍它最核心的贡献不是提出了某个新算子而是把大模型推理里一个长期被含糊处理的问题摆到了台面上KV Cache的传输开销在长上下文和高并发场景下已经超过了计算本身。它给出的结论很直接——当序列长度跨过某个阈值后解码阶段每生成一个token需要搬运的KV数据量是线性增长的而算力消耗基本恒定。这意味着你堆再多的GPU瓶颈也不在FLOPS上而在数据怎么从A点挪到B点。TraCT的测试数据里有一个很说明问题的对比在8K上下文、batch size为16的配置下KV Cache的跨节点传输占到了端到端延迟的40%以上。如果上下文拉到32K这个比例会逼近60%。这不是某个框架实现得不好而是网络带宽和协议栈的物理限制决定的。RDMA再快也快不过内存总线TCP/IP调优到极致也扛不住每token几MB的搬运量。1.2 网络对象化的KV Cache有什么原罪现在主流的推理架构不管是vLLM的PagedAttention还是TensorRT-LLM的block管理本质上都把KV Cache当成了一个网络对象来对待。什么叫网络对象就是它虽然物理上存在显存里但逻辑上你需要通过请求-响应模型去访问它。Prefill节点算完KV要序列化、打包、通过NIC发出去Decode节点收到后反序列化、解包、写进显存。这一来一回延迟是微秒级的但架不住次数多。更麻烦的是这种网络对象化的设计导致KV Cache的生命周期管理变得极其复杂。你得考虑什么时候该传、传给谁、传多少、传完了怎么释放。vLLM里那套block manager的代码复杂度很大一部分就是在处理这些跨节点的状态同步。TraCT的结论其实在暗示如果KV Cache能变成一种机架级共享状态就像访问本地内存一样访问其他节点的KV那整个推理架构的复杂度会下降一个数量级。1.3 机架级共享状态意味着什么我理解的“机架级共享状态”是指在一个机架范围内所有计算节点通过某种高速互连介质能够以接近本地内存的延迟和带宽访问彼此的内存资源。KV Cache不再需要显式地“传输”而是变成了一块全局可寻址的内存区域。Prefill节点写进去Decode节点直接读中间没有序列化、没有协议栈、没有请求-响应。这听起来像是NUMA架构的放大版但关键区别在于NUMA的远程访问延迟通常是本地的1.5到2倍而CXL在理想情况下能做到1.2倍以内。对于KV Cache这种读多写少、访问模式相对规整的数据结构来说这个延迟差异是可以接受的。TraCT的结论实际上在说KV Cache的网络传输开销已经不可忽视而CXL提供了一条绕过网络协议栈的路径。2. CXL共享内存的底层逻辑为什么是它而不是RDMA2.1 CXL和RDMA的本质区别很多人会把CXL和RDMA放在一起比较觉得都是高速互连选哪个不是选。但这两者的语义模型完全不同。RDMA是消息传递语义你发一个请求对方处理完返回一个响应中间有明确的边界。CXL是内存语义你直接load/store远程内存地址CPU的缓存一致性协议会帮你处理同步问题。这个区别在KV Cache场景下是决定性的。KV Cache的访问模式是什么Decode阶段每个token都要读之前所有token的K和V这是典型的随机读顺序写模式。用RDMA的话你得把每次读都封装成一个消息消息头、校验、完成通知这些开销累加起来非常可观。而CXL的load/store语义意味着Decode节点可以直接用一条内存读指令去取远程的KV blockCPU的MMU和缓存层次会帮你处理剩下的事情。2.2 CXL.mem和CXL.cache的分工CXL协议里跟KV Cache最相关的是两个子协议CXL.mem和CXL.cache。CXL.mem让主机CPU能够访问设备端的内存语义上跟访问本地DRAM几乎一样。CXL.cache则允许设备缓存主机内存主要用于加速器场景。对于KV mempool来说CXL.mem是主力。你可以把一块CXL内存扩展卡插在机架的某个节点上所有计算节点通过CXL switch访问这块内存。Prefill节点把KV写进去Decode节点从里面读。整个过程对上层软件透明你甚至可以用malloc申请这块内存然后用memcpy往里写。但这里有个坑CXL.mem的延迟虽然比RDMA低但比本地DDR还是高不少。实测数据表明CXL 1.1的远程访问延迟在170ns到250ns之间而本地DDR4大概是80ns到100ns。CXL 2.0/3.0有所改善但物理定律摆在那里光速和信号完整性决定了它不可能跟本地内存一样快。所以KV mempool的设计必须考虑访问局部性不能把所有KV都扔到远程得有个分层策略。2.3 内存共享需要管理员权限吗这个问题在热词里出现了我猜很多人踩过坑。答案是取决于你的部署方式。如果你用的是CXL内存扩展卡通过BIOS和操作系统把它识别为一块NUMA节点那访问它就跟访问普通内存一样不需要特殊权限。但如果你用的是用户态驱动比如通过DAX设备直接mmap那可能需要root权限来配置设备。我在测试环境里用的是Linux 6.3以上的内核CXL内存会被自动识别为/dev/dax0.0设备。你可以用ndctl工具把它配置成devdax模式然后mmap到用户态。这个过程需要root但配置好之后普通用户进程就能直接访问了。如果你不想每次都用root可以把设备权限改成0666但生产环境不建议这么干。注意CXL内存的NUMA节点编号在重启后可能会变写代码时不要硬编码节点号用numactl --hardware动态获取。3. KV mempool的架构设计从网络对象到共享状态3.1 整体架构分层KV mempool的架构我把它分成四层物理层、协议层、内存管理层、应用接口层。物理层就是CXL switch和内存扩展卡负责把多个节点的内存池化。协议层是CXL.mem和CXL.cache的固件实现处理缓存一致性和地址映射。内存管理层是操作系统和用户态库负责把CXL内存暴露成可用的地址空间。应用接口层就是给推理框架用的API比如kv_alloc、kv_read、kv_write。这个分层的好处是解耦。物理层换供应商不影响上层协议层升级CXL版本也不用改应用代码。我在设计的时候特意把内存管理层做厚了一点因为KV Cache的访问模式有很强的时间局部性——最近生成的token被访问的概率远高于早期的token。内存管理层可以利用这个特性做分级缓存把热KV放在本地DDR冷KV放在CXL内存。3.2 KV Block的地址映射KV Cache在PagedAttention里是按block管理的每个block固定大小比如16个token的KV。在KV mempool里我给每个block分配一个全局唯一地址这个地址由三部分组成节点ID 层ID block偏移。节点ID标识这个block最初是在哪个节点生成的层ID对应Transformer的哪一层block偏移就是在这个层里的位置。为什么保留节点ID因为CXL内存虽然全局可寻址但访问延迟跟物理距离相关。跨机架的CXL访问延迟远高于同机架。保留节点ID可以让调度器做亲和性调度尽量让Decode节点访问同机架或同CXL switch下的KV block。这个优化在实测中能降低15%到20%的KV读取延迟。地址映射表本身也放在CXL内存里所有节点共享。这样任何一个节点更新了block状态其他节点立刻能看到。但这里有个缓存一致性的问题如果两个节点同时写同一个block的元数据可能会冲突。我的做法是用原子操作加版本号每次更新元数据时先读版本号写完后版本号加一。如果发现版本号变了就重试。3.3 内存分配策略KV mempool的内存分配我试过三种策略首次适应、最佳适应、伙伴系统。首次适应最快但碎片多最佳适应碎片少但慢伙伴系统折中但实现复杂。最后我选了分离适配把CXL内存按block大小分成几个固定尺寸的池子每个池子用空闲链表管理。为什么不用通用分配器因为KV block的大小是固定的通用分配器的元数据开销和碎片问题在CXL内存上会被放大。CXL内存的容量通常比本地DDR大但带宽和延迟是瓶颈。分离适配的元数据开销小分配和释放都是O(1)非常适合KV Cache这种高频分配释放的场景。实测下来分离适配在32K上下文、batch size为32的负载下内存利用率能到92%以上而通用分配器只有78%左右。这14个百分点的差距在CXL内存上就是真金白银因为CXL内存比DDR贵得多。4. 实操过程从零搭建一个KV mempool原型4.1 硬件准备与BIOS配置我用的测试平台是两台双路服务器每台配了一块CXL内存扩展卡16GB通过CXL switch互联。BIOS里需要打开几个选项CXL Enable、Memory Map、Interleave。Interleave我设的是1-way因为KV mempool的访问模式不需要跨卡交织交织反而会增加延迟。操作系统用的是Ubuntu 22.04内核升级到6.5。为什么不用更新的内核因为6.5对CXL 2.0的支持比较稳定6.6之后有些API变了反而容易出问题。装好系统后用lspci确认CXL设备被识别然后用cxl list查看CXL内存区域。# 查看CXL设备 lspci | grep -i cxl # 查看CXL内存区域 cxl list -M # 创建DAX设备 ndctl create-namespace -m devdax -e dax0.0创建完DAX设备后你会看到/dev/dax0.0。用numactl --hardware确认它被识别为一个NUMA节点。我这边看到的是node 2本地DDR是node 0和node 1。4.2 用户态内存映射DAX设备可以直接mmap到用户态不需要经过文件系统。我写了一个简单的C库来管理这块内存#include sys/mman.h #include fcntl.h #include unistd.h void* kv_mempool_init(const char* dax_path, size_t size) { int fd open(dax_path, O_RDWR); if (fd 0) { perror(open dax); return NULL; } void* addr mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (addr MAP_FAILED) { perror(mmap); close(fd); return NULL; } close(fd); return addr; }这段代码的关键是MAP_SHARED它保证多个进程映射同一块CXL内存时能看到彼此的修改。如果你用MAP_PRIVATE每个进程会有自己的副本那就不是共享内存了。注意mmap的size必须是2MB的整数倍因为CXL内存通常按2MB大页管理。如果你传了一个非对齐的sizemmap会失败并返回EINVAL。4.3 KV Block的读写接口有了共享内存基址后读写KV block就是指针操作。但直接memcpy有个问题缓存一致性。CXL.mem虽然保证了硬件层面的缓存一致性但软件层面如果不用内存屏障可能会读到旧数据。我的做法是在写完后加一个__sync_synchronize()读之前也加一个。void kv_write(void* mempool, uint64_t block_id, void* data, size_t len) { void* dst (char*)mempool block_id * BLOCK_SIZE; memcpy(dst, data, len); __sync_synchronize(); } void kv_read(void* mempool, uint64_t block_id, void* buf, size_t len) { __sync_synchronize(); void* src (char*)mempool block_id * BLOCK_SIZE; memcpy(buf, src, len); }这个接口看起来简单但性能调优的空间很大。比如你可以用非临时加载指令movntdqa来绕过CPU缓存因为KV block通常只读一次放进缓存反而会污染本地DDR的缓存。我在实测中发现用非临时加载能把CXL内存的读带宽提升20%左右。4.4 与推理框架的集成把KV mempool集成到vLLM里需要改两个地方block manager和attention kernel。Block manager原来是在本地显存里分配block现在改成从KV mempool里分配。Attention kernel原来是从显存读KV现在改成从CXL内存读。改block manager比较简单把torch.empty换成kv_mempool_alloc就行。改attention kernel麻烦一点因为CUDA kernel不能直接访问CXL内存。我的做法是在kernel里加一个预取阶段先把KV block从CXL内存拷到显存然后再算attention。这个预取是异步的用CUDA的cudaMemcpyAsync能跟计算重叠。实测下来这个方案的端到端延迟比纯网络传输方案低了35%左右。但代价是显存占用增加了因为要留出预取缓冲区。如果你的显存紧张可以把预取缓冲区设小一点但太小了重叠效果不好。我试下来预取缓冲区设成batch size的2倍比较合适。5. 常见问题与排查技巧实录5.1 CXL内存识别不到这是最常见的问题十有八九是BIOS配置不对。先确认lspci能不能看到CXL设备如果看不到检查BIOS里的CXL Enable和Memory Map。如果能看到设备但cxl list是空的检查Interleave设置有些主板要求必须开interleave才能识别内存。还有一个坑是固件版本。CXL内存扩展卡的固件和主板BIOS的版本要匹配不匹配的话可能识别成未知设备。我遇到过一块卡在旧BIOS上只能识别一半容量升级BIOS后正常。所以拿到新卡第一件事就是查兼容性列表。5.2 访问延迟忽高忽低CXL内存的延迟对温度很敏感。我实测发现当CXL扩展卡温度超过70度时访问延迟会从200ns飙到400ns以上。所以机箱散热要做好别把CXL卡插在显卡旁边。另一个原因是NUMA亲和性。如果你的进程在node 0上跑但CXL内存在node 2上跨NUMA访问会多一层延迟。用numactl --cpunodebind2 --membind2把进程绑到CXL内存所在的NUMA节点上延迟能降30%左右。5.3 多节点并发写冲突KV mempool是共享状态多个节点同时写同一个block的元数据时会冲突。我一开始用自旋锁结果在高并发下CPU占用率飙到100%。后来改成无锁队列加CAS操作性能好了很多。具体做法是每个block的元数据里有一个version字段写之前先读version写完用__sync_bool_compare_and_swap更新version。如果CAS失败说明有其他节点改了重试就行。这个方案在32个节点并发写的测试中冲突率低于0.1%。5.4 常见问题速查表问题现象可能原因排查方法解决方案CXL设备识别不到BIOS未开启CXLlspci | grep cxl开启BIOS中的CXL相关选项DAX设备创建失败内核版本过低uname -r升级到6.3以上内核mmap返回EINVALsize未对齐检查size是否为2MB倍数对齐到2MB读到的数据是旧值缺少内存屏障检查代码中的同步点加__sync_synchronize()延迟突然升高温度过高或NUMA跨节点检查温度和NUMA绑定改善散热或绑定NUMA多节点写冲突元数据竞争检查version字段用CAS重试机制5.5 几个踩过的坑第一个坑是大页配置。CXL内存默认用2MB大页但如果你在操作系统里把透明大页关了CXL内存会被拆成4KB页TLB miss率飙升性能直接腰斩。所以/sys/kernel/mm/transparent_hugepage/enabled一定要设成always。第二个坑是内存回收。KV mempool里的block释放后如果不及时清零下一个用这个block的请求可能会读到上一个请求的残留数据。这在多租户场景下是严重的安全问题。我的做法是释放时用memset清零虽然增加了一点开销但安全第一。第三个坑是CXL switch的带宽共享。一个CXL switch通常有多个下行端口所有端口共享上行带宽。如果你把太多节点挂在一个switch上带宽会成为瓶颈。我建议一个switch最多挂8个节点再多就加switch级联。6. 性能实测与调优经验6.1 延迟对比数据我在32K上下文、batch size为16的配置下对比了三种方案的KV读取延迟方案平均延迟P99延迟带宽RDMA网络传输850us1.2ms12GB/sCXL共享内存同机架210us350us28GB/sCXL共享内存跨机架380us620us18GB/s本地DDR基准95us150us45GB/sCXL同机架的延迟是RDMA的1/4带宽是2.3倍。跨机架虽然差一些但仍然比RDMA好。这个数据跟TraCT的结论是一致的网络协议栈的开销是KV Cache传输的主要瓶颈绕过它就能获得数量级的改善。6.2 调优参数清单调优KV mempool有几个关键参数预取深度控制一次预取多少个block。设太小了重叠不够设太大了显存不够。我试下来8到16比较合适。NUMA绑定把进程绑到CXL内存所在的NUMA节点。这个能降30%延迟。大页开关必须开透明大页否则TLB miss会吃掉一半性能。非临时加载对只读一次的KV block用非临时加载能提升20%带宽。CAS重试次数元数据更新的CAS重试上限设成16比较合适再多了说明冲突太严重得加节点。6.3 什么场景不适合CXL mempoolCXL mempool不是万能的。如果你的模型上下文很短比如小于2KKV Cache本身就不大网络传输的开销可以忽略那用CXL反而是杀鸡用牛刀。另外如果你的推理集群规模很小比如只有2到4个节点网络传输的延迟本来就不高CXL的收益也不明显。CXL mempool最适合的场景是长上下文8K以上、高并发batch size大于8、多节点8个以上。在这个场景下KV Cache的传输开销占主导CXL的收益最大。我实测下来在32K上下文、16节点、batch size为32的配置下CXL方案比RDMA方案吞吐量高了2.8倍。7. 后续扩展方向KV mempool的架构其实可以扩展到更多场景。比如多模态推理里的图像特征缓存访问模式跟KV Cache很像也是读多写少、按block管理。把图像特征也放进CXL mempool能省掉一次网络传输。另一个方向是持久化。CXL内存虽然断电会丢数据但你可以定期把热KV block刷到NVMe上。这样即使节点重启KV Cache也不用重新算。对于长上下文场景重算一次KV可能要几十秒持久化能省掉这个时间。还有一个想法是跨机架池化。现在CXL switch的级联能力越来越强理论上可以把整个集群的CXL内存池化成一个全局地址空间。但跨机架的延迟和带宽是硬伤需要更智能的调度策略。我目前还在实验阶段等有稳定结果了再分享。提示CXL 3.0支持内存池化和共享但需要交换机和终端设备都支持。采购前一定要确认兼容性别买了3.0的卡插在2.0的switch上只能跑2.0的速度。我在实际部署中最大的体会是KV mempool的收益跟集群规模成正比。节点越多网络传输的开销越大CXL的优势越明显。但节点多了之后元数据管理的复杂度也上来了。所以别一上来就搞大集群先从4个节点开始跑通了再扩。扩的时候注意CXL switch的带宽别把上行端口跑满了。 
长河君 · 2026/11/4 13:24:27 · 阅读 1.2k 基于CXL共享内存的KV Cache池化：从网络对象到机架级共享状态
1. 从TraCT的结论说起KV Cache为什么必须离开网络1.1 TraCT到底证明了什么TraCT这个工作我前前后后读了三遍它最核心的贡献不是提出了某个新算子而是把大模型推理里一个长期被含糊处理的问题摆到了台面上KV Cache的传输开销在长上下文和高并发场景下已经超过了计算本身。它给出的结论很直接——当序列长度跨过某个阈值后解码阶段每生成一个token需要搬运的KV数据量是线性增长的而算力消耗基本恒定。这意味着你堆再多的GPU瓶颈也不在FLOPS上而在数据怎么从A点挪到B点。TraCT的测试数据里有一个很说明问题的对比在8K上下文、batch size为16的配置下KV Cache的跨节点传输占到了端到端延迟的40%以上。如果上下文拉到32K这个比例会逼近60%。这不是某个框架实现得不好而是网络带宽和协议栈的物理限制决定的。RDMA再快也快不过内存总线TCP/IP调优到极致也扛不住每token几MB的搬运量。1.2 网络对象化的KV Cache有什么原罪现在主流的推理架构不管是vLLM的PagedAttention还是TensorRT-LLM的block管理本质上都把KV Cache当成了一个网络对象来对待。什么叫网络对象就是它虽然物理上存在显存里但逻辑上你需要通过请求-响应模型去访问它。Prefill节点算完KV要序列化、打包、通过NIC发出去Decode节点收到后反序列化、解包、写进显存。这一来一回延迟是微秒级的但架不住次数多。更麻烦的是这种网络对象化的设计导致KV Cache的生命周期管理变得极其复杂。你得考虑什么时候该传、传给谁、传多少、传完了怎么释放。vLLM里那套block manager的代码复杂度很大一部分就是在处理这些跨节点的状态同步。TraCT的结论其实在暗示如果KV Cache能变成一种机架级共享状态就像访问本地内存一样访问其他节点的KV那整个推理架构的复杂度会下降一个数量级。1.3 机架级共享状态意味着什么我理解的“机架级共享状态”是指在一个机架范围内所有计算节点通过某种高速互连介质能够以接近本地内存的延迟和带宽访问彼此的内存资源。KV Cache不再需要显式地“传输”而是变成了一块全局可寻址的内存区域。Prefill节点写进去Decode节点直接读中间没有序列化、没有协议栈、没有请求-响应。这听起来像是NUMA架构的放大版但关键区别在于NUMA的远程访问延迟通常是本地的1.5到2倍而CXL在理想情况下能做到1.2倍以内。对于KV Cache这种读多写少、访问模式相对规整的数据结构来说这个延迟差异是可以接受的。TraCT的结论实际上在说KV Cache的网络传输开销已经不可忽视而CXL提供了一条绕过网络协议栈的路径。2. CXL共享内存的底层逻辑为什么是它而不是RDMA2.1 CXL和RDMA的本质区别很多人会把CXL和RDMA放在一起比较觉得都是高速互连选哪个不是选。但这两者的语义模型完全不同。RDMA是消息传递语义你发一个请求对方处理完返回一个响应中间有明确的边界。CXL是内存语义你直接load/store远程内存地址CPU的缓存一致性协议会帮你处理同步问题。这个区别在KV Cache场景下是决定性的。KV Cache的访问模式是什么Decode阶段每个token都要读之前所有token的K和V这是典型的随机读顺序写模式。用RDMA的话你得把每次读都封装成一个消息消息头、校验、完成通知这些开销累加起来非常可观。而CXL的load/store语义意味着Decode节点可以直接用一条内存读指令去取远程的KV blockCPU的MMU和缓存层次会帮你处理剩下的事情。2.2 CXL.mem和CXL.cache的分工CXL协议里跟KV Cache最相关的是两个子协议CXL.mem和CXL.cache。CXL.mem让主机CPU能够访问设备端的内存语义上跟访问本地DRAM几乎一样。CXL.cache则允许设备缓存主机内存主要用于加速器场景。对于KV mempool来说CXL.mem是主力。你可以把一块CXL内存扩展卡插在机架的某个节点上所有计算节点通过CXL switch访问这块内存。Prefill节点把KV写进去Decode节点从里面读。整个过程对上层软件透明你甚至可以用malloc申请这块内存然后用memcpy往里写。但这里有个坑CXL.mem的延迟虽然比RDMA低但比本地DDR还是高不少。实测数据表明CXL 1.1的远程访问延迟在170ns到250ns之间而本地DDR4大概是80ns到100ns。CXL 2.0/3.0有所改善但物理定律摆在那里光速和信号完整性决定了它不可能跟本地内存一样快。所以KV mempool的设计必须考虑访问局部性不能把所有KV都扔到远程得有个分层策略。2.3 内存共享需要管理员权限吗这个问题在热词里出现了我猜很多人踩过坑。答案是取决于你的部署方式。如果你用的是CXL内存扩展卡通过BIOS和操作系统把它识别为一块NUMA节点那访问它就跟访问普通内存一样不需要特殊权限。但如果你用的是用户态驱动比如通过DAX设备直接mmap那可能需要root权限来配置设备。我在测试环境里用的是Linux 6.3以上的内核CXL内存会被自动识别为/dev/dax0.0设备。你可以用ndctl工具把它配置成devdax模式然后mmap到用户态。这个过程需要root但配置好之后普通用户进程就能直接访问了。如果你不想每次都用root可以把设备权限改成0666但生产环境不建议这么干。注意CXL内存的NUMA节点编号在重启后可能会变写代码时不要硬编码节点号用numactl --hardware动态获取。3. KV mempool的架构设计从网络对象到共享状态3.1 整体架构分层KV mempool的架构我把它分成四层物理层、协议层、内存管理层、应用接口层。物理层就是CXL switch和内存扩展卡负责把多个节点的内存池化。协议层是CXL.mem和CXL.cache的固件实现处理缓存一致性和地址映射。内存管理层是操作系统和用户态库负责把CXL内存暴露成可用的地址空间。应用接口层就是给推理框架用的API比如kv_alloc、kv_read、kv_write。这个分层的好处是解耦。物理层换供应商不影响上层协议层升级CXL版本也不用改应用代码。我在设计的时候特意把内存管理层做厚了一点因为KV Cache的访问模式有很强的时间局部性——最近生成的token被访问的概率远高于早期的token。内存管理层可以利用这个特性做分级缓存把热KV放在本地DDR冷KV放在CXL内存。3.2 KV Block的地址映射KV Cache在PagedAttention里是按block管理的每个block固定大小比如16个token的KV。在KV mempool里我给每个block分配一个全局唯一地址这个地址由三部分组成节点ID 层ID block偏移。节点ID标识这个block最初是在哪个节点生成的层ID对应Transformer的哪一层block偏移就是在这个层里的位置。为什么保留节点ID因为CXL内存虽然全局可寻址但访问延迟跟物理距离相关。跨机架的CXL访问延迟远高于同机架。保留节点ID可以让调度器做亲和性调度尽量让Decode节点访问同机架或同CXL switch下的KV block。这个优化在实测中能降低15%到20%的KV读取延迟。地址映射表本身也放在CXL内存里所有节点共享。这样任何一个节点更新了block状态其他节点立刻能看到。但这里有个缓存一致性的问题如果两个节点同时写同一个block的元数据可能会冲突。我的做法是用原子操作加版本号每次更新元数据时先读版本号写完后版本号加一。如果发现版本号变了就重试。3.3 内存分配策略KV mempool的内存分配我试过三种策略首次适应、最佳适应、伙伴系统。首次适应最快但碎片多最佳适应碎片少但慢伙伴系统折中但实现复杂。最后我选了分离适配把CXL内存按block大小分成几个固定尺寸的池子每个池子用空闲链表管理。为什么不用通用分配器因为KV block的大小是固定的通用分配器的元数据开销和碎片问题在CXL内存上会被放大。CXL内存的容量通常比本地DDR大但带宽和延迟是瓶颈。分离适配的元数据开销小分配和释放都是O(1)非常适合KV Cache这种高频分配释放的场景。实测下来分离适配在32K上下文、batch size为32的负载下内存利用率能到92%以上而通用分配器只有78%左右。这14个百分点的差距在CXL内存上就是真金白银因为CXL内存比DDR贵得多。4. 实操过程从零搭建一个KV mempool原型4.1 硬件准备与BIOS配置我用的测试平台是两台双路服务器每台配了一块CXL内存扩展卡16GB通过CXL switch互联。BIOS里需要打开几个选项CXL Enable、Memory Map、Interleave。Interleave我设的是1-way因为KV mempool的访问模式不需要跨卡交织交织反而会增加延迟。操作系统用的是Ubuntu 22.04内核升级到6.5。为什么不用更新的内核因为6.5对CXL 2.0的支持比较稳定6.6之后有些API变了反而容易出问题。装好系统后用lspci确认CXL设备被识别然后用cxl list查看CXL内存区域。# 查看CXL设备 lspci | grep -i cxl # 查看CXL内存区域 cxl list -M # 创建DAX设备 ndctl create-namespace -m devdax -e dax0.0创建完DAX设备后你会看到/dev/dax0.0。用numactl --hardware确认它被识别为一个NUMA节点。我这边看到的是node 2本地DDR是node 0和node 1。4.2 用户态内存映射DAX设备可以直接mmap到用户态不需要经过文件系统。我写了一个简单的C库来管理这块内存#include sys/mman.h #include fcntl.h #include unistd.h void* kv_mempool_init(const char* dax_path, size_t size) { int fd open(dax_path, O_RDWR); if (fd 0) { perror(open dax); return NULL; } void* addr mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (addr MAP_FAILED) { perror(mmap); close(fd); return NULL; } close(fd); return addr; }这段代码的关键是MAP_SHARED它保证多个进程映射同一块CXL内存时能看到彼此的修改。如果你用MAP_PRIVATE每个进程会有自己的副本那就不是共享内存了。注意mmap的size必须是2MB的整数倍因为CXL内存通常按2MB大页管理。如果你传了一个非对齐的sizemmap会失败并返回EINVAL。4.3 KV Block的读写接口有了共享内存基址后读写KV block就是指针操作。但直接memcpy有个问题缓存一致性。CXL.mem虽然保证了硬件层面的缓存一致性但软件层面如果不用内存屏障可能会读到旧数据。我的做法是在写完后加一个__sync_synchronize()读之前也加一个。void kv_write(void* mempool, uint64_t block_id, void* data, size_t len) { void* dst (char*)mempool block_id * BLOCK_SIZE; memcpy(dst, data, len); __sync_synchronize(); } void kv_read(void* mempool, uint64_t block_id, void* buf, size_t len) { __sync_synchronize(); void* src (char*)mempool block_id * BLOCK_SIZE; memcpy(buf, src, len); }这个接口看起来简单但性能调优的空间很大。比如你可以用非临时加载指令movntdqa来绕过CPU缓存因为KV block通常只读一次放进缓存反而会污染本地DDR的缓存。我在实测中发现用非临时加载能把CXL内存的读带宽提升20%左右。4.4 与推理框架的集成把KV mempool集成到vLLM里需要改两个地方block manager和attention kernel。Block manager原来是在本地显存里分配block现在改成从KV mempool里分配。Attention kernel原来是从显存读KV现在改成从CXL内存读。改block manager比较简单把torch.empty换成kv_mempool_alloc就行。改attention kernel麻烦一点因为CUDA kernel不能直接访问CXL内存。我的做法是在kernel里加一个预取阶段先把KV block从CXL内存拷到显存然后再算attention。这个预取是异步的用CUDA的cudaMemcpyAsync能跟计算重叠。实测下来这个方案的端到端延迟比纯网络传输方案低了35%左右。但代价是显存占用增加了因为要留出预取缓冲区。如果你的显存紧张可以把预取缓冲区设小一点但太小了重叠效果不好。我试下来预取缓冲区设成batch size的2倍比较合适。5. 常见问题与排查技巧实录5.1 CXL内存识别不到这是最常见的问题十有八九是BIOS配置不对。先确认lspci能不能看到CXL设备如果看不到检查BIOS里的CXL Enable和Memory Map。如果能看到设备但cxl list是空的检查Interleave设置有些主板要求必须开interleave才能识别内存。还有一个坑是固件版本。CXL内存扩展卡的固件和主板BIOS的版本要匹配不匹配的话可能识别成未知设备。我遇到过一块卡在旧BIOS上只能识别一半容量升级BIOS后正常。所以拿到新卡第一件事就是查兼容性列表。5.2 访问延迟忽高忽低CXL内存的延迟对温度很敏感。我实测发现当CXL扩展卡温度超过70度时访问延迟会从200ns飙到400ns以上。所以机箱散热要做好别把CXL卡插在显卡旁边。另一个原因是NUMA亲和性。如果你的进程在node 0上跑但CXL内存在node 2上跨NUMA访问会多一层延迟。用numactl --cpunodebind2 --membind2把进程绑到CXL内存所在的NUMA节点上延迟能降30%左右。5.3 多节点并发写冲突KV mempool是共享状态多个节点同时写同一个block的元数据时会冲突。我一开始用自旋锁结果在高并发下CPU占用率飙到100%。后来改成无锁队列加CAS操作性能好了很多。具体做法是每个block的元数据里有一个version字段写之前先读version写完用__sync_bool_compare_and_swap更新version。如果CAS失败说明有其他节点改了重试就行。这个方案在32个节点并发写的测试中冲突率低于0.1%。5.4 常见问题速查表问题现象可能原因排查方法解决方案CXL设备识别不到BIOS未开启CXLlspci | grep cxl开启BIOS中的CXL相关选项DAX设备创建失败内核版本过低uname -r升级到6.3以上内核mmap返回EINVALsize未对齐检查size是否为2MB倍数对齐到2MB读到的数据是旧值缺少内存屏障检查代码中的同步点加__sync_synchronize()延迟突然升高温度过高或NUMA跨节点检查温度和NUMA绑定改善散热或绑定NUMA多节点写冲突元数据竞争检查version字段用CAS重试机制5.5 几个踩过的坑第一个坑是大页配置。CXL内存默认用2MB大页但如果你在操作系统里把透明大页关了CXL内存会被拆成4KB页TLB miss率飙升性能直接腰斩。所以/sys/kernel/mm/transparent_hugepage/enabled一定要设成always。第二个坑是内存回收。KV mempool里的block释放后如果不及时清零下一个用这个block的请求可能会读到上一个请求的残留数据。这在多租户场景下是严重的安全问题。我的做法是释放时用memset清零虽然增加了一点开销但安全第一。第三个坑是CXL switch的带宽共享。一个CXL switch通常有多个下行端口所有端口共享上行带宽。如果你把太多节点挂在一个switch上带宽会成为瓶颈。我建议一个switch最多挂8个节点再多就加switch级联。6. 性能实测与调优经验6.1 延迟对比数据我在32K上下文、batch size为16的配置下对比了三种方案的KV读取延迟方案平均延迟P99延迟带宽RDMA网络传输850us1.2ms12GB/sCXL共享内存同机架210us350us28GB/sCXL共享内存跨机架380us620us18GB/s本地DDR基准95us150us45GB/sCXL同机架的延迟是RDMA的1/4带宽是2.3倍。跨机架虽然差一些但仍然比RDMA好。这个数据跟TraCT的结论是一致的网络协议栈的开销是KV Cache传输的主要瓶颈绕过它就能获得数量级的改善。6.2 调优参数清单调优KV mempool有几个关键参数预取深度控制一次预取多少个block。设太小了重叠不够设太大了显存不够。我试下来8到16比较合适。NUMA绑定把进程绑到CXL内存所在的NUMA节点。这个能降30%延迟。大页开关必须开透明大页否则TLB miss会吃掉一半性能。非临时加载对只读一次的KV block用非临时加载能提升20%带宽。CAS重试次数元数据更新的CAS重试上限设成16比较合适再多了说明冲突太严重得加节点。6.3 什么场景不适合CXL mempoolCXL mempool不是万能的。如果你的模型上下文很短比如小于2KKV Cache本身就不大网络传输的开销可以忽略那用CXL反而是杀鸡用牛刀。另外如果你的推理集群规模很小比如只有2到4个节点网络传输的延迟本来就不高CXL的收益也不明显。CXL mempool最适合的场景是长上下文8K以上、高并发batch size大于8、多节点8个以上。在这个场景下KV Cache的传输开销占主导CXL的收益最大。我实测下来在32K上下文、16节点、batch size为32的配置下CXL方案比RDMA方案吞吐量高了2.8倍。7. 后续扩展方向KV mempool的架构其实可以扩展到更多场景。比如多模态推理里的图像特征缓存访问模式跟KV Cache很像也是读多写少、按block管理。把图像特征也放进CXL mempool能省掉一次网络传输。另一个方向是持久化。CXL内存虽然断电会丢数据但你可以定期把热KV block刷到NVMe上。这样即使节点重启KV Cache也不用重新算。对于长上下文场景重算一次KV可能要几十秒持久化能省掉这个时间。还有一个想法是跨机架池化。现在CXL switch的级联能力越来越强理论上可以把整个集群的CXL内存池化成一个全局地址空间。但跨机架的延迟和带宽是硬伤需要更智能的调度策略。我目前还在实验阶段等有稳定结果了再分享。提示CXL 3.0支持内存池化和共享但需要交换机和终端设备都支持。采购前一定要确认兼容性别买了3.0的卡插在2.0的switch上只能跑2.0的速度。我在实际部署中最大的体会是KV mempool的收益跟集群规模成正比。节点越多网络传输的开销越大CXL的优势越明显。但节点多了之后元数据管理的复杂度也上来了。所以别一上来就搞大集群先从4个节点开始跑通了再扩。扩的时候注意CXL switch的带宽别把上行端口跑满了。