Inference

Definición

Inference o inferencia es el proceso de usar un modelo ya entrenado para generar predicciones o respuestas en tiempo real. Es la fase de explotación del modelo: cada vez que llamas a la API de OpenAI, Anthropic o Google, o cada vez que tu servidor procesa una petición contra un modelo desplegado, estás haciendo inference.

Es la cara visible (y facturada) de la IA: mientras el pretraining ocurre una vez con coste fijo enorme, la inference ocurre millones o billones de veces y su coste agregado supera al de entrenamiento en cualquier modelo que llegue a producción seria.

Para hacerse una idea de la escala: ChatGPT atiende del orden de mil millones de mensajes al día. Cada uno implica una inference completa. El gasto en GPUs y energía para inference de OpenAI se estima en miles de millones de dólares anuales.

Cómo funciona

La inference de un LLM tiene dos fases muy distintas técnicamente:

Prefill (procesar el prompt)

1. El prompt completo se tokeniza.
2. Todos los tokens se procesan a través del transformer en paralelo (una única gran pasada).
3. Se calcula y cachea la KV cache (Key/Value de cada capa para cada token) que se usará en la fase siguiente.

Esta fase es compute-bound: usa intensivamente las GPUs.

Decode (generar la respuesta)

1. El modelo genera el primer token de respuesta usando la KV cache del prompt.
2. Ese token se añade al contexto, se actualiza la KV cache.
3. Se genera el segundo token. Y así sucesivamente.
4. Cada token requiere una pasada completa por el modelo, leyendo todos los pesos desde memoria HBM de la GPU.

Esta fase es memory-bandwidth-bound: leer los pesos del modelo (cientos de GB) es el cuello de botella, no el cómputo.

Es por eso que un modelo grande puede generar respuestas a, digamos, 40-100 tokens/segundo en una GPU H100, sin importar cuánto cómputo aplique. La velocidad la limita la memoria.

Sampling: cómo se elige el siguiente token

Después de cada pasada, el modelo produce una distribución de probabilidad sobre todo el vocabulario (cientos de miles de tokens posibles). El método de sampling decide cuál seleccionar:

• Greedy: siempre el token más probable. Determinista pero repetitivo.
• Temperature: divide los logits por T antes del softmax. T baja (0-0.3) → respuestas conservadoras. T alta (0.7-1.5) → respuestas creativas y diversas.
• Top-k: solo considera los k tokens más probables. Filtra cola larga.
• Top-p (nucleus): considera los tokens más probables hasta que su probabilidad acumulada llegue a p. Más adaptativo que top-k.
• Min-p, repetition penalty, frequency penalty: variantes adicionales.

En producción se suelen combinar (temperature + top-p). Para tareas que requieren exactitud (extracción estructurada, código) → temperature 0. Para creatividad (escritura, brainstorming) → 0.7-1.0.

Ventana de contexto y sus límites

La ventana de contexto es el máximo de tokens que el modelo puede procesar en una sola inferencia (prompt + respuesta). Cifras actuales (2026):

• Claude Opus / Sonnet: 200k tokens (~150.000 palabras, libro completo).
• GPT-5: 400k tokens (rumor).
• Gemini 1.5/2: 1M-2M tokens (un par de novelas + código).
• Llama 3.1: 128k tokens.
• Modelos pequeños abiertos: 8k-32k típicamente.

Más contexto no es gratis: la atención escala cuadráticamente. Procesar 200k tokens es ~4× más caro que procesar 100k, y la latencia aumenta proporcionalmente.

Alucinaciones

La hallucination es cuando el modelo genera información que suena correcta pero es factualmente falsa. Sucede porque el LLM optimiza coherencia textual, no verdad. No tiene mecanismo intrínseco de verificación; solo predice el siguiente token según la distribución aprendida.

Mitigaciones en inference:

• Temperature baja: respuestas más deterministas, menos invención.
• RAG: dar contexto factual verificable en el prompt.
• Verificación posterior: comparar respuesta con fuentes, o usar un modelo de fact-check.
• Prompting cuidado: pedir explícitamente "si no sabes, dilo" reduce algo el problema.
• Cadenas de razonamiento (chain-of-thought): forzar al modelo a pensar paso a paso suele reducir errores.

