EmbeddingGemma 2 lokal betreiben: Leitfaden zu Migrationsrisiken

EmbeddingGemma 2 lokal zu betreiben ist nicht automatisch ein 1:1-Ersatz für einen bestehenden Embedding-Dienst. Die Laufzeit lässt sich oft mit überschaubarem Aufwand austauschen. Ändert sich jedoch der Repräsentationsvertrag, müssen die Vektoren in der Regel neu berechnet werden. Für eine sichere Migration solltest du deshalb drei Fragen getrennt betrachten: Wie läuft das Modell? Sind die vorhandenen Vektoren weiterhin kompatibel? Und reicht die Qualität der multimodalen Suche für dein Korpus aus?

Die Migrationsentscheidung auf einen Blick

EmbeddingGemma 2 ist eine gute Wahl, wenn du Text, Code, Bilder, Videos oder Audio lokal innerhalb einer Modellfamilie einbetten möchtest und einen kontrollierten Backfill einplanen kannst. Tausche in der Produktion nicht zuerst den Query-Encoder aus, um die Dokumente später nachzuziehen. Ein Embedding-Modell ist Teil des Indexschemas – auch dann, wenn die Vektordimension auf den ersten Blick gleich aussieht.

Googles Model Card nennt bei 768 Dimensionen einen Wert von 61.36 auf MTEB multilingual v2, 78.68 auf MTEB code v1, 67.84 NDCG@5 bei der Suche in visuellen Dokumenten, 50.67 Hit@1 bei der Videosuche und 69.54 MRR@10 bei der Audiosuche. Diese Werte sind hilfreiche Referenzpunkte, ersetzen aber keine Tests mit deinen eigenen Suchanfragen.

Was sich beim Wechsel zu EmbeddingGemma 2 ändert – und was nicht

EmbeddingGemma 2 ordnet Text, Code, Bilder, Videos und Audio einem gemeinsamen Vektorraum mit 768 Dimensionen zu. Der Checkpoint ist modular aufgebaut: Im offiziellen Entwicklerleitfaden werden eine Konfiguration mit 270M Parametern nur für Text, eine Konfiguration mit 440M Parametern für Text und Bild, eine Konfiguration mit 570M Parametern für Text und Audio sowie die vollständige Konfiguration mit 740M Parametern beschrieben. Werden Encoder deaktiviert, sinken die Zahl der geladenen Gewichte und der Spitzenverbrauch beim Arbeitsspeicher. Dadurch entsteht aber nicht automatisch ein neuer semantischer Vektorraum.

Genau diese Unterscheidung ist bei einer Migration entscheidend. Eine Textanfrage aus der 270M-Konfiguration kann mit einem Dokumentvektor aus der vollständigen EmbeddingGemma-2-Konfiguration verglichen werden, weil Google für diese Konfigurationen einen kompatiblen Vektorraum dokumentiert. Daraus folgt aber nicht, dass sich ein alter Vektor von EmbeddingGemma 1, Qwen, Nomic oder einem API-Anbieter gefahrlos mit EmbeddingGemma 2 abfragen lässt, nur weil er ebenfalls 768 Koordinaten besitzt.

Auch das Aufgabenformat gehört zum Vertrag. Für asymmetrische Suche erwartet EmbeddingGemma 2 beispielsweise eine Suchanweisung wie task: search result | query: ... sowie ein Dokumentformat wie title: ... | text: .... Für die Codesuche gibt es eine eigene Aufgabenanweisung. Wenn deine bisherige Pipeline andere Präfixe, Chunking-Regeln, Normalisierung oder eingebettete Felder verwendet, solltest du diese Änderungen als neue Repräsentationsversion behandeln und wie eine Migration validieren.

Laufzeit auswählen: lokal so schlank wie möglich starten

Für verlässliche Ergebnisse zuerst Sentence Transformers

Die offizielle Model Card dokumentiert google/embeddinggemma-2 für Sentence Transformers und Transformers. Wenn du Mediendaten verarbeiten möchtest, installierst du die Multimodal-Extras:

pip install -U "sentence-transformers[image,audio,video]" transformers

