NUMAの局所性は、マルチGPUによる家庭用AI推論にどのような影響を与えるか？

エヴァ・ウォン

IceWhale author

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

How Does NUMA Locality Affect Multi-GPU Home AI Inference? - Zima Store Online

NUMAのローカリティは、CPUスレッド、ホストメモリ、GPUがPCIeパスの近くに留まらず、非ローカルなドメインをまたいで通信するとき、推論に影響します。

デュアルソケットのホームAIサーバーでは、2つの大容量RAMプールと複数のGPUを1台のマシンとして扱えますが、アクセスは均一ではありません。一方のソケットでスケジュールされたワーカーが、別のソケットに接続されたメモリ上でテンソルを準備し、その後、別のPCIeルート配下にあるGPUへ転送する場合があります。影響の大きさは、モデルの配置、ホスト側でのステージング、テンソル並列処理の通信、インターコネクトのトポロジー、バッチ処理、そしてワークロードが計算律速か転送律速かによって異なります。

NUMAでは、1つのメモリプールが距離に依存するアクセスになる

NUMAシステムでは、各CPUソケットまたは計算ドメインに、他のコアよりも近いメモリがあります。ソフトウェアからは合計容量をまとめてアドレスできますが、リモートアクセスではインターコネクトを通過しなければなりません。その経路は通常、ローカルメモリとはレイテンシーも利用可能な帯域幅も異なります。

NUMAトポロジーは、ホスト側のページがGPUのPCIeルートコンプレックスから遠くに配置される可能性があるため、GPU DMAにも影響します。CPUのスケジューリングとメモリの配置は別々の判断であり、仮想マシンが両者を揃えるために必要なホストのトポロジーを自動的に認識できるとは限りません。

ホストメモリのトラフィックがGPUの計算量に比べて少ない場合、影響は小さくなります。モデルの読み込み、CPUオフロード、トークン化、ピン留めバッファーのコピー、頻繁な同期、またはVRAMを超えてデータがあふれるワークロードでは、影響が大きくなります。NUMAの容量が十分でも、NUMAローカリティが保証されるわけではありません。

GPUの配置は、モデルのデータ経路に2つ目のトポロジーを加える

複数のGPUは、異なるCPUソケット、PCIeスイッチ、またはパッケージ上の異なるパーティションに接続されることがあります。2つのアクセラレーター間を移動するテンソルは、直接のピア経路、専用GPUリンク、PCIeスイッチ、あるいはホストメモリとソケット間のホップを経由する経路を利用します。これらの経路は同等ではありません。

マルチパーティションGPUに関する研究では、非均一なアクセスとパーティション間通信が、競合とカーネルレイテンシーを増幅する可能性が示されています。配置戦略は、データがグローバルに共有されるのか、一部で共有されるのか、または1つのワークグループやパーティション内だけで共有されるのかによって異なります。

モデルの分割は、最も頻繁にトラフィックが流れるトポロジーに従うべきです。隣接するレイヤーやアテンション状態を低速な境界をまたいで配置すると、トークンごとに通信が発生します。一方、通信量の少ない分割なら、距離の影響に耐えられる場合があります。リンクの構成を確認せずにGPUの台数だけを数えると、重要な関係を見落としてしまいます。

テンソル並列処理では、ローカリティがトークンごとのコストになる

テンソル並列推論では、レイヤー内の演算を複数のGPUに分割し、集団通信によって部分的な結果を統合します。これにより、より大きなモデルに対応し、より多くの計算リソースを活用できますが、通信は多くのレイヤーとトークンにわたって繰り返されます。そのため、リモート経路はモデル読み込み時だけの一度限りのペナルティではなく、繰り返し発生するコストになります。

テンソル並列処理は、アクセラレーター間のリンクとシャード配置が必要な同期を支えられる場合に最も効果を発揮します。NUMAまたはPCIeの弱い境界をまたいでGPUを追加すると容量は増えますが、デバイス数から期待されるほどスループットが向上しないことがあります。

モデルを個別に収められ、リクエストをローカルに維持できる場合は、データ並列処理やリクエスト単位の配置のほうが適している可能性があります。1つのモデルを単一デバイスに収められない場合、テンソル並列処理が必要になりますが、追加された容量が速度向上にもつながるかどうかは、バッチサイズ、集団通信の頻度、インターコネクトによって決まります。

Featured

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

ZimaCube2

ファーストタッチとスレッド移行は、意図した配置を崩すことがある

OSは通常、各ページに最初にアクセスしたスレッドの近くにメモリを配置します。初期化を一方のソケットで実行し、その後推論ワーカーが別のソケットで動作すると、ページがリモートに残る可能性があります。スケジューラーによる移行によって、CPU準備スレッドが、処理対象のメモリやGPUから離れた場所へ移されることもあります。

NUMA対応では、最も効率よくアクセスできるCPUソケットとローカルメモリバンクを結び付けます。メモリ割り当てを制御せずにCPUスレッドだけをバインドしたり、GPUとの配置を揃えずにメモリだけをバインドしたりしても、経路の一部しか解決できません。

安定した配置には、CPUアフィニティ、メモリポリシー、デバイス割り当て、トポロジーを考慮したプロセス起動が必要になる場合があります。コンテナや仮想マシンでは、さらに別のマッピング層が加わります。目的は何でも盲目的にバインドすることではなく、大量のデータを扱うプロデューサー、バッファー、コンシューマーの経路を、現実的な範囲で最も近いドメイン内に維持することです。

ローカリティが重要になるのは、推論の特定のフェーズ

モデルの読み込みでは、ストレージからホストへ、そしてホストからGPUへデータを移動する処理が重視されます。プリフィルでは多数のプロンプトトークンを処理し、より大きな行列演算を利用できます。一方、デコードでは1つまたは少数のトークンを繰り返し処理するため、メモリ帯域幅、同期、カーネル起動のオーバーヘッドの影響を受けやすくなります。そのため、NUMAの影響は1つのリクエスト内でも変化します。

GPUのNUMA効果に関する研究では、メモリドメインとキャッシュ再利用に合わせて処理を配置する、配置を考慮したスケジューリングによって、アテンションを改善できることが示されています。ただし、これは普遍的な高速化を意味するものではありません。効果が現れるのは、カーネルの共有パターンとトポロジーを考慮したマッピングが一致する場合です。

平均トークン毎秒だけを報告するベンチマークでは、最初のトークンまでの遅延や、特定のバッチにおけるスケーリングの悪さが隠れることがあります。読み込み時間、プリフィルのスループット、トークン間レイテンシー、GPUリンクのトラフィック、リモートNUMAアクセス、CPUメモリ帯域幅を分けて記録しましょう。