GEO

Calcul au moment du test

Le calcul au moment du test (aussi appelé calcul au moment de l'inférence) est la pratique consistant à laisser un LLM "réfléchir" plus longtemps à l'inférence, en générant davantage de tokens de raisonnement, en exécutant plusieurs chaînes, ou en échantillonnant de nombreux candidats pour choisir le meilleur, afin d'améliorer la qualité des réponses sans réentraîner le modèle. Popularisé par o1 d'OpenAI et DeepSeek-R1 en 2024 et 2025, il a fait passer le raisonnement d'un problème d'entraînement à un bouton réglable à l'exécution.

Le calcul au moment du test (aussi appelé calcul au moment de l'inférence) est la pratique consistant à laisser un LLM "réfléchir" plus longtemps à l'inférence, en générant davantage de tokens de raisonnement, en exécutant plusieurs chaînes, ou en échantillonnant de nombreux candidats pour choisir le meilleur, afin d'améliorer la qualité des réponses sans réentraîner le modèle. Popularisé par o1 d'OpenAI et DeepSeek-R1 en 2024 et 2025, il a fait passer le raisonnement d'un problème d'entraînement à un bouton réglable à l'exécution.

Pourquoi c'est important

Pendant une grande partie de l'ère des LLM, la seule façon de rendre un modèle plus intelligent était d'en entraîner un plus grand avec plus de données. Le calcul au moment du test a brisé cette dépendance. o1 d'OpenAI a montré qu'un même modèle de base, à qui l'on accorde 10 à 30 fois plus de tokens pour raisonner avant de répondre, égale ou dépasse des modèles non raisonnants bien plus grands sur les benchmarks de mathématiques, de codage et de logique. Cela redéfinit les budgets d'inférence : au lieu de "utilisez le plus grand modèle que vous pouvez vous permettre", les équipes demandent désormais "combien de réflexion suis-je prêt à payer pour cette requête ?" L'économie du raisonnement a changé, et la conception des produits aussi, car la qualité du raisonnement est désormais réglable au niveau de la requête.

Comment ça fonctionne

Chaîne de pensée plus longue : le modèle produit des centaines voire des milliers de tokens de raisonnement internes avant la réponse visible. Plus de réflexion → de meilleures réponses.

Échantillons multiples (auto-cohérence) : générer N réponses différentes, choisir celle que le modèle atteint le plus souvent. Simple et efficace en mathématiques.

Recherche en arbre / recherche en faisceau : explorer plusieurs branches de raisonnement en parallèle, élaguer les mauvaises, prolonger les prometteuses.

Modèles de récompense de processus : un second modèle note chaque étape de raisonnement et oriente le modèle principal vers de meilleurs chemins. Utilisé dans la supervision de processus d'OpenAI.

Recherche guidée par vérificateur : générer de nombreux candidats, exécuter un vérificateur externe (tests unitaires, vérificateur mathématique, juge LLM), renvoyer le meilleur.

Best-of-N + reranking : variante plus simple. Générer 16 à 64 candidats, les reranker avec un modèle de récompense, renvoyer le premier.

Le compromis

Toute technique de calcul au moment du test achète de l'exactitude au prix de la latence et du coût :

Latence : une réponse qui prend 500 ms sans raisonnement peut prendre 5 à 30 secondes avec un calcul au moment du test intensif.

Coût : les tokens de raisonnement coûtent autant que n'importe quel autre token de sortie. Une réponse o1 avec 10 000 tokens de réflexion coûte environ 30 à 50 fois une simple réponse GPT-4o.

Rendements décroissants : la courbe exactitude/calcul s'aplatit. Passer de 1 000 à 10 000 tokens de raisonnement aide davantage que de 10 000 à 100 000.

Pas toujours utile : les recherches factuelles simples et la conversation amicale ne tirent aucun bénéfice du raisonnement. Forcer o1 sur "quel temps fait-il" gaspille de l'argent.

Quand l'utiliser

Mathématiques et logique formelle : le calcul au moment du test aide énormément. Les modèles de raisonnement battent les modèles de base de 20 à 40 points sur GSM8K, MATH, AIME.

Génération de code avec tests : générer, exécuter les tests, itérer. La recherche guidée par vérificateur brille.

Planification en plusieurs étapes : décisions d'agent, instructions complexes, optimisation sous multiples contraintes.

Requêtes uniques à enjeux forts : médical, juridique, financier, où payer 5 secondes et 0,30 $ pour une réponse correcte est dérisoire face au coût d'une erreur.

Quand ne pas l'utiliser

UX de chat avec budgets sous la seconde : la latence dégrade l'expérience utilisateur.

Charges de travail à fort volume : une inflation de 20 à 50 fois sur les tokens rend tout point de terminaison à fort volume non rentable.

Recherche ou résumé simples : les réponses en un coup suffisent, réfléchir plus longtemps n'aide pas.

Écriture créative ouverte : davantage de délibération rend les sorties rigides.

Modèles de raisonnement vs modèles classiques

AspectClassique (GPT-4o, Claude 3.5)Raisonnement (o1, R1, Claude Opus 4.6 thinking)
Vitesse de réponseRapideLente
Coût en tokensFaibleÉlevé
Mathématiques / logiqueCorrectExcellent
Écriture créativeForteParfois figée
UX de chatIdéaleExcessive
Meilleur usageLa plupart des requêtesRequêtes difficiles

Le routage de modèles, envoyer les requêtes simples à un modèle rapide et les requêtes difficiles à un modèle de raisonnement, est le schéma standard en production.

Erreurs courantes

Utiliser des modèles de raisonnement partout : gonfle rapidement le coût et la latence sans améliorer la plupart des réponses.

Aucune limite de budget sur les tokens de réflexion : une trace de raisonnement non bornée peut engloutir des milliers de dollars sur une seule requête.

Ignorer la mise en cache : les traces de raisonnement sont souvent répétitives. Le prompt caching peut réduire le coût de façon substantielle.

Sauter l'évaluation : les équipes supposent que raisonnement = mieux. Pour leur domaine spécifique, ce n'est peut-être pas le cas, faites des benchmarks avant de vous engager.

Confondre tokens de réflexion et sortie : les utilisateurs ne devraient pas voir la trace de raisonnement sauf s'ils la demandent. C'est un monologue interne.

Sources :