Temperatura, Top-p y el determinismo que no tienes

El capítulo 4 introdujo el logit como una puntuación real no normalizada, una por clase. El capítulo 8 hizo que un modelo de lenguaje produjera una por entrada del vocabulario. La softmax convierte ese vector $\mathbf{z}$ en probabilidades:

La temperatura entra aquí —el nombre se toma de la física estadística, donde el mismo parámetro controla lo bruscamente que una distribución de Boltzmann se concentra en sus estados de baja energía¹— y divide los logits antes de la exponencial:

Esa ubicación es todo el mecanismo, y merece la pena verlo con dos líneas de álgebra para entender por qué no podría estar en ningún otro sitio. Supón que intentaras aplicar la temperatura a las probabilidades en su lugar: escalarlas por $1/T$ y renormalizar. Obtendrías

La constante se cancela. Escalar probabilidades no hace absolutamente nada; la distribución vuelve sin cambios. La temperatura solo tiene efecto porque actúa sobre el exponente, donde dividir por $T$ antes de exponenciar equivale a elevar cada probabilidad a la potencia $1/T$: una remodelación no lineal que cambia las proporciones entre entradas, no su escala común.

A partir de esa ubicación, ambos límites se deducen sin más trabajo. Cuando $T \to 0$ el logit más grande se escapa del resto y $p$ colapsa sobre el único token con mayor puntuación: greedy decoding. Cuando $T$ crece, cada $z_i/T$ tiende a cero, cada exponencial tiende a 1 y la distribución se aplana hacia una uniforme sobre todo el vocabulario. Exactamente en $T = 0$ la fórmula divide por cero, así que toda implementación lo trata como un caso especial y usa el máximo aritmético, incluido el widget de abajo, que cambia a argmax en $T \le 0.001$.

Una advertencia, porque la colisión de nombres causa confusión real. Hay una segunda cosa no relacionada llamada temperatura en machine learning: temperature scaling, un método de calibración que ajusta un valor en un conjunto de validación para que la confianza de un clasificador coincida con su precisión.² Misma fórmula, nada que ver con la generación. Cuando los papers dicen «temperature», a menudo se refieren a esa; este capítulo nunca lo hace.

Aquí está esa distribución, con la aritmética delante de ti. Los logits son fijos y plausibles, así que los números del texto de abajo pueden comprobarse contra lo que ves:

El número ␣banana es todo el argumento en miniatura: subir la temperatura no puede darle a un modelo una idea que no tenía. Los logits ya están calculados, el ranking ya está fijado y la temperatura lo conserva exactamente: por mucho calor que apliques, un token con menor puntuación nunca pasa por encima de uno con mayor puntuación. Lo único que hace es redistribuir masa hacia abajo por el ranking que el propio modelo produjo. Una temperatura alta no hace que un modelo sea más inventivo; hace más probable que emita los tokens que puntuó como malos.

En un vocabulario real, esto deja de ser una curiosidad y se convierte en la razón por la que la salida a alta temperatura es inutilizable. Medido en Qwen/Qwen2.5-0.5B-Instruct, una pasada forward, el prompt anterior, contando cuántos tokens hacen falta para acumular una proporción dada de la masa de probabilidad:

Lee la última fila despacio. En $T = 2$, para una pregunta con exactamente una respuesta correcta, 32.966 tokens distintos comparten el 90 % superior de la masa de probabilidad. Eso no es un espacio creativo más amplio. Es un modelo al que la aritmética le ha dicho que trate una partícula coreana y un identificador de C++ como opciones vivas para la palabra posterior a A:. La basura del bloque inicial es la consecuencia directa, y no es un bug del modelo ni de la biblioteca: es lo que pidió la solicitud.

El rango útil es estrecho y depende de la tarea, no del gusto. En una pregunta factual, la respuesta es un token y cualquier calor por encima de aproximadamente 1,2 inyecta error a cambio de nada. En una pregunta abierta sí hay más de una buena continuación, y algo de calor compra variedad que sigue siendo fluida:

"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..."

A 1,3 el modelo ha inventado un nombre propio y una frase que no se parsea. La franja entre «idéntico cada vez» e «incoherente» está aproximadamente entre 0,6 y 1,1 para este modelo en esta tarea, y el consejo honesto es que la encuentres midiendo en tu tarea, no copiando un número de una entrada de blog.

Hay una pregunta obvia escondida bajo todo esto: si el modelo tiene una distribución de probabilidad y un token es el más probable, ¿por qué no cogerlo siempre? El greedy decoding es gratis, reproducible y no necesita parámetros.

Porque el resultado es este:

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 %

Ocho frases, una frase. Casi nueve de cada diez ventanas de cuatro tokens ya habían aparecido antes en la misma salida. Esto es degeneración de texto neural, nombrada y explicada por Holtzman et al. en el paper que introdujo top-p.³ El modelo no está roto; maximizar la probabilidad de la secuencia es sencillamente el objetivo equivocado para texto abierto. La escritura humana no es la secuencia de palabras más probable: lleva sorpresa, su probabilidad por token deambula, baja y se recupera, mientras que la ruta de máxima probabilidad es un punto fijo que, una vez alcanzado, no tiene motivo para abandonarse.

Por eso existe el muestreo. También, y esta es la parte que se omite, no es una ley universal. El capítulo 12 midió 24 de 24 correctas en problemas verbales de dos pasos con greedy decoding puro, y muestrear a temperatura 0,8 bajó eso al 81 %; luego la autoconsistencia gastó seis veces más tokens para volver a donde greedy ya estaba. Ambas cosas son ciertas a la vez:

La mayoría de prompts de producción son del segundo tipo y se configuran como el primero, porque la temperatura se dejó en lo que usaba el código de ejemplo.

Muestrear desde la distribución completa no es lo que nadie hace en realidad, porque la cola es enorme y está llena de sinsentidos. Hay que cortar algo. Hay dos respuestas clásicas y se diferencian en un aspecto que lo decide todo.

Top-k conserva un número fijo de candidatos. Ordena por probabilidad, conserva los primeros $k$, descarta el resto y renormaliza.⁴ Top-p, también llamado nucleus sampling, conserva una cantidad fija de masa: toma tokens en orden descendente hasta que su probabilidad acumulada alcanza $p$, y se detiene.³ Formalmente, el núcleo es el conjunto más pequeño $V_p$ con

La diferencia suena cosmética y no lo es, porque los dos prompts que envías en el mismo minuto tienen formas de distribución completamente distintas. Ambos son el mismo modelo a temperatura 1:

Un $k$ fijo, dos fallos en direcciones opuestas. En el prompt factual, $k = 40$ admite 39 tokens que entre todos valen un 3,6 %: deja pasar basura, incluido un candidato con nueve milésimas de punto porcentual, porque la regla cuenta huecos y no evidencia. En el prompt de historia, el mismo $k = 40$ tira el 21 % de la masa que el modelo realmente asignó, porque el núcleo real ahí tiene 467 tokens de ancho.

Top-p hace que exactamente un número cumpla ambos trabajos. Fija $p = 0.9$ y conserva 1 token en el primer prompt y 467 en el segundo, porque hace una pregunta sobre la distribución en vez de imponerle un recuento. Observa esa adaptación directamente: mismo corte, cuatro temperaturas:

Ese widget también zanja una confusión que merece nombre, porque cuesta dinero de verdad. En una distribución segura, top_p = 0.9 no es «un poco de variedad». Es greedy. A temperatura 1, el token líder aquí contiene el 96,90 %, que ya está por encima de 0,9, así que el núcleo tiene un token de ancho y nunca se podrá extraer nada más. Los equipos fijan top_p en 0,9 creyendo que han aflojado algo y luego se preguntan por qué cada respuesta es idéntica.

Configura top-k en su lugar y el fallo opuesto es igual de visible:

