EmbeddingGemma 2 API：ローカルデプロイとマルチモーダル活用

EmbeddingGemma 2 APIを調べると、まず押さえておきたい違いがあります。Googleがホスティングする埋め込みAPIはGemini Embedding 2であり、EmbeddingGemma 2は主にローカルやエッジ環境で推論するためのオープンモデルです。プライベートなマルチモーダル検索には魅力的ですが、そのぶん、どのサービング基盤を使い、どう運用するかは自分で決める必要があります。

EmbeddingGemma 2はGoogle APIとして利用できるのか

EmbeddingGemma 2は正式にリリースされています。ただし、Googleの現在のマネージドGemini APIドキュメントで案内されているモデル名はembeddinggemma-2ではなく、gemini-embedding-2です。EmbeddingGemma 2のモデルカードとGoogleの開発者向けガイドでは、Sentence Transformersのようなローカルライブラリで利用するダウンロード可能なモデルとして説明されています。

ローカルで/v1/embeddingsエンドポイントを公開するのはGoogle Cloudではなく、デプロイしたランタイムです。マネージドサービスを探しているなら、Gemini Embedding 2のドキュメントでクラウドSDKとリクエスト形式を確認できます。使うモデル名はembeddinggemma-2ではなく、gemini-embedding-2です。

from google import genai

client = genai.Client()
result = client.models.embed_content(
    model="gemini-embedding-2",
    contents="A private semantic search service",
)
print(result.embeddings)

マネージド版はGoogleのホスティングAPIを呼び出します。一方、ローカルモデルに適用される認証情報や利用上限は、デプロイしたランタイム側で決まります。

ローカルモデルの構成とスペック

EmbeddingGemma 2は、7億4,000万パラメータのマルチモーダル埋め込みモデルです。テキスト用の2億7,000万パラメータのコアに、必要に応じて利用できるビジョンエンコーダーと音声エンコーダーを組み合わせた構成で、必要なモダリティだけをロードできます。GoogleとDeepMindは、テキスト生成ではなく、テキスト、コード、画像、動画、音声を対象にした検索用途のモデルとして位置付けています。

モデルカードでは、異なるモダリティを横断して比較できる共有ベクトル空間が説明されています。740Mという数字はモデル全体の規模です。Googleの開発者向けガイドが示すように、エンコーダーは選択的に利用できるため、ビジョンと音声を使わないテキスト専用処理では、実際のメモリ使用量や計算量を抑えられます。

デプロイ先に合わせてサービング方法を選ぶ

PythonアプリケーションならSentence Transformers

Pythonサービスで使う場合、公式ドキュメントが案内している方法は、Sentence Transformers経由でgoogle/embeddinggemma-2チェックポイントを利用する構成です。バッチ処理、デバイスの割り当て、プロンプト、正規化、ベクトルの切り詰めまで、細かく制御できます。

検索用途では、クエリとドキュメントに別々の指示を使うのが基本です。Googleの例では、クエリに検索用のプレフィックスを付け、ドキュメントにはtitle: none | text: ...のような形式を使っています。両方を汎用的な呼び出しで埋め込むのではなく、適切なプロンプト名を指定してmodel.encodeを使うのが安全です。

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("google/embeddinggemma-2")

query_vector = model.encode(
    "How do I rotate an API key?",
    prompt_name="query",
    normalize_embeddings=True,
)
document_vectors = model.encode(
    [
        "title: API keys | text: Rotate keys from the security settings page.",
        "title: Billing | text: Download invoices from the billing page.",
    ],
    prompt_name="document",
    normalize_embeddings=True,
)

Pythonから処理を細かく制御したいならこの方法が向いています。複数のサービスから安定したインターフェースで利用したい場合は、HTTPサービング対応のランタイムを選ぶとよいでしょう。

手軽にローカルRESTエンドポイントを立てるならOllama

OllamaのEmbeddingGemma 2ページでは、http://localhost:11434/api/embedにシンプルなローカルAPIを用意できます。

ollama pull embeddinggemma-2

curl http://localhost:11434/api/embed \\
  -d '{
    "model": "embeddinggemma-2",
    "input": "A private semantic search service"
  }'

Ollamaには270m、440m、570m、740mといったモデルタグがあり、表示されるパッケージサイズはおよそ378 MBから1.3 GBまであります。これらは個別にパッケージ化されたモデルバリエーションであり、740Mのフルチェックポイントを指す互換性のある別名ではありません。本番環境の仕様を決める前に、インストールしたタグと対応入力モダリティを確認してください。モデルファミリー自体はマルチモーダルですが、表示されている各バリエーションでは、すべてのモダリティが同じように明確に説明されているわけではありません。

タスクごとのプレフィックス、モデルと次元数の整合性を保つ必要があるほか、モデルを変更する場合はインデックスの再構築も必要です。

