Calculateur de coûts RAG Qwen3 : embeddings et candidats de reranking

Dans un système RAG qui interroge une base de connaissances de support, le coût du reclassement peut dépendre davantage du nombre de passages candidats que de la taille de l’index vectoriel. Dans notre exemple, passer de 20 à 100 candidats multiplie par cinq le volume d’entrée du reranking. Demander seulement cinq résultats ne signifie pas, à lui seul, que le service n’a évalué que cinq passages.

Ce guide associe les tarifs actuels d’Orux pour qwen3-embedding-8b et qwen3-reranker-8b à un calculateur Python exécutable hors ligne. Il aide à fixer un premier budget de candidats et à choisir les mesures suivantes. Les calculs ont été exécutés localement ; aucun nouvel appel de modèle ni benchmark de recherche n’a été réalisé pour cet article. Toutes les charges sont des hypothèses explicites, pas des observations sur votre application.

Séparer indexation, embeddings des requêtes et reclassement

Un modèle d’embeddings transforme le texte en vecteurs comparables. Un reranker évalue la pertinence de documents candidats par rapport à une requête. Les tâches diffèrent : un document inchangé est généralement vectorisé une fois lors de la création de l’index ; le reclassement intervient après réception d’une requête et sélection des candidats. Les modèles natifs sont décrits dans les fiches Qwen Embedding et Qwen Reranker.

Pour le budget, gardez trois compteurs : tokens documentaires vectorisés lors de l’indexation ou des mises à jour, tokens des requêtes vectorisées, puis tokens des couples requête-document évalués au reclassement. Ne multipliez pas tout le corpus par le nombre mensuel de recherches, sauf si votre implémentation le transmet réellement à chaque fois. Inversement, dans une estimation par couples, ne comptez pas la requête une seule fois : elle accompagne chaque candidat.

Le modèle de langage qui rédige la réponse représente un quatrième poste. Stockage vectoriel, infrastructure de recherche, trafic réseau et taxes éventuelles sont également exclus. Cette séparation permet d’analyser une facture inattendue sans attribuer chaque dépense au modèle de réponse.

Comparer les tarifs dans la même unité

Voici les tarifs publics d’entrée d’Orux vérifiés le 30 octobre 2026. Il s’agit des prix du service, pas des tarifs officiels des API hébergées par les éditeurs ni d’une comparaison qualitative. Un Credit vaut environ $0.005. Un zéro indique le prix configuré à cette date, sans promettre une gratuité permanente, une capacité illimitée ou la réussite de futurs appels.

Faites défiler horizontalement pour voir tout le tableau.

Consultez bge-m3 et bge-reranker-v2-m3 pour les alternatives. Leur prix nul invite à examiner l’offre, sans prouver qu’elles satisfont vos exigences de pertinence, latence ou langues. Vérifiez les conditions d’accès, limites et tarifs actuels avant d’en dépendre.

Notre comparatif du coût des requêtes LLM traite d’une autre étape : la génération des réponses. Le guide tarifaire de l’API DeepSeek concerne aussi la génération de texte, pas la recherche vectorielle. Aucun ne remplace une grille tarifaire de reranking.

Exemple de budget pour une recherche de support

Supposons 10,000 passages de 400 tokens chacun. Pendant la première période, les utilisateurs effectuent 10,000 recherches dont les requêtes font 40 tokens en moyenne. Nous comparons 20, 50 et 100 candidats par recherche. Ces longueurs sont des paramètres de planification : langue, tokenizer, mise en forme et composition des documents modifient l’usage réel.

L’indexation initiale représente 10,000 × 400 = 4,000,000 tokens, soit 46.6668 Credits au tarif Qwen Embedding. Les requêtes représentent 10,000 × 40 = 400,000 tokens, soit 4.66668 Credits. Les deux étapes totalisent 51.33348 Credits. L’indexation est ici ponctuelle, et non une charge récurrente pour un corpus inchangé.

La formule illustrative du reclassement est : recherches × candidats × (tokens du document + tokens de la requête). Pour 20 candidats, cela donne 10,000 × 20 × 440 = 88,000,000 tokens d’entrée. Multiplier 88 par 11.6667 donne 1,026.6696 Credits. C’est une estimation de capacité qui ne remplace ni l’usage mesuré ni le relevé de facturation, et exclut les surcoûts de format propres au modèle.

Faites défiler horizontalement pour voir tout le tableau.

Le total inclut indexation initiale, embeddings des requêtes et reclassement, mais pas la génération des réponses. Si l’index reste inchangé à la période suivante, retirez 46.6668 Credits. S’il est partiellement actualisé, remplacez cette somme par le coût des tokens réellement vectorisés de nouveau. Ce tableau ne constitue pas un résultat de latence ou de précision.

Selon ces hypothèses, passer de 20 à 50 candidats multiplie le coût du reclassement par 2.5, et passer à 100 le multiplie par cinq. Ces rapports viennent de la formule de charge, pas d’une qualité multipliée d’autant. Le diagramme est un calcul éditorial, pas une sortie générée par le modèle.

Exécuter le calculateur sans clé API

