Auf den ersten Blick berechnet eine Embedding API nur Input-Token, ohne Output. Doch nach einigen Monaten im RAG-Betrieb liegt die Budgetüberschreitung selten an „zu vielen Abfragen“. Häufiger sind es die Gesamtmenge der zerlegten Dokumente, das vollständige Re-Embedding nach einem Modellwechsel und die Speicher- sowie Anfragekosten der Vektordatenbank, die sich summieren.

Dieser Artikel zerlegt diese Kostenpositionen und gibt eine Reihenfolge für die Schätzung sowie Prioritäten für die Senkung. Stückpreise ändern sich; maßgeblich sind die Preisübersicht und die Anbieterdokumentation. Feste Zahlen nennt dieser Beitrag bewusst nicht.

Hinweis: OpenAI, DeepSeek und weitere genannte Namen sind Marken der jeweiligen Rechteinhaber. Der Artikel beschreibt die übliche Schnittstellenform im Oktober 2026. Modellnamen, Abrechnungsregeln und Preise können sich ändern; prüfen Sie vor dem Einkauf erneut die offiziellen Seiten.

1. Abgerechnet wird Input-Token, nicht die Anzahl der Aufrufe

Die meisten Embedding-Schnittstellen berechnen nur den Input und erzeugen keine Output-Token-Kosten. Der Input ist der Text, der vektorisiert werden soll: Titel, Fließtext, aus Tabellen konvertierter Text, aber auch HTML-Tags, Navigationsleisten und überflüssige Leerzeichen.

Bei der Schätzung gibt es vier Kostentreiber:

  • Tokenizer-Unterschiede: Ein chinesisches Zeichen entspricht nicht zwingend einem Token, und verschiedene Modelle segmentieren unterschiedlich. Schätzen Sie nicht nach Zeichenzahl, sondern senden Sie zunächst eine kleine Stichprobe und lesen Sie das usage-Feld der Antwort.
  • Überlappung beim Chunking: Um Kontext zu erhalten, werden Blöcke oft mit 10 bis 20 Prozent Überlappung erzeugt. Dieser Text wird mehrfach berechnet. Je größer die Überlappung, desto teurer der Indexaufbau.
  • Schmutztext: Kopf- und Fußzeilen, Template-Formulierungen und wiederholte Inhaltsverzeichnisse werden zum normalen Token-Preis abgerechnet, liefern aber keinen Retrieval-Nutzen.
  • Mehrfacher Indexaufbau: Dieselben Dokumente werden in Test, Vorabumgebung und Produktion jeweils neu eingebettet; die Kosten vervielfachen sich mit der Anzahl der Umgebungen.
Kostenposition Wann sie entsteht Abrechnung durch Häufig übersehen
Input-Token Vektorisierung von Dokumenten und Abfragen Embedding-Anbieter Chunk-Überlappung, Kopf-/Fußzeilen, doppelte Indizes
Batch-Aufgaben Offline-Vollindex und inkrementelle Updates Batch-Schnittstelle des Anbieters Ob der Batch-Rabatt tatsächlich greift
Re-Embedding Modellwechsel, Dimensionsänderung, neues Chunking Embedding-Anbieter Vollständiger Neuaufbau und doppelte Speicherung während der Umstellung
Vektorspeicher Ablage von Vektoren und Index Vektordatenbank oder Cloud-Plattform Replikate, Backups, Indexwachstum
Retrieval und Egress Lesen von Vektoren pro Abfrage Datenbank oder Cloud-Plattform Regionsübergreifender Zugriff, Spitzen-QPS
Generierungsaufrufe Übergabe der Treffer an ein großes Modell Modellanbieter Wird oft fälschlich den Embedding-Kosten zugerechnet

Die letzte Zeile verdient Betonung: Günstige Embeddings bedeuten nicht, dass RAG insgesamt günstig ist. Die Trefferblöcke gehen zur Antwortgenerierung an ein großes Modell, und diese Input-Token liegen häufig deutlich über den Vektorisierungskosten. Kalkulieren Sie beide Stufen getrennt.

2. Batch-Schnittstelle: niedrigerer Stückpreis gegen Zeit

Viele Plattformen berechnen Batch-Aufträge günstiger als Echtzeit-Anfragen. Der Preis dafür sind Warteschlangen, Antwortzeiten in Stunden und möglicherweise Einschränkungen bei Modellen und Anfragegröße. Batch eignet sich für den erstmaligen Indexaufbau, nächtliche inkrementelle Synchronisation und Offline-Evaluierung, nicht für die Vektorisierung einer Nutzerfrage in Echtzeit.

Prüfen Sie vor der Nutzung drei Punkte:

  1. Ob Batch-Aufträge ein eigenes Limit haben und mit Echtzeit-Anfragen um Kontingente konkurrieren.
  2. Ob fehlgeschlagene oder teilweise erfolgreiche Anfragen abgerechnet werden und wer die Wiederholungskosten trägt.
  3. Ob das Gateway den Batch-Rabatt des Upstream weitergibt. Nicht jedes Gateway tut das; fragen Sie vor dem Einkauf nach oder prüfen Sie es anhand der ersten Rechnung.

