Motores de inferencia para LLM y hardware de IA local (Edición 2026)

No eliges un motor de inferencia primero. Eliges una estrategia de hardware, una forma de carga de trabajo y un modelo de servicio. El motor viene después.

Esa es la forma más útil de pensar en los motores de inferencia de LLM.

Nota de la serie: Esta es la Parte 3 de mi serie sobre LLMs auto-alojados / IA Local.

• Parte 1: Matemáticas de Memoria GPU para LLMs (Edición 2026).
• Parte 2: Ancho de Banda de Memoria para Hardware de IA Local (Edición 2026).

Esas dos piezas explican la capacidad del hardware y las matemáticas del ancho de banda.

Esta explica la capa de software que convierte ese hardware en inferencia utilizable.

Motores

Estas herramientas sirven para diferentes propósitos / ocupan diferentes capas

• Portabilidad local
• CUDA de consumo
• Flujos de trabajo con memoria unificada de Apple
• Inferencia cuantizada
• Servicio en producción
• Orquestación distribuida
• Ejecución en centro de datos optimizada por el proveedor

Un modelo mental útil:

El motor de inferencia no es "el modelo". Es el agente de tránsito, administrador de memoria, despachador de kernels, planificador, contador de caché, planificador de paralelismo, superficie de API y, a veces, el marco de implementación.

El mejor motor coincide con tu jerarquía de memoria, interconexión, formato de cuantización, objetivos de latencia y rendimiento, arquitectura del modelo y madurez operativa.

La guía de decisión en una página

• Laptop / edge / hardware poco común → llama.cpp
• Flujos de trabajo centrados en Mac → MLX / MLX-LM
• Inferencia local con una sola RTX → ExLlamaV2
• 2-4+ GPUs NVIDIA / CUDA → ExLlamaV3
• Servicio general en producción → vLLM
• Contexto largo / MoE / enrutamiento → SGLang
• Máximo rendimiento en NVIDIA → TensorRT-LLM
• Orquestación de clústeres → NVIDIA Dynamo

El resto de esta guía explica por qué.

Qué hace realmente un motor de inferencia

Un motor de inferencia carga pesos, tokeniza la entrada, ejecuta el pase hacia adelante, muestrea tokens, mantiene la caché KV y transmite los resultados. Los motores serios también manejan procesamiento por lotes, planificación, almacenamiento en caché de prefijos, cuantización, ejecución paralela, servicio de API, métricas y ejecución distribuida.

La carga de trabajo tiene dos fases:

Prefill lee el prompt y construye la caché KV inicial. Es intensivo en cómputo.

Decode genera un token a la vez, leyendo repetidamente los pesos y la caché KV. Está limitado por el ancho de banda de memoria. La velocidad de decode sigue el ancho de banda de memoria más que el pico de cómputo.

Esa distinción explica casi todo:

• Prompt corto, respuesta larga: decode domina → importan el ancho de banda de memoria y el procesamiento por lotes.
• Prompt largo, respuesta corta: prefill domina → importan los kernels de atención y el prefill fragmentado.
• Muchos usuarios: importa la calidad del planificador → procesamiento por lotes continuo, paginación de caché, equidad.
• Contexto largo: la caché KV domina → atención paginada, cuantización de KV, descarga.
• MoE: el enrutamiento de expertos domina → paralelismo de expertos, interconexión, GEMMs agrupados.
• Multi-nodo: la interconexión domina → NVLink, RDMA, paralelismo de tuberías, desagregación.

PagedAttention abordó la fragmentación de la caché KV. FlashAttention usó tileado con conciencia de E/S para reducir el tráfico de HBM. La decodificación especulativa redacta tokens baratos y los verifica en paralelo. El tema recurrente: el rendimiento de la inferencia es movimiento de memoria más planificación.

Los cuellos de botella reales

1. Ancho de banda de memoria, no solo tamaño de VRAM. La VRAM determina el ajuste. El ancho de banda determina la velocidad de decode. El M3 Ultra de Apple ofrece hasta 819 GB/s de ancho de banda de memoria unificada. El H100 SXM de NVIDIA lista 3.35 TB/s de ancho de banda de memoria GPU. La memoria unificada te permite ajustar modelos que no cabrían en VRAM de consumo. La HBM te permite servirlos más rápido cuando el modelo cabe. El ajuste no es velocidad. La capacidad no es ancho de banda.

