- SilverTorch を導入します, ユーザー生成コンテンツのすべての検索コンポーネントを統一されたアーキテクチャの下で統合するレコメンデーション システムの再考.
- シルバートーチのショー 最先端のアプローチと比較して最大 23.7 倍高いスループット. また、CPU ベースのソリューションと比較して、計算コスト効率が 20.9 倍高く、精度も向上しています。.
- 私たちの研究論文, 「シルバートーチ: GPU 上で大規模なレコメンデーションを民主化するための統合モデルベース システム,」が SIGIR のフルペーパートラックに受理されました 2026, 完全な技術的な詳細が含まれています.
業界推奨システム内の検索システムは、マイクロサービスをつなぎ合わせて構成されています, ニューラルネットワークが一貫して統合されていない. 私たちの推奨事項は、複数のプラットフォームにわたって人々にサービスを提供できるように拡張できます. 検索は数百万のコンテンツからの絞り込みを担当します (例えば, リールと写真) ランキング システムに渡す前に、数千にまでダウンします, すべて未満で 100 ミリ秒.
しかし, マイクロサービスベースの設計には、モデルの複雑さと評価される候補の数に厳しい制約がありました。, 最終的には、プラットフォーム上の人々が見るレコメンデーションの品質に上限を設けることになる.
この天井を突破するには, 私たちは検索エコシステムを統合モデルベースのシステムに完全に再考しました – シルバートーチ.
SilverTorch は、私たちが呼ぶ新しいパラダイムの下で動作します。 モデルとしてのインデックス. 私たちは検索システムを単一のニューラル ネットワークとして構築し、この統合ニューラル ネットワーク内のモデル モジュールとしてさまざまなマイクロサービスを表現しています。. Index as Model では、取得に使用された以前のマイクロサービスベースの項目インデックスがモデル内のテンソルになります。. As a user opens up their app, one request flows through a SilverTorch model, completes all critical retrieval functions (ユーザーの興味に似たアイテムを検索する, filtering for eligibility, 複数のユーザーエンゲージメントアクションに対するエンゲージメントの可能性を再ランク付けしてスコアリングする), 高品質コンテンツ候補のリストをランキングに返します. この新しい設計により、100 ミリ秒未満のバーを破ることなく、モデリングの複雑さと評価される候補の数を効果的に増やすことができます。.
SilverTorch makes retrieval significantly more efficient, 大規模に実行される, and enables better recommendations.
- より高いスループット, lower total cost of ownership (TCO). In an 80M-item end-to-end evaluation, SilverTorch は、同じモデル アーキテクチャに基づいて構築された強力な従来のマルチサービス ベースラインと比べて、1 秒あたり 23.7 倍のリクエストを処理しました。, 推定 TCO 効率を 20.9 倍向上させながら.
- 大規模に実証済み. 結果は、SilverTorch が、人々が見るフィードやビデオ コンテンツの背後にある主要な検索システムとして、アプリ ファミリ全体に拡張できることを示しています。.
- より良い推奨事項. ニューラルの再ランキングとマルチタスクのスコアリングを、限られたレイテンシーの範囲内で実用化することで、, SilverTorch は、マイクロサービス アーキテクチャ下では現実的ではなかった取得品質の向上を一貫して可能にしてきました。.
マイクロサービス メッシュから 1 つの統合ニューラル ネットワークへの移行
私たちが置き換えたマイクロサービスのパラダイム
従来の推奨事項の取得は、マイクロサービスのメッシュとして構築されます。. ユーザーがソーシャルメディアプラットフォームを開くとき, the request hits an orchestrator, which fans out to a user-tower model service (ユーザーの興味のベクトル表現を計算します, called a “user embedding”), 複合検索サービス (ユーザーベクトルとの類似性と、言語や地理などの適格性ルールに基づいて候補アイテムを検索およびフィルタリングします。), そして採点サービスも (生存者をランク付けする). オーケストレーターは結果をマージして下流に渡します. 各サービスには独自のコードベースがあります, 多くの場合、別のプログラミング言語で, 独自の導入ライフサイクルを持つ.
これはCPU時代にはうまくいきました. しかし、検索システムの規模が拡大し、洗練されるにつれて、, 3 つの問題が複合して構造上の限界となり、コンポーネントレベルの最適化では解決できない:
- データの移動により遅延が失われる. サービス間のホップごとに、ネットワークの往復時間とシリアル化のオーバーヘッドが発生します。, 実際の計算に資金を提供する必要がある 100 ミリ秒未満の取得予算を使い果たしています。. そして、フィルタリングしているため、, 検索, とスコアリングは独立して設計されています, 一緒に最適化することはできません.
- バージョンの不一致. ユーザータワーモデル, アイテムインデックス, フィルタリング ルールはそれぞれ独自のペースで更新されます. ユーザー モデルは v2 で出荷されるが、項目インデックスはまだ v1 である場合, システムは、v2 ユーザー表現を使用して v1 エンベディングをクエリします。品質ギャップが生じ、下流のランキングでは回復できません。.
- サイロ化された開発環境. 機械学習 (ML) エンジニアが PyTorch を書く. インフラストラクチャ エンジニアは C++ を作成します. 異なるリリースサイクル, さまざまなテスト設定, さまざまなメンタルモデル. 検索を改善するには、アイデアを 2 つの環境間で変換する必要があります (1 サイクルあたり数週間または数か月).
Component-level optimizations like Faiss-GPU help by making the specific microservice faster, しかし、根底にある構造的限界は解決されません. アーキテクチャは依然としてサービスのシステムであり、サービス間でアーティファクトが受け渡されます。.
ザ・シフト: All Components Are Model Modules
SilverTorch はパラダイムを根本から再考します. マイクロサービス システムを設計してそこにニューラル ネットワークを挿入するのではなく, ニューラルネットワークから始めて外側に向けて設計します. We call this Index as Model: Every retrieval component — the item index, 資格フィルター, スコアリング レイヤーとユーザー タワー — 単一の PyTorch モデル内のテンソルまたは演算子になります. That means one artifact to deploy, 実行する 1 つのフォワード パスと、システム内の内容に関する 1 つの信頼できる情報源.
モデルの内部
![写真[1]-シルバートーチ: モデルとしてのインデックス — Windows 7、8、10、11 用の推奨システムの新しい検索パラダイム - Winpcsoft.com](https://winpcsoft.com/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
この単一のニューラルネットワークの内部, ネットワークの異なる領域は異なるジョブを処理します. 近似最近隣 (アン) 検索 地域は、カタログ内のすべてのアイテムをチェックすることなく、ユーザーの興味に最も近いアイテムを見つけます (本を上手に整理している司書がすべての棚を見て回るわけではない). 資格のフィルタリング 地域は各候補の表示が許可されていることを確認します: 正しい言語, 正しい国, 適切なコンテンツポリシー. マルチタスクの再ランキング 地域は複数のエンゲージメントアクションの可能性を予測します (のように, 共有, コメント) すぐに, それからそれらを組み合わせて、 複合スコア. 一部の地域はエンジニアによって手書きされています; 他の人はバックプロパゲーションを通じてエンドツーエンドでトレーニングされます. ランタイムの観点から見ると, それらはすべて nn.Module (PyTorch の標準構成ブロック) であり、互いに区別できません。.
再設計: あらゆるステージに対応した純粋な PyTorch モジュール
各コンポーネントの以前の動作方法
シルバートーチ以前, 実稼働検索パイプライン内のすべてのモジュール — ANN 検索, 資格フィルタリング, ニューラル・リランキング, 複合スコアリング — よく知られた古典的な実装がありました, ほとんどの場合、C++ でスタンドアロン サービスとして構築されています.
| モジュール | 古典的な実装 | どこで実行されるか |
|---|---|---|
| ANN検索 | フェイス | CPUとGPUのバージョン |
| 資格のフィルタリング | 転置インデックス | CPUとGPUのバージョン |
| ニューラルの再ランキング | スタンドアロンの初期段階ランキング サービス | CPUとGPUのバージョン |
| 複合スコアリング | ルールベースの集計 | CPUのみ |
これらの実装は成熟しており、実戦テストが行われています, ただし、それぞれは独自のデータ構造を持つスタンドアロン サービスです, メモリ, と実行モデル. それらを連鎖させることができます — ANN を実行します, 次に、その出力をフィルタリングに渡しますが、簡単に実装することはできません モジュール間の最適化 例: 「最初に最も有望なクラスターを選択する」, それらのクラスタ内のみをフィルタリングする, その後、生存者だけを得点します。」このレベルの共同設計では、モジュールがメモリを共有する必要があります, 実行グラフ, そしてコンパイルステップ.
Pure PyTorch の決定
その共同設計を可能にするために, すべてのモジュールを再実装することを決定しました。 純粋な PyTorch. このパラダイムの下では:
- すべてのデータはテンソルとして表現されます.
- すべてのロジックはテンソルインです, テンソルアウト.
- すべてのモジュールは、PyTorch の標準インターフェイスに準拠した nn.Module です。.
- 実行時, ANN および ブルーム インデックス フィルター モジュールは、トレーニングされた ML リランカーと区別できません。両方とも nn.Module です。, どちらもテンソルを取り込み、テンソルを生成します.
With every module as an nn.Module, ML エンジニアリングとインフラストラクチャ エンジニアリングの境界はなくなり、同じレイヤーに存在します, 単一の PyTorch トレーニング スクリプトで自由に構成され、共同で最適化されます。. システム全体が 1 つの PyTorch モデルに集約されるため、, 私たちは、PyTorch モデルの高速化に関する広範な AI 業界の取り組みから恩恵を受けることができます, PyTorch モデルをより効率的な GPU カーネル コードに自動的に書き換える PyTorch 独自の torch.compile のような. そのエコシステムが進歩するたびに、SilverTorch のサービス パフォーマンスが向上します.
純粋な PyTorch の決定は、CPU 時代の取得コンポーネントを取得して nn.Module でラップするという意味ではありませんでした。. そのため、GPU 実行とモデル グラフ自体に固有の形式で取得プリミティブを再考する必要がありました。. ブルーム インデックス フィルターと融合 Int8 ANN 検索の 2 つの例. どちらの場合も, 利益は古いサービスを PyTorch に移植することで得られるものではありません, ただし、GPU メモリの動作に関する基礎となるアルゴリズムの再設計によるものです。, テンソルレイアウト, 同じフォワードパス内での実行. それが SilverTorch の基本的なプレイブックです: 取得コンポーネントが 1 つの PyTorch モデル内に存在すると、, 共同設計が可能になる, そしてその共同設計が利益を生み出すのです.
ブルーム インデックス フィルターは、SilverTorch が GPU の取得をどのように再設計するかの一例です。. 従来のシステムでは, フィルタリングは通常、逆インデックスによって処理されます。, これは CPU では効率的ですが、GPU では適切に実行するのが困難です. 問題は、推奨フィルタリングでは多くのアイテム属性を一度にチェックする必要があることが多いことです。, 言語などの, 位置, または資格規定, また、投稿リストの長さは属性やクエリによって大きく異なる場合があります。, GPU 上でワープ内の負荷の不均衡とワープの発散を引き起こす. 短いリストが割り当てられたスレッドは早期に非アクティブになります, 最長のリストを処理するレーンが完了するまで、ワープは占有されたままになります。.
SilverTorch は、これをモデル内に直接保存されている Bloom インデックスに置き換えます。. 各アイテムは公開時にコンパクト署名を取得します, サービス提供時に、モデルは単純なビット操作を使用してアイテムがリクエストに一致するかどうかを迅速にチェックできます。. This turns filtering into the kind of dense, parallel work GPUs are good at, フィルター結果はすでにモデル内にあるため、, 別のサービス呼び出しを行わずに、ANN 検索に直接移行できます。.
Fused Int8 ANN search follows the same idea. 汎用 ANN ライブラリは、近くのアイテムを検索するために構築されています, しかし、レコメンデーション システムには、小規模な最近傍検索以上のものが必要です. 多くの場合、後の段階でより適切な関連性を決定できるように、はるかに大きな候補者のプールを撤回する必要があります。.
SilverTorch は、ANN 検索をモデル自体の一部として再実装します. アイテムの埋め込みをコンパクトな Int8 形式で保存します, これにより、メモリ使用量が通常の約半分に削減されます。 16 ビット, and runs search with a fused GPU kernel. これにより、データの移動が減り、より多くの候補を返すために検索段階が安価になります。, 下流モデルに最適な推奨事項を見つけるためのより多くの余地を与える. 当社の Int8 量子化 ANN 検索では、総当たり検索と比較して品質損失が限定的であると同時に、サービスのパフォーマンスが大幅に向上しています。. より洗練されたレイヤーでより多くの項目をランク付けするための余裕が生まれ、エンドツーエンドの検索精度が向上します。, アルゴリズムは大規模な top-k およびプローブ数をサポートします; 実際に, we observe no retrieval recall loss with 64 プローブとトップ-2048.
Benefits — What Shows Up Outside the System
SilverTorch は 3 次元に沿って具体的な影響を与えます: コスト効率を計算する, 推奨品質, エンジニアリング速度と.
コンピューティングのコスト効率
ANN検索を移動することで, 資格フィルタリング, GPU 上での複合スコアリングと、SilverTorch の共同設計によるそれらの結合, 同じマシン上で 1 秒あたりにはるかに多くのリクエストを処理します. 1 秒あたりのリクエストが増えると、同じワークロードに必要なマシンが少なくなります, マシンが少ないほど、リクエストあたりのコンピューティングコストが低くなります.
以下は、本番環境の取得ワークロードの比較です。 80 百万個のアイテム, 同じレイテンシーバジェットの下で各システムに対して実際の運用トラフィックが再生される:
| メトリック | FAISS-CPU | FAISS-GPU | シルバートーチ |
|---|---|---|---|
| Compute cost efficiency vs. CPU ベースライン | ベースライン | 5.9× | 20.9× (13.35× リランキングあり) |
| 最大上位 k | 無制限 (遅い) | 2,048 | 100何千もの |
| ニューラルの再ランキング | サポートされていません | サポートされていません | サポートされている |
| マルチタスクのスコアリング | サポートされていません | サポートされていません | サポートされている |
SilverTorch の 13.35 倍のリクエストあたりのコストの優位性は、複数のソースから得られます: 融合された Int8 ANN カーネルは Faiss-GPU より 2.2 ～ 14.7 倍高速です; ブルームインデックスは、CPU 逆インデックスよりも 291 ～ 523 倍高速です; プローブとフィルターの共同設計により、フィルターの計算がさらに 30 倍削減されます。. モデル グラフの Int8 量子化により、全精度ベースラインと比較してメモリが半分に削減されます。, leveraging the GPU’s dp4a instructions, with no measurable recall loss.
推奨品質
SilverTorch は、検索をより広範で表現力豊かな事前ランキング段階に変えることで、レコメンデーションの品質を向上させます。. In traditional service-based systems, 通常、取得は比較的狭い ANN 結果セットに制限されます, scored mostly by simple embedding similarity, より充実した関連性モデリングは後期段階のランキングに延期される.
SilverTorch unlocked headroom. ANN検索を続けることで, フィルタリング, and scoring inside one model, ファネルを大幅に広げることができます. 少数の候補者のみを下流に渡すのではなく、, 最終的なランキングの前に、追加の学習された関連性レイヤーを通じて 1 ～ 2 桁多くの候補をもたらすことができます。. これにより、検索がレコメンデーションの品質に大きく貢献します, not just a fast pruning step.
ニューラルの再ランキング. SilverTorch は、ドット積の類似性を超え、より豊富なユーザーとアイテムの相互作用モデリングをはるかに大きな候補セットに適用する、ニューラル ネットワーク ベースの再ランキング レイヤーを導入しています。. これらの層は多層パーセプトロンの形を取ることができます, 積み重ねられた自意識, ロジットの混合など、より構造化された相互作用モデル. アイテム表現とクロスフィーチャは GPU メモリに残り、同じモデル内で実行されるため, SilverTorch は、パイプラインの早い段階でこれらのより洗練されたランキング レイヤーを適用する余裕があります。, 従来の検索システムが通常実行できるよりもはるかに多くの候補を検索できる.
マルチタスクのスコアリング. SilverTorch は、ネイティブに多目的の検索も可能にします. スコアリング レイヤーは、さまざまなユーザー アクションの予測を単一の複合スコアに結合します。, そのため、検索は 1 つの粗い類似性信号を中心に最適化されなくなりました。. その代わり, 後期段階のランキングが始まる前に、ユーザーエンゲージメントのより豊富な概念に照らして幅広い候補者プールを評価できます. その結果、ファネルがより広くなり、その中により多くのインテリジェンスが含まれるようになり、より多くの候補者が早期の検索で生き残ることができます。, and they are screened by more sophisticated, 最終ランキングに移る前に複数の目的でスコアリング.
エンジニアリングの速度
最後に, SilverTorch により、チームが検索の改善を迅速に構築して出荷できるようになります。. パイプライン全体が 1 つの PyTorch コードベースに存在するため、, 新しい検索のアイデアに取り組んでいるエンジニアは、PyTorch だけを作成します。. 研究ノートからアルゴリズムを C++ サービスに変換する必要はもうありません, 別のインフラストラクチャチームと調整する, 数週間にわたる統合サイクルを実行します. 新しいイノベーションを構築して公開するのに必要な時間が、数週間から数日に短縮されました.
規模と鮮度を追求したエンジニアリング
SilverTorch は、大規模なレコメンデーション システムをサポートし、新しく作成されたコンテンツをほぼリアルタイムで配信できるように、スケーラビリティとインデックスの鮮度を念頭に置いて設計されています。.
スケールアップとスケールアウト
私たちの戦略は、 まずはスケールアップする. メモリ階層を慎重に調整することで、単一の高性能 GPU を最大限に活用します。 (オンチップSRAM, GPU 常駐 HBM, ホストDRAM, リモートDRAM) データは計算される場所の近くに存在するため、. 単一の GPU を最大化したら, 私たちは ホスト内でスケールアウトする, 同じマシン上の GPU カード間の高帯域幅相互接続を利用する.
ニューラル ネットワークが単一ホストの容量を超えた場合, 私たちは使用します ドキュメントのシャーディング: アイテムの在庫を分割する (ビデオ, 投稿, 写真) ホスト間で, 大規模な図書館のカタログを複数の支店に分割するなど.
モデル内の非常に大規模なスパース ネットワーク (すべての項目とすべてのユーザー特徴を学習済みベクトルにマッピングするテーブルを埋め込む) の場合、次を使用します。 トーチレック, スパーステーブルシャーディング用の PyTorch ライブラリ. TorchRec はこれらのテーブルを HBM 全体に分散します, GPUホストDRAM, さらにはリモート CPU ホスト DRAM, スパースなデータの移動を計算から切り離す.
インデックスの鮮度
モデルモジュールとしてインデックスを使用, インデックスの鮮度を維持することは、運用環境でニューラル ネットワークのモデルの重みを更新することに相当します。, 大規模に, モデルをオフラインにせずに.
SilverTorch は、フルモデルの公開サイクルから鮮度を切り離します。 ストリーミングアップデート. モデルパラメータが最新のトレーニングに基づいて更新されると、, 完全なモデルを完全なスナップショットとして定期的に公開します. パブリッシュ間, 継続的なストリーミング サービスがリアルタイムの信号を読み取る - 新しいアイテム, 更新されたエンゲージメント機能, 適格性の変更 — 対象を絞った更新をインメモリ モデル内の特定のテンソルにインプレースで適用します. サービスの提供を中断したり、モデルを再デプロイしたりすることなく、ランドを更新します。.
結果は、推奨コンテンツの最新性に表示されます. 以前のシステムと比較して、ソーシャル メディア プラットフォーム上のレコメンデーションのかなりの部分を同日の投稿が占めるようになりました。.
SilverTorch の進化と今後の展開
SilverTorch は、ニューラル ネットワークがボルトで組み込まれたマイクロサービス システムから、完全なモデルベースの推奨事項の取得までの道のりです。. 振り返ってみると 2 つのことが際立っています: 完全なモデルベースの検索は実稼働規模で実行可能かつ効率的です — アーキテクチャはインフラストラクチャとモデリングの間の壁を打ち破ります, そしてそれらは一つの統一された実践となる. また、ユーザーエクスペリエンスも向上します — マルチタスク スコアリングやニューラル リランキングなど、以前のシステムではレイテンシー バジェット内で実行できなかった機能.
技術的な作業は 3 つの段階を経ました: まず私たちが 再現された すべてのベースライン取得モジュール — ANN, フィルタリング, スコアリング — PyTorch で. このステップだけで、高速 GPU メモリとデータ移動の削減によるメリットが得られました。. そのとき私たちは 考え直した PyTorch ネイティブの各モジュール, GPUネイティブの方法. これが、SilverTorch の Int8 ANN と Bloom インデックス フィルターの融合の由来です。, 単独で使用するのではなく、構成するように設計されています. ついに, 選択した手書きモジュールに対して逆方向伝播を有効にしました。 訓練された モデルの残りの部分と共同して.
将来に向けて
Index-as-Model は次世代のレコメンデーション システムに最適なパラダイムです, さまざまなアプリのメタ内で広く採用されています. レコメンデーション システムに大規模な言語モデルが組み込まれることが増えているため、 (LLM) ユーザーの意図とコンテンツのセマンティクスを理解するため, SilverTorch のアーキテクチャは自然な統合ポイントを提供します:
- LLM は、単なる別のモジュールとして SilverTorch に接続できます。システムは LLM を他のコンポーネントと同様に扱います。.
- LLM ベースのアイテム生成と SilverTorch のフィルタリングは、同じ GPU 並列パターンを使用します.
- アイテムの知識は、同じストリーミング インフラストラクチャを通じてリアルタイムで更新できます.
- LLM と従来のスコアリングは同じ GPU メモリを共有します。サービス間でのデータの移動はありません。.
要するに, SilverTorch を使用すると、LLM 機能を検索モデル内に直接統合できます。, 並行して配置される別のサービスとしてそれらを調整するのではなく、. このより緊密な結合により、LLM を活用したレコメンデーションが実稼働規模で実行できるシステムの上限が引き上げられます。.
論文を読む
技術的な詳細については, SIGIR で完全な研究論文として受理された私たちの論文をご覧ください。 2026: 「シルバートーチ: GPU 上で大規模なレコメンデーションを民主化するための統合モデルベース システム.」
謝辞
このシステムを実現するために協力してくれた Meta 全体の次の個人とパートナー チームに感謝します。.
ライアン・チャン, 鄧宜傑, フェイ・ディン, エリック・ドン, ファンデュオ, ジェン・ファン, パヴェル・ガルバッキ, ホイ・ゲン, ケビン・グリア, マックス・グー, ケ・ファン, チラーグ・ジャイナ教, アンナ・チョン, エリック・キム, ダクアン, シアル・リー, サム・リン, 劉子琦, マ・イーミン, レイ・マオ, マオ・シャオヘン, ピーター・パーク, ランボ・シー, 方城孫, ジン・ソン, シュオ・タン, ハリー・トラン, アレックス・ワン, バイロン・ワン, 王家州, 梁王, ワン・ウェンティン, 王振, 鄭偉, ホン・ウー, 彭夏, ジュディ・シャン, ビシュエ, ラン・シュエ, チャオヤン, 葉曙光, ホンジャン・イン, ミンユ, ケケ・ザイ, 張銭前, 張瑞, とインジャオ・ジャオ.
ルイ・リー, ワン・チーファン, 王盛志, 王裕博, 王岳明, ジアチー・ザイ, ジョン・エルヘン, RecSys モデリング チーム.
胡信耀, ヤンズン・ファン, ルイ・ジャン, マイニー, 張群秀, チャン・ユーティン, ヤンリー・ジャオ, と RecSys Foundation チーム.
ブルース・デン, コングル・チャン, 郭陸儀, ミン・リー, ヤン・リウ, カイ・レン, ジェリー・チェン・グオチャン, タン・イーミン, ウェイ・ホンハオ, 李裕, 陸正, そしてFacebookチーム.
肉箱, チェン・シェンジエ, ガオ・ミンゼ, アビシェク・クマール, 蘇正宇, ウー・ハオティアン, そしてインスタグラムチーム
シュジアン・ブ, チェンリン・ルー, 王瑞, そしてスレッドチーム.
デン・シーヤン, ルー・ファン, ホンイ・ジア, 馬徐東, 張陸家, AIインフラストラクチャチームと
胡栄栄, 鄭秀一, そしてメタAIチーム.