Température, top-p et le déterminisme que vous n’avez pas

Le chapitre 4 a présenté le logit comme un score réel non normalisé, un par classe. Le chapitre 8 a fait produire à un modèle de langage un logit par entrée du vocabulaire. La softmax transforme ce vecteur $\mathbf{z}$ en probabilités :

La température intervient ici — le nom vient de la physique statistique, où le même paramètre contrôle la concentration plus ou moins forte d’une distribution de Boltzmann sur ses états de basse énergie¹ — et elle divise les logits avant l’exponentielle :

Cet emplacement est tout le mécanisme, et deux lignes d’algèbre suffisent à comprendre pourquoi il ne pouvait pas être ailleurs. Supposons que vous essayiez d’appliquer la température aux probabilités à la place — les multiplier par $1/T$ puis renormaliser. Vous obtiendriez

La constante s’annule. Mettre les probabilités à l’échelle ne change absolument rien ; la distribution revient inchangée. La température n’a d’effet que parce qu’elle agit sur l’exposant, où diviser par $T$ avant l’exponentiation revient à élever chaque probabilité à la puissance $1/T$ — un remodelage non linéaire qui change les rapports entre les entrées plutôt que leur échelle commune.

À partir de cet emplacement, les deux limites suivent sans travail supplémentaire. Quand $T \to 0$, le plus grand logit s’échappe du reste et $p$ s’effondre sur le token ayant le score le plus élevé : greedy decoding. Quand $T$ augmente, chaque $z_i/T$ tend vers zéro, chaque exponentielle tend vers 1, et la distribution s’aplatit vers une distribution uniforme sur tout le vocabulaire. Exactement à $T = 0$, la formule divise par zéro ; toutes les implémentations en font donc un cas particulier et utilisent le maximum arithmétique — y compris le widget ci-dessous, qui bascule vers argmax à $T \le 0.001$.

Un avertissement, car la collision des noms crée une vraie confusion. Il existe en machine learning une deuxième notion sans rapport appelée température : temperature scaling, une méthode de calibration qui ajuste une valeur sur un jeu de validation pour que la confiance d’un classifieur corresponde à sa précision.² Même formule, rien à voir avec la génération. Quand des articles disent « température », ils parlent souvent de celle-là ; ce chapitre, jamais.

Voici cette distribution, avec le calcul sous vos yeux. Les logits sont fixes et plausibles, donc les nombres du texte ci-dessous peuvent être vérifiés par rapport à ce que vous voyez :

Le nombre ␣banana résume tout l’argument : augmenter la température ne peut pas donner à un modèle une idée qu’il n’avait pas. Les logits sont déjà calculés, le classement est déjà fixé, et la température le préserve exactement — aucune quantité de chaleur ne fera jamais passer un token moins bien noté au-dessus d’un token mieux noté. Elle ne fait que redistribuer la masse vers le bas du classement que le modèle a lui-même produit. Une température élevée ne rend pas un modèle plus inventif ; elle augmente la probabilité qu’il émette les tokens qu’il a jugés mauvais.

Sur un vrai vocabulaire, cela cesse d’être une curiosité et devient la raison pour laquelle les sorties à haute température sont inutilisables. Mesuré sur Qwen/Qwen2.5-0.5B-Instruct, une forward pass, le prompt ci-dessus, en comptant le nombre de tokens nécessaires pour accumuler une part donnée de la masse de probabilité :

Lisez lentement la dernière ligne. À $T = 2$, sur une question qui a exactement une bonne réponse, 32 966 tokens différents se partagent les 90 % supérieurs de la masse de probabilité. Ce n’est pas un espace créatif plus vaste. C’est un modèle auquel l’arithmétique a demandé de traiter une particule coréenne et un identifiant C++ comme des options actives pour le mot après A:. Les déchets du bloc d’ouverture en sont la conséquence directe, et ce n’est pas un bug du modèle ni de la bibliothèque — c’est ce que la requête demandait.

La plage utile est étroite et dépend de la tâche plutôt que du goût. Sur une question factuelle, la réponse est un token, et toute chaleur au-dessus d’environ 1,2 injecte de l’erreur pour rien. Sur une question ouverte, il existe vraiment plusieurs bonnes continuations, et un peu de chaleur apporte une variété qui reste fluide :

