5  Inferencia: los mandos y la factura

Entrenar un modelo es cosa de unos pocos. Usarlo es cosa de todos, y ahí hay una cantidad sorprendente de decisiones que se toman por defecto sin saber que se están tomando. Este capítulo repasa los mandos que tenemos a mano y lo que cuesta moverlos.

5.1 Los parámetros de muestreo

En cada paso el modelo produce una distribución de probabilidad sobre todo su vocabulario. Elegir un token de esa distribución es muestrear, y ahí es donde intervenimos.

Temperatura. Aplana o afila la distribución antes de sortear. Con temperatura 0 se elige siempre el token más probable y el sistema se vuelve (casi) determinista. Subiéndola se da oportunidad a candidatos menos probables y aparece la variedad, y con ella el disparate.

Top-p (o muestreo por núcleo). En lugar de considerar todo el vocabulario, se ordenan los candidatos y se corta cuando la probabilidad acumulada llega a \(p\). Con top_p = 0.9 se descarta la cola larga de tonterías pero se conserva la variedad cuando el modelo duda de verdad. Es un corte adaptativo, y por eso suele funcionar mejor que top-k, que corta siempre por el mismo número de candidatos aunque el reparto sea muy distinto.

Punto de partida razonable, no dogma

Caso de uso	Temperatura	Por qué
Extraer campos de un documento	0	Solo hay una respuesta correcta
Clasificar o enrutar	0	Queremos reproducibilidad
Generar código	de 0 a 0.3	Compila o no compila
Redactar un texto	0.7	Queremos que no suene a plantilla
Generar ideas o variantes	de 0.9 a 1.2	Buscamos dispersión a propósito

AdvertenciaTemperatura 0 no es determinismo

Es la trampa que más desconcierta al depurar. Aun con temperatura 0, la misma petición puede dar respuestas distintas: la aritmética en coma flotante sobre GPU no es asociativa y el resultado depende de cómo se agruparon las peticiones en el lote, que depende de la carga del servicio en ese instante.

A eso se suma que el proveedor puede actualizar el modelo bajo el mismo nombre comercial. Si vuestro sistema necesita reproducibilidad estricta, fijad la versión exacta del modelo y asumid que aun así habrá variación. Cualquier prueba automática que compare la salida carácter a carácter os va a fallar de forma intermitente, que es la peor manera de fallar.

5.2 La ventana de contexto

La ventana es el total de tokens que caben en una llamada, sumando lo que enviamos y lo que el modelo escribe. Los modelos de 2026 se mueven entre los 128.000 y el millón largo de tokens, y esa abundancia ha cambiado el diseño de estos sistemas más que ninguna otra cosa.

Tres precisiones que evitan disgustos:

• La ventana es compartida. El system prompt, el historial de la conversación, los documentos recuperados, las definiciones de las herramientas y las respuestas de esas herramientas salen todos del mismo presupuesto. En un agente con quince herramientas, sus definiciones pueden ser miles de tokens antes de que el usuario abra la boca.
• Llenarla es caro y lento. Y recordemos que el coste de la atención crece con el cuadrado de la longitud.
• Llenarla degrada la calidad. Es el problema de lost in the middle y el argumento central de la ingeniería de contexto.

5.3 Razonar gastando más

La novedad de los últimos años es la aparición de modelos que, antes de responder, generan una cadena de razonamiento interna. La idea de fondo ya estaba en la técnica de chain-of-thought (Wei et al. 2022), que consistía en pedir al modelo que pensara paso a paso; lo que ha cambiado es que ahora se entrena al modelo para hacerlo por su cuenta, con aprendizaje por refuerzo sobre problemas de solución verificable (DeepSeek-AI 2025).

Esto abre un eje nuevo: además de elegir un modelo más grande, se puede dejar al mismo modelo pensar más rato. El cómputo en inferencia pasa a ser un mando de calidad.

