LLMs self-hosted en produccion: Ollama vs vLLM vs TGI con criterio

Self-hostear LLMs no es una decision ideologica. Es una decision sobre soberania, latencia, coste y tolerancia al riesgo operativo. Cuando eso ocurre, el problema deja de ser una decision tecnica aislada y pasa a ser un problema de coste, riesgo operativo y capacidad de entrega.

Esta guia aterriza elegir el motor de inferencia que mejor encaja con carga real, control y coste total de operacion con criterios que aguanten produccion, auditoria y crecimiento. El objetivo no es acumular tooling. Es recuperar control y reducir incertidumbre con un sistema que el equipo pueda gobernar sin dependencia innecesaria.

Self-hosting como palanca de ROI, gobernanza y latencia, no como “stack preference”

Las APIs comerciales ganan en una cosa que importa mucho al principio. Reducen time-to-value. Para un MVP o para un producto que todavía no sabe si la funcionalidad va a vivir, delegar infraestructura es una decisión racional. El problema suele aparecer cuando el uso deja de ser exploratorio y empieza a ser una línea estable del P&L.

En producción, el patrón típico es que el coste por token parece marginal hasta que deja de serlo. En el momento en que el volumen sube, el coste se vuelve estructural y además variable, lo cual para finanzas es una combinación difícil. Self-hosting convierte una parte relevante de ese gasto en algo más gobernable. Puedes amortizar GPUs, hacer capacity planning con tus percentiles reales y decidir con precisión qué punto de la curva eliges entre latencia, calidad y coste.

La gobernanza de datos suele ser el segundo motivo y conviene tratarlo con honestidad. No se trata solo de “no sacar PII”. Se trata de demostrarlo con evidencia, auditabilidad y controles. En sectores regulados, casi siempre vuelves a las mismas preguntas. Dónde residen los datos, cuánto tiempo se retienen, quién accede, y cómo lo pruebas. Self-hosting reduce superficie de riesgo con terceros, pero no elimina el riesgo. Lo traslada a tu operación, y si no tienes hardening, segmentación de red, control de accesos y observabilidad, simplemente has cambiado el tipo de incidente que vas a sufrir.

La latencia es el tercer motivo, especialmente en producto interactivo. En cargas de chat, asistentes y flujos que se sienten “en tiempo real”, la variabilidad mata más que la media. Una API externa introduce jitter por red, colas del proveedor y decisiones internas que tú no controlas. Ejecutar el modelo cerca de tu aplicación no garantiza milagros, pero sí te da consistencia. Para un CTO, consistencia significa menos tickets, menos escalados a guardia y menos debugging a ciegas.

Dicho esto, self-hosting también puede salir caro por un motivo que en muchos casos se subestima. El coste de ingeniería. Si tu equipo va a pasar semanas peleándose con drivers, CUDA, fragmentación de VRAM, límites de contexto, kernels y saturación, el supuesto ahorro por token se evapora. La pregunta que suele ordenar la conversación es incómoda pero útil. Qué es más caro en tu empresa, una GPU o una semana de un senior.

Con ese marco, la elección del motor deja de ser una guerra de preferencias y se convierte en ingeniería aplicada a un negocio.

Ollama cuando el cuello de botella es la iteración del producto, no la GPU

Ollama está diseñado para quitar fricción. Esa es su principal virtud y su límite. Si lo que necesitas es tener un modelo corriendo hoy y empezar a integrar con el producto sin abrir una investigación de performance, es difícil de batir.

En entornos reales, la ventaja principal de Ollama no es solo “arrancar en minutos”. Es reducir el coste de equivocarte. En fases tempranas, el cuello de botella rara vez es el throughput. Suele ser la incertidumbre del producto, y por tanto la velocidad con la que tu equipo puede iterar con usuarios, ajustar prompts, probar RAG, fallar rápido y aprender. Un motor que exige tuning avanzado antes de aportar valor te roba lo más caro al principio, que es el ciclo de decisión.

Además, su forma de distribuir modelos tipo “registro” ayuda más de lo que parece. Muchas incidencias en producción vienen de una confusión silenciosa de versiones, cuantizaciones o parámetros. “Juraría que era el modelo X” termina siendo “era el X cuantizado distinto” y tu calidad cambia o tus tiempos se disparan. Tener una forma consistente de fijar versiones reduce esa ambigüedad y mejora gobernanza técnica.