Batch bedeutet nicht unbegrenzte Parallelität. Hunderttausende Elemente in einem Auftrag lösen leicht Drosselung oder einen Fehlschlag aus. Teilen Sie nach Größe auf, protokollieren Sie Token und Laufzeit pro Batch und wiederholen Sie nur fehlgeschlagene Batches, statt alles neu zu starten.

3. Re-Embedding: die am häufigsten unterschätzte Einmalkostenposition

Folgende Änderungen erfordern in der Regel ein vollständiges Re-Embedding:

  • Wechsel des Embedding-Modells oder ein Modell-Upgrade, das den Vektorraum verändert.
  • Änderung der Vektordimension; alte und neue Vektoren lassen sich nicht mischen.
  • Änderung der Chunking-Regeln, der Bereinigungsregeln oder der Dokumentanalyse.
  • Aufnahme einer neuen Sprache, für die das bisherige Modell nicht ausreicht.

Die Kosten des Re-Embeddings umfassen nicht nur die Aufrufe, sondern auch die Laufzeit, die parallele Speicherung alter und neuer Indizes und mögliche Qualitätsschwankungen beim Retrieval während der Umstellung. Bei einer großen Wissensdatenbank kann dieser Betrag alle bisherigen Abfragekosten übersteigen.

Risiken lassen sich so begrenzen:

  • Den Originaltext als maßgebliche Quelle behalten; Vektoren sind abgeleitete Daten und jederzeit neu erzeugbar.
  • In den Index-Metadaten Modellname, Version, Dimension und Chunking-Parameter festhalten.
  • Nach dem Aufbau des neuen Index mit einem festen Fragenset vergleichen, bevor der Verkehr umgeschaltet wird.
  • Im Alltag nur neue und geänderte Dokumente inkrementell einbetten und den vollständigen Neuaufbau als geplante Migration behandeln.

4. Vektorspeicher und Egress: die zweite Rechnung

Die Abrechnung einer Vektordatenbank richtet sich üblicherweise nach fünf Punkten: Speicherkapazität, Arbeitsspeicher, Anzahl der Replikate, Anfragevolumen und ausgehendem Datenverkehr. Für die Kapazitätsschätzung nach Anzahl der Vektoren zuerst die Rohgröße berechnen: Bei 1536 Dimensionen und float32 belegt ein Vektor etwa 6 KB; eine Million Vektoren entsprechen rund 6 GB. Dazu kommen Index, Metadaten und Replikate, sodass der tatsächliche Verbrauch ein Mehrfaches betragen kann.

Häufig übersehene Punkte:

  • Dimension: Höhere Dimensionen erhöhen Speicher- und Rechenkosten. Manche Modelle bieten reduzierte Ausgabedimensionen; ob das verfügbar ist und wie stark der Recall leidet, müssen Sie mit Ihrem eigenen Evaluierungsset prüfen.
  • Replikate und Backups: Hochverfügbarkeitsreplikate vervielfachen den Speicher, und auch Backup-Strategien erscheinen auf der Rechnung.
  • Anfragevolumen: Die Zahl der Retrieval-Aufrufe wächst schneller als die Zahl der Dokumente. Dimensionieren Sie nach QPS, nicht nach Datenmenge.
  • Egress: Cross-Region-Deployments von Anwendung und Datenbank, große Kandidatenlisten pro Abfrage und die Synchronisierung in mehrere Umgebungen erzeugen Traffic-Kosten. Anwendung in derselben Region und eine Begrenzung der zurückgegebenen Kandidaten sparen oft unbemerkt Geld.

Für kleine Szenarien reicht PostgreSQL mit pgvector häufig aus. Erst wenn Datenmenge und Parallelität steigen, lohnt die Prüfung, ob eine verwaltete Vektordatenbank den Aufpreis wert ist.

5. In welcher Reihenfolge Sie Monatskosten belastbar schätzen

  1. Anzahl der Quelldokumente, durchschnittliche Länge und Chunking-Parameter erfassen und daraus die gesamten Input-Token nach dem Chunking berechnen, nicht die Zeichenzahl des Originals.
  2. Mit den echten Abfragelogs der letzten Woche tägliche Abfragezahl und durchschnittliche Abfragelänge ermitteln.
  3. Den Re-Embedding-Plan für die nächsten drei Monate klären: Modellwechsel, neues Chunking, zusätzliche Sprachen.
  4. Beim Vektordatenbank-Anbieter die Abrechnungsposten bestätigen: Speicher, Replikate, Backups, Anfragen und Egress jeweils separat.
  5. „Erster Monat mit Indexaufbau“ und „stabiler Betriebsmonat“ getrennt berechnen; die beiden Budgets nicht vermischen.
  6. Einen Puffer einplanen und die Schätzkoeffizienten mit der Rechnung der ersten Woche korrigieren.

