Runtimes open source para inferencia de LLM en 2026

# Runtimes open source para inferencia de LLM en 2026: llama.cpp vs Ollama vs vLLM vs SGLang

Respuesta directa

Elige llama.cpp para controlar modelos GGUF y hardware CPU/GPU mixto, Ollama para la experiencia local más sencilla, MLX-LM para experimentar en Apple silicon, MLC LLM para navegador o móvil, y vLLM o SGLang para servir muchas peticiones en GPU. TensorRT-LLM encaja en optimización NVIDIA. Reserva TGI para instalaciones existentes porque su repositorio está en mantenimiento.

La comparación útil no es una sola tabla de benchmarks

Quien busca «llama.cpp vs Ollama vs vLLM» suele querer un ganador rápido. Los resultados actuales tienden a responder con una tabla de funciones, matriz de hardware, comparación de formatos y árbol de decisión. La estructura ayuda, pero una clasificación única por velocidad induce a error. Los proyectos ocupan capas distintas y su rendimiento cambia con arquitectura, cuantización, longitud de prompt, lote, concurrencia, acelerador, ancho de banda de memoria y forma de cada petición.

La primera pregunta no es «¿qué runtime da más tokens por segundo?», sino «¿qué trabajo debe realizar el sistema?». Un asistente privado en un portátil, una API para veinte usuarios, una función en iPhone y una plataforma de agentes con varias GPU son sistemas distintos. Incluso con los mismos pesos, el resultado cambia porque cada motor administra memoria, caché y colas de otra manera.

Esta guía compara la documentación oficial revisada el 3 de octubre de 2026. No replica benchmarks promocionales ni supone que una prueba hecha en una máquina se traslada a otra. Relaciona cada stack con el trabajo que pretende resolver y propone una validación repetible antes de elegir.

Tabla de decisión rápida

No existe un ganador universal. La preselección debe salir de la forma del despliegue y terminar con el modelo y prompts reales.

Separa motor, gestor de modelos y plataforma de servicio

Muchas comparativas colocan todos los proyectos en la misma columna como sustitutos directos. No lo son.

Un motor de inferencia carga pesos, asigna memoria, evalúa tokens y ejecuta kernels. Un gestor de modelos añade descarga, nombres, configuración y ciclo de vida. Una plataforma de servicio incorpora colas, batching, routing, métricas, ejecución distribuida y un contrato de API. Algunos proyectos abarcan varias capas, pero conservan un centro de gravedad.

llama.cpp nació como motor C/C++ compacto y ahora también incluye `llama-server`, compatible con OpenAI y con batching continuo, decodificación paralela, embeddings, reranking, JSON restringido, herramientas y métricas. Ollama ofrece una experiencia superior para obtener y ejecutar modelos mediante CLI y REST. vLLM y SGLang se diseñan alrededor de muchas peticiones. MLC LLM considera prioritaria la portabilidad a navegador y móvil.

Por eso «Ollama frente a llama.cpp» es en parte una decisión de experiencia, mientras que «vLLM frente a SGLang» suele ser una decisión de scheduler, caché y operación en producción.

llama.cpp: control local sobre hardware variado

llama.cpp es un punto de partida flexible cuando ya tienes pesos GGUF, memoria limitada o hardware que no es de centro de datos. El repositorio oficial enumera ejecución en CPU y backends CUDA, HIP, Metal, Vulkan, SYCL y otros, además de inferencia híbrida CPU/GPU cuando el modelo no cabe en el acelerador. La cuantización entera es central y permite equilibrar tamaño, calidad, RAM y VRAM.

Úsalo si necesitas controlar contexto, capas descargadas en GPU, cuantización, lotes y caché. También es una base razonable de portabilidad: un mismo GGUF puede moverse entre workstation, Apple silicon, AMD y NVIDIA, aunque las mejores opciones y el rendimiento cambien.

Ya no es solo un generador de terminal. `llama-server` ofrece rutas compatibles con OpenAI para chat, responses y embeddings, y admite usuarios concurrentes. Sin embargo, autenticación, TLS, routing entre instancias, escalado y monitorización completa siguen siendo responsabilidad del operador. Su ventaja es el control transparente, no una plataforma gestionada.

