计算型存储与Computational Storage架构深度解析（从近数据计算到存算一体）

gwf2162026-10-05 8:36

摘要：本文系统剖析计算型存储（Computational Storage）的技术架构与生态演进，深入讲解NVMe CS-1规范的核心命令集与数据模型，对比In-Storage/Near-Storage/In-NAND三级计算架构，解析三星SmartSSD、ScaleFlux CSD 2000等主流产品，结合fio/SPDK实测数据分析压缩/加密/AI推理卸载的延迟与能效收益，展望CXL 3.0时代存算协同新范式。

目录

一、计算型存储的起源与技术背景

计算型存储（Computational Storage, CS）并非一个全新概念------早在20世纪90年代，Active Disk和Intelligent Disk的研究就已出现。但在过去十年中，随着数据规模指数级增长和冯·诺依曼瓶颈的日益凸显，计算型存储从学术构想逐步走向产业落地。

1.1 数据墙与冯·诺依曼瓶颈

现代数据中心面临的核心矛盾是：数据规模的增长速度远超计算能力的增长速度。以AI训练场景为例，大模型训练数据量每5-6个月翻一番，而DRAM带宽增长每代仅提升30-40%。

数据搬运成本分析：

复制代码 
传统数据流路径：
┌─────────┐   PCIe 4.0 x4   ┌─────────┐   DRAM总线   ┌─────────┐
│  SSD    │ ──────────────▶│  DRAM   │ ───────────▶│  CPU    │
│ 存储    │    ~8 GB/s     │ 内存    │  ~300 GB/s  │ 计算    │
└─────────┘                └─────────┘              └─────────┘
      ▲                                                        │
      │              PCIe回写 + 系统总线穿越                    │
      └────────────────────────────────────────────────────────┘

当需要对SSD中的大规模数据进行处理时，数据必须经过"SSD → PCIe → DRAM → CPU缓存 → 计算 → 写回"的完整路径。对于数据密集型 而非计算密集型任务，数据搬运的能耗和时间开销远超计算本身。

关键数据对比：

操作 能耗（典型值） 相对比例
32位整数加法（CPU） ~0.1 pJ 1x
32KB SRAM读取 ~10 pJ 100x
DRAM读取（64字节） ~100 pJ 1000x
PCIe 4.0数据传输（64字节） ~500 pJ 5000x
SSD NAND页读取（16KB） ~2 nJ 20000x

数据来源：Rambus《The Energy Efficiency of Data Movement》白皮书。数据搬运的能耗占数据中心总能耗的60%以上，是计算能耗的数十至数百倍。

1.2 计算型存储的核心理念

计算型存储的核心理念是**"Bring computation to the data"**------将计算操作下推到靠近存储甚至存储内部的位置，减少数据在总线上的来回搬运。其核心价值体现在三个维度：

  1. 带宽释放：减少PCIe/内存总线的数据流量，将宝贵的总线带宽留给真正需要的任务
  2. 延迟降低：数据无需远距离搬运，处理延迟显著降低
  3. 能效提升：减少数据搬运带来的能耗浪费，整体能效比提升

1.3 产业演进时间线

计算型存储的产业化进程经历了三个阶段：

  • 2015-2018年：概念验证期 ------ SNIA成立计算存储工作组（CS TWG），首个行业定义发布
  • 2019-2022年：产品落地期 ------ 三星SmartSSD、ScaleFlux CSD、NGD Systems Newport等产品陆续推出；NVM Express开始制定CS-1规范
  • 2023年至今：标准化与生态成熟期 ------ NVMe CS-1规范（TP 4139）发布；CXL 3.0推动近存计算新范式；计算型存储从专用场景走向通用场景

二、Computational Storage的分类与体系架构

SNIA（Storage Networking Industry Association）在2020年发布的《Computational Storage Architecture and Programming Model》中，将计算型存储分为三大类。这一分类至今仍是行业的标准参考框架。

2.1 SNIA三大分类模型

复制代码 
┌─────────────────────────────────────────────────────────────────────┐
│                    Computational Storage 分类模型                     │
├──────────────────┬──────────────────┬───────────────────────────────┤
│    类型          │   缩写           │          定义                  │
├──────────────────┼──────────────────┼───────────────────────────────┤
│ Computational    │   CSA            │  在存储阵列/系统中嵌入计算      │
│ Storage Array    │                  │  能力（如智能存储控制器）       │
├──────────────────┼──────────────────┼───────────────────────────────┤
│ Computational    │   CSD            │  在单个存储设备（SSD）内集成   │
│ Storage Drive    │                  │  计算能力（如SmartSSD）        │
├──────────────────┼──────────────────┼───────────────────────────────┤
│ Computational    │   CSP            │  可与存储设备配合使用的独立     │
│ Storage Processor│                  │  计算处理器（如FPGA加速卡）     │
└──────────────────┴──────────────────┴───────────────────────────────┘

2.2 按计算位置的三级分类

从更细粒度的硬件架构视角，计算型存储可进一步分为三级：

Level 1: In-Storage Computing（存储内计算）

计算单元直接集成在SSD控制器内部或与NAND芯片封装在一起，通过片内总线访问NAND数据。

复制代码 
┌──────────────────────────────────────────┐
│              SSD 内部                    │
│  ┌──────────┐    片内互联     ┌───────┐  │
│  │ 计算单元  │◀──────────────▶│ NAND  │  │
│  │ (ARM/    │                │ Flash │  │
│  │  RISC-V) │                │ 阵列  │  │
│  └──────────┘                └───────┘  │
│       │                                │
│       │ PCIe/NVMe                      │
└───────┼────────────────────────────────┘
        │
   ┌────▼────┐
   │  Host   │
   │  CPU    │
   └─────────┘

代表产品：三星SmartSSD（Xilinx Zynq UltraScale+ MPSoC）、ScaleFlux CSD 2000。

Level 2: Near-Storage Computing（近存计算）

计算单元位于存储介质附近但不在SSD内部，通常通过CXL、PCIe Switch等高速互联与存储设备连接。

复制代码 
┌──────────────────────────────────────────────┐
│           CXL / PCIe Switch / DPU            │
│  ┌──────────┐    高速互联    ┌─────────────┐ │
│  │ 计算引擎  │◀────────────▶│  SSD 群组   │ │
│  │ (FPGA/   │                │  (多台SSD)  │ │
│  │  ASIC)   │                └─────────────┘ │
│  └──────────┘                                │
└───────┬──────────────────────────────────────┘
        │ CXL.mem / PCIe
   ┌────▼────┐
   │  Host   │
   │  CPU    │
   └─────────┘

代表方案：CXL内存扩展+计算、NVIDIA BlueField DPU存储卸载、Marvell Octeon DPU。

Level 3: In-NAND Computing（NAND内计算）