Ein wiederverwendbarer Schätzrahmen: Die Platzhalterzahlen dienen nur der Veranschaulichung; Stückpreise tragen Sie aus der Preisübersicht und der Vektordatenbank-Rechnung ein.

# Schätzrahmen: Platzhalter, keine realen Preise eines Anbieters
docs_tokens = 40_000_000       # Input-Token aller Dokumente nach dem Chunking
query_tokens = 2_000_000       # monatliche Token für Abfrage-Vektorisierung
reindex_per_month = 1          # vollständige Re-Embeddings pro Monat
vector_gb = 12                 # Vektoren, Index und Replikate zusammen

embed_price_per_1k = 0.0       # Preis pro 1.000 Token aus der Preisübersicht
storage_price_per_gb = 0.0     # Preis pro GB aus der Vektordatenbank

monthly_embed = (docs_tokens * reindex_per_month + query_tokens) / 1000 * embed_price_per_1k
monthly_storage = vector_gb * storage_price_per_gb
print(monthly_embed + monthly_storage)

6. Die Reihenfolge der Kostensenkung nicht umdrehen

Zuerst den Input bereinigen, dann über ein günstigeres Modell nachdenken. Die Reihenfolge:

  1. Bereinigung: Navigation, Kopf- und Fußzeilen sowie wiederholte Templates entfernen, den Haupttext extrahieren und erst dann chunken.
  2. Chunking: An semantischen Grenzen schneiden; eine ausreichende Überlappung genügt. Überlappung ist keine Versicherung.
  3. Heiß und kalt trennen: Historische Archivinhalte müssen nicht vollständig in die Vektordatenbank; sie lassen sich bei Bedarf einbetten.
  4. Abfrage-Cache: Häufige identische Fragen verwenden denselben Vektor und lösen keine erneute Berechnung aus.
  5. Batch: Offline-Indizes über die Batch-Schnittstelle, Echtzeitabfragen über die Echtzeit-Schnittstelle.
  6. Speicheroptimierung: Dimension sinnvoll wählen, Quantisierung prüfen, Replikate nach Abfragevolumen dimensionieren.
  7. Modellaufteilung: Embedding- und Generierungsmodelle getrennt bewerten; nicht auf Kosten der Retrieval-Qualität am Vektor sparen.

Bei umgekehrter Reihenfolge endet man häufig mit einem etwas günstigeren Embedding-Modell, während Chunk-Überlappung, Schmutztext und häufige Re-Embeddings unverändert bleiben. Die Rechnung bewegt sich kaum, und der Recall wird schlechter.

Häufige Fragen

Warum fallen bei Embeddings keine Output-Token-Kosten an?

Embeddings liefern einen Vektor fester Länge statt generierten Text, daher wird üblicherweise nur der Input berechnet. Einzelne Plattformen können Funktionen wie Speicher separat berechnen; maßgeblich ist die offizielle Dokumentation.

Ist die Batch-Schnittstelle immer günstiger als die Echtzeit-Schnittstelle?

Der Stückpreis ist meist niedriger, aber Fristen, Wiederholungen und die Frage, ob das Gateway den Rabatt weitergibt, müssen berücksichtigt werden. Für Abfragen, die sofortige Antworten brauchen, ist sie ungeeignet; die Ersparnis wird durch Wartezeit aufgehoben.

Lassen sich nach einem Modellwechsel nur Teile der Dokumente neu einbetten?

Die Vektorräume von Alt- und Neumodell sind in der Regel nicht kompatibel; eine Mischung führt zu fehlerhaftem Retrieval. Sicher ist der vollständige Neuaufbau mit Schattenindex und Umschaltung erst nach erfolgreicher Evaluierung. Eine teilweise Neueinbettung ist meist nicht praktikabel.

Warum kann der Vektorspeicher teurer sein als die Embedding-Aufrufe?

Weil Speicher nach Kapazität, Replikaten, Anfragen und Egress laufend berechnet wird, während die Vektorisierung bei unveränderten Dokumenten eine einmalige Kostenposition ist. Bei großen Datenmengen, vielen Replikaten und häufigen Abfragen übersteigt die zweite Rechnung leicht die erste.

Schätzung und tatsächliche Rechnung weichen ab – wo zuerst prüfen?

Zuerst bei Chunk-Überlappung und Schmutztext nach überhöhten Token suchen, dann nach mehrfachem Indexaufbau in Testumgebungen, fehlgeschlagenen Wiederholungen und nicht angewendeten Batch-Rabatten. Abschließend Replikate und Egress der Vektordatenbank prüfen.

Nächster Schritt

Wer einen einheitlichen Einstieg, nutzungsbasierte Abrechnung und mehrere Modelle braucht, kann sich beim ZSQH AI Gateway registrieren, mit einem kleinen Budget einen Indexaufbau und eine Abfrage testen und danach anhand des echten Verbrauchs kalkulieren. Modelle und Preise stehen in der Preisübersicht.

Weiterlesen: