从 KVCache 到 AI SSD：存储如何成为大模型推理的「第三层」

——当 NVIDIA G3.5 遇见 Mooncake、CMX 与群联 aiDAPTIV：一场关于 Token 成本的数据架构革命

一、引言：存储突然成了主角

2026 年，NVIDIA 在定义下一代推理架构时做了一件从未做过的事：在 GPU 显存（HBM/VRAM）和通用共享存储之间，单独划出了一层编号为 G3.5 的专属空间，专门用来承载可复用的推理上下文。BlueField-4 + NVMe 闪存 + 专用编排系统，构成了完整的 CMX（Context Memory Storage）平台。

这不是一次普通的产品迭代。这是存储在 AI 计算的架构定义中第一次拥有了独立层级。

在此之前，存储的定位非常清晰：模型文件放在上面，用的时候加载进显存，用完写回磁盘，不参与推理过程本身。但随着 AI Agent 规模化落地，单个任务可能跨越数十次模型调用、多个计算节点，KV Cache、向量索引、MoE 专家权重、用户记忆被反复交替访问。GPU 越来越贵，等待数据到达的成本已经超过了计算本身的成本。

本文从工程师视角出发，系统拆解这一轮 AI 推理数据路径的架构重构：NVIDIA CMX 与 G3.5 层级意味着什么、为什么传统 SSD 无法直接胜任、当前市场中的三大技术路线如何竞争，以及这对工程师在生产环境中做方案选型意味着什么。

二、背景：为什么推理突然「缺存储」

2.1 大模型推理的三个阶段与数据依赖

一次完整的大模型推理分为三个阶段，每个阶段对存储的诉求截然不同：

Prefill（填充）阶段：输入 Prompt 被分词（Tokenize）后逐层通过 Transformer。每一层都会生成并缓存 Key-Value 张量（KV Cache），占用显存规模为 batch_size × seq_len × n_layers × 2 × hidden_size × dtype_size。一个 70B 参数模型处理 8192 Token 上下文，KV Cache 占用轻松超过 100GB，远超单卡 HBM 容量。

Decode（解码）阶段：自回归生成，每个新 Token 都必须读取完整 KV Cache 计算注意力分数，同时追加新的 K/V 条目。GPU 的算力是充足的，但数据搬运一旦跟不上，SM（流多处理器）就会空转。

Context Reuse（上下文复用）阶段：多轮对话、Agent 任务链中的相同前缀（System Prompt、Few-shot 示例），其 KV Cache 在不同请求间理论上可以复用。但复用前提是这些缓存能够被快速定位和读取——这要求存储系统具备 KV 感知的索引能力，而非传统的块设备接口。

2.2 MoE 模型的结构性挑战

Mix-of-Experts（MoE）模型带来了新的存储压力。每个 Token 在每一层会根据路由结果激活少数专家（通常 Top-K，K=1~8），但所有专家的权重必须全部常驻显存。一个 8×22B MoE 模型（8 个 22B 专家 + 路由网络），即使激活比例只有 5%，所有专家权重也必须同时驻留在 HBM 中。这不是计算问题，而是存储容量墙。

结果是：HBM 容量增长的速度，远跟不上模型参数膨胀的速度。H200 的 80GB HBM vs. Llama 3 405B 的完整权重，差距是 5 倍。

2.3 Agent 场景的持续性压力

传统 LLM 服务是「请求-推理-输出」的简单循环，存储只在首尾出现。Agent 推理是另一种范式：

用户任务 → Agent规划 → 工具调用 → 检索RAG → 记忆查询 → 再次调用LLM → ... → 完成任务

在上述循环中，KV Cache、向量数据库、工具描述、记忆对象、历史对话在多个阶段被交叉访问。每一步的输出决定下一步需要读什么——而 GPU 的算力账单在持续计时，等待即浪费。

这就是为什么业界开始说：推理的瓶颈不是算力，而是数据供给。

三、NVIDIA G3.5 与 CMX：存储有了独立层级

3.1 G3.5 是什么

NVIDIA 在 Rubin 架构路线图中引入的分层存储概念：

G3.5 的核心创新不是 NVMe SSD 本身，而是独立的编排层：BlueField-4 DPU 负责 NVMe SSD 的数据保护、网络传输和元数据管理，与 GPU 计算平面解耦。存储不再是 PCIe 总线上的被动设备，而是拥有自己控制平面的主动节点。

3.2 CMX 的数据平面设计

CMX 平台定义了三个核心 API 接口：

cuFile：GPUDirect Storage 路径，GPU 线程直接发起块级 I/O，绕过 CPU 操作系统栈。适合 KV Cache 大块顺序读写（通常 256KB-4MB 粒度）。

// cuFile 读写 KV Cache Block 的示意代码
#include <cufile.h>

CUfileHandle_t fh;
CUfileBufHandle_t buf_handle;