Tres mecanismos distintos circulan con nombres parecidos, hacen cosas distintas y la diferencia es medible. Sea $c_i$ el número de veces que el token $i$ ya ha aparecido.

La misma continuación degenerada de antes, con cada una aplicada. «Pasos alterados» cuenta cuántos de los 120 pasos de generación eligieron un token distinto del que habría elegido el modelo sin penalización. Aquí la ejecución es de 120 pasos frente a los 140 del bloque anterior, por eso la línea base sin penalización marca 85,5 % en vez de 87,6 %:

De ahí salen tres cosas. Presencia a 0,5 cambió tres decisiones de 120 y redujo la repetición una cuarta parte: el bucle se sostenía con un puñado de tokens. Frecuencia a 0,5 cambió cuatro veces más decisiones y tuvo un efecto mucho mayor, porque el multiplicador de recuento sigue creciendo mientras que la constante de presencia no. Y la penalización CTRL al valor ampliamente copiado de 1,2 reescribió 35 de 120 decisiones, lo cual no es un empujoncito: es otro modelo.

Ese último número prepara el fallo del que nadie avisa.

El código se repite. Las tablas se repiten. Las listas se repiten. La salida estructurada se repite por definición: eso es la estructura. Una penalización no puede distinguir entre un modelo atrapado en un bucle y un modelo que emite correctamente la cuarta fila de una tabla, porque ambas cosas parecen un token que aparece otra vez.

Las mismas tres tareas, generadas de tres maneras:

La penalización de frecuencia a 0,5 resultó ser inocua en las tres, lo cual es un resultado útil y ligeramente sorprendente, y dice algo preciso: como no cambió ninguna decisión, los tokens estructurales debían de estar ganando sus posiciones por más de lo que restaba la penalización, incluso después de aparecer cinco y seis veces. La penalización CTRL, que divide en su lugar, sí los desaloja, y esto es lo que produjo:

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

La alineación se desmorona: la cantidad de relleno dentro de cada celda cambia de una fila a otra, porque la secuencia de espacios antes de la barra vertical de cierre es exactamente el tipo de repetición que la penalización existe para romper. Es cosmético, y costó seis tokens extra. El caso de Python no es cosmético:

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 penalización empujó al modelo fuera de total —ya usado en el docstring— hacia total_sum, rellenó la salida con comentarios inventados para gastar su presupuesto en tokens no usados y luego se metió en un range de tres argumentos con stride. El comentario dice incrementando de 2 en 2 cada vez, lo cual es incorrecto para una suma de cuadrados de 1 a $n$. Una penalización de repetición produjo código incorrecto a partir de un prompt que se respondía correctamente sin ella.

La regla que se deriva es corta: las penalizaciones son para prosa abierta, y deben estar desactivadas para código, salida estructurada, datos tabulares y cualquier cosa con un schema. El capítulo 18 trata exactamente de esa segunda categoría.

Toda implementación real aplica esto en una secuencia concreta:

penalizaciones → temperatura → top-k → top-p → muestra

No es contabilidad arbitraria, y cambiar dos etapas de sitio produce distribuciones realmente distintas. Dos mediciones, ambas sobre el prompt factual.

Cortar antes o después de la temperatura. El núcleo se calcula sobre la distribución que recibe, y la temperatura cambia esa distribución radicalmente:

En $T = 2$ la misma configuración nominal produce un conjunto de candidatos de 32.966 o de 1, dependiendo únicamente de qué etapa se ejecute primero. Si alguna vez te has preguntado por qué subir la temperatura «no hace nada» en un proveedor y destruye la salida en otro con los mismos dos números, esta tabla es una respuesta plausible.

Penalizar antes o después de la temperatura. Restar una penalización $\alpha$ y luego dividir por $T$ da una penalización efectiva de $\alpha/T$; dividir primero y luego restar da $\alpha$. Con una penalización de presencia de 1,0 aplicada al token líder:

