英伟达 GPU 的内存管理单元（MMU）主要承担功能：

1. 虚拟地址到物理地址转换
- 将 GPU 线程或 DMA 请求的虚拟地址（VA）映射到物理显存地址（PA），支持复杂的内存访问模式。
2. 统一内存管理（Unified Memory）
- 实现 CPU 和 GPU 共享同一虚拟地址空间，允许透明数据迁移（无需显式拷贝）。
3. 内存保护与隔离
- 通过页表权限位（读/写/执行）和安全域隔离，防止非法访问或越界操作。
4. 虚拟化支持
- 在云环境中支持多虚拟机（VM）共享 GPU 资源，通过多级页表（如 Stage1/Stage2）实现物理显存隔离。
5. 性能优化
- 通过多级 TLB、预取机制和大页支持，降低地址转换延迟，提升显存带宽利用率。
6. 安全扩展
- 支持显存加密（如 NVIDIA A100/H100 的 MIG 安全分区），保护敏感数据。

CUDA：英伟达最深的护城河，加速计算行业发展的时代引擎！- 与非网

从体系结构的组成来说，CUDA 包含了三个部分：开发库、运行期环境和驱动。

「DeepSeek 甚至绕过了 CUDA」，论文细节再引热议，工程师灵魂提问：英伟达护城河还在吗？

reed：NVidia GPU 指令集架构-前言

PTX 在接近汇编语言的层级运行，允许进行细粒度的优化，如寄存器分配和 Thread/Warp 级别的调整。

NVIDIA DGX H800 连接了 8 个 SXM5 H800，通过 4 个 NVLink 交换芯片，每个 GPU 的带宽为 400 GB/s（Nvidia H800，这是被 US 制裁之后的产品，把 Nvlink 的带宽从 900GBps 裁剪到 400GBps），总双向带宽超过 3.2 TB/s。每个 H800 SXM GPU 也通过 PCIe 连接到 CPU，因此 8 个 GPU 中的任何一个计算的数据都可以转发回 CPU。这也是为什么 DeepSeek 放弃 TP 选择了 MoE。

并且因为 H800 裁剪了带宽，但没裁剪 TensorCore，所以在做 Attention 计算的时候，可以用闲置的 TensorCore Matrix 算力去置换带宽，把算力和带宽都用满。在 DeepSeek-V3 论文中，使用英伟达的 H800 GPU 训练 DeepSeek-V3 时，他们针对自己的需求把 132 个流式多处理器（SMs）中的 20 个修改成负责服务器间的通信，而不是计算任务。变相绕过了硬件对通信速度的限制。

cuda 的发展历史和作用_cuda 历史-CSDN 博客
 cuda 护城河历史_cuda 推出时间-CSDN 博客
CUDA（Compute Unified Device Architecture）是 NVIDIA 公司开发的一种并行计算平台和编程模型，它极大地推动了并行计算领域的发展。以下是 CUDA 的发展历程和其作为 NVIDIA 护城河的历史：

初期发展
2006 年：NVIDIA 推出了 CUDA，这是 GPU 并行计算的一个重要里程碑。CUDA 允许开发者利用 GPU 的强大并行处理能力来加速各种计算密集型任务。
2007 年：CUDA 1.0 发布，支持 C 语言编程，为开发者提供了一个新的计算平台。
功能扩展与优化
2008 年：CUDA 2.0 引入了对 C++ 的部分支持，并增加了更多的库和工具。
2010 年：CUDA 3.0 引入了 Fermi 架构的 GPU，提供了更好的双精度性能和更多的内存带宽。
2012 年：CUDA 4.0 引入了 Kepler 架构的 GPU，提供了更高的能效和更好的并行处理能力。
2014 年：CUDA 5.0 引入了 Maxwell 架构的 GPU，进一步提升了能效和性能。
深度学习与高性能计算
2016 年：CUDA 8.0 引入了 Pascal 架构的 GPU，支持更多的并行计算优化。
2017 年：CUDA 9.0 引入了 Volta 架构的 GPU，提供了更好的深度学习性能。
2020 年：CUDA 11.0 引入了 Ampere 架构的 GPU，提供了更好的 AI 和高性能计算（HPC）性能。
现代版本与未来展望
2022 年：CUDA 12.0 发布，支持 NVIDIA Hopper 架构和 Grace CPU，进一步提升了 HPC 和深度学习任务的性能。
2025 年 2 月 24 日：CUDA 12.8 发布，支持 NVIDIA Blackwell 架构。Blackwell 由 208 亿个晶体管构建而成，是 NVIDIA Hopper GPU 中晶体管数量的 2.5 倍以上，是迄今为止最大的 GPU。
原文链接：【AI 系统】GPU 架构回顾（从 2010 年-2017 年）