flowchart LR
    p["Pregunta"] --> m["Modelo"]
    m --> th["Razonamiento<br/>(tokens que se pagan<br/>y no se ven)"]
    th --> r["Respuesta"]

    classDef externo fill:#ececf0,stroke:#868d9c,stroke-width:1.5px,color:#2b2f3a
    classDef modelo fill:#e6ddf5,stroke:#7457bd,stroke-width:1.5px,color:#332757
    classDef contexto fill:#d5e6f5,stroke:#3d7cb0,stroke-width:1.5px,color:#12354e
    class p externo
    class m modelo
    class th contexto
    class r modelo

Conviene tenerlo presente en tres frentes. Esos tokens de razonamiento se facturan aunque no se muestren. Multiplican la latencia, lo que descarta estos modelos para casos interactivos ajustados. Y su ganancia se concentra en tareas con estructura (matemáticas, código, planificación); para reformular un correo, pagar por razonamiento es tirar el dinero.

5.4 Salida estructurada

Cuando la respuesta va a ser consumida por un programa y no por una persona, pedir “devuélveme un JSON” en el prompt es insuficiente: tarde o temprano llegará envuelto en un bloque de código, con un comentario delante o con una coma de más.

Prácticamente todos los proveedores ofrecen hoy salida estructurada, donde se le pasa un esquema (JSON Schema, o una clase de Pydantic que lo genera) y la propia decodificación se restringe a tokens que mantengan la salida válida. No es un ruego, es una restricción mecánica: el JSON sale bien formado por construcción.

from pydantic import BaseModel

class Factura(BaseModel):
    numero: str
    importe: float
    moneda: str

# El esquema se pasa al proveedor y la respuesta llega ya validada

Que el esquema se cumpla no significa que los datos sean correctos: garantiza que importe es un número, no que sea el importe. La validación sintáctica es gratis, la semántica sigue siendo cosa nuestra.

Qué significa “restringir la decodificación”

Merece la pena abrir esa frase, porque debajo hay un mecanismo muy simple que explica varias cosas del resto del manual.

En cada paso, el modelo produce un número por cada token del vocabulario. Lo normal es elegir entre todos. La decodificación condicionada añade un filtro antes de elegir: el esquema se compila a un autómata que sabe, en cada punto de la generación, qué tokens mantendrían la salida válida y cuáles la romperían. A los que la romperían se les pone la probabilidad a cero y se elige entre el resto.