// 打开存储句柄
cuFileOpen(&fh, "/dev/nvme0n1");

// 分配 GPU Direct 缓冲区（锁页内存，GPU 可直接访问）
void* gpu_kvcache_block;
cudaMallocManaged(&gpu_kvcache_block, 4 * 1024 * 1024); // 4MB

// GPU 直接读取 KV Cache 数据（零拷贝路径）
size_t bytes_read;
CUfileIOParams_t read_params = {
    .op_type = CUFILE_IOREAD,
    .u.rd.dev_buf_base = gpu_kvcache_block,
    .u.rd.dev_buf_offset = 0,
    .u.rd.host_buf_len = 4 * 1024 * 1024,
    .u.rd.file_offset = kv_block_file_offset,
};
cuFileRead(fh, &read_params, &bytes_read);

// Prefill 阶段使用读入的 KV Cache
run_model_with_kvcache(gpu_kvcache_block);

SCADA（Storage Context Access for Direct Agents）：NVIDIA 为 Agent 场景专门设计的细粒度接口，针对低于 4KB 的海量并行访问做了优化。在 Agent 场景中，每次工具调用、记忆查询都会产生大量小粒度的元数据读取（Token 位置映射、缓存标签、权限信息等）。SCADA 让 GPU 线程直接控制存储操作，CPU 完全退出控制路径。

// SCADA 细粒度 KV 索引读取
#include <scada.h>

SCADAContext_t scada_ctx;
scada_init(&scada_ctx, "10.0.1.100:8080"); // 连接 CMX 节点

// Agent 记忆查询：需要并行读取多个 KV 条目
uint64_t kv_indices[] = {0x1F3A2B, 0x1F3A30, 0x1F3A45, /* ... 数十个 */};
void* results[NUM_INDICES];

// SCADA batch read：单次 RPC 获取多个 KV 条目
scada_batch_get(scada_ctx,
                /* key_type = */ SCADA_KV_ENTRY,
                /* indices = */ kv_indices,
                /* count = */ NUM_INDICES,
                /* results_out = */ results,
                /* timeout_us = */ 100);  // Agent SLA 通常 < 1ms

统一的元数据服务：CMX 提供跨 GPU 节点的 KV Cache 目录服务（Directory Service），维护「哪个 KV Block 存在哪台 CMX 节点」的映射，支持分布式缓存一致性协议。

3.3 Mooncake 的 KVCache 分离式架构

在 NVIDIA 推出 CMX 之前，月之暗面的 Mooncake 已经实践了以 KV Cache 为中心的分离式推理架构，相关论文被 USENIX FAST '25 接收。

Mooncake 的核心设计思路：将 GPU 集群中原本孤立的 CPU、DRAM 和 SSD 组织为统一的分布式缓存池，以 KV Cache 为调度单元进行跨节点共享。

传统架构：
  Request → GPU Node A（计算）→ Response
               ↑
          KV Cache 在本卡

Mooncake 架构：
  Request → Scheduler（全局调度）
               ↓ 查找 KV Cache 位置
    ┌─────────────────────────────────────┐
    │  CMX Pool (CPU+DRAM+NVMe SSD)       │
    │  ├─ Node A: KV-Block-123 (DRAM)     │
    │  ├─ Node B: KV-Block-456 (NVMe SSD)│
    │  └─ Node C: Prefix-Pool (DRAM)      │
    └─────────────────────────────────────┘
               ↓ Cache Miss/Share
          GPU Node A（计算）

Mooncake 的 KV Cache 以 Block（通常 512 Token）为粒度管理，而非整个请求上下文。相同 System Prompt、Few-shot 示例的前缀 KV Cache 可以在多个请求间完全共享——这是 Mooncake 相比传统方案的核心效率来源。

Mooncake Store 进一步引入 DRAM + NVMe SSD 的多级缓存：热数据保留在 DRAM，冷数据下沉到 NVMe 层，通过预估访问频率和 LRU 策略决定数据放置位置。

四、为什么传统 SSD 无法直接胜任

4.1 传统 SSD 的设计目标 vs. 推理需求

传统企业级 SSD 的性能指标围绕以下场景优化：

但 LLM 推理的访问模式与传统 SSD 设计目标存在结构性错配：

1. 尾延迟 vs. 峰值吞吐

LLM 推理需要的是 P99/P999 尾延迟稳定，而非峰值 IOPS。KV Cache 的读取必须在严格的计算窗口内完成（Prefill 阶段每个 Token 的生成都依赖前序 KV 数据），一次 SSD 尾延迟尖刺（GC 垃圾回收触发时，P99 可能飙升至 500μs+）就会导致整个 Decode 流水线停顿。

