EmbeddingGemma 2 ist ein veröffentlichtes Embeddingmodell mit offenen Gewichten, kein generatives LLM und keine Architekturvorschau. Google DeepMind veröffentlichte den Apache-2.0-Checkpoint am 6. Oktober 2026. Er bildet Text und Code, Bilder, abgetastete Videoframes, Audio oder verschachtelte Kombinationen auf denselben 768-dimensionalen Vektorraum ab. Das vollständige Modell besitzt 740 Millionen Parameter; Deployments können die unabhängigen Vision- und Audio-Encoder weglassen und nur das 270M-Textmodell laden.12
Architektonisch interessant ist die Verbindung aus normaler Encoder-Attention, modalitätsspezifischen Türmen und Retrieval-Ausgabe. Vision- und Audiotürme erzeugen keine eigenen finalen Embeddings. Sie liefern Soft Tokens in der Breite des Textmodells, die Medienplatzhalter in einer gemeinsamen Sequenz ersetzen. Ein bidirektionaler Textencoder mit 24 Schichten verarbeitet anschließend alle Modalitäten, hält den ursprünglichen Input über Per-Layer Embeddings (PLE) in jeder Tiefe direkt zugänglich und mittelt die Tokenzustände schließlich zu einem normalisierten Vektor. Dieser Artikel beschreibt den veröffentlichten Checkpoint und eine versionierte Implementierung. Benchmark- und Gerätespeicherwerte bleiben Herstellermessungen.
Der veröffentlichte Stack
| Komponente | Veröffentlichter Wert | Bedeutung zur Laufzeit |
|---|---|---|
| Textencoder | 24 Schichten, Residualbreite 512, Gated-GELU-MLP-Breite 2.048 | Jeder Transformerblock verarbeitet und liefert [B, S, 512]. |
| Hybride Attention | 20 lokale und vier globale bidirektionale Schichten im wiederholten Verhältnis 5:1 | Lokale Schichten begrenzen den Großteil der Attention-Arbeit; vier Schichten erzeugen weiterhin vollständige S × S-Attention. |
| Lokale Attention | Vier Query-Heads, zwei KV-Heads, Head-Dimension 256 | Q ist [B, 4, S, 256]; K und V sind [B, 2, S, 256]. Jede Position sieht einen Radius von 512 Token. |
| Globale Attention | Vier Query-Heads, ein KV-Head, Head-Dimension 512 | Q ist [B, 4, S, 512]; K und V sind [B, 1, S, 512]. Diese Schichten verwenden den vollständigen unmaskierten Input. |
| Positionskodierung | RoPE-Basis 10.000 lokal und 1.000.000 global | Die beiden Attention-Pfade rotieren Q/K mit unterschiedlichen Frequenzskalen. |
| Multimodale Brücke | Vision- und Audiotürme projizieren auf 512-dimensionale Soft Tokens | Medienvektoren gelangen in denselben Residual Stream wie Text-Embeddings. |
| Ausgabe | Projektion 512 -> 768 pro Token, maskiertes Mean Pooling, L2-Normalisierung | Ein Input wird zu einem Vektor [B, 768] mit Länge eins. |
| Optionale Ausgabegrößen | Führende 512, 256 oder 128 Dimensionen durch MRL | Das Kürzen reduziert Speicher und Ähnlichkeitsarbeit im Vektorindex, nicht die Encoderberechnung. |
Die Parameterzahl ist absichtlich modular: 130M Parameter für den Transformer-Backbone, 140M für Embeddings und Ausgabepfad, 170M für Vision und 300M für Audio. Die offizielle Konfiguration unterstützt daher Text-only (270M), Text plus Vision (440M), Text plus Audio (570M) und vollständig multimodal (740M). Das ist eine Entscheidung über residente Gewichte; sie ändert weder die 512-dimensionale Fusionsschnittstelle noch den finalen 768-dimensionalen Raum.13
Medien werden vor dem gemeinsamen Encoder zu Soft Tokens
Der Processor baut eine einzelne Tokensequenz und markiert Medienpositionen mit <|image|>, <|video|> oder <|audio|>. Der passende Modalitätsturm erzeugt eine Folge 512-dimensionaler Vektoren. In der veröffentlichten Transformers-Implementierung ersetzt masked_scatter damit die Platzhalterpositionen in inputs_embeds. Der resultierende Tensor hat unabhängig von der Modalität seiner Positionen die Form [B, S, 512]; derselbe Encoder mit 24 Schichten kann dadurch Text- und Medienkontext mischen.45
Das ist frühe Fusion auf Tokenebene, keine späte Fusion separat gepoolter Text-, Bild- und Audio-Embeddings. Ein verschachtelter Produkteintrag kann etwa Text, zwei Bildspannen und Spannen abgetasteter Videoframes enthalten; das Modell liefert einen Vektor für die gesamte Sequenz. Die Soft-Token-Anzahl ist zugleich der praktische Rechenregler:
- Ein Bild verwendet standardmäßig 280 Vision-Token.
- Ein Videoframe verwendet standardmäßig 140; der Processor tastet mit 1 FPS ab und begrenzt in der Voreinstellung auf 32 Frames.
- Audio benötigt ungefähr 25 Token pro Sekunde und soll mono mit 16 kHz zugeführt werden.
- Unterstützte Vision-Budgets sind 70, 140, 280, 560 und 1.120 Soft Tokens.
Alle Modalitäten teilen das veröffentlichte Betriebslimit von 8.192 Token. Ohne begleitenden Text passen mit den Standardwerten ungefähr 29 Bilder, 58 Videoframes oder 327 Sekunden Audio. Das sind Budgetrechnungen, keine gleichzeitig erreichbaren Höchstwerte: Verschachtelter Text und Medien verbrauchen dieselbe Sequenz. Ein größeres Vision-Budget erhält mehr Bilddetails, erhöht jedoch die Arbeit lokaler Attention und in den vier globalen Schichten die quadratische Attention-Matrix.15
Die Checkpoint-Konfiguration enthält ein größeres Feld für die Positionskapazität; Google dokumentiert und unterstützt für diese Veröffentlichung jedoch 8.192 Token. Eine Konfigurationsobergrenze belegt keinen größeren validierten Produktionskontext.
Bidirektionale hybride Attention besitzt keinen wiederverwendbaren KV-Cache
Alle 24 Schichten sind Encoder-Schichten: Jedes gültige Token kann nach links und rechts sehen. Zwanzig lokale Schichten verwenden einen symmetrischen Radius von 512; ein inneres Token sieht damit einschließlich seiner selbst höchstens 1.025 Positionen. Jede sechste Schicht ist global, insgesamt also vier Full-Attention-Schichten. Für Sequenzlänge S beträgt die grobe Arbeit für Attention-Scores damit
Das senkt den Koeffizienten quadratischer Attention, macht den Encoder aber nicht linear. Nach der Fusion zählen Medientoken exakt wie Textpositionen.
Die lokalen Schichten verwenden Grouped-Query Attention: Zwei KV-Heads werden für vier Query-Heads wiederholt. Die globalen Schichten verwenden Multi-Query Attention: Ein KV-Head wird von vier Query-Heads geteilt. Queries, Keys und Values erhalten RMS-Normalisierung pro Head. Die veröffentlichte Eager-Implementierung verwendet deshalb den Attention-Skalierungswert 1.0, statt nochmals den üblichen Faktor 1 / sqrt(head_dim) anzuwenden, und berechnet Softmax in FP32, bevor sie in den Datentyp der Values zurückwandelt.43
Anders als ein kausaler Decoder hängt dieses Modell nicht Token für Token an eine Sequenz an und behält keinen schrittübergreifenden KV-Cache. Ein verändertes Dokument wird als vollständige Sequenz neu eingebettet. GQA und MQA reduzieren weiterhin die Breite der K/V-Projektionen und temporärer Tensoren, schaffen aber nicht den persistenten Decode-Cache-Vorteil aus dem KV-Cache-Leitfaden. Produktions-Batching sollte daher nach Encoderlänge und Medientoken-Budgets geplant werden, nicht nach Generation Concurrency.
PLE ist ein tiefenabhängiger Inputpfad, kein Engram-Lookup
EmbeddingGemma 2 verwendet die reine Projektionsform von Per-Layer Embeddings. Nach der Medieninjektion wird der ursprüngliche Input [B, S, 512] einmal auf [B, S, 24 × 512] projiziert, mit 512^-0.5 skaliert, nach [B, S, 24, 512] umgeformt und per RMSNorm normalisiert. Schicht i erhält ihren eigenen Ausschnitt [B, S, 512].4
Nach den Attention- und MLP-Residualupdates dieser Schicht durchläuft der aktuelle Hidden State eine gelernte Projektion 512 -> 512 und GELU. Er wird elementweise mit dem schichtspezifischen PLE-Ausschnitt multipliziert, nochmals auf 512 projiziert, normalisiert und als weiterer Residualschritt addiert:
Dabei wird e_i aus dem Inputvektor an derselben Sequenzposition abgeleitet. So kann jede Tiefe eine gelernte Transformation des unveränderten Inputs heranziehen, statt ausschließlich auf Informationen aus vorherigen Residualblöcken angewiesen zu sein.
Das sollte nicht als Engram Memory bezeichnet werden. Der veröffentlichte PLE-Pfad besitzt weder Hash noch N-Gramm-Schlüssel, externe Tabelle oder sparsamen assoziativen Lookup. Er ist eine dichte, positionsgleiche Projektion der aktuellen Inputsequenz. Das übergeordnete Ziel kann ähnlich wirken—direkter Zugriff auf Inputidentität—doch Datenstruktur und Laufzeitverhalten unterscheiden sich.
Mean Pooling und Matryoshka-Kürzung
Der Textencoder projiziert jeden finalen Tokenzustand von 512 auf 768 Dimensionen. Sentence Transformers wendet dann Padding-Mask-aware Mean Pooling an und normalisiert das Ergebnis in FP32 per L2-Norm. Für die Gültigkeitsmaske m_t lautet die Ausgabe vor der Normalisierung
Matryoshka Representation Learning sorgt dafür, dass führende Präfixe dieses Vektors bereits nützliche Information tragen. Ein 256-dimensionaler Index behält beispielsweise z[:256] und normalisiert den gekürzten Vektor erneut. Das Abschneiden eines bereits normalisierten 768d-Vektors erhält seine Länge nicht. Queries und Korpuseinträge müssen außerdem dieselbe Dimension besitzen; andernfalls ist ihr Skalarprodukt nicht definiert.16
In FP32 belegt ein Rohvektor vor Indexmetadaten 3.072 Byte bei 768d, 2.048 bei 512d, 1.024 bei 256d oder 512 bei 128d. Die 128d-Form ist somit sechsmal kleiner. Sie reduziert nicht die Berechnung im Transformer oder Modalitätsturm, weil das Modell weiterhin die 768d-Repräsentation erzeugt und mittelt, bevor es sie kürzt.
Googles Full-Precision-Benchmarktabelle zeigt bei 512d und 256d nur kleine aggregierte Änderungen, bei 128d jedoch einen größeren Rückgang—besonders für die angegebene multimodale Suite. Das sind Herstellerbenchmarks, keine Zusage für einen Workload. Die Produktionsentscheidung muss empirisch fallen: dieselbe Recall- und Ranking-Evaluation für jede Kandidatendimension, einschließlich der Einstellungen des Approximate-Nearest-Neighbor-Indexes.
Betriebsgrenzen
EmbeddingGemma 2 besitzt eine reale Deployment-Oberfläche: einen 1,49-GB-Safetensors-Checkpoint, Support in Sentence Transformers und Transformers sowie dokumentierte Pfade für vLLM, SGLang, MLX, Ollama, LM Studio und LiteRT. Dennoch ist es eine Embeddingkomponente, kein vollständiges Suchsystem. Chunking, Metadatenfilter, ANN-Parameter, Reranking, Updates und Zugriffskontrolle bleiben Aufgaben der Anwendung.27
Mehrere Grenzen sind wichtiger als die Parameterzahl in der Überschrift:
- BF16 oder FP32 verwenden, nicht FP16. Google gibt an, dass der Aktivierungsbereich FP16 übersteigt und NaNs oder unbemerkt verschlechterte Vektoren entstehen können. BF16 besitzt dieselbe Exponentenbreite wie FP32; FP32 ist der sichere CPU-Fallback.1
- Task-Prefixe konsistent einsetzen. Asymmetrisches Retrieval benötigt unterschiedliche Prefixe für Query und Dokument. Prefixe gelten für Text, nicht für Bild-, Video- oder Audioinput.
- 8K als gemeinsames multimodales Budget behandeln. Ein längeres Video oder größeres Bildtoken-Budget verdrängt unmittelbar Text und erhöht die Kosten der vier globalen Attention-Schichten.
- Nur benötigte Türme laden. Selektives Laden reduziert residente Gewichte. Es lässt einen geladenen 740M-Checkpoint nicht ohne Anwendungssteuerung dynamisch einen Turm überspringen.
- MRL pro Korpus validieren. Ein kleinerer Vektor verändert neben Speicherbedarf auch Retrievalqualität und ANN-Verhalten.
Google berichtet für ein quantisiertes Deployment auf einem Pixel 11 Pro ungefähr 191 MB aktiven RAM im Text-only-Betrieb und 567 MB für das vollständige multimodale Modell. Das sind Herstellermessungen für ein bestimmtes Gerät und eine quantisierte Runtime, keine aus dem Full-Precision-Checkpoint ableitbaren Größen und keine universellen RAM-Zusagen.7
Der architektonische Tausch ist konkret. Soft Tokens schaffen eine gemeinsame Fusionsschnittstelle, verbrauchen aber dasselbe knappe Kontextbudget wie Text. Hybride Attention begrenzt den Großteil paarweiser Arbeit, behält jedoch vier quadratische globale Schichten. PLE gibt jeder Schicht einen direkten Inputpfad, ohne externe Speichertabelle. MRL komprimiert den Vektorindex, nicht den Encoderlauf. Diese Unterschiede bestimmen ein Produktionsdesign; die Bezeichnung 740M allein tut es nicht.
Quellen
Footnotes
-
Google DeepMind, offizielle Model Card für EmbeddingGemma 2, aktualisiert am 6. Oktober 2026. ↩ ↩2 ↩3 ↩4 ↩5
-
Google, veröffentlichter
embeddinggemma-2-Checkpoint auf der versionierten Revision914f7f8. ↩ ↩2 -
Hugging Face, versionierte Transformers-Implementierung von EmbeddingGemma 2. ↩ ↩2 ↩3
-
Hugging Face, versionierte Processing-Implementierung von EmbeddingGemma 2. ↩ ↩2
-
Google, veröffentlichte Modulkonfiguration für Sentence Transformers. ↩
-
Google AI Edge, On-Device-Deployment von EmbeddingGemma 2 und gemessener Pixel-11-Pro-Speicher. ↩ ↩2