Think Before You Grid-Search: Floor-First Triage for LLM Serving

技術要約：LLMサービングにおけるFloor-First（フロア優先）トリアージ

問題提起
大規模言語モデル（LLM）のサービングを最適化するプロダクションチームは、並列化レイアウト（TP, EP, DP）、バッチング、量子化、およびカーネルレベルの作業を含む膨大な構成空間に直面している。レイテンシ目標を達成できなかった際の一般的な運用上の対応は、多数の構成をベンチマークし、Nsight Systemsなどの重いプロファイラを無差別に投入することである。このアプローチは、非効率的なグリッドサーチへと退行しがちであり、測定されたパフォーマンス数値は曖昧なものとなる。例えば、遅いTime Per Output Token (TPOT) は、根本的な帯域幅の制限、実装のギャップ、露出した通信、ホストのオーバーヘッド、あるいは性能の低いカーネルのいずれかに起因する可能性がある。本論文は、エンジニアリング・コミュニティにおいて、いつプロファイリングを行うべきか、そしてどこを最初に探すべきかを判断するための体系的な決定手順が欠如しており、その結果、明示的なリソース計算ではなく「伝承（folklore）」に基づいた予測不能なデプロイメントの選択（例：同一ハードウェア上でのDeepSeekモデルに対する相反する並列化戦略の採用）が行われていると主張している。

手法：Floor First（フロア・ファースト）
本論文は、分析的推定を主要なプロファイリング層として扱う、残差駆動型のトリアージ・ワークフローである「Floor First」を提案する。この手法は、以下の4つの明確なステージで構成される。

1. 分析的フロアの構築（Analytical Floor Construction）
   ベンチマークを行う前に、システムは与えられた構成に対して「二面的なフロア（two-sided floor）」を計算する。このモデルは、各デコードステップを5次元のリソースベクトル（HBMバイト数、FLOPs、ネットワークバイト数、ネットワークメッセージ数、およびKV容量）として扱う。

   • 楽観的フロア ($t_{opt}$): 各リソースの独立した実行時間の最大値 ($max(t_{HBM}, t_{compute}, t_{network})$) として計算され、完全なオーバーラップを想定している。
   • 悲観的フロア ($t_{sum}$): すべてのリソース実行時間の合計 ($t_{HBM} + t_{compute} + t_{network}$) として計算され、オーバーラップがないことを想定している。
   • 診断インターバル: 測定されたベンチマークが $[t_{opt}, t_{sum}]$ の区間のどこに位置するかによって、システム・オーバーラップのゼロコスト診断が可能となる。測定値が $t_{opt}$ に近い場合はオーバーラップが良好であることを示し、$t_{sum}$ に近い場合はスケジューリングやオーバーラップがボトルネックであることを示し、$t_{sum}$ を超える場合は未モデルのコスト（ホストのギャップ、ストラグラー）に時間が漏れていることを示す。

2. ベンチマークの規律（Benchmark Discipline）
   ベンチマークは厳格なルールに基づいて実施されなければならない：自己スロットリングによるバイアスを避けるためのオープンループ負荷生成、現実的な長さ分布、定常状態での動作、およびテールパーセンタイル（P99）の報告。

3. 照合とトリアージ（Reconciliation and Triage）
   測定された時間はフロアと比較される。

   • 小さな残差 (< 1.3× フロア): 調査を終了する。システムはその軸における理論的限界に達しているため、さらなる最適化にはカーネルのチューニングではなく、アーキテクチャの変更（例：スパース・アテンション、量子化）が必要である。
   • 大きな残差: プロファイリングをエスカレーションする。Nsight Systemsは、以下の3つの特定の問いに答えるためにのみ使用される：カーネル間にギャップはあるか？ 通信が露出しているか？ どのカーネルクラスが分析予算を超えているか？ Nsight Computeは、他の原因が排除された後に、その予算を超えたカーネルクラスに対してのみ厳格に使用される。

4. ウォール・オーダリング（Wall Ordering）
   デプロイメントの評価は、単一バッチのレイテンシではなく、「ウォール・オーダリング」によって行われる。すなわち、負荷が増加するにつれて、どのリソース制約（KV容量、KV帯域幅、ウェイト帯域幅、または計算量）が最初に「壁（wall）」となるかを決定する。容量は事後的なメモリチェックではなく、第一級のリソース次元として扱われる。

