ローカルAIのNUMA局所性：メモリ配置がアクセラレーターへのデータ供給速度を変える理由

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Local AI NUMA Locality: Why Memory Placement Changes Accelerator Feed Rate - Zima Store Online

NUMAの局所性はアクセラレーターへのデータ供給速度を変化させます。CPUスレッド、メモリページ、デバイスが近い経路を共有すると、ホスト側の前処理と転送が高速になるためです。

マルチソケットのホームワークステーションでは、すべてのCPUコアから全RAMにアクセスできますが、アクセスコストは均一ではありません。GPUやその他のアクセラレーターは通常、1つのソケットのPCIeルートコンプレックスを介して接続されています。別のノードで前処理を実行し、そこでバッファーを割り当てると、データがデバイスに到達する前にソケット間インターコネクトを通過する可能性があり、競合や変動するレイテンシーが発生します。

NUMAによってホストメモリの距離が可視化される

NUMAシステムでは、CPUとメモリがアクセス距離の異なるノードに分割されます。Linuxでは通常、最初にページフォールトを発生させたCPUにローカルなノードへページが割り当てられます。そのため、モデルの読み込みや入力準備の際のスレッド配置によって、大容量バッファーが物理的に存在する場所が決まることがあります。

LinuxのNUMAメモリーポリシーのドキュメントでは、タスク、VMA、共有、バインド、優先、インターリーブの各ポリシーについて説明されています。また、ポリシーは主にインストール後に割り当てられたページに影響するため、初期化の順序が重要であることも記されています。この区別は、現実的な家庭内の運用環境でも重要です。

ローカル推論では、クリティカルパスにトークン化、画像デコード、テンソル準備、ページ固定バッファー、デバイス転送などが含まれることがあります。リモート配置では、アクセラレーター自体に未使用の計算能力があっても、ホスト側がボトルネックになります。後の診断やレビューに備え、中間状態を見える状態に保つ必要があります。

PCIeトポロジーによってアクセラレーターと特定のCPUノードが結び付く

ホストからデバイスへの最短経路は通常、アクセラレーターを所有するルートコンプレックスがあるCPUソケットを経由します。ワーカーのCPUスレッドと割り当てポリシーをその近傍にバインドすると、特に大容量入力や頻繁な転送でリンクが継続的に使用される場合、帯域幅が向上し、変動が抑えられることがあります。

NVIDIAのCUDA NUMAガイダンスにはNUMAに関する推奨事項が含まれており、自動バランシングによって一部のケースではGPUアプリケーションの性能が低下する可能性があると警告しています。ノード番号を前提にするのではなく、トポロジーを確認し、実際のノードに合わせてポリシーを調整することを推奨しています。

配置はグラフの問題であり、ノード0が最速とは限りません。適切な組み合わせは、マザーボードの配線、IOMMU構成、その他のデバイス、さらに複数のワーカーが同じメモリーチャネルやPCIeリンクを共有して競合するかどうかによって異なります。

ワークロードが複数のノードを使用する場合、バインドが逆効果になることがある

メモリを1つのノードに厳密にバインドすると、そのノードの帯域幅や容量を使い切る一方で、他のノードがアイドル状態になることがあります。パイプラインでは、1つのソケット近くにあるGPUを使用しながら、別のソケット近くにあるキャプチャーカード、NVMeデバイス、または2台目のアクセラレーターも使用する場合があります。1つの配置で転送を最適化できても、前処理やストレージが遅くなる可能性があります。

NVIDIAのGPUアフィニティプロジェクトは、GPUに関連付けられたCPUコアへプロセスを割り当て、適切なアフィニティによって性能を安定させられると説明しています。複数のモードは、固有、連続、ソケット、NUMAというスコープが、異なるマルチプロセスワークロードに適している理由を示しています。

失敗の境界は、単一デバイスのベンチマーク結果をサーバー全体へ一般化することです。統合メモリーシステム、シングルノードマシン、または複数のデバイスにまたがるパイプラインで、盲目的にバインドしないでください。意図した同時実行数の下で、エンドツーエンドのレイテンシー、帯域幅、競合を測定してください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

アクセラレーターだけでなくトポロジーをベンチマークする

CPUノード、メモリー容量、PCIeデバイス、アクセラレーターの局所性を把握します。同じ推論ワークロードを、デフォルト配置、CPUのみのバインド、メモリーのみのバインド、CPUとメモリーを一致させたバインドで実行します。ホストからデバイスへの帯域幅、ページ配置、1秒あたりのトークン数、p95レイテンシーを記録します。

ネットワーク上のモデルストレージからモデルシャードを読み込む場合は、ファイル読み取り時間をページ配置やデバイス転送から分離します。各実行で同じデータをウォームアップし、その後、意図した同時ワーカー数で繰り返して、メモリーチャネルの競合を明らかにします。

一致したトポロジーによって、他のサービスを圧迫することなく、再現性のあるエンドツーエンド結果が改善する場合にのみバインドを採用します。ウォームアップ後に効果が消える場合や、同時実行時に逆効果になる場合は、配置を柔軟なままにするか、転送が重要なスレッドとバッファーだけを分離します。