Motores de Inferencia para LLMs y Hardware de IA Local

Los principales motores de inferencia para LLMs en 2026 son llama.cpp (portabilidad local), vLLM (servicio de producción), TensorRT-LLM (máximo rendimiento en infraestructura NVIDIA), SGLang (contexto largo y arquitecturas MoE), ExLlamaV2/V3 (inferencia cuantizada en GPU de consumo), MLX/MLX-LM (ecosistema Apple Silicon) y TGI (integración con Hugging Face). La selección del motor adecuado depende del hardware disponible, el formato de cuantización requerido, los objetivos de latencia y throughput, y la distinción fundamental entre uso local y servicio de producción.

---

Nota de la serie: Este artículo constituye la segunda parte de la serie sobre LLMs autoalojados e IA Local.

• Parte 1: Ancho de banda de memoria para IA local en 2026

Las entrega anterior establece las bases del hardware: capacidad de memoria y matemáticas del ancho de banda. Esta pieza analiza la capa de software que transforma ese hardware en capacidad de inferencia operativa.

---

Motores (Engines)

La decisión del motor de inferencia no debe ser el punto de partida. Primero se define la estrategia de hardware, el perfil de carga de trabajo y el modelo de servicio. El motor es, con diferencia, la última variable por resolver.

Esa es, en mi opinión, la forma más rigurosa de abordar la selección de motores de inferencia para LLM.

Las herramientas disponibles responden a propósitos distintos y operan en capas diferentes:

• Portabilidad local
• CUDA de consumo
• Flujos de trabajo de memoria unificada de Apple
• Inferencia cuantizada
• Servicio en producción (Production serving)
• Orquestación distribuida
• Ejecución optimizada por proveedor para centros de datos

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

Caso de uso	Motor recomendado
Laptop / Edge / Hardware inusual	llama.cpp
Flujos de trabajo centrados en Mac	MLX / MLX-LM
Inferencia local en una sola RTX	ExLlamaV2
2-4+ GPUs NVIDIA / CUDA	ExLlamaV3
Servicio general en producción	vLLM
Contexto largo / MoE / Enrutamiento	SGLang
Rendimiento máximo de NVIDIA	TensorRT-LLM
Orquestación de clústeres	NVIDIA Dynamo

Las secciones siguientes desarrollan el fundamento de cada recomendación.

¿Qué hace realmente un motor de inferencia?

Un motor de inferencia carga los pesos del modelo, tokeniza la entrada, ejecuta el paso hacia adelante (forward pass), muestrea los tokens, mantiene la caché KV y transmite los resultados. Los motores de categoría profesional gestionan además el batching, la planificación de solicitudes, la caché de prefijos, la cuantización, la ejecución paralela, el servicio de API, las métricas de observabilidad y la ejecución distribuida.

La carga de trabajo de inferencia se divide en dos fases con perfiles de rendimiento fundamentalmente distintos:

• Prefill (Prellenado): procesa el prompt completo y construye la caché KV inicial. Esta fase es intensiva en cómputo (compute-bound).
• Decode (Decodificación): genera tokens de forma secuencial, leyendo repetidamente los pesos y la caché KV en cada paso. Esta fase está limitada por el ancho de banda de memoria (memory-bound). La velocidad de decodificación depende del ancho de banda de memoria con mucha mayor intensidad que del cómputo pico.

Esta distinción explica, por sí sola, la mayor parte de las decisiones arquitectónicas en inferencia:

• Prompt corto, respuesta larga: domina la decodificación → el ancho de banda de memoria y el batching son determinantes.
• Prompt largo, respuesta corta: domina el prefill → los kernels de atención y el chunked prefill marcan la diferencia.
• Múltiples usuarios concurrentes: la calidad del planificador (scheduler) es crítica → continuous batching, paginación de caché y equidad en la distribución de recursos.
• Contexto largo: la caché KV es el factor limitante → paged attention, cuantización de KV y offload a memoria del sistema.
• MoE (Mixture of Experts): el enrutamiento de expertos es el cuello de botella → paralelismo de expertos, interconexión de alta velocidad y GEMMs agrupados.
• Despliegue multinodo: la interconexión lo determina todo → NVLink, RDMA, paralelismo de tubería (pipeline parallelism) y desagregación de fases.