1. Crecimiento de la caché KV. La caché KV crece con el tamaño del lote y la longitud del contexto. Las cargas de trabajo de contexto largo pueden quedarse sin memoria incluso cuando los pesos caben. PagedAttention particiona la caché KV en bloques, aumentando la utilización y soportando lotes más grandes.

1. Interconexión. En el momento en que un modelo cruza los límites de la GPU (multi-GPU), pagas el costo de comunicación. El paralelismo de tensores necesita colectivos all-reduce frecuentes. El paralelismo de tuberías se comunica en los límites de las etapas. El paralelismo de expertos necesita tráfico all-to-all para MoE. Los documentos de vLLM señalan que sin NVLink, el paralelismo de tuberías puede superar al de tensores.

1. Calidad del planificador. Un buen planificador decide qué solicitudes entran al lote, cómo comparten el acelerador el prefill y el decode, si los prompts largos bloquean los decodes cortos y cómo evitar la inanición. Soportar el procesamiento por lotes no es lo mismo que comportarse como un planificador listo para producción.

1. Sobrecarga en tiempo de ejecución. Los gráficos CUDA, la fusión de kernels, la sobrecarga de muestreo, la sobrecarga del tokenizador, la sobrecarga HTTP, el cambio de LoRA y la decodificación estructurada importan. A gran escala, los molestos overheads del 2% forman una unión y exigen atención.

Las familias de motores

Hay cuatro grandes familias:

Tiempos de ejecución portátiles locales: llama.cpp, MLC LLM, ONNX Runtime GenAI, OpenVINO, herramientas estilo Ollama. Se preocupan por "hacerlo funcionar aquí".

Tiempos de ejecución de Apple/memoria unificada: MLX y MLX-LM. Se preocupan por "usar bien la gran memoria compartida y el stack de Apple".

Motores de cuantización CUDA de consumo: ExLlamaV2 y ExLlamaV3. Se preocupan por "hacer que mi caja con 3090/4090/5090 vuele con pesos de baja precisión".

Motores de servicio en producción: vLLM, SGLang, TensorRT-LLM, TGI, LMDeploy. Se preocupan por usuarios concurrentes, caché KV, procesamiento por lotes, paralelismo, observabilidad y costo por token.

Luego están las capas de orquestación como Dynamo que se sitúan sobre los motores y coordinan flotas, desagregación prefill/decode, enrutamiento y autoescalado.

llama.cpp: el rey de la portabilidad

llama.cpp es la respuesta cuando el hardware es extraño, limitado, fuera de línea, centrado en CPU, orientado al edge o no es un ordenado nodo de centro de datos NVIDIA.

Soporta Apple Silicon a través de ARM NEON, Accelerate y Metal; x86 mediante AVX/AVX2/AVX512/AMX; RISC-V; cuantización de baja precisión; CUDA; AMD vía HIP; MUSA; Vulkan; SYCL; y descarga híbrida CPU+GPU. Por eso llama.ccpp es dueño del carril de "solo hazlo funcionar".

El servidor HTTP es más capaz que un "ejecutor local de juguete". llama-server proporciona rutas compatibles con OpenAI, compatibilidad con la API de Messages de Anthropic, reordenamiento, procesamiento por lotes continuo, soporte multimodal, restricciones de esquema JSON, llamada a funciones, decodificación especulativa y una interfaz web.

La limitación crítica: llama.cpp no es para servicio serio multi-nodo en producción. Su backend RPC está explícitamente documentado como prueba de concepto, frágil e inseguro.

Veredicto: Usa llama.cpp cuando la portabilidad, la operación fuera de línea, GGUF o la descarga híbrida importen más que el servicio a escala de flota.

NO uses con múltiples GPUs

MLX y MLX-LM: el arma de Apple Silicon

