Metaが遊休GPUを広告レコメンドに再利用する仕組み ― RMA・SBMによるエラスティシティ設計の解説

推論フリートのパラドックス：全体は逼迫、局所はアイドル

大規模なAI推論フリートを運用していると、必ずこの矛盾に直面します。全体のキャパシティはギリギリなのに、特定のリージョン・特定のアクセラレータ・特定の時間帯には遊休リソースが残っている、という状況です。Metaも同じ課題を抱えており、それを広告レコメンドの品質向上に再利用する仕組みを構築しました。

遊休キャパシティが発生する主な原因は次の4つです。

• ピークプロビジョニングとトラフィック変動のミスマッチ： ピーク基準でキャパシティを確保するため、非ピーク時には遊休化します。
• モデル開発とキャパシティ供給のタイミングずれ： ハードウェアはサプライチェーンのスケジュールで到着しますが、モデルは別スケジュールで開発されるため、消費タイミングが合いません。
• リージョンごとのリソース比率のミスマッチ： GPUはあるがCPUが足りない、あるいはその逆でボトルネックが発生します。
• アクセラレータ種別のミスマッチ： ベンダー・世代・アーキテクチャが異なるとワークロードが移植できず、ハードウェアが遊休化します。

本記事の焦点は「この断片化された遊休リソースをいかに安全に活用するか」です。関連して、AIエージェントの一貫性の罠を扱ったPass^kガイドも併せてご参照ください。「たまにうまく動く」システムの危険性が理解しやすくなるはずです。

2つのエラスティシティレバー：RMAとSBM

Metaが対象としたワークロードは、次の構造的特性を満たす必要があります。高いエラスティシティ（オプショナル作業を迅速に増減できること）、スケール時の品質維持、そしてサービス間依存の少なさです。この条件を満たすレバーとして2つが選ばれました。

RMA（Rank More Ads）

ランキング段階で評価する候補広告数を増やすレバーです。候補が増えれば、ユーザーに関連する広告を見つけられる確率が上がります。ただし候補増加は、CPU負荷の高い上流処理（検索・特徴量処理）とアクセラレータ推論の両方を消費します。

# RMAの概念疑似コード：遊休キャパシティに応じて候補数を調整
class RMAController:
    def __init__(self, base_candidates: int, max_candidates: int):
        self.base = base_candidates
        self.max = max_candidates
        self.target = base_candidates

    def update(self, p99_latency_ms: float, sla_ms: float, available_ratio: float):
        # レイテンシに余裕があれば候補を増やし、逼迫していれば減らす
        if p99_latency_ms < sla_ms * 0.9 and available_ratio > 0.3:
            self.target = min(self.max, int(self.target * 1.1))
        elif p99_latency_ms > sla_ms * 0.95:
            self.target = max(self.base, int(self.target * 0.9))
        return self.target

SBM（Serve Better Models）

高性能モデルへルーティングされるリクエストの割合を制御するレバーです。ランキングに投入する広告数は変えないため、上流CPU負荷はほぼ増えず、アクセラレータの余剰分のみを消費できます。RMAが使えないリソースをSBMが使う、という補完関係です。

# SBMルーターの概念：リクエスト価値セグメントごとに高性能モデル適用率を制御
class SBMRouter:
    def __init__(self, target_coverage: float):
        self.target_coverage = target_coverage

    def route(self, request, segment_value: float, current_coverage: float) -> str:
        # 目標カバレッジに満たない場合、価値の高いリクエストから高性能モデルへ
        if current_coverage < self.target_coverage and segment_value > 0.7:
            return "powerful_model"
        return "baseline_model"

両レバーを併用する理由は、消費するリソースの組み合わせが異なるためです。RMAはCPU＋アクセラレータ、SBMはアクセラレータ中心。したがって遊休リソースの構成に応じて配分比率を柔軟に調整します。

安全な運用の設計：アイソレーション、フィードバックループ、ロードシェディング

