Qwen3-RAG-Kostenrechner: Embeddings und Reranking-Kandidaten

In einem RAG-System für eine Support-Wissensdatenbank können die Reranking-Kosten stärker von der Zahl der Kandidatenpassagen als von der Größe des Vektorindex abhängen. Im folgenden Budgetbeispiel verfünffacht eine Erhöhung von 20 auf 100 Kandidaten das Eingabevolumen des Rerankings. Nur fünf Ergebnisse anzufordern bedeutet nicht automatisch, dass der Dienst lediglich fünf Passagen bewertet hat.

Dieser Leitfaden verbindet die aktuellen Orux-Preise für qwen3-embedding-8b und qwen3-reranker-8b mit einem offline ausführbaren Python-Rechner. Er hilft bei der Wahl eines ersten Kandidatenbudgets und der nächsten Messungen. Die Berechnungen wurden lokal ausgeführt; neue Modellaufrufe oder Retrieval-Benchmarks fanden für diesen Artikel nicht statt. Sämtliche Lastwerte sind ausdrücklich Annahmen, keine Messungen Ihrer Anwendung.

Indexierung, Query-Embeddings und Reranking getrennt betrachten

Ein Embedding-Modell wandelt Text in vergleichbare Vektoren um. Ein Reranker bewertet Kandidatendokumente hinsichtlich ihrer Relevanz für eine Suchanfrage. Unveränderte Dokumente werden normalerweise einmal beim Indexaufbau eingebettet. Reranking erfolgt dagegen nach Eingang einer Anfrage und Auswahl der Kandidaten. Die ursprünglichen Modelle beschreiben die Modellkarten von Qwen Embedding und Qwen Reranker.

Führen Sie drei getrennte Zähler: Dokumenttokens beim Indexieren oder Aktualisieren, Tokens eingebetteter Suchanfragen sowie Tokens der beim Reranking bewerteten Anfrage-Dokument-Paare. Multiplizieren Sie den gesamten Korpus nur dann mit der monatlichen Suchzahl, wenn Ihre Implementierung ihn tatsächlich jedes Mal überträgt. Umgekehrt darf die Anfrage in einer paarweisen Schätzung nicht nur einmal zählen: Sie begleitet jedes Kandidatendokument.

Das Sprachmodell für die Antwort ist ein vierter Kostenblock. Vektorspeicher, Suchinfrastruktur, Netzwerkverkehr und gegebenenfalls Steuern fehlen ebenfalls im Rechner. Die Trennung hilft, eine unerwartet hohe Rechnung zu untersuchen, statt sämtliche Kosten dem Antwortmodell zuzuschreiben.

Aktueller Preisstand mit einheitlicher Bezugsgröße

Die folgenden öffentlichen Orux-Eingabepreise wurden am 30. Oktober 2026 geprüft. Es sind Dienstpreise, weder offizielle Preise der von den Modellentwicklern betriebenen APIs noch ein Qualitätsvergleich. Ein Credit entspricht ungefähr $0.005. Eine Null kennzeichnet den aktuell konfigurierten Preis; sie verspricht weder dauerhafte Kostenlosigkeit noch unbegrenzte Kapazität oder erfolgreiche zukünftige Anfragen.

Horizontal wischen, um die ganze Tabelle zu sehen.

Die Alternativen finden Sie unter bge-m3 und bge-reranker-v2-m3. Der momentane Nullpreis ist ein Anlass, das Angebot zu prüfen, aber kein Beleg für passende Relevanz, Latenz oder Sprachabdeckung. Prüfen Sie Zugang, Grenzen und aktuelle Preise, bevor Sie davon abhängig werden.

Unser Vergleich der LLM-Anfragekosten behandelt eine andere Stufe: die Antwortgenerierung. Auch der DeepSeek-API-Preisleitfaden betrifft Textgenerierung statt Vektorsuche. Beide ersetzen keine Reranking-Preistabelle.

Durchgerechnetes Budget für Support-Suche

Wir nehmen 10,000 Passagen mit jeweils 400 Tokens an. Im ersten betrachteten Zeitraum erfolgen 10,000 Suchen mit durchschnittlich 40 Query-Tokens. Verglichen werden 20, 50 und 100 Kandidaten je Suche. Diese Längen sind Planungsgrößen: Sprache, Tokenizer, Formatierung und Dokumentzusammensetzung verändern den tatsächlichen Verbrauch.

Die anfängliche Indexierung umfasst 10,000 × 400 = 4,000,000 Tokens beziehungsweise 46.6668 Credits zum Qwen-Embedding-Preis. Die Suchanfragen ergeben 10,000 × 40 = 400,000 Tokens oder 4.66668 Credits. Zusammen sind das 51.33348 Credits. Die Indexierung ist hier einmalig und keine wiederkehrende Gebühr für einen unveränderten Korpus.

