Parámetros de modelos: temperatura, top

Durante años, la temperatura fue LA perilla de los modelos de lenguaje: aparecía en cada tutorial, en cada playground y en cada guía de prompting. Hoy, si le mandas temperature a GPT-5 obtienes un error; si se la mandas a Claude Opus 5.5, también; y Google te pide por favor que no la toques en Gemini 3. Esta guía explica qué hacían estos parámetros, cómo se usaban antes, qué los reemplazó y qué usar hoy según el caso.

Fecha de los datos: septiembre 2026. Los proveedores cambian sus APIs rápido — usa esta guía para entender los conceptos y verifica la documentación oficial de cada proveedor antes de escribir código.

1. Qué es el sampling (y qué hacía la temperatura)

Un LLM no “escribe”: en cada paso calcula una probabilidad para cada posible siguiente palabra (token). Ante “El cielo es…”, quizás “azul” tiene 60% de probabilidad, “gris” 20%, “hermoso” 10%, y miles de opciones más se reparten el resto. El sampling (muestreo) es la regla con que se elige entre esas candidatas — y los parámetros clásicos ajustaban esa regla:

Temperatura — controlaba cuánto “azar” había en la elección. Reescala las probabilidades antes de elegir:

Baja (cerca de 0): el modelo elige casi siempre la palabra más probable. Salidas conservadoras, repetitivas entre corridas, “seguras”.
Alta (cerca de 1 o más): las candidatas menos probables tienen chance real de salir. Salidas más variadas y sorprendentes — y con más riesgo de disparate.

Top_p (nucleus sampling) — en vez de reescalar, recorta el menú: solo participan las palabras que acumulan hasta p de probabilidad (top_p 0.9 = “elige solo dentro del 90% más probable”). Descarta la cola de opciones raras.

Top_k — recorte más brusco: solo participan las k palabras más probables (top_k 40 = “elige entre las 40 mejores”).

Los tres atacaban lo mismo — cuánta aleatoriedad tiene la elección de cada palabra — por caminos distintos. Por eso la regla clásica era ajustar uno solo (normalmente temperatura O top_p, nunca ambos).

2. Cómo se usaban antes: la guía clásica

Esta receta funcionó desde GPT-3 hasta los modelos de 2024-2025, y sigue vigente para los modelos no-razonadores que aún la aceptan:

Rango de temperatura	Para qué	Ejemplos
0 – 0.3	Tareas que exigen consistencia y precisión	Extracción de datos, clasificación, generación de código, respuestas a partir de documentos
0.4 – 0.7	Conversación equilibrada	Chatbots de soporte, asistentes generales
0.7 – 1.0+	Variedad y creatividad	Brainstorming, redacción creativa, generar múltiples opciones distintas

Detalles que variaban por proveedor: OpenAI y Google aceptaban temperatura de 0 a 2 (default 1); Anthropic de 0 a 1. Y en la práctica casi nadie tocaba top_p ni top_k — la temperatura era la perilla universal.

3. El giro 2025–2026: llegan los razonadores y la temperatura estorba

Los modelos actuales de frontera son modelos razonadores: antes de responder generan una cadena de razonamiento interna (piensan “en borrador” y luego escriben la respuesta). Y aquí el sampling aleatorio se vuelve un problema: meterle azar a un razonamiento paso a paso produce saltos ilógicos, loops y degradación — justo en las tareas donde más importa la calidad.

La consecuencia: los tres proveedores grandes quitaron o congelaron los parámetros de sampling, cada uno a su estilo.

OpenAI — eliminada con error

Antes (gpt-3.5, gpt-4, gpt-4o, gpt-4.1): temperature 0–2, top_p, frequency_penalty, presence_penalty — todos configurables.
Ahora (GPT-5 en adelante, incluidas las familias 5.6 y 6 actuales): enviar temperature devuelve error “Unsupported parameter”. Lo mismo con top_p, frequency_penalty, presence_penalty, logit_bias y logprobs — quedan fijos internamente (temperatura y top_p en 1, penalties en 0).
Los reemplazos:
- reasoning_effort — cuánto piensa el modelo antes de responder. La escala completa hoy es none, minimal, low, medium, high, xhigh y max, pero no todos los modelos aceptan todos los valores (GPT-6 Astra, por ejemplo, rechaza none); GPT-5.6 parte en medium por defecto. Es la perilla de profundidad: bajo para respuestas rápidas y baratas, alto para problemas difíciles.
- verbosity — cuán larga y detallada es la respuesta (low, medium, high), sin tener que reescribir el prompt. Controla el largo preservando la corrección.
Los modelos antiguos no-razonadores siguen aceptando temperatura, así que el código multi-modelo debe ramificar: si el modelo es GPT-5+, no enviar parámetros de sampling (no hay degradación elegante — es error directo).