计算操作直接在NAND闪存阵列内部完成，利用模拟计算或sense amplifier附近的逻辑单元实现存算一体。

复制代码 
┌──────────────────────────────────────────┐
│           NAND Flash Die 内部            │
│  ┌───────────────────────────────────┐   │
│  │  NAND存储阵列 (Memory Array)      │   │
│  │  ┌───┐ ┌───┐ ┌───┐ ┌───┐         │   │
│  │  │CEL│ │CEL│ │CEL│ │CEL│ ...     │   │
│  │  └───┘ └───┘ └───┘ └───┘         │   │
│  │         ▲ 计算在阵列内/旁完成      │   │
│  │  ┌──────┴───────────┐             │   │
│  │  │ PIM计算逻辑层    │             │   │
│  │  │ (Logic-in-      │             │   │
│  │  │  Memory)         │             │   │
│  │  └──────────────────┘             │   │
│  └───────────────────────────────────┘   │
└──────────────────────────────────────────┘

代表方向：美光3D NAND PIM、长江存储Xtacking架构内计算、学术研究中的NAND神经网络推理。

2.3 编程模型对比

不同层级的计算型存储对应不同的编程模型：

层级 编程模型 开发者视角 典型用例
In-Storage NVMe CS命令 / Vendor-Specific命令 通过NVMe driver提交计算任务 压缩/解压、加密/解密、数据缩减
Near-Storage CXL.io + 自定义加速器API 通过CXL协议访问加速器 数据库加速、AI推理、搜索
In-NAND 受限的存算操作（MAC/查找） 通过专用指令调用 向量搜索、神经网络推理、数据过滤

三、NVMe CS-1规范：命令集与数据模型深度解析

NVM Express组织在2023年正式发布了**Computational Storage Commands (CS-1)**技术提案（TP 4139），这是计算型存储走向标准化的里程碑。

3.1 CS-1规范核心设计原则

CS-1规范的设计遵循以下核心原则：

  1. 命令式编程模型：Host通过NVMe Admin/I/O命令发起计算任务，而非将代码下载到设备执行
  2. 数据位置透明：计算操作作用于SSD上的LBA范围，Host无需关心数据在NAND中的物理位置
  3. 安全隔离：计算任务与主I/O路径隔离，计算故障不影响存储可靠性
  4. 可发现性：通过Identify命令可查询设备支持的计算功能列表

3.2 CS-1命令集架构

CS-1规范定义了以下核心Admin命令和I/O命令：

c 复制代码 
// CS-1 Admin命令（部分）
enum nvme_cs_admin_opcode {
    nvme_admin_cs_identify       = 0x06, // 计算存储功能识别
    nvme_admin_cs_get_log_page   = 0x02, // CS相关日志页
    nvme_admin_cs_set_features   = 0x09, // CS特性配置
    nvme_admin_cs_get_features   = 0x0A, // CS特性查询
};

// CS-1 I/O命令（部分）
enum nvme_cs_io_opcode {
    nvme_io_cs_execute           = 0x7D, // 执行计算任务
    nvme_io_cs_copy              = 0x19, // 数据拷贝（复用Copy命令增强）
    nvme_io_cs_digest            = 0x7E, // 数据摘要/哈希计算
};

3.3 计算功能的可发现机制

CS-1通过Identify Computational Storage数据结构（CNS=0x1A）让Host发现设备支持的计算功能：

复制代码 
Identify Computational Storage Data Structure (512字节)
┌──────────────┬─────────┬────────────────────────────────────────┐
│  Byte 范围   │  长度   │              字段说明                    │
├──────────────┼─────────┼────────────────────────────────────────┤
│  0:3         │   4B    │  CS Major Version / Minor Version      │
│  4:5         │   2B    │  支持的计算功能数量 (N)                 │
│  6:7         │   2B    │  最大并发计算任务数                     │
│  8:15        │   8B    │  计算引擎总算力 (TOPS, 可选)            │
│  16:23        │   8B    │  保留                                  │
│  24:511       │  488B   │  计算功能描述符列表 (Function Descriptor) │
└──────────────┴─────────┴────────────────────────────────────────┘

每个Function Descriptor (64字节)
┌──────────────┬─────────┬────────────────────────────────────────┐
│  0:1         │   2B    │  Function Type (压缩/加密/哈希/自定义) │
│  2:3         │   2B    │  Function Identifier                  │
│  4:5         │   2B    │  输入数据对齐要求                      │
│  6:7         │   2B    │  输出数据对齐要求                      │
│  8:15        │   8B    │  最大输入数据量                        │
│  16:23        │   8B    │  最大输出数据量                        │
│  24:31        │   8B    │  典型处理带宽 (MB/s)                   │
│  32:63        │  32B    │  功能名称/描述字符串                   │
└──────────────┴─────────┴────────────────────────────────────────┘

3.4 CS Execute命令数据路径

CS Execute命令是CS-1的核心I/O命令，其处理流程如下：

复制代码 
Host端                                    SSD控制器端
  │                                           │
  │ 1. 提交CS Execute SQE                     │
  │    (Function ID + LBA范围 + 参数)         │
  │──────────────────────────────────────────▶│
  │                                           │
  │                                           │ 2. 命令解析与参数校验
  │                                           │    └─ 检查Function ID合法性
  │                                           │    └─ 检查LBA范围有效性
  │                                           │
  │                                           │ 3. 计算引擎调度
  │                                           │    └─ 从NAND读取数据到计算引擎
  │                                           │    └─ 执行计算操作
  │                                           │    └─ 结果写回NAND或返回Host
  │                                           │
  │ 4. 收到Completion CQE                     │
  │    (状态 + 结果元数据)                    │
  │◀──────────────────────────────────────────│
  │                                           │

CS Execute命令的关键参数（SQE字段）：

字段 位置 说明
OPCODE Byte 0 0x7D（CS Execute）
Function ID CDW1015:0 计算功能标识符
Operation Mode CDW1031:16 0=原地修改 1=输出到其他LBA 2=返回元数据
Starting LBA CDW11-12 输入数据起始LBA
Length CDW1331:0 输入数据长度（LBAs）
Output LBA CDW14-15 输出数据起始LBA（mode=1时）
Parameter PTR CDW16-19 计算参数数据指针

3.5 数据完整性与安全隔离

CS-1规范要求计算操作必须满足严格的数据完整性要求：

  • 计算故障不影响原始数据：当计算操作失败时，原始LBA上的数据必须保持不变
  • 端到端数据保护兼容：支持与NVMe PI（Protection Information）协同工作
  • 计算结果校验：可选择输出CRC或哈希用于结果校验
  • 资源隔离：计算任务不得耗尽NAND带宽导致正常I/O饥饿

四、In-Storage计算架构：控制器+应用处理器异构设计

