Phase 17 - Lesson 28

Selección de Motor de Servicio Local (Self-Hosted) — llama.cpp, Ollama, TGI, vLLM, SGLang

Cuatro motores dominan la inferencia local (self-hosted) en 2026. Elige según tu hardware, escala y ecosistema. llama.cpp es el más rápido en CPU: soporte de modelos más amplio, control total sobre cuantización e hilos. Ollama es la instalación en un solo comando para computadoras portátiles de desarrollo, ~15-30% más lento que llama.cpp (Go + CGo + serialización HTTP), con una brecha de 3x en rendimiento (throughput) bajo cargas similares a producción. TGI entró en modo de mantenimiento el 11 de diciembre de 2025: solo correcciones de errores, ~10% más lento en rendimiento bruto que vLLM, pero históricamente líder en observabilidad e integración con el ecosistema HF. Ese estado de mantenimiento lo convierte en una apuesta riesgosa a largo plazo; SGLang o vLLM son alternativas más seguras para proyectos nuevos. vLLM es la opción predeterminada para producción de uso general: v0.15.1 (febrero de 2026) agrega PyTorch 2.10, compatibilidad con RTX Blackwell SM120 y optimización para H200. SGLang es el especialista para múltiples turnos de agentes y cargas intensivas en prefijos (prefix-heavy): más de 400,000 GPUs en producción (xAI, LinkedIn, Cursor, Oracle, GCP, Azure, AWS). Restricciones de hardware: solo CPU → solo llama.cpp. AMD / no-NVIDIA → solo vLLM (TRT-LLM está bloqueado para NVIDIA). Patrón de flujo de trabajo de 2026: dev = Ollama, staging = llama.cpp, prod = vLLM o SGLang. Mismos pesos GGUF/HF en todo el proceso.

Tipo: Learn Lenguajes: Python (stdlib, interpretador de árbol de decisión de motores) Prerrequisitos: Todas las lecciones de la Fase 17 que cubren motores (04, 06, 07, 09, 18) Tiempo: ~45 minutos

Objetivos de Aprendizaje

• Elegir un motor según el hardware (CPU / AMD / NVIDIA Hopper / Blackwell), la escala (1 usuario / 100 / 10,000) y la carga de trabajo (chat general / agente / contexto largo).
• Señalar el estado de modo de mantenimiento de TGI en 2026 (11 de diciembre de 2025) y por qué sesga los nuevos proyectos hacia vLLM o SGLang.
• Describir el flujo de trabajo dev/staging/prod usando los mismos pesos GGUF o HF en todo el proceso.
• Explicar por qué "solo CPU" obliga a usar llama.cpp y "AMD" excluye a TRT-LLM.

El Problema

Tu equipo inicia un nuevo proyecto de LLM local. Un ingeniero sugiere Ollama, otro sugiere vLLM y un tercero pregunta "¿no funciona TGI directamente desde la caja?". Los tres tienen razón en diferentes contextos. Ninguno tiene razón para todos.

En 2026, el árbol de decisión importa: hardware primero, escala segundo, carga de trabajo tercero. And un evento específico de 2025 —TGI entrando en modo de mantenimiento el 11 de diciembre— cambia el motor predeterminado para nuevos proyectos.

El Concepto

Los cinco motores

Decisión basada en hardware

Solo CPU → llama.cpp. Ollama también funciona pero es más lento. Ningún otro motor es competitivo en CPU.

GPU AMD → vLLM (soporte para AMD ROCm). SGLang también funciona. TRT-LLM está bloqueado para NVIDIA, por lo que queda fuera.

NVIDIA Hopper (H100 / H200) → vLLM, SGLang o TRT-LLM. Los tres son de primer nivel.

NVIDIA Blackwell (B200 / GB200) → TRT-LLM es el líder de rendimiento (Fase 17 · 07). vLLM y SGLang lo siguen de cerca.

Apple Silicon (serie M) → llama.cpp (Metal). Ollama envuelve esto.

Decisión basada en escala

