Le raisonnement à l'inférence des LLM : que mesure réellement le test-time compute ?

Le test-time compute désigne le calcul ajouté au moment où un modèle produit sa réponse. Au lieu de limiter chaque question à une seule génération, on peut laisser le modèle explorer plusieurs pistes, vérifier une solution, rechercher dans un arbre de décisions ou adapter son budget à la difficulté. Cette famille de méthodes explique une partie des progrès récents des modèles de raisonnement, mais elle est souvent résumée à tort par « laisser le modèle réfléchir plus longtemps ».

Réponse en bref

Le test-time compute mesure une stratégie d'allocation de calcul, pas une capacité abstraite appelée raisonnement. Pour l'évaluer correctement, fixez le modèle, le prompt, les outils et le jeu de tâches, puis tracez une courbe qualité contre tokens, FLOPs, coût et latence. Comparez au moins une génération unique, plusieurs échantillons avec agrégation, une sélection par vérificateur et une règle d'arrêt adaptative. Segmentez les résultats par difficulté et vérifiez les réponses finales avec un oracle indépendant lorsque c'est possible.

Schéma Nexxom. Le même modèle peut recevoir un budget d'inférence différent. L'évaluation doit relier ce budget à une qualité vérifiable et à un coût opérationnel.

De quoi parle-t-on exactement ?

Le calcul d'entraînement, ou train-time compute, modifie les paramètres ou les capacités apprises avant la mise en production. Le calcul à l'inférence ne modifie pas les poids : il dépense davantage de ressources pour une requête donnée. Cela peut prendre la forme de tokens de raisonnement supplémentaires, de plusieurs trajectoires parallèles, d'une recherche séquentielle guidée par un score ou d'appels à des outils.

OpenAI explique dans la présentation de o1 que ses performances progressent avec le temps consacré à la réflexion et avec le calcul utilisé pendant l'entraînement. Le system card o1 précise cependant que les résultats dépendent du checkpoint, du système et du protocole d'évaluation. La conclusion utile pour une équipe n'est donc pas qu'un budget élevé est toujours meilleur, mais que le budget est une variable expérimentale à documenter.

DeepSeek-R1 décrit une autre partie de la même histoire : le papier de DeepSeek-R1 étudie l'apprentissage par renforcement de comportements de raisonnement et publie des modèles distillés. Le train-time compute et le test-time compute ne sont pas interchangeables. Un modèle peut être entraîné pour exploiter un budget d'inférence, mais ce budget doit ensuite être mesuré sur les tâches visées.

Quelles stratégies sont comparées ?

Une génération unique

La génération gloutonne ou l'échantillonnage unique fournit la ligne de base. Elle est rapide et simple à journaliser. Sans cette référence, un gain annoncé grâce à dix trajectoires ne dit pas combien de points viennent réellement du calcul supplémentaire.

Plusieurs trajectoires et agrégation

Best-of-N génère N réponses puis choisit la meilleure avec un score ou une majorité. La self-consistency agrège des réponses qui convergent vers le même résultat. Cette stratégie exploite le parallélisme, mais elle peut répéter la même erreur et augmente le coût proportionnellement à N. Le protocole doit publier N, la température, la graine et la règle de sélection.

Vérification du résultat ou du processus

Un vérificateur peut noter la réponse finale, une étape intermédiaire ou un invariant calculable. La sélection par outcome verifier est pertinente quand la réponse possède un oracle, par exemple un test unitaire ou une égalité numérique. Un process verifier peut détecter une étape incorrecte avant la fin, mais il introduit un second modèle dont la calibration doit être testée. Un score de vérificateur n'est pas une preuve : il faut mesurer ses faux positifs et faux négatifs.

Recherche séquentielle et budget adaptatif

Une recherche en arbre ou une règle d'arrêt peut consacrer plus de calcul aux questions difficiles et arrêter les questions faciles. Le travail de Snell et al. montre, sur leurs tâches et leur protocole, qu'une allocation optimale du calcul d'inférence peut dépasser une simple augmentation de taille du modèle. Leur résultat est une observation expérimentale, pas une constante universelle. Le travail s1 étudie aussi une stratégie de mise à l'échelle à l'inférence avec un budget de tokens contrôlé.

Plus de tokens ne signifie pas meilleur raisonnement

Une réponse longue peut contenir des détours, des répétitions ou une erreur recopiée plusieurs fois. Le nombre de tokens est une mesure de dépense, pas une mesure de validité. À l'inverse, une réponse courte peut être correcte si la tâche est simple. Il faut donc distinguer quatre variables :

