Coût des embeddings : calcul, stockage et mémoire

Ce site est édité par IArche, qui édite ALMA, la plateforme IA pour PME d'IArche. Le coût des embeddings a trois parts : le calcul des vecteurs (payé au jeton à l'indexation, puis à chaque mise à jour et à chaque question), le stockage des vecteurs, et la mémoire de l'index qui les rend rapides à interroger. Avec les prix publics actuels, le calcul est souvent la part la plus faible ; ce sont les dimensions et le volume qui font grossir la facture d'hébergement.

Le coût global d'un RAG (génération augmentée par récupération, réponse rédigée comprise) est traité sur Coût d'un RAG ; ici, on ne regarde que la couche des vecteurs.

1. Le calcul des vecteurs

Prix publics en dollars américains par million de jetons, relevés le 15/11/2026 :

La formule : jetons du corpus × prix ÷ 1 000 000. Calcul illustratif : un corpus de 20 millions de jetons coûte 0,40 $ avec un modèle à 0,02 $, 2 $ avec un modèle à 0,10 $, 4 $ avec un modèle à 0,20 $.

Ajoutez :

• le recouvrement entre passages : s'il est de 10 %, comptez environ 10 % de jetons en plus ;
• les mises à jour : chaque document modifié est réencodé ;
• les questions : chacune est encodée, mais ne pèse que quelques dizaines de jetons ;
• un éventuel changement de modèle : tout le corpus repasse (voir Changer de modèle).

Mistral AI indique par ailleurs, sur sa page de tarifs, que le traitement par lots réduit le prix de 50 %, sans préciser sur cette page à quels modèles cela s'applique.

2. Le stockage des vecteurs

Formules de la documentation pgvector :

Pour un million de passages, le calcul donne :

Ces chiffres ne comptent que les vecteurs : le texte des passages, les métadonnées et l'index s'y ajoutent.

3. La mémoire de l'index

Un index HNSW est rapide quand il tient en mémoire vive ; la documentation de pgvector note qu'il consomme plus de mémoire qu'un index IVFFlat, et qu'il se construit nettement plus vite quand le graphe tient dans maintenance_work_mem. En pratique, c'est souvent la mémoire du serveur, plus que le prix au jeton, qui fixe le coût mensuel. Voir Index HNSW.

Un ordre de grandeur publié : dans la démonstration décrite par Hugging Face, sur un très gros corpus, la recherche en float32 demandait environ 200 Go de mémoire et de disque, contre environ 5,2 Go de mémoire pour l'index binaire et 52 Go de disque pour les deux index quantifiés.

Les leviers d'économie, du plus simple au plus technique

1. Ne pas réencoder pour rien : stockez une empreinte du texte de chaque passage et ne réencodez que ce qui a changé.
2. Choisir la dimension : 1 024 au lieu de 3 072, c'est trois fois moins de place (voir Dimensions et Matryoshka).
3. Passer en demi-précision (halfvec) : deux fois moins de place, et 4 000 dimensions indexables au lieu de 2 000.
4. Quantifier en binaire avec retri : 32 fois moins de place pour l'index (voir Quantification).
5. Utiliser les traitements par lots quand l'éditeur les propose pour l'indexation initiale, qui n'est pas urgente.

Hébergé ou installé chez vous

Un modèle à poids ouverts (BGE-M3, multilingual-e5) n'a pas de prix au jeton, mais il faut une machine pour le faire tourner, et du temps pour l'exploiter. Comparez sur un an : prix au jeton × volume prévu, contre coût de la machine et de son exploitation. Pour un corpus de taille modeste, les prix au jeton relevés ci-dessus rendent souvent le calcul hébergé très bon marché ; la décision se joue alors plutôt sur la confidentialité (voir Embeddings et données personnelles).