El tradeoff aparece cuando la carga crece. Ollama no compite por throughput extremo. Si tu patrón de tráfico tiene concurrencia alta y variabilidad en longitudes de prompt, vas a tocar techo antes. Y el síntoma que más daño hace al negocio no es solo que la latencia aumente. Es que la latencia se vuelve errática. En un servicio de inferencia, cuando la cola empieza a crecer, p95 y p99 se rompen rápido aunque el promedio “parezca aceptable”. Eso se traduce en una percepción de producto lento, pérdida de adopción y, en escenarios internos, usuarios que vuelven al proceso manual.

En equipos pequeños y cargas moderadas, Ollama suele encajar especialmente bien en estos casos.

• Validación con usuarios reales donde prima el feedback rápido y el coste de operación debe ser mínimo.
• Entornos edge u on-prem con recursos limitados y un alcance controlado.
• Servicios internos con demanda estable donde la simplicidad operativa gana a la eficiencia por GPU.

El error común es usarlo “porque es fácil” en un servicio que puede crecer hacia público externo o hacia un volumen interno grande. La migración entonces ocurre durante un incidente de latencia, que es el peor momento para cambiar el core de inferencia. Si sospechas que el producto va a escalar, la decisión inteligente no es evitar Ollama. Es diseñar la integración para poder cambiar de backend sin reescribir medio sistema. Volveremos a esto en la sección de migración.

Cuando el producto valida y el problema ya no es iterar, sino servir volumen con coste controlado, entras en terreno vLLM.

vLLM cuando necesitas tokens por dólar y estabilidad en p95 bajo concurrencia real

vLLM parte de una premisa que en producción se vuelve obvia muy rápido. El coste real no es cuántas GPUs tienes, sino cuántos tokens útiles sirves por dólar y por minuto sin romper SLOs. Si tu uso crece, la eficiencia deja de ser “nice to have” y se convierte en una palanca directa de ROI.

La razón técnica por la que vLLM destaca suele resumirse con PagedAttention. En la práctica, lo que te compra es una gestión más eficiente de memoria para la KV cache cuando tienes múltiples requests concurrentes con longitudes variables. Esto importa especialmente en chat y en workloads donde los prompts crecen, porque el crecimiento de estados y la fragmentación de VRAM se convierten en el factor limitante antes de que “falte cómputo” como tal. En producción hemos visto sistemas donde el salto de “sirvo 30 concurrentes” a “sirvo 150 concurrentes” no vino de comprar más GPUs, sino de usar mejor la VRAM y reducir el desperdicio.

Lo que la documentación rara vez te dice con suficiente énfasis es que vLLM no es un servidor HTTP genérico. Es un scheduler de GPU. Tratarlo como un “deploy y listo” suele llevar a decepción. Los defaults pueden ser correctos, pero no necesariamente óptimos para tu distribución de inputs y outputs, tus límites de contexto, tu patrón de streaming y tu tolerancia al tail latency.

Un patrón que funciona bien es abordarlo como un ejercicio de performance engineering desde el día uno. Eso significa medir tu carga real, no la que imaginas. Significa capturar percentiles de tokens de entrada y salida, y observar cómo cambia p95 cuando la concurrencia sube. Y significa aceptar que en vLLM vas a invertir en tuning, porque el retorno es precisamente servir más con menos.

El riesgo operativo principal de vLLM es su ritmo de evolución. Es una fortaleza y un coste. He visto cambios menores entre versiones alterar p95 bajo carga por ajustes de scheduling o de memoria. Si actualizas sin un harness de benchmarks y pruebas de regresión, acabas encontrando regresiones en producción. Si tu organización prioriza estabilidad por encima de todo y no quiere asumir churn, esto pesa.

vLLM suele ser la elección adecuada cuando tu caso cumple al menos dos de estas condiciones.

• Tienes concurrencia real y el throughput es un cuello de botella medible.
• El coste de GPU es relevante y quieres maximizar tokens por GPU.
• Estás dispuesto a operar con rigor, que incluye tests de rendimiento, control de versiones y tuning continuo.

Cuando quieres un baseline robusto con buena operación por defecto y menos necesidad de “doctorado en tuning” para llegar a un estado estable, TGI suele encajar mejor.

TGI como punto medio con defaults sólidos y operación predecible en entornos enterprise

