APAC HPC-AI 2026 キャッチアップ議事録

2026 APAC HPC-AI Competition への参加に向けたチームの学習記録・技術ドキュメントです。競技中はチーム内の知識共有に、終了後はポートフォリオおよび後輩向け参考資料として活用します。

HPCやAI推論最適化の初心者が、議論に参加できる最低限の背景をそろえることを目的にしています。

読み方

最初に読む順番は次の通りです。

1. 調査ステータス
2. 2026年大会の現時点まとめ
3. 2025年大会の振り返り
4. OpenFOAM課題の入口
5. LLM推論課題の入口
6. 用語辞書

各ページでは、情報の確証度を次のように分けます。

まず押さえる結論

• 2026年大会の公式スケジュールは公開済みだが、課題の細部、計測方法、制約は今後確定する可能性がある。
• メモ上では、HPC側はOpenFOAM、AI側はQwen系LLM推論、PD disaggregation、Dynamo/SGLang周辺が議論対象になっている。
• 2025年大会では、HPC側がNWChem、AI側がDeepSeek-R1 671B + SGLangだったことは公式発表と参加記で整合する。
• 最適化の本体は「速そうなフラグを試す」ではなく、計測、ボトルネック特定、1変更1実験、記録、比較を繰り返すこと。

大会概要

優勝チームは 2027 ISC 国際学生クラスタコンペティション APAC 代表枠を獲得できます。

ドキュメントを読む

公開サイト: https://<your-github-username>.github.io/APAC-HPC-AI/

ローカルでプレビューする場合:

# mdBook のインストール（初回のみ）
cargo install mdbook

# ライブプレビュー（ブラウザで http://localhost:3000 が開く）
mdbook serve --open

リポジトリ構成

src/          # 記事ソース（Markdown）
  SUMMARY.md  # 目次・章構成
book/         # ビルド成果物（Git 管理外）
book.toml     # mdBook 設定
.github/
  workflows/
    deploy.yml  # GitHub Pages 自動デプロイ

コントリビュート

1. src/ 配下に .md ファイルを作成する
2. src/SUMMARY.md に章のリンクを追加する
3. mdbook serve でローカル確認する
4. main ブランチへ push すると GitHub Pages に自動デプロイされる

参考文献の方針

本文中の主張には、できる限り該当ページへのリンクを付けています。まとめて確認する場合は参考文献一覧を見てください。

調査ステータス

このページは、殴り書き.txtに含まれるリンクと議論を、どこまで裏取りできたかを管理するためのページです。

元メモから抽出した主要リンク

確定情報と未確定情報

確定

• 2026年大会はHPC-AI Advisory Council、NSCC Singapore、NCI Australia、Firmus Technologiesなどが関係するAPAC HPC-AI Competitionである。
• 2026年大会の主要日程は公式ページで公開されている。
• 2025年大会は、HPC側でNWChem、AI側でDeepSeek-R1 671B + SGLangが課題だった。
• 2025年大会では、理研R-CCSが支援した日本チームが複数入賞した。
• Qwen3-235B-A22Bは、Qwen公式モデルカード上で総235B、活性化22BのMoEモデルとして説明されている。

要確認

• 2026年HPC課題の正確なOpenFOAMケース、メッシュサイズ、評価コマンド、許可される変更範囲。
• 2026年AI課題がSGLang固定なのか、Dynamo/TensorRT-LLM recipeをどの範囲で参照するのか。
• Qwen3.5など、メモ上の提案が大会設計に反映されるかどうか。
• ランダム重みで測るのか、実モデル重みで測るのか。
• 評価指標が総スループットだけなのか、TTFT、TPOT、p95 latency、request success rateなども含むのか。
• 2026年大会の実機。チームは富岳(A64FX)を前提に最適化を調査しているが、運営メモでは「4ノード・100+コアのCPUクラスタ」とされ、2025年は玄界が使われたとの情報もある。実機は未確定。
• -Ofast系の許容範囲。演算順序変更・近似・精度劣化を伴うため、大会でどこまで許可されるか。昨年は精度低下・収束条件変更が禁止だった。
• system-level tuning（CPU周波数スケーリング、NUMAトポロジ最適化、ファイルシステム/ストレージアクセス）が今年も許可されるか。昨年ルールには記載あり。
• scratch領域の利用可否。重みや中間ファイルをscratchに置けるか。玄界では不可だった可能性あり。
• 利用可能なプロファイリングツール（mpiP/Score-P/Scalasca/nsys等）が実機で使えるか。

調査で見えた論点

• OpenFOAMはMPIによる領域分割、I/O形式、decomposeParDict、ソルバ設定が性能に影響する。
• LLM推論はprefillとdecodeで計算特性が違う。PD disaggregationはこの差を利用する設計。
• 高い総スループットだけを追うと、1リクエストあたりの体感速度が悪化する場合がある。評価指標の定義確認が重要。
• 大会ではルール違反になり得る最適化がある。量子化、モデル品質を落とす変更、実験的機能の扱いは必ずルールで確認する。

議事録

チーム定例・作業会の議事録を日付順に管理します。

運用ルール

• ファイル名はYYYY-MM-DD.mdにする。
• 1回の議事録には、実施日時、参加目的、決定事項、共有内容、TODO、次回方針を残す。
• 調査した技術情報の詳細は各技術ページに分け、議事録には「何を調べたか」「何が決まったか」「次に誰が何を見るか」を中心に書く。
• 参考文献がある場合は、本文中または末尾にリンクを置く。

一覧

• 2026-05-29 キャッチアップ方針決め
• 2026-06-05 最適化テーマ共有とタスク整理
• 2026-06-12 環境構築の進捗と過去問学習方針
• 2026-06-19 perf学習・AI動作確認・ダッシュボード方針
• 2026-06-26 AI実験環境・SGLangベンチ・OpenFOAMプロファイリング方針
• 2026-07-05 ポイント運用・strace I/O調査・神戸勉強会の段取り
• 2026-07-26 2MPIプロファイリング・prefill/decode分析・Nsight Systems導入
• 2026-08-09 競技マシン環境構築（NCI/NSCC）・ベースライン測定・分報導入

テンプレート

# YYYY-MM-DD 議事録

## 実施日時

- YYYY-MM-DD（曜日） HH:MM-

## 目的

- 

## 決定事項

- 

## 共有内容

- 

## TODO

| 項目 | 内容 | 期限 |
|---|---|---|
|  |  |  |

## 次回方針

- 

## 参考リンク

- 

2026-05-29 議事録

実施日時

• 2026-05-29（金）

目的

• APAC HPC-AI 2026に向けて、チーム内で知識共有するための土台を決める。
• HPC、OpenFOAM、AI推論最適化の初心者でも後から追える形で、調査内容をmdBookにまとめ始める。

決定事項

• チームの知識共有にはmdBookを使う。
• 今後の調査内容、体験談、議事録、用語辞書、参考文献をmdBook上で管理する。
• 議事録は日付別にsrc/minutes/配下へ追加し、src/SUMMARY.mdから辿れるようにする。
• 情報の確証度を区別する。公式サイト、公式ドキュメント、論文、公式リポジトリで確認できたものを優先し、体験談やチャット上の情報はその旨を明示する。

共有内容

• 去年までの大会問題、参加体験談、今年の課題候補に関する情報を集めた。
• 2025年大会では、HPC側がNWChem、AI側がDeepSeek-R1 671B + SGLang推論ベンチマークだったことを確認した。
• 2026年大会では、メモ上の議論としてHPC側にOpenFOAM、AI側にQwen系LLM推論、PD disaggregation、Dynamo/SGLang周辺が出ている。
• ただし、2026年の正確なOpenFOAMケース、AI側のモデル構成、評価指標、禁止事項は最終ルールで確認する必要がある。
• 初心者向けに、HPC/OpenFOAM/LLM推論/ベンチマーク指標の用語辞書を作成した。

TODO

今後の方針

• 毎週金曜日18:00から情報共有と目標確認を行う。
• 各自が調べたこと、試したこと、詰まったことを共有する。
• 次の1週間で何を調べるか、何を実験するかを決める。
• 調査内容は議事録だけに閉じず、再利用できる内容は該当する技術ページへ反映する。

次回までの確認ポイント

• 公式ルール更新がないか確認する。
• Qwen、OpenFOAM、プロファイリング、ベンチマーク指標、禁止事項の担当を決める。
• 調査したリンクは必ず参考文献として残す。

関連ページ

• 調査ステータス
• 2026年大会の現時点まとめ
• OpenFOAM課題の入口
• プロファイリングと性能分析
• LLM推論課題の入口
• AI推論ベンチマーク指標
• 用語辞書

2026-06-05 議事録

実施日時

• 2026-06-05（金）18:00-

目的

• HPC/AI最適化に関する勉強会・MTGの内容を共有する。
• 各自の調査内容をすり合わせ、今後の方針と次回までのタスクを整理する。

決定事項

• 10月11〜12日のイベントは、とりあえず全員エントリーしておき、都合が変わった人はオンライン参加に切り替える。（対面／オンラインの最終判断は各自の授業・ゼミ次第）
• プロファイリングは、まずperf + mpiPの組み合わせで着手する。
• コンパイラ最適化はコストが低いので、早い段階で試す。
• CPUアーキテクチャの深掘り（アセンブリレベルの最適化など）は学習コストが高いため、当面は優先度を下げる。
• 来週の発表形式はスライドベースにする（図・画像を載せやすいため）。
• 計測データの保管場所とフォーマットは、来週のMTGで決める（今回は保留）。

共有内容

各自が担当した最適化テーマを発表した。詳細は下記の技術ページに分けて整理した。

調査テーマ

• ボトルネック分析の全体像: 計算・通信・I/Oの割合を把握する（ボトルネック分析）。
• コンパイラ最適化・ライブラリ選定: GCCの最適化オプション、BLASライブラリの選定など（CPU最適化）。
• MPI通信最適化: 通信がボトルネックになりやすい点、ロードインバランス（rank間の負荷の偏り）への対処（MPI通信最適化、領域分割）。
• NUMA最適化: メモリの局所性、スレッド配置の工夫（NUMA最適化）。
• GPU/NCCL最適化: GPU間通信（NCCL）の最適化（NCCL通信最適化）。
• I/O最適化: スクラッチ領域の活用など（I/O最適化）。
• スケーリング分析: ノード数・スレッド数を変えたときの性能変化を測定する（スケーリング分析）。

注: 上記の発表は富岳(A64FX)を前提に調査されている。2026年大会の実機は未確定のため、富岳前提の内容は調査ステータスの要確認項目として扱う（富岳アーキテクチャ）。

方針議論

• CPU演算性能は富岳では比較的強いため、通信（MPI）がボトルネックになる可能性が高いという認識で一致した。
  • ※ ただし、これは富岳を前提とした認識。2026年大会で使う実機（メモ上は「4ノード・100+コアのCPUクラスタ」）は最終ルールで要確認。
• コンパイラ最適化は低コストなので、早めに試す価値がある。
• 大規模LLMのモデルロード時間が競技で課題になりうる。スクラッチ領域への配置が有効な可能性がある（要確認）。

プロファイリングツールの整理

→ まずperf + mpiPの組み合わせで着手するのが現実的、との結論。

データ管理・議事録の運用

• 計測データの保管場所は来週決める。
• 発表はスライドベースで行う。
• スパコンの共有ストレージの活用も検討する（メモ上は「限界」と記載。名称・利用可否は要確認）。

TODO

今後の方針

• 次回までの達成ラインを以下とする。
  • 最低ライン: モデル（担当問題）を動かす ＋ プロファイリングツールを1つ使ってみる。
  • できれば: プロファイリング結果の分析・コードの理解まで進める。
• 1回の実験で変更する条件は1つにし、「なぜ速くなったか」も記録する（プロファイリングと性能分析の基本方針に従う）。

関連ページ

