EmbeddingGemma 2: Multimodale Embeddings für die lokale Unternehmenssuche

Dieser Beitrag wurde mithilfe von KI automatisiert erstellt.

Google DeepMind hat am 6. Oktober 2026 EmbeddingGemma 2 veröffentlicht: ein offenes, leichtgewichtiges multimodales Embedding-Modell mit 740 Millionen Parametern unter der Apache-2.0-Lizenz. Es bildet Text (einschließlich Code), Bilder, Video und Audio in einem gemeinsamen 768-dimensionalen Vektorraum ab und ist laut Google für den Betrieb auf Endgeräten und lokaler Hardware ausgelegt. Modellgewichte stehen auf Hugging Face und Kaggle bereit. Dieser Beitrag ordnet die angekündigten Eigenschaften ein — ohne eigene Messungen, mit Quellenangaben zu allen Zahlen.

Die Kernfakten im Überblick

Merkmal	Angabe (laut Ankündigung bzw. Modellkarte)
Parameter gesamt	740 Mio.
Architektur	Gemma 4
Lizenz	Apache 2.0 (kommerzielle Nutzung erlaubt)
Modalitäten	Text inkl. Code, Bilder, Video, Audio
Vektorraum	768 Dimensionen, per Matryoshka-Lernen auf 512, 256 oder 128 Dimensionen kürzbar
Kontextfenster	8.000 Tokens (laut Google viermal so viel wie EmbeddingGemma 1)
Sprachabdeckung	100+ Sprachen (Modellkarte)
Bezugsquellen	Hugging Face, Kaggle

Quellen: Ankündigung von Google DeepMind (6. Oktober 2026) und Modellkarte auf Hugging Face (abgerufen am 7. Oktober 2026).

Modular aufgebaut: nur laden, was gebraucht wird

Das Modell kombiniert ein Textmodell mit optionalen Encodern für Bild und Audio. Wer nur Text und Code einbetten will, kommt mit dem Textteil aus:

Baustein	Parameter	Pflicht oder optional
Text (inkl. Code)	270 Mio. (130 Mio. Transformer + 140 Mio. Embedding-Teil)	Kernmodell
Vision-Encoder	170 Mio.	optional
Audio-Encoder	300 Mio.	optional

Praktisch bedeutet das: Ein Suchdienst für Dokumente und Code muss nicht die vollen 740 Mio. Parameter laden; multimodale Anwendungsfälle laden die Encoder hinzu.

Speicher sparen mit kürzbaren Vektoren

Über Matryoshka Representation Learning (MRL) lassen sich die Ausgabevektoren laut Google von 768 auf 512, 256 oder 128 Dimensionen kürzen — mit bis zu sechsmal geringerem Speicherbedarf für lokale Vektordatenbanken. Das richtige Format hängt vom Anwendungsfall ab: Je kleiner die Dimension, desto weniger Speicher und Suchlaufzeit, potenziell aber auch weniger Trennschärfe. Diese Abwägung sollte pro Anwendungsfall mit eigenen Stichproben getestet werden, nicht anhand der Marketingzahlen allein.

Zahlen mit Herkunft: was Google ankündigt

Alle folgenden Werte stammen vom Hersteller und wurden für diesen Beitrag nicht unabhängig nachgemessen:

• Code-Qualität: Verbesserung in MTEB Code von 68,76 auf 78,68 Punkte gegenüber EmbeddingGemma 1 (9,92 Punkte).
• Benchmarks: Laut Google führend bei Multimodal-Embeddings unter 1 Milliarde Parametern in MTEB Code und MAEB (Massive Audio Embedding Benchmark).
• Ressourcenbedarf: Mit Quantisierung auf einem Google Pixel 11 Pro etwa 191 MB aktiven RAM für Text-Embeddings bzw. etwa 567 MB für das vollständige multimodale Modell.
• Kontext: 8.000 Tokens entsprechen laut Google bis zu 5,5 Minuten Audio, 29 Bildern oder 58 Videobildern pro Einbettung.
• Vorgänger-Verbreitung: Über 20 Millionen Downloads von EmbeddingGemma 1, laut Google.

Solche Angaben sind ein Startpunkt für eine Evaluierung, kein Ersatz dafür: Wer das Modell einsetzen will, sollte Qualität und Latenz mit eigenen Dokumenten, eigenem Code und eigenen Medien prüfen.

Was das für Unternehmen praktisch bedeutet

Embedding-Modelle sind die Suchmaschine hinter RAG-Systemen: Sie bestimmen, welche Passagen ein Sprachmodell überhaupt zu sehen bekommt. Ein offenes, multimodales Modell dieser Größe macht drei Szenarien attraktiver:

1. Lokale Dokumentensuche: Embeddings werden auf eigener Infrastruktur erzeugt; die Inhalte müssen für die Suche nicht zu einem externen Dienst übertragen werden. Die Pipeline (Betrieb, Aktualisierung, Zugriffskontrolle) verantwortet man selbst.
2. Semantische Codesuche: Code-Repositorys lassen sich lokal indexieren und per natürlicher Sprache durchsuchen.
3. Medienarchive erschließen: Gemeinsame Einbettungen erlauben Textsuche über Bild-, Video- und Audiobestände.

Einsatzweg	Beispiele aus der Ankündigung	Typischer Nutzen
Server und Workstations	vLLM, Ollama, llama.cpp, LM Studio	Indexierung auf eigener Hardware
Python-Pipelines	sentence-transformers, transformers	Suche, Clustering, Klassifikation in Datenflüssen
Browser und Endgeräte	transformers.js, WebGPU, MediaPipe/LiteRT	Suche ohne Serverkontakt
Vektorspeicher	z. B. Qdrant-Anbindung	lokale Vektordatenbanken

Einordnung und Grenzen

• Ein Embedding-Modell ist kein Generatormodell. Es liefert Ähnlichkeiten und Treffer, keine Antworten. Für RAG wird es mit einem generierenden Modell kombiniert — die Antwortqualität hängt dann von beiden Komponenten ab.
• Multimodal heißt: gemeinsamer Raum, nicht garantierte Gleichwertigkeit. Wie gut Bild-, Audio- oder Videotreffer im konkreten Bestand sind, zeigt erst ein Test mit eigenen Daten.
• Offene Gewichte sind kein Betriebspaket. Apache 2.0 erlaubt kommerzielle Nutzung; Betrieb, Modellpflege, Monitoring und Zugriffskontrolle bleiben eigene Aufgaben.
• Herstellerangaben bleiben Herstellerangaben. Benchmarkwerte gelten für die getesteten Datensätze, nicht automatisch für den eigenen Dokumentbestand.

Für die Einbettung in eine Unternehmenssuche mit Berechtigungen und belegbaren Treffern siehe auch unseren Beitrag Mehr als einfaches RAG sowie die CogLake Knowledgebase.

Quellen

• Google DeepMind: „EmbeddingGemma 2: an open, lightweight multimodal embedding model“, 6. Oktober 2026 — https://deepmind.google/blog/embeddinggemma-2-an-open-lightweight-multimodal-embedding-model/
• Modellkarte „google/embeddinggemma-2“ auf Hugging Face, abgerufen am 7. Oktober 2026 — https://huggingface.co/google/embeddinggemma-2

Stand: 7. Oktober 2026. Alle Leistungs- und Ressourcenangaben sind Herstellerangaben ohne eigene Überprüfung durch CogLake.