Die Wahl des Embedding-Modells wirkt wie der einfache Teil beim Bau einer Retrieval-Pipeline. Man nimmt das Modell, das alle nehmen, schickt einen String hin, bekommt ein Float-Array zurück und wendet sich dem interessanten Problem zu. Der Modellname steht in einer Zeile Konfiguration und fühlt sich an wie etwas, das man an einem Dienstag ändern kann.
Ist er nicht. Diese eine Zeile legt die Breite jedes Vektors fest, den Sie jemals speichern werden, die Größe Ihres Index, die Form Ihres Datenbankschemas und den Preis dafür, es sich anders zu überlegen. Embedding ist der billigste Teil einer Retrieval-Pipeline im Betrieb und einer der teuersten in der Wiederholung. Dieser Text behandelt die vier Dinge, die die Entscheidung wirklich bestimmen — Dimensionen, Hardware, Preis und Migration — und warum die Spitze des Leaderboards fast nie die richtige Antwort ist.

Was Sie tatsächlich auswählen
Ein Embedding-Modell verwandelt Text in einen Vektor fester Länge, in dem Abstand ungefähr Bedeutung abbildet. Das leistet jedes Modell am Markt. Unterschiede gibt es in vier Eigenschaften, und nur eine davon ist Qualität.
Ausgabedimension — wie viele Floats zurückkommen. Das ist Ihr Schema. Es bestimmt Speicher, Indexgröße, Speicherdruck und Vergleichskosten und ist die Eigenschaft, die sich am schwersten nachträglich ändern lässt.
Kontextlänge — wie viel Text in einen Aufruf passt. Die v3-Modelle von OpenAI nehmen 8.192 Token, die aktuellen Voyage-Modelle 32.000, Coheres embed-v4.0 sogar 128.000. Viel Kontext klingt uneingeschränkt besser, ändert aber vor allem, wie viel Chunking nötig ist — und über Retrieval-Qualität entscheidet ohnehin meist das Chunking.
Wo es läuft — gehostete API oder ein Modell, das Sie herunterladen und selbst betreiben. Das ist zuerst eine Frage von Datenhoheit und Abhängigkeit, erst danach eine Kostenfrage.
Retrieval-Qualität auf Ihren Daten — nicht auf einem Benchmark. Dazu gleich mehr.
Es gibt eine fünfte Eigenschaft, die fast niemand prüft: was das Modell weiß. OpenAI dokumentiert unmissverständlich, dass text-embedding-3-large und text-embedding-3-small keine Kenntnis von Ereignissen nach September 2021 haben. Für die meisten Ähnlichkeitsaufgaben ist das belanglos. Steckt Ihr Korpus aber voller Produktnamen und Begriffe, die es damals noch nicht gab, embedded das Modell unbekannte Token.
Das Leaderboard ist nicht die Antwort
MTEB — der Massive Text Embedding Benchmark, später zu MMTEB für mehrsprachige Abdeckung erweitert — ist die Standard-Rangliste. Sie ist wirklich nützlich, und sie wird regelmäßig als Empfehlung missverstanden, welches Modell man nehmen sollte.
Warum, zeigt diese Tabelle. Sie ist eine Momentaufnahme, keine aktuelle Rangliste: die mehrsprachigen Werte, wie sie das Qwen-Team in der Modellkarte zu Qwen3-Embedding-0.6B berichtet, entnommen dem MTEB-Leaderboard am 24. Mai 2025. Lesen Sie sie als Lehrstück, nicht als heutigen Stand:
| Modell | Parameter | MTEB mehrsprachig, Mittelwert |
|---|---|---|
| Qwen3-Embedding-8B | 8B | 70,58 |
| Qwen3-Embedding-4B | 4B | 69,45 |
| Gemini Embedding | — | 68,37 |
| Qwen3-Embedding-0.6B | 0,6B | 64,33 |
| multilingual-e5-large-instruct | 0,6B | 63,22 |
| Cohere-embed-multilingual-v3.0 | — | 61,12 |
| BGE-M3 | 0,6B | 59,56 |
| text-embedding-3-large | — | 58,93 |
Zwei Dinge fallen auf. In dieser Momentaufnahme stand die Standardwahl der meisten Teams — das Flaggschiff-Embedding-Modell von OpenAI — am Ende der Tabelle, unterhalb eines offenen 0,6B-Modells, das Sie selbst betreiben können. Und das 0,6B-Modell lag rund sechs Punkte hinter dem 8B-Modell, bei einem Bruchteil der Betriebskosten.
Nun die Einschränkungen, die wichtiger sind als die Rangfolge. Es handelt sich um herstellerberichtete Zahlen aus einer einzigen Momentaufnahme eines einzigen Benchmarks, und beides hat sich seither bewegt: MTEB umfasst inzwischen über tausend Aufgaben in mehr als tausend Sprachen und deckt zusätzlich Bild und Audio ab. Was das Leaderboard heute anzeigt, sind sicher nicht diese Zahlen. Der mehrsprachige Mittelwert mittelt zudem über Retrieval, Klassifikation, Clustering, Bitext Mining und mehr, während Ihre Anwendung genau eine dieser Aufgaben erledigt. Über Ihre Domäne, Ihr Sprachpaar, Ihr Latenzbudget, Ihre Dimensionen und Ihre Lizenz sagt der Wert nichts.
Was die Veralterung überlebt, ist die Lehre — und nur sie zählt: Das bekannteste Modell ist nicht automatisch das beste, und ein kleines offenes Modell kann mithalten. Nutzen Sie das Leaderboard, um drei oder vier Kandidaten in die engere Wahl zu nehmen, und schauen Sie dabei auf die Live-Ansicht statt auf eine Tabelle in einem Blogbeitrag. Entscheiden Sie dann auf dem einzigen Weg, der zählt: hundert echte Anfragen, für jede markiert, welcher Abschnitt zurückkommen soll, und messen. Diese Testmenge ist wertvoller als das Modell, das Sie damit auswählen — denn sie überlebt jede künftige Migration.
Dimensionen sind eine Speicherrechnung
Das ist der Teil, der erst in der Produktion auffällt.
Ein Vektor ist nicht umsonst aufzubewahren. In Postgres mit pgvector belegt eine vector-Spalte 4 Byte pro Dimension plus 8 Byte Overhead, halfvec 2 Byte pro Dimension plus 8. Hochgerechnet wird die Modellwahl zum Posten in der Rechnung:
| Dimensionen | Typ | Byte pro Vektor | Pro 1 Mio. Vektoren |
|---|---|---|---|
| 384 | vector |
1.544 | 1,5 GB |
| 1.024 | vector |
4.104 | 4,1 GB |
| 1.536 | vector |
6.152 | 6,2 GB |
| 3.072 | vector |
12.296 | 12,3 GB |
| 3.072 | halfvec |
6.152 | 6,2 GB |
Das ist reiner Spaltenspeicher, ohne Index- und Zeilen-Overhead. In der Praxis ist der Index die größere Zahl — und er möchte in den Arbeitsspeicher passen.

