Qwen3 RAG Cost Calculator: Embeddings and Reranking Candidate Budgets

For a RAG system that searches a support knowledge base, the reranking bill can be driven more by the number of candidate passages than by the size of the vector index. In the worked budget below, increasing the reranking pool from 20 to 100 passages multiplies reranking input volume by five. Asking the service to return only five results does not, by itself, mean it evaluated only five passages.

This guide combines the current Orux prices for qwen3-embedding-8b and qwen3-reranker-8b with a runnable, offline Python calculator. Its purpose is to help you choose an initial candidate budget and decide what to measure next. The arithmetic was run locally; no new model request or retrieval benchmark was performed for this article. All workload sizes are explicit assumptions, not observations about your application.

Separate indexing, query embedding and reranking

An embedding model turns text into vectors that a retrieval system can compare. A reranker takes a query and candidate documents and assigns relevance scores. These are different jobs: you normally embed an unchanged document once when building an index, while reranking happens when a query arrives and candidates have already been selected. The native models are described in the Qwen embedding model card and Qwen reranker model card.

For budgeting, keep three counters: document tokens embedded during indexing or updates, query tokens embedded during searches, and query-document tokens evaluated during reranking. Do not multiply your entire corpus by monthly query count unless your implementation actually sends that corpus on every search. Conversely, do not count the query only once in a pair-based reranking estimate: the same query accompanies each candidate document.

The final language model that writes an answer is a fourth cost center. Vector storage, search infrastructure, network traffic and any applicable taxes are also outside the calculator. Separating these costs makes it possible to investigate an unexpectedly large invoice without blaming the answer model for every charge.

Current price snapshot: compare the same unit

The following are Orux public input prices checked on October 30, 2026. They are service prices, not official vendor-hosted API prices or a comparison of model quality. One Credit equals approximately $0.005. A displayed zero is the current configured price, not a promise of permanent free service, unlimited capacity or a successful future request.

Swipe horizontally to view the full table.

The alternative model pages are bge-m3 and bge-reranker-v2-m3. Their zero-price snapshot is a reason to inspect the current offer, not evidence that they will meet your relevance, latency or language requirements. Review access, limits and the current quote before building a dependency on any offer.

For context, our LLM request-cost comparison covers a different stage: answer generation. The DeepSeek API pricing guide also concerns text generation rather than vector retrieval. Neither should be substituted for a reranking price table.

A worked support-search budget

Assume a support knowledge base with 10,000 passages of 400 tokens each. During the first measured period, users submit 10,000 searches averaging 40 query tokens. We compare reranking 20, 50 or 100 candidates per search. Token lengths here are planning inputs: language, tokenizer, formatting and document composition can change actual usage.

Initial indexing uses 10,000 × 400 = 4,000,000 tokens, or 46.6668 Credits at the Qwen embedding rate. Embedding the queries uses 10,000 × 40 = 400,000 tokens, or 4.66668 Credits. Together these two embedding stages contribute 51.33348 Credits. Indexing is a one-time component in this example, not a recurring charge for an unchanged corpus.

For reranking, the illustrative formula is searches × candidates × (document tokens + query tokens). At 20 candidates that is 10,000 × 20 × 440 = 88,000,000 input tokens. Multiplying 88 by 11.6667 gives 1,026.6696 Credits. This formula is a capacity estimate; it does not replace the service's measured usage or settlement record, and it excludes any model-specific formatting overhead.

Swipe horizontally to view the full table.

The total includes initial indexing, query embedding and reranking, but no answer generation. For an unchanged index in the next period, subtract 46.6668 Credits; for a partially updated index, replace that amount with the tokens actually re-embedded. The same table must not be presented as a latency or accuracy result.

Moving from 20 to 50 candidates costs 2.5 times as much for the reranking stage under these assumptions. Moving from 20 to 100 costs five times as much. Those ratios come from the workload formula, not a claim that the model becomes 2.5 or five times better. The diagram is an editorial calculation, not generated model output.