从 2017 年 Volta 架构的第一代 tensor core 深度学习 DSA 组件，到 2022 年 Hopper 架构中再次加入第一代 Transformer Engine，Transformer Engine 是 PyTorch 的一个拓展，为了利用 FP8 的特性，针对 Transformer 里面的 Kernel 进行了重写，包含了一系列 LayerNorm, GeLU, ScaledSoftmax 等。

Yongfeng：详解 NVIDIA H100 TransformerEngine[转]

https://sci-hub.se/10.1145/3307650.3322224

NV 在内存管理方面的演进：

（1）最开始是分离内存管理，又可以分为两种，即锁页内存和零拷贝内存。在最原始的方式下，从主机内存拷贝数据到 GPU，首先操作系统会分配一块用于数据中转的临时锁页内存，然后将用户缓冲区中的数据拷贝到锁页内存中，再通过 PCIe DMA 拷贝到 GPU 显存中。

（2）在 CUDA4.0 引入了 Unified virtual address space，全局使用统一地址空间，即半分分离内存管理。实际上也是语法糖，将原有的四个方向的拷贝函数合成了一个，用户调用统一的拷贝函数，由 Cuda Runtime 来判定数据源和目标所在的物理地址。

在 UVA 之前，你需要管理哪些指针指向主机内存和哪些指针指向设备内存。有了 UVA，由指针指向的内存空间对应用程序代码来说是透明的。通过 UVA，由 cudaHostAlloc 分配的固定主机内存具有相同的主机和设备指针。因此，可以将返回的指针直接传递给核函数。

https://tallendev.github.io/assets/papers/sc21.pdf

（3）CUDA6.0 引入了 unified memory，这时可以通过软件维护的内存 coherence。Unified Memory 在 Unified Virtual Address 的基础上更进一步，将系统内的所有内存资源都整合到相同的虚拟地址空间中。不管是 CPU 还是 GPU 代码，不用再区分其指针指向的空间，这给用户编程提供了极大的便利性。

cuda unified memory 简介和 cuda 深拷贝问题

统一内存创建了一个受管内存池，该池在 CPU 和 GPU 之间共享，弥合了 CPU 与 GPU 的鸿沟。使得 CPU 端和 GPU 端都能通过同一个指针访问数据，从而避免了程序员编写代码时显示的执行 GPU 和 CPU 端的内存拷贝命令

如果不用 Unified Memory，我们如果需要在 GPU 上处理数据，需要显示的调用 cudaMemcpy 函数到 GPU 端，需要在 CPU 端处理的时候还需要在 cudaMemcpy 回来, 会带来很大的麻烦。而 unified memory 则可以解决这个问题（拷贝依然会执行，但是是系统帮程序员执行，不需要显示调用 cudamemcpy）

使用 unified memry 需要使用 cudaMallocManaged 函数来进行分配。

这样带来的好处主要是可以减少代码量，使得程序员不用费尽心思去进行 CPU 和 GPU 端数据的拷贝，尤其是对于一些嵌套结构体，链表之类的拷贝起来比较麻烦的问题。

CUDA 的统一内存（Unified Memory）允许 CPU 和 GPU 共享数据，通过以页面大小为单位进行数据传输。当分配的内存小于页面大小时，可能导致同一页面在不同 GPU 间频繁迁移，影响性能。为避免此问题，应尽量避免在多 GPU 环境下分配小块内存。

CUDA 统一内存：简化编程与内存管理的革命,-CSDN 博客

 CUDA--Unified Memory

在编写 CUDA 程序时，经常要对 CPU 和 GPU 上分配内存和管理，这样就增加了编写程序发复杂度。在 cuda6 后引入了统一寻址（Unified Memory）技术，该技术使得 CPU 和 GPU 使用同一个指针对同一块内存进行处理，省去了原始的在 CPU 和 CPU 分配内存然后来回拷贝的过程，简化了程序的编写。