• プロファイリングと性能分析
• ボトルネック分析
• プロファイリングツール実践ガイド
• スケーリング分析
• I/O最適化
• CPU最適化（コンパイラ・ライブラリ）
• MPI通信最適化
• 領域分割（decomposePar）
• NUMA最適化
• 富岳（A64FX）アーキテクチャ
• NCCL通信最適化
• 2026年大会の現時点まとめ
• 調査ステータス
• 用語辞書

2026-06-12 議事録

実施日時

• 2026-06-12（金）

目的

• 環境構築の進捗を共有する。
• 問題が未公開の期間に何を進めるか（過去問・プロファイリング学習）を決める。

決定事項

• 問題が未公開のうちは、環境をたくさん触ることとプロファイリングを学ぶことに注力する。
• 過去問を解いて、プロファイリングを学び、最適化を試して理解を深める。
• 6月中に過去問のプロファイリング＆最適化を行う（過去問は6月中に解きたい）。
• 来週までに、各自プロファイリングツールを複数試し、結果をスライドにまとめる。
• 来週はTeams会議で実施する（松村は不在）。

共有内容

進捗（環境構築）

共有された知見

• PythonのPackage Managerはuvがおすすめ。
• perfのcache-referenceイベントはハードウェア依存らしい（要確認）。計測値の比較時は環境差に注意する。
• ベンチマーク抽出ツールは大会側から指定されるらしい（未確定）。詳細は不明だが、現時点でも分析の練習はできそう。

TODO

今後の方針

• 6月中: 過去問を解き、プロファイリングと最適化を試して理解を深める。
• 7月: 問題が公開されることを期待する。公開後は、その問題に対する取り組みへ移行する。
• 来週: プロファイリングツールをたくさん試し、その結果をスライドにまとめて共有する（Teams、松村不在）。

未確定事項

• 2026年大会の問題（HPC/AI課題）はまだ公開されていない。
• ベンチマーク抽出ツールは大会側指定。内容は未確定。
• cache-referenceなどHWイベントの扱いは環境依存のため要確認。

関連ページ

• プロファイリングと性能分析
• プロファイリングツール実践ガイド
• ボトルネック分析
• OpenFOAM課題の入口
• 2026-06-05 最適化テーマ共有とタスク整理
• 調査ステータス

2026-06-19 議事録

実施日時

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

目的

• 各自の進捗共有（プロファイリング学習、環境構築、AI推論の動作確認）。
• 計測結果の共有方法（ダッシュボード）と今後の方針を確認する。

決定事項

• プロファイリングはperfを中心に進める。まずperf statで全体像を掴み、perf record/perf reportで詳細を見る（詳細はプロファイリングツール実践ガイド）。
• ビルドは用途別（Debug / Profile / Release / Optimize など）に切り替えられるよう整備する。分析しやすさと速度はトレードオフのため。
• 計測結果・グラフはダッシュボードに集約して共有する方向で進める。ツールはOSSを調査しつつ、AIを使った自作も検討する。
• 環境は再現性を重視する。リポジトリ/コンテナを整備し、他メンバーがコマンド一つで同じ環境を再現できるようにする。
• Pythonのパッケージ管理はuvを使う（動作が速く扱いやすい）。
• AI推論は最終的にSGLangを使う想定で進める。

共有内容

プロファイリング学習（perf）— 田中

perfは日本語情報が少なく、man、Archwiki、ライブコーディング動画（impl Rust: One Billion Row Challenge）が学習に役立った。 実践的な使い方・注意点・ビルドオプションは技術ページへ分離した（プロファイリングツール実践ガイド）。要点:

• まずperf stat -r <n> -d -d -dで詳細イベント＋複数回実行の統計を取る。perf record/perf reportがcall graph・アセンブリ分析まででき、最も使いやすい。
• perf recordはイベント数が多すぎると解析不能・ストレージ圧迫になる。実行中プロセスへ短時間アタッチ（perf record -F 999 -g --call-graph fp -p <PID> -- sleep 30）が有効。
• 可視化にflamegraphが便利。

AI推論の動作確認

• まずtransformersで小さめのモデルを動かし、モデルロード・KVキャッシュ確保まで確認した。
• ベンチマークは昨年使われたShareGPTデータセットを利用して試行。token生成・読み込みの速度を計測した（メモ上の数値: 約512 tokens/s 処理・約128 tokens/s 出力。対照実験はこれから。要確認）。
• vLLMとSGLangを比較。vLLMは起動が速い一方でドライバ依存により不安定だったため、SGLangに切り替えて進めている（要確認：環境依存）。
• 目標はプロファイリングだが、現状は環境構築とモデル動作確認まで。次は大きめのモデルでベンチを取得する。

環境構築・再現性

• ローカルで構築したものをコンテナ等で他メンバーが再現できるようにする方針。スパコン側でSSH先をクローンすれば全員が同じ環境を再現でき、効率が上がる。
• 管理担当を置き、リポジトリ/環境を整備する。

データ共有・ダッシュボード

• 計測結果をダッシュボードに集約する案。あるメンバーが自分の研究で使っている仕組み（データ投入 → Pythonで自動グラフ生成 → Webページ表示）を流用できそう。
• OSSのダッシュボードツールの調査、またはAIでの自作を検討する。

TODO

今後の方針

• 来週も各自のプロファイリング・環境整備を継続する（次回はHPC側のプロファイリング共有を予定）。
• 7月の問題公開を見込み、それまでは過去問・環境・計測の練度を上げる。

関連ページ

• プロファイリングツール実践ガイド
• プロファイリングと性能分析
• CPU最適化（コンパイラ・ライブラリ）
• NCCL通信最適化
• LLM推論課題の入口
• 2026-06-12 環境構築の進捗と過去問学習方針
• 調査ステータス

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動作確認・ダッシュボード方針

2026-07-05 議事録

実施日時

• 2026-07-05（日）Teams（一部オンライン参加）

目的

• 各自の進捗（計算ポイント運用、ダッシュボード、OpenFOAMのI/Oプロファイリング）を共有する。
• 2026-07-10から2026-07-12の神戸勉強会に向けて、宿泊・移動の段取りを決める。
• トークン（計算ポイント）復活までの当面の進め方を確認する。

決定事項

• 計算ポイントは不足しそうなため、Slack経由で権利者へ追加購入を依頼する。単価は研究施設が1ポイント2円、民間が1ポイント3円で、追加分は概ね3,000円規模の見込み。
• ポイントの浪費を防ぐため、ジョブのelapsed time（実行時間上限）を1〜2時間に設定し、不要なジョブは適宜打ち切る運用にする。1回に投げるジョブは絞る。
• ダッシュボードは玄界上で構築する方針。共有リポジトリ内に作っても、OpenFOAMチーム用に別途作って隣に並べてもよい。結果がすぐ反映される形を優先し、具体的な作り方は担当者に任せる。
• AIチームのGitHub連携は、学生プランでは想定機能が使えない可能性が高い。原因の切り分けは難しいため、当面はアカウント種別の問題として扱う。
• OpenFOAMの動作確認は玄界へトンネルを張って行う。表示されない場合は接続をやり直す（2回試すと通ることがある）挙動を共有した。
• 神戸勉強会はメリケンパーク近くのホテルを2泊（2026-07-10チェックイン、2026-07-12チェックアウト）で予約する。4名1部屋（シングルベッド4台、オーシャンビュー、エアコンあり）で一人あたり約8,742円/泊。
• 移動は新幹線を基本とし、山梨・静岡からの参加者は静岡駅まで車で出て静岡から新幹線に乗る案を採用する。関東からの参加者は新横浜からのぞみで合流する。
• トークン復活までは新規の重い作業ができないため、次にやることは復活後に改めて検討する。復活後の作業結果は次回にまとめて共有する。

共有内容

計算ポイントの運用

• 現状ポイントが不足しそうなので、権利者へ追加購入を依頼する。研究施設単価2円/民間単価3円で、追加は数千円規模。
• ジョブのelapsed timeを1〜2時間に制限し、無駄なジョブを止めてポイント消費を抑える。1回に投げるジョブ数も絞る方針。
• 現時点では、各自まだ本格的な実行までは進めておらず、投げたジョブも限定的。

ダッシュボードとGitHub

• ダッシュボードは玄界上に構築し、結果がその場で反映される形を目指す。共有リポジトリ内でも、OpenFOAMチーム用に別立てでもよい。
• AIチームのGitHub連携は学生プランでは目的の機能が使えない可能性が高く、原因を切り分けきれないため、当面はアカウント種別の問題として整理する。

OpenFOAMのI/Oプロファイリング（strace）

• 昨年のLVK資料を参照しつつ、strace系のツールでOpenFOAMの動作を追い、どのシステムコールが何回呼ばれ、どれが失敗しているかを確認した。
• ファイルのオープン・読み込み・書き込み・削除といったI/O系イベントを、重要そうなものに絞って一覧化して見られる。例としてopenの失敗回数が多いことが確認できた。失敗の一因は、存在しないライブラリを探しに行って時間がかかっているケースと考えられる。
• コマンドのオプションを変えると詳細一覧が出力され、読み込みに何マイクロ秒かかったかなどを見られる。メモリ配分の情報も確認できるとの記載があった。
• blockMeshの実行を題材に、入力ファイル（blockMeshDictなど）を読み込み、結果を書き込む流れをstraceで観察した。

スタック／ヒープとメモリ指定

• 昨年資料に「スタック領域を使う（ヒープを使わない）ことで高速化する」旨の記述があり、stack／heap／globalのメモリ指定を増やす設定が候補として挙がった。
• ただし、実際にどう入力するか、どの程度効果が出るかはまだ明らかになっておらず要確認。単純に増やせばメモリを食うだけになる懸念もあり、スクラッチ領域への書き込みなどとの関係も含めて検証が必要。

神戸勉強会の段取り

• 2026-07-10から2026-07-12の2泊で、メリケンパーク近くのホテルを予約。4名1部屋（シングル4台、オーシャンビュー、エアコンあり）で一人約8,742円/泊、2泊で約1万6〜7千円。
• 移動は新幹線が基本。山梨・静岡側の参加者は静岡駅まで車で出て静岡から新幹線に乗る案を採用（高速利用で車移動は1.5〜2時間、駐車場は静岡駅周辺で1日約900円）。車を使うと約5,000円安くなる見込み。
• 関東からの参加者は新横浜からのぞみで合流する想定。往路初日はホテル直行、時間があれば神戸観光も検討する。学割の証明書が間に合わなかったため、切符は各自で手配し精算する。

TODO

次回方針

• トークン（計算ポイント）復活までは新規の重い作業を止め、復活後に次のタスクを決める。
• 復活後は、ポイント制約の中でelapsed timeと投げるジョブ数を管理しながら計測を進める。
• OpenFOAM側はstraceのI/O観察とメモリ指定の検証を続け、失敗回数や無駄なI/Oを減らす余地を探す。
• 神戸勉強会（2026-07-10〜12）で、現地作業と情報共有を進める。

参考リンク

• 2026-06-26 AI実験環境・SGLangベンチ・OpenFOAMプロファイリング方針
• I/O最適化
• プロファイリングツール実践ガイド
• OpenFOAM最適化の考え方
• 調査ステータス

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の方が遅い（通信オーバーヘッドが計算削減量を上回る）。
• プロファイラには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

次回方針

• 本番環境の構築とマルチGPU／NCCL検証を主軸に進める。スケジューラやハイパラ探索はAI／自動探索に寄せる。
• 週末にまとめて実験し、結果を次回共有する。ジョブは1時間枠に複数実験を詰めて投げる。
• 大会ルール公開（2026-08-01頃）後に、本番課題・使用モデル・評価条件を確認し、方針を見直す。
• 各自のスライドをWiki化し、公開範囲（限定公開・パスワード）を決める。

参考リンク

• 2026-07-05 ポイント運用・strace I/O調査・神戸勉強会の段取り
• MPI 特別講義まとめ
• MPI通信最適化
• AI推論ベンチマーク指標
• PD Disaggregation
• NCCL通信最適化
• プロファイリングツール実践ガイド

2026-08-09 議事録

実施日時

• 2026-08-09（日）Teams（オンライン）

目的

