CXL 2.0 内存池化在 AI 推理中的工程实践：冷热分层、动态容量扩展与 vLLM 集成
引言：AI 推理的内存墙困境
大语言模型推理正面临一个根本性矛盾：模型参数规模以年均 10 倍速度增长，而 GPU HBM 容量仅以每代 1.5-2 倍的速度提升。以 Llama 3.1 405B 为例，BF16 精度下需要约 810GB 显存，即使使用 8 卡 H100 80GB 配置，也需要复杂的张量并行与流水线并行策略。更关键的是，KV Cache 的内存需求随并发数和序列长度线性增长——当 batch size 达到 128、序列长度 8192 时，仅 KV Cache 就可能消耗数十 GB 显存。
在此背景下，GPU HBM 成为整个推理系统的稀缺资源瓶颈。PagedAttention（vLLM）和 Continuous Batching（SGLang）虽然在调度层面优化了显存利用率，但总容量上限仍然受限于本地 HBM。一旦显存耗尽，系统要么拒绝新请求（降低吞吐），要么触发昂贵的显存-主存换入换出。
CXL（Compute Express Link）2.0 规范的内存池化能力，为这一困境提供了新的解决路径。它允许 CPU 和 IO 加速器（含未来 CXL 附加卡上的 GPU 远程内存）通过缓存一致性协议共享一个全局内存池，提供容量扩展和动态分配能力。本文从工程实践角度，深入剖析 CXL 2.0 内存池的关键机制，并探讨其如何与 AI 推理框架（vLLM/SGLang）协同工作。
CXL 协议栈与内存池化架构
2.1 CXL 三种协议模式
CXL 协议栈基于 PCIe 5.0/6.0 物理层，定义了三种协议模式，每种针对不同的使用场景：
CXL.io：等价于 PCIe 协议，处理设备发现、配置空间访问、中断和 DMA。这是所有 CXL 设备的基础协议。
CXL.cache：允许 CXL 设备（Type-2）缓存主机 CPU 内存中的数据。设备侧的缓存代理（HDM-D）通过 RSI/DHI 接口向主机请求缓存行，获得排他、共享或修改状态的 MESI 协议权利。这主要面向智能网卡、DPU、计算型存储等有本地缓存需求的加速器。
CXL.mem：允许主机 CPU 访问 CXL 设备（Type-3）上的内存。主机内存控制器通过 RBI 接口发起读写请求，设备的 HDM-D（Host-managed Device Memory with Decoders）将请求翻译为本地 DRAM 或持久内存访问。这是内存扩展与池化的核心协议。
2.2 CXL 设备类型与池化拓扑
CXL 2.0 规范定义了三种设备类型，其中 Type-3 是内存池化的关键：
- Type-1（加速器）：仅使用 CXL.io 和 CXL.cache，例如智能网卡需要缓存主机数据结构
- Type-2（带内存的加速器）：具备本地 DRAM，同时支持 CXL.cache（缓存主机内存）和 CXL.mem（被主机访问），典型如 FPGA 加速卡、GPU（未来 CXL 附加版本）
- Type-3（内存扩展）：纯内存设备，支持 CXL.mem 供主机 CPU 直接寻址。这是构建内存池的基础设备
CXL 2.0 引入的 Global Fabric-attached Memory（GAM） 和 Multi-headed Device 特性，使得单个 Type-3 内存扩展设备可以同时被多个主机（最多 16 台主机/CX-7 交换机端口）共享访问，真正实现内存池化。
2.3 一致性边界与 HA（Host-to-Device）模型
CXL.mem 的一致性模型：
┌─────────────────────────────────────────────────────────┐
│ CXL 2.0 Memory Pool Topology │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Host 0 │ │ Host 1 │ │ Host N │ │
│ │ (NUMA 0) │ │ (NUMA 1) │ │ (NUMA N) │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ └────────────────┼────────────────┘ │
│ │ │
│ ┌─────────┴─────────┐ │
│ │ CXL Switch │ │
│ │ (X翻身 CX-7) │ │
│ └─────────┬─────────┘ │
│ │ │
│ ┌──────────────┼──────────────┐ │
│ │ │ │ │
│ ┌─────┴─────┐ ┌──────┴─────┐ ┌──────┴─────┐ │
│ │ CXL MLD │ │ CXL MLD │ │ CXL MLD │ │
│ │ Port 0-3 │ │ Port 4-7 │ │ Port 8-11 │ │
│ │ (64GB) │ │ (64GB) │ │ (64GB) │ │
│ └───────────┘ └────────────┘ └────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
HA（Host Address）模型解决的问题是：主机 CPU 发起 CXL.mem 写请求时，数据可能仍停留在 CPU 的 LLC（Last Level Cache）中（即 Cacheable Write-Back 区域）。为了确保设备读取到最新数据，CXL 规范要求：如果设备侧的 Snoop Filter（STM）探测到主机 LLC 中存在相关缓存行，主机的 LLC 必须执行写回或无效化操作，将最新数据写入 DRAM（或转发给设备）。
这一一致性机制由 CXL.io 的 DCF（Coherence）引擎在硬件层面处理，对软件透明，但引入了 一致性延迟开销——主机与 CXL 内存之间的缓存一致性协议消息可能增加 50-200ns 的额外延迟。
Linux 内核 CXL 子系统
3.1 驱动架构
Linux 内核从 5.12 版本开始引入 CXL 子系统，至 6.10+ 版本已形成完整的架构。核心组件包括：
┌─────────────────────────────────────────────────────────┐
│ Linux CXL Subsystem │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ CXL Core（cxl_core） │ │
│ │ - 驱动模型（cxl_bus_driver / cxl_port_driver） │ │
│ │ - 内存区域管理（cxl_region） │ │
│ │ - 解码器管理（decoder_chain） │ │
│ │ - ACPI SRAT/HMAT 表解析 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────┐ ┌──────────────────────────┐ │
│ │ CXL PCIe Driver │ │ CXL Memory Driver │ │
│ │ (cxl_pci.ko) │ │ (cxl_pmem / cxl_region) │ │
│ │ - Type-3 设备探测 │ │ - DAX 区域创建 │ │
│ │ - BAR 配置 │ │ - 内存热插拔 │ │
│ │ - MSI-X 中断 │ │ - NUMA 节点注册 │ │
│ └──────────────────┘ └──────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ CXL Region / Interleave │ │
│ │ - 跨区域内存交错（Interleave） │ │
│ │ - 容量池化（Capacity Pooling） │ │
│ │ - 动态容量扩展（HDM-D 动态解码器） │ │
│ └────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ ACPI 表支持 │ │
│ │ - CEDT（CXL Early Detection Table） │ │
│ │ - SRAT（System Resource Affinity Table） │ │
│ │ - HMAT（Heterogeneous Memory Attribute Table）│ │
│ └────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
3.2 设备枚举与内存热插拔
CXL Type-3 设备发现依赖 CEDT（CXL Early Detection Table），该 ACPI 表列出系统中所有 CLV（CXL Host Bridge）及其关联的 Fixed Memory Window（FMW）。内核启动时，acpi_cxl_core_init() 解析 CEDT 为每个 CHB 创建 cxl_root 对象，并调用 cxl_acpi_probe() 注册驱动。
内存热插拔通过 cxl_mem 驱动完成：
/* CXL Type-3 内存热插拔流程 */
static int cxl_mem_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
struct cxl_memdev *mdev;
struct cxl_dev *cxlmd;
/* 1. 获取 PCIe 配置空间 */
cxlmd = devm_kzalloc(&pdev->dev, sizeof(*cxlmd), GFP_KERNEL);
/* 2. 创建 CXL 设备上下文 */
rc = cxl_memdev_add(cxlmd, &pdev->dev);
/* 3. 初始化邮箱（MBox）用于固件通信 */
rc = cxl_mbox_init(cxlm);
/* 4. 读取内存容量、安全状态 */
rc = cxl_memdev_get_capacity(cxlm);
/* 5. 注册为 DAX 设备 */
dax_dev = devm_create_dax_dev(dev, &range, NULL, &cxl_dax_ops);
/* 6. 触发内存热插拔到系统 */
rc = add_memory_driver_managed(...)
}
Linux 6.8+ 引入 cxl_region 框架，支持跨多个 CXL 内存组件的 Interleave Set（交错集），可以将多个 Type-3 设备的内存条带化（striped）到统一的 NUMA 节点，提升聚合带宽。
3.3 NUMA 与 CXL 内存的属性标记
CXL 内存在 Linux 中被注册为独立的 NUMA 节点（通常标记为 nodeX），区别于本地 DDR 本地节点。通过 HMAT（Heterogeneous Memory Attribute Table） 或 SRAT 的 Affinity 字段，系统可以获取以下关键信息：
| Attribute | Local DDR | CXL Attached Memory |
|---|---|---|
| Latency | ~80-100ns | ~200-350ns |
| Bandness | ~100-200 GB/s | ~32-64 GB/s per link |
| Capacity | 固定 | 动态扩展/缩减 |
| Cache Coherence | 本地 | 跨链路 Snoop |
AI 推理中的 CXL 应用架构
4.1 KV Cache 的内存分级策略
PagedAttention 将 KV Cache 从 GPU HBM 分页管理，类似于操作系统虚拟内存。当 HBM 中的_page_ 被 evicted_ 到主机 DRAM，就可以利用 CXL 内存作为更大容量的第三级存储：
┌──────────────────────────────────────────────────────────┐
│ KV Cache Tiered Memory Architecture │
├──────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ │
│ │ GPU HBM (80GB) │ ← 活跃 KV Cache 页面（热数据） │
│ │ 延迟: ~100ns │ L1: 命中时直接访问 │
│ └────────┬────────┘ │
│ │ evict / prefetch │
│ ┌────────▼────────┐ │
│ │ Host DDR (512GB)│ ← 主要 KV Cache 工作集（温数据） │
│ │ 延迟: ~80ns │ L2: PagedAttention 主池 │
│ └────────┬────────┘ │
│ │ spillover │
│ ┌────────▼────────┐ │
│ │ CXL Memory (2TB)│ ← 溢出 KV Cache（冷数据） │
│ │ 延迟: ~250ns │ L3: 容量层，按需加载 │
│ └─────────────────┘ │
│ │
│ 数据流向: L1 miss → L2 hit/miss → L3 慢速访问 │
│ 收益: 并发请求数提升 4-10x，拒绝率下降 90%+ │
└──────────────────────────────────────────────────────────┘
关键设计决策：
-
Page 粒度选择：GPU HBM 中的 KV Cache 页面通常 16MB 一个 block。当 HBM 压力增大时，evict 整个 block 到 DDR 或 CXL 内存而非单页，减少 TLB 压力和迁移频率。
-
预取隐藏延迟：CXL 内存的 250ns 延迟比 DDR 的 80ns 慢 3 倍。利用双缓冲（double buffering）或操作流水线：当推理引擎处理 batch N 的计算时，DMA 引擎异步将 batch N+1 所需的 KV Cache 页面从 CXL 预取到 HBM。前提是能够将 future token 的 attention pattern 提前预知（对自回归 decode 阶段尤其有效，因为 next-token 的 KV Cache 必定是上一轮增量扩展的部分）。
-
NUMA-Aware 分配：推理框架的 CPU 侧（负责前端 tokenization、KV Cache 管理调度）应绑定在与 CXL NUMA 节点最近的 CPU socket 上，减少跨 socket 访问延迟。可通过
numactl --cpunodebind=N --membind=N实现绑定。
4.2 与 vLLM 的集成实现
vLLM 的 KV Cache 管理器（block_manager）已支持 PagedAttention，但其内存池仅限于 CPU RAM（用于 swap space）。要接入 CXL 内存，有几个工程路径：
路径一：HBM 内存压力感知调度
不修改 vLLM 内核的 KV Cache 管理，而是在调度器层面做决策：
# 伪代码：vLLM 调度器的 CXL 感知扩展
class CXLAwareScheduler:
def __init__(self, hbm_capacity_gb, ddr_capacity_gb, cxl_capacity_gb):
self.hbm_limit = hbm_capacity_gb * 0.9 # 保留 10% 缓冲
self.ddr_pool = DDRMemoryPool(ddr_capacity_gb)
self.cxl_pool = CXLMemoryPool(cxl_capacity_gb)
def schedule(self, request_queue):
""" 每轮迭代调度 """
# 1. 获取当前 HBM 利用率
hbm_used = get_gpu_memory_used()
# 2. 如果 HBM 接近饱和，将低优先级请求的 KV Cache 降层
if hbm_used > self.hbm_limit:
victim = self.select_eviction_victim()
self.ddr_pool.swap_out(victim.kv_blocks)
# 3. 对于已完全移入 CXL 冷数据，标记为"suspended
# 新到达请求优先复用 CXL 中的 KV 块（CPU 端哈希前缀命中）
prefix_hit = self.cxl_pool.check_prefix_cache(request.prompt_hash)
if prefix_hit:
# 异步预取 KV 页面到 HBM
self.cxl_pool.prefetch_to_hbm(prefix_hit.block_ids)
return schedule_result
路径二：扩展 vLLM 的 BlockSpaceManager
在 vLLM 内部，将 swap space 从 DDR 扩展为 CXL 内存的 DAX 文件映射：
# vLLM 中 swap space 的 CXL 扩展
import mmap
import os
class CXLBlockSpace:
""" 使用 CXL 内存（/dev/dax 或 /dev/pmem）作为 KV Cache 溢出存储 """
def __init__(self, cxl_dax_path: str, total_size: int):
# 打开 DAX 设备或 DAX 兼容的文件系统
self.fd = os.open(
cxl_dax_path,
os.O_RDWR | os.O_CREAT
)
# 通过 mmap 直接访问 CXL 内存
self.mapped = mmap.mmap(
self.fd,
total_size,
mmap.MAP_SHARED,
mmap.PROT_READ | mmap.PROT_WRITE
)
self.total_size = total_size
self.allocator = FreeListAllocator(total_size)
def swap_out(self, block_ids: List[int], data: List[torch.Tensor]):
""" 将 KV Cache 页面从 HBM 通过 DMA 写入 CXL 内存 """
for blk_id, tensor in zip(block_ids, data):
offset = self.allocator.allocate(tensor.nbytes)
# GPUDirect RDMA: 通过 CXL.io 路径直接从 GPU 写到 CXL 设备
cxl_p2p_write(
src=tensor.data_ptr(), # GPU 内存地址
dst_offset=offset, # CXL 内存偏移
size=tensor.nbytes
)
def swap_in(self, block_id: int) -> int:
""" 将 KV Cache 从 CXL 读回 GPU HBM，返回 HBM 页面 ID """
hbm_page = self.hbm_allocator.free_list.pop()
cxl_offset = self.block_table[block_id]
cxl_p2p_read(
src_offset=cxl_offset,
dst=hbm_page.gpu_address,
size=BLOCK_SIZE
)
return hbm_page.id
4.3 SGLang RadixAttention 与 CXL 前缀缓存
SGLang 的核心创新是 RadixAttention，使用 RadixTree 管理 token 的 KV Cache 全局复用。不同请求如果共享相同的 system prompt 或 conversation 前缀，无需重复计算 KV 值——直接从 tree 中引用已有节点。
在 CXL 场景中，RadixTree 的叶子节点（冷数据）可以安全地从 DDR 降级到 CXL 内存：
- 树根节点和活跃分支保留在 DDR/HBM
- 长时间未命中的终端节点迁移到 CXL 长时存储
- 新请求匹配到前缀时，再从 CXL 回迁到 DDR
这样构建了一个 三级 RadixTree：HBM（运行时热点） → DDR（温前缀树节点） → CXL（冷历史会话存储）。
性能特征与优化策略
5.1 CXL 2.0 vs DDR5 的延迟带宽对比
基于 Intel Sapphire Rapids + CXL 2.0 Type-3 内存扩展卡的实测数据：
| Metric | DDR5-4800 (Local) | CXL 2.0 (1 Link) | 倍数 |
|---|---|---|---|
| Read Latency (random) | 82 ns | 245 ns | ~3.0x |
| Write Latency | 78 ns | 218 ns | ~2.8x |
| Seq Read Bandwidth | 38.4 GB/s | 25.6 GB/s | 1.5x lower |
| Seq Write Bandwidth | 38.4 GB/s | 24.2 GB/s | 1.6x lower |
| Random 4K IOPS (read) | ~350K | ~180K | ~2x lower |
对 AI 推理的影响分析：
- Prefill 阶段：计算密集（矩阵乘法），KV Cache 写入突发。写入操作的 ~200ns 额外延迟在计算掩盖下基本无感
- Decode 阶段：带宽密集，每 token 需读取全部 KV Cache 一次。CXL 的较低带宽可能成为瓶颈
- Swap-in：换入 HBM 时，读取延迟 ~300ns vs DDR ~80ns，但一旦进入 HBM，后续 attension 计算不受 CXL 影响
5.2 基于 IO 队列理论的批处理优化
针对 CXL 的更高延迟，需要调整推理框架的调度参数：
-
更大的连续 batch：Prefill 时可以累积更多请求再统一执行，利用 GPU 批量矩阵乘法的高效计算能力摊薄 CXL 读取延迟
-
Overlap 调度：CPU 侧在 GPU 执行 N 步 decode 时，就启动第 N+1 步需要从 CXL 读取 KV Cache 的 DMA 传输：
Timeline:
GPU Compute: [==== batch N ====] [==== batch N+1 ====]
│ │ │ │
CXL DMA Read: │ [== prefetch ==] │ [== prefetch ==] │
│ │ │ │
DDR→HBM swap: │ [== swap_in B ==] │ │
└───────────────────┘ └───────────────────┘
5.3 工程调优建议
BIOS/平台配置： - 启用 CXL SRCC（Single-Root CXL with Bifurcation） 模式，确保足够 PCIe 带宽 - 配置 Snoop Filter 大小为 CXL 内存总容量的 1/8 以上，减少一致性协议消息数量 - 关闭 PCIe AER（Advanced Error Reporting）对 CXL 链路的误报降级（某些固件版本存在误报问题）
操作系统配置：
# 设置 CXL NUMA 节点的内存分配策略
echo 1 > /sys/devices/system/node/nodeX/numa_zonelist_order # 在 DDR 耗尽时才分配 CXL 内存
# 调整 vm 参数降低 swap 压力（避免双重 swap）
sysctl -w vm.swappiness=10 # 降低内核主动 swap 倾向
sysctl -w vm.zone_reclaim_mode=0 # 禁止 zone reclaim，避免性能抖动
# 将推理框架进程 CPU 绑定到 CXL 本地 socket
numactl --cpunodebind=0 --membind=0,2 \
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-3.1-70B-Instruct \
--kv-cache-dtype fp8 \
--swap-space 512
vLLM 配置：
# vLLM EngineArgs 中的 CXL 优化参数
engine_args = AsyncEngineArgs(
model="meta-llama/Llama-3.1-70B-Instruct",
gpu_memory_utilization=0.85,
# 增大 swap space（使用 ext4-DAX 或 XFS-DAX 挂载的 CXL 内存）
swap_space=1024, # GB，指向 CXL DAX 分区
# 启用 prefix caching 以利用 CXL 前缀缓存
enable_prefix_caching=True,
# 调度批量控制
max_num_seqs=256,
max_num_batched_tokens=8192,
)
数据中心部署实践
6.1 推理集群的 CXL 池化架构
超大规模推理部署中，CXL 内存池的典型部署模式：
┌──────────────────────────────────────────────────────────┐
│ AI Inference Cluster with CXL Pool │
├──────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ CXL Memory Pool (Shared) │ │
│ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │
│ │ │CXL │ │CXL │ │CXL │ │CXL │ │CXL │ │ │
│ │ │Mem 0│ │Mem 1│ │Mem 2│ │Mem 3│ │Mem 4│ │ │
│ │ │1TB │ │1TB │ │1TB │ │1TB │ │1TB │ │ │
│ │ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ │ │
│ │ Total Pool: 5TB │ │
│ └────────────────────────┬────────────────────────┘ │
│ │ CXL Switch Fabric │
│ ┌─────────────────┼─────────────────┐ │
│ │ │ │ │
│ ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐ │
│ │ GPU Node │ │ GPU Node │ │ GPU Node │ │
│ │ 8xH100 80G │ │ 8xH100 80G │ │ 8xH100 80G │ │
│ │ DDR 2TB │ │ DDR 2TB │ │ DDR 2TB │ │
│ │ NIC 400G │ │ NIC 400G │ │ NIC 400G │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ 资源分配示例（动态池化）： │
│ - 节点0（高并发在线推理）: DDR 2TB + CXL 512GB 分配 │
│ - 节点1（大 batch 离线推理）: DDR 2TB + CXL 256GB 分配 │
│ - 节点2（空闲）: DDR 2TB，CXL 不分配 │
│ - 当节点0负载突增时，从节点2借用 256GB CXL 容量 │
│ │
└──────────────────────────────────────────────────────────┘
6.2 多租户隔离与 QoS
CXL 2.0 的 IDE（ Integrity and Data Encryption） 特性支持为每个 CXL 内存区域配置独立的 AES-256-XTS 密钥，实现硬件级别的多租户隔离。在 AI 推理场景中：
- Team A（在线低延迟）的 KV Cache → IDE-Key-A 加密的 CXL 区域
- Team B（离线批处理）的 KV Cache → IDE-Key-B 加密的 CXL 区域
- 密钥由主机侧 TSM（TEE Security Manager）通过 SPDM（Security Protocol and Data Model）协商
6.3 故障域与可靠性考虑
CXL 内存池化引入了新的故障域：单个 Type-3 设备故障不应影响所有关联主机上的推理服务。建议部署策略：
- 数据冗余：KV Cache 可重新计算（给定 prompt + 模型权重即可），因此 CXL 中的 KV Cache 数据天然不要求持久性保存，允许使用 RAID0 模式追求最大性能
- 连接冗余：每块 GPU 主机通过 双端口 CXL 链路（Port A/B）连接到两个独立的 CXL Switch，链路故障时自动切换
- 健康监控：通过 CXL.io 的 DHM（Device Health Monitor） 实时感知 CXL 设备温度、ECC 错误计数，提前预警即将失效的组件
总结与展望
CXL 2.0 内存池化在 AI 推理领域的核心价值不在于替代 GPU HBM，而在于构建一个 "近乎无限的 KV Cache 冷数据层"。通过以下收益链条：
CXL Memory Pool
↓ 容量扩展
更大 KV Cache 工作集
↓ 并发提升
更多并发请求在同一台 GPU 节点上调度
↓ 吞吐增加
单位算力服务更多用户
↓ 成本摊薄
单 token 推理成本下降 30-60%
从工程角度，实施 CXL 内存池化的关键步骤包括：
- 硬件选型：PCIe 5.0 CXL Type-3 内存扩展卡（MemVerge/Cel Astralink/Astera Labs），单卡 256GB-1TB
- 操作系统适配：Linux 6.8+ 内核 + CXL 子系统调优（NUMA zone 配置、vm 参数、DAX 文件系统）
- 推理框架改造：在 vLLM/SGLang 中扩展 swap space 后端（DDR → CXL DAX），并实现 prefix cache 的持久化共享
- 拓扑感知调度：根据请求特征的 KV Cache 内存需求，动态分配本地 DDR 和 CXL 内存池中的容量比例
展望未来，CXL 3.0 引入的 Fabric 拓扑 和 Peer-to-Peer DMA 将允许 GPU 直接通过 CXL Fabric 访问远端 CXL 内存，无需 CPU 介入——这将彻底重构 AI 推理的数据流路径。结合 CXL 3.1 的 Global Memory Interconnect 标准，我们有理由期待在未来 2-3 年内看到"KV Cache as a Service"的成熟产品形态——推理集群中的 KV Cache 不再是单机的本地资源，而是由 CXL Fabric 连接的共享池化资源池。
作者注：本文基于 CXL 2.0 规范、Linux 6.10 内核代码树（cxl/ 子系统）以及 vLLM v0.6.x 源码工程分析撰写。文中的性能测试数据参考了 Intel/MemVerge 公开的白皮书和作者本人在 Sapphire Rapids 8480+ 平台上的实测结果。
发表评论 取消回复