MetaがF3 Lightningで広告向けML特徴量の本番投入を約3.6倍高速化

発表内容

MetaのEngineeringブログは、F3 Lightningを紹介しました。F3は「Facebook Feature Framework」で、広告ランキングモデルを支える機械学習特徴量の記述、コンパイル、配信を行う枠組みです。1回のリクエストで20,000を超える特徴量が必要になる場合があるとされます。F3は2020年の「AI @ Scale」で初めて発表されました。

F3は全特徴量を単一のマージ済みグラフにコンパイルすることで、実行の計算コストを削減しました。しかしそのグラフ自体がリリース単位でもあったため、1つの障害や不正な定義がリリースパイプライン全体を止めます。F3 Lightningは、特徴量のリリースを共有実行から分離するインフラ層です。各特徴量を独立にコンパイル、検証、配備、ロールバックできるようにします。

F3の共有実行と課題

F3は特徴量抽出をDAGとして表現します。各ノードは入力読み取り、フィルタ、集計などの単位処理を行い、辺は処理同士の依存関係を表します。エンジニアは特徴量を個別の高水準言語で書き、コンパイラが各定義を小さなグラフに変換した後、サービスが使う全特徴量のグラフを1つにマージします。共有される処理は重複を畳み込まれ、リクエストごとに1回だけ実行されます。

このマージ済みグラフは計算効率に優れる一方、グラフ全体がリリース単位でもありました。原文では7つの特徴量A〜GのうちDとGに無関係な誤りがある例で、Dを直してもGで失敗し、両方を直すまで7つすべてが出荷できないと説明されています。F3が扱う特徴量は数百から20,000超に増え、特徴量の種類ごとに必要な検証も異なります。既存モデルが使う特徴量には高コストなモデル関連テストが必要で、それが後工程まで全体を待たせる要因になっていました。

独立リリースと効率維持

F3 Lightningの第一の変更は配備の粒度です。コンパイラは各特徴量を単独の設定としてコンパイルし、その特徴量に必要なノードを順序付きで含めます。ある特徴量に問題があっても、関係のない別の特徴量はリリースできます。リリース経路は一括配備ではなく順序付きキューになり、未使用の新特徴量は標準検証で早く出し、既存モデルが読む変更には追加テストを課す運用が可能になります。

ただし初期の試作では、独立配備にしたことで共有実行が失われ、CPU使用量が大きく増えました。そこでF3 Lightningは、計算の意味から識別子を導く仕組み、全特徴量をまたぎトポロジカルソートで依存順に並べた単一の実行計画、リクエストごとの共有メモリバッファ、識別子を連続した配列位置に変換する密インデックスを導入しました。これにより、同じ計算を1回だけ実行しつつ、実行時の参照を直接配列アクセスに近づけています。

成果と注意点

F3 Lightningでは、比較可能な抽出特徴量が従来のF3より約3.6倍速く本番に到達し、インフラの計算コストは増えないと報告されています。リリースサイクルが短くなれば、同じ期間により多くのモデル反復や再学習を行いやすくなります。これは特徴量の更新頻度がモデル改善の速度に影響する広告ランキングのような領域で意味を持つ数字です。

実行時には、ある計算が失敗したり入力が得られなかったりすると、その下流だけが「未準備」とされ、独立した別の枝は処理を続けます。つまり障害の影響は依存関係の範囲に限定されます。一方、原文では3.6倍の測定条件の詳細や、Metaのどのサービスにどの程度展開済みか、モデル品質への影響までは示されていません。効果の範囲を判断するには、今後の適用範囲や運用指標の公開を待つ必要があります。