Une équipe doit publier ces dimensions ensemble. Une courbe qui ne montre que l'exactitude masque le prix du gain. Une courbe qui ne montre que les tokens peut pénaliser une méthode qui utilise un vérificateur efficace. Lorsque les FLOPs ne sont pas disponibles, indiquez précisément la proxy choisie et ne la présentez pas comme une mesure matérielle.

Le protocole expérimental minimal

1. Définir la tâche et l'oracle

Commencez par les décisions que le système doit prendre : répondre à une question réglementaire, produire un patch qui passe des tests, classer un incident ou calculer un résultat. Définissez un oracle indépendant, une grille humaine avec double annotation ou un test exécutable. Écartez les tâches dont la réponse n'a pas de critère vérifiable du tableau principal.

2. Figer les facteurs de comparaison

Le modèle, la version, le prompt système, les outils, la température, la longueur maximale, le contexte et les règles de troncature doivent rester identiques entre budgets. Si une méthode reçoit un outil supplémentaire, créez une condition expérimentale séparée. Le guide d'évaluation de HELM rappelle l'intérêt de documenter le scénario, les métriques et les contraintes plutôt que de publier un seul score.

3. Stratifier la difficulté

Séparez les questions faciles, intermédiaires et difficiles avec une règle définie avant l'expérience. Un budget adaptatif peut sembler très performant sur la moyenne en consommant presque tout le calcul sur quelques cas. Rapportez la qualité par tranche ainsi que le budget moyen et le p95. Si la difficulté est estimée par le modèle lui-même, validez cette estimation sur un échantillon annoté.

4. Mesurer la courbe coût-qualité

Testez une grille de budgets, par exemple 1, 2, 4, 8 et 16 trajectoires ou une limite de tokens croissante. Pour chaque point, donnez intervalle de confiance, nombre de questions, coût estimé et latence. Recherchez le point de rendement décroissant, c'est-à-dire le premier budget qui n'améliore plus la qualité au-delà de l'incertitude acceptable.

5. Contrôler la contamination et l'adaptation

Un benchmark public peut avoir été vu pendant l'entraînement ou dans des traces d'évaluation. Conservez un jeu privé, un jeu temporel ou des tâches générées puis vérifiées par des humains. Ne changez pas le prompt après avoir vu le résultat sans créer une nouvelle condition. Le papier de Simple test-time scaling et l'analyse critique It's Not That Simple illustrent pourquoi le protocole et la contrainte de longueur peuvent changer l'interprétation d'un gain.

Tableau de décision pour une équipe produit

Ce que le test-time compute mesure réellement

Il mesure l'efficacité d'une politique de calcul dans un contexte donné. Cette politique inclut le modèle, le générateur, le vérificateur, les outils, le budget et la règle d'arrêt. Deux systèmes avec le même nombre de tokens peuvent avoir une qualité différente si l'un explore des trajectoires diversifiées et l'autre répète la même continuation.

La bonne unité de comparaison est donc une courbe reproductible, pas une anecdote de réponse spectaculaire. Conservez les sorties candidates, les scores de vérification, les erreurs, les coûts et les seeds lorsque la confidentialité le permet. Pour une API, ajoutez un identifiant de version et le prix appliqué le jour du test. Pour un système local, indiquez le matériel, le débit et la méthode d'estimation des FLOPs.

Mise en production : une règle simple

Commencez par le plus petit budget qui atteint le seuil de qualité métier. Augmentez le calcul seulement si le gain persiste sur un jeu privé et si la latence p95 reste compatible avec l'expérience. Ajoutez une abstention ou une escalade humaine lorsque le vérificateur est incertain. Réévaluez la courbe après chaque changement de modèle, de prompt, de fournisseur ou de prix.

Cette approche évite deux erreurs symétriques : payer pour une réflexion inutile sur les requêtes faciles et confondre une réponse plus longue avec une réponse plus fiable. Le test-time compute est un levier d'architecture et d'évaluation. Il devient une capacité produit seulement lorsqu'il est relié à un oracle, à un coût et à une décision opérationnelle.

Sources et lectures primaires

• OpenAI, Learning to reason with LLMs
• OpenAI, o1 System Card
• DeepSeek-AI, DeepSeek-R1
• Snell et al., Scaling LLM Test-Time Compute Optimally
• Muennighoff et al., s1: Simple test-time scaling
• Liu et al., It's Not That Simple
• Stanford CRFM, HELM
• HELM GitHub, scenarios and metrics