MLX es el framework de arreglos de Apple para Apple Silicon, y MLX-LM es el paquete de LLM construido sobre él. Es un stack de ML centrado en Mac.

El hecho clave del hardware es la memoria unificada. Apple Silicon le da a la CPU y a la GPU acceso directo al mismo grupo de memoria. Los arreglos de MLX viven en memoria unificada, y eliges el dispositivo al ejecutar la operación en lugar de mover arreglos entre espacios de memoria separados.

Esto cambia la compensación de la inferencia local. En un sistema con GPU discreta, la pregunta es "¿cabe en VRAM?". En una Mac con chip M y gran memoria unificada, la pregunta se convierte en "¿cabe en memoria y puede el sistema de memoria alimentar a la GPU lo suficientemente rápido?". Los modelos grandes cuantizados pueden caber en máquinas donde el mismo modelo sería imposible en una GPU de consumo de 24 GB.

Sin embargo, también es más lento.

MLX-LM agrega integración con Hugging Face Hub, cuantización, ajuste fino LoRA y completo, inferencia distribuida y un gran ecosistema de modelos de la comunidad MLX. MLX ya no es solo para Mac: ofrece paquetes CUDA y solo CPU para Linux. La comunicación distribuida soporta MPI, Ring sobre TCP, JACCL para RDMA sobre Thunderbolt y NCCL para CUDA.

El propio servidor de MLX-LM advierte que no se recomienda para producción porque solo implementa verificaciones de seguridad básicas.

Veredicto: Usa MLX para flujos de trabajo de ML y LLM centrados en Mac. Para servicio público de alta concurrencia, comienza con un stack de servicio real.

ExLlamaV2 y V3: CUDA de consumo, afinado y rápido

ExLlamaV2 es el motor de cuantización CUDA local para personas que quieren que una GPU NVIDIA de consumo rinda por encima de su peso. Soporta atención paginada, procesamiento por lotes dinámico, almacenamiento en caché de prompts, deduplicación de caché KV, generación por lotes, transmisión y decodificación especulativa. La palabra a recordar es local. Hace que los modelos cuantizados sean rápidos en GPUs CUDA modernas, especialmente tarjetas de consumo.

Mejores casos: una caja con RTX 3090/4090/5090, asistente de codificación local, chat local, modelos cuantizados EXL2 y uso en estación de trabajo prosumer.

ExLlamaV3 extiende la filosofía hacia inferencia multi-GPU y MoE local. Agrega el formato de cuantización EXL3 basado en QTIP, paralelismo de tensores y de expertos flexible para hardware de consumo, un servidor compatible con OpenAI a través de TabbyAPI, procesamiento por lotes continuo dinámico y soporte multimodal.

V3 es convincente cuando tienes 2-4+ GPUs NVIDIA de consumo o quieres MoE local. Espera advertencias: algunos modelos no soportan paralelismo de tensores o de expertos en ExLlamaV3.

Veredicto: ExLlamaV2 es el motor CUDA local del entusiasta. ExLlamaV3 es la frontera para configuraciones locales multi-GPU (2-4). Espera bordes más ásperos para una mejor capacidad.

vLLM: el servidor de producción open-source por defecto

vLLM es el primer motor que la mayoría de los equipos deberían evaluar para el servicio serio de LLMs open-source.

Ofrece gestión de memoria KV basada en PagedAttention, procesamiento por lotes continuo, prefill fragmentado, almacenamiento en caché de prefijos, gráficos CUDA/HIP, cuantización extensa (FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ, AWQ, GGUF), kernels optimizados de atención y GEMM/MoE, decodificación especulativa, torch.compile y desagregación prefill/decode/encode.

También es flexible: paralelismo de tensores/tuberías/datos/expertos/contexto, transmisión, salidas estructuradas, llamada a herramientas, API compatible con OpenAI y API de Messages de Anthropic, gRPC, multi-LoRA y soporte para NVIDIA, AMD, CPUs x86/ARM/PowerPC, además de plugins para TPUs, Gaudi, Ascend, Apple Silicon y más.