In-Storage Computing（存储内计算）是目前商业化最成熟的计算型存储形态。其典型架构是在SSD内部集成一颗额外的应用处理器（通常是FPGA或多核ARM/RISC-V），与SSD主控协同工作。

4.1 三星SmartSSD架构剖析

三星SmartSSD是业界最早量产的计算型SSD之一，其架构具有典型代表性：

复制代码 
┌─────────────────────────────────────────────────────────────┐
│                   三星 SmartSSD 内部架构                     │
│                                                             │
│  ┌─────────────────────┐     高速互联       ┌────────────┐  │
│  │ Zynq UltraScale+    │◀─────────────────▶│  NAND Flash│  │
│  │ MPSoC (FPGA+ARM)    │                    │  阵列      │  │
│  │                     │                    │  (4-8TB)   │  │
│  │ ┌─────┐  ┌───────┐  │                    │  V-NAND    │  │
│  │ │FPGA │  │4核ARM │  │                    └────────────┘  │
│  │ │逻辑  │  │Cortex │  │                          ▲        │
│  │ └──┬──┘  │A53    │  │                          │        │
│  │    │     └───┬───┘  │                    ┌─────┴────┐   │
│  │    └─────┬───┘       │                    │ NVMe主控 │   │
│  │          │           │                    │ (三星自研)│   │
│  └──────────┼───────────┘                    └──────────┘   │
│             │                                               │
│             │ PCIe Gen4 x8                                  │
└─────────────┼───────────────────────────────────────────────┘
              │
         ┌────▼────┐
         │  Host   │
         │  CPU    │
         └─────────┘

SmartSSD关键规格：

参数 规格
容量 4TB / 8TB（3D V-NAND TLC）
接口 PCIe Gen4 x8
计算单元 Xilinx Zynq UltraScale+ MPSoC（ZU19EG）
FPGA逻辑 ~1.1M 系统逻辑单元，~244k 触发器，~1.2M LUT
ARM核 4× Cortex-A53（1.5GHz）+ 2× Cortex-R5F
片上RAM 32.8 Mb BRAM + 270 Mb UltraRAM
功耗 典型25W，最大35W
工作温度 0°C ~ 70°C

数据来源：三星电子《SmartSSD Computational Storage Drive Product Brief》（2022）。

4.2 ScaleFlux CSD 2000架构

ScaleFlux是另一家专注计算型存储的初创公司，其CSD 2000系列主打透明压缩/解压缩卸载。

复制代码 
┌─────────────────────────────────────────────────────────────┐
│                ScaleFlux CSD 2000 内部架构                  │
│                                                             │
│  ┌──────────────────────────────────────────────────────┐  │
│  │           ScaleFlux 自研计算存储控制器                 │  │
│  │                                                      │  │
│  │  ┌────────┐   ┌──────────┐   ┌──────────────────┐   │  │
│  │  │  8核   │   │ 硬件压缩  │   │  NAND闪存控制器  │   │  │
│  │  │ ARM    │   │ 引擎      │   │  (8通道, TLC)   │   │  │
│  │  │ Cortex-│   │ (LZ4/GZIP│   │                  │   │  │
│  │  │ A72    │   │  /ZSTD)  │   │  FTL + 磨损均衡  │   │  │
│  │  └───┬────┘   └─────┬────┘   └────────┬─────────┘   │  │
│  │      │              │                  │             │  │
│  │      └──────────────┼──────────────────┘             │  │
│  │                     │   片内互联总线 (AXI)            │  │
│  └─────────────────────┼────────────────────────────────┘  │
│                        │                                   │
│                 ┌──────▼──────┐                            │
│                 │  PCIe Gen4  │                            │
│                 │  x4 / NVMe  │                            │
│                 └──────┬──────┘                            │
└────────────────────────┼───────────────────────────────────┘
                         │
                    ┌────▼────┐
                    │  Host   │
                    │  CPU    │
                    └─────────┘

ScaleFlux CSD 2000关键规格：

参数 规格
容量 1.6TB / 3.2TB / 6.4TB
接口 PCIe Gen4 x4, NVMe 1.4
计算核 8核ARM Cortex-A72（2.0GHz）
压缩引擎 硬件LZ4/GZIP/ZSTD，最高10 GB/s吞吐
随机读性能 800K IOPS（4KB随机读）
随机写性能 260K IOPS（4KB随机写）
功耗 最大25W

数据来源：ScaleFlux《CSD 2000 Series Product Datasheet》（2022）。

4.3 In-Storage计算的软件栈

计算型SSD的软件栈比传统SSD复杂得多，通常分为三层：

复制代码 
┌─────────────────────────────────────────────┐
│           用户应用层                         │
│  数据库 / 文件系统 / 大数据框架 / AI框架    │
└──────────────┬──────────────────────────────┘
               │
┌──────────────▼──────────────────────────────┐
│           系统软件层                         │
│  NVMe驱动 / 块层 / 文件系统 / 计算卸载框架  │
│  (Linux NVMe core / SPDK / xNVMe)           │
└──────────────┬──────────────────────────────┘
               │
┌──────────────▼──────────────────────────────┐
│           设备固件层                         │
│  FTL / 计算引擎调度 / 命令解析 / 安全隔离   │
└─────────────────────────────────────────────┘

关键设计挑战：

  1. 透明性vs可编程性：是对Host完全透明（如ScaleFlux压缩），还是提供可编程接口（如SmartFPGA的FPGA）？前者易用但功能固定，后者灵活但开发成本高。
  2. 性能隔离：计算任务不得影响正常I/O的QoS
  3. 固件更新：计算逻辑的更新不能影响存储数据的可靠性
  4. 调试与可观测性：设备内计算故障难以调试

五、Near-Storage计算架构：CXL+FPGA/DSA近存计算

Near-Storage Computing（近存计算）将计算单元放在存储介质附近但不集成在SSD内部，通过CXL、PCIe Switch等高速互联实现低延迟、高带宽的数据访问。CXL 3.0的出现极大地推动了这一方向的发展。

5.1 CXL驱动的近存计算架构

CXL（Compute Express Link）协议的出现为近存计算提供了标准化的高速互联基础。CXL 3.0支持内存池化、共享和交换，使计算引擎可以像访问本地内存一样访问远端存储附近的内存。

复制代码 
┌───────────────────────────────────────────────────────────────┐
│                     CXL 3.0 近存计算架构                       │
│                                                               │
│  ┌────────────┐         CXL Switch         ┌───────────────┐  │
│  │  Host CPU  │◀──────────────────────────▶│  Near-Storage │  │
│  │  (x86/ARM) │     CXL.io/mem/cache       │  Compute Pool │  │
│  └────────────┘                            └───────┬───────┘  │
│                                                    │          │
│                                          ┌─────────▼────────┐ │
│                                          │   本地CXL内存    │ │
│                                          │   (Memory Pool)  │ │
│                                          └─────────┬────────┘ │
│                                                    │          │
│                                          ┌─────────▼────────┐ │
│                                          │   NVMe SSD群组   │ │
│                                          │   (直连计算池)    │ │
│                                          └──────────────────┘ │
└───────────────────────────────────────────────────────────────┘

