La Inferencia es un Problema Nuevo
El entrenamiento es un trabajo por lotes: horas de cómputo intensivo y nadie espera una sola respuesta. La inferencia es un servicio activo: miles de solicitudes por segundo, cada una con un presupuesto de latencia medido en cientos de milisegundos. Los objetivos de optimización son completamente diferentes: ya no maximizas precisión, maximizas solicitudes-por-segundo dentro de un SLA de latencia.
Latencia vs Rendimiento
- Latencia — tiempo desde la solicitud hasta el primer/total de tokens (los usuarios lo sienten).
- Rendimiento — solicitudes o tokens servidos por segundo (los costos dependen de esto).
Hay una compensación. Los lotes pequeños minimizan la latencia; los lotes grandes maximizan el rendimiento. Los sistemas de producción ajustan la agrupación para llenar la brecha entre el presupuesto de latencia y el tiempo de inactividad de la GPU.
Agrupación
Una GPU puede procesar muchas secuencias en paralelo. El agrupamiento dinámico agrupa solicitudes que llegan juntas en una sola pasada. El stack de serving de LLM también reutiliza el KV cache: las tensores clave/valor de los tokens generados anteriormente, almacenados en caché para que el siguiente token solo recalcule la posición más nueva. Sin el KV cache, cada token re-procesaría todo el prompt — la optimización de serving más importante.
Cuantización
Los pesos del modelo suelen ser floats de 16 bits. La cuantización los reduce a enteros de 8 o 4 bits:
| Precisión | Memoria | Velocidad | Impacto en calidad |
|---|---|---|---|
| FP16/BF16 | Base | Base | Ninguno |
| INT8 | ~½ | Más rápido | despreciable |
| INT4 | ~¼ | Más rápido | Pequeño, depende de la tarea |
Pesos más pequeños significan que más del modelo cabe en la memoria de la GPU, mayores tamaños de lote y serving más barato — a costa de un pequeño riesgo de calidad que debe evaluarse por tarea.
Inferencia en GPU vs CPU
| CPU | GPU | |
|---|---|---|
| Coste por token | Más alto | Más bajo a escala |
| Latencia por solicitud | Más alta | Más baja |
| Ideal para | Modelos pequeños, tolerantes a cold start, carga esporádica | Modelos grandes, carga alta y constante |
Modelos pequeños (embedders, clasificadores, re-rankers) suelen servir bien en CPU. Modelos generativos grandes necesitan GPU. La elección equivocada quema dinero o latencia.
Autoescalado y Cold Starts
Los endpoints de modelo se escalan por volumen de solicitudes, pero cargar un modelo de varios Gigabytes toma decenas de segundos: el cold start es real. Las políticas de autoescalado deben aprovisionar antes de picos, mantener un mínimo base y aceptar que las nuevas instancias no pueden servir al instante. La caché de completaciones repetidas y la reutilización de instancias de GPU son mitigaciones estándar.
Cuándo es la Herramienta Correcta
Elige serving auto-hospedado cuando controlas la infraestructura y la carga es constante; elige una API de inferencia gestionada cuando la carga es puntiaguda, quieres operar sin ops, o el modelo cambia a menudo. La respuesta correcta depende del coste-por-token, presupuesto de latencia, requisitos de residencia de datos y tiempo de ingeniería — no de moda.
Trayectoria de Práctica
- Explica por qué la reutilización del KV-cache es la victoria de serving de LLM más importante.
- Estima la memoria ahorrada por INT8 vs FP16 para un modelo de 7B parámetros.
- Describe un patrón de carga donde la inferencia en CPU es la mejor opción.
- Diseña una política de autoescalado que sobreviva a un cold start.
- Compara serving auto-hospedado vs gestionado para dos escenarios con nombre.