如果您是应用程序开发者或集群管理员，可能已经意识到非统一内存访问（NUMA）会对系统性能产生显著影响。当应用程序未能充分感知 NUMA 架构时，性能表现往往会出现不一致且难以预测的情况。
面对这些挑战，NVIDIA 为其硬件一致性平台（如 GH200、GB200 和 GB300）的驱动程序推出了基于相干驱动的内存管理（CDMM）模式。CDMM 使 NVIDIA 驱动程序能够接管 GPU 显存的控制与管理，而非依赖操作系统。这种机制为应用程序提供了更精细的内存控制能力，使其能够将数据放置在合适的内存空间中，从而实现更高的性能表现。
在本博客中，我们将探讨 NUMA 与 CDMM 之间的区别，以及它们对应用性能的影响。此外，我们还发布了关于这一主题的白皮书，欢迎查阅以获取更多详细信息。
什么是 NUMA？
NUMA 模式是 NVIDIA 驱动在硬件一致性平台上的当前默认模式。该模式向操作系统统一暴露完整的 CPU（主机）内存和 GPU（设备）内存，使得标准 Linux API（如 malloc 和 mmap）以及 CUDA API 均可在 CPU 和 GPU 上进行内存分配。同时，NUMA 模式支持通过用户空间 API 实现 CPU 与 GPU 之间的动态内存迁移，也可由内核自动完成内存迁移，以优化系统资源的利用效率。
需要考虑的一个重要问题是，NUMA 模式会将 GPU 显存视为统一的内存资源池，从而在一定程度上削弱了将 GPU 显存与通用操作系统功能进行严格隔离的能力。在典型的 NUMA 行为下，内存访问可能溢出至 GPU 端，这种数据流动方式可能无法满足特定应用程序对性能的要求。
因此，NVIDIA 提出了一种替代方案：基于相干驱动的内存管理（CDMM）模式。
什么是硬件一致性平台？
多个 NVIDIA 系统（包括 GH200、GB200 和 GB300）在 CPU 与 GPU 之间采用了直接的 NVLink 芯片到芯片（C2C） 连接。这种设计带来了 PCIe 连接系统所不具备的重要特性——硬件一致性内存，使得 CPU 和 GPU 能够直接访问彼此的内存，从而实现更高效的协同计算。
这可能会对依赖 NUMA 特定行为的应用程序产生一些意外影响。例如，操作系统可能将 GPU 显存用于非预期的用途，如缓存文件，或在避免内存分配请求因显存不足（OOM）而失败时进行干预。对于某些应用程序和工作流程，尤其是那些针对特定 CPU 与 GPU 显存布局（如 Kubernetes 环境）进行优化的场景，此类行为可能带来不利影响。
新的 CDMM 模式有效应对了这些挑战，在 Kubernetes 等应用场景中展现出显著优势。
NUMA 如何影响 Kubernetes
由于 Kubernetes 是管理大型 GPU 集群的常用方式，因此在 NUMA 模式下运行 Kubernetes 时，可能会出现一些特定的异常行为。这些行为不仅可能影响性能，甚至可能干扰应用程序的正常运行。
- 内存过多报告： Kubernetes 在统计系统内存时错误地将 GPU 显存纳入其中，导致 Pod 申请的内存总量超过实际可用的系统内存，从而引发 OOM（内存溢出）故障。
- Pod 显存限制同时作用于 GPU 显存和系统内存： Kubernetes 中的 Pod 显存限制本应仅针对系统内存设计，但由于每个 GPU 被作为独立的 NUMA 节点暴露给系统，该限制被错误地同时应用于 GPU 显存和系统内存，违反了 Pod 规约 API 的预期行为。
- GPU 显存的隔离缺失： 默认情况下，Kubernetes Pod 可访问其所在 NUMA 节点内的全部显存资源，包括 GPU 显存。这使得容器可能在自身无法使用的 GPU 上分配显存，破坏了资源隔离机制。
基于这些原因，我们建议在使用 Kubernetes 时采用 CDMM 模式。
什么是 CDMM？
CDMM 是 NVIDIA 驱动程序的一种替代操作模式，旨在防止将 GPU 显存作为软件 NUMA 节点暴露给操作系统。在此模式下，NVIDIA 设备驱动程序直接管理 GPU 显存，使其与 CPU 的系统内存相互隔离。这一设计借鉴了通过 PCIe 连接的 GPU 架构模型，其中 GPU 显存与系统内存是独立存在的。
在 CDMM 模式下，CPU 内存由 Linux 内核管理，而 GPU 内存则由 NVIDIA 驱动程序负责管理。这意味着 GPU 显存的管理权在 NVIDIA 驱动程序手中，而非操作系统。驱动程序能够直接控制显存的分配与使用方式，从而实现更精细的资源调控，通常也有助于提升应用程序的运行性能。
CDMM 对 CUDA 开发者有何影响
CDMM 的主要影响在于迁移系统分配的内存。在当前 CDMM 的实现中，系统分配的内存不会被迁移到 GPU。尽管 GPU 仍可通过 C2C 链路访问这部分内存，但内存页不会发生迁移。
例如，当应用使用提示鼓励调用 cudaMemPrefetchAsync()、cudaMemPrefetchBatchAsync()、cudaMemDiscardAndPrefetchBatchAsync() 和 cudaMemAdvise(SetPreferredLocation) 等函数进行迁移时，页面将不会发生迁移。
CDMM 对系统管理的影响
当系统运行在 CDMM 模式时，虽然仍存在与 GPU 对应的 NUMA 节点，但这些节点不会向操作系统提供任何内存。因此，使用 numactl 或 mbind 等工具对 GPU 显存进行操作将不会产生任何效果。对于 GPU 显存的管理，建议避免在 CDMM 模式下使用此类工具。不过，这些工具仍可用于管理系统的主机内存。
CDMM 目前是基于 Kubernetes 的 GPU Operator 部署的默认模式，要求使用 Linux 驱动程序 580.65.06 或更高版本。若要启用 CDMM，需在加载驱动程序时传入相应的内核模块参数及其值。有关启用 CDMM 模式的具体命令和语法，请参考 CDMM 白皮书。
CDMM 与 NUMA 使用指南
下文重点阐述了 CDMM 与 NUMA 模式之间的主要差异，并探讨了在何种情况下应选择其中某一种模式。
应用程序专用的内存管理
- NUMA 模式： 适用于使用操作系统 NUMA API 并依赖操作系统统一管理整体系统内存（包括 CPU 内存和 GPU 内存）的应用程序。
- CDMM 模式： 适用于需要直接控制 GPU 显存、并绕过操作系统内存管理机制的应用程序。
内存池化
- NUMA 模式：使 GPU 与 CPU 内存整合为统一的内存池，提升内存容量与带宽的协同管理能力，从而优化工作负载性能。
- CDMM 模式：由驱动程序进行内存管理，限制操作系统将 GPU 显存用于通用用途，确保显存专用于 GPU 相关的数据处理。
GPU显存使用情况：可见性与测量方法
- NUMA 模式： 标准工具可报告集成池中 GPU 显存的使用情况，并支持按 NUMA 节点进行筛选，从而呈现完整的系统级显存视图。
- CDMM 模式： 提供对 GPU 显存的精细化控制与更高可见性。由驱动程序管理的 GPU 显存机制，有助于管理员和开发者清晰掌握显存消耗情况，便于性能诊断与优化。
总结
下表重点说明了 NUMA 与 CDMM 模式在显存处理方式上的主要差异。
| NUMA | CDMM | |
| 内存管理机制中，操作系统可管理 CPU 内存，而 GPU 内存则由 NVIDIA 驱动负责管理。 | GPU 显存可作为通用内存池暴露给操作系统 | 也可选择不暴露，以供系统按需使用 |
| 在 CPU 与 GPU 之间，系统支持内存的动态分配与迁移 | 但部分系统分配的内存可能未被迁移到 GPU |
通过深入了解并战略性地实施 CDMM，开发者和管理员能够充分释放 NVIDIA 硬件一致性内存架构的潜力，为 GPU 加速工作负载提供卓越的性能与精准的控制。
如果您使用的是 GH200、GB200 或 GB300 等支持硬件一致性架构的平台，请参考相关白皮书。并考虑启用 CDMM 模式，以实现对 GPU 显存更精细的应用程序控制，特别是在使用 Kubernetes 的场景下。
