# FaaScale: Unlocking Fast LLM Scaling for Serverless Inference > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 3 (May 20 / Wed)、Research Track Oral "LLM Serving 2" セッション（09:00 PDT） > - **登壇者:** Minchen Yu\*¹, Rui Yang\*², Chaobo Jia¹, Zhaoyuan Su², Sheng Yao³, Tingfeng Lan², Yuchen Yang³, Zirui Wang², Yue Cheng², Wei Wang³, Ao Wang⁴, Ruichuan Chen⁵ — ¹CUHK-Shenzhen, ²University of Virginia, ³Hong Kong University of Science and Technology, ⁴Alibaba Group, ⁵Nokia Bell Labs（\*equal contribution） > - **URL:** https://mlsys.org/virtual/2026/oral/3769 > - **OpenReview:** https://openreview.net/forum?id=jgL8LuOVyT > [!abstract] 概要（論文アブストラクト・忠実日本語訳） > サーバレスコンピューティングはクラウドベースの大規模言語モデル（LLM）推論にとって魅力的なパラダイムであるが、データ転送コストの高さからオンデマンドでの LLM スケーリングは依然として大きな課題である。本論文では、高速かつリソース効率の高いモデルスケーリングを実現するサーバレス LLM システム FaaScale を提案する。中核となるアイデアは、パイプライン化マルチキャスト推論（pipelined multicast inference）という共同設計原理であり、動的なマルチキャストとクロスノードのパイプライン並列実行をモデル転送中に相乗的に組み合わせる。FaaScale はこの設計を PipeCast というモデルスケーリング方式で実装する。PipeCast はモデルブロックを適応的にマルチキャストし、その場で推論パイプラインを動的に構成する。GPU メモリとホストメモリにまたがる効率的なメモリ管理と組み合わせることで、FaaScale はバースト性のある LLM 推論ワークロードを効果的に処理し、実環境の LLM トレースにおいてテイルの TTFT レイテンシを最大 5 倍改善し、GPU コストを 31.3% 削減する。 ## 問題設定: サーバレス LLM 推論のスケーリング課題 サーバレス推論プラットフォーム（Amazon SageMaker Serverless Endpoints、Alibaba Serverless GPU、Hugging Face Serverless Inference Endpoints 等）では、ユーザがモデルを推論エンドポイントとして公開し、プラットフォームが動的なリクエストに応じて自動的にリソースをスケーリングする。しかし LLM 推論の採用拡大に伴い、以下の 3 つの性質がサーバレスプラットフォームに根本的な課題をもたらす。 1. **バースト性のあるリクエストパターン**: 本番 LLM トレース（BurstGPT、匿名化されたグローバルクラウドプロバイダ XYZ、Azure OpenAI GPT サービス）の分析により、リクエストレートが数分以内に 10 倍以上急増するバースト性が確認された（論文 Figure 1）。サブ秒単位の高速スケーリングが必要となる。 2. **大きなリソースフットプリント**: 単体の LLM が数百 GB の GPU メモリを要する（例: Llama-70B で 140 GB）。モデルのロードと初期化に数分を要し、コールドスタートが発生する。 3. **モデルの増殖**: Hugging Face 上のファインチューニング済み LLM バリアントは 50 万以上に達し、指数関数的に増加中である。全モデルの総メモリ需要が GPU クラスタ容量を大幅に超過し、頻繁なモデルの退避・再ロードが発生する。 ### 既存手法の限界 論文では 3 つの既存アプローチを検討し、いずれもバースト性・スケーラビリティ・コスト効率のバランスを達成できないことを示す。 - **リモートロード**: Hugging Face Inference Endpoints 等がリモートレジストリやオブジェクトストレージからモデルを取得する方式。ダウンロード帯域幅の低さと並列ロード時のネットワーク帯域競合により、リアルタイム推論サービスには不適。 - **GPU オーバープロビジョニング**: SageMaker Endpoints 等がアクティブなインスタンスを予約 GPU 付きで常時確保する方式。低需要時にも GPU がアイドルとなり、サーバレスの従量課金モデルに反する。 - **ホストメモリ／SSD キャッシュ**: モデルをホストメモリや SSD にキャッシュし、リクエスト到着時に GPU へロードする方式。モデルサイズの増大とテナント多様性の増加によりキャッシュヒット率が低下する。論文の実測では、モデルの 95% 以上がメモリ滞在時間 15 秒以下で退避され、SSD ロード（キャッシュミス）が全ロードの 64%（Trace 1）および 36%（Trace 2）を占める（論文 Figure 2, 3）。SSD から GPU への Llama-70B ロードは最適化実装でも 30 秒以上を要する。 ## 着想: 高速インターコネクトとパイプライン化マルチキャスト推論 FaaScale の設計は 2 つの洞察に基づく。 1. 現代の GPU クラスタは 400 Gbps の RDMA 対応高速ネットワークインターコネクトを備えており、効率的なモデルマルチキャストの機会を提供する。多数のモデルをローカルにキャッシュする必要なく、ノード間でモデルを高速転送できる。 2. モデルの部分的なパラメータが到着した時点で推論を開始できる。すなわち、モデルマルチキャスト中に協調的な分散推論実行を重畳させることが可能である。 この 2 つの洞察を統合した設計原理が**パイプライン化マルチキャスト推論（pipelined multicast inference）**であり、モデルの配信と実行を密に重畳させることで起動レイテンシを最小化し、動的ワークロード下でのスケーラビリティを強化する。 ## FaaScale のアーキテクチャ概要 FaaScale は以下のコンポーネントで構成される（論文 Figure 4、スライド p.6）。 **クラスタマネージャ**: ユーザのプロンプトクエリをワーカノードへディスパッチし、グローバルリソースを管理し、モデルスケーリングとパイプライン実行を調整する。内部に Resource Manager、Model Scaling Controller、Pipelined Execution Controller、Request Dispatcher を持つ。 **ワーカノード**: 各ノードに Model Manager と Node Controller を配置。Model Manager は GPU やホストメモリ等のローカルリソースを追跡し、モデルの実行・転送タスクを管理する。転送には GPUDirect RDMA（GDR）を活用し、ホストを経由せず異なるノードの GPU 間で直接データを交換する。ホストメモリ上のモデルへの RDMA 経由の直接アクセスもサポートする。 **ブロックレベルモデルマルチキャスト**: モデルを色分けされたブロックに分割し、バイノミアルパイプラインベースのハイパーキューブ通信トポロジでマルチキャストする。各ワーカノードは受信したブロックを隣接ノードへ転送し、協調的にモデルを配信する。 ## PipeCast: モデルスケーリング方式の設計 PipeCast は FaaScale の中核となるモデルスケーリング方式であり、3 つの主要設計を持つ。 ### 推論認識型モデルマルチキャスト（Inference-Aware Model Multicast） PipeCast はバイノミアルパイプラインアルゴリズムを拡張し、様々なスケーリングシナリオに対応する適応的なモデルマルチキャストを実現する。 **k-way 転送戦略**: k 個のソースノードから N 個のノードへモデルを配信する k → N スケーリングを考える。PipeCast は N ノードを k 個のサブグループに均等分割し、各サブグループ内で 1 → L スケーリング（L = ⌊N/k⌋ または N%k）を実行する。モデルブロックを k 個のチャンクに分割し、サブグループ間で循環シフト（circular shift）により転送順序をずらすことで、相補的なブロックが並列に転送される（論文 Figure 5、スライド p.9）。 この設計により、サブグループ間で協力的なマルチキャストが実現し、最初の完全なモデルコピーが b/k タイムステップ後に利用可能となる（b はモデルブロック数）。ナイーブなアプローチでは全サブグループが独立にマルチキャストを行い全ブロックの到着を待つ必要があるのに対し、PipeCast では任意の 2 ノード間で相補的なブロックを集約することで早期にパイプライン並列実行を開始できる。 **選択的ブロックサイズ**: ブロックサイズ b はマルチキャスト性能に重要である。小さすぎる b は転送時間の増大を招き、大きすぎる b はブロック数の減少とパイプライン実行時の中間結果通信オーバーヘッドの増大を招く。PipeCast はオフラインプロファイリングにより最適な b を経験的に決定する。 **最適化された転送順序**: Algorithm 1（論文）で k-way 転送戦略を定式化する。モデルブロックを k 個の等サイズチャンクに分割し、各サブグループに対して循環シフトによりブロック転送順序を生成する。これにより完全なモデルの組み立てに必要な時間を最小化する。 ### パイプライン化推論実行（Pipelined Inference Execution） PipeCast は**動的実行パイプライン**の抽象化を導入する。実行パイプラインは複数ノードにまたがるモデルサービングインスタンスとして機能し、パイプライン並列で推論を実行する（論文 Figure 6a、スライド p.10）。 **実行パイプラインの生成**: Algorithm 2 により、可能な限り多くのサブグループからパイプラインを構成する。残りの未割り当てノードが単一サブグループに属する場合はそのまま 1 本のパイプラインとし、複数サブグループに属する場合は各サブグループから 1 ノードずつ選出してパイプラインを構成する。 **2D 実行パイプライン**: 4 ノードのパイプラインを例にとると（論文 Figure 6a）、第 1 次元では各ノードが特定のモデルブロックを担当し、第 2 次元ではリクエストバッチをパイプライン処理する。あるノードが担当ブロックの計算を完了すると中間結果を次ノードへ渡し、自身は次バッチの計算を開始する。中間活性値のみを転送し KV キャッシュは転送しない設計により、データ転送のオーバーヘッドを抑える。 **マルチ GPU モデルへの対応**: 単一 GPU に収まらないモデルの場合、以下の 3 ケースを動的に選択する。 - **Case 1（クロスノード実行パイプライン）**: 単一 GPU に収まるモデルの既定モード。 - **Case 2（マルチ GPU モデルのクロスノードパイプライン）**: 完全なブロックを受信した GPU が即座にクロスノード実行パイプラインを形成し、全ブロック到着を待たずにパイプライン推論を開始する（論文 Figure 6b）。 - **Case 3（ノード内スケールアップ）**: 同一ノード上の複数ローカル GPU を活用し、NVLink 等のノード内高速通信（RDMA より 1 桁以上高帯域）によりモデルブロックを高速複製する（論文 Figure 6c）。 ### モード切替（Mode Switching） PipeCast はノードが完全なモデルレプリカを受信した後、ローカル実行モードに切り替えることを許容する。これによりクロスノード通信オーバーヘッドを排除し、部分ロード状態から完全ロード状態へのスムーズな遷移を実現する。 ## 効率的なモデル管理 ### ローカリティ駆動型モデル起動（Locality-Driven Model Startup） FaaScale はストレージ階層に応じたマルチレベルの起動戦略を採用する（スライド p.11）。 - **GPU（ホットスタート）**: モデルが GPU メモリに完全にロード済みの場合、即座にローカル実行を開始する。 - **ホストメモリ（ウォームスタート）**: モデルがホストメモリにキャッシュされている場合、FaaScale は直接 GPU へロードし、ロード完了前でも複数のウォームインスタンスにまたがる実行パイプラインを構成して推論を開始する（PipeCast）。 - **キャッシュなし（コールドスタート）**: モデルが GPU にもホストメモリにもない場合、リモートの GPU またはホストメモリからモデルブロックを直接取得し、PipeCast によりスケーリングを実行する。 ### メモリ管理の最適化 FaaScale は GPU とホストメモリの効率的な管理のため 2 つの戦略を採用する。 - **テンソルパッキング**: 各モデルブロックに関連する全テンソルデータを連続メモリ領域にマッピングし、ブロック単位のバルク転送を効率化する。推論実行には影響しない。 - **GPU メモリ事前確保**: モデルブロックと中間結果のためのメモリチャンクを事前に確保する。リクエスト間でサイズが一定であるため、KV キャッシュ等の動的状態は vLLM 等の推論エンジンに管理を委ねる。スケールアウト時にはクラスタ内に RDMA アクセス可能な完全なレプリカが 1 つ存在すればよく、実行時のメモリ確保オーバーヘッドを最小化する。 ## 実装 FaaScale は Python 10K 行、C++ 1K 行で実装されている。クラスタマネージャとワーカノードの 2 コアコンポーネントで構成される。推論モジュールは Meta の Llama 推論フレームワークを拡張してローカル・分散推論の双方をサポートし、転送モジュールは Derecho の RDMC 上に構築してバイノミアルパイプラインと GDR/RDMA セマンティクスを実装する。RDMC から約 470 行、片側 RDMA とメモリ領域拡張に約 520 行を再利用・追加し、主要な RDMA P2P 転送 API は Pybind11 経由で Python に公開する。ソースコードは公開されている（GitHub: lambda-scale/lambda-scale、lambda-scale/rdma-p2p）。 ## 実験・評価 ### 実験環境 最大 24 基の NVIDIA H800 GPU と 12 ノードを持つ共有 HPC クラスタ上で評価。2 つのテストベッドを構成（論文 Table 1）。 | テストベッド | GPU | NIC | メモリ | SSD | ノード数 | |---|---|---|---|---|---| | Testbed1 | 1xH800 | 1x400Gb/s IB | 400Gb/s | 400Gb/s | 12 | | Testbed2 | 4xH800 | 1x400Gb/s IB | 400Gb/s | 400Gb/s | 6 | Testbed1 は単一 GPU にモデル全体が収まる場合（Llama-2 7B 等）のノード間通信スケーラビリティ検証用、Testbed2 は単一 GPU に収まらないモデル（Llama-2 70B 等）のマルチ GPU 環境検証用。 モデルは Llama-2 の 7B、13B、70B。k 値は {1, 2, 4}。ベースラインは ServerlessLLM（USENIX OSDI 2024）、FaaSNet（USENIX ATC 2021）、NCCL（NVIDIA）。 評価指標: (1) スループット（TPS）、(2) レイテンシ（TTFT）、(3) コスト効率（GPU 時間）。 ### マルチキャスト性能（論文 Figure 7） エンドツーエンドのマルチキャストレイテンシを測定。FaaScale は FaaSNet に対して最大 1.82 倍、NCCL に対して最大 1.53 倍の高速化を達成する。モデルサイズが大きくノード数が多いほど（例: 70B / 4 ノード、13B / 12 ノード）、FaaScale の優位性が拡大する。これはバイノミアルパイプラインによるモデルのブロック分割とクラスタ帯域全体の活用によるものである。 ### スループット性能（論文 Figure 8） 高負荷下での k 値ごとのスループットスケーリング能力を測定。FaaScale は部分ロード済みのモデルブロックから実行パイプラインを形成して即座にサービスを開始できるため、全ベースラインを一貫して上回り、ピークスループットに大幅に速く到達する。Llama-2 7B で k=1 の場合、FaaScale は約 0.6 秒でスケーリングを開始し、k=4 では約 0.15 秒で開始する。ベースラインはモデルレプリカの完全な複製完了を待つ必要がある。 ### レイテンシ性能（論文 Figure 9） TTFT の P90 レイテンシと CDF を測定。FaaScale は 1.1 秒で全 50 リクエストのサービスを開始し、FaaSNet の 2 倍、NCCL の 1.4 倍、ServerlessLLM の 8 倍高速である。ServerlessLLM-SSD は SSD I/O の遅さとオンデマンドロード中の推論実行遅延により、長いテイルレイテンシを示す。 ### 実環境ワークロード（BurstGPT トレース）での評価（論文 Figure 10, 11、スライド p.14） Azure OpenAI GPT サービスの実トレースである BurstGPT を用いた 30 分間のバースト性ワークロードで評価。 **スケーリング挙動（Figure 10）**: FaaScale はリクエストスパイクへの応答として他の全システムより迅速にスケールアウトし、スケールイン時も迅速に GPU リソースを解放する。3 つのベースラインは全てスケールアウト・スケールインの双方で遅延が発生する。 **コスト効率**: FaaScale は FaaSNet に対して最大 17.8%、NCCL に対して最大 18.1%、ServerlessLLM に対して最大 31.3% の GPU リソース削減を達成する。Ideal Scaling（モデルロードオーバーヘッドゼロを仮定した理想ケース）との差は 4.3〜18.6% に留まる。 **TTFT 分布（Figure 11）**: BurstGPT ワークロード下で、FaaScale は 3 モデル全てにおいて全ベースラインを上回る。P90 TTFT レイテンシで 2.4〜5 倍の改善を達成する。NCCL と FaaSNet は SSD からの頻繁なモデルロードによりテイルレイテンシが増大する。ServerlessLLM はキャッシュヒット率が高い場合に CDF が左方シフトするが、キャッシュミス時のフォールバックにより全体性能は FaaScale に劣る。 ## 関連研究 - **パイプライン推論とモデルスケーリング**: 既存のパイプライン推論研究は静的なリソース構成に依拠する。BlitzScale はチェインベースのモデルスケーリングと Prefill/Decoding 分離の実行スケジュールを組み合わせるが、P/D 分離を前提とする。FaaScale はバイノミアルパイプラインによるスケーラブルなマルチキャストを強調し、P/D 分離を仮定しないより汎用的なサーバレス環境を対象とする。DynamoLLM は予測可能性を活用するが、FaaScale はバースト性・予測不能なワークロードを対象とする。Medusa は CUDA グラフと KV キャッシュ状態のマテリアライゼーションによる単一ノード起動オーバーヘッド削減を対象とし、FaaScale の分散クロスノードモデル転送・実行とは相補的である。 - **ネットワーク前提と適用可能性**: FaaScale は高速なクロスモデル転送が最重要となる安定した RDMA 対応ネットワークを持つ現代の AI サービングクラスタを対象とする。コア設計は特定のインターコネクトに紐付かず、低帯域幅・高ジッタのネットワークでも絶対的な改善幅は縮小するが同一の設計が適用可能である。 ## 結論・オープン課題 FaaScale は高速かつ効率的なモデルスケーリングを実現するサーバレス推論システムである。高速 RDMA ネットワークを活用した高速モデルマルチキャストと、モデルマルチキャスト中の協調的クロスノード実行を可能にするパイプライン化マルチキャスト推論戦略を導入する。効率的なモデル管理と組み合わせ、バースト性ワークロードを支え、最先端システムに対してテイルレイテンシを最大 5 倍改善し GPU コストを最大 31.3% 削減する。 オープン課題として以下が挙げられる。 - 高度に不安定なネットワーク条件下でのブロックサイズ b の適応的チューニング（現在はオフラインプロファイリングに依拠） - マルチテナントサービングにおけるモデル間のリソース共有・アドミッション制御との統合（Aegaeon 等との組合せ） - 異種 GPU ノードを持つクラスタへの拡張（Helix 等のヘテロジニアスクラスタスケジューラとの連携） - KV キャッシュ再利用との統合（Mooncake 等のクラスタレベル KV キャッシュプールとの相補的利用）