遊休キャパシティ最大のリスクは予告なく回収され得る点です。Metaの設計原則は明確です。「遊休キャパシティを失ってもオプショナル作業が減るだけで、ベースラインサービングのキャパシティを絶対に圧迫してはならない」。

1) 物理的・論理的アイソレーション

• SBMは物理的アイソレーション： ベースラインモデルと高性能モデルが別々のルーティングターゲットを使用します。遊休キャパシティが縮小すれば高性能モデルへのルーティング比率を下げるだけで、そのリクエストは既にプロビジョニング済みのベースラインモデルへ流れます。
• RMAは論理的アイソレーション： モデルレプリカがベースラインと追加作業を混在で受け持ちますが、グローバル予算で増分作業量の総量を制限します。物理的分離ではなく「予算上限」でアイソレーションを達成する方式です。

2) ワークロード別フィードバックループ

• RMA： 中央PIDコントローラがテールレイテンシを観測してランキングへ送る広告数の目標を算出し、クライアントが適用します。
• SBM： 中央コントローラが高性能モデルのカバレッジ目標を設定し、クライアント側ルーターがセグメントごとにexplore-and-exploitで増分効果を測定して配分を更新します。絶対的なリクエスト価値と増分効果は必ずしも一致しないため、このプロセスが不可欠です。

3) 多層ロードシェディング

中央コントローラは分単位で動作しますが、プリエンプションはミリ秒単位で発生します。そのため2段階の即時対応を備えます。

• サーバー側シェディング： 遊休プールが縮小すると、サーバーが即座に低価値のオプショナル作業を除去します。
• クライアント側シェディング： クライアントがサーバー状態を直接観測し、過負荷の兆候があれば自らオプショナル作業を削減します。

いずれも価値シグナルに基づいて除去対象を選ぶため、遷移期間の品質劣化を最小化できます。

注意点と限界

• ワークロード適合性： 本パターンは「オプショナル作業を増やすほど品質が向上し続ける」ワークロードにのみ有効です。線形に品質が伸びないシステムでは過剰投資となります。
• 制御ループの遅延： 中央制御が分単位である以上、急激な回収にはローカルシェディングが必須です。シェディングポリシーがなければベースラインSLAが破綻し得ます。
• 測定の複雑さ： SBMのexplore-and-exploitは継続的な実験トラフィックを要求します。実験基盤を持たない組織ではここがボトルネックになります。

実務適用に向けたまとめ

Metaの事例から持ち帰るべき要点は3つです。

1. **遊休リソースは「捨てるコスト」ではなく「オプショナル作業の燃料」**です。ただし、オプショナル作業の品質曲線が右上がりになるワークロードを選ぶ必要があります。
2. アイソレーション戦略を先に決めてください。 物理的分離が可能なワークロード（SBM型）と、予算上限でアイソレーションすべきワークロード（RMA型）を区別することが設計の出発点です。
3. 中央制御とローカルシェディングを必ず二重化してください。 プリエンプションはコントローラより速く発生します。

国内環境では特にマルチクラウド／オンプレミス混在インフラでこのパターンが有効です。リージョンごとにGPU世代が混在している場合、SBMのように「アクセラレータのみを追加消費する」レバーの方がRMAより安全な第一歩になります。ただし国内のSI案件では実験基盤（explore-and-exploit用のトラフィック分割）が不足しているケースが多いため、SBM導入前にA/B基盤の整備状況を確認することをお勧めします。

次のステップとしてはprecomputation elasticity（リクエスト時点より前に事前計算する方式）を検討してください。リアルタイムトラフィックの位置・タイミング制約から比較的自由なため、バッチ性ワークロードが多い組織にとってより現実的な第一歩となり得ます。

根拠資料: Meta Engineering - Turning opportunistic AI inference capacity into better ads recommendations

併せて読みたい記事

• MetaがAV1をRTCに導入した理由と3年間の試行錯誤
• AIエージェントが昨日できたことが今日できない理由、Pass^kで見る一貫性の罠