# NUMA対応CPUピニング ## 定義 NUMA(Non-Uniform Memory Access)ノードとは、CPU・GPU・NIC・メモリが物理的に近接して配置され、同一ノード内のアクセスがノード間アクセスより高速になるハードウェアの論理グループである。NUMA対応CPUピニングとは、プロセス(およびそのスレッド)を、対象GPUが接続されたNUMAノードのCPUコアに明示的に固定(`numactl --cpunodebind`・`taskset`・cgroup `cpuset`)し、同時にそのプロセスのメモリ割り当ても同じNUMAノードに固定(`--membind`)することで、クロスNUMAアクセスに伴うレイテンシ増を回避する手法である。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 3 OS, Docker, and Kubernetes Tuning for GPU-Based Environments]]) Linuxの既定のNUMAバランシングはAIワークロードには不十分であり、OSスケジューラがプロセスをNUMAノード間で移動させ得るため、明示的なピニングが必要になる。ローカルNUMAノードのメモリアクセスレイテンシは約80ns、リモートは約139nsであり約75%増加する。8GPUノードでGPU0-3がNUMAノード0、GPU4-7がノード1に接続されているような構成では、`nvidia-smi topo -m`でGPUごとのNUMA affinityを動的に取得し、各訓練プロセスを対応するノードにバインドする。PyTorchのDataLoaderでは、`worker_init_fn`にクロージャでNUMAノードとCPUリストを渡し、各ワーカープロセス内で再度バインドを適用する(CUDA API呼び出しはワーカー内で行わない)。ページロックメモリ(`pin_memory=True`)や`non_blocking=True`のH2Dコピーと組み合わせることで、データ準備からGPU転送までのパスをすべてローカルメモリ上に保つ。実運用では5〜10%のスループット改善とジッタ低減が報告される。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 3 OS, Docker, and Kubernetes Tuning for GPU-Based Environments]]) Grace Blackwell/GH200のような統合CPU-GPUスーパーチップは、NVLink-C2Cにより最大約900GB/sのコヒーレントなCPU-GPUメモリアクセスを提供するが、LinuxはCPU DRAMとGPU HBMを依然として別々のNUMA/デバイスメモリとして扱うため、NUMAピニングの価値は完全には失われない。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 3 OS, Docker, and Kubernetes Tuning for GPU-Based Environments]]) 『詳解 システム・パフォーマンス 第2版』6章は、CPUスケジューラの側からNUMA対応を補足する。NUMA対応カーネルはCPU・メモリリソースを局所化されたグループとして自動検出し、NUMAアーキテクチャを反映したトポロジ(Linuxでは「スケジューリングドメイン」、ルートドメインを頂点とする)に組織することで、あらゆるメモリアクセスのコストを推計できるようにする。CPUだけをバインドする方法として、taskset(1)コマンド(CPUマスクや範囲でCPUアフィニティを設定)、cpuset機能(CPUをグループにまとめ、排他的cpusetにするとほかのプロセスがそのCPU群を使えなくなりキャッシュのウォーム度が保たれる)がある。numactl(8)はCPUバインドとメモリノードへのバインドの両方を設定できるとして7章に接続される。マルチプロセッサランキューの文脈でも、CPUごとにランキューを分けるとメモリの局所性が上がりスレッド同期(ミューテックスロック)のコストを避けられる一方、ランキューがグローバルに共有されるとスケーラビリティが損なわれると説明される(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.2.3, §6.4.2.4, §6.9.6, §6.9.7)。 ## 横断的知見 - 『詳解 システム・パフォーマンス 第2版』7章は、UMA(共有システムバスで均一レイテンシ)対NUMA(CPUインターコネクト経由でローカル1ホップ/リモート2ホップ以上のレイテンシ差)というハードウェアモデルと、numactl(8)の--membind/--physcpubindによる明示的バインドの必要性を一般論として説明する。これは、AI Systems Performance Engineering本のGPUワークロード向けNUMA対応CPUピニング(ローカル約80ns対リモート約139nsという実測レイテンシ差、numactl --cpunodebind/--membindの併用)が依拠している基礎メカニズムそのものであり、両ソースは「OSの既定スケジューリングだけではNUMA局所性が保証されないため明示的なバインドが要る」という結論で一致する。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] §7.3.1.2, §7.6.4, [[@2025__OReilly__AI Systems Performance Engineering - Chapter 3 OS, Docker, and Kubernetes Tuning for GPU-Based Environments]]) - 6章の「CPUだけのバインド(taskset/cpuset)」と7章・AI本の「メモリも含めたNUMAバインド(numactl --membind)」は別レイヤーの操作であり、GPUワークロードではCPU側のtasksetだけでは不十分でメモリノードのバインドが必須になる。6章はCPUスケジューラのランキュー分割によるメモリ局所性向上を一般原理として述べるにとどまるが、AI Systems Performance Engineering本はこの原理をGPU接続NUMAノードという具体的なトポロジに適用し、5〜10%のスループット改善という定量的な効果まで示す。「CPUバインドはメモリバインドと組み合わせて初めて効果を発揮する」という関係が3ソースを通じて確認できる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.9.6, §6.9.7, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] §7.6.4, [[@2025__OReilly__AI Systems Performance Engineering - Chapter 3 OS, Docker, and Kubernetes Tuning for GPU-Based Environments]]) ## 未解決の問い - クロスNUMAレイテンシの75%増という数値は特定のデュアルソケット構成での実験値であり、AMD EPYC・Intel Xeon・ARM系サーバなど異なるCPUアーキテクチャでどこまで一般化できるか。 - Grace BlackwellのようなNVLink-C2C統合アーキテクチャが普及した場合、従来型のCPUピニングの重要性はどの程度低下するか、それとも「CPU DRAM対GPU HBM」という新しい形の局所性管理が必要になるだけか。 - コンテナ・Kubernetes環境でNUMAピニングのポリシーを子プロセス(fork/spawn)にどこまで確実に伝播できるか、ランタイムやカーネルごとの違いはどこまで実証されているか。 ## 関連 - ソース: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 3 OS, Docker, and Kubernetes Tuning for GPU-Based Environments]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] - エンティティ: [[NVIDIA GH200]] / [[Kubernetes]] / [[NVIDIA]] - 関連概念: [[GPU多重化(MPS・MIG)]] / [[GPUクラスタスケジューリング]] / [[NUMAメモリ配置]](OSカーネル一般のNUMA/UMAハードウェアモデルとnumactl(8)の基礎解説) ## 出典 - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 3 OS, Docker, and Kubernetes Tuning for GPU-Based Environments]](§NUMA Awareness and CPU Pinning, §NUMA-Friendly Memory Allocation and Memory Pinning) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] §7.3.1.2, §7.6.4 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]](§6.2.3 ランキューとメモリ局所性・§6.4.2.4 NUMAグループ/スケジューリングドメイン・§6.9.6 CPUバインド・§6.9.7 排他的cpuset)