在消费级硬件上运行 70B 参数的大语言模型，长期受限于显存容量与 PCIe 带宽的传统瓶颈。NVIDIA RTX 3090 仅配备 24 GB 显存，而 FP16 精度下的 70B 模型需要约 140 GB 才能完整加载。即便采用 4 bit 量化，仍需约 35 GB 显存，超出单卡能力数倍。传统方案依赖 CPU 充当数据中转站：NVMe 读取模型权重到主机内存，再通过 cudaMemcpy 复制到 GPU 显存 —— 这形成了双跳（NVMe → Host RAM → GPU VRAM）的性能损耗链。gpu-nvme-direct 项目提出了一种激进方案：让 CUDA 内核直接与 NVMe 控制器通信，绕过 CPU 完成存储到 GPU 的数据路径。
为什么需要 GPU 主动发起 NVMe 操作
现代推理流水线中，CPU 介导的 memcpy 造成了严重的时间浪费。以 Llama-70B 为例，模型权重通常以 Q4 或 Q6 量化格式存储，单个层的权重往往达到数百 MB。使用传统路径加载一层需要经历 NVMe 读取、内核态到用户态的数据拷贝、以及最终的 GPU 复制，整个过程使 GPU 处于空闲等待状态。虽然异步 I/O 与 pinned memory 可以部分缓解问题，但 CPU 仍然是数据路径上不可绕过的瓶颈。
gpu-nvme-direct 的核心思路来自 ASPLOS 2023 的 BaM 论文：在支持 PCIe Barred Memory Access（BAR）的系统上，GPU 可以通过内存映射 I/O（MMIO）直接访问 NVMe 控制器的寄存器空间，从而自行构造 NVMe 命令、提交到队列、轮询完成队列。整个数据流变为 NVMe DMA → GPU VRAM，CPU 仅在初始化阶段介入。
PCIe 拓扑与设备映射的硬件基础
该实现基于特定的硬件配置搭建，工程化的关键在于正确识别和映射 PCIe 设备地址。实验平台使用华硕 ROG STRIX B450-F GAMING II 主板，配备 AMD Ryzen 7 5800X 处理器，GPU 与 NVMe 设备的 PCIe 地址分别为 0000:0a:00.0（RTX 3090）与 0000:01:00.0（WD SN740 512 GB）。值得注意的是，B450 芯片组仅支持 PCIe Gen3 通道，因此即便使用 Gen4 NVMe 设备，实际运行在 Gen3 x4 带宽上限（约 3.9 GB/s）。
BAR（Base Address Register）映射是整个方案的技术核心。NVMe 控制器通过 BAR0 空间暴露其寄存器接口，包括 Submission Queue（SQ）基地址、Completion Queue（CQ）基地址、以及各种控制与状态寄存器。Linux 系统下可通过 lspci -s 0000:01:00.0 -vv 查看具体映射地址。GPU 需要将 NVMe 控制器的 BAR0 寄存器空间映射到自己的地址空间，以便通过 MMIO 指令（PTX 的 st.mmio.sys 与 ld.mmio.sys）进行读写。
分层实现方案：因 NVIDIA 限制的妥协
必须正视的现实是：NVIDIA 在 GeForce 系列 GPU 上禁用了原生的 PCIe P2P DMA 功能。这意味着消费级显卡无法像专业加速卡（如 A100）那样直接在 GPU 之间或 GPU 与存储设备之间建立 DMA 通道。gpu-nvme-direct 项目采用了三层层级递进的实现策略，以适配不同的硬件能力。
第一层（Tier 1）是基础模式：GPU 负责驱动 NVMe 的门铃（doorbell）与完成队列轮询，命令队列与数据缓冲区仍然位于主机 pinned memory 中。GPU 通过 MMIO 写入 NVMe 控制器的 SQ Tail Doorbell 寄存器提交命令，然后轮询 CQ Head Doorbell 等待完成。数据通过 NVMe DMA 写入主机 pinned memory，再由 GPU 读取 —— 虽然仍需一次额外复制，但 GPU 已经能够在 I/O 过程中保持计算与数据传输的并行。
第二层（Tier 2）需要修改 NVIDIA 的开源内核模块以启用 cudaHostRegisterIoMemory 功能，使数据缓冲区能够直接驻留在 GPU VRAM 中。此时 NVMe DMA 目标地址直接指向 GPU 显存，消除了主机内存的中间停留。
第三层（Tier 3）代表 BaM 论文描述的完整形态：命令队列和数据缓冲区均驻留在 GPU VRAM 中。这需要原生的 P2P DMA 支持，目前仅在数据中心级 GPU 上可用。
CUDA 内核的 NVMe 命令构造
在 GPU 端运行的 CUDA 内核需要直接操作 NVMe 协议规定的命令结构。一个标准的 NVMe READ 命令包含多个字段：Opcode（01h 表示读取）、数据长度（以逻辑块为单位）、起始 LBA（Logical Block Address）、以及 PRP（Physical Region Page）指针用于指定数据传输的目的地。
gpu-nvme-direct 项目的实现中，CUDA 内核首先在共享内存或全局内存中构造完整的 SQ Entry。构造完成后，内核调用 __threadfence_system() 确保所有内存操作对 PCIe 可见。随后使用 PTX 指令 st.mmio.sys 向 NVMe 控制器的 SQ Tail Doorbell 寄存器写入新值，通知控制器有新的命令待处理。提交命令后，内核进入轮询状态，通过 ld.mmio.sys 读取 CQ Phase Bit 或 Status 字段判断命令是否完成。
这个过程的技术难点在于 NVMe 的 Maximum Data Transfer Size（MDTS）限制。消费级 NVMe 设备的 MDTS 通常为 512 KB 或 1024 KB，单次命令无法传输超过此限制的数据量。读取大块数据需要使用 PRP List—— 在命令的第二个 PRP 字段中写入一个指向 PRP 条目数组的地址，每个 PRP 条目描述一个物理页大小的数据区域。实测中，WD SN740 在 Gen3 x4 模式下可达到 3.35 GB/s 的持续读取带宽，约等于理论上限的 96%，管道深度（pipeline depth）设为 32 时表现最优。
与 ntransformer 推理引擎的集成
gpu-nvme-direct 已成功集成到 ntransformer 项目 —— 一个使用 C++/CUDA 编写的 Llama 70B 高效推理引擎。集成后，70B Q6_K 量化模型能够以 0.2 tokens/s 的速度流式推理。相比传统的 mmap 方式加载模型权重，这一方案实现了约 33 倍的性能提升。
推理过程中的数据流水线如下：当 GPU 执行第 L 层的矩阵乘法运算时，第 L+1 层的权重已通过 GPU 发起的 NVMe 读取操作预取到 VRAM 中。这种计算与 I/O 的完美重叠，使 GPU 在整个推理过程中始终保持高利用率，而非在权重加载期间空闲等待。
关键工程参数与监控点
若要在类似硬件上复现此方案，以下参数值得特别关注。主板需支持 Resizable BAR（或称 Above 4G Decoding），并在 BIOS 中启用该功能，使 GPU 能够访问超过 4 GB 的物理地址空间。NVMe 设备应选择支持 1024 KB MDTS 的型号，以获得更大的单次传输粒度。CUDA 版本建议使用 13.1，驱动版本 590.48.01（采用开放内核模块并打了 cudaHostRegisterIoMemory 补丁）。管道深度的默认值 32 可作为起点，实际调优需根据 NVMe 设备的队列深度与延迟特性进行微调。
性能监控方面，应重点关注 NVMe 设备的实际带宽利用率（可通过 nvme-cli 或设备供应商工具获取）、GPU 显存带宽占用、以及系统 PCIe 错误计数。任何 CRC 错误或总线重传都会显著拖累有效带宽。
局限性与适用场景
该方案并不适用于对吞吐量有严格要求的批量推理场景。单 RTX 3090 上 0.2 tokens/s 的生成速度意味着每个 token 需要约 5 秒的等待时间，更适合作为研究与实验环境，或对交互延迟无严格要求的个人开发者探索场景。对于需要更高吞吐的生产部署，仍应考虑多卡并行（需要解决 PCIe P2P 的消费者限制）或使用配备 NVLink 的专业计算卡。
从系统工程的角度看，gpu-nvme-direct 展示了在消费级硬件约束下，通过深度定制软硬件协同仍可挖掘出显著的性能空间。其三层递进的设计思路 —— 从 GPU 控制 I/O 到 GPU 直接 DMA—— 也为后续硬件能力演进预留了升级路径。
资料来源：gpu-nvme-direct 项目 GitHub 仓库（https://github.com/xaskasdf/gpu-nvme-direct）。