# 一个 KV Cache 读取的时间预算分析
# 以 20 Token/s 的 Decode 速度为例：
# 每个 Token 生成时间预算 = 50ms
# Prefill 的注意力计算时间 = 30ms（假设）
# KV Cache 读取必须在内完成 = 20ms（剩余时间）
# NVMe SSD 4KB 读延迟 = 80-120μs（理想状态）
# 但 GC 触发时，P99 延迟可达 400-800μs，仍在 20ms 内
# 
# 问题在于：这不是稳定的 120μs，而是双峰分布
# GPU 无法依赖这个数据源的延迟稳定性

2. NAND Flash 的物理约束

NAND Flash 以页（Page，4KB-16KB）为单位读取，以块（Block，256-512页）为单位擦除。FTL（Flash Translation Layer）负责地址映射、垃圾回收（GC）、磨损均衡（Wear Leveling）。

这些机制导致：

• 写放大（Write Amplification）：更新一个 Page 需要先将整个 Block 读入内存、擦除、写入更新后的数据。持续写入 KV Cache 会让写放大系数高达 3-5×。
• 尾延迟不可预测：GC 在后台运行，但在高写入压力下会触发紧急回收，产生数毫秒的 I/O 暂停。
• 寿命压力：普通 TLC SSD 的 DWPD 为 1-3，企业级 3-5。Agent 场景下持续写入 KV Cache，5 DWPD 可能也不够。

3. 语义盲区

传统 SSD 不知道自己在服务什么数据。它看到的只是 LBA（Logical Block Address）地址流，看不到 KV Cache 的语义结构：这是第几层的 K、属于哪个请求、访问频率如何、哪些是热数据（即将被 Prefill 重用）。

# 语义盲区导致的问题示例

# 传统 SSD 视角：
# 读 LBA 0x1A3F2, 读 LBA 0x1A3F6, 读 LBA 0x1A402 ...
# 这些 LBA 之间可能完全没有关联，也可能对应同一 Transformer 层的
# 连续 K 向量——SSD 无法利用这个访问局部性

# KV 语义视角：
# Prefill 阶段：连续读 [layer_0_k, layer_0_v, layer_1_k, layer_1_v, ...]
# Decode 阶段：随机读 [layer_N_k[token_i], layer_N_v[token_i]]
# 两种访问模式截然不同，但落在同一个 SSD 上

# 没有语义理解，就无法：
# - 按层/请求分离命名空间
# - 针对 Prefill 批量预取做调度优化
# - 识别即将被复用的 KV Block 并优先保留在热缓存层

4.2 文件系统到 NVMe 栈的延迟链路

即使 SSD 固件层面解决了尾延迟问题，数据从 SSD 到达 GPU 还要经过多层软件栈：

应用程序（vLLM/SGLang）
  ↓ (1) 用户态内存拷贝
页缓存/文件系统（ext4/btrfs）
  ↓ (2) 系统调用
块设备层（kernel block layer）
  ↓ (3) I/O 调度
NVMe 驱动（nvme driver)
  ↓ (4) PCIe DMA
NVMe SSD 控制器
  ↓ (5) FTL 查找
NAND Flash 介质
  ↑ (6) DMA 回传
PCIe  DMA
  ↓ (7) 用户态内存映射
GPU（通过 CUDA/PyTorch tensor）

每一层的排队、上下文切换、中断处理、内存拷贝都会叠加延迟。对于 256KB 的 KV Cache 块，这尚且可以接受；但对于 Agent 场景中大量 1-4KB 的细粒度访问，每层开销可能超过 I/O 本身。

五、三大技术路线深度解析

5.1 路线一：AI 负载强化型企业级 SSD

代表产品：英韧科技洞庭 N3X 系列、华为 OceanDisk 系列

这一路线的核心思路是：在传统 NVMe SSD 架构内，针对 AI 推理场景重新排序性能指标，但不改变 SSD 的基本运行逻辑。

英韧洞庭 N3X 系列的技术选择：

• 介质：XL-Flash（3D XPoint 级别低延迟介质）+ SLC NAND
• 目标场景：KV Cache 卸载、高并发临时数据读写
• 关键指标对比（据公开材料）：

XL-Flash 是一种介于 DRAM 和 NAND 之间的持久内存介质，延迟远低于 TLC/QLC NAND，但成本也更高。N3X 将其用于写入密集型的 KV Cache 场景，而非作为通用缓存。

华为 OceanDisk 的系列化策略：

华为没有采用单一规格，而是按负载特征将 SSD 分为三个系列：

• EX 560（极致性能）：极高随机写入性能、微秒级写延迟、高写入耐久性。面向：模型微调、检查点保存、高频缓存写入。
• SP 560（均衡推理）：在性能、耐久性和成本之间取得平衡。面向：AI 一体机、集群推理中的 KV Cache、长上下文、多并发访问。
• LC 560（超大容量）：单盘最高 245TB，侧重顺序读取带宽。面向：训练语料、多模态数据、向量库、大规模模型文件。