1 usuario / desarrollo local → Ollama. Un solo comando, primer token en segundos.

10-100 usuarios / equipo pequeño → vLLM con una sola GPU.

100-10k usuarios / producción → pila de producción de vLLM (Fase 17 · 18) o SGLang.

Más de 10k usuarios / corporativo → pila de producción de vLLM + descompuesta (Fase 17 · 17) + LMCache (Fase 17 · 18).

Decisión basada en carga de trabajo

Chat general / Preguntas y respuestas → vLLM gana por ser el predeterminado general.

Varios turnos de agentes (herramientas, planificación, memoria) → RadixAttention de SGLang (Fase 17 · 06) domina.

RAG con alto reúso de prefijos → SGLang.

Generación de código → vLLM funciona bien; SGLang es ligeramente mejor en caché.

Contexto largo (128K+) → vLLM + precompletado en bloques (chunked prefill); SGLang + KV escalonado (tiered KV).

La trampa del mantenimiento de TGI

TGI de Hugging Face entró en modo de mantenimiento el 11 de diciembre de 2025; de aquí en adelante solo recibirá correcciones de errores. Históricamente: observabilidad de primer nivel, la mejor integración de su clase con el ecosistema de HF (model cards, herramientas de seguridad) y rendimiento bruto ligeramente por detrás de vLLM.

Para proyectos nuevos en 2026: evita elegir TGI de forma predeterminada. Las implementaciones existentes de TGI pueden continuar pero deberían migrar eventualmente. SGLang y vLLM son las opciones predeterminadas más seguras.

El patrón de flujo de trabajo

Dev (Ollama) → staging (llama.cpp) → prod (vLLM). Mismos pesos GGUF o HF en todo el proceso. Los ingenieros iteran rápidamente en laptops; staging refleja la cuantización de producción; prod es el objetivo de servicio.

Advertencia sobre Ollama

Ollama es excelente para desarrollo. No es adecuado para producción compartida: la serialización HTTP de Go agrega overhead, la gestión de concurrencia es más simple que en vLLM y el soporte de OpenTelemetry se queda atrás. Usa Ollama donde se destaca —un usuario, un comando— y cambia a vLLM para entornos compartidos.

Local vs administrado es una decisión aparte

La Fase 17 · 01 (hiperescaladores administrados) y la Fase 17 · 02 (plataformas de inferencia) cubren el servicio administrado. Esta lección asume que ya has decidido alojar localmente. Razones para el alojamiento local: soberanía/residencia de datos, ajuste fino personalizado, costo total de propiedad a escala, o un modelo de dominio no disponible en servicios alojados.

Números que debes recordar

• Modo de mantenimiento de TGI: 11 de diciembre de 2025.
• vLLM v0.15.1: febrero de 2026; PyTorch 2.10; soporte para Blackwell SM120.
• Huella en producción de SGLang: más de 400,000 GPUs.
• Brecha de rendimiento de Ollama vs llama.cpp: 15-30% más lento; 3x bajo carga de prod.

Use It

El archivo code/main.py recorre un árbol de decisión: dados el hardware, la escala y la carga de trabajo, elige un motor y explica por qué.

Ship It

Esta lección produce outputs/skill-engine-picker.md. Dadas las restricciones, elige un motor y diseña el plan de migración.

Ejercicios

1. Ejecuta code/main.py con tu hardware / escala / carga de trabajo. ¿Coincide el resultado con tu intuición?
2. Tu infraestructura cuenta con 12 H100s y 8 MI300X AMD. ¿Qué motor elegirías? ¿Por qué TRT-LLM no es una opción?
3. Un equipo quiere usar TGI en 2026 porque "es lo que conocemos". Argumenta el caso de la migración.
4. Dev con Ollama a prod con vLLM: ¿qué cambia en la cuantización, configuración y observabilidad?
5. Producto RAG con longitud de prefijo P99 de 8K y alto reúso entre inquilinos. Elige un motor y combínalo con la Fase 17 · 11 + 18.

Términos Clave

Lecturas Recomendadas