> [!abstract] 概要(arXiv abstractの日本語訳) > LLM基盤に関する評価的主張——「ワークロードXはハードウェアY・ソフトウェアZで最速である」——は、ハードウェアアクセラレータ・インターコネクト帯域幅・ソフトウェアフレームワーク・並列化計画・通信ライブラリにまたがる複雑な構成空間に依存する。現行のインフラ評価ベンチマークは、なぜある構成が別の構成より優れているかを説明しない、少数のend-to-end数値のみを公開する。我々はCCL-Benchを提示する。これは、あらゆるMLワークロードについて再利用可能なエビデンスを記録することで既存ベンチマークの限界に対処する、トレースベースのベンチマークである。CCL-Benchに寄稿される各データポイントは、実行トレース・YAMLワークロードカード・起動スクリプトをパッケージ化する。我々は、このエビデンスから細粒度の計算・メモリ・通信効率メトリクスを計算する、コミュニティ拡張可能なツールキットを開発した。CCL-Benchを用いて、要約統計量ベンチマークでは裏付けられない3つの主張を提示する。(i) より高い計算通信オーバーラップは訓練のstep timeの長期化と共起しうり、非効率な並列化選択を明らかにすることがある、(ii) TPUインターコネクト帯域幅を2倍にすると、小〜中規模ワークロードではGPUインターコネクト帯域幅を2倍にする場合よりもはるかに高いend-to-endのstep time改善が得られる、(iii) あるトレーニングフレームワーク上のベストチューニング済み構成は、同一ハードウェア上の同等にチューニングされた別フレームワークの構成より最大3倍遅く動作しうる。 ## 論文情報 - タイトル: CCL-Bench 1.0: A Trace-Based Benchmark for LLM Infrastructure - 著者: [[Eric Ding]](筆頭)・[[Byungsoo Oh]]・[[Bhaskar Kataria]]・[[Kaiwen Guo]]・[[Jelena Gvero]]・[[Abhishek Vijaya Kumar]]・[[Arjun Devraj]]・[[Lindsey Bowen]]・[[Atharv Sonwane]]・[[Emaad Manzoor]]・[[Rachee Singh]](いずれも[[Cornell University]]) - 媒体: arXiv preprint(Preprint表記、査読前) - 発表年: 2026年5月7日投稿 - arXiv ID: 2605.06544v1(cs.DC) - コード: https://github.com/cornell-sysphotonics/ccl-bench - ベンチマークプラットフォーム: https://cclbench.ai/ ## 概要 CCL-Benchは、LLM基盤(ハードウェア・ソフトウェア・並列化構成)の性能評価を、要約統計量ではなく実行トレース・ワークロードカード・起動スクリプトの3点セットを一次成果物として記録するトレースベースのベンチマークである。Cornell大学の授業プロジェクトを起源とし、100件超のワークロード・7種のモデルアーキテクチャ・7種のフレームワーク・3種のハードウェア環境を収集した。コミュニティ拡張可能なメトリクスツールキット、実測トレースをハードウェアシミュレータに接続するwhat-if分析パイプライン、LLMエージェントによる構成自動探索ツールCCL-Searchの3本柱で構成される。 ## 問題設定 入力は、評価対象のワークロード(モデルファミリー・フェーズ・バッチサイズ・シーケンス長)と、それを実行するインフラ(ハードウェアプラットフォーム+ソフトウェアスタック)の組である。出力は、単一のスカラー値ではなく、実行トレース(操作・カーネル・通信イベント・ランクごとのタイムスタンプ)・ワークロードカード(YAML形式のワークロード/アーキテクチャ/システム記述)・起動スクリプトからなる**再利用可能なエビデンス**であり、これに対して任意のタイミングで新しいメトリクスツールを事後適用できる。前提として、寄稿者はKineto(PyTorch Profiler)またはJAX Profiler/XProfでトレースを収集できる環境を持つこと、および最低5回の定常状態イテレーション(推論は128ステップ以上のdecode)を実行できることが要求される。 ## 提案手法 ### アーキテクチャ全体像 CCL-Benchは「エビデンス層」(ワークロードカード・起動スクリプト・トレースプール)と「分析層」(E2E/XPU/メモリ/通信の各メトリクス)の2層構造を持ち、分析結果はランキング・構成最適化(CCL-Search)・what-if分析という3つの下流タスクにつながる。 **Figure 1: CCL-Bench overview** ![[_attachments/arxiv-2605.06544/fig01-overview.png]] (Figure 1. 標準化されたトレース+ワークロードカードで各実行を記録し、メトリクスツールキットが細粒度メトリクスを計算、下流の分析・最適化プラグインへつなぐ全体像。左からRun Script/Workload card/Traceがエビデンス層(Evidence layer)としてCCL-Benchに入力され、Analysis layerがE2E/XPU/Memory MetricsとComm. Metricsを計算し、右側のRanking・Config optimization(CCL-Search)・What-if analysisへ出力する。Source: Figure 1.) ### 評価対象の構造(Workload / Software / Hardware Platform) CCL-Benchが評価するLLM基盤は、Workload(モデルファミリー・フェーズ・バッチサイズ・シーケンス長)、Software(コンパイラ・通信ライブラリ・フレームワーク)、Hardware Platform(アクセラレータ・メモリ・インターコネクト・トポロジ)の3層に分解される。SoftwareとHardware Platformを合わせたものを「Infrastructure」と呼び、CCL-Benchの評価対象そのものとなる。ワークロードは、Llama-3.1-8B・DeepSeek-V3-16B等のオープンウェイトモデルを対象とし、量子化・フェーズ(training/inference)・バッチサイズ・シーケンス長で規定される。ソフトウェアは、TorchInductor/Tritonのようなグラフキャプチャ・演算子融合・カーネル生成を担うコンパイラ層、NCCL/MSCCL++/XLA collectivesの通信ライブラリ層、TorchTitan/Megatron-LM/vLLM/SGLang/MaxTextのようなtraining/servingフレームワーク層(DP/TP/PP/EP次数・micro-batch size・pipeline schedule・ZeRO stage等で構成される)からなる。 **Figure 2: LLM infrastructure evaluated by CCL-Bench** ![[_attachments/arxiv-2605.06544/fig02-infrastructure-hierarchy.png]] (Figure 2. Workloadが「何を計算すべきか」を定義し、Infrastructure(Software+Hardware Platform)が「どう実行するか」を決める階層構造。Source: Figure 2.) ### エビデンススキーマ(トレース・ワークロードカード・起動スクリプト) CCL-Benchへの各投稿は3つの成果物からなる。(1) 操作・カーネル・通信イベント・タイムスタンプ・ランクごとの活動を記録する実行トレース(Kineto JSONまたはJAX/XProf JSON)、(2) モデルファミリー・バッチサイズ・シーケンス長・ステップ数といったワークロードと、ハードウェアアーキテクチャ・training/serving engine・並列化構成・collective libraryチューニング・コンパイラといったインフラ全体を名指しするYAMLワークロードカード、(3) 実験を起動したrunスクリプト。これらを合わせることで、読者は再実行なしに測定された性能を特定のインフラ要素へ帰属できる。 代表的なワークロードカードのフィールドを以下に示す。 **(Table 1. Workload-card fields, subset)** | Role | Template field | Example | |---|---|---| | Workload | workload.model.model_family | llama-3.1-8b | | Workload | workload.model.phase | training | | Workload | workload.data.batch_size | 4 | | Workload | workload.data.seq_len | 8192 | | Architecture | workload.hardware.xpu_spec.model | nvidia_a100 | | Architecture | workload.hardware.network_topo.topology | slingshot | | System | Model-executor.framework.name | torchtitan | | System | Model-executor.model_plan_parallelization | DP shard=2, TP=4, PP=2 | | System | Model-executor.communication_library.name | NCCL | | System | Model-executor.protocol_selection | rocev2, p2p | 完全なスキーマ(Appendix B, Table 2)は、Provenance(version・description・hf_url・trace_url・contributor)、Workload model(phase・moe・granularity・model_family・precision・epochs・iteration)、Model architecture(num_params・num_layers・num_heads・head_dim等)、Workload data(batch_size・seq_len・input_len・output_len・dataset)、Hardware network(topology・bandwidth_gbps)、Hardware XPU(type・model・total_count・count_per_node・driver_version)、Executor framework(name・compiler_tool_selection)、Parallelization(dp_replicate・dp_shard・tp・pp・cp・ep・pp_mb)、Communication(name・version・env・protocol_selection)、Metric source(traces・metrics_specific_trace)まで及ぶ。GPU(Kineto)とTPU(XLA)のトレースは同じChrome-trace JSONコンテナ形式を共有するが、タイムスタンプ単位(GPUはµsのts/dur、TPUはpsのdevice_offset_ps/device_duration_ps)・FLOPs報告(XLAはmodel_flopsを直接記録、GPUはワークロードカードのモデルアーキテクチャから推定)・ステップ境界(GPUはProfilerStep#N、TPUは$core.py:331 step)・collective命名・memory-transferイベント表現・ストリームモデルの6点で差異があり、クロスプラットフォーム比較には単位変換が必須である(Appendix A)。 ### コミュニティ拡張可能なメトリクスツールキット ツールiは、ワークロードカードとトレースからスカラーメトリクスへの関数 $f_i: W \times T \rightarrow \mathbb{R}$ として定義される。n個のツール群を同一エビデンスに適用すると性能プロファイル $m(w, \tau) = (f_1, \ldots, f_n) \in \mathbb{R}^n$ が得られ、単一のスカラーでは特徴づけられない計算効率・メモリスループット・通信オーバーヘッドを同時に捉える。ツールは`tools/<metric>/`配下の自己完結Pythonモジュールとして実装され、ワークロードカードの`metric_source.traces`フィールドを読んだディスパッチャ(`tools/main.py`)が適切なバックエンドを呼び出す。 **(Table 3. CCL-Bench 1.0 metric catalog、抜粋。Dir: ↑=高いほど良い、↓=低いほど良い。P=PyTorch/Kineto JSON(GPU)またはXLA profiler JSON(TPU)、Pgpu=GPU限定Kineto、N=Nsight Systems SQLite)** | カテゴリ | Metric key | Unit | Dir | Src | 説明 | |---|---|---|---|---|---| | Model execution | avg_step_time | s | ↓ | P | エンジン1イテレーションあたりの平均wall-clock時間 | | Model execution | mfu | % | ↑ | P | Model FLOPs Utilization | | Model execution | ttft | s | ↓ | P | Time to first token(推論限定) | | Model execution | tpot | s | ↓ | P | Time per output token(推論限定) | | Compute | mean_sm_coverage | % | ↑ | Pgpu, N | 全カーネルの平均SM occupancy(duration加重) | | Compute | dominant_kernel_concentration | % | ↓ | P, N | 最大単一カーネル/HLOカテゴリの時間比率 | | Compute | compute_bound_fraction | % | ↑ | P, N | compute-bound kernel(SM coverage>70%かつduration>10µs)の時間比率 | | Compute | memory_bound_fraction | % | ↓ | P, N | memory-bound kernel(SM coverage<50%)の時間比率 | | Compute | moe_fraction | % | ↓ | Pgpu, N | MoE固有カーネル(expert compute・routing・dispatch/combine)の時間比率 | | Memory | average_memory_bandwidth | GB/s | ↑ | P, N | メモリコピー操作中の持続帯域幅 | | Memory | memory_transfer_overhead | % | ↓ | P, N | 計算と並行しないDMA/memcpy区間の時間比率(§D.2) | | Communication | communication_fraction | % | ↓ | P, N | collective通信カーネルの時間比率 | | Communication | total_communication_time | s | ↓ | P, N | overlap区間を差し引いた平均通信時間 | | Communication | compute_comm_overlap | % | ↑ | P, N | 計算と並行実行される通信時間の比率(§D.3) | | Communication | load_imbalance_ratio | ratio | ↓ | P, N | ランク間のmax/min active time | | Communication | straggler | ratio | ↓ | Pgpu | NCCL collectiveごとのランク間straggler遅延比率 | | Communication | bw_allgather / bw_allreduce / bw_reducescatter / bw_alltoall | GB/s | ↑ | P | 各collectiveの中央値実効帯域幅(アルゴリズム係数補正済み) | | Communication | bw_peertopeer | % | ↑ | N | NVLink/PCIe TX利用率(pipeline parallelism) | | Utility | scale_up_bw_utility | % | ↑ | P | scale-up帯域幅2倍化によるstep time改善(Astra-simトレースリプレイ) | MFUは観測FLOPs/s ÷ (全XPUのピークFLOPs/s)で定義され、PyTorchバックエンドでは per-tokenのFLOP推定式(推論: $2(N_{act}-N_{emb})+4LHQS$、訓練: $6(N_{act}-N_{emb})+12LHQS$、$N_{act}$は有効パラメータ数・$N_{emb}$は埋め込みパラメータ数・$L$層数・$H$ヘッド次元・$Q$ヘッド数・$S$シーケンス長)から算出し、XLAバックエンドではトレース中の`model_flops`を直接積算する。memory transfer overheadは、メモリコピー区間の集合から計算区間の集合を差し引いた「計算と並行しない純粋なDMA時間」の比率として定義され(GPU: `union(M)\union(C)`、TPUはXLAが積極的にDMAをパイプライン化するため理想的には0%近傍)、compute-communication overlapは通信カーネル時間のうち計算カーネルと並行実行される割合として定義される(先頭・末尾ステップを除外して内側ステップ・ランクにわたって平均)。 ### エビデンス駆動の3つの活用シナリオ **(1) 事後的なメトリクス拡張**: 新しいメトリクスツールは、既存プール中の互換トレース全てに事後適用できる。本論文はこれを実演するため、通信トラフィック量メトリクスを新規開発し、EP=4とEP=8のDeepSeek-V3-16B訓練間の性能差を説明した(後述4.1節)。 **(2) トレース駆動のwhat-if分析**: CCL-Benchの実測トレースは、各ランクのカーネルタイミング・collective種別・グループID・バッファサイズを記録しており、これを[[MLCommons Chakra]]の実行グラフ形式(計算カーネル→COMP_NODE、collective→COMM_COLL_NODE、アイドル区間→gapノード)に変換し、[[Astra-Sim]]に投入することで、異なるインターコネクト帯域幅・トポロジ・collectiveアルゴリズムの仮定下でのイテレーション時間を推定できる。GPU(Kineto)とTPU(XLA)双方のトレースに対する変換パイプラインを構築している。 **Figure 4: CCL-Bench trace-driven what-if pipeline** ![[_attachments/arxiv-2605.06544/fig04-whatif-pipeline.png]] (Figure 4. ①target workload選択→②Chakra ET trace formatへ変換(`gen_gpu_chakra_et()`/`gen_tpu_chakra_et()`)→③Astra-Simでの性能シミュレーションとwhat-if分析→④utility metricsの計算、という4段パイプライン。実測トレースの計算ノードは元の実測durationのまま再生し、通信ノードのみを対象ネットワーク構成下で再シミュレートすることで、実測計算挙動を保持しつつネットワークパラメータだけを変化させる。Source: Figure 4.) このwhat-if分析のために、ハードウェア資源 $r$(scale-out帯域幅・scale-up帯域幅・scale-upドメインサイズ等)についてutility指標を次式で定義する。 $\text{Utility}(r) = \frac{T - T_{2\times}(r)}{T} \times 100\%$ ここで $T$ はベースラインstep time、$T_{2\times}(r)$ は資源 $r$ を2倍にした場合のシミュレートされたstep timeである。utilityが小さいほどそのワークロードは資源 $r$ の増強から得るものが少なく(計算バウンドまたは無感応)、大きいほどボトルネックであることを示す。 **(3) 自動化された構成最適化(CCL-Search)**: LLMエージェントベースの構成最適化ツールで、ワークロード・ターゲットインフラ・最適化目的(例: step time最小化、またはレイテンシとアクセラレータコストのバランス)を与えると、構成を反復提案・実機実行・トレース収集・目的関数評価というループを回し、次の提案を洗練させる。探索過程の全試行がCCL-Benchのベンチマークエントリとして記録されるため、チューニング労力そのものが検証可能・再現可能になる。 **Figure 6: CCL-Search loop** ![[_attachments/arxiv-2605.06544/fig06-cclsearch-loop.png]] (Figure 6. `update_policy`のみがLLM呼び出しであり、他のステップ(`execute()`・`compute_metrics()`・`update_history()`)はローカル/ツール実行である。CCL-Searchは`generate_config`というPythonポリシー関数を反復的に書き換える。各イテレーションは(1)`generate_config`が構成を提案、(2)対象ハードウェアで実行、(3)CCL-Benchがトレースを収集し`compute_metric`で目的スコアを計算、(4)`update_policy`がスコアと全実行履歴を渡してLLMを呼び出し次のラウンドの`generate_config`を改訂、の4段階からなる。Source: Figure 6.) CCL-Searchは[claude-opus-4-6](Anthropic Messages API)を用い、`generate_config`ポリシーをstructured tool-use呼び出しで毎イテレーション提出させる。システムプロンプトと全実行履歴(構成・スコア・エラー)は毎回ユーザーターンのコンテキストとして渡される。実験でのLLMポリシー合成時間は平均約33秒/イテレーションであった(Appendix I)。ポリシー設計指針として、TPはノード内に収める(`tp <= gpus_per_node`)、PPはレイヤー数を割り切る値かつバブルオーバーヘッドが`(PP-1)/num_microbatches`に比例、DPは低速インターコネクト上ではノードをまたぐと高コスト、EP(MoE限定)はエキスパート数・DPを割り切る値かつ低速インターコネクトではAllToAllが支配的コストになる、といった経験則がシステムプロンプトに明示的に埋め込まれている(全文はAppendix I)。 ### ユーザーインタフェース CCL-Benchのリーダーボードは、投稿を行、メトリクスを列とする2次元テーブルであり、ワークロード単位でエントリをクラスタリングして横断比較できる。 **Figure 8: CCL-Bench user interface** ![[_attachments/arxiv-2605.06544/fig08-ui-screenshot.png]] (Figure 8. Standard Workload Leaderboardのスクリーンショット。deepseek-v3-16bのEP=8/DP=2/TP=4とEP=4/DP=2/TP=4の2エントリを並べて比較したモーダル画面で、Configuration(TP/PP/DP/Shard(FSDP)/EP/Comm Library)とMetrics(Step Time・MFU・GPU効率・メモリ・Communication・What-if simulation)を同一画面に並置する。EP=8がStep Time 3.63s(MFU 8.83%)、EP=4が12.49s(MFU 2.57%)であることが直接読み取れる——これはFigure 3(b)の数値と対応する。Source: Figure 8 / Appendix E.) ## 新規性 既存のLLMインフラベンチマーク(MLPerf・LLM-Perf・各種ベンダーリーダーボード)は3つの根本的限界を持つ。第一に、評価メトリクスが実験時点で固定される——通信内訳・計算利用率・straggler深刻度・メモリ転送オーバーヘッドのような新しい評価軸を後から知りたければ、全く別の実験をやり直す必要がある。第二に、性能改善への示唆が乏しい——既存ソフトウェア/ハードウェアスタックの性能比較はできても、性能ギャップを埋めるためにどこを改善すべきかの手掛かりが乏しい。第三に、チューニング労力が不可視である——公開リーダーボードの「勝利」は、丁寧にチューニングされたエンジン対そうでないベースラインの比較を反映していることが多く、両者を平等にチューニングし直すと順位が変わりうる。 CCL-Benchはこれらを「アウトカムのみを報告し説明(explanation)を欠く」という共通原因に帰着させ、実行を再現可能にするだけの十分に豊かなエビデンス記録によって対処する。関連する[[実行トレース]]研究のうち、Holistic Trace Analysis(HTA)はKinetoトレース上でカーネル内訳・通信計算オーバーラップ・トレース差分を計算する先行研究だが、CCL-Benchはこれを標準化されたワークロード・比較軸・共有トレースプールを持つベンチマーキングフレームワークへ拡張する点で異なる。また、Chakra(実行トレースの標準表現)を「協調設計のための交換フォーマット」として提案する研究に対し、CCL-Benchは実測トレースをChakra ETへ変換してシミュレータに接続する「実測から出発するwhat-if分析」の具体的な適用例を提供する。シミュレータ研究(Astra-Sim・SimAI等)は物理ハードウェア上で全構成を実行せずに設計空間探索を可能にするが、経験的較正に依存しており、CCL-Benchのようなトレースベースのエビデンスがその較正源になりうる。 ## 実験設定 - **ハードウェア環境**: (1) NERSC [[Perlmutter]]スーパーコンピュータ。各ノードに4基のA100 GPUをNVLink 3.0(300GB/s単方向、scale-upドメイン)で接続し、ノード間はSlingshot-11ファブリック(200Gbps、scale-outドメイン)で接続。(2) Google TPU v6e。8チップでノードを構成し32ノードでpodを構成する2Dトーラストポロジ(scale-upドメイン)、チップ間interconnect(ICI)帯域幅100GB/s単方向。 - **ソフトウェアスタック**: 通信ライブラリはNCCL・MSCCL++・XLA collectives、training/serving engineはMegatron-LM・TorchTitan・MaxText・vLLM・SGLang。 - **ワークロードスイート**(Appendix F, Table 4): **(Table 4. Selected workload suite for CCL-Bench 1.0)** | ID | Model | Phase | Batch | Sequence/input length | |---|---|---|---|---| | WL1 | Qwen3-4B | Inference | 128 | 1024 input | | WL2 | Llama-3.1-8B | Inference | 128 | 1024 input | | WL3 | DeepSeek-MoE-16B | Inference | 128 | 1024 input | | WL4 | Llama-3.1-8B | Training | 4 | 512 sequence | | WL5 | DeepSeek-V3-16B | Training | 8 | 1024 sequence | | WL6 | DeepSeek-V3-16B | Training | 64 | 2048 sequence | | WL7 | DeepSeek-V3-236B | Training | 64 | 1024 sequence | - **トレース収集の overhead**: Intel Xeon Gold 6438M2 CPU + NVIDIA L40 GPU 2基で1.88Bパラメータのテストモデルをテンソル並列訓練し、JSONトレース収集オーバーヘッドを測定したところ、6ステップ平均で0.22%(変動係数2.67%)と低かった(Appendix A)。 ## 実験結果 ### 4.1 フレームワーク/ライブラリ開発者の視点(Claim 1) フレームワーク開発者は通常MFUとcompute-communication overlapの2指標を、固定ワークロード・ハードウェア構成下でのstep time短縮の代理指標として最適化する。CCL-Benchのトレースプールでこの仮定を検証したところ、MFUに関する仮定は支持された(MFUが高いほどstep timeが低い)一方、overlapに関する仮定は支持されなかった。 **Figure 3: MFU/overlap vs. step time、および EP=4/EP=8のstep-time・通信量内訳** ![[_attachments/arxiv-2605.06544/fig03-mfu-overlap-steptime.png]] (Figure 3. (a左) A100 GPU(Perlmutter)上でのMFU vs. step time——各点は1つのCCL-Benchエントリで、MFUが高いほどstep timeが低い傾向を裏付ける。(a右) compute-comm overlap vs. step timeでは逆に、DeepSeek-V3-16B MoE訓練(WL5)においてoverlapが高いほどstep timeが悪化するという反直観的な結果を示す。(b) WL5のEP=4/EP=8構成(TP=4, DP=2, PP=1)についてstep time内訳(compute/overlapped comm/exposed comm/idle)とcollective別トラフィック量内訳(AllReduce/AllGather/ReduceScatter/AllToAll)を比較。EP=8はstep time 3.67s・トラフィック7.9GBに対し、EP=4は11.98s・29.1GBであり、より小さいEP次数(GPU数に対する相対値)がより高いoverlapを持ちながらより長いstep timeとなる。Source: Figure 3.) 原因分析のため、著者らは(1)step timeを計算/exposed通信/overlapped通信へ帰属するツール、(2)各ステップのcollective別トラフィック量を捕捉するツールを新規開発し、既存トレースに再実行なしで適用した。高いoverlapを示した実験は総GPU数に対して小さいexpert parallelism(EP)次数を使用していた(例: 8GPUでEP=4)一方、低overlapの実験はより大きいEP次数(EP=8)を使用していた。compute-comm内訳(Figure 3(b))は両構成とも通信がstep timeを支配することを示すが、トラフィック量内訳は小さいEPドメインの構成がReduceScatterとAllGatherのトラフィックを著しく多く生成することを示す。これは、小さいEPドメインがデータ並列ドメインをまたいでエキスパートを複製するため、fully-sharded data parallelismによる重みの収集・勾配同期が必要になるからであり、これらのcollectiveは部分的にオーバーラップ可能だが、追加の通信量がオーバーラップの利益を上回りstep timeを増加させる。 > [!claim] Claim 1 > compute-communication overlapの増加は必ずしも訓練のstep time短縮を意味しない。それはむしろ、非効率な並列化選択(expert/data parallelismの協調最適化不足)を明らかにすることがある。 ### 4.2 ハードウェアベンダーの視点(Claim 2) ハードウェア設計者がインターコネクト増強への投資判断をする際、trace-driven what-if simulation(Figure 4のパイプライン)を用いてUtility(r)を算出した。 **Figure 5: GPU/TPU帯域幅・scale-upドメインサイズのutility比較** ![[_attachments/arxiv-2605.06544/fig05-bandwidth-utility.png]] (Figure 5. Perlmutter A100(GPU、scale-out帯域幅・scale-up帯域幅・scale-upドメインサイズの3軸)とTPUv6e(TPU、ICI帯域幅)についてutilityを比較。GPUクラスタでは最適な増強先がワークロード依存: scale-out帯域幅の倍化は通信ヘビーな複数ノード訓練で有効(最大28.7%)だが単一ノード推論では効かない。scale-upドメインサイズの倍化はWL4(53.9%)・WL5(46.7%)で最大の効用を示す。大規模訓練(WL6: 128GPU、WL7: 256GPU)は計算バウンドのためutilityが低い(3.9%・3.4%)。TPUはICI帯域幅の倍化から一貫して高いutilityを得る(推論で最大GPU scale-up帯域幅utilityの102.57倍、訓練で22.82倍)——これはTPUの低いベースライン帯域幅(100GBps ICI vs. 300GBps NVLink)と低い接続性(torus vs. fully-connected)に起因する。Source: Figure 5.) さらに大規模ワークロードでの検証として、256GPU上のDeepSeek-V3-236B(WL7)のトレースを最大構成として、scale-upドメインサイズ・scale-up帯域幅・scale-out帯域幅を同時に変化させるクラスタアーキテクチャスイープを行った。 **Figure 13: WL7に対するクラスタアーキテクチャスイープ(what-if simulation)** ![[_attachments/arxiv-2605.06544/fig13-cluster-arch-sweep.png]] (Figure 13. Baseline(SU=4基, SU BW 300GB/s, SO BW 200Gbps, hidden 53%)からBalanced(SU=32, 1800GB/s, 400Gbps, hidden 79%)・Aggressive(SU=128, 3600GB/s, 800Gbps, hidden 81%)へネットワーク資源を増強しても、overlapされる通信の割合(hidden)の増加は逓減する。step timeの改善もBaseline 12.17s→Balanced 10.63s(-1541ms)→Aggressive 10.58s(-1596ms)とほぼ頭打ちになり、追加のネットワーク資源投入だけでは限界があることを示す。Source: Figure 13 / Appendix H。) > [!claim] Claim 2 > TPU ICI帯域幅の倍化は、小規模ワークロードにおいてGPU scale-up帯域幅の倍化よりも高いend-to-end utilityをもたらす(推論で最大100倍、訓練で最大22倍)。中〜大規模GPU訓練ワークロードでは、帯域幅改善よりscale-upドメインサイズの拡大の方が有効な投資先である。 ### 4.3 プロダクション運用者の視点(Claim 3) 運用者が分散LLM訓練ジョブをデプロイする際の並列化次数・micro-batch size・activation checkpointing等の選択は、大規模で相互依存的かつフレームワーク固有の構成空間となる。著者らはCCL-Searchを用いてLlama-3.1-8B(WL4、16 Perlmutter GPU)上でTorchTitanとMegatron-LMをそれぞれ15イテレーション・5ノブ(TP・DP・PP・micro-batch size・activation checkpointing)にわたって探索した。 **Figure 7: CCL-Search探索結果** ![[_attachments/arxiv-2605.06544/fig07-cclsearch-results.png]] (Figure 7. (a) step-time目的(Score=-avg_step_time)でのTorchTitan/Megatron-LM探索。TorchTitanはTP=1, DP=4, PP=4でstep time 1.50s、Megatron-LMはTP=4, DP=1, PP=4で0.44sに到達し、両者の最適点は構成空間上の異なる位置にある(3.4倍差)。TorchTitanの最適構成をMegatron-LMに適用すると1.3s(TorchTitan比15%高速だがMegatron-LM自身の最適比では3倍遅い)。15イテレーション以内でstep timeをTorchTitanで最大8倍・Megatron-LMで最大19倍削減。(b) 複合目的(Score = w×T0/T + (1-w)×N0/N、w=0.5)でのMegatron-LM探索。step time(T)とXPU数(N)のトレードオフを表すPareto最適構成群(iter 0→iter 3→iter 7/8)を発見する。下段パネルはTP/DP/PP/micro-batch size/activation checkpointingの探索履歴で、グレーアウトは失敗した実行を示す。Source: Figure 7.) 複合目的の探索はDeepSeek-V3-16B(WL5)でも実施され、異なるシード方策からの再現性を検証した(Appendix I)。 **Figure 14 / Figure 15: 複合目的探索(WL4 / WL5)** ![[_attachments/arxiv-2605.06544/fig14-cclsearch-composite-wl4.png]] (Figure 14. WL4 Llama-3.1-8B(Perlmutter)、w=0.5。Megatron-LMでiter 0(16GPU)からiter 11(4GPU)へ、step timeを犠牲にしすぎずXPU数を削減するPareto探索が進む様子。Source: Figure 14 / Appendix I.) ![[_attachments/arxiv-2605.06544/fig15-cclsearch-composite-wl5.png]] (Figure 15. WL5 DeepSeek-V3-16B(Perlmutter)、Figure 7(b)とは異なるシード方策(TP=4, DP=1, PP=3, EP=1, micro-batch=4, activation checkpointingなし)からの探索。最終方策はmicro-batch sizeのみがFigure 7(b)の結果と異なり、探索の収束が方策初期化に対して頑健であることを示唆する。Source: Figure 15 / Appendix I.) > [!claim] Claim 3 > 同一ワークロードを異なるtraining engineへデプロイするにはフレームワーク固有のチューニングが必要である。あるフレームワークで最適な構成は、別フレームワークでの最良発見構成より最大3倍遅くなりうる。 ### 横断比較(cross-system / cross-architecture、Appendix G) Perlmutter A100上でNCCLとMSCCL++を、TP/EP次数・アクセラレータ数を固定して比較したところ、通信比率は一貫してMSCCL++が有利(Qwen3-4B: 49.5%→46.5%、DeepSeek-MoE-16B: 53.7%→46.4%)だが、レイテンシへの効果はワークロード依存であった(WL1・WL3は改善、WL2 Llama-3.1-8Bは36.6ms→38.4msへ悪化)。 **Figure 9: NCCL vs. MSCCL++** ![[_attachments/arxiv-2605.06544/fig09-nccl-vs-mscclpp.png]] (Figure 9. ワークロード・ハードウェア・フレームワーク・TP/EP次数・アクセラレータ数を固定し通信スタックのみを変えたペア比較。Source: Figure 9.) vLLMとSGLangを通信バックエンド・並列化・その他構成を固定して比較すると、密モデル推論(WL1/WL2)ではvLLMがより高いMFUを達成し高速(Qwen3-4B: 17.1% vs. 8.6%、Llama-3.1-8B: 28.4% vs. 15.5%、通信比率はほぼ同等)、MoE推論(WL3)ではAllToAllの実装効率差からSGLangが優位(通信比率53.7%→38.8%、76.1ms vs. 81.2ms)であった。 **Figure 10: vLLM vs. SGLang** ![[_attachments/arxiv-2605.06544/fig10-vllm-vs-sglang.png]] (Figure 10. 通信スタック・並列化・アクセラレータ数を固定しフレームワークのみを変えたペア比較。TTFT/TPOT/Communicationの3指標を並置。Source: Figure 10.) TPU v6e単独でのtensor-parallelスイープでは、Llama-3.1-8B推論(batch-128/input-1024)でTP1→TP4への移行がstep timeを222ms→85msへ短縮する一方、通信比率はほぼ0%→19.3%へ増加し、TP8ではさらに26.9%に増加しつつstep timeは98msへ悪化する(過剰並列化による回帰)。 **Figure 11: TPU v6e tensor-parallelスイープ** ![[_attachments/arxiv-2605.06544/fig11-tpu-tp-sweep.png]] (Figure 11. Llama-3.1-8B batch-128/input-1024推論でのTP1/2/4/8スイープ。Source: Figure 11.) WL1〜WL5にわたるA100 GPU(Perlmutter)とTPU v6e(Torus)の全体比較では、TPU v6eが全ワークロードでより高いMFUを達成(WL1: 2.1倍・WL2: 1.5倍・WL3: 4.3倍・WL4: 10.4倍・WL5: 1.6倍)し、訓練(WL4/WL5)ではGPU側の通信オーバーヘッドがMFUを抑制する。step timeはTPUが推論WL1/WL2で2.0倍低速だがWL3では逆にGPUより長い(1.09s vs. 0.12s、高MFUにもかかわらず)。通信比率は全ワークロードでGPUがTPUを上回る(WL5では93.1% vs. 2.0%)。 **Figure 12: GPU vs. TPU 総合比較** ![[_attachments/arxiv-2605.06544/fig12-gpu-vs-tpu-overview.png]] (Figure 12. WL1〜WL5にわたるstep time・MFU・CPU-chipメモリ帯域幅・通信比率の4パネル比較。各バーはそのワークロードタスク・ハードウェアプラットフォームに属する全CCL-Benchエントリの平均。Source: Figure 12.) ## 考察 CCL-Bench 1.0は、GPU/TPU上の小〜中規模オープンソースモデルの訓練・バッチ推論をカバーする。今後のバージョンではより大規模なモデル、追加アクセラレータ(Trainium等)、request-level latencyを伴うオンラインサービング、精度に影響する最適化(量子化・sparsity・投機的デコーディング)への拡張が計画されている。ワークロード×インフラの直積を網羅することは構造的に不可能であるため、CCL-Benchはワークロード/インフラ非依存のトレースプロトコルの上に、通信バックエンド・インターコネクトファブリック・MoE collectiveといったテーマ駆動のローリング投稿モデルを採用する。同一のトレース成果物が事後的なメトリクス拡張と下流のシミュレーションベースwhat-if分析の両方を支えており、既存の性能モデルへの接続が自然な次のステップとされる。トレースストレージのスケーラビリティも課題であり、単一のマルチランクトレースは10GBに達し、500基超のアクセラレータでの実行では合計100GBに近づく。モデル・プラットフォーム・並列化の多様性を優先する投稿選定ポリシーと、メトリクスツールが必要とするフィールドを保持した圧縮/サンプリング形式が今後必要になる(Appendix J)。 Broader Impacts(Appendix J)では、トレースが機密情報(クラスタトポロジ・演算子シーケンス・構成選択)を含みうることを指摘し、生のトレースを公開できない寄稿者向けにメトリクスのみの投稿(ローカルでツールキットを実行し計算済みメトリクス値のみ提出)を部分的な緩和策として提供するが、これはトレースが提供する監査可能性の保証を犠牲にすると述べる。トレース匿名化(演算子名の秘匿・タイミング摂動)の明確な規範とツールの確立は未解決の課題として残されている。 ## 強み / 弱点・課題 - **強み**: (1) スカラー要約ではなくエビデンス(トレース+ワークロードカード+起動スクリプト)を一次成果物とすることで、事後的なメトリクス拡張・トレース駆動what-if・チューニング過程の検証可能性という3つの新しい活用シナリオを一度に開拓している。(2) [[MLCommons Chakra]]・[[Astra-Sim]]という既存の実行トレース標準/シミュレータ資産を「実測トレースの適用先」として直接活用し、理論と実測の橋渡しを具体的なパイプラインとして示した。(3) 3つの主張(overlapの反直観性、GPU/TPU帯域幅utilityの非対称性、フレームワーク間チューニング非移植性)はいずれも従来のend-to-end数値だけのベンチマークでは発見できないことを明示的に実演しており、トレースベースアプローチの価値を具体的な発見で裏付けている。 - **弱点・課題**: (1) 論文自身が認める通り、カバレッジは小〜中規模モデル・GPU/TPUの訓練/バッチ推論に限定され、オンラインサービングのrequest-levelレイテンシや量子化・投機的デコーディングのような精度に影響する最適化は未対応。(2) トレースストレージのスケーラビリティ(単一マルチランクトレースが10GBに達する)は投稿の実務的障壁になりうる。(3) トレースに含まれうる機密情報(クラスタトポロジ等)とオープンな検証可能性の間のトレードオフは、metric-only submissionという部分解のみが提示されており、匿名化技術は未解決課題として残る。(4) CCL-Searchのポリシー合成にclaude-opus-4-6を用いる設計は、LLMプロバイダやモデルバージョンへの依存を導入しており、探索結果の長期的な再現性(同一プロンプトでも将来のモデル更新で挙動が変わりうる)について論文内での議論は見当たらない。