• 2026 HPC課題の確定ルールと評価方法（FVOPS）を共有する。
• 競技マシン（NCI Gadi、NSCC ASPIRE-2A）へのアクセス環境（VPN・アカウント）を整える。
• OpenFOAMのベースライン測定の進め方と玄界での実測結果を確認する。
• チーム内の情報共有方法として「分報（Times）」の導入を決める。

決定事項

• HPC側は主にGadiを使う方針とする。ASPIRE-2Aは結果のばらつき（spread）が大きく、ルール上「改善率がspreadを下回るとscore評価されない」可能性があるため（要確認）、安定して結果が出るGadiを優先する。
• 大きな高速化はdata layout／cache locality／memory trafficの削減方向で狙う。compiler／MPI設定・process bindingは重要だが改善幅は数%程度と割り切る。source modificationはルール上許可されている。
• ベースラインは同一条件で4〜5回実行してばらつきを把握する。process bindingが正常に動作していることを必ず確認する（解除すると約3.7倍遅くなる）。
• 情報共有用に「分報（Times）」チャンネルをTeams上に作る。各自が思ったこと・悩みどころ・判断・決定をその場で書き溜めていく。通知で全員が疲れないよう、非表示（ミュート）チャンネルとして作る。
• 環境構築の手順（VPN接続、アカウント作成、ログイン方法）を、画像付きで後からまとめてWiki化する。九州大学側の知見も参照する。
• Iris（講習会で使ったスパコン）は練習用として使う。本番では使わない旨をルール・手順に明記する。

共有内容

2026 HPC課題の確定ルール（小林）

• 固定されているもの（変更不可）。

  • OpenFOAM v2506以降を使用する。
  • 計算量、出力結果の精度。
  • 使用ノード数は1, 2, 4。

• 評価指標FVOPS（高いほどよい）。

  FVOPS_trim = (64,000,000 × 4) / (ExecutionTime_step5 − ExecutionTime_step1)
  

  • solverが出力するExecutionTimeを結果として使う。
  • Step1〜5を実行し、Step1の結果は除外する（ウォームアップ相当）。

• 評価対象は「4ノードでベースラインからどれだけ高速化したか」。

報告・提出するもの（小林）

• 1/2/4ノードそれぞれの結果（Log.icoFoam と parse_result.sh の RESULT）。
• 最適化内容（何を変更したか。1つの変更につき1行）。
• 最適化の仮説（なぜ高速化すると考えたか）とボトルネックの根拠（なぜボトルネックと判断したか）。この2つは重要な評価項目。
• FVOPS before / after / Delta（変化量）。
• MPI rank数（ranks per node）、Decomposition（分割法）、Subdomain数（rank数との関係も明示）、Ordering/renumbering（未実施ならその旨）。
• 総run数（実験期間中の全run）と総core-hours / SU（消費した計算資源）。

競技マシン：Gadi と ASPIRE-2A（小林）

• 昨年の資料を見た限り、HPC部門ではGadiを選ぶチームが多い。

• gitで公開されていたベースラインログでは、ASPIRE-2Aは結果のばらつきが大きい。ルール上、改善率がspreadを下回るとscore評価されない可能性がある（要確認）。

• 公開ベースラインログの要約（Best FVOPSは高いほど良い）。

  Cluster	Nodes	Runs	平均 [s/step]	Spread	Best FVOPS
  Gadi	1	3	31.881	1.22%	2.0161 M
  Gadi	2	3	15.467	0.29%	4.1457 M
  Gadi	4	8	6.592	1.87%	9.7785 M
  ASPIRE-2A	1	3	55.286	4.03%	1.1793 M
  ASPIRE-2A	2	8	27.261	23.91%	2.6003 M
  ASPIRE-2A	4	8	12.001	13.73%	5.7168 M

• ポイント（core-hours / SU）には上限があり、消費量は報告義務がある（報告項目に含まれる）。

主催者が推奨していること（小林）

• ベースラインを再現する。同一条件で4〜5回実行し、結果のばらつきを把握する。
• process bindingが正常に動作することを確認する（解除すると約3.7倍遅くなる）。
• compiler／MPI設定の変更は試して記録する価値はあるが、大幅な高速化は期待しない。主催者の測定ではMVAPICH/UCX設定・binding・compiler flagsはいずれも改善幅が数%程度だった。
• 大きな改善を狙うならdata layout・cache locality・memory traffic。solverはachievable memory bandwidthのかなり高い割合をすでに使っており、命令の高速化よりDRAMとのデータ移動量そのものを減らす方に余地が大きい。source modificationも許可されており、公式ルールは許可例としてcache blocking、SpMV vectorization、通信と計算のoverlap、PCG global reductionsの融合などを挙げている。

玄界上でのベースライン（小林）

• 条件：OpenFOAM-v2606、MPIはMVAPICH 3.0-gcc8.5.0、decompositionはscotch、各ノード数3回ずつ実行。

  ノード数	平均実行時間 [s/step]	Best実行時間	ばらつき	Best FVOPS
  1	32.384	31.869	4.84%	2.0082 M
  2	17.929	17.312	9.42%	3.6968 M
  4	6.816	6.678	3.18%	9.5844 M

• Gadiの公開ベースライン（4ノードBest FVOPS 9.7785 M）と近い水準まで再現できている。2ノードのばらつき（9.42%）はやや大きく、測定回数を増やす余地がある。

アカウント・VPN・環境構築

• NSCCのアカウントは各メンバーに1つずつ付与される（ASPIRE内では個人アカウント）。
• 接続にはEndpoint Security VPNのソフトをインストールする。ユーザー名APACSC15でログインに失敗する事例があったが、原因はI（大文字アイ）とl（小文字エル）の取り違え。画像共有で解決した。VPN接続時は毎回、端末側で認証（QRコード等の二段階認証）が必要。
• NCI（Gadi）はASPIREとは別のマシン。利用にはプロジェクトのメンバーシップ申請（join）が必要で、プロジェクトコードで検索して参加リクエストを送る。各自のアカウント名でログインする。
• 接続手順は各自で一度確認し、後で画像付きにまとめてWiki（限定公開の想定）に残す。

情報共有：分報（Times）の導入

• リーダーの提案。会社で導入している経験から、効率的だったとのこと（経験談）。
• 「思ったこと・気づき・判断・決定」を時系列で書き溜め、チームで共有する。ドキュメントに残すほどでもないが後から見返したい内容の受け皿にする。
• リアルタイム性と相性が良い。夏休み期間は出社・発表がまばらになるため、記録として特に有用。
• チャンネルの粒度（個人ごと／チームごと／全体）は今後調整する。まずはTeamsに作成し、HPC／AIそれぞれの気づきを記録として残す。通知は非表示（ミュート）運用にする。

TODO

次回方針

• HPCはGadiを主軸に、4ノードのベースラインを固めてから最適化に入る。まずはdata layout／cache locality方向の候補を検討する。
• VPN・アカウントの環境が整い次第、各自が小林の測定を後追いで再現し、spreadを確認する。
• 分報を実際に運用し始め、判断や気づきを蓄積する。

参考リンク

• 2026-07-26 2MPIプロファイリング・prefill/decode分析・Nsight Systems導入
• 2026-07-05 ポイント運用・strace I/O調査・神戸勉強会の段取り
• MPI通信最適化
• 領域分割（decomposePar）
• NUMA最適化
• プロファイリングツール実践ガイド

2026年大会の現時点まとめ

公式に確認できたこと

2026年大会の公式ページは、2026 APAC HPC-AI Competitionです。

公式ページに掲載されている主要日程は次の通りです。

表彰には、First Place、Second Place、Third Place、Merit Prize、HPC Special Prize、AI Special Prizeなどがあると公式ページに書かれています。

メモ上の2026年課題候補

殴り書き.txtには、主催側の説明として次の内容が含まれています。

• HPC側: OpenFOAM HPC Committee repositoryからOpenFOAMベンチマークケースと入力ファイルを使う予定。
• HPC側: 4ノード、100コア超の現代的CPUクラスタで短時間に終わる問題サイズを選ぶ予定。
• AI側: Qwen inference / PD disaggregation inference workloadsを更新中。
• AI側: Dynamoのbenchmarksとrecipes/qwen3-235b-a22b-fp8をPBS/Slurmに適用する計画。
• ただし、正確なOpenFOAMケース、パラメータ、SGLangで使うモデル構成、測定方法は未確定。

これは重要な手がかりですが、公式ページに最終ルールとして掲載されたものではありません。現時点では「要確認」として扱います。

今年の質問リスト

大会運営に確認すべき質問です。

当面の動き方

最終ルールが出るまでは、競技固有の数値チューニングではなく、次を優先します。

• OpenFOAMの並列実行、領域分割、ログの読み方を理解する。
• LLM推論のprefill、decode、KV cache、throughput、latencyの意味を理解する。
• 実験ログのフォーマットを先に決める。
• 1回の実験で1つの変更だけを入れ、差分を説明できるようにする。

参考文献

• 2026 APAC HPC-AI Competition
• OpenFOAM HPC Committee repository
• Dynamo benchmarks
• Dynamo Qwen3-235B-A22B-FP8 recipe

2025年大会の振り返り

公式発表で確認できる2025年課題

HPC-AI Advisory Councilの2025年結果PDFでは、2025年大会の課題が次のように説明されています。

公式PDFでは、参加者がprofiling、algorithmic refinements、architecture-specific tuningを使ってHPC/AI性能を改善したことも説明されています。

日本チームの結果

東京農工大学などのプレスリリースでは、理研R-CCSが支援した4チームの入賞が確認できます。

このプレスリリースでは、理研R-CCSが2025年大会から学生出場支援事業を開始し、練習用計算資源として九州大学のスーパーコンピュータ「玄界」の利用支援などを行ったことも説明されています。

参加記から得られる実践知

木更津高専チームの参加記は公式ルールではありませんが、初心者チームが何に詰まるかを知るうえで有用です。

主な学びは次の通りです。

• 最初の数週間は、最適化以前にクラスタ、VPN、2FA、ジョブスケジューラ、モデルロードに慣れる時間になる。
• 2025年のAI側では、SGLang公式ドキュメントとブログを読み、parallelism、batch size、network、attention、MoE/MTPなどを調べている。
• 実験は300回規模になり得るため、実験前に仮説を書き、実験後に設定、結果、ログ、解釈を残す仕組みが必要。
• 成功例だけでなく、期待した高速化が出なかった例も重要。例えばDP Attentionは文献上よく見えても、実環境ではスループットが落ちる可能性がある。

2026年に引き継ぐべき教訓

1. ベースラインをまず動かす。
2. 実行時間、ロード時間、I/O、ネットワーク、GPU使用率、CPU使用率を分けて見る。
3. 「速くなった」ではなく、「どのメトリクスが、どの条件で、どれだけ変わったか」を記録する。
4. 大会ルール上禁止される可能性がある変更を、早い段階でリストアップする。
5. プレゼン評価もあるため、最終スコアだけでなく実験設計と説明可能性を残す。

参考文献

• HPC-AI Advisory Council Announces Results of the 8th APAC HPC-AI Competition
• 学生向け計算科学分野国際コンペティションで上位入賞
• The 8th APAC HPC-AI Competition参加記

プロファイリングと性能分析

これは何か

プロファイリングは、プログラムの実行時間、CPU/GPU使用率、メモリ使用量、通信時間、I/O待ち時間を計測する作業です。 最適化の前に必ず行い、「どこが遅いのか」を事実で確認します。

コンテストで上位を狙うには、最初からコードや設定を勘で変えるのではなく、まず性能探偵として遅い場所を特定することが重要です。

なぜ重要か

HPCやAI推論では、遅く見える原因が一つとは限りません。

• CPU計算が重い。
• GPUが十分に使えていない。
• GPU間通信が詰まっている。
• MPI通信待ちが長い。
• KV cacheやメモリアクセスが帯域不足になっている。
• I/Oやモデルロードで待っている。
• CPU側の前処理がGPUを待たせている。

ボトルネックを特定しないまま最適化すると、スコアに効かない場所へ時間を使う危険があります。