Die illustrative Reranking-Formel lautet: Suchen × Kandidaten × (Dokumenttokens + Query-Tokens). Bei 20 Kandidaten sind das 10,000 × 20 × 440 = 88,000,000 Eingabetokens. 88 × 11.6667 ergibt 1,026.6696 Credits. Dies ist eine Kapazitätsschätzung, kein Ersatz für gemessenen Verbrauch oder Abrechnung. Modellspezifischer Formatierungsaufwand ist nicht enthalten.

Horizontal wischen, um die ganze Tabelle zu sehen.

Die Summe enthält anfängliche Indexierung, Query-Embeddings und Reranking, jedoch keine Antwortgenerierung. Bei unverändertem Index ziehen Sie im Folgezeitraum 46.6668 Credits ab. Bei Teilaktualisierungen ersetzen Sie diesen Betrag durch die tatsächlich neu eingebetteten Tokens. Die Tabelle darf nicht als Latenz- oder Genauigkeitsmessung dargestellt werden.

Unter diesen Annahmen kostet Reranking mit 50 statt 20 Kandidaten das 2.5-Fache; mit 100 Kandidaten das Fünffache. Die Verhältnisse stammen aus der Lastformel und behaupten keine entsprechende Qualitätssteigerung. Das Diagramm ist eine redaktionelle Berechnung, keine generierte Modellausgabe.

Rechner ohne API-Schlüssel ausführen

Speichern Sie den Code als budget.py und starten Sie python3 budget.py. Er verwendet nur die Python-Standardbibliothek und sendet keine Netzwerkanfragen. Decimal bewahrt den veröffentlichten Tarif, ohne Geldwerte über binäre Gleitkommazahlen umzuwandeln. Passen Sie Preis und Lastannahmen vor der Verwendung für eine andere Anwendung oder einen anderen Preisstand an.

"""Scenario calculator, not a tokenizer or a measured API bill. No network calls."""
from decimal import Decimal
RATE = Decimal('11.6667')  # Credits per 1M input tokens, checked 2026-10-30
USD_PER_CREDIT = Decimal('0.005')
QUERIES, CHUNKS, DOCUMENT_TOKENS, QUERY_TOKENS = 10000, 10000, 400, 40

def credits(tokens):
    return Decimal(tokens) * RATE / Decimal(1000000)

def scenario(candidates):
    index_tokens = CHUNKS * DOCUMENT_TOKENS
    query_tokens = QUERIES * QUERY_TOKENS
    pair_tokens = QUERIES * candidates * (DOCUMENT_TOKENS + QUERY_TOKENS)
    rerank = credits(pair_tokens)
    total = credits(index_tokens + query_tokens) + rerank
    return pair_tokens, rerank, total, total * USD_PER_CREDIT

if __name__ == '__main__':
    assert credits(4000000) == Decimal('46.6668')
    assert scenario(20)[1] == Decimal('1026.6696')
    assert scenario(50)[1] / scenario(20)[1] == Decimal('2.5')
    assert scenario(100)[1] / scenario(20)[1] == Decimal('5')
    print('k | rerank tokens | rerank Credits | first-period Credits | USD equivalent')
    for k in (20, 50, 100):
        print(k, *scenario(k), sep=' | ')

Die Assertions prüfen die Indexierungsrechnung und beide Kandidatenverhältnisse. Die Ausgabe reproduziert die Tabelle. Dies bestätigt den Rechner, nicht die Modellqualität oder die genaue Tokenzahl einer gehosteten Anfrage. Vergleichen Sie als nächsten operativen Schritt Ihren ersten echten Verbrauchsnachweis mit der Schätzung und ersetzen Sie angenommene mittlere Dokument- und Query-Längen.

Kandidatenzahl und Ergebniszahl sind verschieden

Das aktuelle Orux-Reranking-Formular enthält query, documents und optional top_n. Das Dokumentarray legt fest, welche Passagen zur Bewertung übermittelt werden. Verstehen Sie top_n als gewünschte Ergebniszahl, nicht als Ersatz für kürzere Eingaben zur Kostenkontrolle. Für einen Vergleich von 20 und 100 Kandidaten müssen tatsächlich zwei unterschiedliche Kandidatenmengen vorbereitet werden.

Embedding-Anfragen verwenden input und das derzeit angebotene encoding_format: "float". Native Modelloptionen und gehostetes Formular sind unterschiedliche Schnittstellenverträge. Nehmen Sie nicht an, dass sämtliche Funktionen der Modellkarte als Orux-Parameter verfügbar sind. Prüfen Sie vor der Integration den exakten Modellalias und das aktuelle Eingabeformular.