这种分层策略的工程意义在于：AI 推理不是一个单一负载，Prefill、Decode、Checkpoint、RAG 向量检索各有其 I/O 特征，用同一款 SSD 覆盖所有场景必然有取舍。系列化让采购方可以按负载特征精确匹配。

DiskBooster 驱动层软件：华为通过 DiskBooster 将 SSD 与 HBM、DDR 组织为分层存储体系，让数据在不同层级间自动流动。热 KV Cache 保留在 HBM，温数据下沉到 DDR，冷数据溢出到 NVMe SSD。软件层感知访问热度并做预取和淘汰决策，SSD 则专注于提供尽可能低的尾延迟。

代码示例：基于 DiskBooster 的 KV Cache 分层策略：

# DiskBooster 分层存储策略伪代码
import torch
from diskbooster import TierManager

tier_mgr = TierManager([
    Tier("hbm",   capacity_gb=80,  latency_us=1,   bandwidth_gb=2.5,  type="hbm"),
    Tier("ddr",   capacity_gb=512, latency_us=50,  bandwidth_gb=0.3,  type="dram"),
    Tier("ssd",   capacity_gb=8000,latency_us=200, bandwidth_gb=0.05, type="nvme"),
])

def allocate_kvcache_layer(layer_id: int, batch_size: int, seq_len: int, 
                             n_heads: int, head_dim: int) -> torch.Tensor:
    """根据层热度决定 KV Cache 放置层级"""
    kv_size_per_token = 2 * n_heads * head_dim * 4  # fp16: 4 bytes
    
    # 估算访问频率（工程中需要 profiling）
    access_freq = estimate_layer_access_freq(layer_id)
    
    tier = tier_mgr.select_tier(
        size_bytes=batch_size * seq_len * kv_size_per_token,
        access_freq=access_freq,
        latency_budget_us=compute_latency_budget(seq_len),
    )
    
    tensor = tier.allocate(size_bytes=batch_size * seq_len * kv_size_per_token)
    return torch.from_dlpack(tensor.to_dlpack())

# 调度策略：Prefill 阶段将新 KV Cache 写入 DDR（低延迟写入）
# Decode 阶段的热数据保留在 HBM
# 超过 HBM 容量的历史 KV Cache 溢出到 SSD（分层淘汰）

5.2 路线二：VRAM 扩展型缓存 SSD（群联 aiDAPTIV）

代表产品：群联（Phison）aiDAPTIV 方案

群联没有把 SSD 定义为独立的数据层，而是将其作为 GPU 显存（VRAM）的扩展——模型权重切分后流式传输，部分 KV Cache 卸载到 SSD 以腾出显存空间。

核心架构：

GPU VRAM（80GB HBM）
  ├─ 当前计算层权重 + 热 KV Cache
  └─ 次热 KV Cache（溢出至 aiDAPTIV SSD）

aiDAPTIV Cache SSD（TB 级高耐久 NVMe）
  ├─ 超出 VRAM 容量的 MoE 专家权重
  ├─ 历史 KV Cache（用于上下文复用）
  └─ 压缩的 Embedding 表

内存管理中间件（aiDAPTIV Runtime）
  ├─ 权重流式调度器（根据 MoE 路由结果预取专家权重）
  ├─ KV Cache 管理器（按 LRU 淘汰 + SSD 回写）
  └─ VRAM ↔ SSD 数据流水线（DMA 零拷贝）

aiDAPTIV 的关键创新点：

1. MoE 权重流式化：传统 MoE 推理要求所有专家权重常驻 VRAM。aiDAPTIV 将权重按层和专家分组，按需从 SSD 流式加载。由于 MoE 的路由结果通常在计算当前 Token 后才确定，aiDAPTIV 在等待下一个 Token 的 Prefill 阶段提前预取可能激活的 Top-K 专家权重，利用计算间隙掩盖 I/O 延迟。

// aiDAPTIV 专家权重流式加载示意
typedef struct {
    uint64_t expert_id;
    uint64_t weight_offset;    // SSD 上的偏移量
    uint64_t weight_size;      // 权重大小（字节）
    float    activation_prob;  // 基于历史的激活概率（用于预取决策）
} ExpertMetadata;

// 预取决策：根据历史路由模式预测下一个 Token 可能激活的专家
void prefetch_experts_for_next_token(
    ExpertMetadata* experts, 
    int n_experts,
    uint64_t* ssd_buffer,
    cudaStream_t compute_stream
) {
    // 按激活概率排序，取 Top-K
    sort_by_activation_prob(experts, n_experts);
    
    for (int i = 0; i < TOP_K; i++) {
        // 异步 DMA：从 SSD 预取到 GPU Direct 缓冲区
        cudaMemcpyAsyncAsync(  // 概念示意
            /* dst = */ vram_expert_workspace + i * EXPERT_SIZE,
            /* src = */ ssd_base + experts[i].weight_offset,
            /* size = */ experts[i].weight_size,
            /* dir  = */ cudaMemcpyDeviceToDevice,
            /* stream = */ compute_stream
        );
    }
}