"Write a two-sentence story about a lighthouse."

T = 0.0  "The lighthouse stood tall and proud, its beacon illuminating the
          night sky above. A lone sailor, his eyes fixed on the distant
          horizon..."

T = 0.7  "In the quiet, stormy waters of the sea, a lighthouse stood
          sentinel over the horizon, its golden dome casting a warm glow
          on the fog-shrouded streets below..."

T = 1.0  "In the quiet night, a lone lighthouse stood sentinel over the
          sea, its shining beacon a beacon of hope and solace for sailors
          and fishermen across the vast and endless ocean..."

T = 1.3  "In the gentle sunlight, now reflecting upon the opening of Jack's
          lighthouse, Jim Trahan, a small-time individual difficult to
          define in paperwork, wondered about a career where simplicity
          reigns..."

À 1,3, le modèle a inventé un nom propre et une phrase qui ne se parse pas. La bande entre « identique à chaque fois » et « incohérent » est à peu près de 0,6 à 1,1 pour ce modèle sur cette tâche, et le conseil honnête est de la trouver en mesurant sur votre tâche, pas en copiant un nombre depuis un article de blog.

Une question évidente se cache sous tout cela : si le modèle possède une distribution de probabilité et qu’un token est le plus probable, pourquoi ne pas toujours le prendre ? Le greedy decoding est gratuit, reproductible et ne demande aucun paramètre.

Parce que le résultat est ceci :

prompt: "In a shocking finding, scientists discovered a herd of unicorns
         living in a remote valley."

greedy: " The unicorns were so rare that they were not even recognized by
         the local people. The unicorns were so rare that they were not
         even recognized by the local people. The unicorns were so rare
         that they were not even recognized by the local people. ..."

         repeated 4-grams: 87.6 %

Huit phrases, une phrase. Près de neuf fenêtres de quatre tokens sur dix étaient déjà apparues plus tôt dans la même sortie. C’est la dégénérescence du texte neuronal, nommée et expliquée par Holtzman et al. dans l’article qui a introduit top-p.³ Le modèle n’est pas cassé ; maximiser la probabilité de séquence est simplement le mauvais objectif pour du texte ouvert. L’écriture humaine n’est pas la suite de mots la plus probable — elle contient de la surprise, sa probabilité par token erre, plonge et remonte — tandis que le chemin de probabilité maximale est un point fixe qui, une fois atteint, n’a aucune raison d’en sortir.

C’est pour cela que l’échantillonnage existe. Et c’est aussi — la partie qu’on oublie souvent — pas une loi universelle. Le chapitre 12 a mesuré 24 réponses correctes sur 24 à des problèmes de mots en deux étapes avec un simple greedy decoding, et l’échantillonnage à température 0,8 a fait tomber ce résultat à 81 % ; la self-consistency a ensuite dépensé six fois plus de tokens pour revenir là où le greedy était déjà. Les deux faits sont vrais en même temps :

La plupart des prompts de production sont du deuxième type et sont configurés comme le premier, parce que la température a été laissée à la valeur utilisée par l’exemple de code.

Échantillonner depuis la distribution complète n’est pas ce que qui que ce soit fait réellement, car la queue est immense et pleine de non-sens. Il faut couper quelque chose. Il existe deux réponses classiques, et elles diffèrent sur un point qui décide de tout.

Top-k conserve un nombre fixe de candidats. Triez par probabilité, gardez les $k$ premiers, écartez le reste, renormalisez.⁴ Top-p, aussi appelé nucleus sampling, conserve une quantité fixe de masse : prenez les tokens par ordre décroissant jusqu’à ce que leur probabilité cumulée atteigne $p$, puis arrêtez.³ Formellement, le noyau est le plus petit ensemble $V_p$ tel que

La différence paraît cosmétique, mais ne l’est pas, parce que les deux prompts que vous envoyez dans la même minute ont des formes de distribution complètement différentes. Les deux utilisent le même modèle à température 1 :

Un $k$ fixe, deux échecs en sens opposés. Sur le prompt factuel, $k = 40$ admet 39 tokens qui valent ensemble 3,6 % — il laisse passer des déchets, y compris un candidat à neuf millièmes de pour cent, parce que la règle compte des emplacements et non des preuves. Sur le prompt d’histoire, le même $k = 40$ jette 21 % de la masse que le modèle avait réellement attribuée, parce que le vrai noyau y mesure 467 tokens de large.