Los documentos de vLLM señalan que las implementaciones multi-nodo típicamente usan Ray, y sin NVLink, el paralelismo de tuberías puede superar al de tensores. La trampa es asumir que vLLM elimina la necesidad de pensar en sistemas. Aún necesitas ajustar el procesamiento por lotes, la longitud del contexto, la utilización de memoria GPU, el diseño del paralelismo y el enrutamiento. vLLM te da un motor muy bueno; aún requiere buen diseño de sistemas.

Veredicto: Si alguien dice "necesitamos servir modelos abiertos en producción", vLLM es el punto de partida por defecto.

SGLang: el primo con mentalidad de sistemas de vLLM

SGLang es a lo que recurres cuando la carga de trabajo de servicio es fea: salidas estructuradas, contexto largo, MoE, desagregación y enrutamiento.

Ofrece almacenamiento en caché de prefijos RadixAttention, desagregación prefill-decode, decodificación especulativa, procesamiento por lotes continuo, atención paginada, paralelismo de tensores/tuberías/expertos/datos, salidas estructuradas, prefill fragmentado y procesamiento por lotes multi-LoRA. Soporta NVIDIA, AMD, Intel Xeon, TPUs de Google, NPUs Ascend y más.

El diferenciador de SGLang es la arquitectura de servicio. Su desagregación prefill-decode separa el prefill intensivo en cómputo del decode intensivo en memoria en instancias especializadas, transfiriendo la caché KV entre ellas. Esto evita que los lotes largos de prefill interrumpan el decode y disparen la latencia de tokens.

Veredicto: SGLang es para equipos cuyo cuello de botella ya no es "¿podemos ejecutar el modelo?" sino "¿podemos ejecutarlo bajo tráfico hostil sin incendiar la latencia, la memoria y el costo?"

TensorRT-LLM: máximo rendimiento en NVIDIA

TensorRT-LLM es el stack de máximo rendimiento en NVIDIA. Está optimizado, especializado, es potente y no pretende ser portátil.

Proporciona APIs de Python para construir motores TensorRT con optimizaciones de última generación, además de tiempos de ejecución en Python y C++. Incluye kernels personalizados para atención, GEMMs y MoE; desagregación prefill-decode, paralelismo amplio de expertos, decodificación especulativa; y una API de Python de alto nivel integrada con NVIDIA Dynamo y Triton Inference Server.

Las GPUs B200 pueden cargar pesos FP4 con kernels optimizados. H100 y posteriores soportan cuantización FP8 que puede duplicar el rendimiento y reducir a la mitad el consumo de memoria en comparación con 16 bits con una pérdida mínima de precisión.

Donde brilla: flotas de clase H100/H200/B200/GB200/GB300, centros de datos solo NVIDIA, implementación FP8/FP4, servicio multi-nodo y MoE a escala. Donde es incómodo: portabilidad AMD, Apple o Intel; modelos experimentales que cambian rápidamente; configuraciones locales pequeñas; y equipos que necesitan "funciona en todo".

Veredicto: Si estás comprometido con NVIDIA y te importa el rendimiento absoluto, TensorRT-LLM merece estar en la comparativa. Intercambias portabilidad por rendimiento. Especialización afinada pero menos funciones.

El resto del campo

TGI es el servidor de producción de Hugging Face con trazabilidad, métricas, paralelismo de tensores y procesamiento por lotes continuo. Úsalo cuando la integración con HF y la simplicidad importen.

MLC LLM es el motor de implementación universal primero-compilador con APIs compatibles con OpenAI en REST, Python, JavaScript, iOS y Android. Mejor para "enviar LLMs a todas partes", especialmente navegador, móvil y aplicaciones nativas.

ONNX Runtime GenAI implementa el bucle generativo completo sobre ONNX Runtime y potencia Foundry Local, Windows ML y el AI Toolkit de VS Code. Soporta CPU, CUDA, DirectML, TensorRT-RTX, OpenVINO, QNN, WebGPU y GPU AMD. Mejor para implementación de aplicaciones y flujos de trabajo ONNX.

OpenVINO GenAI es la historia optimizada por Intel para CPUs Xeon, GPUs Arc, Core Ultra y NPUs. Ofrece servicio compatible con OpenAI con procesamiento por lotes continuo y atención paginada. Mejor para hardware Intel.

