Ce que coûte une question RAG : combien de chunks envoyer

Votre chatbot documentaire fonctionne, la première facture arrive, et elle est plus élevée que ne le justifient les questions. Dans presque toutes les configurations RAG, l'argent va au même endroit : les chunks récupérés que vous collez devant chaque question. Une question RAG coûte les tokens de la question, de vos instructions et de N chunks côté entrée, plus une réponse courte côté sortie. Les chunks sont la partie que vous contrôlez, et chacun ajoute le même nombre de tokens à chaque requête.

Ce guide compte une requête, chiffre 1 000 et 100 000 d'entre elles aux prix en vigueur, et montre ce qui change quand vous passez top-k de 3 à 10. La récupération elle-même (votre base vectorielle, votre découpage) reste de votre côté ; seul l'appel de génération final part vers l'API du modèle. Si la facturation entrée/sortie est nouvelle pour vous, commencez par tokens d'entrée vs de sortie.

Ce qui entre dans une requête RAG#

Imaginons un bot de support sur la documentation de l'entreprise. Un client demande : « Comment réinitialiser la double authentification ? », votre récupérateur renvoie les cinq meilleurs passages, et vous envoyez ceci au modèle :

• un prompt système : « Réponds uniquement à partir du contexte. Si l'information n'y est pas, dis-le. » — environ 300 tokens une fois les règles de formatage ajoutées ;
• la question avec un peu de contexte de conversation — environ 200 tokens ;
• 5 chunks d'environ 500 tokens chacun — 5 × 500 = 2 500 tokens ;
• la réponse : deux ou trois courts paragraphes — environ 300 tokens en sortie.

Le côté entrée fait 2 500 + 300 + 200 = 3 000 tokens, le côté sortie environ 300. Ce sont les hypothèses de l'auteur pour un bot de support typique ; remplacez-les par vos propres chiffres. Tout ce qui suit utilise cette requête comme unité.

Le moyen rapide de voir la répartition : les chunks représentent environ cinq sixièmes de toute l'entrée, et l'entrée est dix fois la réponse. Essayez l'estimation vous-même :

Ce que coûtent 1 000 questions#

Une requête est trop petite pour être perceptible, alors changez d'échelle. Avec 3 000 tokens en entrée et 300 en sortie, 1 000 questions envoient 3 000 000 de tokens d'entrée et génèrent 300 000 tokens de sortie. Faites glisser les curseurs ci-dessous pour correspondre à votre propre bot ; le site recalcule aux prix en vigueur pour chaque modèle.

Le tableau montre la même charge de travail pour les trois modèles, avec la référence OpenRouter à côté. Au total, entrée et sortie confondues, chacun d'eux revient moins cher qu'OpenRouter ici.

Et pour 100 000 questions ? Cela fait 300 000 000 de tokens en entrée et 30 000 000 en sortie. Sur DeepSeek-V4-Flash, cela donne $7.50, sur GLM-5.3-Flash $7.20, sur MiniMax-M2.7 $19.50. Les prix sont fixes par modèle, sans heures de pointe, donc un lot nocturne et un chat diurne coûtent le même prix au token. Voir la liste complète des prix sur la page de tarification.

Top-k : chaque chunk ajoute le même montant#

Deuxième scénario : un assistant wiki interne. Quelqu'un suggère : « Envoyons 10 chunks au lieu de 3, au cas où. » L'entrée croît linéairement : chaque chunk ajoute 500 tokens à chaque requête.

2 000 contre 5 500 tokens : la réponse a la même longueur, donc toute la différence dans la facture de l'assistant wiki est en entrée. Savoir si cela vous apporte une meilleure réponse est une question de qualité : au-delà du point où le bon passage est déjà dans le contexte, les chunks supplémentaires ajoutent surtout du bruit et du coût. Une façon pratique de choisir k est de prendre un ensemble de vraies questions, de vérifier à partir de quel k le bon passage apparaît, et de s'arrêter un peu au-dessus.

