Bei RAG oder semantischer Suche wird das Embedding oft als Erstes ausgelagert: Text an eine gehostete API senden, Vektoren zurückerhalten, an die Vektordatenbank übergeben. Das ist schnell umgesetzt, doch sobald Datenmenge, Compliance-Anforderungen oder schwer kalkulierbare Rechnungen steigen, suchen Teams nach Alternativen.

Drei Wege sind verbreitet: eine gehostete Embedding-API, ein selbst betriebenes Modell mit offenen Gewichten und die in eine Vektordatenbank integrierte Vektorisierung. Keiner ist grundsätzlich überlegen; die Unterschiede liegen bei Dimension und Sprache, Latenz, Datenschutz, Kosten und Betrieb.

Der Artikel vergleicht diese fünf Dimensionen, liefert eine Auswahltabelle nach Szenario und eine Migrationscheckliste. Modelle, Dimensionen und Preise richten sich nach der Dokumentation der Anbieter und der Preisübersicht.

Hinweis: OpenAI, Azure, Cohere, Pinecone, Qdrant, Milvus, Weaviate, BAAI und Qwen sind Marken der jeweiligen Rechteinhaber. Der Artikel vergleicht technische Wege und begründet keine Kooperation und keine Freigabe. Modellspezifikationen und Schnittstellenlimits können sich mit Versionen ändern; maßgeblich ist die offizielle Dokumentation.

1. Die drei Wege zuerst unterscheiden

Gehostete Embedding-API. Dazu zählen die Direktverbindung zum Modellanbieter, Modellservices von Cloud-Anbietern und OpenAI-kompatible Gateways. Vorteile: kein Betriebsaufwand, nutzungsbasierte Abrechnung, schneller Wechsel. Nachteil: Der Text verlässt das eigene Netz, und die Kosten wachsen mit dem Aufrufvolumen.

Modelle mit offenen Gewichten. Beispiele sind BGE-M3, Qwen3-Embedding, EmbeddingGemma, multilingual-e5 und die jina-Reihe. Die Gewichte sind herunterladbar und lassen sich auf eigenen Servern oder in einer privaten Cloud betreiben. Vorteil: Daten bleiben im internen Netz. Nachteil: Inferenzressourcen, Versionen, Skalierung und Monitoring liegen bei Ihnen.

Integrierte Vektorisierung in Vektordatenbanken. Dazu gehören das integrierte Embedding von Pinecone, der Vectorizer von Weaviate, FastEmbed von Qdrant und die Embedding-Funktion von Milvus. Beim Schreiben wird direkt Text übergeben, die Datenbank oder das von ihr aufgerufene Modell erzeugt den Vektor; eine Klebeschicht entfällt. Integrierte Vektorisierung bedeutet jedoch nicht automatisch lokale Inferenz; viele Umsetzungen rufen weiterhin externe Modelldienste auf. pgvector übernimmt nur Speicherung und Retrieval und erzeugt keine Vektoren.

2. Dimension: höher ist nicht automatisch besser

Die Dimension bestimmt die Ausdrucksfähigkeit und direkt auch Speicher- und Retrievalkosten. Beispiele: text-embedding-3-small von OpenAI hat standardmäßig 1536 Dimensionen, 3-large 3072; BGE-M3 hat 1024; Qwen3-Embedding in den Größen 0.6B, 4B und 8B entspricht 1024, 2560 und 4096 Dimensionen; EmbeddingGemma hat standardmäßig 768 und lässt sich auf 512, 256 oder 128 reduzieren. Diese Angaben dienen nur als Beispiel; maßgeblich ist die offizielle Dokumentation.

Der Speicher lässt sich grob schätzen: Anzahl der Vektoren × Dimension × Bytes pro Gleitkommazahl. Eine Million Vektoren mit 1024 Dimensionen und float32 belegen rund 4 GB Rohdaten; bei 3072 Dimensionen sind es etwa 12 GB, ohne Index, Replikate und Metadaten.

# Rohgröße der Vektoren schätzen, ohne Index, Replikate und Metadaten
chunks = 1_000_000
for dim in (768, 1024, 1536, 3072):
    gb = chunks * dim * 4 / 1024**3
    print(f"{dim} Dimensionen: {gb:.1f} GB")

Entscheidend ist, dass Dimension und Modell gebunden sind. Vektoren unterschiedlicher Modelle oder unterschiedlicher dimensions-Parameter dürfen nicht in denselben Index. Nach einem Modellwechsel ist eine vollständige Neuberechnung nötig; Auffüllen mit Nullen oder Kürzen, um die Länge zu erreichen, ist unzulässig.

3. Sprachabdeckung: chinesische Szenarien separat testen

Viele Modelle werben mit Unterstützung für Hunderte Sprachen, aber „unterstützt“ heißt nicht, dass die Qualität auf Ihrem Korpus stimmt. Chinesisch, gemischtsprachige Texte, Russisch, Produktbezeichnungen, Abkürzungen und Tippfehler beeinflussen den Recall.