Anthropic (Claude) — eliminada con error en los modelos nuevos

Antes (hasta la familia Claude 4.6, incluidos Sonnet 4.6 y Haiku 4.5, vigentes hoy): temperature 0–1; en la familia 4.x se acepta una sola de temperature o top_p (ambas a la vez da error).
Ahora (todo modelo posterior a Opus 4.6: Opus 4.7, 4.8, 5 y 5.5, Sonnet 5, Fable 5 y 5.1): temperature, top_p y top_k fueron eliminados — la referencia de la API los marca como deprecados y enviarlos devuelve error 400 (solo temperature: 1.0 se acepta por compatibilidad).
Los reemplazos:
- Thinking adaptativo (thinking: {type: "adaptive"}) — el modelo decide cuándo y cuánto razonar según la dificultad de cada pedido, en vez de un presupuesto fijo de tokens de razonamiento (el antiguo budget_tokens quedó deprecado/eliminado).
- effort (low, medium, high, xhigh, max) — controla la profundidad de razonamiento y el gasto total de tokens: bajo = respuestas más directas y baratas; alto = más exploración y calidad en tareas difíciles. El default es high (Opus 5.5 parte en medium) y no todos los modelos aceptan xhigh y max.
- El estilo se pide en el prompt: si usabas temperatura 0 buscando consistencia, hoy es effort bajo + instrucciones estrictas; si usabas temperatura alta buscando variedad, hoy se pide explícito (“varía el fraseo y la estructura entre respuestas”, o “propón 4 direcciones distintas antes de elegir una”).

Google (Gemini) — existe, pero “no la toques”

Antes (Gemini 1.5 y 2.5): temperature 0–2 (default 1), top_p, top_k, y en 2.5 un thinking_budget en tokens para el razonamiento.
Ahora (Gemini 3 en adelante, hasta los 3.8 Flash actuales): la temperatura sigue existiendo en la API, pero Google recomienda fuertemente dejarla en su default de 1.0 — la documentación oficial advierte que bajarla “puede producir comportamiento inesperado, como loops o degradación de rendimiento”, sobre todo en tareas matemáticas y de razonamiento. Su consejo explícito para quien migra: borrar los seteos de temperatura del código legado.
El reemplazo: thinking_level (minimal, low, medium, high; default high; minimal no disponible en 3.1 Pro) — la perilla de profundidad de razonamiento. El thinking_budget antiguo quedó deprecado, y usar ambos en el mismo request da error 400.

4. Por qué pasó esto (la explicación de fondo)

Tres razones convergen:

El azar rompe el razonamiento. Una cadena de razonamiento es una secuencia lógica; elegir palabras improbables a mitad de un paso deductivo produce errores que se arrastran y amplifican. Los proveedores calibran el sampling internamente junto con el entrenamiento del modelo — y ese equilibrio es parte del producto, no algo que el usuario deba ajustar a ciegas.
El control se movió de nivel. La temperatura era una perilla de bajo nivel (cuánto azar por palabra) que la mayoría usaba como proxy de cosas que en realidad quería controlar a nivel de comportamiento: cuánto piensa (effort / thinking_level / reasoning_effort), cuánto escribe (verbosity / instrucciones de largo), qué tono usa (prompt). Las perillas nuevas controlan directamente lo que importa — y de paso mapean mejor a costo y latencia.
La promesa de la temperatura 0 era falsa. Mucha gente la usaba creyendo que garantizaba salidas idénticas entre corridas. Nunca fue cierto: la infraestructura del proveedor, las actualizaciones silenciosas del modelo y la aritmética de punto flotante hacen que el mismo input pueda producir salidas distintas incluso a temperatura 0. Quitarla también quita una falsa sensación de control.