Encaja en asistentes de una persona, lotes sin conexión, funciones de escritorio y pruebas cuidadosas en hardware heterogéneo. Para más opciones, consulta el directorio de herramientas locales gratuitas.

Ollama: la ruta corta hacia una API local

Ollama suele ser la respuesta más fácil cuando el requisito es «instalar un modelo y llamarlo desde una aplicación». Su proyecto admite macOS, Windows y Linux, dispone de Docker y expone una API REST para ejecutar y gestionar modelos. La documentación de compatibilidad con OpenAI cubre formas conocidas por clientes existentes.

La ventaja principal no es que Ollama siempre genere más rápido que llama.cpp. Es que obtención, manifiestos, almacenamiento, proceso y API llegan como producto coherente. Eso ahorra trabajo en prototipos, enseñanza, chat privado y herramientas de desarrollo.

Elige Ollama si la sencillez importa más que ajustar cada parámetro. Elige llama.cpp directamente si necesitas una compilación concreta, una opción experimental, un reparto de memoria singular o un componente mínimo integrado en otro producto. Como ambos evolucionan, verifica la versión exacta: no supongas que cada función nueva de llama.cpp aparece de inmediato en Ollama.

MLX-LM: la vía enfocada a Apple silicon

MLX-LM es un paquete Python para generar y ajustar modelos en Apple silicon con MLX. Su README documenta integración con Hugging Face, cuantización, conversión, ajuste LoRA y completo, inferencia distribuida y APIs de terminal y Python. Es atractivo para quien quiere un flujo nativo de investigación en Mac antes que un servidor multiplataforma.

Úsalo para experimentación, evaluación local, conversión y fine-tuning en Apple. Puede servir aplicaciones, pero su ventaja definitoria es la alineación con el stack de Apple silicon. Si el mismo runtime debe llegar a Linux, Windows, AMD y NVIDIA, llama.cpp u otra capa portable suele ser una base más directa.

El formato importa. Los pesos compatibles con MLX y GGUF pertenecen a ecosistemas distintos. Antes de elegir, confirma arquitectura, tokenizer, cuantización y plantilla de chat exactos.

MLC LLM: navegador, móvil y edge heterogéneo

MLC LLM destaca porque apunta a WebGPU y WebAssembly en navegador, además de iOS, Android y backends GPU nativos. El proyecto describe un `MLCEngine` común con APIs compatibles con OpenAI en REST, Python, JavaScript y entornos móviles.

Es una opción sólida si la inferencia local es una función que se entrega en dispositivos de usuarios, no un servidor de la red local. Una demo web, un asistente móvil privado o una aplicación de campo offline tienen restricciones para las que vLLM no fue diseñado.

El coste es la complejidad de compilación y distribución. Web y móvil exigen planificar tamaño de descarga, memoria y compatibilidad por dispositivo. Que una plataforma esté soportada no demuestra que el modelo deseado quepa o funcione bien en todos sus equipos.

vLLM: servicio GPU orientado a caudal

vLLM es un candidato predeterminado fuerte para un servicio compatible con OpenAI y tráfico GPU concurrente. El proyecto oficial destaca PagedAttention, batching continuo, prefill fragmentado, caché de prefijo, decodificación especulativa, paralelismo distribuido, streaming y varios métodos de cuantización. El servidor ofrece chat, completions, responses, embeddings y otras rutas.

La idea clave es la utilización. Una persona envía una petición y espera. Un servicio recibe solicitudes con prompts y salidas de tamaños distintos al mismo tiempo. El batching continuo y la gestión paginada de la caché KV buscan mantener ocupado el acelerador y controlar la fragmentación de memoria.

Elige vLLM si dispones de hardware compatible, múltiples usuarios o trabajos y necesitas una API familiar. Mide caudal y latencia: maximizar tokens agregados puede empeorar la cola larga, y una configuración excelente para prompts cortos puede sufrir con prefill extenso. Además, protégelo tras un proxy inverso; su documentación advierte que la clave de API integrada no cubre todos los endpoints.

Si quieres evaluar capacidad antes de comprar hardware, revisa la guía de créditos GPU gratuitos y la de API de IA gratuitas, siempre sujeto a condiciones vigentes.

SGLang: agentes y servicio estructurado a escala