TGI suele ser el sweet spot para organizaciones que quieren rendimiento competitivo sin convertir la inferencia en un proyecto de optimización permanente. No es tan plug-and-play como Ollama y no busca la optimización extrema como vLLM, pero viene con algo que en producción vale dinero. Defaults razonables y un encaje natural con Hugging Face.

Si tu stack ya usa Transformers, tokenizers del Hub o flujos de ML alrededor de Hugging Face, TGI reduce integraciones ad hoc. Eso no es comodidad. Es reducción de riesgo. Menos glue code significa menos superficie que nadie quiere mantener en seis meses. También significa menos divergencia entre cómo entrenas o evalúas y cómo sirves en producción.

Operativamente, TGI suele darte un primer despliegue “suficientemente bueno” sin una sesión larga de tuning. Implementa batching dinámico y optimizaciones comunes de manera que puedes llegar rápido a un baseline estable, instrumentar y luego decidir si compensa exprimir más. Para un CTO, esto es un patrón sano de ROI. Primero estabilizas y haces gobernanza de métricas, luego optimizas cuando hay demanda y evidencia.

Hay otro punto menos glamuroso que importa mucho. Cómo se degrada el sistema bajo carga variable. En producción, los incidentes raramente vienen del promedio. Vienen de degradación progresiva, consumo de memoria impredecible y condiciones borde que aparecen en p99. La implementación de TGI con componentes en Rust tiende a ser más predecible en consumo y estabilidad. No significa ausencia de incidencias, significa menos sorpresas de runtime en escenarios típicos de producción.

Y si tu organización requiere soporte comercial como mitigación de riesgo, TGI tiene una ventaja práctica. Hay una ruta natural hacia soporte enterprise dentro del ecosistema. Para ciertas compañías, poder escalar un problema crítico con responsables del proyecto vale más que un 10 por ciento extra de throughput.

Con las tres opciones claras, la pregunta útil ya no es “cuál es mejor”. Es “qué criterios evitan errores caros en mi contexto”.

La decisión correcta suele salir de tu distribución de tokens, no de un benchmark

El error que veo más a menudo es elegir motor como si todos los sistemas fueran de alto tráfico. La mayoría no lo son, o no lo son todavía. Sobredimensionar significa más complejidad, más puntos de fallo y más tiempo de equipo. Subdimensionar significa latencia y pérdida de adopción, que en la práctica es pérdida de ROI incluso si técnicamente “funciona”.

La forma más fiable de decidir es caracterizar la carga con datos y no con suposiciones. No necesitas un laboratorio perfecto. Necesitas responder con honestidad a preguntas concretas. Cuál es la distribución real de longitud de prompt, cuál es la longitud de salida esperada, cuántas requests concurrentes tienes en p95 y p99, y qué latencia p95 es aceptable para que el producto se sienta bien.

En producción, hay errores que se repiten porque son contraintuitivos. El promedio engaña. La variabilidad de longitudes de secuencia te rompe la VRAM antes de lo que esperas. Y si no mides tokens por segundo por GPU, acabas comprando capacidad a ciegas.

Si tuviera que quedarme con una única lista en esta sección, sería una instrumentación mínima que debería existir desde el día uno, independientemente del motor.

• p50, p95 y p99 de latencia end-to-end, y time-to-first-token si usas streaming
• tokens por segundo por GPU y por instancia, y cómo cae esa métrica bajo carga
• utilización de VRAM, eventos de OOM y correlación con longitudes de secuencia
• distribución de tokens de entrada y salida por percentiles, porque determina tuning y capacity planning

Esto conecta directamente con negocio. Sin estas métricas, tu planificación de capacidad es opinión, y la conversación con finanzas se vuelve fricción. Con estas métricas, puedes justificar inversión en GPUs, decidir si merece la pena optimizar, y estimar el ROI de una migración con evidencia.

Con datos en mano, el mapa suele quedar así. Ollama gana cuando priorizas simplicidad y velocidad de adopción con tráfico moderado. vLLM gana cuando el throughput o la eficiencia por GPU son un cuello de botella real y puedes invertir en performance engineering. TGI gana cuando quieres un baseline robusto, operación predecible e integración natural con HF, especialmente en organizaciones donde la estabilidad pesa más que el último porcentaje de throughput.