统一寻址创建了一块托管内存（managed memory），这是在 CPU 和 GPU 共享的内存，它在 CPU 和 GPU 之间架起了桥梁。这块托管内存 CPU 和 GPU 都能访问通过单一指针访问得到，最关键的一点是，系统会自动地在 host 端和 device 端转移在 Unified Memory 内存分配的数据，这样就好像看起来 CPU 内存好像运行在 GPU，GPU 内存好像运行在 CPU。

CUDA 统一内存优化 DeepUM: Tensor Migration and Prefetching in Unified Memory
利用 CUDAUnified Memory，训练超出 GPU 内存容量的 DNN。其实 Unified Memory 允许通过缺页异常来训练超出 GPU 内存容量的 DNN，但是页面的迁移带来了很大的开销。DeepUM 使用一种新的关联预取技术来隐藏页面传输的开销。

UM 的缺点：

由于 UM 是虚拟内存空间，因此对于 GPU 上的每个内存请求都要进行地址转换，这可能严重影响性能

处理缺页异常会在 CPU 和 GPU 之间迁移页面，这会带来很大的 I/O 开销。

但是 UM 也有很多好处：

使用纯粹的 GPU 内存，无法运行内存占用高于 GPU 内存容量的 CUDA 核函数，而 UM 可以利用缺页异常按需迁移页面，因此可以训练更大的 DNN。

使用纯粹的 GPU 内存可能会有比较严重的内存碎片问题，DNN 在训练过程中有频繁的内存分配和释放操作，尽管 tensorflow 和 pytorch 等主流 DL 框架都有自己的 GPU 内存管理机制，但是仍然存在一些内存碎片问题。而 UM 是虚拟内存空间，所有的内存对象都是以 4KB 的页为基础单元的，这会减小内存碎片问题，更有可能训练更大的 DNN。

DeepUM 实现了一些优化技术来减小 UM 带来的开销：

DeepUM 修改了一项最初为 cache line 预取而开发的相关预取技术来预取 GPU 页面。DeepUM 在许多预取技术中选择了相关预取（correlation prefetching）。

page fault handler 监控异常访问，因此 DeepUM 可以从 page fault handler 这里获得 fault pages 之间的关系。

DeepUM 利用了一个事实：在 DNN 训练时，核函数执行模式和内存访问模式大多是固定、重复的。因此可以记忆这些重复的模式，然后进行相关预取。

DeepUM 的相关表记录了在训练时核函数的执行历史以及页面访问，它通过相关表预测接下来会执行哪个核函数，然后预期页面。传统的相关预取使用单个表来存储历史并记录 CPU cache line 之间的关系，DeepUM 相关预取使用了两个不同的表（核函数的执行历史、页面访问模式）。

采取了两种优化技术来减少页面异常处理的时间：page pre-eviction，page invalidation。

UM 构建了一块统一的内存空间，CPU 和 GPU 都能访问。从 Pascal 架构开始，NVIDIA GPU 就有了页面迁移引擎（page migration engine），通过利用缺页异常机制（page fault mecheni***），GPU 可以拥有一个虚拟内存系统。当 GPU 访问一个不在 GPU 内存中的页面时，就会触发缺页中断，然后 NVIDIA 设备驱动将页面迁移到 GPU 内存里。因此，UM 允许在 GPU 上执行超出 GPU 内存的程序。

左侧是 CPU 的统一内存空间（物理位置位于 CPU 内存，即主存）、右侧是 GPU 的统一内存空间（物理位置位于 GPU 内存），

在图 a 中，page1 和 page2 都位于 CPU 的统一内存空间，GPU 访问 page1，触发缺页中断（如图 b），NVIDIA 设备驱动将 page1 从主存迁移到 GPU 内存上，然后重新对 page1 的访问。

尽管 UM 有这些好处，但是 UM 的缺点很明显，那就是缺页异常处理的开销太大。SM 中有 TLB，在处理异常时，TLB 无法运行，等到异常处理完毕后，TLB 才能继续；缺页异常还会引入很大的 I/O 开销（CPU 和 GPU 之间页面迁移）。因此可以使用 CUDA API 如 cudaMemPrefetchAsync()、cudaMemAdvise() 来减少缺页异常。

NVIDIA Page Fault Handler

fault buffer : fault buffer 是 GPU 上的一个循环队列，存储了异常访问信息（faulted access information）。GPU 可以同时产生多个异常。fault buffer 里面可以存储对于同一个页面的多次异常访问信息。

