長文・画像検索をTPUで高速化、vLLMの埋め込み推論は何が変わったか｜2026年8月27日版
Google Cloudは2026年8月26日、オープンソースの推論エンジン「vLLM」でCloud TPUを使い、長文・画像対応の埋め込みモデルを運用するための技術を公開しました。
核心は、15,000トークンを超える入力を分割処理しながら、検索に使うベクトルの精度を維持できるようにしたことです。社内文書検索やマルチモーダルRAGを構築するチームにとって、GPU以外の推論基盤を現実的に比較できる材料が増えました。
今日押さえたい点は次の4つです。
- Qwen3-Embedding-8Bなどの埋め込みモデルを、vLLM経由でCloud TPUに展開できる
- 長い入力を分割する「Chunked Prefill」に、状態を引き継ぐStepPoolを組み合わせた
- TPUと参照環境の出力をコサイン類似度で比較し、ハードウェア変更によるずれを検証した
- GKEでTPUとGPUの調達優先順位を設定し、空き状況に応じた構成を取りやすくした
今回の更新が重要な理由
埋め込みモデルは、文章や画像を意味の近さで比較できる数値ベクトルへ変換します。生成AIが回答を書く前に、関連する社内文書や商品画像を探すRAGでは、この処理が検索品質を左右します。
試作段階なら、短い文章を少量処理するだけでも動きます。しかし本番環境では、長い契約書、図表を含む資料、大量の商品データが同時に届きます。そこで問題になるのが、アクセラレーターのメモリ、初回コンパイルの遅延、負荷変動への対応です。
今回の発表は新しい基盤モデルの公開ではありません。既存の埋め込みモデルを長い入力と大量リクエストに耐えさせる、推論基盤側の更新です。
長文処理を支える3つの仕組み
Google CloudとvLLMコミュニティは、TPU固有の制約に合わせて複数の改良を加えました。
テンソルの形をTPUに合わせる
モデルを複数のTPUチップに分割すると、語彙行列などのサイズがハードウェアの分割条件に合わない場合があります。そのままでは、各チップの計算結果を集約する際に不整合が起きます。
今回導入されたのは、行列へ安全に余白を加えてサイズをそろえる方法です。モデルの意味的な出力を変えず、テンソル並列処理で扱える形に整えます。
JAX/XLAのコンパイルを事前に済ませる
TPUでは、JAX/XLAが計算グラフをコンパイルして実行します。実際のリクエスト到着後にコンパイルが始まると、最初の処理が遅れたり、複数プロセスで予期しない停止が起きたりする可能性があります。
そこで、モデルの分割方法を考慮した事前ウォームアップを実施し、推論開始前にコンパイルキャッシュを準備します。遅延のばらつきを抑え、デプロイ直後の動作を安定させるための変更です。
StepPoolで分割前後の状態を保持する
長い入力を一度に計算すると、TPUのHBMを使い切る恐れがあります。Chunked Prefillは入力を複数の塊に分け、このメモリ負荷を抑える仕組みです。
ただし埋め込み処理では、各チャンクから得た情報を最後に一つのベクトルへ集約しなければなりません。途中の状態が失われると、分割処理は完了しても正しい埋め込みを生成できません。
新しいハイブリッドStepPoolは、集約途中の状態をCachedRequestStateに保持します。リクエストが一時中断された場合も状態を引き継ぎ、後続チャンクの結果を積み上げられる設計です。
ここがポイント: 長文対応の本質は、単に入力を小分けにすることではありません。分割した計算の状態を最後まで正しく保持し、一貫した検索ベクトルへ戻すことにあります。
TPUに変えても検索結果は同じか
埋め込みモデルでは、生成文章の自然さではなく、ベクトル間の距離が検索順位を決めます。わずかな数値差でも、類似度が接近した文書の順位を入れ替える可能性があります。
Google CloudはTPUの出力と参照環境の出力を比較し、コサイン類似度による合格基準を次のように設定しました。
- テキスト入力：0.999以上
- テキストと画像を含むマルチモーダル入力：0.995以上
1に近いほど、両環境が生成したベクトルの向きが一致します。公開記事では、Qwen3-Embedding-8BとQwen3-VL-Embedding-8Bについて、この基準を満たす数値的一致を確認したと説明しています。
また、Qwen3-Embedding-8BをTPU Ironwoodで動かした検証では、BF16、16,000トークン超、テンソル並列数4の条件で、合計毎秒83,996トークン、毎秒5.13リクエストと報告されました。
ただし、これはGoogle Cloudが示した特定条件での結果です。実際の性能は入力長、バッチ構成、TPUの種類、前後の検索処理によって変わるため、導入判断には自社データによる再計測が必要です。
GKEでTPUとGPUを使い分ける
推論エンジンをvLLMにそろえる利点は、アプリケーション側から見た実行方法を共通化しやすいことです。Cloud TPUを使う場合も、runner="pooling"を指定して埋め込みを取得できます。
Google Kubernetes Engine（GKE）のCustom Compute Classesを使うと、アクセラレーターの優先順位を定義できます。たとえば、予約したTPUを優先し、利用できないときはGPUのSpotまたはオンデマンド枠へ切り替える構成が可能です。
これは「TPUとGPUを常に同じ性能で置き換えられる」という意味ではありません。モデル対応、精度、起動時間、スループットを各環境で確認したうえで、容量不足時の退避先を設計できるということです。
日本の開発チームが確認すべきこと
今回の技術は、社内検索、ECの商品検索、画像を含むナレッジベースなどで選択肢になります。特に長文を細かく切り刻まずに検索対象へ含めたいチームは、検証する価値があります。
開発者
- 利用モデルがvLLM-TPUの対象になっているか確認する
- 実データの入力長に合わせて
max_model_lenとバッチ数を調整する - TPUと現在のGPU環境で、検索上位件数や順位の差を測る
- 初回起動だけでなく、負荷上昇時と切り替え時の遅延も記録する
企業のAI基盤担当者
- アクセラレーター料金だけでなく、待機時間や最低稼働単位を含めて比較する
- TPUからGPUへ切り替わった際も、同じ品質基準を満たすか監視する
- 本番データを使った再現率、適合率、誤検索率を継続的に確認する
- 公開レシピをそのまま本番投入せず、認証、ネットワーク、ログ管理を追加する
継続ウォッチ
次に見るべきなのは、対応モデルの数よりも本番運用の再現性です。
- 15,000トークン超の入力が混在した場合の末尾遅延
- TPUとGPUをまたぐ切り替え時のベクトル互換性
- StepPool利用時の同時実行数とHBM消費量
- 日本語文書や図表を含む資料での検索順位
- TPU Ironwoodを利用できる地域、割り当て方法、実運用コスト
今回の公開で、TPUは生成モデルだけでなく、RAGの入口を担う埋め込み推論でも比較対象になりました。導入時は公表されたトークン処理量だけを見るのではなく、同じ検索結果を維持できるかを自社の日本語データで確かめることが最初の実務になります。