2. 上下文复用减少 Prefill：KV Cache 卸载到 SSD 后，在多轮对话或相似任务链中，可以直接读取历史 KV Cache 而非重新 Prefill。这是 Token 级成本节省的直接来源。

3. 产品形态：群联不单独销售 SSD，而是将高耐久缓存盘、中间件、安装工具和经过验证的硬件配置打包成可部署方案，目标市场覆盖教育、科研、政府、企业私有化部署和本地模型微调。

5.3 路线三：存内计算型智能 SSD（江波龙 SPU + iSA）

代表产品：江波龙 WM8500 SPU + iSA 软件栈

江波龙的路线是将存储控制器从数据通道升级为存储侧智能调度节点，在 SSD 主控内部集成压缩、缓存和数据调度能力，减少对主机 CPU 的依赖。

SPU 架构设计：

• 工艺：5nm
• 核心能力：存内无损压缩、HLC（Hierarchical LLM Cache）高级缓存、混合 NAND 调度

三大关键能力：

存内无损压缩：压缩在 SSD 主控内部执行，不消耗主机 CPU 和内存带宽。对于 KV Cache 中的冗余模式（相同 Token 序列在不同请求中的重复出现），压缩比可达 2-4×。压缩后数据直接存储在 NAND 中，读取时在主控内解压后通过 DMA 送入 GPU——主机只看到压缩前后的大小差异，不知道内部实现。

# iSA 压缩感知的 KV Cache 存储策略
class ISAStorageManager:
    def __init__(self, spu_device="/dev/nvme0n1"):
        self.spu = SPUDevice(spu_device)
        self.compression_ ratios = {}
    
    def store_kv_block(self, kv_block: torch.Tensor, 
                       block_id: str, 
                       compression_hint: str = "high"):
        """
        compression_hint: 'high'（高压缩率，慢）| 'low'（低压缩率，快）
        SPU 主控根据 hint 选择压缩算法：ZSTD（高压缩）| LZ4（低延迟）
        """
        if compression_hint == "high":
            # SPU 内执行 ZSTD 压缩
            compressed = self.spu.compress(
                kv_block.numpy(), 
                algorithm="zstd", 
                level=19,
                output_buffer=self.spu.on_device_buffer  # 零拷贝
            )
        else:
            # SPU 内执行 LZ4 压缩
            compressed = self.spu.compress(
                kv_block.numpy(),
                algorithm="lz4",
                output_buffer=self.spu.on_device_buffer
            )
        
        # 记录压缩比，用于读取时的解压空间分配
        ratio = compressed.size / kv_block.nelement() * kv_block.element_size()
        self.compression_ratios[block_id] = ratio
        
        # 写入 NAND，SPU 内部处理 FTL 和垃圾回收
        self.spu.write(compressed, block_id=block_id)
    
    def retrieve_kv_block(self, block_id: str, 
                           decompress_into: torch.Tensor):
        """从 SSD 读取并就地解压到目标 GPU tensor"""
        compressed = self.spu.read(block_id=block_id)
        
        # 在 SPU 主控内执行解压，结果 DMA 送入目标 buffer
        self.spu.decompress(
            compressed,
            output=decompress_into,  # 可以是 GPU Direct 内存地址
            algorithm=self._detect_algorithm(compressed)
        )

HLC 高级缓存：将 SSD 上的 NAND 区域划分为多个逻辑缓存池（Cache Tier），每个池针对不同的数据温度：

// SPU 缓存层级设计
typedef enum {
    HLC_TIER_HOT    = 0,  // 活跃 KV Cache（3DWPD+ SLC NAND）
    HLC_TIER_WARM   = 1,  // 最近使用（1-3DWPD MLC NAND）
    HLC_TIER_COLD   = 2,  // 归档/长上下文（0.5-1DWPD TLC NAND）
} HLCTier;

// iSA 软件层决定数据温度，SPU 执行物理放置
int store_kvcache_with_tier(SPUDevice* spu, 
                              KVBlock* block,
                              HLCTier tier) {
    // 垃圾回收在后台异步进行，不阻塞写入
    return spu->write_to_tier(block, tier, /* async= */ true);
}

5.4 路线四：计算-存储联合设计（寅谱 + 联芸）

代表产品：寅谱-联芸 AI SSD 技术联盟方案

这是目前技术整合深度最大的路线，由推理芯片公司（寅谱）和 SSD 主控公司（联芸）联合开发，目标是从 middleware → firmware → controller → NAND 介质建立完整的 AI 语义链路。

核心设计理念：让存储设备理解模型的执行顺序，而非等待主机侧指令。

三大技术支柱：

1. 模型语义感知的地址布局（Semantic-Aware Address Layout）

