**NUMA 节点**是 CPU、GPU、NIC 和内存的**逻辑分组**，这些组件在物理上彼此靠近。访问同一 NUMA 节点内的资源比跨节点访问要快得多。例如，一个运行在 NUMA 节点 0 的 CPU 上的进程如果需要访问 NUMA 节点 1 的 GPU，数据就必须通过节点间链路传输，会产生更高的延迟。实际上，**跨 NUMA 节点的内存访问延迟几乎可以翻倍**。
#### **1.1.2 查看系统 NUMA 拓扑**
你可以用以下两个命令结合查看系统的完整 NUMA 拓扑：
```bash theme={null}
# 查看 CPU/内存的 NUMA 分布
numactl -H
# 查看 GPU 与 NUMA 节点的对应关系
nvidia-smi topo -m
```
`numactl -H` 的输出示例（4 个 NUMA 节点的服务器）：
```bash theme={null}
available: 4 nodes (0-3) # 系统有 4 个 NUMA 节点
node 0 cpus: 0-15 64-79 # 节点 0 拥有这些 CPU 核心
node 0 size: 128827 MB # 节点 0 的本地内存大小
node 1 cpus: 16-31 80-95
node 1 size: 129012 MB
node 2 cpus: 32-47 96-111
node 2 size: 128968 MB
node 3 cpus: 48-63 112-127
node 3 size: 128993 MB
node distances: # 节点间相对访问距离（根据 BIOS 写入 ACPI SLIT 表）
node 0 1 2 3
0: 10 12 12 12
1: 12 10 12 12
2: 12 12 10 12
3: 12 12 12 10
```
`nvidia-smi topo -m` 的输出示例（5 个 GPU 的服务器）：
```
GPU0 GPU1 GPU2 GPU3 GPU4 CPU Affinity NUMA Affinity
GPU0 X NV4 NV4 SYS NV4 48-63,112-127 3
GPU1 NV4 X NV4 SYS NV4 32-47,96-111 2
GPU2 NV4 NV4 X SYS NV4 16-31,80-95 1
GPU3 SYS SYS SYS X PHB 0-15,64-79 0
GPU4 NV4 NV4 NV4 PHB X 0-15,64-79 0
Legend:
X = Self
SYS = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node
PHB = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
PXB = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge)
PIX = Connection traversing at most a single PCIe bridge
NV# = Connection traversing a bonded set of # NVLinks
```
* **矩阵区域**（GPU 之间的交叉格）— GPU 间的互连类型，与 Legend 对应：
* `X` = 自己跟自己
* `SYS` = 经过 PCIe + 跨 NUMA 节点的 CPU 互连，如 QPI/UPI（最慢）
* `NODE` = 经过 PCIe + 同一 NUMA 节点内的 Host Bridge 互连
* `PHB` = 经过 PCIe Host Bridge，即经过 CPU（同一 NUMA 节点内）
* `PXB` = 经过多个 PCIe bridge，但不经过 Host Bridge
* `PIX` = 经过最多一个 PCIe bridge（同一 PCIe switch 下）
* `NV#` = 通过 # 条 NVLink 直连（最快，如 `NV4` = 4 条 NVLink）
* **CPU Affinity 列** — 该 GPU 关联的 CPU 核心编号，如 GPU0 对应核心 48-63 和 112-127
* **NUMA Affinity 列** — 该 GPU 属于哪个 NUMA 节点，**这就是你做 `numactl` 绑定时需要的值**
#### **1.1.3 使用 numactl 进行 CPU pinning**
确认了 GPU 所在的 NUMA 节点后，需要显式指定 NUMA 亲和性（NUMA affinity）——将进程或线程分配到与 GPU 相同 NUMA 节点上的 CPU 核心。这种做法称为 **CPU pinning**。可以使用 `numactl` 实现，两个关键参数：
* `--cpunodebind=
Pinned memory（也称 page-locked 或 nonpageable memory）是一类不能被换出到磁盘的内存。
在上图的例子中，虚拟页号在 TLB 中被找到，并立即转换成物理页号。
**TLB miss**
当虚拟页码在 TLB 中找不到时，就会发生所谓的“TLB 未命中”情况。此时，TLB 必须查询系统的物理内存，以确定对应的物理页码是多少。与 TLB 命中相比，这种查询方式会导致更高的延迟。如果 TLB 已满且发生 TLB 未命中，那么 TLB 中最近最少使用的数据条目会被清除，新的数据条目则会取而代之。在下面的例子中，虚拟页码在 TLB 中不存在，因此 TLB 必须查询物理内存来获取该页码。
参考资料：[How is Virtual Memory Translated to Physical Memory?](https://blogs.vmware.com/cloud-foundation/2020/03/03/how-is-virtual-memory-translated-to-physical-memory/)
MPS 由以下几个组件组成：
* **Control daemon process**：control daemon 负责启动和停止 server，并协调 client 与 server 之间的连接。
* **Client runtime**：MPS client runtime 内置在 CUDA Driver library 中，任何 CUDA 应用都可以透明地使用它。
* **Server process**：server 是多个 client 共享的 GPU 连接，并负责在 client 之间提供并发执行能力。
**MPS 的典型场景是：多个 MPI 进程或多个 CUDA 进程单独都无法占满 GPU 时，通过共享同一块 GPU 并发执行 kernel 来提高 GPU 利用率。** 如果某个程序本身就将 GPU 完全占满到 100%，MPS 并不能让它变得更快，因为利用率无法超过 100%。
**请注意，MPS 并不对 GPU 内存进行分区，因此所有进程将共享整个 GPU 内存空间。MPS 主要负责计算共享和调度。** 问题在于，某个进程可能会申请大量 GPU 内存，导致 GPU 上出现 OOM 错误，从而终止在该 GPU 上运行的所有其他进程。
#### **2.3.2 GPU Instance 和 Compute Instance**
MIG 配置分两层：先创建 GPU Instance（GI），再创建 Compute Instance（CI）。
* **GPU Instance（GI）**：GI 由一组 GPU 切片和 GPU 引擎组成，决定这个 MIG 实例的 GPU 内存容量、带宽和 QoS。
* **Compute Instance（CI）**：CI 是在某个 GI 内继续划分出的计算实例，使用父 GI 的一部分 SM 切片。**CI 主要隔离计算资源，也就是 SM；它不提供独立的 GPU 内存隔离。** 多个 CI 可以共享同一个 GI 的 GPU 内存切片和 DMA、NVDEC 等引擎，但各自拥有独立的 SM 资源。
CUDA 应用会把 CI 及其所属 GI 视为一个 CUDA device；多数场景可以用 `-C` 参数直接创建覆盖整个 GI 的默认 CI。
#### **2.3.3 MIG 设备命名规则**
[MIG 设备名称](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/mig-device-names.html) 描述了实例的资源形态。`xg.ygb` 表示一个 GPU Instance：`xg` 表示使用 `x` 份 GPU 计算切片，`ygb` 表示 GPU 内存容量档位。例如 `3g.40gb` 表示使用 3 份 GPU 计算切片和 40GB 档位的 GPU 内存。如果一个 GI 继续拆成多个 CI，名称会带上 `c`，格式为 `xc.xg.ygb`；例如 `1c.3g.40gb` 表示在 `3g.40gb` GI 内使用 1 份计算切片的 CI。