Verlassen Sie sich bei der Auswahl nicht nur auf Ranglisten. Testen Sie mit echten Nutzerfragen, echten Dokumentblöcken und schwierigen Fällen – synonymen Umschreibungen, sprachübergreifenden Fragen, nummerierten Klauseln. Messen Sie mindestens recall@k und MRR und prüfen Sie anschließend, ob die Rangfolge plausibel ist. Die Modelle betonen Mehrsprachigkeit, doch am Ende entscheiden Ihre eigenen Daten.

Auch die Tokenisierungseffizienz zählt. Bei derselben Obergrenze von 8192 Token passen unterschiedlich viele Zeichen in Chinesisch, Englisch und Code. Beim Chunking ist eine Reserve nach Token sicherer.

4. Latenz und Durchsatz: p95 statt Durchschnitt

Die Latenz einer gehosteten API setzt sich aus Netzwerk-Roundtrip, Warteschlange und Inferenz zusammen. Regionsübergreifende Aufrufe, Netzschwankungen und Warteschlangen in Spitzenzeiten treiben p95 über p50. Batch-Anfragen senken die Kosten pro Element, erhöhen aber die Antwortzeit einer Anfrage und eignen sich für die Offline-Indizierung.

Beim Selbstbetrieb entsteht Latenz vor allem durch Inferenz-Warteschlangen und Batching. Kleine Modelle laufen auch auf CPUs, haben aber begrenzten Durchsatz; große Modelle brauchen GPUs, dazu kommen VRAM, Parallelität und Kaltstart. Ohne Betriebsteam wird dieser Kostenblock häufig unterschätzt.

Die integrierte Vektorisierung einer Vektordatenbank fügt eine weitere Aufrufkette hinzu; Schreiben und Abfragen warten jeweils auf die Modellantwort. Das spart Codekomplexität, nicht unbedingt Latenz. Messen Sie Durchsatz beim Einspielen und p95 bei Abfragen getrennt.

5. Datenschutz und Compliance: Wohin geht der Text?

Eine gehostete API bedeutet, dass Text das eigene Netz verlässt. Klären Sie, ob Daten zum Training verwendet werden, wie lange sie aufbewahrt werden, in welcher Region sie liegen und ob ein unternehmensgeeigneter Datenvertrag möglich ist. Bei personenbezogenen Daten, Verträgen und Finanzdaten zuerst die Compliance-Prüfung durchlaufen.

Selbstbetrieb mit offenen Gewichten hält den Text im eigenen VPC, ist aber nicht automatisch compliant: Modelllizenz, Logs, Backups und Zugriffskontrolle liegen bei Ihnen. Bei integrierter Vektorisierung müssen Sie prüfen, welches Modell im Hintergrund aufgerufen wird und in welche Region die Anfragen gehen.

Auch Vektoren können Informationen preisgeben. Embedding ist keine Verschlüsselung; Angreifer können Ähnlichkeitsinferenzen betreiben. Berechtigungslabels, Mandantentrennung und Zugriffslogs verdienen dieselbe Sorgfalt wie der Originaltext.

6. Kostenstruktur: Der Stückpreis ist nur ein Posten

Vergleichen Sie nicht nur den Preis pro Million Token. Die vollständigen Kosten umfassen mindestens:

  • Token beim Einspielen: erstmalige Vektorisierung und inkrementelle Aktualisierungen.
  • Abfrage-Token: Jede Frage muss erneut vektorisiert werden.
  • Neuberechnung und Migration: vollständiger Lauf bei Modell- oder Chunking-Wechsel sowie Doppelschreiben, Umschaltung und Rollback.
  • Speicher und Arbeitsspeicher: Vektoren, Index, Replikate und Metadaten.
  • Inferenz und Betrieb: GPU, CPU, Strom, Deployment, Upgrades und Monitoring beim Selbstbetrieb.

Am häufigsten unterschätzt werden die Neuberechnungskosten. Ein vollständiger Lauf kann Stunden bis Tage dauern. Konkrete Stückpreise stehen in der Preisübersicht; sie ändern sich mit Anbieter und Version. Feste Zahlen nennt dieser Artikel bewusst nicht.

7. Wegwahl nach Szenario