PagedAttention resolvió la fragmentación de la caché KV. FlashAttention empleó tiling consciente de E/S para reducir el tráfico de HBM. La decodificación especulativa propone tokens de bajo costo y los valida en paralelo. El hilo conductor es inequívoco: el rendimiento de la inferencia se reduce a movimiento de memoria y planificación eficiente.

Los cuellos de botella reales

Ancho de banda de memoria, no solo capacidad de VRAM

La VRAM determina si el modelo cabe. El ancho de banda determina la velocidad de decodificación. El M3 Ultra de Apple alcanza los 819 GB/s de ancho de banda de memoria unificada. La NVIDIA H100 SXM registra 3.35 TB/s de ancho de banda de memoria GPU. La memoria unificada permite alojar modelos que exceden la capacidad de cualquier VRAM de consumo. La HBM permite servirlos con mayor rapidez cuando el modelo cabe. Que quepa no equivale a velocidad; capacidad no es ancho de banda.

Crecimiento de la caché KV

La caché KV escala proporcionalmente con el tamaño del lote (batch) y la longitud del contexto. Las cargas de trabajo con contexto extenso pueden agotar la memoria disponible incluso cuando los pesos del modelo caben con holgura. PagedAttention mitiga este problema al particionar la caché KV en bloques, incrementando la utilización de memoria y permitiendo lotes más amplios.

Interconexión

En el instante en que un modelo trasciende los límites de una GPU individual, se incurre en un costo de comunicación. El paralelismo de tensores exige operaciones all-reduce frecuentes. El paralelismo de tubería comunica en los límites de cada etapa. El paralelismo de expertos requiere tráfico all-to-all para MoE. La documentación de vLLM señala que, en ausencia de NVLink, el paralelismo de tubería puede ofrecer mejor rendimiento que el paralelismo de tensores.

Calidad del planificador (Scheduler)

Un planificador eficaz decide qué solicitudes ingresan a cada lote, cómo coexisten el prefill y la decodificación en el mismo acelerador, si los prompts extensos bloquean las decodificaciones breves y cómo prevenir la inanición (starvation) de solicitudes. Soportar batching no es equivalente a comportarse como un planificador preparado para producción.

Sobrecarga del tiempo de ejecución (Runtime overhead)

Los CUDA graphs, la fusión de kernels, la sobrecarga de muestreo, el tokenizador, la capa HTTP, el cambio dinámico de LoRA y la decodificación estructurada tienen impacto medible. A gran escala, las sobrecargas aparentemente insignificantes del 2% se acumulan y requieren atención deliberada (valga la coincidencia con el mecanismo de attention).

Las familias de motores

El ecosistema se agrupa en cuatro familias con prioridades distintas:

1. Runtimes locales portátiles: llama.cpp, MLC LLM, ONNX Runtime GenAI, OpenVINO, herramientas estilo Ollama. Su premisa: «haz que funcione aquí».
2. Runtimes de Apple y memoria unificada: MLX y MLX-LM. Su premisa: «aprovecha la gran memoria compartida y el stack de Apple».
3. Motores de cuantización CUDA para consumo: ExLlamaV2 y ExLlamaV3. Su premisa: «extrae el máximo rendimiento de una GPU de consumo con pesos de bajos bits».
4. Motores de servicio en producción: vLLM, SGLang, TensorRT-LLM, TGI, LMDeploy. Su premisa: usuarios concurrentes, gestión de caché KV, batching eficiente, paralelismo, observabilidad y optimización del costo por token.

Por encima de estas familias existen capas de orquestación, como NVIDIA Dynamo, que coordinan flotas de motores, gestionan la desagregación de prefill/decode, implementan enrutamiento inteligente y escalado automático.

llama.cpp: El rey de la portabilidad

llama.cpp es la respuesta cuando el hardware es heterogéneo, limitado, opera sin conexión, depende significativamente de la CPU, está orientado al edge o simplemente no es un nodo de centro de datos NVIDIA convencional.