Für eine Migration ist dies der beste Referenzpfad, weil Prompt-Namen, Kürzung, Normalisierung und das Verhalten bei multimodalen Eingaben den offiziellen Beispielen folgen. Die Laufzeit muss damit nicht automatisch die geringste Latenz liefern. Sie schafft aber eine belastbare Ausgangsbasis, bevor du optimierst.

Ein minimaler Smoke-Test nur für Text sieht so aus:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer(
    "google/embeddinggemma-2",
    config_kwargs={"vision_config": None, "audio_config": None},
)
query = model.encode(
    "embedding model migration",
    prompt_name="SearchQuery",
    truncate_dim=256,
    normalize_embeddings=True,
)
document = model.encode(
    "Rebuild vectors when the embedding representation changes.",
    prompt_name="Document",
    truncate_dim=256,
    normalize_embeddings=True,
)
print(model.similarity(query, document).item())

Führe diesen Test aus, bevor du einen Server, Quantisierung oder eine Vektordatenbank einführst. So prüfst du, ob Checkpoint, Aufgaben-Prompts, Dimension und Normalisierung korrekt zusammenspielen.

Ökosystem-Laufzeiten erst nach einem Feature-Abgleich einsetzen

Googles Entwicklerleitfaden nennt vLLM, Hugging Face Transformers, Sentence Transformers, SGLang, MLX, Ollama, LM Studio und LiteRT als unterstützte Werkzeuge für Entwicklung oder Deployment. Diese Liste ist ein Hinweis auf die Verfügbarkeit, aber kein Beleg dafür, dass jede Laufzeit dieselbe Kombination aus Text, Bild, Video, Audio, Interleaving, Aufgabenpräfixen, Kürzung und Batching bereitstellt.

Prüfe bei jeder infrage kommenden Laufzeit anhand einer echten Anfrage fünf Punkte: die exakte Checkpoint-Revision, die von dir verwendeten Modalitäten, die Ausgabedimensionen, die Normalisierung nach der Kürzung sowie das Verhalten bei Query- und Dokumentpräfixen. Eine Laufzeit, die Text schnell verarbeitet, aber deinen Pfad für visuelle Dokumente nicht unterstützt, ist kein gleichwertiger Ersatz für das vollständige Modell.

Ein kompakter nativer Server ist Optimierung, nicht Migrationsstrategie

Das öffentliche embeddinggemma.c-Repository bietet einen spezialisierten C11-/Metal-ähnlichen Server für EmbeddingGemma 300M mit Varianten für CPU, Metal, CUDA, ROCm und Intel XPU. Die README dokumentiert einen OpenAI-kompatiblen /v1/embeddings-Endpunkt, Dimensionen von 768/512/256/128 sowie einen 278 MB großen Q4_0-Modell-Download. Das Projekt berichtet über einen kontrollierten Vergleich auf einem Apple M5 Max gegenüber llama.cpp Build b8981 in 54 Zellen und einen geometrischen Mittelwertvorteil von 1.25×. Das sind projektspezifische Durchsatzwerte – kein Qualitätsvergleich und kein Beleg für multimodale Parität mit dem 740M-Checkpoint.

Für die Migration ist vor allem die API-Form interessant. Wenn deine Anwendung bereits OpenAI-kompatible Embeddings verwendet, kann ein lokal betriebener Server mit passendem Endpunkt den Adapteraufwand reduzieren. Behalte das Ergebnis von Sentence Transformers trotzdem als Referenz für die Korrektheit, bis Modalitäts- und Präfixverhalten des Servers zu deiner Produktionspipeline passen.

Risiko beim Index-Rebuild: Die Dimension ist nur eine von mehreren Achsen

Vektoren neu berechnen, sobald sich die Quelle-zu-Vektor-Funktion ändert

Gehe von einem vollständigen Rebuild aus, wenn du Modellfamilie, Modellversion, Aufgabenpräfix, Normalisierung, Chunking, Kürzungsregeln, eingebettete Felder oder die Ähnlichkeitssemantik änderst. Sowohl der Migrationsleitfaden von Qdrant als auch die Analyse zur Modellmigration von Nalar betonen denselben operativen Grundsatz: Dokument- und Query-Vektoren müssen derselben Repräsentationsversion angehören. Gleiche Dimensionen beweisen keine semantische Kompatibilität.