主な貢献

1. 残差駆動型トリアージ・ワークフロー: ターゲット定義、フロア構築、およびプロファイラ・エスカレーションを分離し、最適化の努力をパイプライン作業（レイアウト/スケジューリング）とカーネル作業のどちらに配分するかを決定する明示的な停止ルールを備えた決定ループ。
2. 二面的なフロア・モデル: プロファイラを実行することなく、オーバーラップ効率を診断するための、楽観的および悲観的な境界を提供する分析モデル。
3. 出力としてのウォール・オーダリング: コンカレンシーが増加するにつれてどのリソースの壁が最初に結合するか（binds first）に基づいてデプロイメントの代替案を比較する手法。これにより、単一バッチのレイテンシが劣るレイアウトであっても、より高い容量の壁を持つことで、グッドスルー（goodput）の最前線を支配できることが明らかになる。
4. メトリクス規律: 「リッジ恒等式（ridge identity）」($MFU/MBU = I_{work}/I_{ridge}$) に基づく利用率メトリクスの体系化を行い、結合しているリソースに対して正しいメトリクスが報告されるようにする。
5. アーティファクトとエージェントのスキル: エージェントによる最適化ループにおいて、エージェントが反射的にプロファイラに頼ることを防ぐための、依存関係のないPythonアーティファクト (floor.py) と、エージェントが読み取り可能なスキル (SKILL.md)。

ケーススタディの結果
本論文では、この手法を16枚のNVIDIA H20 GPU上で動作するDeepSeek-V3.2スタイルの671B MoEモデルに適用している。

• ハードウェア特性: H20 GPUは、約74 FLOP/byteのリッジポイントを持つことが特定された（H100の約590に対し）。これは、メモリ帯域に縛られる領域が8倍に広い、極めて「デコード指向」のパーツであることを意味する。
• レイアウトの判断:
  • TP16: バッチサイズ64、コンテキスト8Kにおいて、TP16はKV容量により約70の同時リクエストに制限される。KV帯域幅の項が顕著であり、実現可能な領域内で計算の壁に到達することはない。
  • EP16 + DP Attention: このレイアウトは、ウェイト・トラフィックをわずかに悪化させる代わりに、約644リクエストという、桁違いに高い容量の壁を実現する。TP16は単一ストリームのレイテンシでは優れている（B=1で2.4倍高速）が、高コンカレンシーのグッドスルーにおいてはEP16+DPが優位となる。
  • スパース・アテンション (DSA): KV帯域幅の壁を取り除くが、KV容量の壁は取り除かない。なぜなら、フルKVは依然としてアドレス指定可能である必要があるためである。
• 不一致の解決: 本研究は、なぜ異なるチームが同じハードウェア上で相反するレイアウト（TP vs DP）を採用したのかを説明している。最適な選択は、動作点（コンカレンシー）の関数として計算可能である。高コンカレンシーはDPを支持し、低コンカレンシーはTPを支持する。

意義と主張
本論文は、LLMサービングにおけるプロダクションでの意見の相違は、広範な実験を必要とするのではなく、小さなリソース計算（GPUあたりの5つの数値とモデルの次元）から予測可能であると主張している。この計算を体系化することで、本ワークフローは以下の提供を行う。

• 測定値が分析的フロアに近い場合に、無駄なプロファイリング作業を防ぐ。
• 高価なツールを使用する前に、正しい最適化軸（パイプラインかカーネルか）を特定する。
• ポイント・ベンチマークではなく、「ウォール・オーダリング」を通じてデプロイメントの選択を説明する。
• 標準的なヒューリスティックが機能しない、極端な特性を持つハードウェア（H20など）に対する堅牢な手法を提供する。

著者らは、現在のドラフトが分析的フロアと較正された定数に依存していることを謙虚に認め、残差の閾値とエスカレーション・ルールを経験的に検証するために、計画された測定キャンペーン（セクション8）が必要であると述べている。本手法は、エンジラーリングのための決定手順として提示されており、フロア・チェックを通過した残差に対しては、依然として不可欠であるシミュレータやプロファイラの代替物ではない。