SGLang se define como framework de inferencia optimizado para agentes, rollouts de aprendizaje por refuerzo y servicio a gran escala. Su matriz actual incluye GPU NVIDIA y AMD, TPU de Google, hardware Intel, Apple silicon y más aceleradores. El ecosistema añade routing, integraciones de caché y componentes de servicio.

Debe estar en la lista cuando la carga reutiliza prefijos, produce salidas estructuradas, llama herramientas o ramifica peticiones de agentes. Esos patrones pueden beneficiarse de planificación y caché más allá de un servidor básico. También encaja si un equipo busca un framework rápido para investigación y producción.

Esa amplitud tiene coste operativo. Las funciones soportadas varían por modelo y backend, y el ritmo de cambios exige regresiones al actualizar. Compara SGLang con vLLM usando la misma revisión, precisión, distribución de peticiones y concurrencia. Un benchmark externo con otras opciones no decide una compra.

TensorRT-LLM: especialización NVIDIA

TensorRT-LLM es el toolkit de NVIDIA para optimizar y desplegar inferencia en sus GPU. Combina definición de modelos en Python con kernels especializados, cuantización, runtime y ejecución distribuida.

Merece una prueba si el despliegue está comprometido con NVIDIA y el equipo puede asumir la construcción y el ajuste de motores. La especialización puede habilitar optimizaciones que un stack portable no ofrece. Es menos atractiva como primer prototipo o cuando cambiar de proveedor de hardware es obligatorio.

No presupongas que el runtime más especializado siempre gana. Compatibilidad, conversión, longitud de secuencia y tráfico determinan el retorno. Mide la latencia completa y el esfuerzo operativo, no solo kernels.

TGI: válido para lo instalado, no como opción automática nueva

Hugging Face Text Generation Inference ayudó a consolidar batching continuo, paralelismo tensorial, streaming, cuantización, métricas y trazas. Su repositorio indica ahora que TGI está en mantenimiento y recomienda vLLM y SGLang para nuevos despliegues, además de llama.cpp o MLX para uso local.

Eso no obliga a retirar una instalación sana. Las integraciones existentes y procedimientos conocidos tienen valor. Sí implica que un proyecto nuevo debe considerar el menor desarrollo de funciones y comparar una migración antes de profundizar su dependencia.

TensorSharp: candidato .NET con divulgación

La oportunidad que originó esta guía fue enviada por el mantenedor de TensorSharp, quien declaró su relación. El repositorio presenta un motor y runtime de agentes .NET nativo para GGUF, con CPU y aceleradores, interfaz web y APIs compatibles con Ollama y OpenAI. También publica comparativas con llama.cpp.

Son pruebas del propio proyecto, no demostración independiente de superioridad. TensorSharp puede interesar a equipos que necesitan integración .NET gestionada o su runtime de agentes, pero deben repetir resultados con idéntico archivo, contexto, prompts, calentamiento, hilos y hardware. Un ecosistema menor también exige revisar cadencia, incidencias, modelos y actualizaciones.

La conclusión correcta es incluirlo, no recomendarlo sin condiciones: resuelve un problema real de integración .NET, pero rendimiento y compatibilidad deben validarse localmente.

Formato y compatibilidad pueden decidir antes que la velocidad

El nombre de un modelo no basta. El runtime debe implementar exactamente arquitectura, tokenizer, plantilla, cuantización y proyector multimodal del artefacto.

llama.cpp y TensorSharp se centran en GGUF. MLX-LM usa pesos compatibles con MLX. vLLM y SGLang suelen consumir repositorios tipo Hugging Face. TensorRT-LLM puede requerir construir un motor y MLC compila para el destino. Convertir es posible a menudo, pero añade tiempo, almacenamiento y otro artefacto que verificar.

Antes del benchmark confirma:

1. La revisión exacta, no solo la familia, está soportada.
2. La cuantización funciona en el backend final.
3. La plantilla produce los tokens de control correctos.
4. Herramientas, JSON, embeddings o multimodal funcionan si son requisitos.
5. Contexto y caché KV caben con concurrencia realista.
6. La licencia permite el uso previsto del modelo y el producto.

Ruta de selección por carga

Una persona y un portátil