UM block : 1 个 UM block 最多由 512 个连续的页面组成，也就是 4KB*512=2MB。每个 UM block 都包含了所有页面的信息，比如这些页面存在 CPU 还是 GPU、读写权限等。NVIDIA 以 UM block 的粒度来管理页面，如果一个 UM block 包含了 faulted page，那么这个 UM block 被称为 faulted UM block。

GPU 页面异常处理（fault page handler）的流程

首先，NVIDIA 驱动程序从 GPU 的故障缓冲区中获取发生故障的页面地址和访问类型（步骤 1）。

然后，NVIDIA 驱动程序预处理这些故障（步骤 2），它移除重复的地址并根据它们的 UM 块进行分组。

接下来，NVIDIA 驱动程序检查每个故障 UM 块的可用 GPU 内存空间（步骤 3）。

如果没有可用的 GPU 内存空间用于故障 UM 块，它会将一些页面从 GPU 驱逐到 CPU（步骤 4）。

然后，它在 GPU 中填充故障页面（步骤 5）（也就是为故障页面分配 GPU 内存空间），

并将页面传输到 GPU（步骤 6）。

当传输完成时，UM 块的故障页面被映射到 GPU（步骤 7）。

这个过程重复，直到所有的故障 UM 块都被处理（步骤 8）。

最后，NVIDIA 驱动程序向 GPU 发送一个重播信号，故障处理器完成处理（步骤 9）。

DeepUM 修改了一个最初用于缓存行预取的相关预取技术来预取 GPU 页面。来隐藏页面传输的开销。这种技术是完全自动的，对用户是透明的。

此外，文章还提出了两种优化技术，以尽量减少 GPU 错误处理的时间。

一种是基于相关表信息的页面预先驱逐。当 GPU 内存被过度订阅时，页面驱逐会增加页面错误处理时间，因为页面驱逐逻辑位于页面错误处理例程的关键路径上。

另一种优化是在页面驱逐受害者预计不再被 PyTorch 使用时，使 GPU 内存中的页面失效。这种优化删除了 CPU 和 GPU 之间不必要的内存流量。

DeepUM 的整体架构

DeepUM 由两部分组成：DeepUM Runtime 和 DeepUM Driver

DeepUM runtime

DeepUM runtime 为 CUDA 内存分配函数提供封装函数，来把所有 GPU 内存分配请求转换为 UM 分配请求。通过在 UM 空间里面分配 GPU 内存对象，实现对 GPU 内存的超额分配。此外，DeepUM runtime 为 CUDA 核函数启动命令和其他 CUDA 库函数（比如 cuDNN cuBLAS）提供了封装函数。

DeepUM runtime 管理着 execution ID table，这个表记录了核函数启动历史，以及核函数名称、参数的哈希值。当一个新的核函数启动命令进入到 deepUM runtime 时，它会计算该核函数名称、参数对应的哈希值，然后在表里查询有没有同样的哈希值，如果有的话，就把对应的 execution ID 赋给这个核函数，如果没有的话，就把新的哈希值记录到表中，并赋给这个核函数一个新的 execution ID。最后，DeepUM runtime 在执行这个新的核函数启动命令之前，会把一个 CUDA callback 函数排队到 CUDA runtime，这个 callback 函数会把接下来的核函数启动命令对应的 execution ID 传递给 DeepUM driver，DeepUM driver 在相关预取中使用这个 execution ID。

DeepUM driver

DeepUM driver 处理 GPU 缺页异常，并且把页面预取到 GPU。

核函数执行模式和内存访问模式是固定的、重复的，因此可以记忆下来，进行相关预取。DeepUM driver 管理 correlation table，记录了在 DNN 训练过程中的核函数执行历史和页面访问。通过相关表中的信息预测接下来会执行哪个核函数，进行相关预取。

DeepUM driver 中有四个线程：fault handling thread、correlator thread、prefetching thread、migration thread

fault handling thread : 使用 NVIDIA 驱动中的函数（比如访问 fault buffer、给 GPU 发送重放信号）处理缺页异常。DeepUM driver 拦截发往 NVIDIA driver 的缺页异常中断信号，然后 fault handing thread 读取 fault buffer，将读取到的异常访问信息传递给其他三个线程。fault queue 存储异常页面对应的 UM block 的地址，fault queue 拥有最高优先级，以保证 GPU 尽快重放异常访问。