En multi-GPU, el criterio cambia. Si el modelo no cabe en una sola GPU o necesitas paralelizar por latencia, la madurez del soporte multi-GPU deja de ser un nice to have. En ese escenario, vLLM y TGI suelen ser elecciones más naturales, mientras que Ollama raramente es la primera opción si el paralelismo es un requisito desde el inicio.

Lo cual nos lleva al punto que diferencia a equipos que escalan de equipos que se quedan atrapados. Diseñar para migrar desde el principio.

Migrar sin trauma requiere desacoplar la app del motor y estandarizar comportamientos

La decisión inicial no debería ser irreversible. Lo que separa a equipos maduros es la disciplina de arquitectura para mantener soberanía. Tu aplicación no debería depender de un motor específico, debería depender de una interfaz estable.

Un patrón que funciona bien es imponer una API interna estable compatible con OpenAI, o una abstracción mínima propia si tienes necesidades específicas, y tratar el motor como un backend intercambiable. Esto reduce el coste de cambiar de motor cuando los datos lo justifican, en lugar de hacerlo bajo presión durante un incidente.

En producción, el coste real de migrar casi nunca está en cambiar el endpoint. Está en las diferencias de comportamiento que se filtran si no has estandarizado lo esencial. El streaming se comporta distinto, los timeouts se calibran distinto, los límites de contexto no siempre son equivalentes, el tool calling puede variar, y los detalles de sampling pueden cambiar la distribución de resultados. Si tu lógica de producto se acopla a esas particularidades, la migración deja de ser una tarea y se convierte en un proyecto.

Si haces bien el desacoplamiento, migrar de Ollama a TGI o a vLLM puede ser cuestión de horas o pocos días. Si lo haces mal, se convierte en semanas de fricción y riesgo, justo cuando el negocio ya depende de la capacidad de servir esa inferencia.

Y aquí hay una verdad operativa que conviene decir sin rodeos. Sin observabilidad de inferencia, no existe tuning serio. Y sin tuning serio, cualquier discusión de coste por token o SLOs es aspiracional. Lo que no mides, lo pagas en incidentes o en GPUs.

El motor correcto es el que minimiza tu coste total, no el que gana en un gráfico

No existe un motor universalmente superior. Existen motores alineados con tradeoffs distintos, y esos tradeoffs se convierten en coste o en ventaja según tu fase y tu carga.

Ollama es una elección fuerte cuando necesitas simplicidad y velocidad de puesta en marcha con una operación mínima. vLLM es una elección fuerte cuando el throughput y la eficiencia por GPU son un cuello de botella real y estás dispuesto a invertir en ingeniería de performance con rigor. TGI suele ser el equilibrio pragmático cuando buscas rendimiento competitivo, operación predecible e integración natural con Hugging Face, con un perfil de riesgo más enterprise.

La recomendación operativa que suele maximizar ROI y minimizar riesgo es bastante consistente. Empieza con el motor que minimiza complejidad para tu fase actual, instrumenta desde el primer día como si fueses a escalar, y migra cuando los datos lo justifiquen. Esa combinación te da soberanía sin comprarte una deuda operativa innecesaria.

Una matriz de decision rapida evita elegir motor por simpatia tecnica

Cuando la conversacion se alarga demasiado, suele ser porque el equipo esta comparando motores fuera de contexto. La pregunta util no es cual gana en abstracto. Es cual reduce el coste total en la fase actual del producto.

La tabla no sustituye medicion real, pero evita un error frecuente. Empezar con una pila compleja porque el benchmark parecia brillante o quedarse corto porque el primer prototipo iba bien. Si tu distribucion de carga todavia es incierta, simplifica y protege la opcion de migrar. Si ya sabes que el cuello de botella es throughput o coste por token, entonces deja de optimizar por comodidad y pasa a optimizar por operacion.

Lecturas relacionadas que amplian esta decision

• AWS vs GCP vs Azure para IA/ML en 2026: como decidir sin deuda operativa
• GPT-5.1 en empresa: razonamiento adaptativo, herramientas y gobernanza
• Gemini 3.0 en empresa: multimodalidad, contexto largo y control operativo
• MLOps en produccion: del prototipo a un sistema gobernable
• Embeddings multimodales: guia practica para busqueda y recuperacion
• Nuestro servicio de IA y MLOps

Cuando merece actuar

Si esta carga de IA ya esta afectando latencia, coste por inferencia o control de respuesta, conviene auditar el flujo completo antes de escalar uso o cambiar de modelo.