キャッチアップすべき技術一覧

HPCコンテストでの優先順位

去年の課題との対応

2025年AI部門では、単純なCUDA最適化よりも、次の順番で状況を切り分ける力が重要だった可能性があります。

1. GPUは本当に忙しいのか。
2. GPU間通信で詰まっていないか。
3. KV cache参照で帯域不足になっていないか。
4. CPUがGPUを待たせていないか。

これは要確認の推測ですが、SGLangや大規模LLM推論では、GPU kernel単体の高速化だけでなく、batching、KV cache、GPU間通信、CPU側スケジューリングが全体性能に影響します。

最初に見るべき指標

代表ツール

実験の進め方

1. 何も変更しないbaselineを測る。
2. CPU、GPU、通信、I/Oのどこで時間を使っているかを大まかに分ける。
3. 最も時間割合が大きい箇所を1つ選ぶ。
4. その箇所に対して1つだけ変更する。
5. 同じ条件で再測定する。
6. 速くなった理由、遅くなった理由、変わらなかった理由を記録する。

実験ログテンプレート

experiment_id:
date:
target:
baseline_command:
changed_setting:
nodes:
cpus:
gpus:
input_size:
profiling_tool:
wall_time:
cpu_summary:
gpu_summary:
memory_summary:
communication_summary:
io_summary:
bottleneck_hypothesis:
result:
next_action:

参考文献

• Linux perf tools documentation
• Intel VTune Profiler Documentation
• NVIDIA Nsight Systems User Guide
• NVIDIA nvidia-smi Documentation
• NVIDIA NCCL Documentation
• Open MPI Profiling Interface

ボトルネック分析

このページは、2026-06-05の勉強会でチームが共有したボトルネック分析の基礎をまとめたものです。 担当: 渡邉。

これは何か

ボトルネック分析とは、プログラム全体の実行時間のうち、どこが最も時間を使っているかを切り分ける作業です。 最適化の前に必ず行い、「速くすべき場所」を事実で決めます。

なぜ重要か

HPCでは、「CPUが遅いからCPUを速くする」という発想は的外れになりやすいです。 実際には、次の場所がボトルネックになることが多いです。

• メモリアクセス（帯域待ち）
• ノード間通信（MPI）
• 同期待ち（待機・idle）

つまり、計算そのものより「待ち時間」が支配的になりやすい、という認識が出発点です。

基本フロー

最初に、全体時間を次の観点で分解します。

マクロからミクロへ：最適化の定石

いきなりソースコードの行を見てはいけません。 ボトルネックの「種別」を大局から絞り込みます。

合言葉は「推測するな、計測せよ」。低負荷ツールで「当たり」をつけ、高負荷ツールで「原因」を特定します。

ツールの詳細はプロファイリングツール実践ガイドにまとめています。

注意点

• 計測ツール自体にオーバーヘッドがあります。マクロ→ミクロの順で、必要なときだけ重いツールを使います。
• 1回の実験で変える条件は1つにします。
• 「速くなった」だけでなく、なぜ速くなったかを記録します。

関連ページ

• プロファイリングと性能分析
• プロファイリングツール実践ガイド
• スケーリング分析
• MPI通信最適化

参考文献

• Linux perf tools documentation
• Score-P Documentation

プロファイリングツール実践ガイド

このページは、2026-06-05の勉強会でチームが整理した「用途別プロファイラ・トレースツールの全体像」をまとめたものです。 個々のツールの公式情報は参考文献を参照してください。

これは何か

性能解析ツールは、何をどの粒度で測りたいかによって使い分けます。 ここでは、抽象度（マクロ／ミドル／ミクロ）と対象レイヤ（CPU／MPI／OpenMP／GPU／メモリ）で整理します。

大局から局所へ：3つの抽象度

レイヤ別の代表ツール

CPU（計算密度・メモリアクセス）

gprofは関数プローブのオーバーヘッドが大きく、現代のHPCでは非推奨とされています。

MPI（通信・同期のオーバーヘッド）

アプリが「計算」しているのか「待機」しているのかを切り分けます。

MPIトレース・タイムライン可視化

「なぜ・いつ・誰のせいで待機したか」を時系列で追います。

GPU（ホスト連携→カーネル深掘り）

最大の罠は「いきなりGPUカーネル内部を見ること」。まずCPU-GPU間のデータ転送(PCIe)を疑います。

OpenMP（並列インバランスと同期）

「CPU使用率が100%か」ではなく「有意義な計算をしているか」を問います。

メモリ（安全性検証とヒープ最適化）

富岳・HPCコンテストでよく使う組み合わせ

チームの調査では、富岳環境で次のツールが定番として挙がりました（実機・利用可否は要確認）。

• 必須: mpiP / Score-P / Cube / perf / nsys（GPU使用時）
• 発展: Scalasca / Vampir / HPCToolkit / VTune

OpenFOAMのMPI最適化なら、次の流れが強力とされています。

mpiP  →  Score-P  →  Cube  →  Scalasca

まず何から使うか（チームの結論）

• 最初の一手は perf + mpiP。低負荷で「当たり」をつけられる。
• 必要に応じてScore-P/Cube/Scalascaへ深掘りする。

perf の実践的な使い方（チーム調査メモ）

2026-06-19の勉強会で田中が共有した内容。perfは日本語情報が少なく、man、Archwiki、ライブコーディング動画（impl Rust: One Billion Row Challenge）が学習に役立った。

よく使うコマンド

注意点

• perf recordはイベント数が多すぎると問題になる（長時間実行・並列実行）。perf report等で解析できなくなり、ストレージも圧迫する。
• 対策として、実行中のプロセスへ短時間だけアタッチする: perf record -F 999 -g --call-graph fp -p <PID> -- sleep 30。
• 可視化の補助ツールとしてflamegraphが便利。
• 今後の課題: MPI環境でのperf等の使い方を実際に動かして確認する。

ビルドオプション（分析しやすさ vs 速度）

分析しやすさと高速化はトレードオフ。用途別（Debug / Profile / Release / Optimize など）に切り替えられるよう環境を整備する。

• 性能に影響しない: -g（デバッグ情報。無いとソース対応・シンボルが分からず、アセンブリ/ポインタ表示になる）
• 性能に影響する（最適化を抑制して分析しやすくする）:
  • -fno-omit-frame-pointer … call graphが見やすくなる
  • -fno-inline … 関数ごとの性能が見やすくなる
  • -foptimize-sibling-calls（を無効化）… 末尾呼び出しのジャンプ化を抑え、関数ごとの性能が見やすくなる

注意点

• 富岳前提のツール構成です。2026年大会の実機は未確定なので、利用可能なツールは要確認です（調査ステータス）。
• ツールはオーバーヘッドが大きいものほど後段で使います。

関連ページ

• ボトルネック分析
• プロファイリングと性能分析
• スケーリング分析

参考文献

• Linux perf tools documentation
• Intel VTune Profiler Documentation
• NVIDIA Nsight Systems User Guide
• NVIDIA Nsight Compute Documentation
• Score-P Documentation
• Scalasca
• Vampir
• mpiP: Lightweight, Scalable MPI Profiling
• Linaro Forge (MAP)
• Arch Wiki: デバッグ/プロファイリング
• Arch Wiki: パフォーマンスの向上
• One Billion Row Challenge
• impl Rust: One Billion Row Challenge (YouTube)
• flamegraph-rs/flamegraph

スケーリング分析

このページは、2026-06-05の勉強会でチームが共有したスケーリング分析の基礎をまとめたものです。 担当: 田中。

これは何か

スケーリング分析とは、ノード数・コア数・MPIランク数・OpenMPスレッド数などの計算資源を変えたときに、実行時間や並列効率がどう変化するかを測り、並列化の限界やボトルネックを特定する分析です。

CPU計算を単純に速くする方法として「CPUの数を増やす」「クロック周波数を上げる」が考えられますが、資源を増やした分だけ速くなるとは限りません。それを確かめるのがスケーリング分析です。

基本概念

理想的には、CPU/nodeを 1, 2, 4, … と増やすと実行時間が 1/1, 1/2, 1/4, … と減るはずですが、実際にはきれいに比例しません。

なぜ理想どおりにならないか

特にload imbalanceは重要です。一部のrankが先に終わっても、最も遅いrankが終わるまで全体は終わりません。追加したnodeの効果が「待ち」で失われます。

大会との関係

• 「ノードを増やせば勝てる」ではなく、どこまで増やすと効率が落ちるかを把握することが重要です。
• 領域分割の手法（scotchなど）やrank数の調整で、スケーリングが改善することがあります（領域分割）。

最初に見るべき指標

改善の進め方

実行時間だけを見るのではなく、計算資源を変えながら対照実験を行い、プロファイリングで原因を特定します。

1. 入力を固定し、node/rank/thread数を変えて測る（strong scaling）。
2. speedupと並列効率を出し、頭打ちになる点を探す。
3. その点でプロファイルを取り、逐次部分・通信・load imbalanceのどれが原因か切り分ける。
4. 原因に応じて対策（分割手法変更、rank数調整、通信削減など）を1つずつ試す。

代表的なプロファイリングツールはperfです。詳しくはプロファイリングツール実践ガイドを参照してください。

実験ログテンプレート

experiment_id:
date:
case:
nodes:
ranks:
threads:
wall_time:
speedup_vs_1node:
parallel_efficiency:
rank_time_imbalance:
bottleneck_hypothesis:
notes:

関連ページ

• ボトルネック分析
• プロファイリングと性能分析
• MPI通信最適化
• 領域分割（decomposePar）

参考文献

• Amdahl’s law (Wikipedia)
• OpenFOAM v13 User Guide: Running applications in parallel

I/O最適化

このページは、2026-06-05の勉強会でチームが共有したI/O最適化の基礎をまとめたものです。 担当: 小林。HPCとAIの両方にまたがるため、性能分析章に置きます。

これは何か

I/O最適化とは、システムやストレージにおけるデータ読み書きの処理効率を高め、待ち時間を減らす手法です。 計算が速くても、ファイルの読み書きで待っていると全体は遅くなります。

HPC（OpenFOAM）でのI/O

OpenFOAMでは計算中に次のI/Oが発生します。

• モデルロード、初期メッシュ読み込み
• 境界条件・物性値ファイルの読み込み
• 各時刻ディレクトリへの結果出力、ログ出力
• 並列実行時のprocessor*/以下への読み書き
• post-processing用データ出力

対策の方向性

scratch領域とは、マシンから高速にアクセスできる作業用ディレクトリのこと。計算中に一時的に使います。

富岳でのI/Oプロファイリング（要確認）

富岳の利用手引書には、I/Oプロファイリング・I/O最適化の項目があり、DarshanやLLIO情報でI/O待ちを確認できるとされています。 ただし2026年大会の実機・利用可否は未確定です（調査ステータス）。

AI（Qwen multi-GPU推論）でのI/O

Qwenのmulti-GPU推論では、次のデータ移動が性能に影響します。

• モデル重みの読み込み
• 入力リクエストの読み込み
• CPU → GPU 転送
• GPU間通信（NCCL）
• KV cacheの読み書き
• prefill worker → decode worker のデータ受け渡し
• ログ出力

対策の方向性

昨年のI/O最適化（経験談）

• 昨年のHPCでは、一時ファイル・中間ファイルの置き場所をscratch領域に変えて高速化していた、との情報があります（要確認）。
• AI課題でも、本番でDeepSeekの重みをscratch領域に置けたとの話がありますが、玄界では不可だった可能性も指摘されています（要確認）。

出典: 木更津高専チームの参加記（経験談）。

最初に見るべき指標

注意点

• scratch領域の利用可否・容量は環境ごとに違います。大会の実機ルールで要確認です。
• I/Oを減らすために結果出力を削りすぎると、解析・検証ができなくなります。

関連ページ

• プロファイリングと性能分析
• NCCL通信最適化
• OpenFOAM課題の入口

参考文献

• 富岳 利用手引書（利用及びジョブ実行編）
• Darshan HPC I/O characterization tool
• 木更津高専チームの参加記

