Ein Embedding-Modell für RAG wählen: Warum die Wechselkosten wichtiger sind als der Preis

2026 werden Embedding-Modelle oft sorgfältig verglichen und entscheiden dabei doch eine Frage, die kaum ins Gewicht fällt. Tabellen listen den Preis pro Million Tokens. Retrieval-Tests laufen nebeneinander auf zweihundert Beispieldokumenten. Eine Woche geht für Vektordimensionen drauf. Dann wird ein Modell gewählt, das System geht live, und ein halbes Jahr später trifft das Team auf Kosten, die niemand eingeplant hat.

Hier ein Argument, das zunächst falsch klingt, aber standhält. Bei den meisten produktiven RAG-Systemen ist der Unterschied bei den Monatskosten zwischen gehosteten Embedding-Optionen nahe an einem Rundungsfehler. Was die Architektur wirklich prägt, ist, was es kostet, später den Kurs zu ändern. Die Rechnung ist das ganze Argument, deshalb kommt sie zuerst.

Drei Achsen, meist verkehrt herum gewichtet

Embedding-Modelle unterscheiden sich in drei Punkten, und Teams bringen sie oft in die falsche Reihenfolge.

• Die Retrieval-Qualität wird zuerst gebenchmarkt. Sie wird öffentlich auf MTEB gemessen, und sie ist real, doch die Spanne unter den Spitzenreitern ist viel enger, als das Marketing suggeriert.
• Die Kosten landen in der Präsentation. Sie werden normalerweise pro Million Tokens angegeben, wodurch sie wie die dominierende Variable wirken. Das sind sie nicht, wie die Zahlen unten zeigen.
• Die betriebliche Seite wird fast nie bewertet. Wer betreibt das Modell? Was passiert, wenn der Anbieter es abkündigt? Wie lange dauert ein vollständiger Neuaufbau des Index? Kann das Modell überhaupt laufen, wenn Compliance verlangt, dass Dokumente im Netzwerk bleiben?

Die These: Qualitätsunterschiede an der Spitze sind zu klein, um ein Produktergebnis zu verändern, Kostenunterschiede sind zu klein, um ein Budget zu verändern, und die betriebliche Seite ist die Achse, die still entscheidet, wie stark du am Ende gebunden bist.

Was Embeddings wirklich kosten

Der Preis ist der Bezugspunkt für alles, also fangen wir dort an. OpenAIs text-embedding-3-small kostet $0.02 pro Million Tokens und gehört damit 2026 zu den kostengünstigsten gehosteten Optionen.

Übertragen wir das auf eine realistische Last. Nimm einen Korpus von hundert Millionen Tokens, eine wirklich große interne Wissensdatenbank, und indexiere alles:

corpus_tokens      = 100_000_000
price_per_million  = 0.02            # text-embedding-3-small
index_build_cost   = corpus_tokens / 1_000_000 * price_per_million
# 2.0

Zwei Dollar. Das ist die gesamte API-Rechnung, um einen Korpus von hundert Millionen Tokens einmal zu embedden.

Auf der Abfrageseite sieht es ähnlich aus. Bei fünfhunderttausend Abfragen im Monat mit text-embedding-3-small kostet das Embedden der Abfragen etwa $3.25 monatlich. Neben einer Inferenzrechnung, einer Rechnung für den Vektorspeicher und dem Nachmittag eines einzigen Engineers ist das Rauschen.

Und das größere text-embedding-3-large? Es kostet mehr pro Token und schneidet in öffentlichen Benchmarks besser ab. Die ehrliche Regel, wann man danach greift: erst, nachdem man einen Retrieval-Fehler gemessen hat, den bessere Embeddings beheben würden. Ist das oberste Ergebnis falsch, weil Chunks schlecht geschnitten sind oder weil Abfragen den Dokumenten im Sinne der Kosinus-Ähnlichkeit nicht gleichen, hilft ein stärkerer Encoder nicht. Er macht ein falsches Retrieval nur etwas selbstsicherer.

Dieselbe Überlegung gilt für die Frage ältere ada-002 gegen 3-small. 3-small ist günstiger und im Allgemeinen stärker, ein Greenfield-Projekt hat also eine einfache Antwort. Ist bereits ein Index gebaut, spielt der Preis keine Rolle, wie der Abschnitt zur Migration unten erklärt.