Dann kommt eine harte Wand. pgvector indexiert vector-Spalten bis 2.000 Dimensionen. Ein 3.072-dimensionales Embedding aus text-embedding-3-large lässt sich überhaupt nicht hinter einen einfachen HNSW- oder IVFFlat-Index legen — es braucht halfvec, Quantisierung oder einen schmaleren Vektor. Diesen Mechanismus habe ich ausführlich in Brauchst du eine Vektordatenbank behandelt, und hier treffen sich beide Entscheidungen: Das gewählte Modell kann die Speicher-Engine disqualifizieren, die Sie bereits betreiben.
Die gute Nachricht: Meist dürfen Sie weniger Dimensionen anfordern. OpenAI dokumentiert, dass die eigenen v3-Modelle mit Matryoshka Representation Learning trainiert sind, das die wichtigsten Informationen in die vorderen Dimensionen packt, sodass sich das Ende abschneiden lässt. Qwen weist dieselbe Fähigkeit für seine Embedding-Modelle aus, und Voyage bietet einen entsprechenden Parameter output_dimension. In der API von OpenAI heißt er dimensions:
from openai import OpenAI
client = OpenAI()
# Standardmäßig 3.072 Dimensionen — zu breit für einen pgvector-Index.# Mit 1.024 passt es, bei überschaubarem Qualitätsverlust.response = client.embeddings.create( model="text-embedding-3-large", input="Wie rotiere ich einen Service-Account-Schlüssel?", dimensions=1024,)Das zentrale Ergebnis aus OpenAIs eigener Dokumentation verdient eine präzise Formulierung: Auf MTEB schlägt ein auf 256 Dimensionen gekürztes text-embedding-3-large-Embedding immer noch ein ungekürztes text-embedding-ada-002-Embedding mit 1.536 Dimensionen. Sechsmal schmaler und trotzdem besser. Wenn Sie Vektoren in Standardbreite speichern, weil der Beispielcode es so machte, zahlen Sie sehr wahrscheinlich für Dimensionen, die Sie nicht vermissen würden.
Voyage geht weiter und lässt auch den Ausgabedatentyp wählen — int8, uint8 oder bitgepacktes binary, wobei das zurückgegebene Array nur ein Achtel der Länge hat. Das ist dieselbe Idee wie beim Quantisieren eines Sprachmodells, angewandt auf den Ausgabevektor statt auf die Gewichte.
Braucht es eine GPU?
Diese Frage kommt ständig und wird meist schlecht beantwortet, in der Regel von Leuten, die nur generative Modelle betrieben haben.
Ein Embedding-Modell ist ein Encoder. Ein Vorwärtsdurchlauf über die Eingabe, ein Pooling-Schritt, fertig. Keine autoregressive Schleife, kein KV-Cache, der pro Token wächst, kein Sampling. Ein 0,6B-Embedding-Modell und ein 0,6B-Chatmodell sind nicht im Entferntesten dieselbe Last. Und weil jede Eingabe im Batch unabhängig ist, parallelisiert Embedding nahezu perfekt: Der Durchsatz skaliert mit der Batchgröße, bis der Speicher ausgeht.
Damit hängt die Antwort davon ab, auf welcher Seite der Pipeline Sie stehen.
Zur Abfragezeit wird eine kurze Zeichenkette pro Request embedded. Das schafft eine CPU bequem. Sentence Transformers empfiehlt ausdrücklich, kleine Embedding-Modelle in latenzkritischen lokalen Setups auf die CPU zu legen, damit sie nicht mit einem generativen Modell auf derselben GPU um VRAM und Rechenzeit konkurrieren.
Zur Indexzeit werden Millionen Abschnitte embedded. Hier geht es bei der GPU darum, heute fertig zu werden statt übers Wochenende. Das ist eine Terminfrage, keine Architekturentscheidung — und meist eine gemietete Maschine für ein paar Stunden, kein dauerhafter Posten.