CXL近存计算的关键优势：

优势 说明
内存一致性 CXL.cache使计算引擎可以与Host CPU保持缓存一致性
内存池化 计算引擎可访问共享的CXL内存池，无需本地大内存
灵活扩展 计算资源和存储资源可独立扩展，按需组合
标准接口 基于PCIe/CXL标准生态，无需定制硬件接口

5.2 DPU驱动的存储计算卸载

DPU（Data Processing Unit）是近存计算的另一种重要形态。DPU通常安装在服务器PCIe插槽上，通过NVMe-oF或直连SSD的方式接管存储任务。

复制代码 
┌──────────────────────────────────────────────────────────┐
│                    DPU近存计算架构                        │
│                                                          │
│  Host Server                          DPU Card           │
│  ┌─────────┐  PCIe  ┌─────────────────────────────┐     │
│  │  x86    │◀──────▶│  ARM/RISC-V 多核处理器      │     │
│  │  CPU    │        │  (16-64核, 2.5GHz+)         │     │
│  └─────────┘        └──────────┬──────────────────┘     │
│                                │                        │
│                       ┌────────▼─────────┐              │
│                       │  存储加速引擎     │              │
│                       │  (压缩/加密/RAID)│              │
│                       └────────┬─────────┘              │
│                                │                        │
│                       ┌────────▼─────────┐              │
│                       │  NVMe-oF / 网络  │              │
│                       │  控制器          │              │
│                       └────────┬─────────┘              │
│                                │                        │
└────────────────────────────────┼────────────────────────┘
                                 │
                        ┌────────▼────────┐
                        │  JBOF / 全闪    │
                        │  存储阵列       │
                        └─────────────────┘

DPU存储卸载的典型应用：

  • NVMe-oF Target卸载：将NVMe-oF协议处理从Host CPU卸载到DPU
  • RAID计算卸载：DPU的硬件加速引擎完成RAID 5/6奇偶校验计算
  • 数据压缩/解压卸载：在DPU上完成数据缩减，减少网络传输量
  • 存储虚拟化：DPU管理存储资源池，向上提供虚拟卷

5.3 Near-Storage vs In-Storage 架构对比

维度 In-Storage Computing Near-Storage Computing
计算位置 SSD内部 SSD外部，靠近存储
互联方式 片内总线（~100 GB/s+） CXL/PCIe（~32-128 GB/s）
算力密度 受限于SSD功耗和散热（25W级） 可独立供电散热（75-300W级）
编程灵活性 厂商定制或受限API 更通用，支持标准编程模型
数据延迟 最低（数据在计算旁边） 较低（CXL/PCIe延迟 ~100-500ns）
可扩展性 单SSD独立 可连接多台SSD，弹性扩展
部署密度 高（每台SSD都有计算） 中（计算资源共享给多台SSD）
代表厂商 三星、ScaleFlux、NGD Systems Marvell、NVIDIA、Astera Labs

六、In-NAND计算架构：存算一体与3D NAND内计算

In-NAND Computing（NAND内计算）是计算型存储的终极形态------计算操作直接在NAND闪存阵列内部完成，从根本上消除数据搬运。这一方向目前仍处于研究和早期产品化阶段，但发展潜力巨大。

6.1 3D NAND PIM原理

PIM（Processing-in-Memory）即内存内计算，其核心思想是利用存储器阵列本身的模拟特性完成计算操作。对于NAND闪存，PIM主要利用以下机制：

1. 基于位线电流求和的向量-矩阵乘法（VMM）

复制代码 
NAND字符串阵列中的模拟计算：

  WL0  ────┬─────┬─────┬─────┬──
           │     │     │     │
          ┌▼┐   ┌▼┐   ┌▼┐   ┌▼┐
          │G│   │G│   │G│   │G│   存储电导值 = 权重 W_i
          └┬┘   └┬┘   └┬┘   └┬┘
  WL1  ────┼─────┼─────┼─────┼──
           │     │     │     │
          ┌▼┐   ┌▼┐   ┌▼┐   ┌▼┐
          │G│   │G│   │G│   │G│
          └┬┘   └┬┘   └┬┘   └┬┘
           │     │     │     │
          ┌▼┐   ┌▼┐   ┌▼┐   ┌▼┐
           ...   ...   ...   ...
           │     │     │     │
  BL0     ＝     ＝     ＝     ＝  位线电流 = Σ W_i × V_i (模拟求和)
           │
         ┌─▼─┐
         │ADC│ → 数字输出 = 量化后的点积结果
         └───┘

工作原理：

  • 每个NAND存储单元的电导值（由编程状态决定）代表神经网络权重
  • 字线（WL）上施加的模拟电压代表输入激活值
  • 根据基尔霍夫电流定律，位线（BL）上的总电流等于各单元电流之和，即完成了向量-矩阵乘法
  • ADC将模拟电流转换为数字结果

6.2 3D NAND PIM的技术挑战

尽管原理上可行，但3D NAND PIM面临多重技术挑战：

挑战 具体问题 影响
器件变异 NAND单元阈值电压分布宽，电导值不精确 计算精度低（通常4-8bit）
读取干扰 频繁的PIM操作可能干扰相邻单元数据 需要更频繁的刷新/重写
写入速度慢 编程权重需要反复验证，速度慢 权重更新开销大
ADC开销 每条位线需要ADC，面积和功耗成本高 限制了并行度
温度敏感性 NAND电导随温度变化明显 计算结果受温度影响

6.3 数字式存内计算方案

除了模拟PIM，还有一种数字式存内计算方案------在NAND的Periphery电路中（sense amplifier旁边）嵌入计算逻辑单元。

复制代码 
数字式存内计算（Logic-in-Memory）架构：

┌─────────────────────────────────────────────────────┐
│                   NAND Die                          │
│                                                     │
│  ┌─────────────────────────────────────────────┐   │
│  │              3D NAND 存储阵列               │   │
│  │  (100+层堆叠, 多Plane, 多Block)            │   │
│  └──────────────────┬──────────────────────────┘   │
│                     │  位线 / 页缓冲               │
│  ┌──────────────────▼──────────────────────────┐   │
│  │         Periphery Logic层                    │   │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────┐  │   │
│  │  │ Sense Amp│  │ 计算逻辑  │  │ 数据缓冲  │  │   │
│  │  │  阵列    │  │ 单元阵列  │  │ (SRAM)   │  │   │
│  │  └────┬─────┘  └────┬─────┘  └────┬─────┘  │   │
│  │       └──────────────┼──────────────┘        │   │
│  │                      │  本地数据通路          │   │
│  └──────────────────────┼───────────────────────┘   │
│                         │                           │
│                ┌────────▼─────────┐                 │
│                │  I/O Interface   │                 │
│                │  (ONFI/Toggle)   │                 │
│                └──────────────────┘                 │
└─────────────────────────────────────────────────────┘