传统 SSD 的 LBA 排布不考虑数据语义，关联紧密的数据可能被分散到不同物理位置。寅谱-联芸方案根据模型的层结构、MoE 专家分布和 KV Cache 访问模式，重新设计 NAND 上的数据布局。

传统 LBA 排布：
  [请求A层0 KV] [请求B层0 KV] [请求A层1 KV] [请求B层1 KV] ...
  （跨请求、跨层交错，Prefill 批量读取效率低）

语义感知排布：
  [请求A层0 KV] [请求A层1 KV] ... [请求A层N KV]  ← 连续
  [请求B层0 KV] [请求B层1 KV] ... [请求B层N KV]  ← 连续
  （同请求同请求、跨层连续，Prefill 批量读取效率高）

2. 预测式预取（Predictive Prefetching）

寅谱在推理芯片研发中积累了模型执行数据流分析能力。将这些能力下沉到 SSD 固件层，可以实现比主机侧预取更精确的时机控制：

• Prefill 预取：Prefill 阶段 KV Cache 的生成顺序与 Token 序列完全对应，可以精确预取下一批 KV 数据。
• MoE 专家预取：根据 MoE 历史路由模式，预测下一个 Token 可能激活的 Top-K 专家，提前从 NAND 加载到缓存。
• 上下文复用预取：识别相同 System Prompt 的请求，直接预取其 Prefix KV Cache。

// 寅谱-联芸方案：SSD 固件内的预测式预取引擎
typedef struct {
    uint8_t  model_id;
    uint8_t  layer_id;
    uint64_t kv_block_addr;      // NAND 物理地址
    float    next_access_prob;    // 基于历史模式预测的访问概率
    uint16_t prefetch_window;     // 预取窗口（Token 数）
} PrefetchEntry;

void ssd_firmware_prefetch_engine(SPUFirmware* fw, 
                                   KVCacheRequest* req) {
    // 分析当前请求的 Token 序列和已加载的 KV 状态
    PrefetchCandidate candidates[N_MAX];
    int n_candidates = 0;
    
    for (int layer = req->current_layer + 1; 
         layer < req->current_layer + PREFETCH_DEPTH; 
         layer++) {
        // 预测下一个 K/V 块的访问时间和物理位置
        PredictedAccess pred = fw->predict_access(req, layer);
        
        if (pred.confidence > CONFIDENCE_THRESHOLD) {
            candidates[n_candidates++] = (PrefetchEntry){
                .model_id = req->model_id,
                .layer_id = layer,
                .kv_block_addr = pred.nand_addr,
                .next_access_prob = pred.probability,
                .prefetch_window = pred.optimal_window,
            };
        }
    }
    
    // 在当前计算批次完成后，按优先级预取
    sort_by_probability(candidates, n_candidates);
    for (int i = 0; i < n_candidates; i++) {
        fw->issue_prefetch_async(candidates[i]);
    }
}

3. 多精度数据分层（Multi-Precision Data Tiering）

这是寅谱-联芸方案的独特创新：将模型权重和 KV Cache 按数值精度划分热冷层次：

• 低精度位（低 8-16bit）：作为「热数据」，优先保留在 DRAM 或高速 NAND 层，可直接参与推理计算。
• 高精度位（高 8-16bit）：作为「冷数据」，存储在普通 NAND 层，使用时与低精度合并恢复。

这个设计利用了一个工程洞察：并非所有推理场景都需要完整 FP16/BF16 精度。对于需要高吞吐的中等质量推理（如 RAG 检索、重排序），INT8/FP8 的中间结果可能已经足够。SSD 上的精度分层可以减少需要常驻高速缓存的数据量。

六、生产环境实战：从方案选型到部署踩坑

6.1 方案选型决策树

根据不同场景，推荐以下选型策略：

推理场景分析
  │
  ├─ 单卡推理 / 边缘部署
  │   └─ 推荐：江波龙 SPU + iSA（压缩 + 存内调度，适配端侧功耗约束）
  │
  ├─ 多卡集群 / 云端推理（追求 GPU 利用率）
  │   ├─ 高并发短上下文 → 英韧 N3X / OceanDisk SP560（低延迟写入）
  │   └─ 长上下文多轮对话 → NVIDIA CMX + 群联 aiDAPTIV（上下文复用）
  │
  ├─ MoE 模型专用推理
  │   └─ 推荐：寅谱-联芸方案（专家权重流式 + 精度分层）
  │
  └─ 超大上下文 RAG 场景
      └─ 推荐：OceanDisk LC560（245TB 超大容量）+ 分层缓存

6.2 部署中的关键技术细节

1. KV Cache 的 Chunk 大小选择

KV Cache 的切分粒度直接影响 I/O 效率和内存管理。过大 → 内存碎片严重、淘汰粒度粗；过小 → I/O 数量过多、NVMe 队列饱和。