デバイスに組み込むならエッジ向けランタイム

Google AI Edgeでは、Universal EmbedderガイドでEmbeddingGemma V2を扱っています。また、LiteRT-LMの埋め込みモデルドキュメントでは、ローカルでOpenAI互換の/v1/embeddingsサービングを行う方法が説明されています。オフライン動作やデバイス上でのプライバシーを、一般的なクラウド環境の手軽さより優先したい場合に適した選択肢です。

一般的なハードウェア上のサーバーで動かすなら、まずはSentence TransformersかOllamaから始めるとよいでしょう。オフライン動作、プライバシー、起動時のフットプリント、デバイス連携が最優先の要件になった段階で、エッジ向けランタイムへの移行を検討します。

大きなモデルを選ぶ価値があるマルチモーダル用途

EmbeddingGemma 2の強みが最も生きるのは、複数のメディアを1つの検索空間で扱いたいプロジェクトです。

コード検索と開発者向けリトリーバル

公開されている評価表によると、記載されたコードベンチマークでのEmbeddingGemma 2のMTEB Codeスコアは78.68で、EmbeddingGemma 1の68.76を上回っています。リポジトリ検索、APIドキュメント検索、コード向けRAGで試す理由にはなりますが、利用する言語構成やコードベースで同じ結果が得られる保証はありません。

大きなモデルへ移行する必要がないケース

入力が通常のOCRテキストだけのパイプラインでは、マルチモーダル対応によって構成が複雑になる一方、検索品質は向上しない可能性があります。Paperless-ngxのあるユーザーは、このトレードオフを次のように表現しています。

「paperless-ngxがモデルに送る普通のOCRテキストに対して、embeddinggemma-2が通常のembeddinggemmaより本当に優れているのかは分からない。同じ結果のために、かなり手間が増えるように思える」 — u/Great-Cow7256, Reddit

これはベンチマーク結果ではありません。しかし、移行の判断基準としては的を射ています。動作中のテキスト専用インデックスを作り直す前に、実際のコーパスで検索品質を比較しましょう。

次元数は768d、512d、256d、128dのどれを選ぶべきか

Googleの埋め込みドキュメントでは、EmbeddingGemma 2でMatryoshka方式の切り詰めに対応していることが説明されています。エンコード後に、より小さなベクトルへ変換できる仕組みです。ベクトルを小さくすればインデックスの保存容量や転送量を減らせますが、最も大きく圧縮した設定では品質も低下します。

数値は、Ollamaのモデルページに掲載された評価表からの引用です。新しくマルチモーダルインデックスを作るならまず768d、保存容量を抑えたいなら512dまたは256dを起点にし、128dはテキスト中心のワークロードで検証してから選ぶのがよいでしょう。

1つのベクトルインデックス内で次元数を混在させてはいけません。既存のデータベースが768次元ベクトルを保存している場合、256dへ変更するには、インデックス済みのドキュメントを再度埋め込み、インデックスを再構築する必要があります。クエリベクトルには、ドキュメントベクトルと同じモデル、プロンプト、正規化方法、次元数を使わなければなりません。

モデルのサイズではなくワークフローで選ぶ

Googleのマネージドエンドポイントを使うならGemini Embedding 2、Pythonから細かく制御するならSentence Transformers、手早くローカルHTTPサービスを立てるならOllama、オフラインのデバイス運用が重要ならAI Edge/LiteRT-LMを選びます。

コーパスが通常のOCRテキストだけで、現在のインデックスが必要な関連性を満たしているなら、より小さなテキスト専用モデルを使い続けるのも合理的です。EmbeddingGemma 2はマルチモーダル構成をシンプルにできる可能性がありますが、テキスト専用の検索品質を自動的に改善するモデルではありません。

EmbeddingGemma 2 API FAQ

EmbeddingGemma 2はGemini APIから利用できますか？

GoogleのマネージドGemini APIドキュメントで現在案内されているモデル名はgemini-embedding-2です。EmbeddingGemma 2は主にローカル推論向けのオープンモデルとしてドキュメント化されていますが、ローカルランタイムからAPI互換のエンドポイントを公開することはできます。

EmbeddingGemma 2はCPUで動かせますか？

CPUバックエンドを明示的に提供するローカルランタイムであれば、CPU推論を利用できます。関連するランタイムの情報は、GoogleのAI Edge埋め込みドキュメントで確認できます。実際の性能は、ハードウェア、量子化、バッチサイズ、使用するモダリティによって変わります。

既存のベクトルは作り直す必要がありますか？

埋め込みモデル、タスクのフォーマット、正規化の方針、ベクトル次元数のいずれかを変更するなら、通常は作り直す必要があります。移行を再現できるよう、インデックスにはモデル識別子、次元数、前処理のメタデータを保存しておきましょう。