> [!abstract] 概要(arXiv abstract の日本語訳) > Meta の大規模言語モデル(LLM)——Llama モデルファミリー——は月間アクティブユーザー約10億人にサービスを提供している。これらのモデルの推論展開には、多様なハードウェア選択肢(例: H100、H200、MI300X)、複数の並列化戦略(テンソル・パイプライン・エキスパート・コンテキスト・データ並列)、繊細なランタイム選択(例: 継続的バッチング対プレフィル-デコード分離)にまたがる複雑な設計空間を、ワークロード固有の特性を活かしながら厳格なサービスレベル目標(SLO)を満たしつつ航行する必要がある。本論文は、数百万件の展開構成を分析し、レイテンシ SLO を満たしつつスループットを最大化する構成を特定するための、体系的アプローチの開発と適用から得た知見を提示する。ランタイム設計間のトレードオフ、並列化戦略のフェーズ固有の性質、異種ハードウェアを活用する機会、プラットフォームのスケーリング挙動、Mixture-of-Experts(MoE)のようなモデルアーキテクチャのシステムレベルの含意を含め、大規模で Llama 推論を運用してきた経験から得た教訓を共有する。我々の本番環境での経験が、より広範な LLM 推論コミュニティに実践的な洞察を提供することを望む。 ## 論文情報 - タイトル: Optimizing Deployment Configurations for LLM Inference: Challenges and Insights - 著者: Meta Inference Team(責任著者 Sungmin Cho・Jaewon Lee、全著者は付録に約60名を列挙) - 所属: Meta Platforms, Inc. - 媒体・発表年: The 9th MLSys Conference(Industry Track)、Bellevue, WA, USA, 2026 - 発表スライド: MLSys 2026 発表資料(Sung Min Cho / Meta、`https://mlsys.org/media/mlsys-2026/Slides/3780.pdf`) - コード: 非公開(社内シミュレータ、論文中に公開リポジトリの言及なし) ## 概要 本論文は、Meta が Llama モデルファミリーを月間アクティブユーザー約10億人規模で本番運用する中で得た、LLM 推論デプロイメント最適化の知見をまとめた実務報告である。ハードウェア・並列化・ランタイムの組み合わせが数百万規模に達する設計空間に対し、軽量な性能シミュレータによる体系的探索手法を開発し、その適用から得られた5つの知見(ランタイム設計のトレードオフ、フェーズ別並列化、異種ハードウェア活用、MoE のシステム的含意、スケールアウト対スケールアップのプラットフォーム選択)を報告する。 ## 問題設定 **発表スライド: 推薦モデルとの推論コスト比較** ![[_attachments/87_Optimizing_Deployment_Confi/slide-inference-cost-comparison.png]] (Llama3 70B(2Kプロンプト・150出力・バッチサイズ64)の1クエリあたり FLOPs は推薦モデル(4K アイテムのランキング)の3,000倍超、メモリトラフィックは25倍超、システム時間は30倍超と試算される。論文 Table 1 に対応する数値をスライドが可視化したもので、Meta が月間アクティブユーザー約10億人規模で運用する上で小さな展開非効率が莫大なコストに直結する背景を示す。Source: MLSys 2026 発表スライド p.2。) - **入力**: LLM モデル M(計算グラフ)、リクエスト分布 D(入力/出力長・最大コンテキスト長・セッション挙動)、ハードウェア構成 H(アクセラレータ・プラットフォーム・ネットワーク)、並列化選択 P(PP・TP・CP・EP・DP)、ランタイム構成 R(継続的バッチング/分離・最大バッチサイズ・KV キャッシュポリシー)、レイテンシ SLO L(TTFT・TTIT)。 - **出力**: レイテンシ SLO を満たしつつ正規化スループット QPS_cluster(例: 256 アクセラレータあたり)を最大化する (M, D, H, P, R) の組み合わせ。定式化は次のとおり: max_{M,D,H,P,R} QPS_cluster(M, D, H, P, R) subject to TTFT(M, D, H, P, R) ≤ L_TTFT TTIT(M, D, H, P, R) ≤ L_TTIT - **前提となる困難**: (1) ワークロード多様性——テキストエージェント・マルチモーダルエージェント・リアルタイムエージェント・safety/query 生成・データ拡張・データスコアリングの各サービスで入力長 50〜32K+ トークン、出力長 100〜1K+ トークン、TTFT 200ms 未満〜数秒、モデルサイズ 10B〜500B+ と要件が大きく異なる(Table 2)。(2) 組合せ的パラメータ空間——ランタイム構成だけで約1,000通り、5次元並列化だけで約1,000通り、総組合せ数はしばしば100万を超える。(3) 技術革新の速さ——MoE・Mamba 等の新アーキテクチャや量子化・投機的デコードが性能プロファイルを頻繁に変え、構成の再評価を要する。 **Figure 1: LLM クエリのライフサイクル(Prefill と Decode)** ![[_attachments/87_Optimizing_Deployment_Confi/fig01-llm-query-lifecycle.png]] (Figure 1. 1件の LLM クエリは Prefill(入力全体を一括処理)ののち複数の Decode ステップ(1トークンずつ逐次生成)へ分岐する。マルチターン(2個目の Prefill)ではそれまでの文脈が Context として引き継がれる。Prefill は計算バウンドで TTFT を、Decode はメモリ帯域バウンドで TTIT を支配し、両フェーズの資源特性の違いが並列化・ランタイム設計のトレードオフの根源になる。Source: 論文 Figure 1。) **Figure 2b: 本番トラフィックの入出力トークン長分布** ![[_attachments/87_Optimizing_Deployment_Confi/fig02b-io-length-histogram.png]] (Figure 2b. 入力トークン長は0〜1,200と5,000〜6,500付近に2峰性のピークを持ち12,000超まで裾を引く一方、出力トークン長は150付近を中心に単峰かつ急峻に減衰する。1分間平均では入力トークン数が約2,000で比較的安定して見える(Figure 2a)が、実際のリクエスト単位の分布は大きな変動を持ち、固定ワークロード想定でのシステム設計が実態と乖離しうることを示す。Source: 論文 Figure 2b。) ## 提案手法 - **アーキテクチャ(軽量性能シミュレータ)**: 4段構成のプロジェクションフレームワーク(Figure 7)。(1) **入力**——モデルアーキテクチャ・ハードウェア仕様・ランタイム設定・SLO 要件、(2) **ベンチマーキング**——各ハードウェア上で GEMM・attention・AllReduce・AlltoAll 等の演算子をマイクロベンチマークし、ハードウェアあたり10万件超の測定値を性能データベースに蓄積、(3) **推定**——モデル分割・演算子性能モデル・グラフ実行シミュレータからなる Performance Estimator が TTFT/TTIT/QPS を推定、(4) **最適化**——SLO 制約下でスループットを最大化する構成を選ぶ。 - **アルゴリズム/手法の詳細**: - **Operator Performance Model F**: 実測値から多次元区分線形補間/外挿で F(op, H, shape) を構築する。解析モデルより高精度。 - **Model Assembly**: P と D からオペレータ形状を実体化し、F に latency を問い合わせ、通信・ランタイムオーバーヘッドを含むクリティカルパスに沿って合算し、Prefill/Decode それぞれのエンドツーエンドレイテンシを算出する。 - **Runtime-Specific Metrics**: 継続的バッチングでは Prefill/Decode が共有資源上で結合されるため TTFT は Prefill、TTIT は混在した Prefill/Decode レイテンシに依存する。分離推論では独立プールを使うため TTFT/TTIT はそれぞれのプール性能で決まる。QPS_cluster は Prefill/Decode それぞれの最適構成を独立に求めたのち、両者の処理速度を均衡させるアクセラレータ比率を算出して導出する。 - **Search Space Pruning**: メモリ容量制約や SLO 目標に違反する構成を早期に破棄し、標準的な8GPU トポロジに合致する2のべき乗の並列化次数に絞る(GB200 NVL72 等の非標準トポロジには任意の数を許容)。 - **Systematic Search**: 刈り込み後の (H, P, R) 組み合わせを走査し、TTFT・TTIT・QPS_cluster への「性能ランドスケープ」を生成する。 - **Dynamic and Extended Modeling**: 投機的デコード(draft トークン数・受理率でバッチサイズをスケール)と MoE エキスパートルーティング(実測トークン分布で負荷不均衡を捕捉、§4.5参照)をモデル化。電力上限付きアクセラレータを別ハードウェア種として扱うことでエネルギー最適化・TCO 推定も支援する。 - **SLO-Aware Ranking**: レイテンシ SLO(L_TTFT, L_TTIT)に違反する構成を除外し、残った有効構成を最適化目標(例: QPS_cluster 最大)でランク付けし、Pareto 最適フロンティアと制約下の最良構成を特定する。 - **実装上の工夫**: キャッシュとマルチプロセスの活用によりシミュレーション実行時間を数分に短縮し、サイクルレベル・解析的・ML ベースのシミュレータより高速化した。将来ハードウェア(未ベンチマーク)は、シミュレーションベースの演算子性能推定をデータベースにアップロードすることで対応する(LLM の演算子種類は数十程度に限られ演算子間のキャッシング効果も小さいため十分な忠実度を持つ)。 ## 新規性 - 既存研究(Sarathi、Vidur 等のシミュレータ、Yuan+ のルーフラインモデル分析)は特定の最適化や解析的シミュレーションに焦点を当てるが、本論文はそれらを踏まえつつ**数百万規模の展開構成を実測ベンチマーク駆動で体系的に探索する軽量シミュレータ**を提示し、単発の最適化ではなく本番運用から得た**5つの横断的知見**として一般化した点が新しい。 - Prefill-Decode 分離研究(DistServe、Mooncake、Splitwise 等)は分離アーキテクチャそのものを提案するのに対し、本論文は分離 vs 継続的バッチングを**オンライン/オフライン双方の SLO 条件下で定量比較**し、オフラインでは差が消失し継続的バッチングが運用上有利になるという条件付きの結論を示す点で相補的である。 - 並列化戦略研究(Megatron-LM 等)がテンソル/パイプライン並列の設計そのものを扱うのに対し、本論文は Prefill と Decode で**異なる並列化戦略が最適になる**ことを本番構成(例: Prefill が PP4-TP2、Decode が TP8)として定量実証した。 - MoE の Expert Parallelism 研究(GShard、Switch Transformer 等)がアルゴリズム/通信最適化を扱うのに対し、本論文は**密モデルとの iso-parameter 比較でスケールアウト/スケールアップ双方における通信オーバーヘッドの実測差**を示し、EP が本番規模で MoE 移行の意思決定を支えたと報告する。 ## 実験設定 - **ハードウェア(Table 4)**: GPU-A・GPU-B・GPU-C(いずれもスケールアウト、8カード/host、host間帯域50GB/s)、Next-Gen(スケールアウト・スケールアップ両対応、host間/pod内帯域最大900GB/s)。GPU-A/B/C は FLOPs・メモリ帯域・メモリ容量の異なるプロファイルを持つ(具体的ベンダー名は伏せ字表記)。 - **モデル**: Llama3(70B・405B)、MoE 派生(405B・1.8T の仮想的構成)。FFN 重みは特記なき限り FP8 精度を仮定。 - **ワークロードシナリオ(Table 5)**: オンライン(入力2K・出力150・コンテキスト8K)、オフライン(入力2K・出力1K・コンテキスト8K)等。並列化は最大256カード・2のべき乗次数で PP・TP・DP(Attention/FFN 別)・EP を組み合わせて探索。ランタイムは継続的バッチングと分離推論の両方、Prefill バッチサイズ1(オンライン典型)・Decode バッチサイズ1〜4096、KV キャッシュはセッションベースワークロードで persistent KV を使用。 - **評価指標**: TTFT(Time-To-First-Token)・TTIT(Time-To-Incremental-Token)のレイテンシ SLO と、256アクセラレータ正規化スループット QPS_cluster。 ## 実験結果 - **ランタイム設計(§4.2、Table 6/7、Figure 9/10)**: オンライン推論の厳格な SLO 下では分離ランタイムが継続的バッチング比 70B で1.5〜1.8倍、405B で1.8〜2.2倍高い QPS を達成した(例: 70B/GPU-A で分離356 QPS 対継続的バッチング198 QPS)。これは(1) Prefill/Decode の独立最適化、(2) TTIT を犠牲にしない大きな Decode バッチサイズ(70B/GPU-A で112対28)による。オフライン生成(Table 7)ではこの差はほぼ消失し、両者とも深いパイプライン並列と大バッチに収束する(70B/GPU-C では継続的バッチングがわずかに分離を上回るケースもあった)。Meta はオンラインサービスの大半を分離ランタイムへ移行し約30%の容量削減を得た。 **Figure 4 / 発表スライド: 継続的バッチングと分離推論のアーキテクチャ比較、Insight1 定量結果** ![[_attachments/87_Optimizing_Deployment_Confi/fig04-continuous-vs-disagg.png]] (Figure 4. 継続的バッチングは同一 GPU 上で Prefill(P)と Decode(D)を厳密な資源分離なく混在実行するため応答性が損なわれやすいのに対し、分離推論は Prefill/Decode 専用の計算資源を割り当て、コンテキスト伝播オーバーヘッドと引き換えに応答性を高める。Source: 論文 Figure 4。) ![[_attachments/87_Optimizing_Deployment_Confi/slide-insight1-disagg-runtime.png]] (オンライン推論(厳格 SLO)では分離が70Bで1.5〜1.8倍・405Bで1.8〜2.2倍の QPS を達成する一方、オフライン推論(スループットのみ)ではこの差が消失し両者とも深い PP + 大バッチに収束する。Source: MLSys 2026 発表スライド p.9、論文 Table 6/7 の要約。) - **並列化戦略(§4.3、Figure 9)**: Prefill(70B、2K トークン、GPU-A)では TP4PP2 が TP2PP4 よりレイテンシは低いが QPS は20%低く、SLO のヘッドルームを活かす PP4-TP2 が最適解として選ばれた。Decode(70B、8K コンテキスト、GPU-C)では TP を8まで上げると帯域利用が向上し、バッチサイズ128・TP8 が SLO 制約内で最大の QPS(Table 6 の GPU-C で381)を達成した。Next-Gen プラットフォームでは高速な相互接続によりより緩い並列化(Prefill: PP2-TP4、Decode: 大バッチの TP8)で SLO を満たせた。 - **異種ハードウェア(§4.4、Table 8)**: 405B オンラインの分離推論で、GPU-A(高 FLOPs、Prefill 88 QPS だが Decode 77 QPS)と GPU-B/C(高帯域、Decode 276/277 QPS だが Prefill 88/85 QPS)を Prefill/Decode に別々に割り当てると、E2E QPS(67)は同種 GPU-B/B・GPU-C/C 構成と同等になった。性能特性とコスト構造の推定から TCO 改善は15〜25%と見積もられた。最適な Prefill:Decode アクセラレータ比は組み合わせ次第で大きく変わる(GPU-A/A で0.88、GPU-A/B で3.14)。 **発表スライド: 405B モデルの異種ハードウェア構成** ![[_attachments/87_Optimizing_Deployment_Confi/slide-insight3-heterogeneous-hw.png]] (GPU-A(高 FLOPs)を Prefill、GPU-B/C(高 HBM 帯域)を Decode に割り当てる異種構成が、同種最良構成(GPU-B/B・GPU-C/C)と同等の E2E QPS(67)を、より低コストで達成することを示す。Source: MLSys 2026 発表スライド p.11、論文 Table 8 に対応。) - **MoE vs Dense(§4.5、Figure 12/13/14)**: 405B Dense と iso-parameter MoE(125B ベース×4エキスパート、Top-2)を GPU-A・TP8 で比較すると、Prefill は MoE が QPS 213 対 Dense 96(約2倍)、Decode も MoE が QPS 344 対 Dense 210 を記録した。Decode で TP8→TP16 に上げると Dense は QPS 210→84(-60%)と悪化するのに対し、MoE は EP を併用した TP8DP2-TP8EP2 で QPS 344→400(+16%)と向上した。Llama 4 Maverick(128エキスパート)での検証(Figure 13)でも、TP8(単一 host)→TP16(2host)で Decode QPS_cluster がほぼ半減(618→329)する一方、TP8DP2-TP8EP2 は+608(-2%)、TP4DP4-TP4EP4 は+899(TP8比+45%)を達成した。エキスパート負荷不均衡は Prefill では load-balanced 仮定が下限コストを与え、Decode ではメモリ帯域律速のため活性化エキスパート数の予測モデル(load balanced・uniform random・log-linear の3種)を比較し、本番トラフィックに最も一致する log-linear をデフォルトとした(予測手法間で最大3.5倍のコスト差)。 **発表スライド: Expert Parallelism による MoE のデコードスケーリング** ![[_attachments/87_Optimizing_Deployment_Confi/slide-insight4-moe-ep.png]] (Dense モデルは TP8→TP16 で AllReduce コストにより Decode QPS が210→84(-60%)へ悪化するのに対し、MoE モデルは EP を併用することで344→400(+16%)へ向上する。密モデルとの構造的な非対称性を示す。Source: MLSys 2026 発表スライド p.12、論文 Figure 12b に対応。) - **スケールアウト対スケールアップ(§4.6、Figure 15)**: 1.8T 相当の Dense/MoE モデルを Next-Gen のスケールアウト(8カード/host、50GB/s host間)とスケールアップ(64カード/pod、900GB/s pod内)で比較すると、Dense モデルはスケールアウト TP でホストをまたぐと AllReduce コストで QPS がほぼゼロ(QPS 3)まで崩壊するのに対し、スケールアップは限定的な劣化(QPS 14)にとどまった。MoE はスケールアウトでも EP により良好にスケールし(スケールアウト QPS 488、スケールアップ QPS 655)、スケールアップに対してスケールアウトが約2倍のQPS比を維持できる一方、Dense はスケールアップが必須になることを実証した。 ## 考察 - 5つの知見はいずれも「単一の最適解は存在せず、ワークロード・モデルアーキテクチャ・ハードウェア世代の組み合わせに応じて最適構成が変わる」という共通の主張に収束する。著者らはこれを、数百万規模の設計空間を体系的に探索する軽量シミュレータの必要性の根拠として位置づける。 - TP/PP に対する EP の優位性は、モデルアーキテクチャ(密 vs MoE)がインフラ選択(スケールアウト vs スケールアップ)の必要性を規定する例として示され、Meta が主要モデルの多くを MoE ベースアーキテクチャへ移行する意思決定を後押ししたと報告されている。 - 一般化可能性について著者らは、TP 対 PP のフェーズ別トレードオフ・MoE における EP の優位性・SLO 敏感ワークロードでの分離の有効性という定性的傾向は、計算・通信特性という基礎的要因に由来するため他システムにも適用可能だが、効果の大きさはモデル規模やアクセラレータ数に依存すると明記している(§5「Applicability of Insights on Other Inference Scenarios」)。 ## 強み / 弱点・課題 - **強み**: 月間10億ユーザー規模の本番運用に基づく実測知見であり、シミュレータの精度は実機測定に対し±5%以内(§3.4、Figure 8)と検証されている。Prefill/Decode・Dense/MoE・複数アクセラレータ世代を横断した5知見という広いカバレッジを持つ。 - **弱点・限界**: - 使用したハードウェアは GPU-A/B/C・Next-Gen という匿名化表記であり、具体的なベンダー・型番(NVIDIA H100/H200、AMD MI300X など本文中で言及される候補)との対応が明示されていない。 - MoE vs Dense の比較(§4.5)は「iso-parameter の仮想的 MoE モデル」を用いており、著者ら自身も「Llama3 405B の妥当な拡張を表すものではない」と明記している。 - シミュレータは micro-benchmark ベースの補間モデルであり、ネットワークジッタ等の非決定的要因は P99 テールレイテンシに影響しうるが、中央値・平均値の予測に主眼を置くと述べる(§3.4)。 - 論文で報告される数値(スループット・TCO 改善率)は Meta の本番環境・ワークロード分布に強く依存し、著者ら自身が「実務者は自身の環境で構成を検証すべき」と限界を明記している(§5「Future Directions」)。