Szenario Bevorzugter Weg Begründung Zu beachten
Kleines Team, schnelle Validierung Gehostete API Kein Betrieb, nutzungsbasierte Zahlung Modellname, Dimension und Chunking-Version dokumentieren
Daten dürfen das interne Netz nicht verlassen Selbstbetrieb mit offenen Gewichten Text bleibt im eigenen VPC GPU, Lizenz und Backups bewerten
Vektordatenbank vorhanden, Volumen klein Integrierte Vektorisierung Eine Klebeschicht weniger Zugrunde liegendes Modell und Anfrageregion prüfen
Große Offline-Bestände, kostensensibel Selbstbetrieb oder Batch-Hosting Batch-Verarbeitung senkt die Kosten Erst Recall evaluieren, dann vollständig umstellen
Mehrsprachiger Support, Cross-Border-E-Commerce Mehrsprachiges gehostetes Modell oder BGE-M3-Klasse Breite Sprachabdeckung Kleine Sprachen mit echten Daten prüfen
Latenzempfindliche Online-Abfragen Gehostete API in der Nähe oder kleines lokales Modell Weniger Netz-Roundtrips p95 betrachten, nicht nur den Durchschnitt
Dichte und sparse Suche kombiniert Open-Source-Modell mit mehreren Ausgaben Mehrere Vektorarten pro Inferenz Index- und Scoring-Logik wird komplexer

Die Tabelle ist nur ein Ausgangspunkt. Die tatsächliche Wahl hängt von der vorhandenen Infrastruktur ab: Wer bereits eine Cloud nutzt, prüft zuerst deren Modellservice; wer einen GPU-Cluster hat, senkt die Grenzkosten des Selbstbetriebs; wer bereits eine Vektordatenbank nutzt, spart mit integrierter Vektorisierung Engineering-Zeit.

8. Migrationscheckliste

  1. Ist-Zustand erfassen: Modellname, Dimension, Distanzmaß, Chunking-Regeln, Indexparameter und tägliches Aufrufvolumen.
  2. Evaluierungsset aufbauen: einige hundert echte Fragen mit korrekten Dokumenten, fest für Regressionstests.
  3. Zwei bis drei Kandidaten wählen und nicht zu viele Variablen gleichzeitig ändern.
  4. Mit kleinem Traffic doppelt schreiben: alte und neue Vektoren getrennt ablegen, Abfragen über den neuen Index führen, Recall-Unterschiede protokollieren.
  5. Dimension, Normalisierung und Distanzmaß prüfen und bestätigen, dass cosine, dot product und Indexkonfiguration zusammenpassen.
  6. Eine neue Collection für die vollständige Neuberechnung anlegen; keine Vektoren unterschiedlicher Dimension im alten Index mischen.
  7. Prozentual umschalten, alten Index und Rollback-Schalter behalten und mindestens einen Geschäftszyklus beobachten.
  8. Modellversion, Dimension, Chunking-Version und Datum der Neuberechnung im Datenkatalog archivieren.

Der häufigste Migrationsfehler ist nicht schlechte Qualität, sondern eine Inkonsistenz bei Dimension, Normalisierung oder Distanzmaß. Zuerst die technischen Details angleichen, dann über Qualität sprechen.

Häufige Fragen

Lässt sich eine Embedding API vollständig durch Open-Source-Modelle ersetzen?

In vielen Szenarien ja, besonders bei sensiblen Daten oder stabilem Aufrufvolumen. Dann müssen Sie jedoch Inferenzdienst, Modellevaluierung und Versionsupgrades selbst tragen. In der schnellen Validierungsphase ist eine gehostete API unkomplizierter.

Was unterscheidet integrierte Vektorisierung von einem direkten API-Aufruf?

Integrierte Vektorisierung verlagert die Vektorerzeugung in den Schreibprozess der Datenbank und reduziert Code, ruft im Hintergrund aber oft weiterhin einen externen Modelldienst auf. Datenschutz- und Kostenfragen löst sie nicht automatisch; Modellherkunft, Region und Abrechnung vor Vertragsschluss klären.

Erfordert ein Embedding-Modellwechsel immer eine vollständige Neuberechnung?

Ja. Die Vektorräume unterschiedlicher Modelle sind nicht kompatibel; eine Mischung macht Retrieval unzuverlässig. Gleiche Dimension bedeutet nicht, dass sich Vektoren mischen lassen. Vor der vollständigen Neuberechnung eine kleine Evaluierung durchführen.

Sind höhere Dimensionen immer besser?

Nicht unbedingt. Höhere Dimensionen verbessern die Ausdrucksfähigkeit, erhöhen aber Speicher- und Retrievalkosten. Viele Modelle unterstützen Matryoshka-Kürzung, mit der sich Qualität und Kosten abwägen lassen; nach der Kürzung muss neu evaluiert werden.

Welche GPU braucht selbst betriebenes Embedding?

Das hängt von Modellgröße, Batch, Latenzziel und Parallelität ab. Kleine Modelle bedienen auf CPUs auch Szenarien mit niedrigem QPS; große Modelle brauchen meist GPUs und Batching. Zuerst mit echtem Traffic testen, dann die Ausstattung festlegen.

Nächster Schritt

Wer zunächst gehostet validieren möchte, kann im ZSQH AI Gateway einen Test-Key anlegen, Einspielen und Abfragen über die OpenAI-kompatible Schnittstelle testen und danach über Selbstbetrieb entscheiden. Modellverfügbarkeit und Preise stehen in der Preisübersicht.

Weiterlesen: