TraCT: Disaggregated LLM Serving with CXL Shared Memory KV Cache at Rack-Scale
发表时间: 2025-12 · arXiv:2512.18194 (preprint)
原文: https://arxiv.org/abs/2512.18194
作者/机构: Dongha Yoon (Virginia Tech), Younghoon Min (SK Hynix America), Hoshik Kim (SK Hynix America), Sam H. Noh (Virginia Tech), Jongryool Kim (SK Hynix America)
速读
一句话结论
TraCT 提出了一个基于 CXL 共享内存的机架级大语言模型推理系统，通过让 GPU 直接跨节点读写 KV Cache，彻底消除了分离式推理中的网络传输开销，在真实负载下将首字延迟降低了最多 9.8 倍，吞吐量提升了 1.6 倍。
要解决什么问题
当前的大语言模型服务通常采用分离式架构，将计算密集的 Prefill（预填充）阶段和对延迟敏感的 Decode（解码）阶段分配给不同的工作节点，以此提升资源利用率。这种架构引入了一个核心卡点：Prefill 节点生成的 KV 张量必须传输给 Decode 节点。现有的系统均依赖 RDMA 等网络协议栈进行跨节点交换。这意味着每一次 KV 数据的流转，都需要经过发送端主机内存、网卡队列、网络传输、接收端网卡和接收端主机内存。即使引入了全局前缀缓存（如 LMCache 或 Mooncake），缓存命中的 KV 块依然逃不掉这趟网络之旅。随着模型参数和上下文长度的增加，每次请求动辄产生数百兆字节的 KV 数据，这种跨网卡的序列化开销、额外的内存拷贝以及网络拥塞，不仅严重拖慢了首字延迟，导致长尾延迟极不稳定，也成为了限制整个系统吞吐量上限的物理瓶颈。
怎么做的
TraCT 的核心思路是将 CXL（Compute Express Link）Type-3 设备的共享内存池同时作为无网络的 KV 传输介质和机架级的全局前缀缓存。Prefill 节点生成未命中的 KV 块后，直接通过 GPU-CXL DMA 写入共享内存；Decode 节点则通过 DMA 直接从共享内存拉取到本地 GPU，全程绕过 CPU 网络栈和网卡。为了实现真正的零拷贝，TraCT 利用 CUDA 的主机内存注册接口将整个 CXL 内存区域锁定，防止驱动程序在主机 DRAM 中分配中间反弹缓冲区。为了在缺乏跨节点硬件原子操作和全局缓存一致性的 CXL 硬件上实现这一机制，TraCT 设计了三个关键部件。第一是双层软件同步锁：节点内进程先竞争本地 DRAM 锁，获胜者再去轮询 CXL 内存中的全局锁槽位，由一个后台锁管理器统一仲裁，从而将跨节点竞争的参与者数量严格限制在节点数以内。第二是基于偏移量的共享内存分配器：由于不同节点的虚拟地址基址不同，TraCT 摒弃了绝对指针，所有共享数据结构均采用偏移量寻址：
第三是非一致性内存下的可见性管理：由于 GPU-CXL DMA 直接绕过 CPU 缓存，大容量的 KV 负载本身不需要刷新；但对于前缀树索引等元数据，TraCT 采用细粒度的 clflush 指令强制将修改后的缓存行刷入 CXL 设备。为了避免复杂的树形结构引发高频的元数据更新和锁竞争，TraCT 采用固定大小的哈希表结合线性探查来管理前缀缓存，利用当前块的 Token 集合 $T_i$ 和前驱块哈希 $h_{i-1}$ 迭代计算块哈希：
clflush，以此作为数据全局可见的屏障。
效果如何
实验基于两台服务器搭建，配备 NVIDIA A6000 GPU、100Gbps 网卡和 64GB 的 Niagara 2.0 CXL Type-3 内存扩展器，运行 DeepSeek-R1-Distill-Llama-8B 模型。对比基线有两个：NIXL/UCX（代表无缓存的纯 RDMA 网络传输路线）和 LMCache（代表基于主机 DRAM 和网络传输的全局 KV 缓存路线）。在输入长度达 6000 Token 的静态负载下，TraCT 证明了纯 CXL 传输的延迟远低于 RDMA。在基于真实请求分布的合成负载测试中，TraCT 在 3.0 QPS 的压力下，相比 LMCache 将峰值吞吐量提升了 1.6 倍；平均首字延迟降低了最多 9.8 倍，P99 长尾延迟降低了 6.2 倍，同时显著降低了 GPU 的功耗和显存占用时间。该方法的代价在于，为了保证元数据更新的绝对正确性，必须使用同步的 clflush 而非开销更小的异步 clflushopt 指令；同时，为了避免跨 CPU 插槽的延迟惩罚，系统必须将所有工作线程严格绑定在直连 CXL 设备的 NUMA 节点上；此外，受限于元数据更新的同步开销，系统目前只能采用最简单的 LRU 淘汰策略，无法轻易引入更复杂的缓存替换算法。
主要贡献
现代大型语言模型（LLMs）服务系统正越来越多地采用分离式架构，将计算密集的Prefill（预填充）阶段与对延迟敏感的Decode（解码）阶段分离开来，以此提高资源利用率和吞吐量。然而，这种架构引入了一个核心瓶颈：在Prefill阶段生成的Key/Value (KV) 张量必须传输给Decode worker。现有的系统绝大多数依赖基于RDMA的网络路径来进行这种数据交换。随着模型规模和上下文长度的增加，每次请求交换的KV数据量高达数百兆字节，使得KV传输成为影响请求延迟和系统峰值吞吐量的主要因素。即使在使用前缀缓存复用技术时，现有的系统依然需要通过网卡队列、主机DRAM缓冲区以及复杂的传输层协议来搬运KV块，这种网络跳数（NIC hop）显著增加了Prefill延迟并限制了整体性能。
为了解决这一核心问题，本文提出了TraCT，这是一个机架级（rack-scale）的LLM服务系统。TraCT的研究目标是利用Compute Express Link (CXL) 共享内存既作为无网络的KV传输介质，又作为机架级的前缀感知KV缓存。其核心创新点包括：
1. 网络无感知的KV传输与复用：TraCT允许GPU通过CXL的load/store和直接内存访问（DMA）操作，直接读写KV块，彻底消除了限制现有分离式流水线的网卡跳数。
2. 针对非一致性CXL内存的软件同步机制：当前CXL设备不提供跨节点的硬件原子操作，也不保证全设备的硬件缓存一致性。TraCT创新性地提出了一种两层（two-tier）节点间软件锁同步机制，用以在无硬件原子操作的情况下保证互斥。
3. 细粒度可见性与共享对象管理：为了在非一致性共享内存上保证元数据和数据的正确可见性，TraCT引入了细粒度的缓存行刷新策略，并设计了专为跨节点共享定制的内存分配器和基于偏移量的紧凑对象存储。
背景知识与设计原则
CXL共享内存基础与挑战。Compute Express Link (CXL) 【1，CXL specification+URL: https://computeexpresslink.org/cxl-specification/ 】 建立在PCIe之上，在CPU和设备之间提供高带宽、低延迟的通信。特别是CXL Type-3设备，通过CXL.mem协议提供主机可访问的内存。在当前系统中，CXL Type-3设备通常作为一个支持DAX的内存区域暴露出来，可以映射到用户空间作为字节寻址内存。从单节点软件的角度来看，它的行为类似于本地DRAM，支持正常的load/store和DMA读写。然而，当多个主机连接到同一个CXL设备时，硬件并不会自动在主机间保持缓存一致性。近期的研究表明，即使存在一致性，也仅限于特定设备的小区域，无法扩展到设备的全部容量 【8，Tigon: a distributed database for a cxl pod+2025+OSDI】，【9，Memory sharing with cxl: Hardware and software design approaches+2024】。因此，将CXL用作共享内存池的应用程序必须显式地管理跨节点的同步和数据可见性 【8，Tigon: a distributed database for a cxl pod+2025+OSDI】，【21，Partial failure resilient memory management system for (cxl-based) distributed shared memory+2023+SOSP】。CXL为机架级系统提供了无网络栈的内存通信语义，但缺乏跨节点原子操作和全设备一致性，这要求软件必须仔细处理缓存行状态、刷新和排序。
LLM推理的两阶段特性与KV缓存。现代LLM（如GPT、Gemini和Llama 【7，Gemini 2.5: Pushing the frontier with advanced reasoning, multimodality, long context, and next generation agentic capabilities+2025】，【11，The llama 3 herd of models+2024】，【12，Chatgpt (gpt-5)+URL: https://openai.com/chatgpt】）是仅解码器（decoder-only）的Transformer，自回归地生成token。推理分为Prefill和Decode两个阶段。在Prefill期间，长度为$N$的完整输入提示在一次前向传播中被处理，计算$O(N^2)$的注意力交互，此阶段是计算密集型的。模型生成第一个输出token以及$N$个K/V张量，形成初始KV缓存。在Decode阶段，模型逐个生成token，在步骤$t$时，模型仅计算新token的Q/K/V向量，并与之前存储在KV缓存中的$N+t-1$个张量进行注意力计算，此阶段转变为内存受限。为了避免重计算，系统缓存每一层的中间K和V张量。对于大模型，KV缓存占据了极大的内存（例 如Llama3 405B每token需$504\mathrm{KB}$）。
KV管理与分离式架构的耦合。在单节点内，系统如vLLM通过操作系统分页机制解决GPU内存碎片化，SGLang引入RadixAttention实现前缀共享 【10，Efficient memory management for large language model serving with pagedattention+2023+SOSP】，【22，Sglang: efficient execution of structured language model programs+2025+NIPS】。在多节点分离式架构中（如Splitwise、DistServe、Preble和Dynamo 【3，NVIDIA Dynamo+URL: https://github.com/ai-dynamo/dynamo】，【13 ，Splitwise: Efficient generative llm inference using phase splitting+2024+ISCA】，【17，Preble: Efficient distributed prompt scheduling for LLM serving+2025+ICLR】，【23，Distserve: disaggregating prefill and decoding for goodputoptimized large language model serving+2024+OSDI】），Prefill和Decode被拆分到不同worker，这改善了资源扩展，但每次请求都依赖RDMA等网络路径将KV块从Prefill传输到Decode worker。即使LMCache 【6，Lmcache: An efficient kv cache layer for enterprise-scale llm inference+2025】 和Mooncake 【14，Mooncake: Trading more storage for less computation — a KVCache-centric architecture for serving LLM chatbot+2025+FAST】 支持跨节点KV复用，它们依然保留了基于网络的KV张量移动。TraCT探索使用CXL共享内存直接作为机架级KV缓存和传输层，消除网络跳数。
TraCT的设计目标与挑战。TraCT旨在实现三个目标：1. 无网络的KV传输，用GPU与CXL间的直接DMA替代RDMA；2. 机架级KV复用，将KV块及前缀缓存元数据直接存入CXL共享内存；3. 去中心化KV管理，避免集中式元数据服务器，worker通过load/store直接管理状态。实现这些目标面临三大挑战：首先，必须在没有硬件原子操作和全局一致性的情况下确保共享内存区域的互斥访问。现有方法要么依赖极小的硬件一致性区域，要么使用消耗$O(N^2)$内存的队列（如cMPI 【18，cmpi: Using cxl memory sharing for mpi one-sided and two-sided inter-node communications+2025+SC】），或者引入违背CXL初衷的集中式服务器（如Beluga 【19，Beluga: A cxlbased memory architecture for scalable and efficient llm kvcache management+2025】）。其次，在缺乏硬件缓存一致性的情况下，必须处理缓存刷新以保证数据可见性。最后，需要一种不依赖进程私有虚拟地址指针的共享对象管理机制。
方法细节
TraCT架构概览。在TraCT架构中，每个机架包含多个Prefill和Decoding worker，它们均连接到一个共享的CXL Type-3设备。TraCT将该CXL设备暴露为所有参与服务器上支持DAX映射的字节寻址区域。TraCT底层库提供三个原语：节点间锁、内存分配器和对象存储。基于该库，TraCT实现了前缀缓存索引和GPU-CXL KV块传输模块。当LLM请求到达时，Prefill worker首先查找前缀缓存，若命中则执行CXL到GPU的KV块传输；随后计算缺失的KV块，将前缀缓存条目发布并将缺失的KV块通过GPU-to-CXL DMA写入CXL，最后释放GPU资源。对于Decoding worker，在接收到请求后，它直接从CXL读取该提示的所有KV块到GPU内存中，随后开始逐token的生成计算。
确保互斥访问的两层锁定结构。由于CXL Type-3设备不支持跨节点原子指令，TraCT无法依赖传统的硬件锁。如果让所有节点的所有进程直接竞争一个全局锁，由于进程动态加入和退出会导致参与者数量无界，产生极高的竞争。因此，TraCT采用了一种两层（two-tier）软件同步结构，由成对的global_lock和local_lock组成。
* 本地层（节点内互斥）：每个节点在本地DRAM中维护一个常规锁数组（如pthread_mutex）作为local_lock。进程必须先获取其所在节点的local_lock，这确保了在任何时刻，每个节点最多只有一个进程尝试获取全局锁。这种设计将全局锁的竞争者数量严格限制为已知且较小的节点总数。
* 全局层（节点间仲裁）：当进程获取本地锁后，它会将其在CXL共享内存中对应的global_lock槽位状态设置为WAITING，并开始通过load指令对该共享内存字进行自旋轮询。在后台，一个专用的lock_manager线程扫描global_lock条目。对于每个被请求的锁，管理器在处于WAITING状态的节点中选择一个，并将其槽位标记为LOCKED。管理器本身不持有锁，仅负责仲裁。请求进程观察到状态变为LOCKED后即可进入临界区。
* 锁释放：退出临界区时，进程将global_lock条目重置为IDLE，随后释放其local_lock，从而允许其他进程竞争。
保证数据可见性的缓存一致性策略。由于没有跨主机的硬件一致性，节点可能会读取到私有缓存中的过期数据。TraCT通过以下策略保证正确性：
* 元数据可见性：TraCT对修改的元数据执行细粒度的缓存行刷新，而不是刷新整个区域。这确保了诸如发布KV条目、更新引用计数等操作能按程序顺序持久化到CXL设备。
* 有效负载可见性：KV块的有效负载非常大，软件刷新成本极高。但由于GPU-CXL直接DMA完全绕过了CPU缓存，有效负载数据永远不会驻留在CPU私有缓存中。因此，TraCT将元数据（如将前缀缓存条目设置为READY）的发布作为可见性边界。元数据在DMA完成并刷新后，所有节点即可安全地假定对应的KV负载已经在CXL设备中全局可见。
* 避免错误可见性的clflush选择：虽然clflushopt指令开销较低且异步 【15，Persistent memory programming+2017】，【18，cmpi: Using cxl memory sharing for mpi one-sided and two-sided inter-node communications+2025+SC】，但配合mfence并不能保证刷新已到达CXL设备，这会导致锁释放后其他节点读到未落盘的旧值。为了保证节点间的绝对正确性，TraCT强制使用clflush指令，该指令能确保在指令完成前缓存行被强制从本地缓存层次结构中驱逐。
共享内存分配器与对象存储的实现。为了管理CXL中的字节寻址区域，TraCT设计了内存分配器和对象存储：
* 内存分配器：采用类似两层锁的设计，包含一个在CXL共享内存中维护全局位图的全局块分配器，以及在本地DRAM中维护空闲链表的每节点本地堆分配器。这消除了在CXL共享内存中密集的元数据更新，将竞争限制在节点内部。
* 共享对象存储：TraCT仅发布少量根对象（如前缀索引哈希表），并将内部结构通过偏移量进行链接，以此支持层次化数据结构并减少对象管理开销。提供了cxl_shm_put、cxl_shm_get等C API供上层调用。
前缀缓存管理的静态设计。动态的树结构在插入或分裂时会引发频繁的指针更新和缓存行刷新，在非一致性CXL内存中开销极高。TraCT采用固定大小的哈希表结合线性探测来管理前缀缓存。
* 块哈希计算：TraCT利用vLLM的KV块哈希机制 【5，vLLM)+URL: https://github.com/vllm-project/vllm】。对于包 含token ID列表$T_i$的块，其哈希计算为：$h_i = \mathrm{hash}(h_{i-1}, T_i)$。这保留了前缀关系，相同的提示前缀会产生相同的块哈希。
* 插入与查找：Prefill worker使用$h_i$进行线性探测。找到空桶后，分配CXL存储，发起GPU-to-CXL DMA。DMA完成后，更新桶的元数据（哈希值、块长度、KV存储偏移量）并刷新对应的缓存行。查找时消费者匹配哈希值并检索偏移量，全程无需修改元数据。
* 驱逐策略：TraCT在共享内存中维护一个简单的LRU链表。每次访问将条目移至末尾。驱逐时，选择引用计数为零的最老条目，标记无效，释放KV存储并从链表中移除。这仅涉及紧凑元数据字段的更新。
共享内存中的数据结构实现细节。由于不同节点操作系统映射CXL区域的虚拟基址不同，TraCT在所有共享数据结构中采用基于偏移量的寻址方式。每个节点保存其本地虚拟基址，进行如下转换：$\mathtt{ptr} = \mathtt{base} + \mathtt{off}$，$\mathtt{off} = \mathtt{ptr} - \mathtt{base}$。同时，共享对象严格按缓存行边界对齐，以避免伪共享。
启用直接GPU-CXL DMA与NUMA优化。直接调用cudaMemcpy()会导致CUDA驱动在主机DRAM中分配中间反弹缓冲区。TraCT利用CUDA的主机内存注册接口，将整个CXL共享内存区域固定（pin）。这使得CUDA运行时将其视为页锁定主机内存，允许DMA引擎直接访问CXL设备，实现真正的零拷贝。此外，为了避免跨CPU插槽的流量，TraCT将所有相关线程（包括锁管理器和KV连接器线程）绑定到直接连接CXL设备的NUMA节点上。
实验环境
- 数据集与工作负载：实验分为静态负载和合成负载。静态负载固定输出3个token，输入长度在1500到6000之间变化，用于精确控制KV传输量。合成负载使用Dynamo的数据生成器生成三个请求集（Workload A, B, C），其输入长度均值约为4449 tokens，输出长度均值约为215 tokens，通过改变唯一长度（Unique length）来控制前缀缓存命中率。
- 模型架构关键参数：所有评估均使用DeepSeek-R1-Distill-Llama-8B模型。
- 硬件配置：环境包含2台服务器，Server 1运行基准测试客户端和除Prefill外的所有运行时组件，Server 2专用于Prefill任务。每台服务器配备NVIDIA A6000 GPU (48 GB GDDR) 和 512 GB 主机DRAM。基线网络配置使用100 Gbps Mellanox MT2892 NIC。CXL配置使用Niagara 2.0 (第二代CXL Type-3内存扩展器)，提供640 ns延迟和$10.1 \mathrm{GB/s}$带宽 【2，Intel® Memory Latency Checker+URL: https://www.intel.com/content/www/us/en/developer/articles/tool/intelr-memory-latency-checker.html】。配 置64 GB的Niagara空间作为共享内存。
- 软件配置：系统基于Dynamo v0.5.0和vLLM v0.10.1.1实现。对比基线包括：Dynamo + NIXL/UCX（无缓存的RDMA传输基线） 【4，NVIDIA Inference Xfer Library (NIXL)+URL: https://github.com/ai-dynamo/dynamo】，【16 ，Ucx: an open source framework for hpc network apis and beyond+2015+High-Performance Interconnects】，LMCache（DRAM驻留的KV缓存基线，使用48GB主机DRAM） 【6，Lmcache: An efficient kv cache layer for enterprise-scale llm inference+2025】，以及TraCT（在CXL中使用同等大小的前缀缓存）。
实验结果
实验1：CXL作为传输介质的有效性（无缓存）
* 实验内容：在禁用前缀缓存的情况下，对比TraCT与NIXL/UCX基线在不同输入长度（1500至6000 tokens）下的首字延迟（TTFT）分布，以及在6000 token输入下的吞吐量。
* 实验结果：如图5所示，TraCT的TTFT CDF曲线整体向左偏移，表明其Prefill延迟始终更低。输入长度越长（如6000 tokens），延迟差距越明显，且TraCT的尾部延迟更短。如图6所示，在不同QPS负载下，TraCT维持了与基于RDMA的NIXL相当的吞吐量。
* 分析结论：直接的GPU-CXL DMA成功避免了网卡队列、主机DRAM拷贝和传输层开销。即使在没有缓存增益的情况下，CXL共享内存也能提供比RDMA更低且更稳定的延迟，是分离式LLM推理的有效大容量KV传输路径。
* 图表引用：
实验2：端到端吞吐量与延迟性能
* 实验内容：在开启前缀缓存的情况下，使用合成负载对比TraCT、LMCache和NIXL的峰值请求吞吐量和TTFT延迟。
* 实验结果：图7显示，TraCT在所有负载级别下均提供最高的吞吐量，在$\mathrm{QPS}=3.0$时，其峰值吞吐量比LMCache高出$1.6\times$。值得注意的是，图8表明TraCT的前缀缓存命中率与LMCache相当甚至略低。图9的TTFT CDF显示，TraCT将平均TTFT降低了最高$9.83\times$，并将P99尾部延迟降低了最高$6.2\times$。
* 分析结论：吞吐量和延迟的巨大提升源于两个因素。首先，TraCT的解码worker直接从CXL池中获取复用的KV块，而LMCache必须通过网络传输所有命中和未命中的块。其次，基于PCIe/CXL的本地互连对网络竞争极不敏感，消除了网络结构固有的排队和可变性，从而显著稳定了尾部延迟。
* 图表引用：
实验3：单请求时间分解与GPU资源分析
* 实验内容：分解每个请求在调度、KV读取、计算和KV写入上的时间，并监控Prefill和Decode worker的GPU SM利用率、PCIe流量和功耗。
* 实验结果：图10显示，随着负载增加，LMCache和NIXL在解码端的KV读取时间显著增长，而TraCT的KV读取时间几乎保持恒定。图11显示，TraCT显著降低了Prefill和Decoding期间的GPU SM利用率，并提供了持续更高的GPU RX接收带宽。TraCT的整体GPU功耗也明显低于基线。
* 分析结论：LMCache的KV读取时间增长反映了反复的GPU-主机-网卡内存拷贝开销。TraCT因为跳过了命中块的KV传输，直接从CXL消费数据，减少了GPU内存占用时间。解码端避免了网络导致的停顿，稳定了SM利用率，缩短了执行时间，从而有效降低了LLM推理部署的总拥有成本（TCO）。
* 图表引用：
结论
本文提出了TraCT，这是一个机架级的LLM服务系统，它使用直接的GPU-CXL DMA取代了基于RDMA的KV传输，使得Prefill和Decode worker能够通过CXL共享内存高效地共享KV块。为了在非一致性的CXL Type-3设备上正确运行，TraCT引入了两层节点间锁、软件管理的数据可见性机制，以及专为节点间共享设计的分配器和对象存储。在真实的CXL硬件上基于Dynamo-vLLM运行时的评估表明，TraCT相比于基于网络的基线系统，显著改善了TTFT和峰值吞吐量，证明了CXL共享内存是分离式LLM服务的一个实用且高性能的基础底座。
补充细节
相关工作对比分析。
* 分离式LLM推理：近期工作如Splitwise 【13，Splitwise: Efficient generative llm inference using phase splitting+2024+ISCA】、DistServe 【23，Distserve: disaggregating prefill and decoding for goodputoptimized large language model serving+2024+OSDI】、Preble 【17，Preble: Efficient distributed prompt scheduling for LLM serving+2025+ICLR】 和 Dynamo 【3，NVIDIA Dynamo+URL: https://github.com/ai-dynamo/dynamo 】 探索了分离计算密集的Prefill和延迟敏感的Decode阶段。然而，这些系统均将KV传输视为基于RDMA的网络操作，网络跳数始终处于关键路径中。TraCT通过CXL Type-3共享内存和GPU-CXL DMA彻底消除了主机间拷贝和网络序列化。
* 多层KV缓存：LMCache/CacheBlend 【6，Lmcache: An efficient kv cache layer for enterprise-scale llm inference+2025】，【20，Cacheblend: Fast large language model serving for rag with cached knowledge fusion+2025+EuroSys】 和 Mooncake 【14，Mooncake: Trading more storage for less computation — a KVCache-centric architecture for serving LLM chatbot+2025+FAST】 实现了跨分离式服务器的KV状态共享，但它们仍然依赖网络进行跨节点传输。TraCT与这些工作互补，但将前缀感知的KV缓存放置在支持DMA直接访问的CXL共享内存中，改变了性能包络。
* 基于CXL的内存系统：CXL-SHM 【21，Partial failure resilient memory management system for (cxl-based) distributed shared memory+2023+SOSP】、Tigon 【8，Tigon: a distributed database for a cxl pod+2025+OSDI】、cMPI 【18，cmpi: Using cxl memory sharing for mpi one-sided and two-sided inter-node communications+2025+SC】 和 Beluga 【19，Beluga: A cxlbased memory architecture for scalable and efficient llm kvcache management+2025】 探索了CXL共享内存。但它们的同步设计要么依赖特定设备的硬件一致性区域，要么使用队列避免互斥，或者使用集中式元数据服务器。TraCT首次展示了针对非一致性、TB级CXL内存的去中心化KV缓存设计，完全通过软件管理的缓存行刷新和两层锁机制实现机架级共享。
方法细节中的引用汇总：
* 【1】CXL specification (URL: https://computeexpresslink.org/cxl-specification/)。在背景知识中引用，说明CXL是基于PCIe的高带宽低延迟互连标准 。
* 【2】Intel® Memory Latency Checker (URL: https://www.intel.com/content/www/us/en/developer/articles/tool/intelr-memory-latency-checker.html)。在实验环境配置中引用，用于测 量Niagara 2.0 CXL设备的延迟和带宽。
* 【3】NVIDIA Dynamo (URL: https://github.com/ai-dynamo/dynamo)。在背景、实现和相关工作中引用，说明TraCT是基于该生产级分离式框架实现的 。
* 【4】NVIDIA Inference Xfer Library (NIXL) (URL: https://github.com/ai-dynamo/dynamo)。在实验环境中引用，作为基于RDMA的无缓存基线系统 。
* 【5】vLLM (URL: https://github.com/vllm-project/vllm)。在方法细节中引用，TraCT利用了其稳定的KV块哈希机制来生成前缀索引 。
* 【6】Lmcache: An efficient kv cache layer for enterprise-scale llm inference (2025)。在背景、实验和相关工作中引用，作为代表性的支持跨引擎复用的KV缓存层基线。
* 【7】Gemini 2.5: Pushing the frontier with advanced reasoning... (2025)。在背景中引用，作为现代Decoder-only LLM的代表。
* 【8】Tigon: a distributed database for a cxl pod (2025 OSDI)。在背景和设计挑战中多次引用，论证了当前CXL设备缺乏全设备硬件一致性，维持全局监听过滤器不切实际。
* 【9】Memory sharing with cxl: Hardware and software design approaches (2024)。在设计挑战中引用，进一步确认了CXL一致性仅限于小区域的硬件限制。
* 【10】Efficient memory management for large language model serving with pagedattention (2023 SOSP)。在背景中引用，说明vLLM利用分页机制解决单节点KV内存碎片。
* 【11】The llama 3 herd of models (2024)。在背景中引用，作为现代LLM的代表。
* 【12】Chatgpt (gpt-5) (URL: https://openai.com/chatgpt)。在背景中引用，作为现代LLM的代表 。
* 【13】Splitwise: Efficient generative llm inference using phase splitting (2024 ISCA)。在背景和相关工作中引用，说明分离式架构通过网络传输KV块。
* 【14】Mooncake: Trading more storage for less computation... (2025 FAST)。在背景和相关工作中引用，作为构建全局KV缓存集群的先进系统代表。
* 【15】Persistent memory programming (2017)。在方法细节中引用，说明clflushopt指令的异步刷新特性。
* 【16】Ucx: an open source framework for hpc network apis and beyond (2015 High-Performance Interconnects)。在实验环境中引用，作为NIXL底层依赖的网络传输库。
* 【17】Preble: Efficient distributed prompt scheduling for LLM serving (2025 ICLR)。在背景和相关工作中引用，作为分离式架构调度的相关系统。
* 【18】cmpi: Using cxl memory sharing for mpi one-sided and two-sided inter-node communications (2025 SC)。在设计挑战和方法细节中多次引用，指出了其生产者-消费者队列同步机制存在$O(N^2)$内存开销，以及其Arena对象分配器对层次结构的低效性。
* 【19】Beluga: A cxlbased memory architecture for scalable and efficient llm kvcache management (2025)。在设计挑战中引用，指出其采用集中式元数据服务器违背了CXL load/store初衷。
* 【20】Cacheblend: Fast large language model serving for rag with cached knowledge fusion (2025 EuroSys)。在相关工作中引用，作为多层KV缓存的补充研究。
* 【21】Partial failure resilient memory management system for (cxl-based) distributed shared memory (2023 SOSP)。在背景和相关工作中引用，说明早期CXL共享内存系统依赖特定设备的硬件一致性或原子操作。
* 【22】Sglang: efficient execution of structured language model programs (2025 NIPS)。在背景中引用，说明SGLang通过RadixAttention实现了单节点前缀共享。
* 【23】Distserve: disaggregating prefill and decoding for goodputoptimized large language model serving (2024 OSDI)。在背景和相关工作中引用，作为解耦Prefill和Decode worker的经典架构。