工程经验值（基于 vLLM 生产实践）：

# vLLM 中的 KV Cache Block 大小配置
# vLLM 默认 block_size = 16（Token/Block）
# 对于 Prefill 密集型场景，建议增大到 32-64
# 对于 Decode 细粒度访问场景，建议保持 16

# 示例：配置 vLLM 使用自定义 Block 大小
from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",
    tensor_parallel_size=4,
    gpu_memory_utilization=0.90,
    block_size=32,           # 32 Token/Block，Prefill 友好
    num_remote_blocks=1024,   # 启用 SSD 卸载
    remote_block_space=2048,  # SSD 可用空间（GB）
)

# 当 GPU HBM 不足时，vLLM 自动将冷 KV Cache 置换到 SSD
# 读取时通过 pin 技术将热 Block 保留在 GPU

2. Caching 命中率监控

Token 成本节省直接来自 KV Cache 的命中效率。以下是一个实用的监控指标体系：

# KV Cache 命中率监控
import prometheus_client as prom

kvcache_requests_total = prom.Counter(
    'kvcache_requests_total', 
    'Total KV cache requests',
    ['request_type']  # prefetch / retrieval / miss
)

kvcache_tokens_saved = prom.Counter(
    'kvcache_tokens_saved_total',
    'Tokens saved via KV cache reuse'
)

kvcache_latency = prom.Histogram(
    'kvcache_access_latency_ms',
    'KV cache access latency by tier',
    ['tier'],  # hbm / ddr / nvme / disk
    buckets=[0.1, 0.5, 1, 5, 10, 50, 100, 500]
)

def on_model_request(req_id, prefix_tokens):
    """检查是否可以从缓存复用"""
    cache_key = compute_cache_key(prefix_tokens)
    
    with kvcache_latency.time(tier='ddr'):
        cached = ddr_tier.lookup(cache_key)
    
    if cached:
        kvcache_requests_total.labels(request_type='hit').inc()
        kvcache_tokens_saved.inc(len(prefix_tokens))
        return cached
    else:
        kvcache_requests_total.labels(request_type='miss').inc()
        # 需要 Prefill，将新生成的 KV Cache 写入各层
        new_kv = run_prefill(prefix_tokens)
        hbm_tier.store(cache_key, new_kv[:hot_size])
        ddr_tier.store(cache_key, new_kv[hot_size:warm_size])
        ssd_tier.store(cache_key, new_kv[warm_size:])
        return new_kv

3. SSD 寿命监控与预警

AI 推理的 KV Cache 写入量远超普通企业负载，必须建立专门的寿命监控：

# 通过 nvme-cli 监控 SSD 健康状态
# 企业级 AI SSD（如 N3X）在高写入压力下需要关注以下指标：

nvme smart-log /dev/nvme0n1

# 关键字段：
# data_units_written    : 累计写入量（块设备层面）
# host_reads           : 累计读取次数
# wear_leveling_count  : 磨损均衡状态（100=新，0=寿命将尽）
# total_lba_written    : NAND 实际写入量（考虑写放大）
# temperature          : 温度（AI 推理 SSD 温升明显，需关注散热）
# available_spare      : 剩余可用空间百分比

# 告警阈值建议（针对 AI 推理场景）
# wear_leveling_count < 20 → 预警，考虑更换
# temperature > 70°C → 降频或告警
# available_spare < 10% → 紧急告警

# 写入量估算：一个日均 10000 次 Prefill 请求的推理集群
# 每次 Prefill 平均写入 KV Cache：~500MB（70B 模型，8192 Token）
# 日写入量：~5TB/天
# 年写入量：~1.8PB
# 对于 5DWPD、10TB 容量的 SSD：
# 年可用写入量：10TB * 365 * 5 = 18.25PB
# 写入量占比：~10%，理论上足够
# 但需考虑写放大系数（1.5-3×），实际裕量需留足

6.3 常见部署踩坑清单

坑 1：NVMe 直通（SR-IOV）配置导致多租户隔离失效

在共享推理集群中，多个用户的 KV Cache 需要严格隔离。错误配置 PCI SR-IOV 的虚拟功能（VF）可能导致不同用户的 KV 数据互相泄露。

✅ 正确做法：为每个租户分配独立的 NVMe 命名空间（Namespace），在 BlueField-4/SSD 主控固件层启用 Namespace 级别的访问控制。

坑 2：PCIe 5.0 的散热设计被低估

PCIe 5.0 x16 的理论功耗为 15-25W（SSD 控制器 + retimer 芯片），在 AI 服务器 10+ GPU 的高密度部署中，SSD 的气流冷却条件远差于标准服务器。实测表明，温度每升高 10°C，SSD 尾延迟增加约 15-20%。

✅ 正确做法：SSD 安装位置避免在 GPU 上游气流路径；使用主动散热的 SSD 模组；监控 SSD 温度并设置降频阈值。