Soporta Apple Silicon a través de ARM NEON, Accelerate y Metal; x86 mediante AVX/AVX2/AVX512/AMX; RISC-V; cuantización de bajos bits; CUDA; AMD vía HIP; MUSA; Vulkan; SYCL; y offload híbrido CPU+GPU. Esta cobertura explica por qué llama.cpp domina el segmento del «simplemente haz que funcione».

Su servidor HTTP supera ampliamente la categoría de «ejecutor local». llama-server ofrece rutas compatibles con la API de OpenAI, compatibilidad con la API de Messages de Anthropic, reranking, continuous batching, soporte multimodal, restricciones de esquema JSON, llamadas a funciones (function calling), decodificación especulativa e interfaz web integrada.

Veredicto: Opta por llama.cpp cuando la portabilidad, la operación offline, el formato GGUF o el offload híbrido son prioritarios frente al servicio a escala de flota. No recomendado para: configuraciones Multi-GPU.

MLX y MLX-LM: El ecosistema de Apple Silicon

MLX es el framework de arrays de Apple diseñado para Apple Silicon, y MLX-LM es el paquete de LLM construido sobre él. Se trata de un stack de machine learning concebido primordialmente para el entorno Mac.

El elemento diferenciador del hardware es la memoria unificada. Apple Silicon otorga a la CPU y a la GPU acceso directo al mismo espacio de memoria. Los arrays de MLX residen en memoria unificada, y la selección del dispositivo se realiza al ejecutar la operación, eliminando la necesidad de transferir datos entre espacios de memoria separados.

Esta arquitectura transforma la ecuación de la inferencia local. En un sistema con GPU discreta, la pregunta es «¿cabe en la VRAM?». En un Mac de la serie M con memoria unificada abundante, la pregunta se convierte en «¿cabe en la memoria y puede el subsistema de memoria alimentar a la GPU con suficiente rapidez?». Modelos cuantizados de gran escala pueden residir en máquinas donde el mismo modelo resultaría inviable en una GPU de consumo de 24 GB.

No obstante, el costo es velocidad.

MLX-LM incorpora integración con Hugging Face Hub, cuantización, LoRA y ajuste fino completo (full fine-tuning), inferencia distribuida y un ecosistema extenso de modelos mantenidos por la comunidad. MLX ya trasciende el ecosistema Apple: ofrece paquetes para CUDA y CPU exclusiva en Linux. El subsistema de comunicación distribuida soporta MPI, Ring sobre TCP, JACCL para RDMA sobre Thunderbolt y NCCL para CUDA.

Veredicto: MLX es la elección natural para flujos de trabajo de ML y LLM centrados en Mac. Para servicio público de alta concurrencia, se recomienda partir de un stack de servicio diseñado para producción.

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

ExLlamaV2 es el motor de cuantización CUDA orientado a usuarios que desean que una GPU NVIDIA de consumo rinda por encima de sus especificaciones nominales. Incorpora paged attention, dynamic batching, caché de prompts, deduplicación de caché KV, generación por lotes, streaming y decodificación especulativa. La palabra clave es local: optimiza la ejecución de modelos cuantizados en GPUs CUDA modernas, con énfasis en tarjetas de consumo.

Caso de uso ideal: estaciones de trabajo con RTX 3090/4090/5090, asistentes de código locales, chat local, modelos cuantizados en formato EXL2 y entornos prosumer.

ExLlamaV3 extiende esta filosofía hacia el terreno multinodo y la inferencia local de arquitecturas MoE. Introduce el formato de cuantización EXL3 basado en el framework QTIP, inferencia flexible con paralelismo de tensores y expertos para hardware de consumo, servidor compatible con OpenAI a través de TabbyAPI, continuous dynamic batching y soporte multimodal.

V3 resulta atractivo cuando se dispone de 2 a 4 GPUs NVIDIA de consumo o se requiere inferencia MoE local. Cabe señalar que no todos los modelos soportan paralelismo de tensores o expertos en ExLlamaV3.

Veredicto: ExLlamaV2 es el motor CUDA local para entusiastas y profesionales. ExLlamaV3 representa la frontera para configuraciones multi-GPU de consumo (2-4 unidades). A mayor capacidad, mayor complejidad en los bordes.

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

vLLM constituye el primer motor que la mayoría de los equipos deberían evaluar al abordar un despliegue serio de LLMs open-source en producción.