correlator thread : 管理相关表，它根据来自 fault handing thread 的异常访问信息更新相关表。详见 4.2

prefetching thread : prefetching thread 查找相关表并根据出现异常的块地址计算要预取的 UM block 地址。然后，它将预取命令加入预取队列，这是一个单生产者/单消费者队列。预取命令包括要预取的 UM block 地址和预测将使用的 UM block 的 execution ID。

migration thread : 在 CPU 和 GPU 之间迁移 UM block。fault queue 的优先级高于 prefetch queue，因此当 fault queue 空时，才会处理 prefetch queue。

原始的相关预取 (Correlation Prefetching)

基于对的相关预取（pair-based correlation prefetching）在相关表中记录了 miss addrssed 的序列。当 miss 时，会查询相关表，预取所有和 miss address 相关的 address。

如下图 (a) 所示，相关表中每一行记录的是一个不同的 miss address。miss address 序列是 abca，当前的 miss address 是 c，因此 Last 指向 c，SecondLast 指向 b。

DeepUM 中的相关预取技术，基于原始的「相关预取」技术进行了修改

旨在通过预取 CUDA 内核预期访问的页面来减少页面错误。与原始的相关预取不同，DeepUM 使用两种类型的相关表：执行 ID 和 UM 块。

这两种类型的表都是单级 ( = 1)，因为预取线程执行链式操作。此外，由于 DNN 工作负载的特性，没有必要维护多个级别。

注意：DeepUM 中的相关预取是以 UM block 为单位的！而不是 cache line 或者 page！

执行 ID 相关表（简称执行表）:

该表记录了 CUDA 核函数的 execution ID，execution ID 来自 DeepUM runtime。

记录了 CUDA 核心的执行 ID 的执行历史，整个系统中只存在一个这样的表。

图 6 显示了一个执行表的示例。执行表的每个条目都保存了一组相关的执行 ID。

每组由四个执行 ID 组成。前三个 ID 代表最后一个核心（更新表时正在执行的核心）之前刚刚执行的核心。因此，最后一个 ID 表示预取发生时接下来要执行的核心。

例如，执行 ID 为 0 的条目有一个记录（7，9，92，75）。这个记录意味着已经执行了执行 ID 为 7，9，和 92 的核心，执行 ID 为 0 的核心当前正在执行。它预测接下来要执行的核心的执行 ID 为 75。

这个执行表的作用就像是一本历史记录册，它记录了每个核心执行的顺序，这样在预取时就可以根据这个顺序来预测下一个可能会执行的核心，从而提前预取相应的页面，提高性能。

每个条目包含的记录数是可变的，也就是说，一个核心的后继核心的数量是可变的。因此，每个条目可以持有所有后继核心执行 ID 的历史。DeepUM 选择这种方案是为了尽可能准确地预测下一个要执行的核心。即使预测下一个要访问的 UM 块的结果不准确，成本也不高，但预测下一个要执行的核心的结果不准确，成本就很高。

UM 块相关表（简称块表）记录的是 UM 块级别的历史，而不是记录错误页面地址的历史。选择这种粒度的原因有两个。

一个是大规模 DNN 有太多的页面地址需要管理。

另一个是让 DeepUM 与 NVIDIA 驱动程序具有相同的页面管理粒度更有效。

图 7 显示了一个块表的示例。每个执行 ID 都有一个块表，记录了相应 CUDA 核心内的 UM 块访问历史。它类似于原始相关预取中使用的表。然而，一个块表包含了指向最后一个被预取的 UM 块的结束 UM 块的地址，以及指向在相应核心执行中首次出错的 UM 块的开始 UM 块的地址。这两个指针被用来实现链式操作。在当前执行的核心转换过程中，开始 UM 块和结束 UM 块都会被捕获。结束 UM 块是页面所在的 UM 块，该页面在执行 ID 转换之前最后出错。开始 UM 块是第一个出错的页面所在的 UM 块，这个错误发生在执行 ID 转换之后。

https://www.cs.utexas.edu/~skeckler/pubs/HPCA_2016_Paged_Memory.pdf

Unified Memory 是如何处理 page fault 的

这里的 demand paging 的概念和 CPU 的相同，就是访问页时，发生 page fault，然后获取 page, 也被称为 memory oversubscription，但是与 CPU 不同，因为 GPU 没有处理 precise exception 的能力，也没有处理 page fault 的能力。当一个 warp 的遇到 page fault 时，GPU 可以：