Idénticas en $T = 1$, como deben ser. Separadas por un factor de 1,58 en $T = 2$. «Penalización de presencia 1,0» no es una cantidad de penalización bien definida salvo que también sepas dónde se aplica la temperatura, y ninguna API lo documenta.

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)])

Cada proveedor acepta un subconjunto distinto de estos controles, con rangos distintos, e ignora el resto en silencio. No es una queja abstracta. Cualquier aplicación que ofrezca una elección de modelo tiene que anotar las diferencias en alguna parte, y el archivo donde lo hace es un mapa de la incompatibilidad. Esto es lo que uno de esos catálogos declara para un único parámetro en las nueve fuentes de texto que admite:

La palabra es la misma; la escala no. Una «temperatura de 1» es la distribución sin modificar en uno y el calor máximo permitido en otro, y la mitad del catálogo no puede expresar el valor que la otra mitad trata como neutral-más-un-poco. El resto de mandos son igual de desiguales: las entradas de OpenAI, DeepSeek y xAI aceptan penalizaciones de presencia y frecuencia y ningún topK; las de Google, Meta, Cerebras y PaLM aceptan topK y ninguna penalización; Anthropic acepta topK, topP y secuencias de parada y ninguna penalización; y exactamente uno de los nueve —Mistral— acepta una semilla. Enviar un parámetro que un proveedor no implementa generalmente no produce ningún error: la solicitud tiene éxito, el mando no hace nada y tú concluyes que la configuración no tiene efecto.

Y fíjate en lo que es un archivo así: una afirmación sobre la API de otra persona, escrita un día concreto, que nada verifica después. Un catálogo que diga 0 a 1 para un proveedor que ahora acepta 0 a 2 limitará silenciosamente cada solicitud.

Dos controles más pertenecen a la misma familia. logprobs, cuando se ofrece, devuelve las log-probabilidades del token elegido y a menudo las pocas alternativas principales: la única ventana que obtienes hacia la distribución de la que trata este capítulo, y la base de toda heurística de confianza construida sobre un modelo cerrado. Y máximo de tokens más secuencias de parada terminan la generación sin referencia alguna a la probabilidad: un límite duro y una coincidencia de cadena. Ambos aparecen como el finish_reason del capítulo 14, donde length significa que tu respuesta se cortó a media frase por un presupuesto, no que el modelo la terminó.

Fija una semilla y el muestreo se vuelve reproducible. Esa parte es real, y es fácil verificarla:

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\"."

Idéntico byte a byte dentro de una semilla, distinto entre semillas, exactamente como se anuncia. Así que lo que fija la semilla es la extracción aleatoria de la última línea de esa función sample: qué token se elige dada una distribución.

Lo que no fija es la distribución. Y ahí está el problema, porque el vector de logits que produce tu modelo no es un objeto matemático; es la salida de miles de millones de sumas en coma flotante, y esas sumas tienen un orden.

El capítulo 2 dejó este experimento preparado. El mismo millón de números float32, sumados en agrupaciones distintas:

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

Mira la última línea. El número de chunks cambia la respuesta. No es una curiosidad sobre numpy; es el mecanismo, porque cuando un servidor de inferencia divide una reducción entre más o menos unidades paralelas, está haciendo precisamente esto. Y un servidor divide según cuántas solicitudes esté atendiendo.

Aquí está ese efecto sobre el propio modelo. El mismo prompt, la misma pasada forward, con la única diferencia de cuántas otras solicitudes estaban casualmente en el 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

Ejecutado solo, el modelo es perfectamente determinista: veinte pasadas, idénticas hasta el bit. Pon el prompt idéntico en un batch con solicitudes no relacionadas y el 97 % de sus logits cambian. Nada de tu solicitud cambió. Llegó la solicitud de otra persona.

Ahora la parte honesta, porque esto suele contarse como si fuera el final de la historia. Un cambio de $2.5 \times 10^{-5}$ solo altera la salida si dos tokens candidatos estaban a esa distancia entre sí. En 717 pasos de generación a lo largo de doce prompts, la menor brecha entre los dos logits principales fue $2.5 \times 10^{-3}$ —cien veces mayor que la perturbación— y ningún paso estuvo lo bastante cerca como para volcarse. Así que en este modelo, en float32, en un portátil, el batching movió todos los logits y no cambió ningún token.