坑 3：CUDA 与 NVMe 的内存语义不一致

GPU 使用 CUDA Unified Memory 或 managed memory 时，其内存语义与 NVMe 的 PCIe 存储语义存在差异。cudaMemcpy 可能不会触发预期的 fsync，导致数据未落盘就开始计算。

✅ 正确做法：使用 cuFile 的显式 CUFILE_BUF_FLAG_APPENDING 标志确保数据一致性；在 KV Cache 关键路径上做显式同步。

坑 4：SSD 固件 FTL 版本不兼容

不同批次的 SSD 固件对 IO 调度算法、GC 策略有不同的默认配置。升级固件后，生产环境的延迟分布可能发生显著变化。

✅ 正确做法：任何固件升级前，在与生产环境相同的负载下做 72 小时 P99 延迟回归测试；记录每次固件升级前后的尾延迟分布并做 diff。

七、展望：AI 推理存储的下一步

7.1 CXL 内存池与 SSD 的协同

CXL（Compute Express Link）正在为服务器内部的内存资源池化提供统一协议。未来可能出现「CXL 内存池 + NVMe SSD」联合构成 G3.5 层的设计：热数据在 CXL 连接的 DRAM 池中（延迟 ~100-200ns），温数据在 NVMe SSD 中（延迟 ~50-200μs），两层之间通过统一内存语义透明调度。

7.2 存算一体 SSD 的远期图景

寅谱在推理芯片中积累的近存计算（Near-Memory Computing）技术，可能会在未来几年内与 SSD 主控融合。想象一下：SSD 主控不仅做数据调度，还能在 NAND 阵列旁边执行 Transformer 的线性层投影计算——将「数据搬运」变成「计算前移」。

7.3 每 Token 成本才是真正的竞争维度

当产业评估指标从「峰值算力」「显存容量」转向「每 Token 成本（PCT）」「每瓦 Token 产出」，存储的重要性将进一步凸显：

• 一个命中率 60% 的 KV Cache 复用方案，相当于将 Prefill 计算量减少 60%
• 1% 的 Prefill 计算节省 = 直接降低 1% 的 GPU 账单
• 这就是为什么存储厂商会如此认真地进入推理数据路径——Token 经济学的账本会给出答案

八、总结

2026 年的 AI 推理存储革命，本质上是一场关于数据在哪里、数据何时到达、数据如何被理解的架构重构。NVIDIA G3.5 层级的设立，是这场革命的里程碑事件，但它只是一个起点。

从 Mooncake 的 KVCache 分离式架构，到 NVIDIA CMX 的 G3.5 平台，到群联 aiDAPTIV 的 VRAM 扩展方案，到江波龙 SPU 的存内智能调度，再到寅谱-联芸的语义感知 SSD——每一条路线都在回答同一个问题：存储如何从被动设备变成推理流水线上的主动参与者。

对于工程师而言，这场变革意味着：

1. 推理优化不再只是 GPU 配置调优，而是涵盖存储层、网络层、内存层的端到端数据工程。
2. 方案选型需要按负载特征精细化，不同类型的 Agent 任务（长上下文 vs. 高并发 vs. MoE 推理）需要不同的存储策略。
3. SSD 选型要看尾延迟分布而非峰值指标，P99/P999 的稳定性才是生产环境的真正需求。
4. 存储厂商的合作深度将成为差异化壁垒，寅谱-联芸式的跨域协同比单一厂商更难复制。

存储拿到了 G3.5 编号这张入场券，但真正决定胜负的，是谁能在 Agent 推理的复杂数据流中找到让 GPU 永远不等数据的答案。

参考文献

[1] R. Qin et al., "Mooncake: A KVCache-centric Architecture for Serving LLM Chatbot," USENIX FAST '25, 2025. https://www.usenix.org/conference/fast25/presentation/qin

[2] Mooncake Project, "Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving," GitHub. https://github.com/kvcache-ai/Mooncake

[3] NVIDIA, "Introducing NVIDIA BlueField-4-Powered CMX Context Memory Storage Platform for the Next Frontier of AI," 2026. https://developer.nvidia.com/blog/...

[4] 英韧科技，"从 N3X 到 Gen6：英韧科技如何用三大要素打造国产 AI SSD"，2026.

[5] Huawei, "Huawei OceanDisk LC 560 SSD Data Sheet," 2025.

[6] Phison Electronics, "How aiDAPTIV+ Works." https://phisonaidaptiv.com/zh-tw/how-aidaptiv-works/

[7] 江波龙，"SPU 与 iSA"，2026. https://cn.longsys.com/about/news/13353.html

[8] 联芸科技，"CFMS 2026：AI 推理时代，存储主控芯片价值跃迁"，2026.

[9] Gartner, "AI Agent Infrastructure Market Analysis," 2026.