暂停所有 warp 的执行

或者暂停当前 warp 的执行，调度其他可以执行的 warp

显然第一种代价更大，因此 GPU 按照第二种执行，内部也就需要存放一个 page fault queue。而后具体的处理 page fault，搬运 page 的操作，超出了 GPU 的能力范围，需要 CPU 执行或者 CPU 发送命令到 GPU 执行。

具体的流程：

GPU 内部单元向 TLB 发起虚实地址转换请求，TLB miss，而后在 GPU MMU page walk，查询页表，依然 miss 后，触发 page fault。

GPU MMU 向内部单元发送该地址翻译失败响应，挂起该 warp。

GPU 将 page fault 存到 page fault queue 中，向 CPU 发起 page fault 异常请求。

CPU 执行 GPU runtime 程序从 page fault queue 中读取 page fault 的请求，不同于 CPU 处理 CPU page fault 的直接处理方式，GPU 可能会同时发生多个 page fault，于是：对 page fault queue 中的地址进行排序 sort，Sort 之后，方便在 CPU 的页表中进行查找

不同于 CPU 处理 CPU page fault 的另一点是，不仅会处理 GPU 的 page fault 对应的页，也会进行 prefetch 其他的页，预取一些页进入 GPU 内存，提高 page fault 的利用效率

而后根据该 page 的属性，CPU 需要 unmap 这个 page，将该页放到 GPU 的内存中，同时在 GPU 的页表中增加这个 page，并 flush 这个 GPU uTLB

完成上述操作后，GPU 才可以重新将 page fault 的 warp 重新调度

后面又发现 GPU 处理 evict 和 fetch 的操作是顺序的，以保证正确性，因此他们提出可以在中断处理时，先 evict 一个页，因为 GPU 内存向 CPU 内存写，比读要快，因此 evict 和 fetch 操作可以并行执行。

https://ramyadhadidi.github.io/files/kim-asplos20.pdf

CUDA Unified Memory 统一内存使用注意

一方面，只需要定义一个指针即可在主机和设备端通用；另一方面，去掉了显式的内存拷贝，大大缩短了代码数量和编写、维护难度。

在 CUDA 编程使用 Unified Memory 的时候有几个注意点：

Unified Memory has three basic requirements:

1, a GPU with SM architecture 3.0 or higher (Kepler class or newer)

2, a 64-bit host application and operating system, except on Android

3, Linux or Windows

（4）再接着在 CUDA 11.2 引入了 stream ordered memory allocator（流顺序内存分配器），使用 cudaMalloc 和 cudaFree 管理内存分配会导致 GPU 在所有正在执行的 CUDA 流之间进行同步。Stream Order Memory Allocator 使应用程序能够通过启动到 CUDA 流中的其他工作（例如内核启动和异步拷贝）来对内存分配和释放进行排序

10.CUDA 编程手册中文版---附录 F 流序内存分配_cudamallocasync-CSDN 博客，
使用 NVIDIA CUDA 流顺序内存分配器，第 1 部分
 jhang：CUDA 编程入门之 Stream-Ordered Memory Allocator(1)

（5）在 CUDA 11.7 引入了 Lazy loading，内核延迟加载，提高了内核加载效率。CUDA Runtime 在程序初始化期间将不再加载所有模块，除非这些模块包含 managed variables，程序能够仅加载实际需要使用的内核，在初始化过程中节省时间。这减少了 GPU 存储器和主机存储器上的内存开销。

（6）最终在 CUDA 12，NVIDIA 走到了一个新高度，通过 NVLINK C2C 实现硬件层面的 cache level coherence，既保证了速度又确保了可编程性。

在 Grace Hopper 系统中，处理器（CPU 或 GPU）可以直接通过 NVLink-C2C 互连访问另一个处理器的物理内存（CPU 和 GPU 共享一个虚拟内存空间（即系统内存））。这种访问以缓存行粒度进行，CPU 端的传输大小为 64 字节，GPU 端为 128 字节。所访问的内存被透明地缓存在两个处理器的高速缓存层次结构中。此外，两个处理器缓存是完全一致的。原子操作也可以在 NVLink-C2C 互连上执行，允许任何处理器以原子方式读取和修改物理内存位置。这些特性是在硬件级别实现的，并且不需要用户干预，遵循 Arm 的 AMBA CHI 协议。