Eso describe condiciones favorables, no una garantía, y basta con un cambio en esas condiciones:

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."

Seis de ocho respuestas divergen, y una de ellas se degrada mucho. La tabla del capítulo 2 dice por qué: bfloat16 conserva 7 bits de mantisa, así que cerca de una magnitud de logit de 16 los valores representables están separados por 0,125: 16,0, luego 16,125, luego 16,25; y el redondeo puede mover un logit hasta 0,0625. Mientras tanto, el 4,7 % de los pasos de generación medidos arriba tenían una brecha entre los dos primeros por debajo de 0,1. Esa es toda la diferencia entre los dos experimentos: en float32 la perturbación era cien veces menor que la decisión más cercana, y en bfloat16 tiene el mismo tamaño. La inferencia de producción se ejecuta en 16 bits, sobre hardware con kernels fusionados y órdenes de reducción que nadie promete mantener. Si «el ruido numérico es despreciable» es una pregunta sobre precisión y hardware, no sobre el modelo.

Así que, las cuatro causas, catalogadas como prometió el capítulo 9:

El parámetro seed de OpenAI es honesto sobre esto de la única forma en que puede serlo: se entrega junto con un campo system_fingerprint que identifica la configuración del backend, y la documentación afirma que el determinismo es best-effort y que un fingerprint cambiado significa que los resultados pueden diferir. Léelo como lo que es: un proveedor diciéndote que controla las cuatro causas anteriores, que tú no controlas ninguna, y que lo único que puede ofrecer es decirte a posteriori que algo se movió.

Todo aquí ha tratado de un mando y sus consecuencias. Da un paso atrás y aparece el problema más difícil: el objeto que hemos estado ajustando es una distribución de probabilidad, y las distribuciones de probabilidad no tienen interfaz.

Una function call sí la tiene. Una fila de base de datos sí la tiene. Un handler POST que espera un cuerpo JSON con tres campos obligatorios sí la tiene, y rechazará cualquier otra cosa. Entre el modelo y cada otro componente de tu sistema hay un contrato sobre el que una parte no puede prometer nada: el modelo producirá algo, extraído de una distribución que has moldeado pero no fijado, y el código del otro lado necesita un valor de un tipo conocido o falla.

El puente entre esos dos mundos se construye con el material de este capítulo, no con parsing y reintentos. Si un token rompería la estructura requerida, no lo muestreas y esperas: pones su logit en $-\infty$ antes de que la softmax lo vea. El constrained decoding es una máscara sobre el mismo vector que hemos pasado este capítulo remodelando, y convierte «por favor, responde en JSON» de una petición en una garantía.

El capítulo 18 es ese contrato: tool calling, JSON Schema, salidas estructuradas y qué hace falta para que sea seguro construir un sistema determinista encima de uno probabilístico.

Todas las mediciones de este capítulo proceden de Qwen/Qwen2.5-0.5B-Instruct en CPU, float32 salvo que se indique lo contrario, con el muestreo implementado tal como se escribe en la sección opcional en vez de delegarlo a una biblioteca. Es un modelo pequeño, y los valores concretos son suyos; los mecanismos no. How to generate text with different decoding methods, de Von Platen (Hugging Face, 2020), es el artículo contra el que se mide este y sigue siendo la mejor introducción breve al mismo material. Para la sección de determinismo: las notas de reproducibilidad de PyTorch describen lo que una semilla arregla y no arregla en una sola máquina, la documentación de OpenAI sobre seed y system_fingerprint describe lo que un proveedor puede y no puede prometer, y la discusión de Thinking Machines de 2025 sobre kernels invariantes al batch es el relato público más claro de por qué arreglar esto a nivel de servidor de inferencia es posible, pero no gratis.