Cohere : reranker 100 candidats au lieu de 20 fait passer la charge de 4,4 à 22 000 tokens

Cohere a publié une analyse pratique pour choisir entre l'inférence shared, facturée à la consommation, et l'inférence dedicated, à capacité dédiée, pour les modèles Embed et Rerank. Son auteur, la solutions architect Payal Singh, part d'un constat simple : comparer les grilles tarifaires n'a aucun sens tant qu'on ne sait pas comment l'application utilise le modèle. Un appel d'embeddings sur 100 descriptions de produits d'environ 200 tokens pèse près de 20 000 tokens. Une requête de recherche d'un acheteur tient en quelques mots. Pour la facturation, ce sont deux « requêtes ». Pour le matériel, ce sont deux charges totalement différentes.

Un modèle, deux profils

Cohere prend l'exemple d'une boutique en ligne. Il faut d'abord indexer le catalogue : chaque description passe par le modèle et le vecteur est enregistré. La première fois, le travail est considérable ; ensuite, il se réduit à un flux de petits lots au fil des mises à jour de l'assortiment. L'application envoie les produits par paquets, environ 100 descriptions par appel, et personne n'attend le résultat. L'important est de terminer la tâche, pas de la terminer vite : on optimise donc le throughput et le coût par unité de travail.

La requête de recherche « waterproof trail running shoes » fonctionne à l'inverse. Elle est courte, et l'utilisateur regarde un indicateur de chargement. Ici, la réactivité prime, et on la paie par un moins bon rapport prix/performance. En somme, on demande au même modèle d'accomplir deux tâches différentes. Une infrastructure réglée pour de gros lots ne garantit pas forcément le temps de réponse voulu sur des milliers de petites requêtes sensibles à la latence.

Rerank : la profondeur des résultats joue le rôle de multiplicateur

Le reranker a sa propre géométrie. La recherche vectorielle renvoie, disons, 50 candidats, et le modèle évalue chaque paire « requête — document » indépendamment. La requête est retraitée pour chaque candidat : le travail croît donc proportionnellement à leur nombre.

Selon l'estimation de Cohere, un appel type comprend une requête d'environ 20 tokens et 50 produits d'environ 200 tokens. Cela donne de l'ordre de 11 000 tokens par recherche. Si l'on augmente la profondeur des résultats, le tableau change sans un seul nouvel utilisateur :

• 20 candidats : environ 4 400 tokens par recherche ;
• 50 candidats : environ 11 000 tokens ;
• 100 candidats : environ 22 000 tokens.

Le nombre de recherches et l'expérience utilisateur restent identiques, mais il faut cinq fois plus de calcul. C'est pourquoi Cohere propose de considérer la profondeur du retrieval comme une décision d'infrastructure, et pas seulement comme un réglage de qualité.

Ce qu'il faut retenir des key takeaways

Les thèses de l'article dessinent la logique suivante :

• la request shape compte plus que le volume de requêtes : quelques gros appels Embed peuvent consommer plus de compute que des milliers de courtes requêtes de recherche, ce qui rend le RPM peu fiable comme unique métrique de planification de capacité ;
• l'inférence dedicated est généralement plus économique pour une charge stable et prévisible, tandis que le modèle à la consommation convient mieux à un trafic variable ou par pics ;
• le seuil de rentabilité dépend de la taille des requêtes, du volume de tokens et du nombre de candidats en rerank, et pas seulement du prix de l'infrastructure ;
• le throughput maximal n'équivaut pas à la capacité réellement disponible en production : il faut respecter les exigences de latency tout en maintenant un coût raisonnable.

Comment aborder le choix en pratique

La démarche est celle que propose Cohere elle-même : profil des requêtes, puis schéma de trafic, puis taux d'utilisation, et seulement ensuite choix du déploiement. Commencez par mesurer la taille réelle des requêtes : combien de documents par lot d'indexation, combien de tokens en moyenne, combien de candidats envoyés au reranker. Séparez ensuite la charge de fond (indexation, recalculs par lots) de la charge interactive (recherche, où l'utilisateur attend). La première peut souvent rester en mode shared si elle est irrégulière. La seconde, avec un flux stable, est une candidate à la capacité dédiée.

Recalculez par ailleurs les coûts lorsque la profondeur de reranking change : passer de 20 à 100 candidats peut déplacer le seuil de rentabilité. Et testez la puissance sous la latence cible, plutôt qu'au débit maximal annoncé. Dans le fragment disponible, cette partie de l'article s'interrompt à la section sur les schémas de trafic ; Cohere n'y donne donc pas de seuils précis de bascule entre les modes.