Empieza por Ollama si valoras comodidad. Usa llama.cpp si tienes GGUF o quieres ajustar memoria y offload. En Apple silicon, añade MLX-LM si importan Python o fine-tuning.

Una API local para un equipo pequeño

Ollama o `llama-server` pueden bastar con poca concurrencia. Añade autenticación y límites de red: software «local» expuesto en una red compartida sigue siendo un servicio. Mide espera, primer token y caché con varios usuarios.

Un servicio GPU interno o público

Prueba primero vLLM y SGLang. Incorpora TensorRT-LLM si la flota es solo NVIDIA y compensa optimizar más. Incluye recuperación, métricas, despliegues graduales, sobrecarga y recarga de modelos.

Una función web o móvil

Evalúa MLC LLM. Para aplicaciones solo Apple, MLX también puede encajar. Distribución de dispositivos, tamaño, temperatura y presión de memoria pesan más que un benchmark de escritorio.

Una instalación TGI existente

Mantenla estable mientras construyes una prueba de compatibilidad con vLLM o SGLang. El aviso de mantenimiento es una señal de planificación, no una orden urgente.

Un producto .NET nativo

Compara TensorSharp con un servidor separado de llama.cpp o sus bindings. Decide por cobertura, seguridad, observabilidad y mantenimiento; no por el benchmark del autor que envió la oportunidad.

Cómo medir sin engañarte

Usa la revisión y cuantización que desplegarás. Congela muestreo y plantilla. Separa carga fría, prefill y decode. Prueba concurrencia 1 y la concurrencia real, en vez de publicar un único máximo de tokens por segundo.

Mide al menos:

• carga del modelo y pico de RAM/VRAM;
• tiempo al primer token con prompts cortos y largos;
• tokens de salida por segundo y petición;
• caudal agregado a la concurrencia objetivo;
• latencias mediana, percentil 95 y 99;
• aciertos de caché con prefijos repetidos;
• corrección de JSON y llamadas a herramientas;
• estabilidad al cancelar, saturar y recargar;
• energía o coste por tarea útil completada.

Separa calentamiento y estado estable. Repite y publica comando, hardware, revisión y distribución de prompts. Si un runtime exige otra cuantización, indícalo: entonces comparas despliegues completos, no solo motores.

Veredicto práctico

Para la mayoría de usuarios locales, la primera comparación es Ollama frente a llama.cpp: comodidad contra control. Quien desarrolla en Apple debe sumar MLX-LM; quien entrega en navegador o teléfono, MLC LLM. Para un servicio compartido, empieza por vLLM y SGLang, y añade TensorRT-LLM si aceptas una vía específica de NVIDIA.

TGI sigue siendo relevante en sistemas instalados, pero su mantenimiento cambia el cálculo para proyectos nuevos. TensorSharp es un candidato especialista razonable para .NET, con la cautela de que la oportunidad y sus benchmarks proceden del mantenedor.

El runtime no es el modelo y el benchmark no es la carga. Preselecciona por capa de despliegue, valida compatibilidad y mide tus prompts con tu concurrencia. Es más lento que elegir la primera fila de una tabla, pero mucho más probable que produzca un sistema fiable.

Para seguir evaluando, visita el centro editorial de FreeAI Tokens y comprueba condiciones en el directorio de tiers gratuitos.

Fuentes y evidencia

• Repositorio de llama.cpp y documentación de llama-server: hardware, cuantización y servicio.
• Repositorio de Ollama y compatibilidad con OpenAI: instalación, ciclo de vida y API.
• Repositorio de MLX-LM: generación, conversión, cuantización y ajuste en Apple silicon.
• Repositorio de MLC LLM: WebGPU, móvil, backends nativos y APIs comunes.
• Repositorio de vLLM y servidor compatible con OpenAI: planificación, caché y servicio.
• Repositorio de SGLang: enfoque de cargas, instalación y hardware.
• Repositorio de TensorRT-LLM: optimización NVIDIA y arquitectura.
• Repositorio de Text Generation Inference: funciones y aviso de mantenimiento.
• Repositorio de TensorSharp: funciones .NET y benchmarks del proyecto.

Fuentes revisadas el 3 de octubre de 2026. Las afirmaciones de rendimiento no reproducidas se identifican como propias del proyecto; esta es una guía por carga, no un ranking de benchmarks.