README · by ansango
← Volver al libro

Fundamentos y optimización de inferencia

Cómo poner un modelo en producción: panorama de inferencia, métricas de rendimiento, AI accelerators, model optimization y service optimization

~7 min de lectura
Resumen

Esta nota cubre el capítulo 9 completo: la fase de inferencia, donde el modelo ya entrenado recibe peticiones en producción y genera respuestas. Vemos qué es la inferencia, las métricas que importan (latencia, throughput, coste), los AI accelerators (GPU, TPU, ASIC), las técnicas de model optimization (cuantización, pruning, distillation, Flash Attention) y las de service optimization (batching, caching, speculative decoding, paralelización). El libro es claro: la optimización de inferencia es donde se decide si tu producto es viable económicamente.

Por qué la inferencia importa

El libro abre el capítulo con un dato contundente: la inferencia es la mayor parte del coste de una aplicación de IA. Mientras que entrenar un modelo es un gasto único (y enorme), servirlo cuesta por cada llamada, todos los días, durante años. Una mala optimización de inferencia puede hundir un negocio con buen modelo.

“El entrenamiento es la inversión inicial. La inferencia es la hipoteca.”

La inferencia es lo que pagas recurrentemente, así que optimizarla tiene impacto directo en el modelo económico.

Understanding inference

Qué es la inferencia

Inferencia es el proceso de usar un modelo entrenado para generar outputs a partir de inputs nuevos. En LLMs, típicamente:

  1. Prefill: el modelo procesa el prompt completo en paralelo, calcula KV cache.
  2. Decode: el modelo genera tokens uno a uno, cada uno condicional al anterior.

Estas dos fases tienen características muy distintas:

Inference overview

El libro describe tres modos principales de servir un modelo:

Online inference

Responde a peticiones en tiempo real con baja latencia. El caso típico de chatbots y APIs.

Batch inference

Procesa grandes volúmenes de peticiones en grupos. Acepta latencia mayor (minutos-horas) a cambio de mayor throughput.

Streaming inference

Responde con tokens a medida que se generan. Reduce el time-to-first-token percibido por el usuario.

Métricas clave

Latencia

Siempre mide p95, no la media

La latencia mediana engaña. Un p95 de 5 segundos es una mala experiencia para el 5% de tus usuarios. Mide p50, p95, p99 y pon alertas en los dos últimos.

Throughput

Coste

Calidad

Aunque no es métrica de infraestructura, hay que medirla en inferencia:

Trade-off latencia vs throughput

Batching más grande = más throughput, peor latencia. Batching más pequeño = menos throughput, mejor latencia. El batch size óptimo depende del caso de uso.

AI accelerators

El hardware que ejecuta la inferencia determina el techo de rendimiento.

CPU

GPU

El estándar para inferencia de LLMs.

TPU

ASIC especializados

Apple Silicon

Cómo elegir

CasoHardware recomendado
Experimentación localApple Silicon, RTX 4090
Inferencia pequeña-mediaA100, L4
Inferencia alta escalaH100, A100 cluster
Latencia ultra-bajaGroq, Inferentia
Cloud-nativeTPU en GCP, Inferentia en AWS

Model optimization

Técnicas que reducen el coste del modelo en sí: tamaño, memoria, tiempo de inferencia.

Cuantización

La técnica más efectiva. Reduce los bits por peso de 16 a 8 o 4.

Trade-offs

Frameworks de cuantización

Pruning

Eliminar pesos que contribuyen poco, “podando” la red.

Distillation

Entrenar un modelo pequeño para imitar a uno grande.

Distillation vs quantization

Son ortogonales. Un modelo puede estar cuantizado Y destilado. La combinación típica es: destilar a un modelo más pequeño, después cuantizar, y obtener reducciones de 10-30x con calidad razonable.

Flash Attention

Optimización algorítmica que reduce el uso de memoria y acelera el cómputo de la atención.

Soporte nativo en PyTorch 2.0+, cada vez más el estándar.

KV cache optimization

El KV cache (que almacena claves y valores pasados) crece linealmente con la longitud del contexto. Optimizaciones:

Speculative decoding

Usar un modelo pequeño y rápido para proponer tokens, y un modelo grande y preciso para verificarlos.

# Pseudo-código
def speculative_decoding(prompt, draft_model, main_model, k=4):
    while not done:
        # Draft model propone k tokens
        draft_tokens = draft_model.generate(prompt, k=k)
        
        # Main model verifica los k tokens en paralelo
        main_logits = main_model.score(prompt + draft_tokens)
        
        # Aceptar los tokens correctos, rechazar los incorrectos
        accepted = verify(draft_tokens, main_logits)
        prompt += accepted

Inference service optimization

Técnicas que optimizan cómo se sirve el modelo, no el modelo en sí.

Batching

Agrupar varias peticiones en un solo forward pass.

Static batching

Tamaño fijo de batch. Simple pero ineficiente.

Dynamic batching

Tamaño variable, ajustándose a la carga. Más complejo pero mejor.

Continuous batching (in-flight batching)

Cada vez que un request termina, se añade uno nuevo al batch. Utilización mucho mayor.

Caching

Cachear resultados para evitar recomputación.

Prompt caching

Si dos requests tienen prompts idénticos (mismo system prompt + context), cachear el KV cache.

Response caching

Si dos requests producen la misma respuesta, cachear directamente.

Semantic caching

Cachear por similitud semántica del prompt. Dos prompts parecidos comparten cache.

import hashlib

def semantic_cache_lookup(query, cache):
    query_embedding = embed(query)
    for cached_query, cached_response in cache:
        if cosine_sim(query_embedding, cached_query) > 0.95:
            return cached_response
    return None

Paralelización

Para servir modelos muy grandes, distribuir entre GPUs.

Tensor parallelism

Particionar los pesos del modelo entre GPUs. Cada GPU tiene una parte.

Pipeline parallelism

Capas consecutivas en GPUs distintas. Pipeline de procesamiento.

Sequence parallelism

Particionar la dimensión de secuencia entre GPUs.

Expert parallelism (Mixture of Experts)

Solo las GPUs con los expertos activos para un token concreto participan.

Frameworks de serving

Choosing batch size

El batch size óptimo depende del caso:

# Configuración típica de vLLM
engine_args = {
    "model": "model_name",
    "tensor_parallel_size": 4,  # 4 GPUs
    "max_num_seqs": 256,        # batch máximo
    "max_model_len": 8192,
    "gpu_memory_utilization": 0.9,
}

Cuantificación de la mejora

El libro insiste en que cada técnica tiene su coste y su beneficio:

TécnicaMejora típicaCuándo aplicar
INT8 quantization2x memory, 1.5x speedDefault para modelos grandes
INT4 quantization4x memory, 2x speedHardware moderno, modelos robustos
Flash Attention2-4x speedHardware Ampere+
PagedAttention2-4x throughputOnline serving
Continuous batching2-10x throughputOnline serving
Speculative decoding2-3x speedTienes un modelo pequeño bueno
KV cache optimization1.5-2x speedContextos largos
Tensor parallelismNx memoriaModelos más grandes que una GPU
Optimiza de fuera hacia adentro

El libro recomienda empezar por las optimizaciones con mejor ratio: continuous batching, Flash Attention, INT8 quantization. Solo después baja a técnicas más quirúrgicas.

Coste por inferencia

El cálculo económico es simple una vez tienes los números:

Coste total = (precio_por_hora_gpu × horas_usadas) /
              (tokens_generados_por_hora)

Ejemplo

Para reducir coste:

Resumen en tres frases

Próximos pasos