5. Tabla de equivalencias: antes → ahora

Lo que lograbas con…	Cómo se hace hoy en modelos razonadores
`temperature: 0` (consistencia, precisión)	Effort/reasoning bajo + prompt estricto + salidas estructuradas (JSON schema) — que garantizan formato de verdad, cosa que la temperatura nunca hizo
`temperature: 0.8+` (creatividad, variedad)	Pedirla en el prompt: “varía fraseo y estructura”, “propón N direcciones distintas y luego desarrolla una”
`top_p` / `top_k`	Nada — dejar los defaults; ya no son configurables (o no conviene tocarlos)
Respuestas más cortas/largas	`verbosity` (OpenAI) o instrucción explícita de largo en el prompt
`thinking_budget` en tokens (Gemini 2.5) / `budget_tokens` (Claude ≤4.6)	`thinking_level` (Gemini 3) · thinking adaptativo + `effort` (Claude) · `reasoning_effort` (GPT-5+)
“Que no invente” (bajar temperatura como anti-alucinación)	Nunca funcionó bien así — RAG con contexto anclado, instrucciones de no inventar y evaluación (ver el manual de evaluación de la academia)

6. Guía práctica: qué usar según el caso

Caso de uso	Modelo clásico (acepta temperatura)	Modelo razonador (GPT-5+, Claude 4.7+, Gemini 3)
Extracción / clasificación	temperatura 0 – 0.2	effort/thinking bajo + salida estructurada
Chatbot de soporte	temperatura 0.3 – 0.5	defaults + prompt de tono; verbosity/largo explícito
Redacción creativa	temperatura 0.8 – 1.0	prompt pidiendo variedad; effort medio
Razonamiento complejo (análisis, matemática, código difícil)	temperatura baja (y cruzar los dedos)	effort/thinking alto — para esto se inventaron estas perillas
Agentes y tareas largas	temperatura 0 – 0.3	effort alto/xhigh + especificación completa de la tarea al inicio

Y la regla de oro para código nuevo: no mandes parámetros de sampling salvo que sepas exactamente por qué. El default del proveedor es hoy la opción correcta en casi todos los casos, y el código queda portable entre modelos.

7. Mitos para dejar atrás

“Temperatura 0 = respuestas idénticas siempre” — falso desde siempre; el no-determinismo viene también de la infraestructura y de actualizaciones del proveedor.
“Más temperatura = modelo más creativo/inteligente” — no: es más azar por palabra. La creatividad útil se pide en el prompt; el azar solo hace la salida menos predecible.
“Hay que setear temperatura en toda llamada” — al revés: hoy el mejor default es no enviarla, y en los modelos nuevos enviarla es directamente un bug (error 400).
“Esto es un cambio cosmético de las APIs” — es un cambio de paradigma: pasamos de ajustar cómo elige palabras el modelo a ajustar cuánto piensa y cuánto escribe. Las perillas nuevas son más útiles, más predecibles y mapean directo a costo y latencia.

Fuentes

OpenAI — Reasoning models (documentación oficial) — parámetros no soportados en modelos razonadores.
OpenAI — Introducing GPT-5 for developers — presentación de reasoning_effort y verbosity.
OpenAI Cookbook — GPT-5 New Params and Tools — uso práctico de los parámetros nuevos.
OpenAI Community — Temperature in GPT-5 models — confirmación del error “Unsupported parameter” y valores fijos.
Microsoft Learn — Azure OpenAI reasoning models — parámetros fijos (temperature/top_p = 1, penalties = 0) en la serie GPT-5.
Google — Gemini 3 Developer Guide — recomendación de mantener temperatura en 1.0, thinking_level y deprecación de thinking_budget.
Google Developers Blog — New Gemini API updates for Gemini 3 — anuncio de los cambios de API en Gemini 3.
Anthropic — Referencia oficial de la API de Claude (Messages): temperature, top_p y top_k marcados como deprecados para los modelos posteriores a Opus 4.6; guía de effort y thinking adaptativo (verificado en septiembre de 2026).

Parámetros de modelos: temperatura, top_p y su reemplazo