Une API Embedding semble ne facturer que des tokens d'entrée, sans sortie. Pourtant, après quelques mois de projet RAG, le dépassement de budget vient rarement d'un « trop grand nombre de requêtes » : il provient du volume total de documents après découpage, de la revectorisation complète lors d'un changement de modèle, et de la superposition des coûts de stockage et de requêtes de la base vectorielle.

Cet article décompose ces postes, propose un ordre d'estimation et une priorité de réduction des coûts. Les prix unitaires évoluent : faites foi sur la page Tarifs des modèles et sur la documentation de l'éditeur ; aucun chiffre n'est figé ici.

Remarque : OpenAI, DeepSeek et les autres noms cités sont des marques de leurs détenteurs respectifs. Cet article prend comme exemple les interfaces courantes en octobre 2026 ; noms de modèles, règles de facturation et prix peuvent changer, vérifiez à nouveau les pages de l'éditeur avant tout achat.

1. La base de facturation est le token d'entrée, pas le nombre d'appels

La plupart des interfaces Embedding ne facturent que l'entrée et ne produisent pas de tokens de sortie. L'entrée correspond au texte à vectoriser : titres, corps, tableaux convertis en texte, mais aussi balises HTML, menus de navigation et espaces superflus.

Quatre facteurs amplifient l'estimation :

  • Différences de tokenizer : un caractère chinois ne vaut pas forcément un token, et chaque modèle découpe différemment. N'estimez pas au nombre de caractères : appelez d'abord un petit échantillon et lisez le champ usage de la réponse.
  • Chevauchement des fragments : pour préserver le contexte, le découpage prévoit souvent 10 % à 20 % de recouvrement, et ce texte est facturé plusieurs fois. Plus le recouvrement est élevé, plus la construction de l'index coûte cher.
  • Textes parasites : en-têtes, pieds de page, formulations de gabarit et tables des matières répétées sont facturés comme des tokens normaux s'ils ne sont pas nettoyés, sans apporter de valeur de recherche.
  • Index construits plusieurs fois : si les mêmes documents sont vectorisés en test, en préproduction et en production, le coût est multiplié par le nombre d'environnements.
Poste Moment d'apparition Facturé par Oubli fréquent
Tokens d'entrée Vectorisation des documents et des requêtes Fournisseur Embedding Recouvrement, en-têtes, index répétés
Tâches par lots Indexation initiale et incrémentale hors ligne Interface par lots du fournisseur Remise par lots réellement appliquée
Revectorisation Changement de modèle, de dimensions ou de découpage Fournisseur Embedding Recours complet et double stockage pendant la bascule
Stockage vectoriel Écriture des vecteurs et de l'index Base vectorielle ou cloud Réplicas, sauvegardes, inflation de l'index
Recherche et trafic sortant Lecture des vecteurs à chaque requête Base ou cloud Accès inter-régions, pics de QPS
Appels de génération Passage au grand modèle après recherche Fournisseur du modèle Souvent imputé à tort au coût Embedding

La dernière ligne mérite d'être soulignée : un Embedding bon marché ne signifie pas un RAG bon marché. Les extraits envoyés au grand modèle pour produire la réponse représentent souvent des tokens d'entrée bien plus coûteux que la vectorisation ; le budget doit être calculé en deux parties.

2. Les interfaces par lots : un prix unitaire plus bas contre du temps

La plupart des plateformes facturent les appels par lots moins cher que les appels en temps réel, au prix d'une mise en file, d'un délai de retour en heures et, parfois, de restrictions sur les modèles disponibles et la taille des requêtes. Les lots conviennent à la construction initiale de l'index, à la synchronisation incrémentale nocturne et à l'évaluation hors ligne ; ils ne conviennent pas à la vectorisation en temps réel d'une question utilisateur.

Trois points à vérifier avant usage :

  1. Les tâches par lots ont-elles un quota distinct, ou entrent-elles en concurrence avec les requêtes temps réel ?
  2. Les requêtes échouées ou partiellement réussies sont-elles facturées, et qui supporte le coût des reprises ?
  3. La passerelle répercute-t-elle la remise amont ? Ce n'est pas systématique : demandez-le avant l'achat, ou vérifiez sur la première facture.