在 Grace Hopper 内存系统中，Grace CPU 具有一个称为系统内存管理单元 (SMMU) 的独特硬件，该硬件由 ARM 的 SMMUv3 规范定义

Grace Hopper 系统使用两个不同的页表：一个全局页表和一个 GPU 专用页表。选择用于内存分配的页表取决于使用的特定程序级 API。

一个集成的系统页表。Grace Hopper 系统引入了一个位于 CPU 内存中的系统范围页表。操作系统直接访问这个页表，创建并管理页表项（PTE）。SMMU 使用这个页表为 CPU（在用户应用程序需要时）和 GPU（通过 NVLink-C2C 互连请求时）提供虚拟到物理地址转换。系统范围页表中的内存页面可以物理上存在于 CPU 或 GPU 的内存中，并且它们使用系统页面大小，该页面大小由操作系统定义并受 CPU 架构能力的限制。当使用 Grace 处理器时，页面大小为 4KB 或 64KB。

GPU 专用页表。Grace Hopper 系统保留了 NVIDIAGPU 早期版本中的本地 GPU 页表。该页表位于 GPU 内存中，只能由 GPU 访问，并在托管内存的物理位置在 GPU 上时存储与 cudaMalloc 分配和 cudaMallocManaged 分配相对应的虚拟到物理地址映射。此页表使用的页面大小为 2MB

在数据位于 CPU 内存的情况下，当 GPU 的高速缓存中保存有虚拟到物理地址的映射时，在 Grace Hopper 系统上访问一个虚拟地址位置的工作流程：

GPU 线程访问一个虚拟地址。

数据没有被缓存在 GPU 缓存层次结构中。这会导致缓存未命中的情况。

在 GPUTLB（Translation Lookaside Buffers）中查找虚拟地址以进行虚拟到物理地址的转换。由于转换已经被缓存，所以使用它来进行对物理内存的访问。

GMMU 使用 NVLink-C2C 互连以 cacheline 为粒度来发起直接内存访问 (DMA)。

请求的访问从 CPU 内存执行，并且被发送回 GPU。

访问完成并且内存被缓存在常规 GPU 缓存层次结构中。

各代 GPU MMU 的演进（从 P100 到 B100）

1. Pascal 架构（P100，2016 年）
- MMU 功能：
- 基础地址转换：支持 2 级页表（类似传统 GPU MMU），虚拟地址空间为 40 位。
- 初步统一内存：通过 CUDA 6.0 引入 Unified Memory，但需手动数据迁移（`cudaMemcpy`），效率较低。
- 基本隔离：依赖 PCIe 的 SR-IOV 实现虚拟机分片，MMU 仅支持简单权限控制。
- 限制：
- TLB 容量小（L1 TLB 约 64 条目），高并发计算时频繁未命中。
- 虚拟化性能差，Hypervisor 需频繁干预地址转换。
2. Volta 架构（V100，2017 年）
- 关键改进：
- 增强的统一内存：支持按需页面迁移（Page Migration），GPU 可触发缺页中断，驱动自动迁移数据。
- 多级页表：引入 4 级页表（48 位虚拟地址），支持更大显存映射。
- 虚拟化初步优化：硬件辅助的 TLB 无效化指令（减少 Hypervisor 开销）。
- 性能提升：
- L2 TLB 容量提升至 512 条目，支持 2MB 大页，AI 训练任务提速约 20%。
- 应用场景：
深度学习训练（如 ResNet）受益于大页和按需分页。

3. Ampere 架构（A100，2020 年)
- 关键改进：
- 多实例 GPU（MIG/Multi-InstanceGPU）： MMU 支持显存硬分区（每个实例独立地址空间），最多分割 7 个实例。
- 硬件虚拟化（Stage2）：
引入类似 ARM SMMU 的 Stage2 转换，虚拟机直接管理客户页表（VA→IPA），Hypervisor 控制 IPA→PA。
- 安全扩展：
显存加密引擎（AES-XTS），保护多租户场景数据。
- TLB 优化：
L2 TLB 容量增至 2048 条目，支持 1GB 大页。
- 性能提升：
虚拟化延迟降低 50%，大模型训练（如 GPT-3）显存利用率提升 30%。