Schneide keinen alten 768-dimensionalen Vektor ab und behandle ihn anschließend als 256-dimensionalen EmbeddingGemma-2-Vektor. Die Matryoshka-Ausgaben von EmbeddingGemma 2 werden für unterstützte Kürzungsgrößen trainiert und müssen nach der Kürzung erneut normalisiert werden. Die Model Card nennt folgende offiziellen Referenzwerte:

Die offizielle Model Card nennt außerdem bei 768 Dimensionen 67.84 NDCG@5 für die Suche in visuellen Dokumenten und 50.67 Hit@1 für die Videosuche. Verwende diese Werte als Baseline für die volle Dimension, statt Werte für reduzierte Dimensionen zu erfinden. Die belastbare Schlussfolgerung ist richtungsbezogen: 256d liegt deutlich näher an der Qualität der vollen Dimension als 128d, und bei multimodalen Aufgaben fällt die Qualität mit 128d stärker ab. Erzeuge daher jeden Vektor mit dem ausgewählten Checkpoint und der gewählten Dimension neu, statt Vektoren eines anderen Modells zu kürzen.

Der gemeinsame EmbeddingGemma-2-Raum kann unnötige Arbeit vermeiden

Es gibt eine wichtige Ausnahme. Wenn dein bestehendes Korpus bereits mit EmbeddingGemma 2 eingebettet wurde und du lediglich eine andere Auswahl seiner Encoder lädst, teilen sich die Konfigurationen laut Googles Entwicklerleitfaden denselben Vektorraum. Eine reine Textanfrage kann dann mit einem Dokumentvektor aus dem vollständigen Modell abgeglichen werden. In diesem Fall musst du bestehende Textvektoren möglicherweise nicht neu erzeugen, nur weil der Serving-Prozess nun auch Bild- oder Audio-Unterstützung lädt.

Für neue Datensätze mit Medien brauchst du trotzdem neue Vektoren. Ein reiner Textindex kann ein Bild, Video oder Audioelement nicht finden, das nie eingebettet wurde. Multimodale Suche in einem bestehenden Korpus ist daher auch bei unverändertem Checkpoint eine schrittweise Korpusmigration.

Mit Blue-Green-Deployment oder Named Vectors umschalten

Für ein laufendes System bietet Qdrants Migrationsmuster eine klare Vorlage: neue Collection anlegen, neue Datensätze dual schreiben, aus den maßgeblichen Quelldaten nachladen, Recall@10/MRR/nDCG@10 vergleichen, einen Alias umschalten und die alte Collection für einen Rollback behalten. Qdrants Leitfaden verwendet Version 1.19.0, ein Beispiel mit 512 Dimensionen und Batches von 100 Punkten. Diese Werte sind Beispiele und keine Vorgaben für EmbeddingGemma 2.

Mit Named Vectors lassen sich alte und neue Repräsentationen auch in einer Collection ablegen – vorausgesetzt, deine Vektordatenbank unterstützt das und dein Update-Pfad schreibt beide Varianten zuverlässig. Weaviate empfiehlt in seinem Leitfaden zur Vectorizer-Migration für den Produktivbetrieb Collection-Aliase, weil sich die alte Collection für einen sofortigen Rollback behalten und nach der Validierung löschen lässt. Die Alternative, einen Vektor zur bestehenden Collection hinzuzufügen, kann den Speicher dauerhaft vergrößern und eignet sich eher für Vergleiche als für einen sauberen Endzustand.

Multimodale Qualität: Genau die veränderten Bereiche testen

Der gemeinsame Vektorraum von EmbeddingGemma 2 ist nur dann wertvoll, wenn das Suchverhalten zu deinen Daten passt. Ein rein textbasierter Benchmark kann bestätigen, dass die Textsuche durch die Migration nicht beschädigt wurde, während Fehler bei PDF-Seiten, Diagrammen, Bildbeschreibungen, Videoframes, Audioclips oder ineinander verschachtelten Datensätzen unentdeckt bleiben.

Beginne mit getrennten, beschrifteten Testgruppen:

1. Textanfrage → Text-Chunk.
2. Codeanfrage → Code-Chunk.
3. Textanfrage → Bild oder visuelles Dokument.
4. Textanfrage → Videoframe oder Audiosegment.
5. Gemischte Text-und-Medien-Anfrage → gemischtes Dokument.
6. Sprachübergreifende Anfrage → Dokument in den von dir angebotenen Sprachen.

