2026-07-26 議事録
実施日時
- 2026-07-26(日)Teams(オンライン)
目的
- 各自の進捗を共有する(OpenFOAMの2MPIプロファイリング、LLM推論のprefill/decode分析、Nsight Systems導入)。
- 小規模問題での分析の限界を踏まえ、本番環境・マルチGPU検証に向けた優先順位を整理する。
- 計算ポイント(ジョブ予約)の使い方と、週末のまとめ実験の進め方を決める。
決定事項
- マルチGPU/NCCL通信の検証を最優先にする。スケジューラやハイパーパラメータの細かいチューニングは優先度を下げ、公式ドキュメントで決まる範囲やAI探索に任せる。
- 週末に実験をまとめて実施する。全タスクを洗い出し、一括で投下する。
- ジョブ予約は最小単位が1時間なので、1時間枠に複数実験をまとめて投げる運用にする。制限時間は2時間程度に設定してもポイントは大きく減らない見込み。
- 「機械的に決められる項目」を2人でリストアップし、リストの項目ごとにGoogle スライドを作って共有する。あわせて本番環境の構築を進める。
- Nsight Systems(
nsys)をGPU側の共通プロファイラとして使う方向で進める。使い方は各自で一度確認する。 - 大会運営から提供された資料をWiki化・公開する場合は、著作権に配慮してパスワード保護や限定公開を検討する。
- 本番モデルは
Qwen 3.5系(LLM Foundation)とみられるが、正式には要確認。大会ルールは2026-08-01頃に公開予定で、その後にクラスタマシンへアクセスできる見込み。
共有内容
OpenFOAM 2MPIプロファイリング(小林)
OpenFOAM-devのfoamRunを1MPIと2MPIで実行し、実行時間を計測した。ウォームアップとして1回実行した後、5回ずつ実行して平均を算出した。- 1MPI:
2.710 [s] - 2MPI:
6.168 [s] - 今回の問題は小規模なため、2MPIの方が遅い(通信オーバーヘッドが計算削減量を上回る)。
- 1MPI:
- プロファイラには
PMPI(MPIのプロファイリングインターフェース)を使用した。LLMにPMPIラッパを作成させ、MPI関数の呼び出し回数・時間・メッセージサイズを記録した。 - rank1の
MPI_Waitall(約2.24 [s]、rank0は約0.21 [s])とMPI_Recv(約0.49 [s]、rank0は約0.01 [s])が大きく、rank1の通信待ち時間が長い。 - メッセージサイズは小さい通信がほとんど(
Allreduceは0〜8Bが大多数、point-to-pointも65〜256B中心)。問題が小規模なため小さいメッセージが多数発生している。 - 小さいメッセージほど帯域を十分に使えず、
message rate(1秒間に処理できる通信メッセージ数)の制約の影響を強く受ける。 - ボトルネックは「小さいメッセージの通信が多いこと」と「rank1の通信待ちが発生していること」。
- 改善案:小さいメッセージを集約する。複数データを
packして集約バッファにまとめ、MPI_Isend/MPI_Irecvを1回にしてunpackする。通信する合計データ量は変わらないが、Isend/Irecvの呼び出し回数を減らせる。
LLM推論のprefill/decode分析(松村)
-
vLLM/SGLangのエンジン構成(scheduler、KV cache manager、block_pool、paged KV cache memory)を整理した。 -
昨年のデータセット
ShareGPT_V3_unfiltered_cleaned_split.jsonを確認した。リクエスト数2000、総入力トークン626,729、総生成トークン388,685。2025年の平均は入力約313/出力約194トークン。 -
入力順は
seed=2026で固定とみられ(要確認)、順番はいじれない。2000リクエストを同時にエンジンへ渡す(bench_offline_throughput.py)と、スケジューラが並び替える。Continuous batching/Dynamic batchingにより、実行時は自然と近い長さ・近いタイミングのリクエストが同じバッチに入る。 -
SGLangのハイパーパラメータを整理した。
--mem-fraction-static:KV Cache用に確保するGPUメモリ割合。OOMにならない範囲で大きくする。--schedule-conservativeness:スケジューラがどれだけ積極的にリクエストを投入するか。--max-running-requests:同時実行できる最大リクエスト数。--chunked-prefill-size:Prefillを分割するトークン数。長文Promptで有効。
-
評価指標は
TTFT(最初の1トークンまでの時間)、ITL(トークン間隔)、TPS(システム全体の毎秒生成トークン数)。TPSが高くても1回答あたりが高速とは限らない。 -
計測結果(長い質問は最初の読み込みだけでなく生成中にも影響する)。
条件 TPS ITL 短い質問・短い回答 1,812 6.96 ms 長い質問・短い回答 1,372 9.60 ms 短い質問・長い回答 1,239 11.52 ms -
結論:スケジューラ改変などは実際の問題(来週判明予定)が分かってから。固定できるものは固定し、優先度の低い項目は後回しにして、マルチGPU検証(
Qwen 3.5)を急ぐ。
Nsight Systems導入(渡邊)
Matsumura-CODEの導入とShareGPTのスモークテストを完了した。Nsight Systems(nsys、NVIDIA提供のGPUシステムプロファイラ)を導入した。perfのようにCUDAカーネル実行時間、CPU⇔GPU同期、メモリ転送、ストリーム並列性、アイドル時間をGUIで可視化できる。nsysはCUDAツールキットに同梱されている(玄界上でnsys 2023.2.3を確認)。nsys profile --trace=cuda,nvtx,osrt ...のように起動する(cuda=CUDA kernel/memcpy/stream、nvtx=PyTorch/SGLangの区間マーカー、osrt=CPUスレッド/mutex/同期)。sleep 1の動作確認は成功。生成した.nsys-repをローカルに落としてNsight Systemsで解析する流れ。- ShareGPTを使ったスモークテスト(
Qwen3-30B、num-prompts 4、bfloat16、tensor-parallel-size 1、context-length 2048、disable-cuda-graph)のプロファイリングは失敗中。単体のスモークテストではモデルが動くが、nsysで挟むと途中で止まる。エラーコードやログが出ておらず、どこで止まったか切り分け中。サーバ/クライアント分離型で起動しており、サーバ側の終了を検知できずに詰まっている可能性がある。
全体の議論・方針
- 小規模問題では推測ベースの議論に限界がある。本番モデル・本番に近い環境での検証を優先する。
- 確定している要素は固定し、不確定要素(
NCCL通信など)にリソースを集中する。それ以外はAIで探索する。 - 待ち時間が依然として長い。渡邊のジョブは3日経っても実行されていない。制限時間を1〜2時間にしてもポイントは減っていないため、まとめて実行する方向。
- パラメータ探索の自動化案:実行時間を目的関数にし、シェルスクリプト経由でパラメータを振って最適値を探す(
Optuna/ベイズ最適化のイメージ)。2次元パラメータなら結果を可視化して次の探索点を決められる。根拠を明示したい場面ではAIより可視化が有効。 - Wiki化:今週分の各自のスライドをスクショ・PDF化し、翻訳と解説を付けてMarkdownでWikiに取り込む方針。公開時は著作権に配慮する。
TODO
| 項目 | 内容 | 目的 |
|---|---|---|
| メッセージ集約の検証 | 小さいメッセージをpackして集約バッファで一括Isend/Irecvしunpackする実装を試す | message rate制約とrank1の通信待ちを緩和する |
| nsysプロファイル修復 | ShareGPTスモークテストがnsysで止まる原因(サーバ/クライアント終了検知)を切り分ける | GPU側プロファイルを取得できるようにする |
| マルチGPU検証 | 本番モデル(Qwen 3.5系)でマルチGPU・NCCL通信を検証する | 本番環境に近い条件で効果を測る |
| 機械的項目のリスト化 | 機械的に決められる項目を2人で洗い出し、項目ごとにGoogle スライドを作る | 本番環境構築の作業を分担・共有する |
| 週末まとめ実験 | 全タスクを1時間枠にまとめてジョブ投下する | ポイントと待ち時間を節約して結果を一括取得する |
| 本番環境構築 | 本番モデル・本番に近い実験環境を1式構築する | 推測ではなく実測で議論できるようにする |
次回方針
- 本番環境の構築とマルチGPU/
NCCL検証を主軸に進める。スケジューラやハイパラ探索はAI/自動探索に寄せる。 - 週末にまとめて実験し、結果を次回共有する。ジョブは1時間枠に複数実験を詰めて投げる。
- 大会ルール公開(2026-08-01頃)後に、本番課題・使用モデル・評価条件を確認し、方針を見直す。
- 各自のスライドをWiki化し、公開範囲(限定公開・パスワード)を決める。