Un lot n'équivaut pas à une concurrence illimitée. Soumettre un million d'éléments d'un coup déclenche facilement une limitation ou un échec de tâche. Découpez selon le volume, enregistrez les tokens et la durée de chaque lot, et ne relancez que les lots en échec pour éviter une reprise globale.

3. La revectorisation : le coût ponctuel le plus sous-estimé

Les changements suivants imposent généralement une revectorisation complète :

  • remplacer le modèle d'embedding, ou une mise à jour du modèle qui modifie l'espace vectoriel ;
  • modifier la dimension des vecteurs, les anciens ne pouvant pas être mélangés aux nouveaux ;
  • changer les règles de découpage, de nettoyage ou d'analyse des documents ;
  • ajouter une langue pour laquelle le modèle d'origine est insuffisant.

Le coût de la revectorisation ne se limite pas aux appels : il inclut le temps de recalcul, le stockage simultané des anciens et nouveaux index, et les variations de qualité de recherche pendant la bascule. Sur une très grande base de connaissances, ce montant peut dépasser la somme de tous les coûts de requêtes antérieurs.

Pour réduire le risque :

  • conservez le texte brut comme source de vérité ; les vecteurs ne sont que des données dérivées, reconstructibles à tout moment ;
  • enregistrez dans les métadonnées de l'index le nom du modèle, sa version, la dimension et les paramètres de découpage ;
  • une fois le nouvel index construit, comparez-le sur une série de questions fixes avant de basculer le trafic ;
  • n'effectuez au quotidien que l'embedding incrémental des documents ajoutés ou modifiés, et traitez la revectorisation complète comme une migration planifiée.

4. Stockage vectoriel et trafic sortant : la deuxième facture

La facturation d'une base vectorielle repose généralement sur cinq éléments : capacité de stockage, mémoire, nombre de réplicas, volume de requêtes et trafic sortant. Pour estimer la capacité à partir du nombre de vecteurs, calculez d'abord la taille brute : en 1536 dimensions et float32, un vecteur occupe environ 6 Ko ; un million de vecteurs représente environ 6 Go, avant index, métadonnées et réplicas, qui peuvent multiplier l'occupation réelle.

Points souvent négligés :

  • Dimensions : plus la dimension est élevée, plus le stockage et le calcul de recherche coûtent cher. Certains modèles permettent une sortie de dimension réduite ; vérifiez la disponibilité et l'impact sur le rappel avec votre propre jeu d'évaluation.
  • Réplicas et sauvegardes : les réplicas haute disponibilité multiplient le stockage, et la stratégie de sauvegarde entre aussi dans la facture.
  • Volume de requêtes : le nombre de recherches croît plus vite que le nombre de documents ; dimensionnez selon le QPS, pas selon le volume de données.
  • Trafic sortant : une application et une base dans des régions différentes, des requêtes renvoyant beaucoup de candidats ou une synchronisation vers plusieurs environnements génèrent des frais de réseau. Placer l'application dans la même région et limiter le nombre de candidats renvoyés permet d'économiser une somme discrète.

Pour de petits volumes, PostgreSQL avec pgvector suffit souvent ; lorsque les données et la concurrence augmentent, évaluez si une base vectorielle managée justifie son surcoût.

5. L'ordre à suivre pour estimer le coût mensuel

  1. Comptez les documents sources, leur longueur moyenne et les paramètres de découpage, puis calculez le total de tokens d'entrée après découpage, et non le nombre de caractères d'origine.
  2. À partir des journaux de requêtes de la dernière semaine, comptez le nombre de requêtes quotidiennes et leur longueur moyenne.
  3. Précisez le plan de revectorisation des trois prochains mois : changement de modèle, de découpage, ajout de langues.
  4. Demandez au fournisseur de la base vectorielle comment sont facturés stockage, réplicas, sauvegardes, requêtes et trafic sortant.
  5. Calculez séparément le « premier mois de construction » et le « mois en régime stable » ; ne mélangez pas les deux budgets.
  6. Gardez une marge et corrigez les coefficients avec la facture réelle de la première semaine.

Le cadre d'estimation réutilisable ci-dessous utilise des valeurs d'exemple uniquement. Renseignez les prix unitaires à partir de la page Tarifs des modèles et de la facture de la base vectorielle.