Si ya hemos escrito {"numero": "F-2026-1", el autómata sabe que lo siguiente tiene que ser una comilla abriendo el nombre del campo que falta, así que todos los demás tokens dejan de estar disponibles. No es que el modelo se porte bien: es que no puede escribir otra cosa.

De ahí salen tres consecuencias que conviene tener claras:

• La validez está garantizada, no es probable. No hay un porcentaje de fallo que baje con un prompt mejor: los estados inválidos no existen.
• En su versión más simple no hace falta ni un esquema. Si la salida tiene que ser una de cinco etiquetas, basta con mirar los números de los cinco tokens que abren cada una y quedarse con el mayor. Es una sola pasada y sale gratis una medida de cuánto duda, cosa que aparece en varios cuadernos del manual.
• Es exactamente lo que hay detrás de las llamadas a herramientas. Cuando decimos que un modelo “decide” invocar una herramienta con unos argumentos, lo que ocurre por debajo es una decodificación restringida al esquema de esa herramienta. Son el mismo mecanismo contado dos veces, y verlo así ahorra bastante confusión al llegar a la parte de agentes.

AdvertenciaForzar la gramática no mejora el contenido

Es la contrapartida y se olvida a menudo. Restringir la decodificación garantiza la forma y puede empeorar el fondo, porque obliga al modelo a seguir por un camino que quizá no era el que llevaba.

El caso típico: un campo obligatorio cuyo dato no está en el documento. Sin restricción, el modelo tenía la opción de decir que no lo encuentra. Con el esquema encima, tiene que escribir algo en ese campo, y escribirá lo más plausible que se le ocurra. Un Optional bien puesto evita más alucinaciones que media página de instrucciones.

5.5 Decodificación especulativa

Queda un mando que no está en el prompt ni en los parámetros de muestreo y que explica por qué dos servicios con el mismo modelo pueden ir a velocidades muy distintas.

El problema de fondo es que generar es secuencial. Cada token necesita el anterior, así que por muchas GPU que se pongan, la latencia de una respuesta larga está atada a ese ir y venir. No es un problema de cómputo sino de dependencia.

La idea para romperla es apostar. Un modelo pequeño y rápido, el borrador (drafter), propone varios tokens de golpe. El modelo grande los verifica todos en una sola pasada, que es algo que sí puede hacer en paralelo, y acepta el prefijo con el que está de acuerdo. Desde el primer desacuerdo, descarta el resto y pone su propio token.

Lo importante, y lo que hace que esto no sea un compromiso sino una mejora limpia: la salida es idéntica a la que habría producido el modelo grande solo. El pequeño no decide nada, solo adivina para ahorrar viajes. Si adivina bien, se ganan varios tokens por pasada; si adivina mal, se pierde poco.

Cómo se hace en la práctica

Durante años esto exigía dos modelos entrenados por separado y compatibles entre sí, que es un requisito incómodo. La tendencia desde 2026 es publicar el borrador junto con el modelo, entrenado para acompañarlo.

Las familias Gemma 4 son el ejemplo más claro: cada modelo se distribuye con un borrador de predicción multi-token pensado para él. El del modelo pequeño de la familia ronda los 76 millones de parámetros y cuatro capas, comparte la tabla de embeddings con el modelo grande, se apoya en las activaciones de su última capa y cruza la atención contra su caché en lugar de mantener una propia. Google habla de aceleraciones de hasta tres veces sin pérdida de calidad. Hay un repaso visual del mecanismo que lo explica en viñetas, y el anuncio con las cifras.

Dos matices para leer bien esas cifras:

Acelera la latencia, no abarata la factura. Se pagan los mismos tokens de entrada y de salida, solo que llegan antes. Quien busque ahorrar dinero tiene que mirar las palancas de abajo; quien busque que la respuesta empiece a aparecer antes, esto.

La ganancia depende de lo predecible que sea el texto. Con salida muy estructurada, código o formatos fijos, el borrador acierta mucho y la aceleración es grande. Con texto creativo, acierta menos y la ganancia se encoge. Los “hasta 3x” de cualquier fabricante son el mejor caso, no la media.

5.6 Lo que cuesta

Los precios por token han caído de forma brutal y sostenida, y sin embargo las facturas de IA de las empresas no paran de crecer. No es una paradoja: al bajar el precio unitario se disparan los casos de uso y, sobre todo, se disparan los tokens por caso de uso. Un agente que da diez vueltas a un bucle con el historial completo en cada vuelta consume mucho más que un chat.

La estructura de costes tiene una forma bastante estable:

Por qué un agente cuesta lo que cuesta

Concepto	Orden de magnitud relativo
Tokens de entrada	Barato
Tokens de entrada en caché	Muy barato (a menudo una décima parte)
Tokens de salida	Caro (varias veces la entrada)
Tokens de razonamiento	Se facturan como salida

De ahí salen las tres palancas que de verdad mueven la aguja, por orden de eficacia:

1. Enrutar por dificultad. La mayor parte del tráfico real no necesita el modelo más caro. Mandar lo fácil a un modelo pequeño y reservar el grande para lo difícil es la decisión que más ahorra, y es justo lo que facilita un gateway.
2. Cachear el prefijo. Estructurar los prompts para que la parte estable vaya delante y se reutilice.
3. Acortar la salida. Pedir campos en vez de prosa. Es donde está el precio alto.

TipMedid antes de optimizar

Sin trazas por petición con tokens de entrada, salida y modelo, cualquier discusión sobre coste es una discusión de opiniones. Instrumentar esto es barato y es el tema del capítulo de observabilidad. Los datos del sector son elocuentes: la enorme mayoría de las organizaciones se equivoca en su previsión de gasto en IA por márgenes que en cualquier otra partida serían inaceptables.

Con los mandos claros, toca ver qué modelos hay para elegir: el panorama.

DeepSeek-AI. 2025. «DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning». arXiv preprint arXiv:2501.12948.

Wei, Jason, Xuezhi Wang, Dale Schuurmans, et al. 2022. «Chain-of-Thought Prompting Elicits Reasoning in Large Language Models». Advances in Neural Information Processing Systems 35.