Enregistrez le code dans budget.py, puis lancez python3 budget.py. Il utilise uniquement la bibliothèque standard Python, sans requête réseau. Decimal conserve le tarif publié sans passer les montants par des flottants binaires. Adaptez le tarif et la charge avant de l’utiliser à une autre date ou pour une autre 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=' | ')

Les assertions vérifient le calcul d’indexation et les deux rapports entre nombres de candidats. La sortie reproduit le tableau. Cela valide le calculateur, pas la qualité des modèles ni le nombre exact de tokens déclaré par une requête hébergée. Comparez ensuite votre premier relevé réel à l’estimation et remplacez les longueurs moyennes supposées des documents et requêtes.

Le nombre de candidats diffère du nombre de résultats

Le formulaire Orux actuel de reclassement expose query, documents et l’option top_n. Le tableau documents détermine les passages soumis à l’évaluation. Considérez top_n comme le nombre de résultats souhaités, pas comme un substitut à la réduction des entrées pour maîtriser les coûts. Pour comparer 20 et 100 candidats, préparez deux ensembles réellement différents.

Une requête d’embeddings utilise input et le format actuellement exposé encoding_format: "float". Les options natives et le formulaire hébergé sont des contrats différents : ne supposez pas que toutes les fonctions d’une fiche modèle existent comme paramètres Orux. Vérifiez l’alias exact et le formulaire en vigueur avant l’intégration.

Pour une question comme « Comment modifier l’adresse e-mail de facturation ? », recherchez d’abord les candidats dans vos propres documents autorisés, puis envoyez uniquement ces passages au reranker. Conservez les identifiants avec les textes pour relier les indices ou résultats aux sources. Un score indique une pertinence, sans confirmer l’actualité du document, les droits du lecteur ou sa suffisance pour répondre.

Choisir le plus petit ensemble qui préserve les preuves utiles

Un reranker ne peut pas retrouver un passage absent de ses candidats. Réduire l’ensemble n’est donc pas une optimisation inconditionnelle. Constituez des questions de support représentatives et annotées : noms exacts de produits, formulations ambiguës, politiques récemment modifiées et questions sans réponse valable. Identifiez les passages nécessaires à une réponse correcte avant de comparer les réglages.

Pour chaque budget, mesurez si le passage requis a été trouvé avant le reclassement, sa position après et si la génération reçoit assez de preuves. Notez séparément latence et usage facturé. Si le passage manque déjà avant le reranking, examinez la recherche et la préparation documentaire : un modèle plus grand ou plus cher ne peut évaluer ce qu’il n’a pas reçu.

Gardez un jeu d’évaluation et un instantané documentaire stables pour comparer 20, 50 et 100 candidats. Sinon, une mise à jour du corpus peut sembler être une amélioration du modèle. Cet article ne propose aucun nombre universellement gagnant. Ne retenez l’option moins chère que si la couverture des preuves et l’expérience mesurées restent acceptables. Recommencez lorsque longueurs, trafic ou prix changent sensiblement.

Questions fréquentes

Q.Le total de la première période garantit-il la facture API ?

Non. C’est une estimation fondée sur des hypothèses explicites et un instantané tarifaire. Elle omet format supplémentaire, différences de tokenisation, génération et infrastructure. Utilisez-la pour comparer les candidats de manière cohérente, puis confrontez vos premières requêtes aux relevés d’usage et de facturation avant d’en faire une prévision.

Q.top_n à cinq revient-il au prix de cinq candidats ?

Ne le supposez pas : la requête contient toujours tous les documents soumis à l’évaluation. Distinguez les candidats d’entrée des résultats renvoyés. Pour mesurer l’effet budgétaire d’un ensemble réduit, raccourcissez documents et vérifiez que les preuves importantes restent présentes.

Q.Faut-il vectoriser les documents inchangés à chaque recherche ?

Pas dans le fonctionnement par index décrit ici. Leurs embeddings sont stockés et réutilisés jusqu’à modification du contenu ou du dispositif d’embedding. Les requêtes constituent une étape distincte. Comptabilisez ajouts, modifications et réindexations volontaires plutôt que de multiplier le corpus entier par chaque recherche.

Q.Le prix nul de BGE prouve-t-il que c’est le meilleur choix ?

Non. Il établit seulement un constat tarifaire à la date de vérification. Il ne dit rien de la qualité de recherche, des conditions d’accès, de la latence ou des prix futurs. Évaluez l’alternative sur des questions représentatives et vérifiez sa page actuelle avant d’en dépendre en production.

Q.Le calculateur appelle-t-il un modèle ou dépense-t-il des Credits ?

Non. L’exemple effectue des calculs locaux avec la bibliothèque standard, sans clé API ni réseau. Il montre les relations budgétaires, sans produire d’embeddings ou de scores. Un test ultérieur appelant un modèle hébergé reste une opération distincte, soumise aux prix et limites applicables.

Tarifs vérifiés le 2026-10-30. Sources : Qwen Embedding sur Orux, Qwen Reranker sur Orux, BGE Embedding sur Orux, BGE Reranker sur Orux, et les deux fiches Qwen liées plus haut.