Infrastructure mutualisée ou dédiée pour l'embedding et le reranking : comment choisir selon la charge de travail

Request

Profile : la forme de la requête compte plus que le volume

Cohere a mené une analyse sur le choix entre infrastructure mutualisée (shared, consommation à l'usage) et dédiée (dedicated) pour l'embedding et le reranking. Constat principal : on compare généralement le prix au token et le nombre de requêtes par minute, mais ces métriques ne disent presque rien sur le bon choix à faire. La logique est simple : Request Profile → Traffic Pattern → Utilization → Deployment Choice.

Un même modèle d'embedding peut effectuer des tâches radicalement différentes. Sur un site e-commerce, l'embedding sert à deux usages : l'indexation du catalogue (des centaines de descriptions de produits traitées en une fois, environ 150 mots soit 200 tokens par texte) et le traitement d'une requête de recherche (une seule requête courte, pendant que l'utilisateur regarde un spinner tourner). Le traitement par batch optimise le débit et le coût, tandis que la requête de recherche optimise la réactivité. Ce sont des exigences opposées, et une seule infrastructure ne peut pas servir efficacement les deux cas.

Le reranking ajoute un paramètre critique : le nombre de candidats à réévaluer. Une recherche vectorielle renvoie 50 produits, et le reranker réévalue chacun par rapport à la requête. Le modèle compare la requête à chaque candidat indépendamment, donc la charge de calcul évolue strictement avec le nombre de candidats. Profil typique : une requête de 20 tokens plus 50 documents de 200 tokens chacun, soit environ 11 000 tokens par opération. Passez de 20 à 100 candidats — l'utilisateur ne remarquera rien, mais la charge grimpera de 4 400 à 22 000 tokens. C'est une décision de profondeur de recherche, pas de montée en charge liée au nombre d'utilisateurs.

Traffic

Pattern et latence : ce qui déterminer la capacité réelle

Deux applications avec le même trafic de pointe peuvent avoir un coût d'infrastructure totalement différent. Un trafic stable (recherche mondiale, flux constant tout au long de la journée) rend l'infrastructure dédiée plus économique : elle est bien exploitée, sans temps mort ni pics non absorbés. Un trafic en pics (rapports financiers, batch jobs, pics sur des créneaux précis) favorise l'infrastructure mutualisée, car on ne paie pas pour une capacité qui reste inactive la majeure partie du temps.

La question clé n'est pas « quel est le trafic de pointe ? » mais « à quel point l'utilisation de la capacité est-elle prévisible et constante ? » Un service qui reçoit 10 000 requêtes par seconde pendant 5 minutes par jour a une économie totalement différente d'un service qui reçoit 100 requêtes par seconde en continu.

Le débit maximal d'un GPU ne reflète pas la capacité réelle en production, car chaque charge de travail a ses propres exigences de latence. L'indexation par batch peut tourner à plein régime, l'achèvement de la tâche comptant plus que la vitesse. Les requêtes de recherche, elles, exigent des budgets de latence stricts, car le délai affecte directement l'expérience utilisateur et le chiffre d'affaires. Le reranking, en élargissant le nombre de candidats, augmente le nombre de documents traités par seconde mais réduit le nombre de recherches traitées par seconde. L'infrastructure doit garantir un débit respectant les exigences de latence, pas simplement atteindre un pic de benchmark.

Seuil de rentabilité et économie du choix

Cohere a calculé les points de bascule économique sur l'exemple d'un seul GPU NVIDIA A10, avec des tarifs standards à la consommation (hors remises, trafic 24/7) :

• Query Embedding (requête unique, 8 tokens) : seuil de rentabilité d'environ quelques dizaines de milliers de requêtes/min
• Catalog Embedding (100 textes × 200 tokens, 20 000 tokens par requête) : seuil de rentabilité d'environ 20 requêtes/min
• Long-document Embedding (100 textes × 1000 tokens, 100 000 tokens par requête) : seuil de rentabilité d'environ 4 requêtes/min
• Reranking (1 requête + 50 documents, 11 000 tokens) : seuil de rentabilité d'environ 29 requêtes/min

Même modèle, même tarif, et le seuil de rentabilité varie d'un facteur de plusieurs centaines selon la taille de la requête. Un profil catalogue à 30 requêtes/min peut sembler modeste, mais il dépasse déjà le seuil de 20 requêtes/min — l'infrastructure dédiée devient donc plus économique. Changez la taille de la requête, le nombre de candidats, les exigences de latence ou le schéma de trafic, et ce point bascule radicalement. Il n'existe donc pas de réponse universelle : le choix entre mutualisé et dédié dépend de la charge de travail concrète, des latences requises et des schémas de trafic — pas de métriques génériques comme le prix au token ou le RPM.