Top-p fait accomplir les deux tâches à un seul nombre. Définissez $p = 0.9$ et il conserve 1 token sur le premier prompt et 467 sur le second, parce qu’il pose une question sur la distribution au lieu de lui imposer un nombre. Observez directement cette adaptation — même coupe, quatre températures :

Ce widget règle aussi un malentendu qu’il faut nommer, parce qu’il coûte réellement de l’argent. Sur une distribution confiante, top_p = 0.9 n’est pas « un peu de variété ». C’est du greedy. À température 1, le token de tête détient ici 96,90 %, déjà au-dessus de 0,9 ; le noyau ne fait donc qu’un token de large et rien d’autre ne peut jamais être tiré. Des équipes règlent top_p à 0,9 en pensant avoir desserré quelque chose, puis se demandent pourquoi chaque réponse est identique.

Réglez top-k à la place, et l’échec opposé est tout aussi visible :

Trois mécanismes différents circulent sous des noms similaires, ils font des choses différentes, et la différence se mesure. Soit $c_i$ le nombre de fois où le token $i$ est déjà apparu.

La même continuation dégénérée que plus haut, avec chacune de ces pénalités appliquée. « Étapes modifiées » compte combien des 120 étapes de génération ont choisi un token différent de celui que le modèle non pénalisé aurait choisi. L’exécution fait ici 120 étapes contre 140 dans le bloc ci-dessus, ce qui explique pourquoi la baseline non pénalisée indique 85,5 % plutôt que 87,6 % :

Trois choses en découlent. Presence à 0,5 a changé trois décisions sur 120 et réduit la répétition d’un quart — la boucle tenait grâce à une poignée de tokens. Frequency à 0,5 a changé quatre fois plus de décisions pour un effet beaucoup plus grand, parce que le multiplicateur du compte continue de croître alors que la constante de presence ne le fait pas. Et la pénalité CTRL à la valeur largement copiée de 1,2 a réécrit 35 décisions sur 120, ce qui n’est pas un coup de pouce ; c’est un autre modèle.

Ce dernier nombre prépare l’échec dont personne ne vous avertit.

Le code répète. Les tableaux répètent. Les listes répètent. Les sorties structurées répètent par définition — c’est cela, la structure. Une pénalité ne sait pas faire la différence entre un modèle coincé dans une boucle et un modèle qui émet correctement la quatrième ligne d’un tableau, parce que les deux ressemblent à un token qui réapparaît.

Les trois mêmes tâches, générées de trois façons :

La frequency penalty à 0,5 s’est révélée inoffensive sur les trois, ce qui est un résultat utile et légèrement surprenant, et qui dit quelque chose de précis : puisqu’aucune décision n’a changé, les tokens structurels devaient gagner leurs positions avec une marge supérieure à la pénalité soustraite, même après être apparus cinq ou six fois. La pénalité CTRL, qui divise à la place, les déloge bel et bien, et voici ce qu’elle a produit :

repetition 1.2, markdown table:
  | n | 2^n |
  | --- | --- |
  | 0 | 1      |
  | 1 | 2       |
  | 2 | 4       |

L’alignement s’effondre : la quantité de remplissage à l’intérieur de chaque cellule change d’une ligne à l’autre, parce que la séquence d’espaces avant la barre verticale fermante est exactement le type de répétition que la pénalité est conçue pour casser. Cosmétique, et cela a coûté six tokens supplémentaires. Le cas Python n’est pas cosmétique :

nothing / frequency 0.5:
      total = 0
      for i in range(1, n + 1):
          total += i ** 2
      return total