LMDeploy es un kit de herramientas centrado en CUDA con TurboMind para rendimiento y PyTorch para accesibilidad. Más interesante para usuarios de CUDA que quieren una alternativa a vLLM/SGLang/TensorRT-LLM.

NVIDIA Dynamo es una capa de orquestación distribuida sobre motores como vLLM, SGLang y TensorRT-LLM, que soporta desagregación, enrutamiento inteligente y almacenamiento en caché KV de múltiples niveles. Úsalo cuando el servicio con un solo motor ya no sea suficiente.

Nota: NO USES Ollama.

Recetas de estrategia de hardware

Servidor solo CPU: llama.cpp primero. OpenVINO para Intel Xeon. ONNX Runtime GenAI para implementación de aplicaciones/ONNX.

MacBook / Mac Studio: MLX / MLX-LM para flujos de trabajo nativos de Mac. llama.cpp para portabilidad GGUF.

Una sola RTX 3090 / 4090 / 5090: ExLlamaV2 para inferencia local EXL2. llama.cpp para GGUF o portabilidad. vLLM si se sirve a múltiples usuarios.

Caja con dos o cuatro RTX de consumo: ExLlamaV3 para inferencia cuantizada multi-GPU o MoE. vLLM si el comportamiento de servicio importa. SGLang si se prueban patrones de enrutamiento o contexto largo.

Nodo 8×H100 / H200: Comienza con vLLM o SGLang. Compara TensorRT-LLM si es solo NVIDIA y el rendimiento justifica el ajuste. Usa Dynamo cuando la orquestación multi-nodo sea necesaria.

Infraestructura clase B200 / GB200 / GB300: Compara TensorRT-LLM, SGLang y vLLM. Agrega Dynamo para orquestación a nivel de flota, enrutamiento con conciencia de KV y autoescalado.

AMD MI300 / MI325 / MI350 / MI355: Comienza con vLLM o SGLang en ROCm. Evita asumir que los benchmarks de NVIDIA se transfieren limpiamente.

Intel Xeon / Core Ultra / Arc: OpenVINO GenAI o OpenVINO Model Server. ONNX Runtime GenAI si la incrustación en aplicaciones importa.

Navegador, móvil, aplicación nativa: MLC LLM / WebLLM u ONNX Runtime GenAI.

Evaluación comparativa: qué medir

Benchmark malo: "Obtuve 180 tok/s."

Un buen benchmark incluye:

Modelo: modelo exacto, arquitectura, número de parámetros, parámetros activos de MoE.

Pesos: tipo de dato, formato de cuantización, tamaño de grupo, calibración.

Motor: versión, commit, backend, banderas.

Hardware: SKU de GPU, capacidad de memoria, ancho de banda, interconexión, CPU, RAM.

Carga de trabajo: distribuciones de longitud de entrada/salida, concurrencia, transmisión, prefijos compartidos, salida estructurada.

Métricas: TTFT, TPOT, latencia de extremo a extremo, p50/p95/p99, tokens por segundo, solicitudes por segundo, uso de memoria GPU, tasa de aciertos de caché KV, rendimiento de prefill, rendimiento de decode, costo por 1M de tokens.

Reglas de evaluación comparativa:

1. Nunca compares motores usando solo tokens por segundo de un solo usuario.
2. Prueba tu distribución real de prompts y salidas.
3. Prueba con concurrencia realista.
4. Separa el prefill del decode.
5. Rastrea el p95 y p99, no solo los promedios.
6. Mide el margen de memoria en la longitud de contexto objetivo.
7. Prueba la reutilización de caché si tu aplicación tiene prefijos repetidos.
8. Evalúa la salida estructurada por separado; la gramática añade sobrecarga.
9. Evalúa LoRA y multi-LoRA por separado.
10. Vuelve a probar después de actualizaciones de driver, CUDA, ROCm, modelo o motor.

Errores comunes

Elegir solo por capacidad de VRAM. La VRAM determina el ajuste. El ancho de banda y el planificador determinan la velocidad. Una máquina con gran memoria unificada puede albergar modelos enormes, pero un H100 decodifica más rápido cuando el modelo cabe debido a un ancho de banda HBM mucho mayor.