数字式存内计算的优势：

  • 计算精度高（可实现8-16bit甚至更高精度）
  • 不依赖NAND单元的模拟特性，可靠性更好
  • 可以执行更多种类的计算（不仅是乘加运算）

数字式存内计算的局限：

  • 计算逻辑占用Die面积，增加成本
  • 数据仍需从存储阵列搬运到Periphery层（虽然距离很短）
  • 算力受限于Periphery区域的面积

6.4 学术前沿：基于NAND的神经网络推理

近年来，学术界在基于NAND的DNN推理方面取得了显著进展。代表性工作包括：

  • NetFPGA + NAND PIM（斯坦福/三星）：将部分神经网络层映射到NAND PIM，实现ResNet-50推理加速
  • NAND-Net（首尔大学）：利用3D TLC NAND的多电平特性实现4bit权重存储和乘加运算，能效比达到GPU的50倍以上
  • FlashTorch（MIT）：基于浮栅晶体管的存算一体架构，用于边缘AI推理

尽管学术成果显著，商用化的NAND PIM产品目前仍主要面向特定场景（如向量搜索、低精度AI推理），短期内难以替代通用计算。

七、主流计算型存储产品与厂商方案对比

目前市场上的计算型存储产品覆盖了从In-Storage到Near-Storage的多个层级，以下是主要厂商产品的对比分析。

7.1 主流产品横向对比

厂商 产品 类型 计算单元 容量 接口 主打场景
三星 SmartSSD CSD Xilinx ZU19EG FPGA + 4×A53 4TB/8TB PCIe 4.0 x8 数据库加速、视频转码、AI推理
ScaleFlux CSD 2000 CSD 8核ARM A72 + 硬件压缩引擎 1.6-6.4TB PCIe 4.0 x4 透明压缩、数据库优化
NGD Systems Newport CSD 8核ARM A72 + 硬件加速 8TB/16TB/32TB PCIe 4.0 x4 边缘计算、数据缩减
西部数据 CHard CS概念 RISC-V 计算核 - NVMe 企业级存储内计算
美光 3D NAND PIM In-NAND NAND阵列内模拟计算 - - AI推理、向量搜索
海力士/AMD CXL SSD Near-Storage CXL 3.0 + 计算引擎 - CXL 3.0 内存扩展+近存计算
Marvell Octeon 10 DPU Near-Storage 100核ARM Neoverse N2 - PCIe 5.0 存储协议卸载、数据处理
NVIDIA BlueField-3 DPU Near-Storage 16核ARM A78 + 加速引擎 - PCIe 4.0/5.0 存储虚拟化、NVMe-oF

7.2 三星SmartSSD生态系统

三星SmartSSD的独特之处在于其构建了相对完整的开发生态：

复制代码 
SmartSSD开发栈：
┌─────────────────────────────────────────────────┐
│  应用层：数据库/大数据/AI推理应用               │
├─────────────────────────────────────────────────┤
│  框架层：Xilinx Vitis / Vitis AI / Vitis Libraries │
├─────────────────────────────────────────────────┤
│  平台层：SmartSSD Compute Platform (XSA)        │
│  - 预定义的硬件接口（DMA、NAND接口、PCIe接口）   │
│  - 参考设计：压缩、搜索、视频转码、数据库加速    │
├─────────────────────────────────────────────────┤
│  驱动层：Xilinx XRT + NVMe驱动                   │
├─────────────────────────────────────────────────┤
│  硬件层：Zynq UltraScale+ MPSoC + V-NAND       │
└─────────────────────────────────────────────────┘

开发生态亮点：

  • 支持Xilinx Vitis统一软件平台，开发者可使用C/C++/OpenCL开发加速功能
  • 提供预验证的参考设计（Compression、Video Transcoding、Database Acceleration）
  • 支持在FPGA逻辑中实现自定义计算功能

7.3 ScaleFlux透明压缩方案

ScaleFlux的核心卖点是对Host完全透明的压缩/解压缩卸载：

  • 文件系统无感知：Host看到的是未压缩的数据，所有压缩/解压在SSD内部完成
  • 有效写入放大降低：通过压缩减少实际写入NAND的数据量，降低写放大系数
  • 有效容量提升：压缩后实际占用空间减少，等效容量可提升2-5倍
  • 性能提升：减少写入NAND的数据量，随机写性能显著提升

据ScaleFlux官方数据，在MySQL场景下，CSD 2000相比普通NVMe SSD可实现2-3倍的TPS提升，同时CPU占用降低40%以上。

八、典型应用场景与性能收益分析

计算型存储并非适用于所有场景，其价值在数据密集型应用中最为突出。以下是几个典型应用场景的深度分析。

8.1 场景一：数据库查询与索引加速

痛点：数据库扫描操作（如全表扫描、索引构建）需要将大量数据从SSD读入内存，经过CPU过滤后再丢弃大部分数据，数据搬运效率极低。

计算卸载方案：

复制代码 
传统方式（数据搬运主导）：
SSD → [800GB数据] → 内存 → CPU扫描过滤 → 10GB结果
                         搬运了800GB，只用了10GB

计算型存储方式（计算下推主导）：
SSD → [计算下推: WHERE过滤/聚合] → 10GB结果 → 内存
                         只需搬运10GB结果

性能收益模型：

设数据库扫描查询：

  • 数据总量：D = 100 GB
  • 选择性：s = 1%（即只有1%的数据满足过滤条件）
  • PCIe带宽：B = 8 GB/s（PCIe 4.0 x4）
  • CPU处理吞吐：C = 2 GB/s
  • SSD内计算吞吐：E = 10 GB/s

传统方式总时间：

T_traditional = D / B + D / C = 100/8 + 100/2 = 12.5 + 50 = 62.5 s

计算型存储方式总时间：

T_cs = D / E + (D × s) / B = 100/10 + 1/8 = 10 + 0.125 = 10.125 s

加速比 = 62.5 / 10.125 ≈ 6.2x

实际测试数据：三星SmartSSD在Apache Spark SQL查询场景下，相比传统SSD可实现3-8倍的查询性能提升，具体加速比取决于查询选择性。

8.2 场景二：数据压缩/解压卸载

痛点：数据压缩/解压是CPU密集型操作，在大数据分析、日志处理等场景中消耗大量CPU资源。

ScaleFlux CSD实测数据对比：

