NVMe

深入解读 FMS 2026 的五条核心技术主线：High Bandwidth Flash、3D 内存封装、CXL 内存池、PCIe 6.0 液冷 SSD，以及面向 AI 的 NVMe 可运维基础设施。

GDS、GIDS 和 uGDS 的名字非常接近，也都在讨论 GPU 与存储之间的数据通路，因此很容易被理解成同一项技术的三个版本。 实际上，它们解决的是三个不同层面的问题： GDS 关注数据路径：怎样让存储数据不经 CPU 内存中转，直接进入 GPU 显存； GIDS 关注控制路径：怎样让 GPU Kernel 自己决定并发起存储请求，减少 GPU 与 CPU 往返； uGDS 关注软件栈：怎样让 CPU 在用户态直接管理 NVMe 队列，绕过内核 NVMe 驱动与文件系统。 可以先用一句话概括： GDS 是“数据直达 GPU”，GIDS 是“GPU 主动要数据”，uGDS 是“用户态 CPU 直接驱动 NVMe 把数据送到 GPU”。 本文从请求由谁发起、数据经过哪里、NVMe 命令由谁构造、是否保留文件系统语义等维度，分析三者的区别与联系。更深入的原理可以继续阅读本系列的三篇文章： NVIDIA GPUDirect Storage（GDS）详解：让存储数据绕过 CPU 直达 GPU NVIDIA GPU-Initiated Data Storage（GIDS）详解：让 GPU Kernel 主动访问存储 uGDS 原理解析：在用户态打通 NVMe SSD 与 GPU 显存 一、先区分数据路径与控制路径 理解这三项技术的关键，是不要把“数据经过哪里”和“谁发起 I/O”混为一谈。 数据路径 数据路径描述有效载荷如何移动。例如： 传统路径：SSD → CPU 内存 → GPU 显存 直接路径：SSD ──────────→ GPU 显存 GDS、GIDS 和 uGDS 都希望建立 SSD 与 GPU 显存之间的 DMA 路径，减少 CPU bounce buffer。但“数据不经过 CPU 内存”并不代表“CPU 没有参与”。 ...

大模型推理正在把存储重新推到系统性能的核心位置。模型权重、KV Cache、Embedding 和训练检查点都可能在 SSD、主存与 GPU 显存之间频繁搬运。传统路径通常要经过文件系统、内核块层、页缓存或用户态中转缓冲区，不但增加 CPU 开销，也让小块 I/O 延迟变得难以控制。 uGDS 是 ScaleX-IO 开源的一套用户态 GPU Direct Storage 开发库。它的核心思路很直接： 让 CPU 在用户态构造 NVMe 命令并管理提交队列与完成队列，由 SSD 通过 PCIe P2P DMA 直接读写 GPU 显存，从数据路径中绕开内核 NVMe 驱动和文件系统。 本文结合 uGDS 当前源码，解释它为什么快、一次 I/O 如何执行、内核模块与用户态库如何分工，以及使用这类“绕过内核”的存储栈时必须承担哪些工程责任。 一、uGDS 想解决什么问题 先看一条常见的数据读取路径： NVMe SSD │ ▼ 内核 NVMe 驱动 → 块层 → 文件系统 │ ▼ 主机内存缓冲区 │ ▼ GPU 显存 即使系统支持 Direct I/O，应用仍然通常要进入内核，由内核驱动准备 NVMe 命令、完成 DMA 映射并处理中断或轮询。若数据还要经过主机内存，再复制到 GPU，路径会更长。 ...