2026-06-26 議事録

実施日時

• 2026-06-26（金）Teams（オンライン）

目的

• AI推論の実験環境、MLflowダッシュボード、SGLangベンチマークの初期結果を共有する。
• HPC/OpenFOAM側のプロファイリングツール検証とI/O周りの論点を確認する。
• 競技ルールが未確定な範囲を整理し、次に確認すべきことを決める。

決定事項

• AI推論の実験結果は、当面はMLflowに集約して管理する。重要なrun IDを控え、比較に使わない結果は整理する。
• MLflowは玄界上で動かせる可能性があるため、ローカルへ結果をダウンロードする形ではなく、共有ストレージへ保存・コピーする形を検討する。
• AI推論環境は、現時点で動作しているSGLang中心に揃える。vLLMは引き続き不安定なため、必要になった段階で再検証する。
• AIチームの実行スクリプトやプロファイリング設定は、Git経由で変更案を出し、共有リポジトリへ反映してから各自がpullして使う。
• モデル候補は、現時点ではQwen3系に揃えて練習する。Qwen3.5系も候補として見たが、最終課題として使われるかは未確定。
• ベンチマークは、baselineを取ったうえで1回に1条件だけ変える。まずconcurrencyの飽和点を探し、その後に入力長、出力長、ランタイム、パラメータを順番に見る。
• 精度評価、固定すべき生成パラメータ、モデル構造変更の可否、モデルロード時間を測定に含めるか、scratch領域の使い方は大会ルール依存のため要確認として扱う。
• 次回定例は2026-07-05（日）18:00予定。2026-07-11から2026-07-12は神戸での勉強会予定を前提に調整する。

共有内容

AI推論の評価とルール確認

• 共有されたデータセットには、会話プロンプトはあるが明示的な正解ラベルは見当たらない。速度と処理量を中心に見るベンチマークと考えられるが、精度評価の扱いは要確認。
• 「精度を落とさない」という制約は、固定された生成パラメータを守ること、モデル構造や品質に影響する変更を避けることに関係しそうだが、どこまでが許可されるかは未確定。
• 速度だけでなく、なぜその変更で速くなったか、品質や制約をどう守ったかを説明できることがプレゼン評価にも関係する。

MLflowダッシュボード

• OSSのMLflowでAI実験用ダッシュボードを構築した。Quick Startの手順でstack起動までは可能。
• 現状の手順はMac前提になっている可能性がある。今後、玄界上で起動できるかを確認する。
• MLflow UIではタグや比較機能を使ってrunを横並びで見られるが、操作方法やパラメータ設計はまだ整理が必要。
• 実験結果は一旦MLflowに貯め、後から重要なrun IDを控えて比較する運用がよさそう。

SGLang実行環境

• SGLang向けの環境構築は一通り完了した。profile系の実行で、実験パラメータ、summary、GPU metricsなどを出せる状態。
• 実行結果はMLflow側と連動させる想定。
• vLLMも候補にしていたが、現時点では動作が安定していない。まずはSGLangで進める。
• 別メンバーが作った環境との差分を確認し、どちらかに統一する。SGLangを使うなら、基本的には同じ環境に揃える方針。

SGLangベンチマークとconcurrency

• AIチーム共有スライドQwen3-30Bプロファイリング.pptxで、Qwen3-30Bの初期プロファイリング結果が共有された。
• concurrencyを変えた軽いベンチマークを実施した。concurrencyは単純な物理並列数ではなく、SGLang内部のschedulerが複数リクエストをどう並行処理するかに関係する。
• concurrency 1から8までは、総トークン生成速度が伸びた。output TPSは168.1から864.3へ約5.14倍、QPSは1.313から6.753へ増加した。
• concurrency 4まではTTFT p50への悪影響が小さく、速度向上のメリットが大きそう。concurrency 8では総スループットは上がるが、TTFT p50が102ms、E2E latency p99が1,091msまで悪化した。
• 成功率は各条件100%だった。concurrency 8では160/160 success。
• GPU平均使用率は89.6%、GPUメモリ使用量は86.2GiB/95.8GiB（約90%）、平均消費電力は250W、最大温度は27度というメモがあった。ただし、モデル、入力長、出力長、測定条件に依存するため要確認。
• 次はconcurrency 12、16、24、32などを試し、速度向上が鈍る飽和点とレイテンシ悪化の境目を探す。
• 理論上の8倍にならない要因として、schedulerの管理コスト、KV cacheアクセス、メモリ帯域、decodeの逐次性、prefill/decodeの干渉、リクエスト長のばらつき、GPU kernelの効率限界が挙がった。

HPC/OpenFOAMとプロファイリング

• 玄界上でプロジェクトを持ってくるところまでは確認した。ビルドは再実行・再確認中。
• lscpuの出力から、ログインノードと計算ノードでCPU数、thread per core、周波数、NUMA構成などが違う可能性がある。重い計測は計算ノードで行い、ログインノードでは軽い確認に留める。
• MPIのプロファイリングとしてmpiPを試した。ローカルでも仮想的に複数rankを立てて通信時間を確認できる。
• perf statはハードウェアイベントの概要確認に使いやすい。一方、perf recordのcall graphは階層が深すぎると読みづらいため、表示階層を絞るなどの工夫が必要。
• 並列プログラムでは、1スレッド単位のcall graphだけでなく、複数スレッドやrankを横並びで見て待ち時間を確認できる可視化が重要。
• OpenFOAMは手元で動かせる状態。小さいblockMesh実行に対してstrace等でI/Oプロファイルを取り、ファイル読み込み、ファイル存在確認、失敗回数、実行時間などを見た。
• OpenFOAMのI/O最適化は、本番環境のscratch領域、共有ストレージ、ファイル配置、許可されるファイルパス変更に強く依存する。現時点では要確認。

scratch領域とモデルロード

• AI側では、モデル重みをscratch領域へ置くべきかが論点になった。
• モデルロード時間が測定に含まれるか、モデルがGPUメモリに収まるか、ロード後に重みへ再アクセスするかによって、scratch領域の重要度が変わる。
• HPC側でも、scratch領域の容量や利用ルールがI/O最適化に影響する。
• 2026年本番環境の構成、scratch容量、測定開始点は未確定。

TODO

今後の方針

• 公式ルールが出るまでは、競技固有の断定を避ける。
• AI側はSGLang、MLflow、concurrencyを中心に、baselineから1条件ずつ変えて記録する。
• HPC側はOpenFOAMを動かし、perf、mpiP、straceなどでCPU、通信、I/Oの見方を固める。
• 実験結果は「速くなった」だけでなく、どの指標がどう変わったか、なぜその変更を固定するのかを残す。

関連ページ

• 2026年大会の現時点まとめ
• 調査ステータス
• AI推論課題の入口
• AI推論ベンチマーク指標
• AI推論最適化の論点
• プロファイリングツール実践ガイド
• I/O最適化
• MPI通信最適化
• OpenFOAM最適化の考え方
• 2026-06-19 perf学習・AI動作確認・ダッシュボード方針