GPU トポロジー研究でメモリ配置を調整、H200 のデコードスループットが実測で 14.3% 向上

9 月 21 日に投稿された GPU スケジューリングに関する研究は、ストリーミングマルチプロセッサ（SM）の数が同じでも、物理的な位置やメモリまでの距離によって性能が異なる可能性を示した。著者らはトポロジーと非一様メモリアクセス（NUMA）を構成に組み込み、特定の Qwen3-8B テストで H200 のデコードスループットを 14.3% 向上させた。[論文情報](https://arxiv.org/abs/2609.24270)

研究では、マイクロベンチマークで演算とメモリの対応関係を調べ、プリフィルとデコードの専用状態をそれぞれのパーティション内に保持し、共有の重みと KV キャッシュをパーティションにまたがって配置した。プロトタイプは mini-SGLang に統合され、プリフィルのバッチサイズは 4、シーケンス長は 4K、デコードのバッチサイズは 128、平均 KV 長は 512 とした。クラスタ互換性をすでに考慮したベースラインと比べ、H200 と B200 のデコードスループットはそれぞれ 14.3% と 10.4% 向上したが、プリフィルの改善は限定的だった。[手法と実験](https://arxiv.org/html/2609.24270v1)

このプロトタイプでは、2 つの MIG インスタンスがマッピングされたメモリを共有できるよう、CUDA ドライバを変更する必要があり、そのまま導入できる選択肢とは見なせない。論文ではコードのオープンソース化を今後の予定としているため、現時点では手法とテスト条件を確認できるものの、公開されたプロトタイプを使って数値を独立に検証することはできない。[実装上の制約](https://arxiv.org/html/2609.24270v1)

現行の CUDA ドキュメントも、この結果を理解するための手がかりになる。Green Contexts は SM を分割できるが、Thread Block Clusters を使う場合は、まとめてスケジューリングするための要件も記述する必要があり、演算ユニット数を指定するだけでは足りない。また、SM とワークキューを分離しても、処理の並行実行が必ず保証されるわけではないと説明されている。したがって、リソースの分割、演算クラスタとの互換性、実際に実行が重なっているかどうかは、それぞれ確認する必要がある。[CUDA 公式ドキュメント](https://docs.nvidia.com/cuda/cuda-programming-guide/04-special-topics/green-contexts.html)

検証ツールの計測方法も統一する必要がある。Nsight Compute のドキュメントによると、新しいバージョンでは、帰属先を特定できる指標を Green Context が使用する SM 数に応じてスケーリングする。割り当てが重複する場合、一部の指標には他のコンテキストの寄与が含まれる可能性がある。使用率を比較する際は、プロファイリングツール、ドライバ、リソース構成も併せて記録すべきだ。[プロファイリングに関するドキュメント](https://docs.nvidia.com/nsight-compute/ProfilingGuide/)

推論サービスを運用するチームにとって、この研究は新たな診断の方向性を示している。エンジニアリング上の次のステップは、モデル、バッチサイズ、コンテキスト長を固定し、デコードスループット、最初のトークンが出力されるまでのレイテンシ、テールレイテンシを個別に測定したうえで、構成による違いを比較することだ。単一の段階が速くなったというだけでは、サービス全体で完了できるリクエスト数が増えたかどうかは判断できない。

今後注目すべきなのは、プロトタイプ公開後に異なる GPU カードで結果を再現できるか、また、正式なインターフェースで同等の構成と効果を再現できるかだ。それまでは、導入側はこの結果を著者らによる特定条件下の測定として扱い、ハードウェアトポロジーとソフトウェアバージョンの記録を残し、GPU 群全体にそのまま外挿することを避けるべきだ。