Verwende 768d oder 512d als erste multimodale Baseline. Laut offizieller Model Card entfallen innerhalb eines gemeinsamen Kontexts von 8.192 Tokens 280 Tokens auf ein Bild, 140 Tokens auf einen Videoframe und 25 Tokens pro Sekunde Audio. Gemischte Eingaben teilen sich dasselbe Budget. Ein Datensatz mit Text, Bildern und Video bietet daher für jede einzelne Komponente weniger Platz als eine Eingabe mit nur einer Modalität.

Die Model Card berichtet außerdem, dass 128d bei multimodalen Aufgaben einen stärkeren Qualitätsverlust verursacht als bei reinen Textaufgaben. Damit ist 128d für einen großen Textindex ein sinnvoller Kandidat für eine erste Vorauswahl, aber kein Standard für ein gemischtes Medienarchiv. Teste 256d mit deinen tatsächlichen Anfragen zu visuellen Dokumenten und Cross-Modal-Suche, bevor du die Speichereinsparung akzeptierst.

Vergleiche eine einheitliche EmbeddingGemma-2-Pipeline mit deiner bisherigen getrennten Text-/Bild-Pipeline anhand identischer Anfragen. Leite die multimodale Qualität nicht allein aus der Architektur des gemeinsamen Vektorraums ab.

Schrittweiser Einführungsplan für ein bestehendes RAG-System

1. Den aktuellen Vertrag erfassen. Halte Modell-ID, Checkpoint-Revision, Präfixe, Chunking, Dimensionen, Metrik, Normalisierung, Quellfelder und jede bereits indexierte Modalität fest.
2. Einen repräsentativen Evaluationsdatensatz erstellen. Definiere Ziele für Recall@k, MRR oder nDCG und bilde separate Testgruppen für Text, Code, visuelle Dokumente, Audio, Video, Sprachen und lange Anfragen.
3. Die lokale Baseline ermitteln. Verarbeite dasselbe Korpus zunächst mit Sentence Transformers. Protokolliere Embedding-Latenz, Suchlatenz, Speicherverbrauch, Indexgröße, Fehler und Verteilungen der Scores.
4. Einen versionierten Kandidatenindex aufbauen. Behalte stabile Dokument-IDs und die maßgeblichen Text-/Mediendaten außerhalb des Vektorspeichers, damit der Backfill reproduzierbar bleibt.
5. Schreibvorgänge während des Backfills abgleichen. Verwende entweder einen Quellensnapshot mit anschließender Wiedergabe der Änderungen oder schreibe neue und aktualisierte Datensätze parallel in beide Repräsentationsversionen.
6. Produktive Anfragen im Schattenbetrieb auswerten. Vergleiche Rankings, Leerresultatquoten, Latenz und markierte Relevanz, ohne die für Nutzer sichtbaren Antworten zu verändern.
7. Atomar umschalten. Binde den EmbeddingGemma-2-Query-Encoder und den dazugehörigen Index unter einer gemeinsamen Version oder einem Alias. Setze den neuen Query-Encoder niemals als Zwischenschritt gegen den alten Index ein.
8. Rollback ermöglichen. Behalte alten Index und alten Query-Pfad, bis repräsentativer Traffic die Akzeptanzschwellen erfüllt. Beende danach die Dual Writes und gib den zusätzlichen Speicher frei.

FAQ

Lässt sich EmbeddingGemma 2 ausschließlich auf der CPU betreiben?

Ja, mit einer CPU-fähigen Laufzeit. Die Model Card empfiehlt Float32, wenn BFloat16 nicht verfügbar ist. Die reine Textkonfiguration umfasst 270M Parameter. Der CPU-Durchsatz hängt von Laufzeit, Präzision, Batching und Hardware ab. Miss ihn deshalb mit deinem eigenen Korpus, statt GPU-Werte zu übernehmen.

Die Wahl der Laufzeit ist ein Kompromiss zwischen Referenztreue, Feature-Parität, Serving-Effizienz und dem Validierungsaufwand für eine neue Suchversion.