OpenAI gegen Cohere

Dieser Vergleich taucht in fast jedem Architektur-Review auf und wird meist als Qualitätsfrage gerahmt, obwohl es eigentlich darum geht, was passt. Ein Vorbehalt: Aktuelle veröffentlichte Preise und Benchmark-Zahlen von Cohere liegen hier nicht vor, deshalb wird nichts erfunden. Sagen lässt sich, wo sich die Form der Entscheidung unterscheidet.

Cohere hat Embed v3 auf mehrsprachiges Retrieval und Suchrelevanz ausgerichtet, nicht darauf, der günstigste Allzweck-Encoder zu sein. Bei einem wirklich mehrsprachigen Korpus, vor allem wenn Nutzer in einer Sprache nach Dokumenten in einer anderen suchen, ist das die Achse, die du an deinen eigenen Daten testen solltest, statt einem Leaderboard zu vertrauen. Sprachübergreifendes Retrieval ist der Bereich, in dem die Modellwahl noch verändert, was Nutzer sehen, denn ein Modell, das damit schlecht umgeht, verschlechtert sich nicht sanft. Es liefert Dokumente, die mit voller Überzeugung irrelevant sind.

Die praktische Anweisung ist eng gefasst. Bei einer rein englischen Last ist der Vergleich größtenteils akademisch, also entscheide nach betrieblichen Gesichtspunkten. Alle anderen sollten ein Evaluationsset von etwa hundert Abfragen in den echten Sprachen aufbauen und es vor der Festlegung durchlaufen lassen, denn hier verallgemeinern Benchmarks am schlechtesten.

Lokale Modelle verändern die Frage

Eine Zahl verändert das Bild: Lokale Embedding-Modelle wie Nomic Embed und BGE liegen auf MTEB höchstens fünf Prozent hinter text-embedding-3-large und senken die Kosten pro Token bei hohem Volumen auf null.

Das sind fünf Prozent auf einem öffentlichen Benchmark, der ohnehin übertreibt, wie stark die Modellwahl die Ergebnisse auf einem bestimmten Korpus verschiebt.

Ein Modell lokal zu betreiben, ist daher keine Sparmaßnahme. Die Rechnung der gehosteten API war schon winzig, und ein Modell im Stil von sentence-transformers auf der eigenen GPU zu hosten, kostet ebenfalls: die Instanz, das Deployment und wer um drei Uhr morgens dafür Bereitschaft hat.

Self-Hosting gewinnt in drei Punkten, alle betrieblich:

1. Datenresidenz. Dürfen Dokumente deine Infrastruktur nicht verlassen, ist die Debatte beendet, und offen bleibt nur, welches lokale Modell.
2. Planbarer Durchsatz. Nichts begrenzt Anfragen außer den Einstellungen, die du gewählt hast, und es gibt keine nutzungsbasierte Rechnung zu prognostizieren. Eine Pipeline, die ihren Index rund um die Uhr neu aufbaut, profitiert von dieser Stabilität mehr als vom Wegfall der Token-Gebühren.
3. Kontrolle über den eigenen Vektorraum, was am meisten zählt und am wenigsten diskutiert wird.

Die wahren Wechselkosten

Jeder Vektor in einem Index stammt von einem bestimmten Modell. Vektoren verschiedener Modelle lassen sich nicht vergleichen, und es gibt keine Umrechnung zwischen ihnen. Wechselst du das Modell, wird jeder gespeicherte Vektor gegenüber neuen Abfragen bedeutungslos.

Ein Modellwechsel bedeutet also, den ganzen Index neu aufzubauen. Hier führt die übliche Kostendarstellung in die Irre. Für das erneute Embedden eines großen Korpus werden beängstigende Summen genannt, doch bei echten Tokenpreisen ist der API-Anteil klein. Nimm hundert Millionen Tokens zu $0.02 pro Million: Das sind zwei Dollar, und selbst ein zehnmal teureres Modell hält die Summe im niedrigen dreistelligen Bereich.

Die wahren Kosten sind keine Zeile im Token-Budget. Es ist alles drumherum:

