> [!abstract] 概要(Abstract 和訳) > サーバーレスコンピューティングは、クラウドベースの大規模言語モデル(LLM)推論にとって魅力的なパラダイムであるが、需要に応じた LLM のスケーリングは、データ転送コストの高さゆえに大きな課題であり続けている。本論文では、高速かつリソース効率の良いモデルスケーリングを実現するサーバーレス LLM システム、FaaScale を提示する。中核となる着想は co-design 原則――pipelined multicast inference――であり、これはマルチキャストと、モデル転送中の動的なクロスノードのパイプライン並列実行とを相乗させるものである。FaaScale はこの設計を PipeCast によって実装する。PipeCast は、モデルブロックを適応的にマルチキャストしつつ、その場で推論パイプラインを動的に形成するモデルスケーリング方式である。GPU とホストメモリ間の効率的なメモリ管理と組み合わせることで、FaaScale は bursty な LLM 推論ワークロードを効果的に処理し、実世界の LLM トレースにおいて最大 5 倍低い tail time-to-first-token レイテンシと 31.3% のコスト削減を達成する。 ## 論文情報 - タイトル: FaaScale: Unlocking Fast LLM Scaling for Serverless Inference - 著者: Minchen Yu*・Rui Yang*・Chaobo Jia・Zhaoyuan Su・Sheng Yao・Tingfeng Lan・Yuchen Yang・Yue Cheng・Wei Wang・Ao Wang・Ruichuan Chen(* は Equal contribution) - 所属: The Chinese University of Hong Kong, Shenzhen / University of Virginia / Hong Kong University of Science and Technology / Alibaba Group / Nokia Bell Labs - 媒体: Proceedings of the 9th MLSys Conference, Bellevue, WA, USA, 2026 - コード: FaaScale codebase (github.com/lambda-scale/lambda-scale)、FaaScale RDMA P2P codebase (github.com/lambda-scale/rdma-p2p) - 関連技術レポート: Yu et al., "λScale: Enabling fast scaling for serverless large language model inference" (arXiv:2502.09922, 2025) ―本論文が §7 で「our technical report」として参照する詳細版・マイクロベンチマーク/感度分析/アブレーションの掲載先 - 発表スライド: MLSys 2026 発表スライド(16ページ、`https://mlsys.org/media/mlsys-2026/Slides/3769.pdf`、登壇者 Minchen Yu、連絡先 [email protected]) ## 概要 FaaScale は、サーバーレス LLM 推論プラットフォームにおけるモデルスケーリングの高速化を目的としたシステムである。中核の設計原則は pipelined multicast inference――モデルブロックのマルチキャストと、モデル転送中に動的形成されるクロスノードのパイプライン並列推論とを同期させ、モデル全体の到着を待たずに分散推論を開始できるようにする co-design である。この原則を PipeCast というスキームで実装し、さらに GPU/ホストメモリ横断のメモリ管理を組み合わせることで、bursty なワークロード下での TTFT レイテンシと GPU コストの両方を改善する。 ## 問題設定 - **入力**: サーバーレス LLM 推論プラットフォームの実世界ワークロード(BurstGPT トレース、XYZ という匿名化された大手クラウドの本番トレース)。リクエスト率は数秒〜数分のスケールで一桁以上急増する(Figure 1)。 - **前提条件**: モデルは GPU メモリ・ホストメモリ・SSD の階層に分散して配置され、クラスタは 400Gbps RDMA 対応の InfiniBand などの高速インターコネクトを備える。 - **必要なデータ**: 各ノードの GPU/ホストメモリ利用状況、モデルブロック単位のロケーリティ(GPU 常駐/ホストメモリキャッシュ/どちらにも無い)。 なお model proliferation の規模感について、論文本文(Introduction)は「Hugging Face は 50 万超のファインチューニング LLM をホストし、指数関数的に増加している」と記述するのに対し、発表スライド(p.3)は「Hugging Face 上に 2M(200 万)超のモデル」というさらに大きい数字を提示している。スライドの方が論文投稿より後の集計に基づく可能性があり、数字の食い違いとして注記しておく。 論文は既存の 3 つのコールドスタート緩和策の限界を実測で示す。(1) リモートロード(Hugging Face 方式)は S3 等からの帯域制約により低速。(2) 過剰プロビジョニング(SageMaker 方式)は GPU アイドルを常態化させ pay-per-use の前提と矛盾する。(3) ホストメモリ/SSD キャッシュ(ServerlessLLM 等)は、Llama-70B 相当のモデルサイズ設定でモデルのキープアライブ時間の 95% 超が 15 秒未満に留まり(Figure 2)、2 本の実トレース再生でキャッシュミス(SSD ロード)が 64%/36% を占める(Figure 3)。SSD からのロードは Llama-70B で 30 秒超を要し、ホストメモリロードより一桁遅い。 ## 提案手法 ### アーキテクチャ FaaScale は cluster manager(リクエストディスパッチャ・リソースマネージャ・model scaling controller・pipelined execution controller から構成)と、各 worker node 上で稼働する model manager(推論モジュール + 転送モジュール)から成る(Figure 4)。model manager は GPUDirect RDMA(GDR)を用いて GPU 間データを直接交換し、ホストを経由するデータ移動を回避する。1 ノードがモデルインスタンスを保持し、それを他ノードへブロック単位でマルチキャストする場面を典型例とする。 **Figure 4: FaaScale アーキテクチャ概要** ![[_attachments/24_FaaScale_Unlocking_Fast_LLM/fig04-architecture.png]] (Figure 4. モデルを 4 色のブロックに分割し、1 ノードが他ノードへマルチキャストする例。各 worker node の Model Manager は GPU/ホストメモリ上のモデルインスタンスを管理し、GDR/RDMA 経由で NIC からブロックを送受信する。Source: Adapted from FaaScale Figure 4.) ### アルゴリズム/手法の詳細(PipeCast) PipeCast は動的実行パイプラインという抽象を導入する。これは、複数 GPU ノードにまたがる動的な集合であり、モデル全体を協調的に保持しながらパイプライン並列を行う推論インスタンスとして機能する。設計は 3 つの要素からなる。 1. **適応的モデルマルチキャスト**: k → N スケーリング(k 個のソースノードが残り N−k 個のノードへ配信)を、N ノードを k 個のサブグループ(各 L = ⌊N/k⌋ または N mod k ノード)に均等分割し、各サブグループが 1 → L スケーリングを binomial pipeline 方式で実行する形に一般化する。モデルブロック数 b は、細粒度過ぎると転送時間 T が延び、粗粒度過ぎるとパイプライン実行時の中間データ通信オーバーヘッドが増える "elbow point" を持つため、オフラインプロファイリングで一度だけ選ぶ(RDMA 対応の安定ネットワークを前提。高変動ネットワークへの適応チューニングは future work)。 2. **k-way 伝送戦略(Algorithm 1)**: b 個のモデルブロックを k 個の等サイズチャンクに分割し(l = ⌈b/k⌉)、各サブグループ i の転送順序 O_i を「チャンク集合を i だけ循環シフトしたもの」として生成する。これにより異なるサブグループが相補的なブロックを並行して転送し、最初の完全なモデルインスタンスが b/k タイムステップで組み上がる。 3. **実行パイプライン生成戦略(Algorithm 2)**: 未割当ノードを持つサブグループ集合 G から、可能な限り多くのサブグループを跨いでパイプラインを構築する。G が単一サブグループのみになれば、そのサブグループ内ノードで直接パイプラインを組む。複数サブグループが残る場合は、各サブグループから 1 ノードずつ選んでパイプラインを構成する(最小サブグループサイズ a 回繰り返す)。これにより、相補的なモデルブロックが到着した時点で実行パイプラインが動的に形成され、全ノードの受信完了を待たずに推論が始まる。 **Figure 5: PipeCast の 2 → 8 スケーリング例(k-way マルチキャストとパイプライン形成)** ![[_attachments/24_FaaScale_Unlocking_Fast_LLM/fig05-pipecast-multicast.png]] (Figure 5. (a) 素朴な 2 → 8 マルチキャスト(サブグループごとに独立実行、ブロック転送順序も同一)。(b) PipeCast の 2-way 動的パイプライン並列: サブグループ 1 は {B3,B4} を先に、サブグループ 2 は {B1,B2} を先に転送する循環シフトにより、ノード B/D・F/H が全ブロックを早期に組み上げてパイプライン並列推論(PP1・PP2)を開始できる。(c) binomial-pipeline マルチキャストの最初の 3 ステップの詳細。Source: Adapted from FaaScale Figure 5.) ### 実装上の工夫 - **2D 実行パイプライン**: 単一 GPU に収まるモデルでは、4 ノードパイプラインが複数バッチ(複数リクエスト)を 2 次元パイプライニングで並列処理する。各ノードは特定のモデルブロックを担当し、あるバッチの処理を終えると次のバッチの計算に移りつつ、中間結果を次ノードへ渡す。発表スライドは、この設計の要点を「モデル転送と推論のオーバーラップを、KV キャッシュではなく中間活性化(intermediate activations)のみを転送することで単純に保つ」と明快に定式化しており、論文本文よりも設計判断の理由(なぜ KV キャッシュでなく中間活性化か)が伝わりやすい。 **スライド図: Pipelined collaborative inference(2D 実行パイプラインの可視化)** ![[_attachments/24_FaaScale_Unlocking_Fast_LLM/slide-2d-execution-pipeline.png]] (左: 4 ノードがそれぞれモデルブロック 1〜4 を担い、リクエスト D/E/F/G が各ノードを順に流れる古典的なパイプライン並列の模式図。右: 各ノードの GPU 0〜3 上でモデルブロック(実線)と in-flight ブロック(斜線)がどのタイミングで揃うかを示し、中間データが対角線状に次ノードへ流れる様子を描く。論文 Figure 6 とは異なる角度からの独自可視化。Source: MLSys 2026 発表スライド p.10。) - **マルチ GPU モデル対応**: モデルが単一 GPU に収まらない場合、PipeCast はモデルサイズと資源availability に応じて 3 つの実行戦略(単一 GPU モデル向けクロスノードパイプライン/マルチ GPU モデル向けクロスノードパイプライン/単一ノード内の GPU 間 NVLink レプリケーションによるスケールアップ)を動的に選択する。NVLink は RDMA より一桁高い帯域を提供し、ノード内複製を高速化する。 - **ロケーリティ駆動モデル起動**: GPU 常駐(hot start)・ホストメモリキャッシュ(warm start、PipeCast でマルチノードパイプラインを併用)・完全コールド(null、リモート GPU/ホストメモリからブロック取得)の 3 レベルで起動戦略を切り替える。 - **効率的メモリ管理**: (1) tensor packing でモデルブロック単位のテンソルを連続メモリ領域にまとめてバルク転送効率を上げる。(2) GPU メモリ事前割当により、リクエスト間でサイズが一定なモデルブロック・中間結果のメモリ確保オーバーヘッドを削減する(KV キャッシュ等の動的ランタイム状態は推論エンジン側が管理し、この設計の対象外)。スケールアウト時に必要なのは RDMA アクセス可能なメモリ上の完全レプリカ 1 つのみで、1-to-N 拡張(能動レプリカから)と 0-to-N 拡張(インメモリレプリカから)を同一機構でカバーする。 ## 新規性 既存のバイナリツリー等の汎用マルチキャストスキーム(FaaSNet が採用)は推論セマンティクスに非依存であり、計算と通信のオーバーラップを最大化できない。また、既存研究の pipelined inference(Crankshaw ら, Clipper 2017; Shen ら, Nexus 2019 等)は静的なリソース構成を前提とする。FaaScale はこの 2 点を統合し、モデルスケール転送中に動的に実行パイプラインを構築する co-design を提案した点が新規性である。関連研究として言及される BlitzScale (Zhang et al., 2024) はチェーンベースのモデルスケーリングと Prefill/Decode 分離 (Zhong et al., DistServe 2024) 前提のスケジュールを組み合わせるのに対し、FaaScale は binomial pipeline によるスケーラブルなマルチキャストを重視し、P/D 分離を仮定しないより汎用的なサーバーレス環境を対象とする。DynamoLLM (Stojkovic et al., 2025) は予測可能性を利用したモデルプリフェッチに依拠するが、FaaScale は bursty かつ予測不能なワークロードを対象に設計される。Medusa (Zeng et al., 2025) は CUDA グラフと KV キャッシュ状態の materialize によって単一ノードの起動オーバーヘッドを削減するもので、FaaScale が対象とするクロスノードのモデル転送・実行とは相補的な位置づけである。 ## 実験設定 - **実験環境**: 共有 HPC クラスタ、最大 24 台の NVIDIA H800 GPU・ユーザーあたり 12 ノードを占有的に割当。Testbed1(1×H800/ノード、単一 GPU でモデルが収まるケース、例 Llama-2 7B、12 ノード)と Testbed2(4×H800/ノード、単一 GPU に収まらないケース、例 Llama-2 70B、6 ノード)の 2 構成。いずれも単一 400Gb/s InfiniBand NIC を備える(Table 1)。 - **モデル・パラメータ**: Llama-2 7B/13B/70B、k ∈ {1, 2, 4}。7B・13B は Testbed1、70B は Testbed2 で実行。 - **評価指標**: (1) スループット(tokens per second)、(2) レイテンシ(TTFT)、(3) コスト効果(累積 GPU 時間)。 - **比較対象**: ServerlessLLM(Fu et al., OSDI 2024。動的スケーリング向け locality-enhanced サーバーレス LLM 推論の SOTA。Ray Serve のクラスタ管理オーバーヘッドを除去して実装)、FaaSNet(Wang et al., ATC 2021。Alibaba の実運用サーバーレスコンテナプロビジョニング、バイナリツリートポロジを GDR ベースロードに拡張)、NCCL(NVIDIA 製マルチ GPU 通信ライブラリ。ネイティブなマルチキャスト非対応のため broadcast プリミティブを動的プロセスグループ形成で代用)。 - **実ワークロード評価**: BurstGPT(Wang et al., 2024。Azure OpenAI GPT サービス由来の実トレース)から 30 分のスニペットを抽出。NCCL・FaaSNet はリモート GPU からの GDR ロードを優先しキャッシュミス時のみ SSD にフォールバック、ServerlessLLM はホストメモリキャッシュヒット時のみ高速でミス時は SSD、FaaScale は best-effort のホストメモリキャッシュに加えキャッシュミス時に PipeCast マルチキャストへフォールバックすると仮定。 ## 実験結果 ### マルチキャスト性能(§7.2, Figure 7) **Figure 7: エンドツーエンドのモデルマルチキャストレイテンシ(k=1)** ![[_attachments/24_FaaScale_Unlocking_Fast_LLM/fig07-multicast-latency.png]] (Figure 7. 4 ノード(16 GPU、Llama-2 70B)・8 ノード(8 GPU、Llama-2 7B)・12 ノード(12 GPU、Llama-2 13B)の 3 構成での転送レイテンシ比較。FaaScale は FaaSNet に対し最大 1.82×、NCCL に対し最大 1.53× の高速化を達成。優位性はモデルサイズとクラスタ規模の拡大とともに拡大する(7B・4 ノードでは差は小さいが、70B・4 ノードや 13B・12 ノードでは差が拡大)。12 ノードでの相対的な gain 縮小は binomial multicast 設計自体の限界ではなく、テストベッドの GPU–NIC の NUMA 配置と NCCL のトポロジ最適化に起因すると論文は分析する。Source: Adapted from FaaScale Figure 7.) ### スループット・レイテンシ性能(§7.3, Figure 8) **Figure 8: GDR 経由のスループットスケーリング(k を変えた場合)** ![[_attachments/24_FaaScale_Unlocking_Fast_LLM/fig08-throughput-scaling.png]] (Figure 8. 上段 Llama-2 7B・下段 Llama-2 70B。FaaScale(緑)は k=1/2/4 いずれの設定でも FaaSNet・NCCL・ServerlessLLM よりピークスループットに到達する時間が大幅に短い。ServerlessLLM は SSD ベースロードのため立ち上がりが特に遅い(ミニプロットで延長タイムラインを表示)。k を大きくすると FaaScale の立ち上がり開始時刻はさらに早まる(Llama-2 7B で k=1 時 約0.6 秒 → k=4 時 約0.15 秒)。k≥2 では分散パイプライン実行の同期・中間データ転送オーバーヘッドに由来する階段状のプラトーが生じるが、これは各小規模パイプライン内に閉じており、クラスタ全体の同期を要しないため根本的なスケーラビリティのボトルネックではないと論文は論じる。Source: Adapted from FaaScale Figure 8.) - **TTFT**: FaaScale は 50 リクエスト全てを 1.1 秒で処理開始でき、これは FaaSNet 比 2×、NCCL 比 1.4×、ServerlessLLM 比 8× 高速(7B・70B でも同様の傾向)。ServerlessLLM-SSD はオンデマンド SSD I/O の遅さと、モデル全体のロード完了を待つ推論開始の遅延により long-tail TTFT を示す。 ### 実ワークロード評価(§7.4, BurstGPT トレース) - FaaScale は 3 モデルサイズ全てで、他システムより有意に速くスケールアウト・スケールインする。累積 GPU 時間は FaaSNet 比最大 17.8%、NCCL 比 18.1%、ServerlessLLM 比 31.3% 少ない。Ideal Scaling(モデルロードオーバーヘッドをゼロと仮定する理想値)との差は 4.3〜18.6% に留まり、最も理想に近い挙動を示す。 - TTFT の CDF では、FaaScale が全モデルサイズで他ベースラインを上回る。静的ワークロード時と異なり、バーストworkload下では NCCL・FaaSNet の CDF は SSD からの頻繁なモデルロードにより右(遅い方)にシフトし、逆に ServerlessLLM は高いキャッシュヒット率のため左(速い方)にシフトする傾向が観察された。 **スライド図: End-to-end performance(GPU 割当推移・累積 GPU 時間・TTFT の CDF を統合した要約)** ![[_attachments/24_FaaScale_Unlocking_Fast_LLM/slide-end-to-end-performance-summary.png]] (Llama2-7B・Llama2-70B それぞれについて、RPS の推移(最上段)と、FaaScale・Ideal Scaling・FaaSNet・ServerlessLLM・NCCL 各方式の GPU 割当推移(緑破線が FaaScale の挙動を全方式に重ね描き)、累積 GPU 時間の棒グラフ(最下段)を1枚に統合し、右側に Llama2-7B/70B の TTFT CDF を並置する。論文 Figure 10・Figure 11 に対応するが、本スライドは全システムを縦に並べて比較しやすくした独自レイアウト。ヘッドライン数値として「31% cost reduction」「5x P90 TTFT latency improvement」を明記。Source: MLSys 2026 発表スライド p.14。) ## 考察 - FaaScale の設計は安定した RDMA 対応ネットワークを持つモダンな AI サービングクラスタを前提とする。ただし核となる恩恵(モデルブロック到着後すぐに推論をオーバーラップさせる)はインターコネクトの種類に依存せず成立し、より低帯域・高ジッタ・非 RDMA なネットワークでも(絶対的な gain は縮小するものの)適用可能と論文は主張する。 - マルチテナント・異種性への拡張として、FaaScale の高速スケールアウトは Aegaeon(マルチモデル間のリソース共有・admission control)や Helix(異種 GPU クラスタスケジューラ)と直交し組み合わせ可能と位置づけられる。KV キャッシュ再利用(Mooncake 等)とも自然に統合できるとされる。 - 動的実行パイプラインはブロック可用性の追跡・パイプラインメンバーシップ更新・完全レプリカ組み上げ後のパイプライン退役といった軽量な制御プレーン調整を要するが、これは一時的なメタデータ管理に限定され、モデル転送や GPU 計算自体には追加負荷を与えないため、スケールアウト応答性を高めつつデータパスは不変に保たれると論文は説明する。 ## 強み / 弱点・課題 **強み** - コールドスタート問題を「マルチキャストと推論実行の co-design」という単一の設計原則に還元し、既存の汎用マルチキャストや静的パイプライン推論の限界を明確に切り分けている。 - 実世界トレース(BurstGPT)での評価に加え、マルチキャスト性能・スループット・レイテンシを個別に切り分けたマイクロベンチマークを揃え、改善の要因(マルチキャスト高速化 vs 早期パイプライン実行開始)を分離して説明している。 - k-way 伝送戦略とパイプライン生成戦略が疑似コード(Algorithm 1・2)として明示されており、再現性・検証性が高い。 **弱点・課題** - ブロックサイズ b はオフラインプロファイリングによる単一設定で運用され、ネットワーク条件が大きく変動する環境への適応チューニングは明示的に future work とされている。 - k≥2 で観測される階段状スループットプラトー(分散パイプライン実行の同期・中間データ転送オーバーヘッド由来)は「小規模パイプライン内に閉じ、クラスタ全体のボトルネックにはならない」とされるが、この主張を裏付ける定量的な感度分析は本論文中には無く、技術レポート(λScale, arXiv:2502.09922)に委ねられている。 - k → N スケーリングの前提として「k ≥ 1(ホストメモリ上に少なくとも 1 レプリカ)」が要求されるが、この前提が崩れる完全な 0 レプリカ状態からの初回コールドスタートの扱いは本文で深く扱われていない。