Inference Engineering: qué es y qué se optimiza (TTFT, tokens/s, VRAM, costo)

El mismo modelo, la misma GPU, la misma pregunta. Un servidor responde con el primer token en 300 ms; otro tarda casi dos segundos. La diferencia no está en el modelo. Está en todo lo demás: cómo se sirve, cómo se agrupan las peticiones, cuánta memoria se reserva, qué se cachea.

Eso es Inference Engineering: la disciplina de correr modelos, no de entrenarlos. Es la parte del stack de AI que casi nadie documenta en español y la razón por la que me estoy moviendo hacia ahí. Esta pieza es el mapa: qué se mide, dónde está el cuello de botella y por dónde empezar.

Entrenar vs inferir

Entrenar es escribir el modelo: ajustar miles de millones de parámetros con datos. Inferir es usarlo: darle un prompt y calcular la respuesta.

La mayoría de los ingenieros de AI no entrenamos nada. Consumimos modelos (de API o abiertos) y nuestro trabajo es que respondan rápido, barato y sin caerse. Ese trabajo tiene métricas propias, palancas propias y presupuestos propios.

Las 5 métricas que se optimizan

Y la que manda sobre todas: VRAM. La memoria de la GPU decide qué modelo puedes correr, con cuánto contexto y cuántas peticiones a la vez. Todo lo demás se negocia contra ella.

El presupuesto de VRAM (la cuenta que nadie te enseña)

La VRAM que necesita un modelo no son solo sus pesos:

VRAM ≈ pesos (parámetros × bits/8) + caché KV (contexto × batch) + overhead

Un modelo de 8B en FP16 pesa unos 16 GB solo en pesos. A eso se le suma la caché KV: la memoria de las conversaciones en curso, que crece con el contexto y con el número de peticiones simultáneas. Un modelo que "cabe" en tu GPU puede no caber con 8 usuarios a 32k de contexto. Ese es el error número uno: presupuestar por pesos y olvidar el contexto.

Las palancas (lo que de verdad mueve la aguja)

1. Cuantización: guardar los pesos en 8 o 4 bits. Es la forma más directa de que un modelo quepa. → Cuantización con números
2. Batching continuo: en vez de atender una petición por vez, el servidor mezcla tokens de varias en el mismo paso de GPU. vLLM se presenta como "full-fledged continuous batching engine" y reporta hasta 1.7x más throughput que su versión anterior, medido con Llama 3.1 8B y Llama 3.3 70B sobre el dataset ShareGPT. - Source: vLLM V1: A Major Upgrade to vLLM's Core Architecture
3. Prefix caching (KV cache): si muchas peticiones comparten el mismo prefijo (tu system prompt, un documento), se calcula una vez y se reutiliza. vLLM reporta menos de 1% de pérdida de throughput con 0% de aciertos, y varias veces más rendimiento con aciertos altos, por eso lo activa por defecto. - Source: vLLM V1
4. Atención paginada (PagedAttention): gestionar la caché KV en bloques en vez de reservar memoria fija por conversación; es lo que permite servir más contexto simultáneo con la misma VRAM. - Source: Efficient Memory Management for LLM Serving with PagedAttention - Kwon et al.
5. Routing de modelos: no todo necesita el modelo caro. Un clasificador barato decide qué petición va a qué modelo. → Model routing y costos
6. Speculative decoding: un modelo pequeño propone tokens y el grande los verifica. Ganas velocidad cuando el pequeño acierta.

El cuello de botella que casi nadie mira: la CPU

En modelos pequeños el problema deja de ser la GPU. vLLM documenta que, con Llama-8B en una NVIDIA H100, el tiempo de ejecución en GPU puede ser de ~5 ms, y el resto del tiempo se va en CPU: tokenizar, preparar inputs, des-tokenizar, hacer streaming de la respuesta. - Source: vLLM V1

Traducción práctica: puedes tener una GPU sobrada y un servidor lento por culpa de la CPU y del loop del API. Antes de comprar hardware, mira dónde se va el tiempo.

Cómo empezar (esta semana)

1. Calcula el presupuesto de VRAM del modelo que quieres (pesos + KV cache a tu contexto y concurrencia). Si no cabe, cuantiza o baja el contexto.
2. Corre el modelo local con LM Studio u Ollama para tener una línea base. → Inferencia local en 2026
3. Mide TTFT y tokens/s con un script simple y repetible, no "a ojo". → Medir inferencia sin engañarte
4. Sube a vLLM cuando necesites varias peticiones simultáneas: es ahí donde el batching continuo cambia el juego.
5. Ponle precio a tu feature: costo por 1M tokens o por hora de GPU. Si no lo sabes, no es un producto. → El costo real de tu feature de AI

Todo el desarrollo completo está en la guía Inference Engineering: de cero a producción.

¿Tu cuello de botella hoy es el modelo, la GPU o la CPU? Cuéntame en los comentarios: es la primera pregunta que hago cuando alguien dice "mi AI va lento".

Referencias

• vLLM V1: A Major Upgrade to vLLM's Core Architecture - vLLM Team
• Efficient Memory Management for LLM Serving with PagedAttention - Kwon et al. (paper)
• Models for Agents (vLLM, Ollama, routing) - Google ADK