Wenn Sie den CPU-Weg gehen, betreiben Sie kein rohes PyTorch. Sentence Transformers unterstützt drei Backends — PyTorch, ONNX und OpenVINO — und liefert Hilfsfunktionen zum Export und zur int8-Quantisierung für CPU-Inferenz mit. Die eigene Entscheidungshilfe lautet sinngemäß: Auf der GPU Flash Attention nutzen, sofern das Modell es unterstützt; auf der CPU zuerst klären, ob ein kleiner Genauigkeitsverlust akzeptabel ist, dann OpenVINO auf Intel-Hardware und ONNX auf allem anderen.
from sentence_transformers import SentenceTransformer
# int8-quantisierter ONNX-Build, einmal exportiert und wiederverwendet.model = SentenceTransformer( "sentence-transformers/all-MiniLM-L6-v2", backend="onnx", model_kwargs={"file_name": "onnx/model_qint8_avx512_vnni.onnx"},)
embeddings = model.encode(chunks, batch_size=64)Für einen Serving-Pfad statt eines Skripts liefert Hugging Face mit Text Embeddings Inference Container-Images für GPU und CPU. Damit wird aus „ein Embedding-Modell betreiben” ein Deployment statt eines Python-Prozesses, für den sich jemand zuständig fühlt.
Das Extrem der CPU-Argumentation sind statische Embedding-Modelle: ohne Attention, drastisch schneller, spürbar schwächer. Es gibt sie, sie sind dokumentiert, und für Ähnlichkeitssuche in hohem Volumen bei geringem Risiko sind sie eine echte Option — die einen Benchmark verdient, bevor Sie Hardware für nötig halten.
Was die API wirklich kostet
Gehostetes Embedding ist auf eine Weise billig, die sich leicht in beide Richtungen missverstehen lässt.
Die veröffentlichten Preise von OpenAI:
| Modell | Dimensionen | Preis pro 1 Mio. Token | Seiten pro Dollar |
|---|---|---|---|
| text-embedding-3-small | 1.536 | 0,02 $ | ~62.500 |
| text-embedding-3-large | 3.072 | 0,13 $ | ~9.615 |
| text-embedding-ada-002 | 1.536 | 0,10 $ | ~12.500 |
Die Spalte mit den Seiten pro Dollar stammt von OpenAI selbst und rechnet mit rund 800 Token pro Seite. Beachten Sie die dritte Zeile: ada-002 kostet das Fünffache von text-embedding-3-small und schneidet auf MTEB schlechter ab — 61,0 % gegenüber 62,3 % in OpenAIs eigener Tabelle. Steht es noch in Ihrem Code, dann nur, weil es niemand überprüft hat.
Trennen Sie die Kosten nun nach Phase, denn beide verhalten sich völlig unterschiedlich.
Abfragen sind praktisch kostenlos. Eine Suchanfrage hat vielleicht fünfzehn Token. Eine Million Anfragen sind fünfzehn Millionen Token, also dreißig Cent beim kleinen Modell. Das taucht auf keiner Rechnung sichtbar auf.
Die Indexierung ist die Rechnung. Fünf Milliarden Token — ein ernsthafter Korpus — kosten rund 100 Dollar mit text-embedding-3-small und rund 650 Dollar mit text-embedding-3-large. Immer noch wenig. Genau deshalb ist der nächste Abschnitt wichtig, denn diese Summe fällt nicht nur einmal an.
Dem gegenüber ist Self-Hosting ebenfalls nicht umsonst: eine GPU-Instanz für das Indexierungsfenster, Entwicklungszeit, ein Container, der gepatcht werden will, und eine Modelldatei, die versioniert werden muss. Der ehrliche Umschlagpunkt liegt selten beim Tokenpreis. Er liegt darin, ob Ihre Texte Ihre Infrastruktur verlassen dürfen, ob Sie eine Modellversion festschreiben müssen, die kein Anbieter unter Ihnen abkündigen kann, und ob Sie ohnehin schon Inferenz-Hardware für etwas anderes betreiben. Trifft nichts davon zu, ist die API zu diesen Preisen sehr schwer zu schlagen.
Die Migration, die niemand einplant
Hier liegt die Falle.
Vektoren aus zwei verschiedenen Modellen sind nicht vergleichbar. Nicht „ungenauer” — bedeutungslos. Andere Dimensionalität, andere Geometrie, anderes Trainingsziel. Es gibt keine Umrechnung. Ein Modellwechsel bedeutet also, jeden jemals gespeicherten Abschnitt neu zu embedden und jeden Index darüber neu zu bauen.
Deshalb ist die Indexierungssumme von oben die Zahl, um die herum Sie planen sollten. Sie ist keine einmalige Einrichtungsgebühr, sondern der Preis für jede künftige Meinungsänderung zu Ihrem Embedding-Modell. Bei 650 Dollar pro vollem Durchlauf ist das Geld nebensächlich, die betriebliche Choreografie nicht — halb migrierte Ergebnisse können Sie nicht ausliefern, denn eine mit dem neuen Modell embeddete Anfrage gegen Dokumente aus dem alten Modell liefert Rauschen.
Das Muster, das funktioniert, ist ein Schattenindex:
- Eine zweite Vektorspalte oder eine zweite Collection neben der aktiven anlegen.
- Sie im Hintergrund befüllen, so schnell es Budget und Rate Limits zulassen.
- Die eigene Testmenge gegen beide laufen lassen. Auf Ihren Anfragen vergleichen, nicht auf einem Leaderboard.
- Lesezugriffe hinter einem Flag umschalten, die alte Spalte für ein Rollback-Fenster behalten, dann verwerfen.
Zwei Dinge machen diese Migration billiger, lange bevor Sie sie brauchen. Speichern Sie Modellnamen und Dimensionszahl neben jedem Vektor, damit eine teilmigrierte Tabelle lesbar bleibt statt zum Rätsel zu werden. Und behalten Sie den Rohtext des Abschnitts, nicht nur seinen Vektor — müssen Sie den Quelltext erst von anderswo rekonstruieren, wird aus dem Hintergrundjob ein Projekt. Beides kostet am ersten Tag nichts und entscheidet später über ein Wochenende oder ein Quartal. Derselbe Instinkt gilt für das Chunking selbst, worauf ich im Context Engineering eingehe.
Das Fazit
Beginnen Sie mit text-embedding-3-small bei 1.536 Dimensionen — oder mit einem kleinen offenen Modell wie Qwen3-Embedding-0.6B, wenn die Texte Ihre Infrastruktur nicht verlassen dürfen. Beide sind günstig, beide sind schnell, und beide sind gut genug, um die restliche Pipeline dagegen zu bauen.
Erledigen Sie dann die vier Dinge, auf die es ankommt. Bauen Sie eine Testmenge aus echten Anfragen mit bekannter richtiger Antwort, denn sie überlebt jedes Modell, das Sie einsetzen werden. Fordern Sie weniger Dimensionen an als vorgegeben und messen Sie den Verlust — oft ist er nicht nachweisbar, bei halbem Speicherbedarf. Gehen Sie davon aus, dass Sie das Modell wechseln, und speichern Sie Modellnamen und Rohtext, damit dieser Tag ein Hintergrundjob bleibt. Und nutzen Sie das Leaderboard für eine Vorauswahl, niemals für die Entscheidung.
Das Modell ist die leichte Entscheidung. Die Vektorbreite ist das Schema, und mit dem Schema leben Sie.




Aus der Community
Diskussion im Fediverse
Antworten von Mastodon und Bluesky — direkt aus dem offenen Netz, ohne Tracking.
Antworten werden geladen …
Noch keine Antworten. Starte die Diskussion:
Antworten konnten gerade nicht geladen werden.