Un modèle d'embedding gratuit vient de changer ton calcul de coûts RAG

IBM a livré ce mois-ci un modèle d'embedding multilingue qui tient sous 100M de paramètres, gère des fenêtres de contexte de 32K tokens, et est distribué sous licence Apache-2.0. Si ton pipeline RAG appelle encore une API d'embeddings commerciale pour chaque chunk de document et chaque requête, le plancher de coûts sur cette couche vient de tomber à quasi zéro. La question cette semaine n'est pas de savoir s'il faut l'évaluer — c'est à quelle vitesse tu peux lancer le benchmark.

Ce qui a changé dans la release Granite Embedding R2

IBM a publié Granite Embedding Multilingual R2 sur Hugging Face sous licence Apache-2.0. Le modèle passe sous les 100M de paramètres, ce qui le place dans une catégorie de poids qui tourne confortablement sur un seul GPU A10 ou L4 — le genre déjà provisionné dans la plupart des comptes cloud mid-market. La capacité phare, c'est le contexte de 32K tokens, significativement plus long que la limite de 512 tokens qui a forcé des stratégies de chunking sur la plupart des systèmes RAG en production. Le support multilingue est intégré nativement, pas ajouté en surface, couvrant assez de langues pour compter pour toute entreprise avec des corpus documentaires européens ou APAC.

Le modèle a été benchmarké contre d'autres modèles de retrieval sous 100M paramètres, et il affiche des scores au sommet de cette catégorie. Apache-2.0, ça signifie : aucune restriction d'usage, aucun frais au token, aucune clause sur la sortie des données à négocier, et aucune revue de licence avant de livrer à un client en secteur régulé. IBM positionne ce modèle comme la couche de retrieval de sa famille Granite 4.0 plus large — les mises à jour suivront donc une feuille de route produit plutôt qu'un calendrier de recherche.

Pourquoi ça change le calcul sur la dépendance aux APIs d'embedding

La plupart des stacks RAG construits en 2023–2024 utilisent par défaut un endpoint d'embeddings commercial. Les raisons étaient sensées à l'époque : intégration rapide, pas de GPU à gérer, qualité de base correcte. Le problème, c'est que les embeddings sont appelés deux fois par retrieval — une fois à l'indexation pour chaque chunk, une fois à la requête pour chaque demande utilisateur. À l'échelle, c'est un coût prévisible et cumulatif sans plafond naturel.

La fenêtre de contexte de 32K change bien plus que les coûts. Les limites de contexte courtes ont forcé les ingénieurs à construire des pipelines de chunking qui introduisent du bruit dans le retrieval : une clause contractuelle découpée sur deux chunks, un ticket de support qui perd son en-tête, un document de politique interne qui répond à la question seulement lu en entier. Avec 32K de contexte, des documents entiers peuvent être indexés comme unités simples. Ça simplifie le pipeline d'ingestion, réduit la surface d'erreurs de retrieval, et rend la logique de re-ranking plus facile à raisonner. Moins de pièces mobiles, c'est une réduction du risque — pas seulement du confort.

La capacité multilingue compte pour un segment client rarement adressé directement : les entreprises qui opèrent des outils internes sur plusieurs régions, ou les éditeurs SaaS qui vendent sur des marchés non anglophones. Maintenir des modèles d'embedding séparés par langue, ou accepter une dégradation de qualité d'un modèle à dominante anglaise — les deux sont évités ici. Un modèle, un déploiement, un centre de coûts.

Parle à Domani AI de la construction de ce pipeline →

Ce qu'un CTO devrait faire ce lundi matin

Le mouvement cette semaine, c'est un benchmark contenu — pas une migration complète. Cadre-le sur 3 jours de temps ingénieur et produis une seule sortie : un chiffre de delta de coût sur 12 mois, avec ton volume d'embeddings réel.

Voici le cadre de calcul :

• Récupère ta facture API embeddings des 30 derniers jours. Multiplie par 12 pour obtenir une base annualisée.
• Estime le coût en self-hosted — un seul GPU L4 sur Google Cloud tourne à environ 0,80–1,20 $/heure à la demande, moins sur engagement. Pour la plupart des pipelines sous 10M tokens/jour, un seul GPU gère la charge avec de la marge.
• Lance Granite R2 sur un échantillon de 1 000 documents de ton corpus réel. Compare la qualité de retrieval avec tes embeddings actuels en utilisant ton eval set existant. Si tu n'as pas d'eval set, construis un golden set de 50 questions cette semaine — ce travail est de toute façon en retard.
• Vérifie ta posture de licence — Apache-2.0 ne nécessite pas de revue juridique pour la plupart des contextes enterprise, mais confirme avec ton conseil si tu opères dans un secteur régulé.

La migration elle-même est peu risquée. Les modèles d'embedding se trouvent à la couche d'ingestion et de requête, derrière ton vector store. Changer le modèle nécessite de re-indexer ton corpus (une opération unique) et de mettre à jour l'appel d'embedding à la requête. Ça ne touche pas ton LLM, ta logique de prompt, ni ta couche applicative. Un ingénieur compétent peut faire tourner un index parallèle et A/B tester la qualité de retrieval avant de décommissionner entièrement la dépendance à l'API.

Ce que ça coûte — et ce que ça économise réalistement

Le compromis honnête, c'est la propriété opérationnelle. Une API commerciale te donne zéro surface d'infrastructure. Self-héberger Granite R2 signifie que tu possèdes le déploiement, la logique de scaling et le SLA d'uptime. Pour une équipe qui fait déjà tourner des workloads GPU — ce que sont la plupart des entreprises AI-first de 50 à 500 FTE — c'est une charge incrémentale, pas une nouvelle capacité. Pour une équipe sans infrastructure GPU aujourd'hui, le calcul est différent : intègre le temps de setup (compte 2 à 4 jours pour un déploiement conteneurisé avec health check et politique d'autoscale) et l'overhead ops continu avant de t'engager.

Côté économies : les entreprises qui embedent plus de 500M tokens par mois sur une API commerciale dépensent typiquement 500–2 000 $/mois sur ce seul poste, selon le fournisseur et le tier. En self-hosted sur un seul GPU réservé, on arrive à environ 400–600 $/mois en compute, avec une qualité au moins équivalente aux alternatives commerciales sous 100M paramètres. Au-dessus de 2B tokens/mois, le delta est suffisamment significatif pour justifier un service d'embedding dédié avec redondance. En dessous de 50M tokens/mois, les économies sont réelles mais pas structurantes — l'argument le plus solide est la résidence des données et la longueur de contexte, pas le coût. Sache quel argument s'applique à ta situation avant de planifier la migration.