Las alucinaciones son inherentes al paradigma actual. Mientras no haya modelos con grounding factual real, son un riesgo a gestionar, no eliminar.

Ejemplo práctico: el coste real de una llamada

Cuando un usuario en antonioecheverria.es lanza una pregunta al bot:

• Prompt total (system + RAG context + pregunta): 1.800 tokens.
• Respuesta: 220 tokens.

Con Claude Sonnet 4.6 (precios ~3 €/MTok input, 15 €/MTok output):

• Coste prefill: 1.800 × 3 / 1.000.000 = 0,0054 €.
• Coste decode: 220 × 15 / 1.000.000 = 0,0033 €.
• Total ≈ 0,0087 € por interacción.

Si el usuario quiere streaming (ver la respuesta token a token), el tiempo total será:

• Prefill: ~400ms para 1.800 tokens.
• Decode: 220 tokens / ~50 tokens-s = ~4,4 segundos.
• TTFT (Time To First Token): ~400-500ms.
• Tiempo total: ~5 segundos.

Optimizaciones reales que aplicamos en producción:

• Prompt caching: cachear el system prompt + RAG estático → coste de prefill / 10.
• Speculative decoding: usar un modelo pequeño para "adelantar" tokens al grande → 2-3× tokens/s.
• Modelo más pequeño cuando aplica: Haiku para tareas simples, Sonnet/Opus para complejas. Router inteligente.
• Batch: agrupar varias peticiones simultáneas.

Inferencia: tipos de deployment

• API gestionada: OpenAI, Anthropic, Google. Pagas por token, no gestionas nada. Simple y caro a escala.
• Modelo abierto en cloud: Llama/Mistral en Together AI, Fireworks, Anyscale, Groq. Pago por uso pero más barato y más control.
• Autohospedado en cloud: tus propias GPUs en AWS, GCP, Azure. Cuando el volumen es grande.
• Autohospedado on-premise: cuando hay restricciones de privacidad o regulatorias.
• Edge: modelo cuantizado en dispositivo (iPhone, Pixel, Mac M-series). Llama 3.1 8B corre decentemente en una Mac M3.

Hardware típico para inference de LLMs grandes: NVIDIA H100/H200, AMD MI300X, Google TPU v5, Groq LPUs (especializados para velocidad de inferencia).

Errores comunes en inference

• Llamar siempre al modelo más caro: la mayoría de tareas no necesitan Opus o GPT-5. Routear por complejidad ahorra 5-10×.
• No usar streaming cuando aporta UX: hace la latencia perceptible mucho menor.
• Ignorar prompt caching: si tienes system prompts grandes que se repiten, no cachear es dejar dinero sobre la mesa.
• No medir TTFT y tokens-s: si tu UX percibe lenta una API, mide antes de optimizar.
• Temperature alta para tareas estructuradas: provoca outputs inconsistentes en código, JSON, extracción.
• Contexto inflado innecesariamente: cada token extra es coste. Comprimir prompt es la optimización con mejor ROI.
• Reintentar sin idempotencia ni jitter: amplifica fallos transitorios.
• No tener fallback: si tu único proveedor cae, tu producto cae. Usa al menos dos.

Cuándo prestar atención al detalle de inference

Sí, profundiza si:

• Tu producto depende de LLMs y los costes empiezan a escalar.
• La latencia afecta a la UX y necesitas optimizar.
• Estás eligiendo entre proveedores y modelos.
• Tu volumen justifica autohospedar.

Es menos crítico si:

• Estás prototipando casualmente con bajo volumen.
• Tu uso es interno con pocos usuarios y el coste es marginal.

Referencias

• vLLM · Continuous batching for LLM inference — el motor open source más usado para inference eficiente
• Anthropic · Prompt caching — documentación oficial del cache para reducir coste
• Speculative decoding paper (Leviathan et al.) — técnica clave para acelerar generación