TGI de Hugging Face: servir modelos abiertos a escala

Actualizado: 2026-05-03

Servir un LLM abierto en producción no es trivial: mantener la GPU saturada, agrupar peticiones sin bloquear, aplicar cuantización sin perder calidad y exponer una API compatible con OpenAI implica resolver varios problemas a la vez. Text Generation Inference (TGI)^[1] de Hugging Face intenta resolverlos con una pila coherente. Es una de las opciones más maduras del ecosistema abierto, aunque con un cambio de licencia que merece atención.

Puntos clave

• TGI soporta continuous batching, FlashAttention v2, tensor parallelism y cuantización (bitsandbytes, GPTQ, AWQ) con mínima configuración.
• Para modelos del Hugging Face Hub, TGI es el camino de menor fricción — carga por ID, no conversión de formato.
• TGI 2.0+ cambió a licencia comercial restrictiva para uso productivo: evalúa los términos antes de adoptar.
• Para throughput puro en GPUs potentes, vLLM suele ganar. Para CPU o Apple Silicon, llama.cpp es mejor.
• La API compatible con OpenAI (/v1/chat/completions) permite transiciones entre modelos hosted y self-hosted sin cambios de código.

Qué es TGI

TGI es un servidor de inferencia especializado en generación de texto. Escrito principalmente en Rust (el router) y Python (el worker con PyTorch). Soporta los modelos más populares del hub: Llama 2, Mistral, Falcon, StarCoder, BLOOM, CodeLlama, Yi, MPT, Phi y variantes.

Las capacidades clave:

• Continuous batching: agrupa peticiones concurrentes sin esperar a que la más lenta termine. Maximiza utilización de GPU.
• FlashAttention v2: implementación optimizada de atención que reduce memoria y acelera el cómputo.
• PagedAttention: gestión de memoria KV-cache inspirada en vLLM (aunque vLLM lo implementa mejor).
• Tensor parallelism: partir el modelo entre varias GPUs.
• Cuantización: bitsandbytes (NF4, FP4, INT8), GPTQ, AWQ, EETQ. Inferencia 4-bit u 8-bit sin mayor trabajo.
• Streaming SSE: tokens al cliente en cuanto se generan.
• Guided generation: gramáticas, regex, JSON schema via Outlines.
• API compatible con OpenAI: /v1/chat/completions como capa adicional.

Despliegue mínimo

docker run --gpus all --shm-size 1g -p 8080:80 
  -v $PWD/data:/data 
  ghcr.io/huggingface/text-generation-inference:latest 
  --model-id mistralai/Mistral-7B-Instruct-v0.2 
  --quantize bitsandbytes-nf4

Tras unos minutos cargando, el endpoint responde en POST /generate con tokens en streaming. En Kubernetes, el chart oficial cubre despliegues con GPU operator; los pods necesitan nvidia.com/gpu: 1 (o más para tensor parallelism).

Donde TGI brilla

TGI es la opción correcta para:

• Modelos del Hugging Face Hub directos: carga por ID, sin conversión de formato.
• Modelos cuantizados con bitsandbytes: soporte nativo de NF4, FP4, INT8.
• Streaming SSE de alta calidad: first-token-latency baja, throughput estable.
• Hugging Face Inference Endpoints: TGI es el motor detrás de su servicio gestionado.
• Integración con Transformers: misma familia de herramientas, compatibilidades probadas.

Si ya estás en el ecosistema HF, TGI es el camino de menor fricción.

Donde otros lo superan

• Throughput puro: vLLM^[2] exprime más tokens/segundo en GPUs potentes gracias a su PagedAttention bien implementada, y es Apache 2.0.
• CPU o Apple Silicon: llama.cpp^[3] / Ollama^[4] son mejores para inferencia sin GPU.
• Modelos esotéricos: TGI cubre los populares; modelos menos comunes o muy nuevos pueden no estar soportados.
• Licencia: TGI 2.0+ cambió a una licencia comercial restrictiva para uso productivo. Empresas que asumían código Apache están reevaluando — algunas han migrado a vLLM por ello.

Optimizaciones con gran impacto

Tres ajustes pequeños con gran efecto:

• --max-batch-prefill-tokens: límite total de tokens en fase prefill (la más costosa). Más alto equivale a más concurrencia pero más VRAM.
• --max-total-tokens: ventana máxima por petición. Ajustar al mínimo necesario ahorra memoria.
• --quantize gptq o --quantize awq: mejor que bitsandbytes si tienes un modelo pre-cuantizado.

Mide throughput antes y después con locust^[5] o vegeta^[6] para validar el impacto real.

API compatible con OpenAI

curl http://localhost:8080/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{
    "model": "tgi",
    "messages": [{"role": "user", "content": "Hola"}],
    "stream": true
  }'

Esto permite usar LangChain^[7], LiteLLM^[8] y SDKs de OpenAI sin cambios de código. La transición entre un modelo hosted y self-hosted pasa de semanas a minutos.

Operación en producción

Checklist para operar TGI en serio:

• Health checks apuntando a /health.
• Métricas Prometheus en /metrics — expone latencia, throughput y uso de VRAM.
• Limitar concurrencia a nivel router para evitar OOM en picos.
• Backup del modelo descargado: si el hub está inaccesible no puedes arrancar.
• Monitoreo de temperatura GPU — GPUs a 90°C degradan y fallan.
• Plan para updates de CUDA/driver — TGI es sensible a versiones.

Alternativas a tener en cuenta

• vLLM^[2]: mejor throughput general, comunidad muy activa, Apache 2.0.
• llama.cpp^[3] / Ollama^[4]: CPU y Apple Silicon, despliegue más simple.
• TensorRT-LLM^[9]: el techo de rendimiento en GPUs NVIDIA, pero con alta complejidad operativa.
• LMDeploy^[10]: rendimiento muy bueno en ciertos modelos.

Conclusión

TGI sigue siendo una elección robusta y sensata para la mayoría de equipos que sirven modelos abiertos: soporte de modelos populares del hub, cuantización fácil, API familiar e integración con el ecosistema HF. El cambio de licencia en 2.0 es lo más importante a evaluar antes de adoptar en contextos comerciales. Para throughput absoluto en GPUs top, vLLM suele ganar; para máxima simplicidad en CPU, llama.cpp. Si no tienes restricciones de licencia y estás en el ecosistema HF, TGI sigue siendo la opción de menor fricción.

1. Text Generation Inference (TGI)
2. vLLM
3. llama.cpp
4. Ollama
5. locust
6. vegeta
7. LangChain
8. LiteLLM
9. TensorRT-LLM
10. LMDeploy