4. Hopper 架构（H100，2022 年）
- 关键改进：
- 动态地址扩展：支持 57 位虚拟地址（未来兼容性），适应百亿参数模型。
- 增强虚拟化（vGPU 2.0）：
硬件沙盒化 MMU，每个 vGPU 实例独立加密上下文。
- 智能预取：
基于线程块访问模式的 TLB 预取算法，推荐系统推理吞吐量提升 40%。
- 显存压缩：
稀疏页表压缩（如 MoE 模型），减少显存占用。
- 应用场景：
超大规模推荐系统（如 Meta 的 DLRM）、机密计算（医疗 AI）。

5. Blackwell 架构（B100，2024 年）
- 关键改进：
- 内存池：
MMU 支持跨 GPU/CPU 的一致性内存访问（CXL.mem），统一地址空间扩展至 64 位。
- 显存优化：
针对 HBM3e 的 3D 堆叠显存设计低延迟转换路径，减少高密度计算开销。
- 量子安全加密：
集成抗量子加密算法（如 CRYSTALS-Kyber），应对未来算力攻击。
- 自适应页表：
动态调整页表层级（4 级/5 级），优化稀疏与密集访问场景。
- 性能提升：
千亿参数模型训练（如 GPT-5）显存效率提升 50%，边缘推理延迟降低 35%。

演进趋势总结

架构	GMMU 关键创新	性能提升方向	典型场景
P100	基础统一内存、2 级页表	初代 AI 计算支持	传统 HPC、小规模训练
V100	按需分页、4 级页表	大模型训练效率	深度学习框架（TensorFlow）
A100	MIG 分区、Stage2 虚拟化、显存加密	多租户隔离、安全增强	云 AI、多任务推理
H100	动态地址扩展、智能预取、稀疏压缩	超大规模模型支持、低延迟推理	推荐系统、机密计算
B100	内存池、3D 显存优化、量子安全	跨设备一致性、抗未来威胁	千亿模型训练、边缘

对上层软件带来的好处

1. 显存优化：
- 使用 `cudaMallocManaged` 时启用大页（`hugePage` 标志），减少 TLB 未命中。
2. 虚拟化配置：
- 在云环境中启用 MIG 或 vGPU，利用硬件隔离提升多租户性能。
3. 安全实践：
- 通过 `nvidia-***i` 启用显存加密（如 `-fgpu` 参数）保护敏感数据。
4. 未来兼容性：
- 针对 CXL 内存池设计分布式训练框架，减少数据迁移开销。

参考资料

函谷叨客：【研究综述】浅谈GPU通信和PCIe P2P DMA

CUDA Unified Virtual Address Space & Unified Memory

Introducing Low-Level GPU Virtual Memory Management

《GPUVM: GPU-driven Unified Virtual Memory》
《An Evaluation of Unified Memory Technology on NVIDIA GPUs》
《In-Depth Analyses of Unified Virtual Memory System for GPU Accelerated Computing》
《Interplay between Hardware Prefetcher and Page Eviction Policy in CPU-GPU Unified Virtual Memory》
《Harnessing Integrated CPU-GPU System Memory for HPC: a first look into Grace Hopper》
李常青：[文献翻译] Harnessing Integrated CPU-GPU System Memory for HPC: a first look into Grace Hopper

NVIDIA 的 Blackwell 架构：解析 B100、B200 和 GB200

CUDA02 - 访存优化和Unified Memory
Phoenix Studio：CUDA|Unified Virtual Address|Unified Memory
GPU Microarch 学习笔记【2】Unified Memory
https://ramyadhadidi.github.io/files/kim-asplos20.pdf
https://www.cs.utexas.edu/~skeckler/pubs/HPCA_2016_Paged_Memory.pdf
GPU Microarch 学习笔记【2】Unified Memory
CUDA统一内存优化DeepUM: Tensor Migration and Prefetching in Unified Memory
SoJGooo：cuda统一内存优化DeepUM: Tensor Migration and Prefetching in Unified Memory
【论文笔记】【存储】DeepUM: Tensor Migration and Prefetching in Unified Memory

G10: Enabling An Efficient Unified GPU Memory and Storage Architecture with Smart Tensor Migrations

OC-DNN: Exploiting Advanced Unified Memory Capabilities in CUDA 9 and Volta GPUs for Out-of-Core DNN Training
DeepUM: Tensor Migration and Prefetching in Unified Memory
《PTX与CUDA：性能、兼容与生态——赵家程中科院计算所处理器芯片全国重点实验室中科加禾》

更多「Ethan」精彩内容，欢迎点击「阅读原文」