Run the calculator without an API key

Save the following as budget.py and run python3 budget.py. It uses only Python's standard library and makes no network requests. Decimal arithmetic preserves the published rate rather than converting financial values through binary floating point. Change the rate and workload inputs before using it for another price snapshot or application.

"""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=' | ')

The assertions check indexing arithmetic and the two candidate-count ratios. The printed totals reproduce the table above. This verifies the calculator, not the quality of either model or the exact number of tokens a hosted request will report. A useful operational next step is to compare your first real usage record with this estimate and replace the assumed average document and query lengths.

Candidate count is not the returned result count

On the current Orux reranking form, the relevant inputs are query, documents and optional top_n. The documents array determines which passages you submit for evaluation. Treat top_n as the requested number of results, not a cost-control substitute for shortening the input array. If you want to compare budgets for 20 and 100 candidates, actually prepare two different candidate sets.

An embedding request uses input and the currently exposed encoding_format: "float". Native-model options and the hosted form are different contracts: do not infer that every feature in a model card is exposed as a request parameter on Orux. Use the exact model alias from the model page and inspect its current input form before integrating.

For an illustrative support query such as “How do I change the invoice email?”, retrieve candidates from your own approved documents first, then send only those passages for reranking. Keep document IDs alongside the text so you can map returned indices or results back to their source. A score is a relevance signal, not confirmation that a passage is current, authorized for that user, or sufficient to answer the question.

Choose the smallest pool that preserves useful evidence

A reranker cannot recover a relevant passage that never entered its candidate set. Therefore, reducing the pool is not an unconditional optimization. Start with a labeled set of representative support questions: include exact product names, ambiguous wording, recent policy changes and questions with no valid answer. Record which source passages a correct answer needs before comparing settings.

For each candidate budget, measure whether the required passage was retrieved before reranking, where it appears afterward, and whether the answer stage receives enough evidence. Record latency and billed usage separately. If a relevant passage is missing before reranking, investigate retrieval and document preparation; a larger or more expensive reranker cannot score a document it did not receive.

Use a stable evaluation set and document snapshot when comparing 20, 50 and 100 candidates. Otherwise a corpus update can look like a model improvement. There is no universal winning candidate count in this article. Keep the cheaper setting only if your measured evidence coverage and user experience remain acceptable. Repeat the check when document lengths, traffic mix or pricing change materially.

FAQ

Q.Is the first-period total a guaranteed API bill?

No: it is an estimate from explicit workload assumptions and the published price snapshot. It omits formatting overhead, actual tokenization differences, answer generation and infrastructure. Use it to compare candidate budgets consistently, then reconcile the first real requests against the usage and billing records before treating it as a forecast.

Q.Does setting top_n to five make reranking cost the same as five candidates?

Do not assume that it does: the request still contains every document you submitted for scoring. Keep the number of candidate inputs separate from the number of returned results. To test the budget effect of fewer candidates, reduce the documents array and check whether important evidence remains available.

Q.Do unchanged documents need embedding on every query?

Not in the index-based workflow described here: document embeddings are stored and reused until the content or embedding setup changes. Query embedding is a separate step. Account for additions, edits and intentional re-indexing rather than multiplying the full document corpus by every search in the period.

Q.Does the zero BGE price prove it is the best choice?

No: the current zero input-price entry establishes only a pricing observation at the check date. It says nothing about your retrieval quality, access conditions, latency or future prices. Evaluate an alternative against representative questions and confirm the live model page before making it a production dependency.

Q.Does this calculator call a model or spend Credits?

No: the Python example performs local arithmetic with the standard library, without an API key or network request. The example demonstrates budget relationships rather than generating embeddings or relevance scores. A later integration test that calls a hosted model is a separate operation and must follow its current pricing and limits.

Prices checked on 2026-10-30. Sources: Qwen embedding on Orux, Qwen reranker on Orux, BGE embedding on Orux, BGE reranker on Orux, and the two Qwen model cards linked above.