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 環境構築の進捗と過去問学習方針

テンプレート

# 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年大会の現時点まとめ

公式に確認できたこと

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へ深掘りする。

注意点

• 富岳前提のツール構成です。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)

スケーリング分析

このページは、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管理を伴うメモリ集約と説明しています。

参考文献

• Qwen/Qwen3-235B-A22B model card
• Qwen3 blog
• SGLang Documentation
• SGLang PD Disaggregation
• 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がそのまま使われるかは未確定ですが、指標の考え方としては有用です。

最小の比較表

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

参考文献

• Dynamo benchmarks README
• NVIDIA Dynamo: Disaggregated Serving user guide
• 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する必要があります。

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 Speculative Decoding
• SGLang Pipeline Parallelism for Long Context
• SGLang v0.4 blog
• 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

用語辞書

大会・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
• 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 PD Disaggregation
• SGLang Speculative Decoding
• SGLang Pipeline Parallelism for Long Context
• SGLang v0.4 blog

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 を推奨します。