repetition 1.2:
      # Initialize total_sum with 0
      total_sum = 0
      # Loop through numbers from 1 to n, incrementing by 2 each time
      for i in range(1, n + 1,

La pénalité a poussé le modèle hors de total — déjà utilisé dans la docstring — vers total_sum, a rembourré la sortie avec des commentaires inventés pour dépenser son budget sur des tokens inutilisés, puis l’a conduit dans un range à trois arguments avec un pas. Le commentaire dit incrementing by 2 each time, ce qui est faux pour une somme de carrés de 1 à $n$. Une repetition penalty a produit du code incorrect à partir d’un prompt auquel il avait été correctement répondu sans elle.

La règle qui suit est courte : les pénalités sont faites pour de la prose ouverte, et elles doivent être désactivées pour le code, les sorties structurées, les données tabulaires et tout ce qui a un schéma. Le chapitre 18 porte exactement sur cette seconde catégorie.

Toute vraie implémentation les applique dans une séquence précise :

pénalités → température → top-k → top-p → échantillonnage

Ce n’est pas de la comptabilité arbitraire, et inverser deux étapes produit réellement des distributions différentes. Deux mesures, toutes deux sur le prompt factuel.

Couper avant ou après la température. Le noyau est calculé sur la distribution qu’on lui donne, et la température change radicalement cette distribution :

À $T = 2$, le même réglage nominal donne un ensemble de candidats de 32 966 ou de 1, uniquement selon l’étape qui s’exécute en premier. Si vous vous êtes déjà demandé pourquoi augmenter la température « ne fait rien » chez un fournisseur et détruit la sortie chez un autre avec les deux mêmes nombres, ce tableau est une réponse plausible.

Pénaliser avant ou après la température. Soustraire une pénalité $\alpha$ puis diviser par $T$ donne une pénalité effective de $\alpha/T$ ; diviser d’abord puis soustraire donne $\alpha$. Avec une presence penalty de 1,0 appliquée au token de tête :

Identiques à $T = 1$, comme elles doivent l’être. Écartées d’un facteur 1,58 à $T = 2$. « Presence penalty 1.0 » n’est pas une quantité de pénalité bien définie à moins de savoir aussi où la température est appliquée, et aucune API ne documente cela.

def sample(logits, counts, presence=0.0, frequency=0.0,
           temperature=1.0, top_k=0, top_p=1.0, generator=None):
    z = logits.clone()

    idx = torch.tensor(list(counts))                       # 1. penalties
    if len(idx):
        z[idx] -= presence
        z[idx] -= frequency * torch.tensor([float(c) for c in counts.values()])

    if temperature <= 0:                                   # 2. temperature
        return int(z.argmax())                             #    T=0 is argmax
    p = torch.softmax(z / temperature, -1)

    p, order = p.sort(descending=True)
    if top_k:                                              # 3. top-k
        p[top_k:] = 0
    p = p * ((p.cumsum(0) - p) < top_p)                     # 4. top-p

    p = p / p.sum()                                        # 5. renormalise
    return int(order[torch.multinomial(p, 1, generator=generator)])

Chaque fournisseur accepte un sous-ensemble différent de ces contrôles, avec des plages différentes, et ignore silencieusement le reste. Ce n’est pas une plainte abstraite. Toute application qui propose un choix de modèle doit noter les différences quelque part, et le fichier où elle le fait est une carte de l’incompatibilité. Voici ce que déclare l’un de ces catalogues pour un seul paramètre sur les neuf sources de texte qu’il prend en charge :

Le mot est le même ; l’échelle ne l’est pas. Une « température de 1 » est la distribution non modifiée chez l’un et la chaleur maximale autorisée chez l’autre, et la moitié du catalogue ne peut pas exprimer la valeur que l’autre moitié traite comme neutre-plus-un-peu. Les autres boutons sont tout aussi inégaux : les entrées OpenAI, DeepSeek et xAI acceptent des pénalités presence et frequency mais pas topK ; les entrées Google, Meta, Cerebras et PaLM acceptent topK et aucune pénalité ; Anthropic accepte topK, topP et des séquences d’arrêt, mais aucune pénalité ; et exactement une des neuf — Mistral — accepte une graine. Envoyer un paramètre qu’un fournisseur n’implémente pas ne produit généralement aucune erreur : la requête réussit, le bouton ne fait rien, et vous concluez que le réglage n’a aucun effet.

Et remarquez ce qu’est un tel fichier : une affirmation sur l’API de quelqu’un d’autre, écrite un jour précis, que rien ne vérifie ensuite. Un catalogue qui indique 0 à 1 pour un fournisseur acceptant désormais 0 à 2 plafonnera silencieusement chaque requête.

Deux autres contrôles appartiennent à la même famille. logprobs, lorsqu’il est proposé, renvoie les log-probabilités du token choisi et souvent les quelques meilleures alternatives — la seule fenêtre que vous avez sur la distribution dont parle ce chapitre, et la base de toutes les heuristiques de confiance construites sur un modèle fermé. Et les maximum tokens plus les séquences d’arrêt terminent la génération sans aucune référence à la probabilité : une limite dure et une correspondance de chaîne. Les deux apparaissent comme le finish_reason du chapitre 14, où length signifie que votre réponse a été coupée au milieu d’une phrase par un budget, pas terminée par le modèle.

Définissez une graine et l’échantillonnage devient reproductible. Cette partie est réelle, et facile à vérifier :

seed = 1234  " Paris\nWhat is a good geographical qualifier for describing
               Paris concerning its location?\nA: Near the Mediterranean Sea"
seed = 1234  " Paris\nWhat is a good geographical qualifier for describing
               Paris concerning its location?\nA: Near the Mediterranean Sea"
seed = 7     " Paris is the capital of France. The appellation of Paris is
               \"Île de Paris\"."
seed = 7     " Paris is the capital of France. The appellation of Paris is
               \"Île de Paris\"."

Identiques au byte près pour une même graine, différents d’une graine à l’autre, exactement comme annoncé. Ce que la graine fixe, donc, c’est le tirage aléatoire dans la dernière ligne de cette fonction sample — le token choisi étant donnée une distribution.

Ce qu’elle ne fixe pas, c’est la distribution. Et c’est là que les problèmes commencent, parce que le vecteur de logits produit par votre modèle n’est pas un objet mathématique ; c’est le résultat de milliards d’additions en virgule flottante, et ces additions ont un ordre.

Le chapitre 2 avait préparé cette expérience. Le même million de nombres float32, sommés selon des groupements différents :

sequential          998.564270020    error vs float64: 6.393e-03
pairwise (numpy)    998.570556641    error vs float64: 1.061e-04
in 4 chunks         998.570495605    error vs float64: 1.672e-04
in 8 chunks         998.570556641    error vs float64: 1.061e-04
in 16 chunks        998.570678711    error vs float64: 1.594e-05

sequential == pairwise?  False
4 chunks == 8 chunks?    False

Regardez la dernière ligne. Le nombre de morceaux change la réponse. Ce n’est pas une curiosité à propos de numpy ; c’est le mécanisme, parce que lorsqu’un serveur d’inférence répartit une réduction sur plus ou moins d’unités parallèles, il fait précisément cela. Et un serveur répartit selon le nombre de requêtes qu’il est en train de servir.

Voici cet effet sur le modèle lui-même. Le même prompt, la même forward pass, la seule différence étant le nombre d’autres requêtes qui se trouvaient dans le batch :

20 identical forward passes, batch of 1:  20 / 20 bit-for-bit identical

the same prompt inside a batch of  2:  147,321 of 151,936 logits differ
the same prompt inside a batch of  4:  146,515 of 151,936 logits differ
the same prompt inside a batch of  8:  146,515 of 151,936 logits differ
the same prompt inside a batch of 16:  147,321 of 151,936 logits differ

largest change to any logit: 2.5e-05

Exécuté seul, le modèle est parfaitement déterministe — vingt passages, identiques au bit près. Placez le prompt identique dans un batch avec des requêtes sans rapport et 97 % de ses logits changent. Rien dans votre requête n’a changé. La requête de quelqu’un d’autre est arrivée.

Maintenant, la partie honnête, parce que cela est souvent raconté comme si c’était la fin de l’histoire. Un changement de $2.5 \times 10^{-5}$ ne modifie la sortie que si deux tokens candidats étaient à cette distance l’un de l’autre. Sur 717 étapes de génération réparties sur douze prompts, le plus petit écart entre les deux premiers logits était $2.5 \times 10^{-3}$ — cent fois plus grand que la perturbation — et aucune étape n’était assez proche pour basculer. Donc sur ce modèle, en float32, sur un ordinateur portable, le batching a déplacé chaque logit et n’a changé aucun token.

C’est la description de conditions favorables, pas une garantie rassurante, et un seul changement de ces conditions suffit :

same weights, same prompts, greedy decoding, no seed involved
float32 vs bfloat16:   6 of 8 answers diverge
                       first divergence at step 23, on average

  float32: "...it is scattered and dispersed into different colors,
            including blue. The blue light is scattered more than other
            colors, so it appears to come from the sky."

  bfloat16: "...it is scattered and scattered, causing the colors of the
             sun to be scattered and scattered, creating the appearance
             of a blue color."

Six réponses sur huit divergent, et l’une se dégrade fortement. Le tableau du chapitre 2 explique pourquoi : bfloat16 conserve 7 bits de mantisse, donc près d’une magnitude de logit de 16, les valeurs représentables sont espacées de 0,125 — 16,0, puis 16,125, puis 16,25 — et l’arrondi peut déplacer un logit jusqu’à 0,0625. Pendant ce temps, 4,7 % des étapes de génération mesurées ci-dessus avaient un écart top-two inférieur à 0,1. Toute la différence entre les deux expériences est là : en float32, la perturbation était cent fois plus petite que la décision la plus proche, et en bfloat16, elle est de même ordre. L’inférence de production s’exécute en 16-bit, sur du matériel avec des kernels fusionnés et des ordres de réduction que personne ne promet de conserver. Savoir si « le bruit numérique est négligeable » est une question de précision et de matériel, pas de modèle.

Donc, les quatre causes, cataloguées comme promis au chapitre 9 :

Le paramètre seed d’OpenAI est honnête à ce sujet de la seule manière possible : il arrive avec un champ system_fingerprint qui identifie la configuration backend, et la documentation indique que le déterminisme est best-effort et qu’un fingerprint modifié signifie que les résultats peuvent différer. Lisez cela pour ce que c’est — un fournisseur qui vous dit qu’il contrôle les quatre causes ci-dessus, que vous n’en contrôlez aucune, et que la seule chose qu’il peut offrir est de vous dire après coup que quelque chose a bougé.

Tout ce qui précède portait sur un bouton et ses conséquences. Reculez d’un niveau et le problème plus difficile apparaît : l’objet que nous réglions est une distribution de probabilité, et les distributions de probabilité n’ont pas d’interface.

Un function call en a une. Une ligne de base de données en a une. Un handler POST attendant un corps JSON avec trois champs obligatoires en a une, et il rejettera tout le reste. Entre le modèle et chaque autre composant de votre système se trouve un contrat dont l’une des parties ne peut pas faire de promesses : le modèle produira quelque chose, tiré d’une distribution que vous avez façonnée mais pas fixée, et le code de l’autre côté a besoin d’une valeur d’un type connu, sinon il lève une erreur.

Le pont entre ces deux mondes se construit avec la matière de ce chapitre plutôt qu’avec du parsing et des retries. Si un token casserait la structure requise, vous ne l’échantillonnez pas en espérant — vous réglez son logit à $-\infty$ avant même que la softmax ne le voie. Le constrained decoding est un masque sur le même vecteur que nous avons passé ce chapitre à remodeler, et il transforme « veuillez répondre en JSON » d’une requête en garantie.

Le chapitre 18 est ce contrat : tool calling, JSON Schema, sorties structurées, et ce qu’il faut pour rendre un système déterministe sûr à construire au-dessus d’un système probabiliste.

Toutes les mesures de ce chapitre viennent de Qwen/Qwen2.5-0.5B-Instruct sur CPU, en float32 sauf indication contraire, avec l’échantillonnage implémenté comme écrit dans la section optionnelle plutôt que délégué à une bibliothèque. C’est un petit modèle, et les valeurs spécifiques sont les siennes ; les mécanismes, non. How to generate text with different decoding methods de Von Platen (Hugging Face, 2020) est l’article par rapport auquel celui-ci est mesuré, et reste la meilleure courte introduction au même sujet. Pour la section sur le déterminisme : les notes de reproductibilité de PyTorch décrivent ce qu’une graine fixe et ne fixe pas sur une seule machine, la documentation OpenAI de seed et system_fingerprint décrit ce qu’un fournisseur peut et ne peut pas promettre, et la discussion de Thinking Machines en 2025 sur les kernels invariants au batch est l’explication publique la plus claire de la raison pour laquelle corriger cela au niveau du serveur d’inférence est possible, mais pas gratuit.