powered by TechFeed
表示モード
Deep Dive

Perplexityが検索AIの内部構造を公開 — GPU効率を最大化する三層アーキテクチャ「Ivy・Tulip・ROSE」の設計思想

9月5日、RuntimeWireが「Perplexity publishes its three-layer stack for search embeddings and ranking」と題した記事を公開した。Perplexityが9月4日のXスレッドで、検索プロダクトの中核を担う三層構造のサービングスタックを公開した。Ivy・Tulip・ROSEと名付けられた各層は、リクエスト準備・バッチスケジューリング・GPU実行のそれぞれを互いに干渉させず分離することで、レイテンシとスループットを両立させる設計だ。GPU時間は高コストであり、モデルを効率よくGPUに乗せるまでの前処理が全体のボトルネックになりやすい。これはLLMサービングに限らず、埋め込みモデルの運用でも共通の課題だ。Perplexityはこの問題を三層分離によって解決しようとしている。

9月5日、RuntimeWireが「Perplexity publishes its three-layer stack for search embeddings and ranking」と題した記事を公開した。Perplexityが9月4日のXスレッドで、検索プロダクトの中核を担う三層構造のサービングスタックを公開した。Ivy・Tulip・ROSEと名付けられた各層は、リクエスト準備・バッチスケジューリング・GPU実行のそれぞれを互いに干渉させず分離することで、レイテンシとスループットを両立させる設計だ。

GPU時間は高コストであり、モデルを効率よくGPUに乗せるまでの前処理が全体のボトルネックになりやすい。これはLLMサービングに限らず、埋め込みモデルの運用でも共通の課題だ。Perplexityはこの問題を三層分離によって解決しようとしている。


三層の役割分担

IvyはRust製のHTTPゲートウェイだ。受信リクエストのパース、テキストのトークナイズ、テンプレート適用、大きすぎるバッチの分割を担い、処理結果をgRPC経由でTulipに渡す。CPU寄りの前処理をGPU側のコンポーネントから切り離すことで、リクエストフォーマットやトークナイズの変更がGPU側に波及しない構造になっている。

Tulipも同じくRust製のgRPCサーバーで、リクエストを集約してGPU向けのバッチを組む役割を担う。ここで重要なのが、Perplexityが「小さな埋め込みモデルの実行時間はクエリ数よりもトークン数に依存する」と明記している点だ。スレッドによると、約512トークンでGPUを十分に埋められるという。

つまり、個々のクエリが短くても複数のリクエストをまとめてトークン数を稼ぐことで、GPUを遊ばせずに済む。Tulipはバッチが溜まるのを待ちすぎることによるレイテンシ増加と、バッチが小さすぎることによるGPU効率低下というトレードオフを管理する役割を果たしている。

ROSEはPython製のモデルエンジンで、モデルのフォワードパスを担う。注目すべき実装の詳細として、Perplexityは以下を公開している。

  • LLM(大規模言語モデル)と埋め込みモデルで同一のカーネルを再利用
  • 埋め込み処理ではオートリグレッシブ生成で使うKVキャッシュを使わず、Ragged Attention(バッチ内のシーケンス長がまちまちでも処理できるアテンション実装)を採用
  • モデルの形状やシーケンス長に応じてアテンションバックエンドを動的に切り替える

CPU先行パイプラインの鍵:CUDAグラフとLazyTensors

Perplexityがこの設計で特に力を入れているのが、CPUがGPUの先を走り続けるパイプラインの実現だ。

ROSEはCUDAグラフを使い、一連のGPU操作を記録して単一の呼び出しで起動できるようにする。埋め込みモデルのような小さなモデルでは1回の推論が短時間で完了するため、CPU側のカーネル起動オーバーヘッドが相対的に目立ちやすい。CUDAグラフはその繰り返しコストを削減する。

もう一つの仕組みがLazyTensorsだ。GPUが現在のバッチを処理している間に、CPUは次のバッチの準備を非同期で進める。リクエスト処理・バッチ組み立て・モデル実行を直列ではなくオーバーラップさせることで、ジョブ間のアイドル時間を削るのが狙いだ。

Perplexityはこの組み合わせが「オンライン・バッチ両方の埋め込みワークロードでレイテンシとスループットを改善しつつ、既製のサービングシステムより安価」と主張している。ただし、具体的なベンチマーク数値は公開していない。スレッドにはレイテンシ値・RPS・GPU使用率・フリートサイズ・クエリ単価のいずれも記載されていないため、改善幅を外部から検証することはできない。

参考として、Perplexityが別途公開した検索アーキテクチャの技術資料では、本番インフラが1日2億クエリを処理しており、AWS us-east-1からのSearch APIの中央値レイテンシは358ミリ秒と報告されている。ただしこれはIvy・Tulip・ROSEに帰属する数値ではなく、検索システム全体の指標だ。


ROSEはすでに埋め込みの外側で動いている

ROSEは今回の公開で初登場したわけではない。5月6日に公開されたPerplexity AI Inferenceチームの技術ブログによると、ROSEはもともとカスタマイズ版Llamaモデルの言語デコードと分類タスクのために構築されたエンジンだ。

現在はランキング・分類・スコアリング・埋め込み・LLMワークロードを横断して担い、NvidiaのHopperおよびBlackwell GPU上でカスタムモデルをホスティングしている。PerplexityのSonar・Search・Embeddings APIの背後にも同じエンジンが動いている。

PerplexityはEmbeddings APIを外部開発者向けにも提供しており、0.6Bパラメータと4Bパラメータのスケールでモデルを提供している。ただし今回のスレッドでは、Ivy・Tulip・ROSEのどの部分が外部API向けトラフィックを処理しているかや、コンシューマー向け検索プロダクトで使われているモデルの詳細は明かされていない。


競合環境と公開の意図

検索インフラ自体がプロダクトカテゴリとして成立しつつある。Exaは5月に2億5000万ドルのシリーズCを発表(バリュエーション22億ドル)、Tavilyは2025年8月に2500万ドルのシリーズAを調達している。

アーキテクチャの公開には、技術的な透明性に加えて開発者向けビジネスの側面もある。Embeddings APIを使う開発者は、エンドポイントの裏側にある推論インフラを信頼する必要がある。ゲートウェイ・スケジューラ・エンジンの名前と役割を明示することは、その信頼の根拠を提供する意味を持つ。


詳細はPerplexity publishes its three-layer stack for search embeddings and rankingを参照していただきたい。