La fenêtre de contexte est l'autre limite. Les trois modèles ici ont largement de la place pour un top-k ordinaire : 180K tokens pour MiniMax-M2.7, 380K pour DeepSeek-V4-Flash et 390K pour GLM-5.3-Flash. Les limites de sortie diffèrent : jusqu'à 8 192 tokens par réponse pour GLM-5.3-Flash et MiniMax-M2.7, jusqu'à 32 768 pour DeepSeek-V4-Flash, ce qui compte si vos réponses sont de longs rapports plutôt que de courtes répliques.

Le document entier dans le prompt, ou quatre chunks#

Troisième scénario : questions-réponses sur des contrats. La version paresseuse colle le PDF entier de 30 000 tokens dans chaque question. La version avec récupération envoie la question, les instructions et quatre chunks pertinents d'environ 650 tokens chacun, soit environ 3 000 tokens au total. Mêmes 1 000 questions, mêmes réponses de 300 tokens :

Le document complet envoie dix fois plus d'entrée, 30 000 ÷ 3 000 = 10, pour la même question. Cela reste pertinent pour une question unique sur un document qui tient dans le contexte. Pour un bot qui répond toute la journée, c'est le choix par défaut coûteux. Si une grande partie de cette entrée est le même texte à chaque fois, lisez ce qui concerne le cache de prompt.

Envoyer la requête#

Voici l'étape de génération. La partie récupération est la vôtre : chunks est ce que votre base vectorielle a renvoyé. Le même code fonctionne avec le SDK OpenAI ou en curl simple.

from openai import OpenAI

client = OpenAI(
    base_url="https://api.cheaptokens.dev/v1",
    api_key="YOUR_CHEAPTOKENS_KEY",
)

chunks = ["Chunk 1 text...", "Chunk 2 text...", "Chunk 3 text..."]
context = "\n\n---\n\n".join(chunks)

resp = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-V4-Flash-0731",
    max_tokens=400,
    messages=[
        {"role": "system", "content": "Answer only from the context. If the answer is not there, say so."},
        {"role": "user", "content": f"Context:\n{context}\n\nQuestion: How do I reset two-factor login?"},
    ],
)
print(resp.choices[0].message.content)
print(resp.usage.prompt_tokens, resp.usage.completion_tokens)

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer YOUR_CHEAPTOKENS_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-ai/DeepSeek-V4-Flash-0731",
    "max_tokens": 400,
    "messages": [
      {"role": "system", "content": "Answer only from the context. If the answer is not there, say so."},
      {"role": "user", "content": "Context:\nChunk 1...\n\nQuestion: How do I reset two-factor login?"}
    ]
  }'

La dernière ligne de l'exemple Python est la plus utile. usage.prompt_tokens est votre entrée réelle par question ; comparez-la à l'estimation de 3 000 et remplacez mes hypothèses par vos chiffres. Utilisez l'identifiant complet du modèle, comme dans l'exemple : deepseek-ai/DeepSeek-V4-Flash-0731. Les identifiants sont listés dans la documentation. La configuration complète est dans la documentation, et si vous voulez voir comment les tokens d'un bot s'additionnent au fil d'un dialogue, pourquoi une longue conversation coûte plus cher traite la partie historique.

Quatre façons de réduire l'entrée#

Commencez par max_tokens, qui plafonne la réponse et vous protège d'une réponse emballée. Ensuite, réduisez k à la plus petite valeur qui trouve encore le bon passage. Rendez les chunks plus denses, pour que 500 tokens portent 500 tokens de sens et non des en-têtes et du texte générique. Supprimez les chunks en double avant l'envoi : deux passages quasi identiques coûtent deux fois et ne disent qu'une chose. Et mesurez avec usage sur du trafic réel, car une hypothèse sur des chunks de 500 tokens n'est qu'une hypothèse. Pour un aperçu plus large de où vont les tokens dans un appel API, voir combien de tokens une requête utilise.

Entrez vos propres tokens par requête dans le calculateur ci-dessus pour chiffrer votre bot sur les trois modèles ; si vos réponses sont longues, DeepSeek-V4-Flash est celui à examiner en premier.