OpenFOAM課題の入口

OpenFOAMとは

OpenFOAMは、CFD、つまり数値流体力学のためのオープンソースソフトウェア群です。2026年大会のHPC側では、メモ上、OpenFOAM HPC Committee repositoryのケースが使われる可能性があります。

現時点では、どのケースが大会本番で使われるかは未確定です。

OpenFOAM HPC Committee repository

OpenFOAM HPC Benchmark SuiteのREADMEでは、このリポジトリの目的が次のように説明されています。

• HPCアーキテクチャ上でデータセットをセットアップして実行するためのガイドや初期スクリプトを提供する。
• ハードウェア、ソフトウェア環境、設定を比較するための共通基準を提供する。
• 性能を測るためのKPIを定義する。

README上では、Grand Challenges、Industrial Applications、Microbenchmarks、Other Benchmarksに分かれ、DrivAer、cavity、motorbike、combustion、wind farmなど複数のケースが整理されています。

OpenFOAMの並列実行の基本

OpenFOAM v13 User Guide: Running applications in parallelでは、OpenFOAMの並列実行はdomain decomposition、つまり計算領域を複数の部分に分割して各プロセスに割り当てる方式だと説明されています。

基本の流れは次の通りです。

1. decomposeParDictで分割数と分割方法を決める。
2. decomposeParでメッシュと初期場を分割する。
3. mpirunなどでソルバを-parallel付きで実行する。
4. 必要ならreconstructParで結果を再構成する。

よく出る分割方法は次の通りです。

性能に効きそうな場所

初心者が最初に見るべき観点です。

最初の実験テンプレート

本番ケースが出たら、まず次を固定してベースラインを作ります。

参考文献

• OpenFOAM HPC Committee repository
• OpenFOAM v13 User Guide: Running applications in parallel
• High Performance Computing Technical Committee - OpenFOAM Wiki
• The First OpenFOAM HPC Challenge (OHC-1)

OpenFOAM最適化の考え方

最適化の単位

OpenFOAMの高速化は、少なくとも次の層に分けて考えます。

大会では「どこまで変更してよいか」が最重要です。最終ルールが出るまでは、設定変更と計測基盤の準備に寄せるのが安全です。

ボトルネックの探し方

最初に見るべき症状と対応です。

OpenFOAMで特に注意すること

I/O

OpenFOAMの並列実行では、rankごとにprocessor*ディレクトリが作られます。大規模並列ではファイル数が増え、I/Oが詰まることがあります。

OpenFOAM user guideでは、collated file handlerにより、分割されたfieldやmeshをまとめた形式で扱えると説明されています。ただしMPIのthreading supportなど環境条件があります。

領域分割

分割は「セル数を均等にする」だけでは不十分です。境界面が増えると通信が増えます。乱暴にrankを増やすと、計算より通信の割合が増えて遅くなることがあります。

収束条件

toleranceやrelTolを緩めると速くなる場合がありますが、結果の正当性が変わります。大会で許されるか、評価がwall timeだけか、物理結果の検証があるかを確認する必要があります。

実験ログの最小項目

experiment_id:
date:
author:
case:
openfoam_version:
git_commit:
nodes:
ranks:
threads:
decomposition:
solver_settings_changed:
io_settings_changed:
command:
wall_time:
iteration_count:
residual_summary:
stdout_log:
stderr_log:
notes:
next_action:

参考文献

• OpenFOAM v13 User Guide: Running applications in parallel
• OpenFOAM HPC Benchmark Suite
• The First OpenFOAM HPC Challenge (OHC-1)

CPU最適化（コンパイラ・ライブラリ）

このページは、2026-06-05の勉強会でチームが共有したCPU最適化の基礎をまとめたものです。 担当: 田中。

これは何か

ここでのCPU最適化とは、コンパイラ・ライブラリとそれらの設定を適切に行うことでCPU計算部分を高速化し、実行時間を短縮することとします。 アルゴリズム自体を書き換えるのではなく、「ビルドの仕方」と「使うライブラリ」で速くするアプローチです。

なぜ重要か

• 実装をほとんど変えずに高速化できる可能性があり、コストが低い。
• ハードウェアの性能を引き出せる。
• 一方で、検証コストが大きく、ハードウェアへの理解が必要です。

2025年大会（NWChem）のルールでは、次が許可された最適化として挙げられていました（昨年のルール。今年は要確認）。

• Compiler optimizations: 異なるコンパイラ（Intel、GCC、AOCC）と最適化フラグ
• Mathematical libraries: 最適化されたBLAS/LAPACK（Intel MKL、OpenBLAS、AOCL）の利用
• Parallel strategies: MPI設定、hybrid並列、プロセス配置・affinity、スレッド管理

コンパイラ最適化フラグ

コンパイルオプションを、マシン/プログラムに合わせて組み合わせると、実装を変えずに高速化できる可能性があります。

gccの代表的な最適化オプション:

競技プログラミングで知られるQCFium法のように、pragmaで局所的に指定する例もあります。

#pragma GCC target("avx2")
#pragma GCC optimize("O3")
#pragma GCC optimize("unroll-loops")

参考実験では、これらの指定で約29%（×1.2〜1.5程度）速くなったケースが報告されています（経験談・環境依存）。

-Ofastの注意（重要・要確認）

-Ofastなどの一部の最適化は、次のように数値の振る舞いを変えます。

• 演算の結合順序の変更
• 近似的な数学関数・命令の利用
• NaNや無限大が発生しないと仮定する
• +0.0と-0.0を区別しない
• 動的な丸めモードを無視する

これにより、数値・分岐条件・収束過程の変更、計算精度の劣化が起こりえます。

2025年大会の禁止事項（昨年のルール）には次がありました。今年も同様かは要確認です。

• Algorithm alteration（基本アルゴリズムの変更）
• Precision reduction（計算精度・データ精度の低下）
• Input modification（分子構造、basis set、収束条件の変更）

→ -Ofast系が大会でどこまで許容されるかは、必ずルールで確認し、結果が変わらないか検証すべきです。

検証手段：サニタイザー

望ましくない動作・未定義動作をピンポイントで検出するために、サニタイザーを使います。

-fsanitize=address,undefined
-fno-omit-frame-pointer

ライブラリ選定

数値ライブラリと並列ランタイムにも複数の実装があり、組み合わせで高速化を狙えます。 適切に選ばないと、むしろ並列計算効率が落ちることがあります。

BLASは行列・ベクトル演算の標準API、LAPACKはそれを使う線形代数ライブラリです。

さらに調べるべきキーワード（チームの宿題）

まとめ

• 利点: 実装コストを抑えつつ大幅な高速化が期待でき、ハード性能を引き出せる。
• 欠点: 検証コストが大きく、ハードウェア理解が必須。
• -Ofast系は精度に影響するため、大会での許容範囲を要確認。

関連ページ

• 富岳（A64FX）アーキテクチャ
• NUMA最適化
• OpenFOAM最適化の考え方

参考文献

• GCC Optimize Options
• QCFium法 (Codeforces blog)
• OpenBLAS
• Intel oneMKL Documentation

MPI通信最適化

このページは、2026-06-05の勉強会でチームが共有したMPI通信最適化の基礎をまとめたものです。 担当: 松村。OpenFOAM最適化の中心テーマです。

これは何か

MPI（Message Passing Interface）は、複数プロセス間でデータをやり取りするプロセス間通信ライブラリです。 例: MPI_Send()、MPI_Recv()。

HPCクラスタでは、Node1〜Node4のように数百〜数万のCPUコアが協調して計算します。 そのため、プロセス間の通信が性能を大きく左右します。

なぜMPI通信が必要か

100万セルの流体解析を例にすると、1つのCPUで全部解く代わりに、領域を複数のrank（Rank0〜Rank3）に分割して並列計算します。

• 分割すると、各rankの**境界セル(Boundary Cells)**の情報を隣のrankと交換する必要があります。
• この交換（通信）がないと計算を進められません。

なぜMPI通信が「遅い」か

その差は1000倍以上です。人間サイズに換算すると「1秒 vs 約11日」というイメージです。 だからこそ、通信削減 = 高速化になります。

富岳で見るべき典型的ボトルネック

注: チームは富岳(A64FX)を前提に調査しています。2026年大会の実機は未確定です（富岳アーキテクチャ、調査ステータス）。

① MPI通信

「ノード数を増やしたのに速くならない」典型です。

対策:

• 通信回数の削減
• 通信と計算のオーバーラップ（重ね合わせ）
• MPIランク配置の改善

② メモリ帯域律速

富岳のCPUはA64FX。メモリ帯域がボトルネックになりやすいです。 詳細は富岳アーキテクチャを参照。

Load Imbalance（最重要ボトルネック）

rank間で計算量が偏ると、全体は最も遅いrankに引っ張られます。

→ 全体 = 10秒。速いrankが遊んでいる分、追加した計算資源が無駄になります。 対策は領域分割の改善です（領域分割）。

OpenFOAMの典型的ボトルネック

OpenFOAMはCFD（速度・圧力・温度を解く）で、最終的に巨大な連立一次方程式 Ax = b を解きます。

計算の流れ:

メッシュ生成 → 行列構築 → Pressure Solver → 結果出力

実行時間の多くはPressure Solver（圧力ソルバ）が占めます。

反復法とMPI_Allreduce

Pressure SolverはCG系の反復法（CG、PCG、BiCGStab、GAMGなど）で、正解に少しずつ近づきます。 各反復で残差を計算し、全rankで合わせるためにMPI_Allreduceを使います。

MPI_Allreduceとは: 各rankの値（局所誤差）を集約して全体の値（全体誤差）を計算し、全rankへ配り直す collective通信です（Gather → 合算 → Broadcast）。

Pressure Solver → 残差計算 → MPI_Allreduce → 全員同期 → Pressure Solver → ...

このループが本当のボトルネックになりがちです。

なぜAllreduceが大量発生するのか

CG反復は、反復ごとにMPI_Allreduceを繰り返します。 例えば300 iterationなら、300回以上の通信が発生します。

Pressure Solver 起動 → MPI_Allreduce 頻発 → 通信待ち(Idle) → （繰り返し）

→ 結論: 通信最適化が重要。研究者は次を頑張ります。

• ソルバ変更（PCG → GAMG）
• 通信回数の削減
• rank数の調整
• メッシュ分割の改善（領域分割）

最初に見るべき指標・設定

注意点

• ソルバや収束条件（tolerance/relTol）の変更は、物理結果や収束性に影響します。大会で変更可能か要確認です。
• 富岳前提の議論です。実機の通信特性（InfiniBand/Tofu等）は環境依存です。

関連ページ

• 領域分割（decomposePar）
• 富岳（A64FX）アーキテクチャ
• OpenFOAM最適化の考え方
• スケーリング分析
• プロファイリングツール実践ガイド

参考文献

• Open MPI Documentation
• OpenFOAM v13 User Guide: Running applications in parallel
• The First OpenFOAM HPC Challenge (OHC-1)

領域分割（decomposePar）

このページは、2026-06-05の勉強会でチームが共有した領域分割（OpenFOAMのdecomposePar）の基礎をまとめたものです。 担当: 松村。

これは何か

decomposeParは、OpenFOAMのメッシュを複数のrank（プロセス）へ分割するコマンドです。 分割方法はdecomposeParDictのmethodで指定します。

ポイントは、分割の断面 = 通信が発生する面ということ。分割の仕方で通信量と負荷分散（load imbalance）が決まります。

なぜ重要か

• 分割の断面積が大きいほど、隣接rankとのMPI通信が増えます。
• rank間で計算量が偏ると、速いrankが遅いrankを待ち、並列効率が落ちます。
• つまり、領域分割は通信量とロードバランスの両方に効く重要な設定です。

主な分割手法

コンテスト視点：試す順番

チームのおすすめの順番です（経験談）。

1. hierarchical … 速い・設定簡単
2. scotch … まず比較対象にする
3. ptscotch … 超大規模メッシュ向け

実際のHPCコンテストでは、decomposeParDictのmethodをscotchに変えただけで10〜30%高速化するケースも珍しくありません（経験談・環境依存）。