Ofrece gestión de memoria KV basada en PagedAttention, continuous batching, chunked prefill, caché de prefijos, CUDA/HIP graphs, cuantización extensiva (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 de prefill/decode/encode.

Su flexibilidad es notable: paralelismo de tensor/tubería/datos/expertos/contexto, streaming, salidas estructuradas, llamadas a herramientas (tool calling), APIs compatibles con OpenAI y Anthropic Messages, gRPC, multi-LoRA y soporte para NVIDIA, AMD, CPUs x86/ARM/PowerPC, además de plugins para TPUs, Gaudi, Ascend, Apple Silicon y plataformas adicionales.

La documentación de vLLM indica que los despliegues multinodo suelen emplear Ray y que, sin NVLink, el paralelismo de tubería puede superar al de tensores. La trampa conceptual consiste en asumir que vLLM elimina la necesidad de pensamiento arquitectónico. Persiste la necesidad de ajustar el batching, la longitud del contexto, la utilización de memoria GPU, el diseño del paralelismo y el enrutamiento. vLLM proporciona un motor excepcional; no exime de un diseño de sistemas riguroso.

Veredicto: Ante la necesidad de servir modelos abiertos en producción, vLLM es el punto de partida predeterminado.

SGLang: El primo «arquitecto» de vLLM

SGLang es la herramienta a la que se recurre cuando la carga de trabajo de servicio presenta complejidad adicional: salidas estructuradas, contexto extenso, arquitecturas MoE, desagregación de fases y enrutamiento sofisticado.

Incorpora caché de prefijos RadixAttention, desagregación prefill-decode, decodificación especulativa, continuous batching, paged attention, paralelismo de tensor/tubería/expertos/datos, salidas estructuradas, chunked prefill y batching multi-LoRA. Soporta NVIDIA, AMD, Intel Xeon, Google TPUs, Ascend NPUs y plataformas adicionales.

El elemento diferenciador de SGLang reside en su arquitectura de servicio. La desagregación prefill-decode separa el prefill (intensivo en cómputo) de la decodificación (intensiva en memoria) en instancias especializadas, transfiriendo la caché KV entre ellas. Este diseño evita que los lotes de prefill extensos perturben la decodificación y eleven la latencia de los tokens.

Veredicto: SGLang está orientado a equipos cuyo cuello de botella ya no es «¿podemos ejecutar el modelo?», sino «¿podemos mantener la latencia, la memoria y el costo bajo control ante tráfico hostil?».

TensorRT-LLM: Máximo rendimiento de NVIDIA

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

Proporciona APIs de Python para construir motores TensorRT con optimizaciones de vanguardia, junto con runtimes en Python y C++. Incluye kernels personalizados para atención, GEMMs y MoE; desagregación prefill-decode, Wide Expert Parallelism, 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 generaciones posteriores soportan cuantización FP8, capaz de duplicar el rendimiento y reducir a la mitad el consumo de memoria frente a 16 bits, con una pérdida de precisión mínima.

Dónde brilla: flotas clase H100/H200/B200/GB200/GB300, centros de datos exclusivamente NVIDIA, despliegue FP8/FP4, servicio multinodo y MoE a escala. Dónde resulta incómodo: portabilidad a AMD, Apple o Intel; modelos experimentales en evolución rápida; configuraciones locales modestas y equipos que requieren compatibilidad universal.

Veredicto: Si la infraestructura es NVIDIA y el rendimiento absoluto es prioritario, TensorRT-LLM debe figurar en la comparativa. Se intercambia portabilidad por rendimiento: especialización ajustada a cambio de menor versatilidad.

El resto del campo

Motor	Descripción	Cuándo usarlo
TGI	Servidor de producción de Hugging Face con trazado (tracing), métricas, paralelismo de tensores y continuous batching.	Cuando la integración con Hugging Face y la simplicidad operativa son prioritarias.
MLC LLM	Motor de despliegue universal basado en compilador con APIs compatibles con OpenAI en REST, Python, JavaScript, iOS y Android.	Navegadores, dispositivos móviles y aplicaciones nativas.
ONNX Runtime GenAI	Implementa el ciclo generativo completo sobre ONNX Runtime. Potencia Foundry Local, Windows ML y VS Code AI Toolkit. Soporta CPU, CUDA, DirectML, TensorRT-RTX, OpenVINO, QNN, WebGPU y GPU AMD.	Despliegue de aplicaciones y flujos de trabajo basados en ONNX.
OpenVINO GenAI	Solución optimizada de Intel para CPUs Xeon, GPUs Arc, Core Ultra y NPUs. Servicio compatible con OpenAI con continuous batching y paged attention.	Hardware Intel.
LMDeploy	Kit de herramientas centrado en CUDA con TurboMind para rendimiento y PyTorch para accesibilidad.	Usuarios de CUDA que busquen una alternativa a vLLM, SGLang o TensorRT-LLM.
NVIDIA Dynamo	Capa de orquestación distribuida que opera sobre motores como vLLM, SGLang y TensorRT-LLM. Soporta desagregación, enrutamiento inteligente y caché KV multinivel.	Cuando un motor individual ya no es suficiente para la escala requerida.

Recetas de estrategia de hardware

Hardware	Motor recomendado
Servidor solo CPU	llama.cpp. OpenVINO para Intel Xeon. ONNX Runtime GenAI para despliegue de aplicaciones y flujos ONNX.
MacBook / Mac Studio	MLX / MLX-LM para flujos nativos. llama.cpp para portabilidad GGUF.
Sola RTX 3090 / 4090 / 5090	ExLlamaV2 para inferencia local EXL2. llama.cpp para GGUF o portabilidad. vLLM si se requiere servicio a múltiples usuarios.
Equipo Dual o Quad RTX de consumo	ExLlamaV3 para inferencia cuantizada multi-GPU o MoE. vLLM si el comportamiento del servicio es prioritario. SGLang para enrutamiento o patrones de contexto largo.
Nodo 8xH100 / H200	Partir con vLLM o SGLang. Evaluar TensorRT-LLM si la infraestructura es exclusivamente NVIDIA y el rendimiento justifica la optimización. Incorporar Dynamo cuando la orquestación multinodo sea necesaria.
Infraestructura clase B200 / GB200 / GB300	Benchmark de TensorRT-LLM, SGLang y vLLM. Añadir Dynamo para orquestación a nivel de flota, enrutamiento consciente de KV y autoescalado.
AMD MI300 / MI325 / MI350 / MI355	Partir con vLLM o SGLang sobre ROCm. No asumir que los benchmarks de NVIDIA se trasladan directamente.
Intel Xeon / Core Ultra / Arc	OpenVINO GenAI o OpenVINO Model Server. ONNX Runtime GenAI si la integración en aplicaciones es relevante.
Navegador, móvil, aplicación nativa	MLC LLM / WebLLM u ONNX Runtime GenAI.

Benchmarking: qué medir

Un benchmark riguroso documenta los siguientes elementos:

Elemento	Qué especificar
Modelo	Identificador exacto, arquitectura, conteo de parámetros, parámetros activos en MoE.
Pesos	dtype, formato de cuantización, tamaño del grupo (group size), método de calibración.
Motor	Versión, commit, backend, flags de configuración.
Hardware	SKU de GPU, capacidad y ancho de banda de memoria, interconexión, CPU, RAM del sistema.
Carga de trabajo	Distribuciones de longitud de entrada y salida, nivel de concurrencia, streaming, prefijos compartidos, salida estructurada.
Métricas	TTFT, TPOT, latencia extremo a extremo, percentiles p50/p95/p99, tokens/s, requests/s, utilización de memoria GPU, tasa de aciertos de caché KV, throughput de prefill y decode, costo por 1M de tokens.

Reglas de benchmarking:

• No compares motores empleando únicamente tokens por segundo con un solo usuario.
• Evalúa con tu distribución real de prompts y salidas.
• Prueba con niveles de concurrencia realistas.
• Separa las métricas de prefill de las de decodificación.
• Rastrea los percentiles p95 y p99, no solo los promedios.
• Mide el margen de memoria (headroom) en la longitud de contexto objetivo.
• Evalúa la reutilización de caché si tu aplicación presenta prefijos repetidos.
• Realiza benchmark de salidas estructuradas de forma independiente; las gramáticas introducen sobrecarga adicional.
• Evalúa LoRA y multi-LoRA por separado.
• Repite las pruebas tras actualizaciones de drivers, CUDA, ROCm, modelo o motor.

Errores comunes

• Elegir basándose exclusivamente en la capacidad de VRAM. La VRAM determina si el modelo cabe. El ancho de banda y la calidad del planificador determinan la velocidad. Una máquina con memoria unificada abundante puede alojar modelos de gran escala, pero una H100 decodifica con mayor rapidez cuando el modelo cabe, gracias a su ancho de banda HBM significativamente superior.
• Emplear paralelismo de tensores sobre interconexiones débiles. En ausencia de NVLink o NVSwitch, se recomienda probar el paralelismo de tubería (pipeline parallelism). La documentación de vLLM advierte sobre esta limitación para configuraciones tipo L40S.
• Ignorar la caché KV. El contexto extenso y la concurrencia pueden convertir la caché KV en el factor limitante. PagedAttention, la caché de prefijos, la cuantización de KV y la desagregación de fases dejan de ser opcionales a medida que escala el despliegue.
• Tratar motores locales como servidores de producción. El servidor de llama.cpp es capaz. El servidor de MLX-LM es conveniente. Ollama es práctica para desarrollo. No obstante, la producción exige: seguridad, observabilidad, contrapresión (backpressure), enrutamiento, autoescalado y cumplimiento de SLA. El propio MLX-LM advierte que su servidor no está recomendado para producción.
• Asumir que los formatos de cuantización son intercambiables. GGUF, EXL2, EXL3, AWQ, GPTQ, FP8, FP4, formatos MLX y ONNX no son equivalentes. El formato adecuado es aquél para el cual tu motor objetivo cuenta con kernels optimizados.
• Ignorar la arquitectura del modelo. Los modelos densos, MoE, atención híbrida, modelos multimodales y variantes de contexto largo ejercen presión sobre componentes distintos del motor. El «amplio soporte» no garantiza que cada optimización funcione con la misma eficacia.
• Confiar en tablas de benchmarks sin conocer el perfil de carga. Una tabla generada con Llama 3.1 8B, 1K de entrada y 128 de salida aporta poca información sobre un agente de código con 80K de contexto ejecutando Qwen 3.6 27B o Gemma 4 26B-A4B, ni sobre un servicio RAG con 500 usuarios concurrentes.

El mapa final (estilo opinado)

Perfil	Recomendación
Usuario de IA local	LM Studio o Harbor por conveniencia. llama.cpp para control granular. MLX en Mac. ExLlamaV2/V3 para rendimiento CUDA local.
Construcción de agente local	llama.cpp por portabilidad. MLX si los usuarios operan en Apple Silicon. vLLM si se simula servicio de producción localmente.
Servicio para equipo interno	Partir con vLLM. Emplear SGLang si son relevantes las salidas estructuradas, el contexto extenso, multi-LoRA, MoE o el enrutamiento.
Servicio a clientes a escala	Benchmark de vLLM, SGLang y TensorRT-LLM. Si el enrutamiento y la desagregación son determinantes, SGLang y Dynamo merecen consideración.
Centro de datos NVIDIA	TensorRT-LLM para rendimiento máximo. vLLM para flexibilidad. SGLang para servicio complejo. Dynamo para orquestación de flota.
Apple Silicon	MLX para desarrollo nativo. llama.cpp para GGUF. La memoria unificada ofrece capacidad excepcional con compensaciones en ancho de banda; no equivale a HBM.
Edge, aplicación, navegador o Windows nativo	llama.cpp, MLC LLM, ONNX Runtime GenAI u OpenVINO, según el stack tecnológico.

Principio final

Los Motores de Inferencia tienen consecuencias. Selecciona el motor una vez respondidas las siguientes preguntas:

1. ¿Qué hardware tengo efectivamente disponible?
2. ¿El modelo cabe en la memoria rápida o requiere la memoria del sistema o unificada?
3. ¿Cuál es el cuello de botella predominante: la decodificación o el prefill?
4. ¿Qué longitud de contexto y nivel de concurrencia son operativamente relevantes?
5. ¿Los prompts se comparten con suficiente frecuencia como para justificar caché de prefijos?
6. ¿La arquitectura del modelo es densa, MoE, multimodal o híbrida?
7. ¿Se requiere conveniencia local, servicio de producción u orquestación de flota?
8. ¿Qué formato de cuantización cuenta con kernels optimizados en el motor candidato?
9. ¿La interconexión disponible es PCIe, NVLink, NVSwitch, Ethernet, RDMA o Thunderbolt?
10. ¿La optimización prioriza latencia, throughput, costo, privacidad, portabilidad o velocidad de desarrollo?

El motor adecuado se deduce de las respuestas.

Preguntas frecuentes

¿Qué motor de inferencia debo usar para IA local en una sola GPU NVIDIA?

Para una RTX 3090/4090/5090 individual, ExLlamaV2 es la opción recomendada para inferencia cuantizada local con formato EXL2. Si se prioriza la portabilidad GGUF, llama.cpp es la alternativa adecuada. Para servicio a múltiples usuarios concurrentes, vLLM constituye el mejor punto de partida.

¿vLLM o SGLang: cuál es más adecuado para producción?

vLLM es el motor predeterminado para la mayoría de los despliegues de producción, gracias a su amplio soporte de modelos, formatos de cuantización y plataformas de hardware. SGLang ofrece ventajas cuando la carga de trabajo requiere contexto largo extremo, salidas estructuradas, arquitecturas MoE o desagregación prefill-decode. Se recomienda realizar benchmark de ambos motores con el perfil de carga real.

¿Puedo emplear llama.cpp para servicio de producción?

llama.cpp es excelente para uso local, portabilidad y entornos con hardware heterogéneo, pero no está diseñado para servicio de producción a escala. Su backend RPC se documenta como una prueba de concepto. Para despliegues de producción, se recomienda vLLM, SGLang o TensorRT-LLM según la infraestructura disponible.

¿Qué motor es recomendable para Apple Silicon (Mac)?

MLX/MLX-LM es la opción nativa para Apple Silicon, aprovechando la arquitectura de memoria unificada. llama.cpp constituye la alternativa cuando se requiere portabilidad GGUF o soporte para un catálogo más amplio de modelos. Cabe destacar que el servidor de MLX-LM no está recomendado para producción.

¿En qué circunstancias vale la pena utilizar TensorRT-LLM?

TensorRT-LLM es recomendable cuando la infraestructura es exclusivamente NVIDIA (H100, H200, B200, GB200, GB300), se requiere el máximo rendimiento posible y se acepta la renuncia a la portabilidad. Resulta especialmente relevante para despliegues FP8/FP4, servicio multinodo y arquitecturas MoE a escala. La contrapartida es la pérdida de compatibilidad con AMD, Apple o Intel.

¿Qué métricas son esenciales al realizar benchmark de motores?

Las métricas fundamentales son: TTFT (Tiempo al primer token), TPOT (Tiempo por token de salida), latencia en percentiles p50/p95/p99, tokens por segundo, solicitudes por segundo, utilización de memoria GPU y tasa de aciertos de la caché KV. No se deben comparar motores empleando exclusivamente tokens por segundo con un único usuario; es necesario probar con concurrencia realista y distribuciones de prompts representativas.

¿Es preferible el paralelismo de tensores o el de tubería en ausencia de NVLink?

Sin NVLink o NVSwitch, el paralelismo de tubería (pipeline parallelism) suele ofrecer mejor rendimiento que el paralelismo de tensores. La documentación de vLLM advierte sobre esta limitación para configuraciones como L40S. El paralelismo de tensores requiere operaciones all-reduce frecuentes que resultan especialmente costosas sobre interconexiones PCIe de ancho de banda limitado.

¿Son intercambiables los formatos de cuantización entre motores?

No lo son. GGUF, EXL2, EXL3, AWQ, GPTQ, FP8, FP4, formatos MLX y ONNX no son equivalentes entre sí. Cada motor cuenta con kernels optimizados para formatos específicos. El formato adecuado es aquél para el cual el motor objetivo ofrece soporte nativo optimizado. Por ejemplo, llama.cpp emplea GGUF, ExLlamaV2 utiliza EXL2 y TensorRT-LLM opera con sus propios formatos compilados.