Usar paralelismo de tensores en interconexión débil. Sin NVLink o NVSwitch, prueba el paralelismo de tuberías. Los documentos de vLLM señalan esto para configuraciones tipo L40S.

Ignorar la caché KV. El contexto largo y la concurrencia pueden hacer que la caché KV sea el factor limitante. PagedAttention, el almacenamiento en caché de prefijos, la cuantización KV y la desagregación no son opcionales a escala.

Tratar los motores locales como servidores de producción. El servidor de llama.cpp es capaz. El servidor de MLX-LM es conveniente. Ollama es agradable pero NO DEBE USARSE.

Sin embargo, producción significa seguridad, observabilidad, contrapresión, enrutamiento, autoescalado y comportamiento de SLA. El propio MLX-LM advierte que su servidor no se recomienda para producción.

Asumir que todo formato de cuantización es portátil. GGUF, EXL2, EXL3, AWQ, GPTQ, FP8, FP4, formatos MLX y ONNX no son intercambiables. El formato correcto es aquel para el que tu motor tiene kernels optimizados.

Ignorar la arquitectura del modelo. Los modelos densos, MoE, atención híbrida, modelos multimodales y variantes de contexto largo estresan diferentes partes del motor. Un soporte amplio no significa que cada optimización funcione igual.

Confiar en gráficos de benchmark sin forma de carga de trabajo. Un gráfico para Llama 3.1 8B con 1K de entrada / 128 de salida dice poco sobre un agente de codificación con 80K de contexto ejecutando Qwen 3.6 27B / Gemma 4 26B-A4B, o un servicio RAG con 500 usuarios concurrentes.

El mapa final opinado

Usuario de IA Local: LM Studio o Harbor por conveniencia. llama.cpp por control. MLX en Mac. ExLlamaV2/V3 por rendimiento CUDA local.

Construyendo un agente local: Cualquiera debería funcionar, pero dado lo que la mayoría usa; llama.cpp por portabilidad. MLX si los usuarios están en Apple Silicon. vLLM si se simula servicio en producción localmente.

Sirviendo a un equipo interno: Comienza con vLLM. Usa SGLang si importan las salidas estructuradas, el contexto largo, multi-LoRA, MoE o el enrutamiento.

Sirviendo a clientes a escala: Compara vLLM, SGLang y TensorRT-LLM. Si importan el enrutamiento y la desagregación, SGLang y Dynamo merecen atención.

Centro de datos NVIDIA: TensorRT-LLM por máximo rendimiento. vLLM por flexibilidad. SGLang por servicio complejo. Dynamo por orquestación de flota.

Apple Silicon: MLX para desarrollo nativo. llama.cpp para GGUF. La memoria unificada es un superpoder de capacidad con compensaciones de ancho de banda, no HBM.

Edge, aplicación, navegador o nativo de Windows: llama.cpp, MLC LLM, ONNX Runtime GenAI u OpenVINO, dependiendo del stack.

Principio final

Los motores de inferencia tienen consecuencias.

Elige el motor después de responder estas preguntas:

1. ¿Qué hardware tengo realmente?
2. ¿El modelo cabe en memoria rápida, o solo en memoria del sistema/unificada?
3. ¿El decode o el prefill son el cuello de botella?
4. ¿Qué longitud de contexto y concurrencia importan?
5. ¿Los prompts se comparten lo suficiente para el almacenamiento en caché de prefijos?
6. ¿El modelo es denso, MoE, multimodal o híbrido?
7. ¿Necesito conveniencia local, servicio en producción u orquestación de flota?
8. ¿Qué formato de cuantización tiene kernels optimizados en mi motor objetivo?
9. ¿Mi interconexión es PCIe, NVLink, NVSwitch, Ethernet, RDMA o Thunderbolt?
10. ¿Estoy optimizando latencia, rendimiento, costo, privacidad, portabilidad o velocidad de desarrollo?

El motor sigue las respuestas.

Hasta la próxima.

-Ahmad