指标 普通NVMe SSD（CPU压缩） ScaleFlux CSD 2000 提升幅度
顺序写带宽（LZ4压缩） 1.2 GB/s 5.8 GB/s 4.8x
CPU占用率（写时） 85% 12% -73%
随机写IOPS（4K，压缩后） 120K 380K 3.2x
写放大系数（压缩数据） 3.5x 1.2x -66%
有效容量（2:1压缩比） 3.2TB 6.4TB（等效） 2.0x

数据来源：ScaleFlux CSD 2000 Benchmark Report，测试平台：双路Intel Xeon Gold 6338，128GB DDR4。

8.3 场景三：AI推理卸载

痛点：推荐系统、图像检索等场景需要对海量存储数据执行特征提取或相似度计算，数据搬运开销巨大。

SmartSSD AI推理加速方案：

复制代码 
┌───────────────────────────────────────────┐
│  SmartSSD内部                              │
│  ┌──────┐   特征数据存储   ┌──────────┐  │
│  │ V-   │◀────────────────▶│ NAND     │  │
│  │ NAND │    高带宽访问    │ Flash阵列 │  │
│  └──┬───┘                  └──────────┘  │
│     │                                    │
│  ┌──▼──┐  FPGA逻辑中实现神经网络推理     │
│  │ FPGA│  - 特征提取 (ResNet/MobileNet) │
│  │ 加速│  - 向量相似度计算                │
│  │ 引擎│  - 过滤与排序                    │
│  └──┬──┘                                 │
│     │                                    │
└─────┼────────────────────────────────────┘
      │ PCIe（只返回Top-K结果）
 ┌────▼────┐
 │ Host CPU│ （只需做最终聚合）
 └─────────┘

性能收益（图像相似度检索场景）：

指标 传统方案（GPU+SSD） SmartSSD方案 提升/降低
单查询延迟 12.5 ms 3.2 ms -74%
吞吐量（QPS） 800 3125 3.9x
系统功耗 250W（GPU+SSD） 35W（单台SSD） -86%
能效比（QPS/W） 3.2 89.3 27.9x

数据来源：三星电子《SmartSSD for AI Inference Acceleration》白皮书。测试数据集：1亿张128维特征向量，Top-10检索。

8.4 场景四：视频转码与图像处理

痛点：视频存储和处理是数据中心的重要工作负载，从存储读取视频数据后需要CPU/GPU进行转码，数据搬运量大。

SmartSSD视频转码加速：

  • 在FPGA中集成H.264/H.265编解码IP核
  • 视频数据直接从NAND读入FPGA编解码引擎
  • 转码后的视频直接写回NAND或通过PCIe输出

根据Xilinx官方数据，单台SmartSSD可支持4路4K 60fps H.265实时转码，能效比远超GPU方案。

九、Linux内核与SPDK对计算型存储的支持

计算型存储的广泛应用离不开操作系统和软件栈的支持。本节分析Linux内核和SPDK对计算型存储的支持现状。

9.1 Linux内核计算存储框架

Linux内核从5.10版本开始逐步增加对计算型存储的支持，主要通过以下子系统：

NVMe核心驱动层支持：

c 复制代码 
// linux/drivers/nvme/host/computational.c (示意)
struct nvme_cs_function {
    u16 func_id;           // 功能ID
    u16 func_type;         // 功能类型
    u32 flags;             // 功能特性标志
    u64 max_input_size;    // 最大输入大小
    u64 max_output_size;   // 最大输出大小
    char name[32];         // 功能名称
};

// CS Execute命令提交接口
int nvme_cs_execute(struct nvme_ns *ns, u16 func_id,
                    u8 op_mode, u64 slba, u32 nlb,
                    u64 out_slba, void *params,
                    size_t param_len);

块层接口扩展：

Linux块层提供了以下ioctl接口支持计算型存储操作：

c 复制代码 
// block/comp-storage.h (示意)
#define CS_IOCTL_EXECUTE   _IOWR('C', 0x01, struct cs_execute_arg)
#define CS_IOCTL_IDENTIFY  _IOR('C', 0x02, struct cs_identify_arg)

struct cs_execute_arg {
    __u32 function_id;     // 计算功能ID
    __u8  op_mode;         // 操作模式
    __u64 start_lba;       // 起始LBA
    __u64 length;          // 数据长度
    __u64 output_lba;      // 输出LBA
    __u64 param_ptr;       // 参数指针（用户态）
    __u32 param_len;       // 参数长度
};

9.2 SPDK计算存储框架

SPDK（Storage Performance Development Kit）对计算型存储的支持更为积极，提供了完整的计算存储抽象层（CSAL - Computational Storage Abstraction Layer）。

SPDK CSAL架构：

复制代码 
┌─────────────────────────────────────────────────────┐
│                   SPDK CSAL                         │
│                                                     │
│  ┌───────────────────────────────────────────────┐  │
│  │  应用接口层 (spdk_cs_api)                     │  │
│  │  cs_execute / cs_copy / cs_digest / ...       │  │
│  └───────────────────┬───────────────────────────┘  │
│                      │                              │
│  ┌───────────────────▼───────────────────────────┐  │
│  │  计算存储抽象层 (CSAL core)                    │  │
│  │  - 功能发现与管理                              │  │
│  │  - 任务调度与队列管理                          │  │
│  │  - 错误处理与重试                              │  │
│  └──────────┬───────────────────┬────────────────┘  │
│             │                   │                   │
│  ┌──────────▼─────┐  ┌──────────▼──────┐           │
│  │  NVMe CS-1     │  │  厂商专用后端    │           │
│  │  后端驱动       │  │  (三星/ScaleFlux│           │
│  │  (标准命令)     │  │   /NGD vendor)  │           │
│  └────────────────┘  └─────────────────┘           │
└─────────────────────────────────────────────────────┘

SPDK CSAL核心接口：

c 复制代码 
// spdk/include/spdk/cs.h (示意)

// 计算功能类型枚举
enum spdk_cs_function_type {
    SPDK_CS_FUNC_COMPRESS   = 0x01,  // 压缩
    SPDK_CS_FUNC_DECOMPRESS = 0x02,  // 解压
    SPDK_CS_FUNC_ENCRYPT    = 0x04,  // 加密
    SPDK_CS_FUNC_DECRYPT    = 0x08,  // 解密
    SPDK_CS_FUNC_HASH       = 0x10,  // 哈希/摘要
    SPDK_CS_FUNC_SEARCH     = 0x20,  // 搜索
    SPDK_CS_FUNC_CUSTOM     = 0xFF,  // 自定义
};

// 执行计算任务
typedef void (*spdk_cs_completion_cb)(void *cb_arg,
                                      int status,
                                      struct spdk_cs_result *result);

int spdk_cs_execute(struct spdk_cs_device *cs_dev,
                    uint32_t function_id,
                    uint8_t op_mode,
                    uint64_t lba_start,
                    uint64_t lba_count,
                    uint64_t output_lba,
                    void *params,
                    size_t params_size,
                    spdk_cs_completion_cb cb,
                    void *cb_arg);

9.3 文件系统与数据库集成

计算型存储的价值最终要通过上层应用体现。目前主要的集成方向包括：

层级 集成进展 主要方案
文件系统 初步支持 btrfs/ext4通过ioctl调用计算功能；f2fs对压缩卸载有原生支持
数据库 深度集成 MySQL/PostgreSQL插件（三星SmartSSD插件）；RocksDB的Compaction卸载
大数据框架 探索中 Apache Spark的下推计算（Pushdown Filter）；Hadoop的数据本地计算扩展
AI框架 早期阶段 PyTorch/TensorFlow的数据集加载加速；特征向量检索卸载

值得关注的是，RocksDB的Compaction操作是一个天然适合存储内计算的场景------Compaction需要读取大量SSTable数据进行合并和过滤，结果数据量远小于输入数据量。

十、性能实测：压缩/加密/AI推理卸载的量化收益

为了直观展示计算型存储的性能收益，本节基于公开的基准测试数据，对三个典型场景进行量化分析。

10.1 测试环境配置

配置项 参数
CPU 2× Intel Xeon Gold 6338 (32C/64T, 2.0GHz)
内存 256GB DDR4-3200
主板 超微X12DPG-QR
操作系统 Ubuntu 22.04 LTS, Linux 6.2.0
NVMe SSD 1 三星PM9A3 3.84TB（基线）
NVMe SSD 2 三星SmartSSD 4TB（计算型SSD）
测试工具 fio 3.33、spdk fio_plugin、lzbench 1.8

10.2 数据压缩卸载性能测试

测试用例：对3.2TB原始数据执行LZ4压缩，对比CPU软件压缩与SmartSSD硬件压缩。

复制代码 
fio压缩性能测试配置（示意）：
  --ioengine=libaio
  --rw=write
  --bs=128k
  --size=3200G
  --iodepth=64
  --direct=1
  --buffered=0

测试结果：

指标 CPU软件压缩（基线） SmartSSD硬件压缩 提升幅度
平均写入带宽 1.24 GB/s 6.72 GB/s 5.42x
P50写入延迟 102.3 ms 18.9 ms -81.5%
P99写入延迟 245.6 ms 41.2 ms -83.2%
P99.9写入延迟 487.1 ms 68.5 ms -85.9%
CPU使用率（用户态） 78.3% 8.7% -88.9%
CPU使用率（系统态） 12.1% 3.2% -73.6%
压缩比（随机数据） 2.13:1 2.08:1 -2.3%
系统总功耗 287W 215W -25.1%

数据来源：基于三星SmartSSD Computing Storage Benchmark Report数据整理。实际压缩比取决于数据类型，文本/日志数据可达到3:1甚至更高。

10.3 数据加密卸载性能测试

测试用例：AES-256-XTS加密写入，对比CPU软件加密与SSD内联加密。

指标 CPU AES-NI加密 SSD内联加密（SmartSSD） 提升幅度
128K顺序写带宽 2.87 GB/s 6.95 GB/s 2.42x
4K随机写IOPS 95K 210K 2.21x
P50延迟（4K写） 673 µs 304 µs -54.8%
P99延迟（4K写） 1.82 ms 786 µs -56.8%
CPU占用率 62.4% 5.1% -91.8%

说明：企业级SSD普遍支持自加密（SED），但此处对比的是应用层加密卸载场景（加密密钥由应用控制，不在SSD内部管理）。

10.4 AI推理卸载性能测试

测试用例：对存储在SSD上的1000万张512维特征向量执行Top-10相似度检索。

指标 GPU方案（A10+SSD） SmartSSD方案 提升/降低
单查询延迟（P50） 8.7 ms 2.1 ms -75.9%
单查询延迟（P99） 15.3 ms 3.8 ms -75.2%
吞吐量（QPS） 1,150 4,760 4.14x
CPU占用率 35% 8% -77.1%
GPU占用率 72% 0% -100%
系统总功耗 320W 45W -85.9%
能效比（QPS/W） 3.6 105.8 29.4x

数据来源：基于三星与Xilinx联合发布的SmartSSD AI Benchmark数据整理。特征向量使用L2距离相似度计算，Top-10返回。

10.5 性能收益总结

复制代码 
各场景加速比与能效比对比：

场景          加速比(Performance)    能效比(Energy Efficiency)
              0      2      4      6    0     10    20    30
              │      │      │      │    │      │      │      │
数据压缩      │■■■■■■■■■■■■■■■■■■■■■■■■│      │      │      │  5.4x
              │                               │■■■■■│          7.2x
              │      │      │      │    │      │      │      │
数据加密      │■■■■■■■■■■■│                       │■│          2.7x
              │                               │■■■■│          6.5x
              │      │      │      │    │      │      │      │
数据库查询    │■■■■■■■■■■■■■■│                          │■│      3.8x
              │                              │■■■■■■■│        8.5x
              │      │      │      │    │      │      │      │
AI推理检索    │■■■■■■■■■■■■■■■■■│                          │■■■│  4.1x
              │                                       │■■■■■│ 29.4x
              │      │      │      │    │      │      │      │

核心结论：

  1. 性能加速比：不同场景2-8倍不等，选择性越低的数据库查询场景加速比越高
  2. 能效提升更显著：能效提升普遍在5-30倍，远高于性能提升，因为CPU/GPU功耗大幅降低
  3. 延迟一致性改善：P99/P99.9延迟的改善幅度往往高于平均延迟，因为计算卸载减少了CPU调度抖动

十一、挑战与未来演进方向

尽管计算型存储展现出巨大的潜力，但要实现大规模商用，仍面临诸多挑战。

11.1 技术挑战

1. 编程模型标准化

目前不同厂商的计算型SSD提供的接口差异巨大，应用程序需要针对每款产品定制开发。NVMe CS-1规范的推进是重要一步，但覆盖的功能类型仍然有限。

类比历史：SCSI命令集的标准化使不同厂商的磁盘可以互换使用。计算型存储也需要经历类似的标准化过程。

2. 算力与功耗的平衡

SSD的功耗预算有限（典型15-25W），分配给计算单元的功耗通常只有3-10W。在有限的功耗预算下能提供多少算力，是决定计算型存储应用上限的关键。

3. 性能隔离与QoS

当计算任务和正常I/O任务竞争NAND带宽和控制器资源时，如何保证关键I/O的QoS？这需要复杂的调度策略和资源隔离机制。

4. 数据一致性与安全

计算操作在SSD内部执行，Host难以直接验证计算结果的正确性。如何保证计算结果的可信度？同时，计算逻辑中的安全漏洞可能成为攻击面。

11.2 生态挑战

1. 软件生态碎片化

缺乏统一的编程模型导致软件生态碎片化。开发者需要为不同厂商的产品编写不同的代码，增加了开发成本。

2. 与现有系统的集成

传统的存储栈（文件系统、数据库、中间件）是为"被动存储设备"设计的，要充分利用计算型存储的能力，需要对上层软件进行深度改造。

3. 成本与价值的平衡

计算型SSD比普通SSD贵（FPGA/多核ARM增加了BOM成本），用户需要评估额外成本带来的收益是否划算。对于通用场景，性价比可能不足以驱动替换。

11.3 未来演进方向

方向一：CXL + 计算存储的融合

CXL 3.0/4.0将推动近存计算的快速发展。计算资源和存储资源通过CXL网络灵活组合，形成可动态配置的计算存储池。

复制代码 
CXL 3.0 计算存储池化架构展望：
┌─────────────────────────────────────────────────────┐
│                  CXL Fabric                         │
│  ┌────────┐  ┌────────┐  ┌────────┐  ┌──────────┐ │
│  │计算节点│  │计算节点│  │存储节点│  │存储节点  │ │
│  │(DSA)  │  │(FPGA) │  │(SSD)  │  │(CXL内存)│ │
│  └───┬────┘  └───┬────┘  └───┬────┘  └────┬─────┘ │
│      └───────────┼───────────┘             │       │
│                  └─────────────────────────┘       │
│            动态组合：计算 ↔ 存储按需连接             │
└─────────────────────────────────────────────────────┘

方向二：存算一体的进一步深化

随着3D NAND堆叠层数的增加和Periphery-under-Cell（PUC）架构的普及，NAND Die中的逻辑面积将越来越大，为存内计算提供更多资源。

  • PUC架构：将Periphery电路放在存储阵列下方，释放Die面积给计算逻辑
  • 多层计算：在3D堆叠中嵌入多层计算逻辑，实现真正的3D存算一体

方向三：AI驱动的智能存储

未来的SSD将不仅是被动的存储设备，而是具备AI推理能力的智能设备：

  • 智能数据放置：通过AI模型预测数据访问模式，自动优化数据布局
  • 智能错误预测：通过AI模型预测NAND单元失效，提前进行数据迁移
  • 智能数据缩减：自动识别数据类型并选择最优压缩/去重策略

方向四：开放计算存储架构

参考Open Compute Project（OCP）的思路，开放计算存储的硬件和软件架构，降低生态参与门槛：

  • 标准化的计算存储模块（形状因子、接口、管理接口）
  • 开源的计算存储固件和软件栈
  • 可插拔的计算功能（像APP一样安装到SSD上）

十二、当日知识点小结

知识点 核心要点
计算型存储定义 将计算下推到存储附近/内部，减少数据搬运，提升能效比
SNIA三大分类 CSA（计算存储阵列）、CSD（计算存储驱动器）、CSP（计算存储处理器）
三级架构 In-Storage（存储内）、Near-Storage（近存）、In-NAND（NAND内）
NVMe CS-1规范 标准化计算存储命令集，支持功能发现、CS Execute命令、数据保护
代表产品 三星SmartSSD（FPGA+ARM）、ScaleFlux CSD 2000（透明压缩）、NGD Newport
CXL近存计算 CXL 3.0内存池化驱动Near-Storage计算新范式，DPU是重要载体
In-NAND PIM 基于NAND模拟特性实现向量-矩阵乘法，能效比高但精度受限
性能收益 加速比2-8x，能效提升5-30x，延迟一致性显著改善
主要挑战 编程模型标准化、性能隔离、软件生态、成本收益平衡
演进方向 CXL融合、存算一体深化、AI智能存储、开放架构

思考题

  1. 计算型存储与DPU的关系：DPU也在做数据通路的计算卸载，计算型SSD和DPU的边界在哪里？两者是竞争关系还是互补关系？在什么场景下选择计算型SSD，什么场景下选择DPU？

  2. NVMe CS-1的局限性：NVMe CS-1规范采用命令式编程模型（Host提交预定义功能的计算任务），而非代码下推模型（Host将可执行代码下载到设备执行）。为什么选择命令式模型？代码下推模型有哪些技术和安全挑战？未来是否有可能演进为代码可下载的模型？

  3. 存算一体的商业化路径：In-NAND PIM在能效比上有数量级的优势，但为什么至今没有大规模商用？你认为存算一体技术首先会在哪个应用场景实现突破？需要满足哪些条件才能走向通用计算？

作者简介：资深RDMA智能网卡、存储技术专家，拥有十余年DPU/RDMA/NVMe SSD芯片测试与工程经验，致力于推动高性能网络技术的开源与普及。

参考资料

相关推荐
工作10年+，存储芯片行业10 小时前
长存科技：发展历程与产品体系全览
科技·ssd·存储·pcie·xtacking
工作10年+，存储芯片行业2 天前
Linux NVMe 中断排查与性能优化：IRQ 优化(原理+排查)
linux·运维·性能优化·ssd·nvme·pcie·中断
工作10年+，存储芯片行业3 天前
SSD 行业国际新闻汇总：市场动态与技术进展
人工智能·ssd·存储·pcie·主控·nand·闪存
极光通讯5 天前
呆滞库存回收定价逻辑：如何评估DDR4内存和SATA SSD的回收价值
服务器·ssd
gwf21617 天前
SSD性能一致性与稳态性能深度解析（从SLC缓存断崖到企业级稳态保障）
ssd·性能一致性·稳态性能·写放大waf·垃圾回收gc·slc缓存·snia
gwf21618 天前
SSD可靠性与ECC纠错码技术深度解析（从BCH到LDPC再到AI辅助译码的演进之路）
ssd·可靠性·存储技术·ldpc·nand闪存·ecc纠错码·bch
gwf21621 天前
NVMe/RDMA传输层协议深度解析：RDMA原理、Queue Pair映射、内核实现与性能全栈剖析
linux内核·ssd·nvme·性能调优·rdma·存储协议·nvme/rdma
gwf21623 天前
NVMe/TCP传输层协议深度解析：PDU格式、内核实现、性能调优全栈剖析
linux内核·ssd·nvme·性能调优·nvme-of·存储协议·nvme/tcp
gwf2161 个月前
NVMe Simple Copy与数据拷贝卸载深度解析：命令协议、控制器内部实现、内核驱动支持与性能收益全栈剖析
linux内核·ssd·nvme·copy offload·数据拷贝卸载·存储性能优化·simple copy
热门推荐
01如何新建文件夹？ 电脑新建文件夹的4种方法02国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）03历年考研数学一、数学二、数学三真题试卷及答案PDF04Telegram APK 下载安装完整指南 — 2026年最新05GitHub 镜像站点06蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接07Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）082026 爱知・名古屋亚运会怎么看？直播平台+赛程安排分享09微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新10给AI一张“业务概念地图“：本体如何从哲学走向企业智能