• Die Pipeline, die jedes Dokument erneut aus dem Speicher holen und dasselbe Chunking-Schema anwenden muss, das womöglich gar nicht aufbewahrt wurde.
• Der parallele Index, der laufen muss, solange beide Versionen live sind, denn ein produktiver Vektorspeicher lässt sich während der Geschäftszeiten nicht atomar austauschen.
• Die Retrieval-Evaluation, die von Grund auf neu gemacht werden muss, weil jeder Relevanzschwellenwert auf den alten Vektorraum abgestimmt war.
• Zwei oder drei Wochen Engineering-Aufmerksamkeit, die in genau das Quartal fallen, in dem das Problem auftaucht.

Das ist die Falle. Sie kommt nicht als unerwartete Rechnung. Sie kommt als unerwartetes Projekt.

Daraus ergibt sich eine einfache Auswahlregel: Bevorzuge das Modell, das dir am wenigsten wahrscheinlich unter den Füßen weggezogen wird. Die Erfolgsbilanz des Anbieters, eine klare Abkündigungsrichtlinie und die Möglichkeit, eine Version festzuschreiben, zählen mehr als ein zusätzlicher Benchmark-Punkt, weil sie bestimmen, ob eine Migration überhaupt erzwungen wird. Ein geringfügig schwächeres Modell vier Jahre zu behalten, ist besser, als ein geringfügig stärkeres einzuführen und es nach achtzehn Monaten fallen zu lassen.

Eine kurze Entscheidungshilfe

• Englischer Korpus, Neubau: text-embedding-3-small. Der günstigste glaubwürdige Start, und bei echtem Volumen sind die Kosten vernachlässigbar.
• Gemessene Retrieval-Fehler, die ein stärkerer Encoder beheben würde: text-embedding-3-large, aber erst, wenn es Belege gibt.
• Mehrsprachiges oder sprachübergreifendes Retrieval: Cohere Embed v3, an den eigenen Daten evaluiert, denn hier zeigt sich die Modellwahl noch im Nutzererlebnis.
• Dokumente, die das Netzwerk nicht verlassen dürfen: selbst gehostetes Nomic Embed oder BGE. Hier entscheidet Compliance, nicht der Preis.
• Sehr hohes Volumen an kontinuierlicher Neuindexierung: ein lokales Modell, das Rate Limits und Abrechnung pro Anfrage aus dem Design entfernt.

Nur zwei dieser Zeilen entscheidet das Modell selbst. Den Rest entscheiden Rahmenbedingungen, die unabhängig von der Modellwahl bestehen.

Häufige Fragen

Welches Embedding-Modell ist 2026 das günstigste? Unter den gehosteten Optionen liegt text-embedding-3-small mit $0.02 pro Million Tokens preislich fast ganz unten und bleibt dabei glaubwürdig. Lokale Optionen wie Nomic Embed und BGE haben gar keine Gebühr pro Token, dafür zahlst du mit Hardware und Betreuung. So oder so sind die Beträge klein genug, dass der Preis für die meisten Teams nicht den Ausschlag geben sollte.

Sollten Embeddings von OpenAI oder Cohere kommen? Bei rein englischen Lasten entscheide nach betrieblichen Gesichtspunkten, denn der Qualitätsunterschied wird nicht das sein, was das Produkt begrenzt. Bei mehrsprachigen oder sprachübergreifenden Lasten baue ein Evaluationsset in den tatsächlichen Sprachen und teste beide, denn dort sehen Nutzer einen Unterschied.

Was kostet es, einen großen Korpus neu zu embedden? An API-Gebühren weniger, als die meisten vermuten: etwa zwei Dollar für hundert Millionen Tokens bei $0.02 pro Million. Weh tut die Arbeit drumherum, also jedes Dokument neu zu extrahieren und zu chunken, zwei Indizes während der Umstellung am Leben zu halten und jede Retrieval-Evaluation im neuen Vektorraum zu wiederholen. Plane in Wochen, nicht in Tokens.

Das Fazit: Vergleiche die Modelle ruhig, aber investiere die gesparte Sorge in den Migrationspfad statt in die Preisliste. Die Wahl eines Modells ist eine kleinere Entscheidung, als es sich anfühlt. Der Index, der darum herum gebaut wird, ist eine weit größere.