# Cadre d'estimation : valeurs d'exemple, pas les prix réels d'un fournisseur
docs_tokens = 40_000_000       # tokens d'entrée après découpage de tous les documents
query_tokens = 2_000_000       # tokens de requêtes vectorisées par mois
reindex_per_month = 1          # revectorisations complètes par mois
vector_gb = 12                 # vecteurs, index et réplicas confondus

embed_price_per_1k = 0.0       # prix pour 1 000 tokens indiqué sur la page tarifs
storage_price_per_gb = 0.0     # prix au Go de la base vectorielle

monthly_embed = (docs_tokens * reindex_per_month + query_tokens) / 1000 * embed_price_per_1k
monthly_storage = vector_gb * storage_price_per_gb
print(monthly_embed + monthly_storage)

6. Ne pas inverser l'ordre des optimisations

Traitez d'abord l'entrée, puis envisagez un modèle moins cher. L'ordre est le suivant :

  1. Nettoyage : supprimez navigation, en-têtes, pieds de page et gabarits répétés ; extrayez le corps avant de découper.
  2. Découpage : découpez aux frontières sémantiques, avec un recouvrement juste suffisant ; ne considérez pas le recouvrement comme une assurance.
  3. Séparation chaud/froid : les archives historiques n'ont pas besoin d'être toutes dans la base vectorielle ; vectorisez à la demande.
  4. Cache de requêtes : réutilisez directement le vecteur des questions fréquentes et identiques pour réduire les appels.
  5. Lots : indexation hors ligne via l'interface par lots, requêtes temps réel via l'interface temps réel.
  6. Optimisation du stockage : choisissez une dimension pertinente, évaluez la quantification, dimensionnez les réplicas selon les requêtes.
  7. Répartition des modèles : évaluez séparément Embedding et génération ; ne sacrifiez pas la qualité de recherche pour économiser des frais de vecteurs.

Si l'ordre est inversé, le scénario courant est celui-ci : on adopte un modèle d'embedding un peu moins cher, mais le recouvrement reste élevé, les textes parasites ne sont pas nettoyés et la revectorisation est fréquente ; la facture ne bouge presque pas et le rappel se dégrade.

Questions fréquentes

Pourquoi l'API Embedding n'a-t-elle pas de frais de tokens de sortie ?

Embedding produit un vecteur de longueur fixe, pas du texte généré ; la facturation porte donc généralement sur l'entrée. Quelques plateformes facturent séparément le stockage ou d'autres capacités ; faites foi sur la documentation de l'éditeur.

L'interface par lots est-elle toujours moins chère que le temps réel ?

Le prix unitaire est généralement plus bas, mais il faut tenir compte des délais, des reprises en échec et de la répercussion de la remise par la passerelle. Elle ne convient pas aux requêtes exigeant une réponse immédiate : l'économie de prix unitaire est annulée par l'attente.

Après un changement de modèle d'embedding, peut-on ne revectoriser qu'une partie des documents ?

Les espaces vectoriels des anciens et nouveaux modèles sont généralement incompatibles, et le mélange fausse la recherche. La méthode sûre est une reconstruction complète, avec un index fantôme évalué avant la bascule ; une revectorisation partielle n'est en général pas viable.

Pourquoi le stockage vectoriel peut-il coûter plus cher que les appels Embedding ?

Parce que le stockage est facturé en continu selon la capacité, les réplicas, les requêtes et le trafic sortant, alors que la vectorisation est un coût ponctuel tant que les documents ne changent pas. Avec de gros volumes, de nombreux réplicas et des requêtes fréquentes, la deuxième facture dépasse facilement la première.

L'estimation ne correspond pas à la facture : que vérifier en premier ?

Vérifiez d'abord l'amplification de tokens due au recouvrement et aux textes parasites, puis les index reconstruits dans les environnements de test, les reprises en échec et l'application effective des remises par lots ; contrôlez enfin les réplicas et le trafic sortant de la base vectorielle.

Pour aller plus loin

Pour un point d'entrée unifié, une facturation à l'usage et plusieurs modèles, vous pouvez créer un compte ZSQH AI Gateway, construire un index et exécuter des requêtes avec un petit budget, puis estimer à partir de l'usage réel. Les modèles et tarifs de référence sont sur la page Tarifs des modèles.

Pour aller plus loin :