# LLM基盤ベンチマーク ## 定義 LLM基盤ベンチマークとは、ハードウェアアクセラレータ・インターコネクト帯域幅・ソフトウェアフレームワーク・並列化計画・通信ライブラリにまたがる複雑な構成空間に対して、「どの構成が最速か」という評価的主張を検証・比較するための手法・成果物の総称である。MLPerf・LLM-Perfのような従来型ベンチマークは、少数のend-to-end要約統計量(スカラー値)を公開する「スコアボード」として機能するのに対し、[[CCL-Bench]]([[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]])はこれを、実行トレース・ワークロードカード・起動スクリプトという再利用可能なエビデンスを一次成果物とする「トレースベースのベンチマーク」へ転換する提案を行った。アウトカム(どの構成が速いか)ではなく説明(explanation、なぜ速いか・どこがボトルネックか・別の構成/メトリクスでも結果は同じか)を可能にする記録の豊かさが、両者を分ける核心的な設計軸である。(Source: [[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]]) ## 横断的知見 - **「アウトカムのみ」対「説明可能なエビデンス」という設計軸の対立が、既存ベンチマークの3つの限界に共通する根本原因として整理された**: CCL-Benchは、既存ベンチマーク(MLPerf・LLM-Perf・各種ベンダーリーダーボード)の限界を(1) 評価メトリクスが実験時点で固定される、(2) 性能改善への示唆が乏しい、(3) チューニング労力が不可視、の3点に分解した上で、共通原因を「アウトカムのみを報告し説明を欠く」ことに帰着させた。これは、[[実行トレース]]研究(Chakra)が「協調設計のための標準交換フォーマット」としてトレースを位置づけるのに対し、CCL-Benchは同じトレースを「ベンチマークの一次成果物」として再定義する視点の転換である。(Source: [[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]]) - **実測トレースをシミュレータの入力に変換する「trace-driven what-if analysis」が、シミュレーションの経験的較正ギャップを埋める具体的経路として実演された**: 従来のハードウェア投資判断は主に解析モデルベースのシミュレータ(Astra-Sim・SimAI等)に依存し、実行挙動への接地(グラウンディング)を欠くという指摘がある。CCL-Benchは実測のKineto/XLAトレースを[[MLCommons Chakra]]の実行グラフ形式へ変換し[[Astra-Sim]]に投入することで、実測計算挙動を保持したままネットワークパラメータのみを変化させるwhat-if分析を実現し、utility指標(資源$r$を2倍にした場合のstep time改善率)によってGPU/TPUの帯域幅投資の期待効用を定量化した。(Source: [[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]]) - **通信削減とend-to-endレイテンシ改善は独立した軸である**: CCL-BenchによるNCCL vs. MSCCL++比較(Perlmutter A100、vLLM推論)では、通信比率は一貫してMSCCL++が有利(Qwen3-4B: 49.5%→46.5%、DeepSeek-MoE-16B: 53.7%→46.4%)だが、レイテンシへの効果はワークロード依存で、Llama-3.1-8Bでは通信削減にもかかわらずTPOTが36.6ms→38.4msへ悪化した。単一のend-to-end数値だけを報告する従来型ベンチマークでは、この「通信比率は改善したがレイテンシは悪化した」という現象そのものが不可視になる。(Source: [[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]]) - **フレームワーク固有のチューニング最適点は、公開ベンチマークの「勝敗」がチューニング労力の非対称性を隠しうることを定量的に裏付ける**: CCL-Bench自身が問題視した「チューニング労力の不可視性」を、LLMエージェントベースの構成探索ツールCCL-Searchで直接検証したところ、同一ハードウェア・同一ワークロードでもTorchTitanとMegatron-LMの最良発見構成は構成空間上の異なる点にあり(3.4倍のstep time差)、一方の最適構成を他方に転用すると自身の最適比で最大3倍遅くなった。これは、探索過程そのものをベンチマークエントリとして記録可能にする設計(CCL-Bench/CCL-Search)がなければ検出できない現象である。 - **GPU/TPUの帯域幅投資効用は、ハードウェアの基準帯域幅とワークロード規模の両方に依存し、単純な「帯域幅を増やせば速くなる」という直感を裏切る**: TPU ICI帯域幅の倍化は小〜中規模ワークロードでGPU scale-up帯域幅の倍化よりも著しく高いutilityを持つ(推論で最大100倍、訓練で最大22倍)が、これはTPUの低いベースライン帯域幅(100GBps ICI vs. 300GBps NVLink)と低い接続性(torus vs. fully-connected)に起因する構造的な帰結であり、大規模GPU訓練workloadではむしろscale-upドメインサイズの拡大が有効という逆の傾向を示す。単一の要約指標では、この「どの資源に投資すべきか」というアーキテクト向けの問いに答えられない。 ## 未解決の問い - トレースベースのエビデンス記録(CCL-Bench)と、既存の要約統計量ベンチマーク(MLPerf等)は、どこまで相互運用可能か。同一実験からトレースとMLPerf準拠の要約数値の両方を自動生成し、コミュニティの移行コストを下げる変換パイプラインは実現可能か。 - CCL-SearchのようなLLMエージェントベースの構成探索は、探索過程を記録することでチューニング労力の可視化・検証可能性を実現するが、探索そのものがLLMプロバイダやモデルバージョンに依存する場合、将来のモデル更新後にも同じ探索結果が再現される保証はどう担保すべきか。 - トレースに含まれる機密情報(クラスタトポロジ・演算子シーケンス・構成選択)と、ベンチマークの検証可能性(生トレースの公開)は本質的にトレードオフの関係にある。metric-only submissionは監査可能性を犠牲にする部分解に留まるが、トレース匿名化(演算子名秘匿・タイミング摂動)によってこの対立を解消する具体的な設計は未確立である。 - 単一マルチランクトレースが10GBに達し、500基超のアクセラレータでの実行では合計100GBに近づくというストレージスケーラビリティの制約下で、モデル・プラットフォーム・並列化の多様性を優先する投稿選定ポリシーと、メトリクスツールが必要とするフィールドを保持した圧縮/サンプリング形式は、どのように両立可能か。 - オンラインサービングのrequest-levelレイテンシや、量子化・投機的デコーディングのような精度に影響する最適化は、現行のトレースベースエビデンス設計(ワークロードカードのスキーマ)にどう拡張されるべきか。精度メトリクスを含めない現行設計は、性能と精度のトレードオフを評価する用途にどこまで耐えるか。 ## 関連 - ソース: [[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]] - エンティティ: [[CCL-Bench]] / [[CCL-Search]] / [[MLCommons Chakra]] / [[Astra-Sim]] / [[NCCL]] / [[MSCCL++]] / [[vLLM]] / [[SGLang]] / [[Megatron-LM]] / [[TorchTitan]] / [[MaxText]] / [[Cornell University]] - 概念: [[実行トレース]] / [[並列化戦略]] / [[集合通信]] / [[LLM分散学習]] ## 出典 - [[@2026__arXiv__CCL-Bench 1.0 - A Trace-Based Benchmark for LLM Infrastructure]](トレースベースのLLM基盤ベンチマークCCL-Bench 1.0の一次提案論文。エビデンススキーマ・メトリクスツールキット・trace-driven what-if分析・CCL-Searchによる自動構成最適化、3つの技術的主張)