Für eine Beispielfrage wie „Wie ändere ich die Rechnungs-E-Mail-Adresse?“ suchen Sie zunächst Kandidaten in Ihren freigegebenen Dokumenten und senden nur diese Passagen zum Reranking. Bewahren Sie Dokument-IDs zusammen mit dem Text auf, um zurückgegebene Indizes oder Ergebnisse den Quellen zuzuordnen. Ein Score signalisiert Relevanz, bestätigt aber weder Aktualität noch Zugriffsberechtigung noch ausreichende Belege für eine Antwort.

Kleinste Kandidatenmenge mit ausreichenden Belegen wählen

Ein Reranker kann eine Passage nicht zurückholen, die nie in seiner Kandidatenmenge war. Eine Reduktion ist deshalb nicht bedingungslos eine Optimierung. Beginnen Sie mit annotierten, repräsentativen Supportfragen: genaue Produktnamen, mehrdeutige Formulierungen, jüngste Richtlinienänderungen und Fragen ohne gültige Antwort. Dokumentieren Sie vor dem Vergleich, welche Quellenpassagen eine korrekte Antwort benötigt.

Messen Sie für jedes Budget, ob die benötigte Passage vor dem Reranking gefunden wurde, welchen Rang sie danach hat und ob die Antwortstufe genügend Belege erhält. Erfassen Sie Latenz und abgerechneten Verbrauch getrennt. Fehlt die Passage schon vorher, untersuchen Sie Suche und Dokumentaufbereitung. Ein größerer oder teurerer Reranker kann nicht bewerten, was er nicht erhalten hat.

Nutzen Sie beim Vergleich von 20, 50 und 100 Kandidaten einen stabilen Testsatz und Dokumentstand. Sonst kann eine Korpusaktualisierung wie eine Modellverbesserung aussehen. Dieser Artikel benennt keine universell beste Kandidatenzahl. Behalten Sie die günstigere Einstellung nur, wenn gemessene Belegabdeckung und Nutzererfahrung akzeptabel bleiben. Prüfen Sie erneut, sobald Dokumentlängen, Traffic-Mix oder Preise wesentlich variieren.

Häufige Fragen

Q.Ist die Summe des ersten Zeitraums eine garantierte API-Rechnung?

Nein. Sie ist eine Schätzung aus expliziten Lastannahmen und einem Preisstand. Formatierungsaufwand, tatsächliche Tokenisierungsunterschiede, Antwortgenerierung und Infrastruktur fehlen. Vergleichen Sie damit Budgets konsistent und gleichen Sie die ersten echten Anfragen mit Verbrauch und Abrechnung ab, bevor Sie die Zahl als Prognose verwenden.

Q.Kostet top_n gleich fünf so viel wie fünf Kandidaten?

Davon sollten Sie nicht ausgehen: Die Anfrage enthält weiterhin sämtliche zur Bewertung eingereichten Dokumente. Trennen Sie Eingabekandidaten von zurückgegebenen Ergebnissen. Um den Budgeteffekt weniger Kandidaten zu prüfen, verkleinern Sie documents und kontrollieren Sie, ob wichtige Belege erhalten bleiben.

Q.Müssen unveränderte Dokumente bei jeder Suche neu eingebettet werden?

Nicht im hier beschriebenen indexbasierten Ablauf. Dokument-Embeddings werden gespeichert und wiederverwendet, bis Inhalt oder Embedding-Konfiguration wechseln. Query-Embeddings sind ein eigener Schritt. Berücksichtigen Sie Ergänzungen, Änderungen und absichtliche Neuindexierung, statt den gesamten Korpus mit jeder Suche zu multiplizieren.

Q.Beweist der BGE-Nullpreis, dass es die beste Wahl ist?

Nein. Er belegt lediglich den Eingabepreis am Prüftag. Über Suchqualität, Zugang, Latenz oder künftige Preise sagt er nichts. Bewerten Sie die Alternative mit repräsentativen Fragen und prüfen Sie die aktuelle Modellseite, bevor Sie sie produktiv voraussetzen.

Q.Ruft der Rechner ein Modell auf oder verbraucht Credits?

Nein. Das Beispiel rechnet lokal mit der Standardbibliothek, ohne API-Schlüssel oder Netzwerkzugriff. Es zeigt Budgetzusammenhänge und erzeugt weder Embeddings noch Relevanzscores. Ein späterer Integrationstest mit einem gehosteten Modell ist ein separater Vorgang, für den aktuelle Preise und Grenzen gelten.

Preisprüfung: 2026-10-30. Quellen: Qwen Embedding auf Orux, Qwen Reranker auf Orux, BGE Embedding auf Orux, BGE Reranker auf Orux und die beiden oben verlinkten Qwen-Modellkarten.