設定例:

// decomposeParDict
method scotch;

最初に見るべき指標・設定

注意点

• ptscotchは巨大メッシュで効果的ですが、小さいメッシュでは恩恵が小さいことがあります。
• 分割を変えたら、必ずbaselineと同じ条件で再測定し、効果をプロファイルで確認します。
• 大会で変更可能な設定範囲は要確認です。

関連ページ

• MPI通信最適化
• OpenFOAM最適化の考え方
• スケーリング分析

参考文献

• OpenFOAM v13 User Guide: Running applications in parallel
• Scotch and PT-Scotch

NUMA最適化

このページは、2026-06-05の勉強会でチームが共有したNUMA最適化の基礎をまとめたものです。 担当: 渡邉。

これは何か

NUMA（Non-Uniform Memory Access）は、マルチプロセッサ・システムにおけるメモリ配置のアーキテクチャです。 各プロセッサが個別のローカルメモリを持ち、それに直接アクセスします。

なぜ重要か

• 近いメモリ（ローカル）にアクセスすれば速い。別ノードのメモリ（リモート）にアクセスすると遅い。
• そのため、ローカルメモリを有効に使えるようにスレッドを配置することが重要です。
• 配置を誤ると、リモートメモリアクセスが増えて遅くなります。

基本概念

ローカルメモリ・リモートメモリ

スレッドが使うメモリを、できるだけそのスレッドが動くプロセッサのローカル側に置くのが理想です。 同じメモリにアクセスするスレッドは、同じノードにまとめます。

プロセッサ・アフィニティ

特定のプロセッサ・コアへのスレッド/プロセスの割り当てを保持し続けることです。

• スレッドが使うメモリをローカルに保てる。
• ただし、OSの効率的なリソース管理を妨げる可能性があるため、慎重に設定します。
• numactlコマンドで、NUMAポリシーを制御し、特定ノードでプロセスを動かせます。

ファーストタッチポリシー

OSが、そのメモリ領域に最初にアクセスしたプロセスにメモリを紐付ける仕組みです。

• NUMAを有効に使うには、初期化スレッドと実行スレッドを一致させる必要があります。
• つまり、データを使う実行スレッド自身に初期化させると、ローカルメモリに割り当たります。

大会との関係

• 2025年大会のルールでは「System-level tuning: NUMA topology optimization」が許可項目として挙げられていました（昨年のルール。今年は要確認）。
• マルチソケット/マルチNUMAノード環境では、CPU pinningとファーストタッチでメモリ局所性を上げられます。

最初に見るべき指標・設定

注意点

• アフィニティ固定はOSのスケジューリングと衝突することがあるため、効果を測りながら設定します。
• NUMA最適化は環境構造（ソケット数・NUMAノード数）に強く依存します。

関連ページ

• 富岳（A64FX）アーキテクチャ
• CPU最適化（コンパイラ・ライブラリ）
• プロファイリングと性能分析

参考文献

• iSUS: NUMA 向けの最適化
• iSUS: Understanding NUMA for 3D finite difference (PDF)
• numactl(8) man page

富岳（A64FX）アーキテクチャ

このページは、2026-06-05の勉強会でチームが共有した富岳/A64FXに関する基礎をまとめたものです。

重要（要確認）: チームは富岳(A64FX)を前提に最適化を調査していますが、2026年大会で使う実機は未確定です。 運営メモでは「4ノード・100+コアのCPUクラスタ」とされ、2025年大会では玄界が使われたとの情報もあります。 このページの内容は「富岳前提の調査」として扱い、最終ルールで実機を確認してください（調査ステータス）。

これは何か

富岳は理化学研究所のスーパーコンピュータで、CPUにA64FXを採用しています。

なぜ重要か

A64FXはCPU演算性能が比較的強い一方で、**メモリ帯域がボトルネック（メモリ帯域律速）**になりやすい特性があります。 つまり「CPUを速くする」より「メモリアクセスと通信を改善する」方が効くことが多い、という前提で最適化を考えます。

メモリ帯域律速への対策

SVE(Scalable Vector Extension)は、ベクトル長に依存しないArmのSIMD拡張です。富岳では512bit幅(SVE512)です。

大会との関係

• もし実機が富岳系なら、A64FX/SVE/HBM2の特性を踏まえた最適化が有効になります。
• ただし前述のとおり実機は未確定です。実機が異なる場合、-marchやSVE前提の最適化は効果が変わります。

注意点

• 「A64FXは強いらしい」という認識はあくまで一般論で、実アプリ（OpenFOAM等）では帯域・通信が律速になりがちです。
• 実機・コンパイラ・利用可能ツールは大会のルール公開後に必ず見直します。

関連ページ

• MPI通信最適化
• NUMA最適化
• CPU最適化（コンパイラ・ライブラリ）
• 調査ステータス

参考文献

• 富岳 公式サイト（理研R-CCS）
• A64FX / SVE 入門記事（Qiita）
• 富岳 利用手引書（利用及びジョブ実行編）

LLM推論課題の入口

今年のAI側で出ている名前

メモ上では、2026年AI側の議論に次の名前が出ています。

Qwen3-235B-A22B

Qwen3-235B-A22BのHugging Faceモデルカードでは、主な仕様が次のように説明されています。

MoEなので、全パラメータを毎token使うわけではありません。ただし、重みはGPUメモリ上に載せる必要があるため、active parametersだけで必要VRAMを見積もると失敗します。

SGLang

SGLang公式ドキュメントでは、SGLangは大規模言語モデルとマルチモーダルモデル向けの高性能serving frameworkと説明されています。特徴として、RadixAttention、prefix caching、multi-GPU parallelismなどが挙げられています。

2025年大会のAI側では、DeepSeek-R1 671BをSGLangで推論する課題だったことが公式発表で確認できます。

Dynamo

NVIDIA Dynamoは、分散LLM servingのためのframeworkです。メモ上では、Dynamoのbenchmarksとrecipes/qwen3-235b-a22b-fp8が2026年AI側の参考として示されています。

ただし、該当recipeのREADMEはTensorRT-LLM向けと説明しているため、SGLang課題とどう関係するのかは大会運営への確認が必要です。

推論の2段階: prefillとdecode

LLM推論は大きく2段階に分かれます。

SGLangのPD Disaggregationドキュメントも、prefillは計算集約、decodeはKV cache管理を伴うメモリ集約と説明しています。

continuous batchingとKV cache

concurrencyを上げるとは、複数requestを同時に投げ、serving engine側で並行処理させることです。ただし、GPU上で完全に別々の処理を8本走らせるという意味ではありません。

SGLangやvLLMのようなserving engineでは、schedulerがrequest queueから実行対象を選び、prefill/decode単位でbatch化し、GPUへまとめてforwardします。このときrequestごとの途中状態はKV cacheとして管理されます。

押さえる語彙:

concurrencyを上げると総throughputは伸びやすい一方、TTFTやtail latencyが悪化することがあります。チームのQwen3-30B初期測定でも、concurrency 8ではoutput TPSが伸びる一方でTTFT p50とP99 latencyが悪化しました。

参考文献

• Qwen/Qwen3-235B-A22B model card
• Qwen3 blog
• SGLang Documentation
• SGLang PD Disaggregation
• SGLang Benchmark and Profiling
• Inside vLLM: Anatomy of a High-Throughput LLM Inference System
• NVIDIA Dynamo GitHub
• Dynamo Qwen3-235B-A22B-FP8 recipe

PD Disaggregation

何を分けるのか

PD disaggregationは、LLM推論のprefillとdecodeを別々のworker poolに分ける構成です。

SGLangの説明では、従来の統合engineではprefill batchとdecode batchが同じengineで処理され、decode遅延やDP attentionの不均衡が起きると説明されています。

Dynamoのdesign docでは、disaggregated executionを次の3段階として説明しています。

1. prefill engineがprefillを計算し、KV cacheを生成する。
2. prefill engineがKV cacheをdecode engineへ転送する。
3. decode engineがdecodeを実行する。

なぜ速くなる可能性があるのか

prefillとdecodeは得意なGPU配置・並列化が違います。

この2つを同じworkerで雑に混ぜると、長いprefillがdecodeを邪魔し、ユーザーから見たtoken生成が遅くなることがあります。

RDMAとKV転送

Dynamoのdisaggregated servingドキュメントでは、KV cacheをprefill側GPU memoryからdecode側GPU memoryへ転送するため、RDMAが重要だと説明されています。Dynamo docsでは、RDMAなしではKV cache transferが大きなボトルネックになり得るとも説明されています。

大会環境でInfiniBand、RoCE、UCX、NIXL、Mooncakeなどが使えるかは、必ず確認します。

SGLangとDynamoの関係

DynamoのSGLang backend docsでは、SGLang単体のdisaggregationとDynamo統合時の流れが少し違うと説明されています。

大まかには次の理解でよいです。

最初に見るメトリクス

PD disaggregationの評価では、総throughputだけでは不十分です。

注意点

• PD disaggregationは常に速いとは限らない。短いprompt中心なら転送コストが勝つ可能性がある。
• RDMAが弱い環境では、KV transferがボトルネックになる。
• prefill/decode worker数の比率を間違えると、片方が詰まる。
• 競技評価が総throughputだけの場合、実サービスらしいlatency最適化と衝突する可能性がある。

参考文献

• SGLang PD Disaggregation
• NVIDIA Dynamo: Disaggregated Serving design doc
• NVIDIA Dynamo: Disaggregated Serving user guide
• Dynamo SGLang disaggregation docs

AI推論ベンチマーク指標

なぜ指標が重要か

LLM推論の最適化では、「速い」の意味が複数あります。大会のスコアが総throughputだけなら高concurrencyに寄せる戦略が強くなります。一方で、実サービスの会話体験ではTTFTやTPOTが重要になります。

メモ上の議論でも、「高concurrencyで総throughputは上がるが、1リクエストあたりのtoken生成速度が落ちる」という懸念が出ています。

基本指標

ベンチマークで固定すべき条件

Dynamo/AIPerf

Dynamoのbenchmarks/README.mdでは、Dynamo deploymentの測定にAIPerfを使う例が示されています。例では、--concurrency、--request-count、--streamingなどを指定してprofileし、concurrency sweepでPareto分析を行う流れです。

大会でDynamo/AIPerfがそのまま使われるかは未確定ですが、指標の考え方としては有用です。

チーム測定メモ: Qwen3-30B concurrency sweep

2026-06-26のAIチーム共有スライドQwen3-30Bプロファイリング.pptxでは、Qwen3-30Bに対してconcurrencyを1、2、4、8に変えた初期結果が共有されました。

読み取り:

• concurrency 8でoutput TPSは約5.14倍になったが、理想的な8倍には届いていない。
• concurrency 4まではTTFT p50が54msから57msでほぼ横ばい。concurrency 8では102msまで悪化した。
• P99 latencyはconcurrencyを上げるほど増加した。総throughputとtail latencyのtrade-offを見る必要がある。
• GPU平均使用率は89.6%、GPUメモリ使用量は86.2GiB/95.8GiB（約90%）だった。次のsweepではOOMやKV cache不足に注意する。

この結果は初期測定メモであり、モデル、データセット、入力長、出力長、request count、warmup、生成パラメータを揃えて再測定する必要があります。

最小の比較表

実験結果は最低限この形で残します。

参考文献

• Dynamo benchmarks README
• NVIDIA Dynamo: Disaggregated Serving user guide
• SGLang Benchmark and Profiling
• SGLang PD Disaggregation

AI推論最適化の論点

まず分類する

AI推論最適化は、次の層に分けて考えます。

Qwen3-235B-A22Bで重要そうなこと

Qwen3-235B-A22BはMoEモデルです。総235Bの重みを扱いつつ、1 tokenあたりは一部expertを使います。

重要な論点は次の通りです。

• 重みロード時間とストレージ配置。
• GPUメモリ上に重みとKV cacheをどう載せるか。
• Expert Parallelismでexpert計算をどう分散するか。
• TP/PP/EPの組み合わせ。
• 長いcontextを扱う場合のprefillコスト。
• thinking mode / non-thinking modeと出力長の扱い。

SGLangで出てくる設定

参加記では、--max-running-requestsや--cuda-graph-max-bsをバッチサイズ相当の調整として扱ったと書かれています。SGLangのserver argumentsにもこれらの引数が存在します。

ただし、最適値はモデル、GPU、VRAM、context長、concurrency、CUDA graphの有無で変わります。固定値を丸写ししないで、sweepする必要があります。

SGLang concurrency調査の進め方

2026-06-26のAIチーム共有スライドでは、Qwen3-30Bでconcurrencyを1、2、4、8に変え、output TPS、QPS、TTFT p50、E2E latency p99、GPU使用率、GPUメモリ使用量を比較しました。

次の順番で進める方針です。

1. concurrencyの飽和点を探す。次は12、16、24、32などを試す。
2. 短文、長文、長出力でボトルネックを分ける。
3. SGLangのscheduler系パラメータを触る。
4. 最後にモデル、Tensor Parallel、別ランタイムを比較する。

理論上の8倍に届かない要因として、次が挙がっています。

• schedulerの管理コスト。
• KV cacheアクセスとメモリ帯域。
• decodeの逐次性。
• prefillとdecodeの干渉。
• リクエスト長のばらつき。
• GPU kernelの効率限界。

SGLang公式のBenchmark and Profilingでは、bench_servingは実運用に近いonline serving測定に使え、TTFT、TPOT、ITL、throughputを測れると説明されています。チームの測定でも、concurrencyだけでなくrequest countとwarmupを揃えます。

次に見るSGLang設定候補:

speculative decoding / MTP

SGLangのSpeculative Decoding docsでは、EAGLE、Multi Token Prediction、draft model、NGRAMなど複数の推測デコード手法が説明されています。

メモ上の議論では、ランダム重みでベンチマークすると、MTPやspeculative decodingの有効性が実運用の分布を反映しないのではないかという懸念があります。これは妥当な論点です。推測デコードは「予測したtokenがどれだけ採用されるか」に依存するため、実重み・実データ分布でないと評価が歪み得ます。

DP Attention

2025年参加記では、DeepSeekモデル向けのDP Attentionを試したものの、KV cache削減は確認できてもスループットは大きく下がったと書かれています。

この教訓は、公式ブログや論文上の高速化率をそのまま信じないことです。最適化は次の条件が揃ったときだけ意味があります。

• 同じモデルか。
• 同じGPU世代か。
• 同じbatch/concurrencyか。
• 同じ入力長・出力長か。
• 同じnetworkか。
• 同じ評価指標か。

実験の優先順位

最終ルール前にやるなら、リスクが低い順に進めます。

1. ベンチマークの測り方を固定する。
2. concurrency sweepを作る。
3. TP/PP/DP/EPの意味をチームで説明できるようにする。
4. SGLangの主要server argumentsを読む。
5. PD disaggregationの構成図を描けるようにする。
6. ルール確定後に、禁止されていない範囲で最適化候補を絞る。

参考文献

• SGLang Documentation
• SGLang Server Arguments
• SGLang Benchmark and Profiling
• SGLang Hyperparameter Tuning
• SGLang Speculative Decoding
• SGLang Pipeline Parallelism for Long Context
• SGLang v0.4 blog
• Inside vLLM: Anatomy of a High-Throughput LLM Inference System
• Qwen/Qwen3-235B-A22B model card

NCCL通信最適化

このページは、2026-06-05の勉強会でチームが共有したNCCL通信最適化の基礎をまとめたものです。 担当: 小林。

これは何か

NCCL（NVIDIA Collective Communications Library、読み: ニッケル）は、複数GPU間の通信ボトルネックを軽減するためのライブラリです。

AI課題（Qwen推論）では、Tensor Parallelやprefill-decode間の処理などでGPU間通信が発生します。 NCCLはこのGPU間のcollective通信を担います。

なぜ重要か

Qwenのような大規模LLMを複数GPUで動かすとき、モデルをGPUに分割して実行します。 このとき通信（AllReduceなど）が遅いと、GPUが計算せずに**待つ時間（idle）**が増えます。

つまりHPC-AIでは、NCCLでQwen推論中のGPU間通信を高速化し、tokens/secを上げることが目標になります。

基本概念：NCCLの主な通信

AI TrackでNCCLが使われる流れ

Tensor Parallelでは、各GPUがモデルの一部を計算します。

GPU0/1/2/3: それぞれモデルの一部を計算
        ↓
計算結果を NCCL で集約（AllReduce / AllGather）
        ↓
次の層へ進む

ここで通信が遅いと、GPUの待ち時間が増えて全体が遅くなります。

最適化手順

1. 測定する

Qwen推論を実行し、Nsight SystemsやNCCLログで次を確認します（例）。

• Prefill計算時間 / Decode計算時間
• NCCL通信時間
• GPU idle（GPU待ち時間）
• KV cache転送時間
• どのGPU間で通信しているか（通信経路）

2. ボトルネックを分類して対策する

大会との関係

• 2025年AI課題（16 H100 GPUs）でも、GPU kernel単体よりGPU間通信が律速になりやすいと考えられます（要確認）。
• prefill/decodeの配置はPD Disaggregationと関係します。

注意点

• NCCLパラメータやNIC指定は環境依存です。大会の実機・設定可否は要確認です。
• GPUプロファイリングは「いきなりカーネル内部」ではなく、まずCPU-GPU転送と通信を疑います（プロファイリングツール実践ガイド）。

関連ページ

• LLM推論課題の入口
• PD Disaggregation
• AI推論ベンチマーク指標
• I/O最適化
• プロファイリングツール実践ガイド

参考文献

• NVIDIA NCCL Documentation
• NVIDIA Nsight Systems User Guide

MPI 特別講義まとめ

これは何か

2026-07-11 の特別講義（MPI 入門）の記録です。当日の殴り書きメモを、後から読み返せる形に整理しました。

内容は MPI の仕様（specification）レベルの基礎知識が中心です。特記がない限り、ここに書いたことは MPI 標準として定まっている情報です。実装（Open MPI など）に依存する挙動は、その旨を明記します。

• MPI（Message Passing Interface）: 分散メモリ並列プログラミングの API を定めた国際標準仕様。

1. 並列計算と分散計算

メモリモデルによる分類

補足：理論値を超える Speedup

理論上の上限を超える速度向上（super-linear speedup）が観測されることがあります。主な要因は次の通りです。

• メモリとキャッシュの効果（データが分割されて各ノードのキャッシュに載りやすくなる）
• 並列探索アルゴリズムで早く解が見つかる場合
• 単なる測定上のばらつき（偶然）

2. MPI：仕様と実装の関係

「MPI は specification（仕様）」であり、実際に動くのはその実装です。ここは混同しやすいので分けて整理します。

MPI 仕様の実装（MPI 標準に準拠したライブラリ）

いずれも mpirun / mpiexec を提供し、MPI プログラムを動かすランタイム兼ライブラリです。

GPU 向けコレクティブ通信ライブラリ（MPI 実装ではない）

NCCL / RCCL / HCCL は MPI の実装ではありません。ベンダーごとの GPU/アクセラレータ向け高速コレクティブ通信ライブラリで、allreduce、broadcast、allgather などの集合通信に特化しています。

階層イメージ

• MPI（汎用メッセージパッシングの標準仕様）
  • Open MPI / MPICH / MVAPICH / Intel MPI（仕様に沿った実装）
• NCCL / RCCL / HCCL（各社が GPU 向けに出す高速集合通信エンジン。規格ではなくプロダクト）

3. MPI Hello World

MPI 入門で最初に出てくる最小プログラムです。mpirun -np N ./a.out で起動すると、同じ実行ファイルが N プロセス立ち上がり、それぞれが自分の rank・ノード名・全体プロセス数を表示します。

int main(int argc, char** argv) {
    int world_size, world_rank, name_len;
    char processor_name[MPI_MAX_PROCESSOR_NAME];

    MPI_Init(NULL, NULL);
    MPI_Comm_size(MPI_COMM_WORLD, &world_size);
    MPI_Comm_rank(MPI_COMM_WORLD, &world_rank);
    MPI_Get_processor_name(processor_name, &name_len);

    printf("Hello world from %s, rank %d/%d\n",
           processor_name, world_rank, world_size);

    MPI_Finalize();
}

各要素の意味

覚え方: MPI プログラムの本編は「MPI_Init 〜 MPI_Finalize の間」。

スライドの色分け: 赤 = MPI 関数、緑 = MPI 定義の定数・ハンドル、黒 = 通常の C 要素。

mpicc hello.c -o hello
mpirun -np 4 ./hello

出力例（どのノードにどの rank が割り当てられたか目視で確認できる）:

Hello world from node01, rank 0/4
Hello world from node02, rank 1/4
Hello world from node02, rank 2/4
Hello world from node03, rank 3/4

4. 通信パターンと基本オブジェクト

MPI でできる通信の「地図」です。

通信パターン

基本オブジェクト

MPI プログラムは「どのコミュニケータ内で」「どのデータ型のバッファを」「どの通信パターンで」やり取りするか、の 3 つを組み合わせて設計します。

5. Tag-Matching（タグマッチング）

MPI_Send と MPI_Recv は同時に呼ぶ必要はありません。MPI ランタイムが送信キュー・受信キューを管理し、条件が合った瞬間にデータを受信バッファへ渡します。この対応付けが Tag-Matching です。

マッチングに使うパラメータ

順序が入れ替わっても正しくつながる

• Recv が先: 受信側が先に MPI_Recv を呼ぶと「未完了の受信」としてキューに登録され、データ到着時に即バッファへコピーされる。
• Send（データ）が先: データが先に届くと内部バッファにストックされ、後から MPI_Recv が呼ばれた瞬間にコピーされる。

正しい source, tag, comm さえ指定すれば、送受信のタイミングをぴったり合わせる必要はありません。

マッチングのルール

• マッチング条件（source, dest, comm, tag）は一意である必要はない。同じ条件のメッセージが複数流れてよい。
• Matching in the order posted: 複数がマッチしうる場合、先にポストされた Recv から順に、先にポストされた Send とマッチする（FIFO）。これにより「送った順＝受け取った順」が保たれ、追い越し（overtaking）が起きない。

アプリからのヒント（info オブジェクト）

コミュニケータに info を付けて「自分はこういうことをしない」と宣言すると、実装がマッチング処理を最適化しやすくなります（実際のキー名・サポート状況は実装依存）。

6. ブロッキング Send/Recv の完了条件と引数

ブロッキングな MPI_Send / MPI_Recv は、安全なタイミングまで戻ってこない設計です。

注意: 関数が戻る前に、Send は送信バッファを書き換えない、Recv は受信バッファを読まないこと。

引数の役割（3 分割）

int MPI_Send(void* buf, int count, MPI_Datatype datatype,
             int dest, int tag, MPI_Comm comm)

int MPI_Recv(void* buf, int count, MPI_Datatype datatype,
             int source, int tag, MPI_Comm comm,
             MPI_Status* status)

7. 送信モード（communication modes）

同じ「送る」でも、何をもって送信完了とみなすかがモードで違います。各モードにブロッキング版とノンブロッキング版があります。

モード × ブロッキング / ノンブロッキング

8. Point-to-Point 通信の保証

MPI 標準がどこまで保証し、どこから実装依存かを整理します。キーワードは Order / Progress / Fairness / Resource limitations。

Quality implementation: MPI 標準の保証は最小限（Order 以外はかなり緩い）。実際の良い実装（Open MPI、MPICH、Intel MPI など）は、高速・公平・安定・良い進行性といった望ましい性質を最適化で提供している。「標準の最低ライン」と「実装が提供する挙動」にはギャップがある点に注意。

HPC コンペでチューニングまで踏み込むなら、実装ごとの Progress 性・背景進行の有無はかなり効いてくる。

9. ノンブロッキング通信の完了確認

MPI_Isend / MPI_Irecv は即戻り、MPI_Request を返します。実際の完了は以下のルーティンで確認します。

完了の意味

• 送信（Isend）の完了 → 送信バッファを安全に上書きできる。
• 受信（Irecv）の完了 → 受信バッファにメッセージが入っている。

単一操作の完了

複数のうちどれか 1 個の完了（ANY）

MPI_Request の配列を渡し、そのうち 1 つが完了したら教えてくれます。

典型パターン: 多数の Isend / Irecv を投げておき、Waitany / Testany で「終わった順」に処理して通信と計算を重ねる。

MPI_Request reqs[N];
/* Isend / Irecv をセットアップして reqs に入れる */
for (int finished = 0; finished < N; ++finished) {
    int index;
    MPI_Status status;
    MPI_Waitany(N, reqs, &index, &status);
    /* index 番目の通信の後処理 */
}

10. 集団通信（Collective）

集団通信はコミュニケータ単位で定義されます（defined in the context of a communicator）。そのコミュニケータに属するランクが、全員または特定パターンで同じ collective 関数を呼ぶのが前提です。

10-1. 3 つの分類軸

「nonblocking + persistent + neighborhood」を組み合わせると強力な性能チューニングができる、という布石。

10-2. 入出力パターンによる 4 分類

「誰がデータを出し、誰が結果を受け取るか」で分類します。

グラフでのイメージ

• One-To-All: ルート 1 個 → 全ノードへ広がる木（Bcast, Scatter）
• All-To-One: 全ノード → ルート 1 個へ集まる木（Gather, Reduce）
• All-To-All: 全ノード間の多重エッジ（Allgather, Alltoall, Allreduce）
• Other: 部分和や同期など、単純な送受図で表しづらいもの（Scan, Barrier）

この型を頭に入れておくと、「Allreduce を Allgather + Reduce に分解できるか」「Bcast の木構造はどうか」といった議論が整理しやすくなる。

大会との関係（メモ）

• OpenFOAM 課題（テーマ①）は分散メモリ並列 = MPI が中核。領域分割・ランク配置・通信量・MPI I/O が性能に直結する。
• 実装ごとの Progress 性・背景進行・コレクティブアルゴリズムの違いは、チューニング時の検討対象になりうる。
• 関連ページ: MPI通信最適化、領域分割（decomposePar）、NCCL通信最適化

参考文献

• MPI Forum（MPI 標準仕様）
• Open MPI Documentation
• MPICH Documentation

用語辞書

大会・HPC一般

OpenFOAM / CFD

AI推論

モデル・並列化

Framework / Tool

参考文献一覧

大会

• 2026 APAC HPC-AI Competition
• 2025 APAC HPC-AI Competition
• HPC-AI Advisory Council Announces Results of the 8th APAC HPC-AI Competition
• 学生向け計算科学分野国際コンペティションで上位入賞
• The 8th APAC HPC-AI Competition参加記

OpenFOAM / HPC

• OpenFOAM HPC Committee repository
• OpenFOAM HPC Benchmark Suite GitLab tree
• High Performance Computing Technical Committee - OpenFOAM Wiki
• OpenFOAM v13 User Guide: Running applications in parallel
• The First OpenFOAM HPC Challenge (OHC-1)

HPC最適化・プロファイリング

• Linux perf tools documentation
• Intel VTune Profiler Documentation
• Score-P Documentation
• Scalasca
• Vampir
• mpiP: Lightweight, Scalable MPI Profiling
• Linaro Forge (MAP)
• Darshan HPC I/O characterization tool
• GCC Optimize Options
• QCFium法 (Codeforces blog)
• OpenBLAS
• Intel oneMKL Documentation
• Scotch and PT-Scotch
• Arch Wiki: デバッグ/プロファイリング
• Arch Wiki: パフォーマンスの向上
• One Billion Row Challenge
• flamegraph-rs/flamegraph
• iSUS: NUMA 向けの最適化
• iSUS: Understanding NUMA for 3D finite difference (PDF)
• A64FX / SVE 入門記事（Qiita）
• 富岳 公式サイト（理研R-CCS）
• 富岳 利用手引書（利用及びジョブ実行編）

GPU / NCCL

• NVIDIA NCCL Documentation
• NVIDIA Nsight Systems User Guide
• NVIDIA Nsight Compute Documentation

Qwen / LLM

• Qwen/Qwen3-235B-A22B model card
• Qwen3: Think Deeper, Act Faster
• Qwen3 Technical Report

SGLang

• SGLang Documentation
• SGLang Server Arguments
• SGLang Benchmark and Profiling
• SGLang Hyperparameter Tuning
• SGLang PD Disaggregation
• SGLang Speculative Decoding
• SGLang Pipeline Parallelism for Long Context
• SGLang v0.4 blog

vLLM / 推論システム

• Inside vLLM: Anatomy of a High-Throughput LLM Inference System

Dynamo / NVIDIA

• NVIDIA Dynamo GitHub
• Dynamo benchmarks
• Dynamo Qwen3-235B-A22B-FP8 recipe
• NVIDIA Dynamo: Disaggregated Serving design doc
• NVIDIA Dynamo: Disaggregated Serving user guide
• NVIDIA Dynamo: Tuning Disaggregated Performance
• AIPerf

共有リンク集

チーム内で共有された外部URLを保存するページです。 参考文献一覧とは分けて、共同編集資料、スライド、作業用ドキュメント、外部ノートなどを管理します。

運用方針

• 新しい外部URLを共有したら、このページに追加する。
• 何のためのリンクか、後から見て分かる説明を書く。
• 公式資料や技術的根拠として本文で引用するURLは、必要に応じて参考文献一覧にも追加する。
• Google Drive、Google Docs、Google Slidesなどの共有資料は、アクセス権限も確認する。

チーム作業資料

追加テンプレート

| 名称 | URL | 用途 | 追加日 | 備考 |
|---|---|---|---|---|
|  | <https://example.com> |  | YYYY-MM-DD |  |

mdBook の使い方

mdBook は Rust 製の静的サイトジェネレーターで、Markdown ファイルからドキュメントサイト（HTML）を生成します。このリポジトリで使っているツールです。

インストール

Rust がある場合（推奨）

cargo install mdbook

バイナリを直接取得する場合

GitHub Releases から OS に合ったバイナリをダウンロードして PATH の通ったディレクトリに置きます。

Windows（winget）

winget install -e --id Rust.Rust
cargo install mdbook

プロジェクト構造

book.toml       # プロジェクト設定
src/
  SUMMARY.md    # 目次（章の順序と構成を定義）
  chapter_1.md  # 記事ファイル
book/           # ビルド出力（自動生成・編集不要）

book.toml の主要設定

[book]
title = "APAC-HPC-AI"
authors = ["Typewriter"]
language = "ja"          # サイトの言語コード

[build]
build-dir = "book"       # 出力先ディレクトリ（デフォルト: book）

SUMMARY.md — 目次の書き方

src/SUMMARY.md が本全体の構成を決定します。ここに書いたリンクのみがサイドバーに表示されます。

# Summary

- [はじめに](./introduction.md)

# 第1部：ツールガイド
- [mdBook の使い方](./mdbook-usage.md)
- [GitHub Pages への公開](./github-pages.md)

# 第2部：OpenFOAM
- [OpenFOAM 入門](./openfoam/intro.md)
  - [メッシュ生成](./openfoam/meshing.md)   ← インデントでサブ章

ルール:

• リストアイテム - [タイトル](./ファイルパス) が章になる
• インデント（2スペース or タブ）でサブ章を作れる
• # 見出し はセクション区切り（リンクなし）
• SUMMARY.md に書かれていないファイルはサイトに含まれない

記事の書き方

src/ 以下に .md ファイルを作成します。通常の Markdown がそのまま使えます。

# 章タイトル

## セクション

本文テキスト。**太字**、*斜体*、`コード` が使えます。

コードブロック（シンタックスハイライト付き）:

​```bash
mpirun -np 4 openfoam
​```

数式（KaTeX）:

\\( E = mc^2 \\)    ← インライン数式

\\[
  \nabla \cdot \mathbf{u} = 0
\\]                  ← ブロック数式

ディレクトリで章をまとめる

src/
  openfoam/
    intro.md
    meshing.md

SUMMARY.md でのパス指定: ./openfoam/intro.md

ビルドとプレビュー

mdbook serve 実行中はファイルを保存するたびにブラウザが自動更新されます。

新しい章を追加する手順

1. src/ にファイルを作成する

# 例: OpenFOAM 入門記事
# （Windowsの場合）
New-Item src/openfoam-intro.md

2. src/SUMMARY.md にリンクを追加する

- [OpenFOAM 入門](./openfoam-intro.md)

3. mdbook serve で確認する

この 2 ステップを忘れると、ファイルを作ってもサイトに表示されないので注意。

カスタマイズ（book.toml）

[book]
title = "APAC-HPC-AI"
description = "APAC HPC-AI Competition 2026 チーム知識ベース"

[output.html]
theme = "navy"               # デフォルトテーマ: default, rust, coal, navy, ayu
git-repository-url = "https://github.com/<username>/APAC-HPC-AI"
edit-url-template = "https://github.com/<username>/APAC-HPC-AI/edit/main/{path}"

[output.html.search]
enable = true    # 全文検索（デフォルトで有効）

edit-url-template を設定すると各ページに「ページを編集」リンクが表示され、共同執筆がしやすくなります。

GitHub Pages への公開（GitHub Actions）

main ブランチに push するたびに mdBook を自動ビルドして https://<username>.github.io/<repo>/ に公開する仕組みを作ります。

全体の流れ

git push → GitHub Actions が起動
         → mdbook build を実行
         → book/ を GitHub Pages にデプロイ
         → https://<username>.github.io/<repo>/ が更新される

Step 1: GitHub Actions ワークフローを追加

リポジトリに .github/workflows/deploy.yml を作成します（このリポジトリには既に含まれています）。

name: Deploy mdBook to GitHub Pages

on:
  push:
    branches: [main]
  workflow_dispatch:        # 手動実行ボタンも有効にする

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: "pages"
  cancel-in-progress: false

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install mdBook
        env:
          MDBOOK_VERSION: "0.4.40"
        run: |
          curl -sSL "https://github.com/rust-lang/mdBook/releases/download/v${MDBOOK_VERSION}/mdbook-v${MDBOOK_VERSION}-x86_64-unknown-linux-gnu.tar.gz" \
            | tar -xz
          sudo mv mdbook /usr/local/bin/

      - name: Setup Pages
        uses: actions/configure-pages@v5

      - name: Build
        run: mdbook build

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./book

  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

Step 2: GitHub リポジトリの設定

ワークフローを push する前に、GitHub 側で Pages のソースを「GitHub Actions」に変更します。

1. リポジトリページを開く
2. Settings タブ → 左サイドバー Pages
3. Source を Deploy from a branch から GitHub Actions に変更して Save

![Pages設定の場所: Settings > Pages > Source > GitHub Actions]

この設定をしないとデプロイジョブが Error: HttpError: Not Found で失敗します。

Step 3: 初回デプロイ

# ワークフローファイルを push する
git add .github/workflows/deploy.yml
git commit -m "ci: add GitHub Pages deployment workflow"
git push origin main

push 後、リポジトリの Actions タブでジョブの進行状況を確認できます。緑のチェックマークが付けば成功です。

公開 URL: https://<username>.github.io/<repository-name>/

動作確認チェックリスト

• .github/workflows/deploy.yml が main ブランチに存在する
• Settings → Pages → Source が GitHub Actions になっている
• Actions タブで Deploy mdBook to GitHub Pages ジョブが成功している
• 公開 URL にアクセスしてサイトが表示される

トラブルシューティング

手動デプロイ（ローカルから）

CI を使わずに手動でデプロイしたい場合は gh-pages ブランチに push する方法もあります。

mdbook build
cd book
git init
git add .
git commit -m "deploy"
git push -f https://github.com/<username>/<repo>.git HEAD:gh-pages

ただし、ワークフローによる自動デプロイの方が手間がなくミスも少ないため、通常は CI を推奨します。