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

You don't pick an inference engine first. You pick a hardware strategy, a workload shape, and a serving model. The engine follows.

Translate: "No eliges primero un motor de inferencia. Primero eliges una estrategia de hardware, la forma de la carga de trabajo y un modelo de servicio. El motor viene después."

Then: "That is the most useful way to think about LLM inference engines." -> "Esa es la forma más útil de pensar en los motores de inferencia de LLM."

Series note: Preserve link text translate? "Part 1: GPU Memory Math for LLMs (2026 Edition)" -> "Parte 1: Matemáticas de memoria de GPU para LLMs (Edición 2026)" Keep URL same. Similarly for Part 2.

Those two pieces explain... -> "Esas dos piezas explican..."

This one explains... -> "Esta explica..."

Engines -> ## Motores

These tools serve different purposes... -> "Estas herramientas sirven para diferentes propósitos / ocupan diferentes capas"

List items:

Local portability -> Portabilidad local
Consumer CUDA -> CUDA para consumidores
Apple unified-memory workflows -> Flujos de trabajo de memoria unificada de Apple
Quantized inference -> Inferencia cuantizada
Production serving -> Servicio en producción
Distributed orchestration -> Orquestación distribuida
Vendor-optimized datacenter execution -> Ejecución optimizada por el fabricante en centros de datos

A useful mental model: -> Un modelo mental útil:

The inference engine is not "the model." -> "El motor de inferencia no es 'el modelo'."

It is the traffic cop... -> "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."

The best engine matches... -> "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."

The one-page decision guide -> ## Guía de decisión en una página

List items:

Laptop / edge / odd hardware → llama.cpp -> Portátil / edge / hardware extraño → llama.cpp
Mac-first workflows → MLX / MLX-LM -> Flujos de trabajo centrados en Mac → MLX / MLX-LM
Single RTX local inference → ExLlamaV2 -> Inferencia local con una RTX → ExLlamaV2
2-4+ NVIDIA / CUDA GPUs → ExLlamaV3 -> 2-4+ GPUs NVIDIA / CUDA → ExLlamaV3
General production serving → vLLM -> Servicio general en producción → vLLM
Long-context / MoE / routing → SGLang -> Contexto largo / MoE / enrutamiento → SGLang
NVIDIA max performance → TensorRT-LLM -> Máximo rendimiento NVIDIA → TensorRT-LLM
Cluster orchestration → NVIDIA Dynamo -> Orquestación de clústeres → NVIDIA Dynamo

The rest of this guide explains why. -> "El resto de esta guía explica por qué."

What an inference engine actually does -> ## Qué hace realmente un motor de inferencia

An inference engine loads weights... -> "Un motor de inferencia carga pesos, tokeniza la entrada, ejecuta el paso forward, muestrea tokens, mantiene el cache KV y transmite resultados. Los motores serios también manejan batching, planificación, cache de prefijos, cuantización, ejecución paralela, servicio de API, métricas y ejecución distribuida."

The workload has two phases: -> "La carga de trabajo tiene dos fases:"

Prefill reads the prompt... -> "Prefill lee el prompt y construye el cache KV inicial. Es intensivo en cómputo."

Decode generates one token at a time... -> "Decode genera un token a la vez, leyendo repetidamente los pesos y el cache 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."

That distinction explains almost everything: -> "Esa distinción explica casi todo:"

Short prompt, long answer: decode dominates → memory bandwidth and batching matter. -> Prompt corto, respuesta larga: decode domina → el ancho de banda de memoria y el batching importan.
Long prompt, short answer: prefill dominates → attention kernels and chunked prefill matter. -> Prompt largo, respuesta corta: prefill domina → los kernels de atención y el prefill fragmentado importan.
Many users: scheduler quality matters → continuous batching, cache paging, fairness. -> Muchos usuarios: la calidad del planificador importa → batching continuo, paginación de cache, equidad.
Long context: KV cache dominates → paged attention, KV quantization, offload. -> Contexto largo: el cache KV domina → atención paginada, cuantización KV, descarga.
MoE: expert routing dominates → expert parallelism, interconnect, grouped GEMMs. -> MoE: el enrutamiento de expertos domina → paralelismo de expertos, interconexión, GEMMs agrupados.
Multi-node: interconnect dominates → NVLink, RDMA, pipeline parallelism, disaggregation. -> Multi-nodo: la interconexión domina → NVLink, RDMA, paralelismo de pipeline, desagregación.

PagedAttention tackled... -> "PagedAttention abordó la fragmentación del cache KV. FlashAttention usó mosaicos conscientes de IO para reducir el tráfico de HBM (memoria de alto ancho de banda). La decodificación especulativa redacta tokens baratos y los verifica en paralelo. El tema recurrente: el rendimiento de inferencia es movimiento de memoria más planificación."

The real bottlenecks -> ## Los verdaderos cuellos de botella

Memory bandwidth, not just VRAM size. -> Ancho de banda de memoria, no solo tamaño de VRAM. Explanation: "VRAM determines fit. Bandwidth determines decode speed. Apple's M3 Ultra offers up to 819 GB/s unified-memory bandwidth. NVIDIA's H100 SXM lists 3.35 TB/s GPU memory bandwidth. Unified memory lets you fit models that would not fit in consumer VRAM. HBM lets you serve them faster when the model fits. Fit is not speed. Capacity is not bandwidth." Translate naturally: "La VRAM determina si cabe. 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 de GPU. La memoria unificada te permite cargar modelos que no cabrían en la VRAM de consumo. HBM te permite servirlos más rápido cuando el modelo cabe. Que quepa no es velocidad. Capacidad no es ancho de banda."

KV cache growth. -> Crecimiento del cache KV. Explanation: "KV cache grows with batch size and context length. Long-context workloads can run out of memory even when weights fit. PagedAttention partitions the KV cache into blocks, increasing utilization and supporting larger batches." -> "El cache 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 divide el cache KV en bloques, aumentando la utilización y soportando lotes más grandes."

Interconnect. -> Interconexión. Explanation: "The moment a model crosses GPU boundaries (multi-GPUs), you pay communication cost. Tensor parallelism needs frequent all-reduce collectives. Pipeline parallelism communicates at stage boundaries. Expert parallelism needs all-to-all traffic for MoE. vLLM's docs note that without NVLink, pipeline parallelism can outperform tensor parallelism." -> "En el momento en que un modelo cruza los límites de GPU (multi-GPU), pagas costo de comunicación. El paralelismo de tensor necesita colectivas all-reduce frecuentes. El paralelismo de pipeline se comunica en los límites de etapa. El paralelismo de expertos necesita tráfico all-to-all para MoE. Los documentos de vLLM señalan que sin NVLink, el paralelismo de pipeline puede superar al de tensor."

Scheduler quality. -> Calidad del planificador. Explanation: "A good scheduler decides which requests enter the batch, how prefill and decode share the accelerator, whether long prompts block short decodes, and how to avoid starvation. Supporting batching is not the same as behaving like a production-ready scheduler." -> "Un buen planificador decide qué solicitudes entran al lote, cómo comparten prefill y decode el acelerador, si los prompts largos bloquean los decodes cortos y cómo evitar la inanición. Soportar batching no es lo mismo que comportarse como un planificador listo para producción."

Runtime overhead. -> Sobrecarga en tiempo de ejecución. Explanation: "CUDA graphs, kernel fusion, sampling overhead, tokenizer overhead, HTTP overhead, LoRA switching, and structured decoding all matter. At high scale, the annoying 2% overheads form a union and demand attention (no punt intended)." -> "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, las molestas sobrecargas del 2% se unen y exigen atención (sin juego de palabras)."

The engine families -> ## Las familias de motores

There are four broad families: -> "Hay cuatro grandes familias:"

Portable local runtimes: llama.cpp, MLC LLM, ONNX Runtime GenAI, OpenVINO, Ollama-style tools. These care about "make it run here." -> "Runtimes locales portátiles: llama.cpp, MLC LLM, ONNX Runtime GenAI, OpenVINO, herramientas tipo Ollama. Se preocupan por 'hazlo funcionar aquí'."

Apple/unified-memory runtimes: MLX and MLX-LM. These care about "use big shared memory and Apple's stack well." -> "Runtimes de memoria unificada/Apple: MLX y MLX-LM. Se preocupan por 'usar bien la gran memoria compartida y el stack de Apple'."

Consumer CUDA quant engines: ExLlamaV2 and ExLlamaV3. These care about "make my 3090/4090/5090 box scream with low-bit weights." -> "Motores de cuantización CUDA para consumidores: ExLlamaV2 y ExLlamaV3. Se preocupan por 'hacer que mi caja 3090/4090/5090 vuele con pesos de baja precisión'."

Production serving engines: vLLM, SGLang, TensorRT-LLM, TGI, LMDeploy. These care about concurrent users, KV cache, batching, parallelism, observability, and cost per token. -> "Motores de servicio en producción: vLLM, SGLang, TensorRT-LLM, TGI, LMDeploy. Se preocupan por usuarios concurrentes, cache KV, batching, paralelismo, observabilidad y costo por token."

Then there are orchestration layers like Dynamo that sit above engines and coordinate fleets, disaggregated prefill/decode, routing, and autoscaling. -> "Luego están las capas de orquestación como Dynamo que se sitúan sobre los motores y coordinan flotas, prefill/decode desagregados, enrutamiento y autoescalado."

llama.cpp: the portability king -> ## llama.cpp: el rey de la portabilidad

llama.cpp is the answer when... -> "llama.cpp es la respuesta cuando el hardware es extraño, limitado, offline, intensivo en CPU, orientado al edge o no es un nodo ordenado de centro de datos NVIDIA."

It supports Apple Silicon via ARM NEON, Accelerate, and Metal; x86 via AVX/AVX2/AVX512/AMX; RISC-V; low-bit quantization; CUDA; AMD via HIP; MUSA; Vulkan; SYCL; and CPU+GPU hybrid offload. That is why llama.cpp owns the "just make it run" lane. -> "Soporta Apple Silicon vía ARM NEON, Accelerate y Metal; x86 vía 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.cpp domina el carril 'solo hazlo funcionar'."

The HTTP server is more capable than a "toy local runner". -> "El servidor HTTP es más capaz que un 'ejecutor local de juguete'."

llama-server provides... -> "llama-server proporciona rutas compatibles con OpenAI, compatibilidad con la API Anthropic Messages, reranking, batching continuo, soporte multimodal, restricciones de esquema JSON, llamada a funciones, decodificación especulativa y una interfaz web."

The critical limitation: llama.cpp is not for serious multi-node production serving. Its RPC backend is explicitly documented as proof-of-concept, fragile, and insecure. -> "La limitación crítica: llama.cpp no es para servicio de producción serio multi-nodo. Su backend RPC está explícitamente documentado como prueba de concepto, frágil e inseguro."

Verdict: Use llama.cpp when portability, offline operation, GGUF, or hybrid offload matter more than fleet-scale serving. -> "Veredicto: Usa llama.cpp cuando la portabilidad, la operación offline, GGUF o la descarga híbrida importen más que el servicio a escala de flota."

DO NOT use with Multi-GPUs -> "NO lo uses con múltiples GPUs" (translate link text: "múltiples GPUs")

MLX and MLX-LM: the Apple Silicon weapon -> ## MLX y MLX-LM: el arma de Apple Silicon

MLX is Apple's array framework... -> "MLX es el framework de arrays de Apple para Apple Silicon, y MLX-LM es el paquete LLM construido sobre él. Es un stack de ML centrado en Mac."

The key hardware fact is unified memory. -> "El hecho clave del hardware es la memoria unificada."

Apple Silicon gives the CPU and GPU direct access... -> "Apple Silicon le da a la CPU y GPU acceso directo al mismo grupo de memoria. Los arrays de MLX viven en memoria unificada, y eliges el dispositivo al ejecutar la operación en lugar de mover arrays entre espacios de memoria separados."

This changes the local inference tradeoff. -> "Esto cambia la compensación de la inferencia local."

On a discrete GPU system... -> "En un sistema de GPU discreta, la pregunta es '¿cabe en la VRAM?' En una Mac con serie M y gran memoria unificada, la pregunta se convierte en '¿cabe en la memoria, y puede el sistema de memoria alimentar la GPU lo suficientemente rápido?' Los modelos cuantizados grandes pueden caber en máquinas donde el mismo modelo sería imposible en una GPU de consumo de 24 GB."

However, it is also slower. -> "Sin embargo, también es más lento."

MLX-LM adds Hugging Face Hub integration, quantization, LoRA and full fine-tuning, distributed inference, and a large MLX Community model ecosystem. MLX is no longer Mac-only: it offers CUDA and CPU-only packages for Linux. Distributed communication supports MPI, Ring over TCP, JACCL for RDMA over Thunderbolt, and NCCL for CUDA. -> "MLX-LM añade integración con Hugging Face Hub, cuantización, LoRA y fine-tuning 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."

MLX-LM's server itself warns that it is not recommended for production because it only implements basic security checks. -> "El propio servidor de MLX-LM advierte que no se recomienda para producción porque solo implementa verificaciones de seguridad básicas."

Verdict: Use MLX for Mac-first ML and LLM workflows. For high-concurrency public serving, start with a real serving stack. -> "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 and V3: consumer CUDA, tuned and fast -> ## ExLlamaV2 y V3: CUDA para consumidores, afinado y rápido

ExLlamaV2 is the local CUDA quantization engine... -> "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, batching dinámico, cache de prompts, deduplicación de cache KV, generación por lotes, streaming 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."

Best fits: one RTX 3090/4090/5090 box, local coding assistant, local chat, EXL2 quantized models, and prosumer workstation use. -> "Mejores usos: una caja con RTX 3090/4090/5090, asistente de codificación local, chat local, modelos cuantizados EXL2 y uso en estaciones de trabajo prosumer."

ExLlamaV3 extends the philosophy toward multi-GPU and MoE-local inference. It adds the EXL3 quantization format based on QTIP, flexible tensor-parallel and expert-parallel inference for consumer hardware, an OpenAI-compatible server through TabbyAPI, continuous dynamic batching, and multimodal support. -> "ExLlamaV3 extiende la filosofía hacia inferencia multi-GPU y MoE local. Añade el formato de cuantización EXL3 basado en QTIP, inferencia flexible con paralelismo de tensor y de expertos para hardware de consumo, un servidor compatible con OpenAI a través de TabbyAPI, batching dinámico continuo y soporte multimodal."

V3 is compelling when you have 2-4+ consumer NVIDIA GPUs or want local MoE. Expect caveats: some models do not support tensor or expert parallelism in ExLlamaV3. -> "V3 es convincente cuando tienes 2-4+ GPUs NVIDIA de consumo o quieres MoE local. Espera advertencias: algunos modelos no soportan paralelismo de tensor o de expertos en ExLlamaV3."

Verdict: ExLlamaV2 is the enthusiast's local CUDA engine. ExLlamaV3 is the frontier for multi-GPU (2-4) local setups. Expect rougher edges for better capability. -> "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: the default open-source production server -> ## vLLM: el servidor de producción de código abierto por defecto

vLLM is the first engine... -> "vLLM es el primer motor que la mayoría de los equipos deberían evaluar para servir LLMs de código abierto en serio."

It offers PagedAttention-based KV memory management, continuous batching, chunked prefill, prefix caching, CUDA/HIP graphs, extensive quantization (FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ, AWQ, GGUF), optimized attention and GEMM/MoE kernels, speculative decoding, torch.compile, and disaggregated prefill/decode/encode. -> "Ofrece gestión de memoria KV basada en PagedAttention, batching continuo, prefill fragmentado, cache 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 prefill/decode/encode desagregados."

It is also flexible: tensor/pipeline/data/expert/context parallelism, streaming, structured outputs, tool calling, OpenAI-compatible and Anthropic Messages APIs, gRPC, multi-LoRA, and support for NVIDIA, AMD, x86/ARM/PowerPC CPUs, plus plugins for TPUs, Gaudi, Ascend, Apple Silicon, and more. -> "También es flexible: paralelismo de tensor/pipeline/datos/expertos/contexto, streaming, salidas estructuradas, llamada a herramientas, 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 más."

vLLM's docs note that multi-node deployments typically use Ray, and without NVLink, pipeline parallelism may beat tensor parallelism. The trap is assuming vLLM removes the need for systems thinking. You still need to tune batching, context length, GPU memory utilization, parallelism layout, and routing. vLLM gives you a very good engine; it still requires good System Design. -> "Los documentos de vLLM señalan que los despliegues multi-nodo suelen usar Ray, y sin NVLink, el paralelismo de pipeline puede superar al de tensor. La trampa es asumir que vLLM elimina la necesidad de pensar en sistemas. Aún necesitas ajustar el batching, la longitud del contexto, la utilización de memoria de GPU, el diseño de paralelismo y el enrutamiento. vLLM te da un motor muy bueno; aún requiere buen Diseño de Sistemas."

Verdict: If someone says "we need to serve open models in production," vLLM is the default starting point. -> "Veredicto: Si alguien dice 'necesitamos servir modelos abiertos en producción', vLLM es el punto de partida por defecto."

SGLang: vLLM's systems-brained cousin -> ## SGLang: el primo con mentalidad de sistemas de vLLM

SGLang is what you reach for when the serving workload is ugly: structured outputs, long context, MoE, disaggregation, and routing. -> "SGLang es a lo que recurres cuando la carga de trabajo de servicio es fea: salidas estructuradas, contexto largo, MoE, desagregación y enrutamiento."

It offers RadixAttention prefix caching, prefill-decode disaggregation, speculative decoding, continuous batching, paged attention, tensor/pipeline/expert/data parallelism, structured outputs, chunked prefill, and multi-LoRA batching. It supports NVIDIA, AMD, Intel Xeon, Google TPUs, Ascend NPUs, and more. -> "Ofrece cache de prefijos RadixAttention, desagregación prefill-decode, decodificación especulativa, batching continuo, atención paginada, paralelismo de tensor/pipeline/expertos/datos, salidas estructuradas, prefill fragmentado y batching multi-LoRA. Soporta NVIDIA, AMD, Intel Xeon, TPUs de Google, NPUs Ascend y más."

SGLang's differentiator is serving architecture. Its prefill-decode disaggregation separates compute-intensive prefill from memory-intensive decode into specialized instances, transferring KV cache between them. This prevents long prefill batches from interrupting decode and spiking token latency. -> "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 el cache KV entre ellas. Esto evita que los lotes de prefill largos interrumpan el decode y eleven la latencia de tokens."

Verdict: SGLang is for teams whose bottleneck is no longer "can we run the model?" but "can we run it under hostile traffic without torching latency, memory, and cost?" -> "Veredicto: SGLang es para equipos cuyo cuello de botella ya no es '¿podemos ejecutar el modelo?' sino '¿podemos ejecutarlo bajo tráfico hostil sin quemar latencia, memoria y costo?'"

TensorRT-LLM: maximum NVIDIA performance -> ## TensorRT-LLM: máximo rendimiento NVIDIA

TensorRT-LLM is the NVIDIA-max-performance stack. It is optimized, specialized, powerful, and not pretending to be portable. -> "TensorRT-LLM es el stack de máximo rendimiento NVIDIA. Está optimizado, especializado, es potente y no pretende ser portátil."

It provides Python APIs to build TensorRT engines with state-of-the-art optimizations, plus Python and C++ runtimes. It includes custom kernels for attention, GEMMs, and MoE; prefill-decode disaggregation, Wide Expert Parallelism, speculative decoding; and a high-level Python API integrated with NVIDIA Dynamo and Triton Inference Server. -> "Proporciona APIs de Python para construir motores TensorRT con optimizaciones de última generación, además de 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."

B200 GPUs can load FP4 weights with optimized kernels. H100 and later support FP8 quantization that can double performance and halve memory consumption versus 16-bit with minimal accuracy loss. -> "Las GPUs B200 pueden cargar pesos FP4 con kernels optimizados. Las 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."

Where it shines: H100/H200/B200/GB200/GB300-class fleets, NVIDIA-only datacenters, FP8/FP4 deployment, multi-node serving, and MoE at scale. Where it is awkward: AMD, Apple, or Intel portability; fast-changing experimental models; small local setups; and teams that need "works on everything." -> "Donde brilla: flotas de clase H100/H200/B200/GB200/GB300, centros de datos solo NVIDIA, despliegue FP8/FP4, servicio multi-nodo y MoE a escala. Donde es incómodo: portabilidad AMD, Apple o Intel; modelos experimentales que cambian rápido; configuraciones locales pequeñas; y equipos que necesitan 'funciona en todo'."

Verdict: If you are committed to NVIDIA and care about absolute performance, TensorRT-LLM belongs in the bake-off. You trade portability for performance. Tuned specialization but less features. -> "Veredicto: Si estás comprometido con NVIDIA y te importa el rendimiento absoluto, TensorRT-LLM merece estar en la comparativa. Cambias portabilidad por rendimiento. Especialización afinada pero menos funciones."

The rest of the field -> ## El resto del campo

TGI is Hugging Face's production server with tracing, metrics, tensor parallelism, and continuous batching. Use it when HF integration and simplicity matter. -> "TGI es el servidor de producción de Hugging Face con trazado, métricas, paralelismo de tensor y batching continuo. Úsalo cuando la integración con HF y la simplicidad importen."

MLC LLM is the compiler-first universal deployment engine with OpenAI-compatible APIs across REST, Python, JavaScript, iOS, and Android. Best for "ship LLMs everywhere," especially browser, mobile, and native apps. -> "MLC LLM es el motor de despliegue universal centrado en 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 implements the full generative loop over ONNX Runtime and powers Foundry Local, Windows ML, and the VS Code AI Toolkit. It supports CPU, CUDA, DirectML, TensorRT-RTX, OpenVINO, QNN, WebGPU, and AMD GPU. Best for app deployment and ONNX workflows. -> "ONNX Runtime GenAI implementa el bucle generativo completo sobre ONNX Runtime y potencia Foundry Local, Windows ML y el VS Code AI Toolkit. Soporta CPU, CUDA, DirectML, TensorRT-RTX, OpenVINO, QNN, WebGPU y GPU AMD. Mejor para despliegue de aplicaciones y flujos de trabajo ONNX."

OpenVINO GenAI is the Intel-optimized story for Xeon CPUs, Arc GPUs, Core Ultra, and NPUs. It offers OpenAI-compatible serving with continuous batching and paged attention. Best for Intel hardware. -> "OpenVINO GenAI es la historia optimizada por Intel para CPUs Xeon, GPUs Arc, Core Ultra y NPUs. Ofrece servicio compatible con OpenAI con batching continuo y atención paginada. Mejor para hardware Intel."

LMDeploy is a CUDA-focused toolkit with TurboMind for performance and PyTorch for accessibility. Most interesting for CUDA users who want an alternative to vLLM/SGLang/TensorRT-LLM. -> "LMDeploy es un conjunto de herramientas centrado en CUDA con TurboMind para rendimiento y PyTorch para accesibilidad. Más interesante para usuarios CUDA que quieren una alternativa a vLLM/SGLang/TensorRT-LLM."

NVIDIA Dynamo is a distributed orchestration layer above engines like vLLM, SGLang, and TensorRT-LLM, supporting disaggregation, intelligent routing, and multi-tier KV caching. Use it when single-engine serving is no longer enough. -> "NVIDIA Dynamo es una capa de orquestación distribuida sobre motores como vLLM, SGLang y TensorRT-LLM, que soporta desagregación, enrutamiento inteligente y cache KV de múltiples niveles. Úsalo cuando el servicio con un solo motor ya no sea suficiente."

Note: DO NOT USE Ollama. -> "Nota: NO USES Ollama."

Hardware strategy recipes -> ## Recetas de estrategia de hardware

CPU-only server: llama.cpp first. OpenVINO for Intel Xeon. ONNX Runtime GenAI for app/ONNX deployment. -> "Servidor solo CPU: llama.cpp primero. OpenVINO para Intel Xeon. ONNX Runtime GenAI para despliegue de aplicaciones/ONNX."

MacBook / Mac Studio: MLX / MLX-LM for Mac-native workflows. llama.cpp for GGUF portability. -> "MacBook / Mac Studio: MLX / MLX-LM para flujos de trabajo nativos de Mac. llama.cpp para portabilidad GGUF."

Single RTX 3090 / 4090 / 5090: ExLlamaV2 for EXL2 local inference. llama.cpp for GGUF or portability. vLLM if serving multiple users. -> "Una RTX 3090 / 4090 / 5090: ExLlamaV2 para inferencia local EXL2. llama.cpp para GGUF o portabilidad. vLLM si sirves a múltiples usuarios."

Dual or quad consumer RTX box: ExLlamaV3 for multi-GPU quantized inference or MoE. vLLM if serving behavior matters. SGLang if testing routing or long-context patterns. -> "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 pruebas enrutamiento o patrones de contexto largo."

8×H100 / H200 node: Start with vLLM or SGLang. Benchmark TensorRT-LLM if NVIDIA-only and performance justifies tuning. Use Dynamo when multi-node orchestration becomes necessary. -> "Nodo 8×H100 / H200: Comienza con vLLM o SGLang. Evalúa TensorRT-LLM si es solo NVIDIA y el rendimiento justifica el ajuste. Usa Dynamo cuando la orquestación multi-nodo sea necesaria."

B200 / GB200 / GB300-class infrastructure: Benchmark TensorRT-LLM, SGLang, and vLLM. Add Dynamo for fleet-level orchestration, KV-aware routing, and autoscaling. -> "Infraestructura de clase B200 / GB200 / GB300: Evalúa TensorRT-LLM, SGLang y vLLM. Añade Dynamo para orquestación a nivel de flota, enrutamiento consciente de KV y autoescalado."

AMD MI300 / MI325 / MI350 / MI355: Start with vLLM or SGLang on ROCm. Avoid assuming NVIDIA benchmarks transfer cleanly. -> "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 or OpenVINO Model Server. ONNX Runtime GenAI if app embedding matters. -> "Intel Xeon / Core Ultra / Arc: OpenVINO GenAI o OpenVINO Model Server. ONNX Runtime GenAI si la incrustación en aplicaciones importa."

Browser, mobile, app-native: MLC LLM / WebLLM or ONNX Runtime GenAI. -> "Navegador, móvil, nativo de aplicación: MLC LLM / WebLLM o ONNX Runtime GenAI."

Benchmarking: what to measure -> ## Benchmarking: qué medir

Bad benchmark: "I got 180 tok/s." -> "Benchmark malo: 'Obtuve 180 tok/s'."

Good benchmark includes: -> "Benchmark bueno incluye:"

Model: exact model, architecture, parameter count, active MoE params. -> "Modelo: modelo exacto, arquitectura, número de parámetros, parámetros MoE activos."

Weights: dtype, quant format, group size, calibration. -> "Pesos: dtype, formato de cuantización, tamaño de grupo, calibración."

Engine: version, commit, backend, flags. -> "Motor: versión, commit, backend, flags."

Hardware: GPU SKU, memory capacity, bandwidth, interconnect, CPU, RAM. -> "Hardware: SKU de GPU, capacidad de memoria, ancho de banda, interconexión, CPU, RAM."

Workload: input/output length distributions, concurrency, streaming, shared prefixes, structured output. -> "Carga de trabajo: distribuciones de longitud de entrada/salida, concurrencia, streaming, prefijos compartidos, salida estructurada."

Metrics: TTFT, TPOT, end-to-end latency, p50/p95/p99, tokens per second, requests per second, GPU memory usage, KV cache hit rate, prefill throughput, decode throughput, cost per 1M tokens. -> "Métricas: TTFT, TPOT, latencia extremo a extremo, p50/p95/p99, tokens por segundo, solicitudes por segundo, uso de memoria de GPU, tasa de aciertos de cache KV, rendimiento de prefill, rendimiento de decode, costo por 1M tokens."

Benchmarking Rules: -> "Reglas de Benchmarking:"

Never compare engines using only single-user tokens per second. -> Nunca compares motores usando solo tokens por segundo de un solo usuario.
Test your actual prompt and output distribution. -> Prueba tu distribución real de prompt y salida.
Test with realistic concurrency. -> Prueba con concurrencia realista.
Separate prefill from decode. -> Separa prefill de decode.
Track p95 and p99, not only averages. -> Rastrea p95 y p99, no solo promedios.
Measure memory headroom at target context length. -> Mide el margen de memoria en la longitud de contexto objetivo.
Test cache reuse if your app has repeated prefixes. -> Prueba la reutilización de cache si tu aplicación tiene prefijos repetidos.
Benchmark structured output separately; grammar adds overhead. -> Evalúa la salida estructurada por separado; la gramática añade sobrecarga.
Benchmark LoRA and multi-LoRA separately. -> Evalúa LoRA y multi-LoRA por separado.
Re-test after driver, CUDA, ROCm, model, or engine upgrades. -> Vuelve a probar después de actualizaciones de driver, CUDA, ROCm, modelo o motor.

Common mistakes -> ## Errores comunes

Choosing by VRAM capacity alone. -> Elegir solo por capacidad de VRAM. (then explanation) VRAM determines fit. Bandwidth and scheduler determine speed. A large unified-memory machine can fit huge models, but an H100 decodes faster when the model fits due to much higher HBM bandwidth. -> "La VRAM determina si cabe. El ancho de banda y el planificador determinan la velocidad. Una máquina con gran memoria unificada puede cargar modelos enormes, pero un H100 decodifica más rápido cuando el modelo cabe debido a un ancho de banda HBM mucho mayor."

Using tensor parallelism on weak interconnect. -> Usar paralelismo de tensor en interconexión débil. Without NVLink or NVSwitch, test pipeline parallelism. vLLM's docs call this out for L40S-like setups. -> "Sin NVLink o NVSwitch, prueba el paralelismo de pipeline. Los documentos de vLLM lo señalan para configuraciones similares a L40S."

Ignoring KV cache. -> Ignorar el cache KV. Long context and concurrency can make KV cache the limiting factor. PagedAttention, prefix caching, KV quantization, and disaggregation are not optional at scale. -> "El contexto largo y la concurrencia pueden hacer que el cache KV sea el factor limitante. PagedAttention, cache de prefijos, cuantización KV y desagregación no son opcionales a escala."

Treating local engines as production servers. -> Tratar los motores locales como servidores de producción. llama.cpp server is capable. MLX-LM server is convenient. Ollama is pleasant yet SHOULD NOT BE USED. -> "El servidor de llama.cpp es capaz. El servidor de MLX-LM es conveniente. Ollama es agradable pero NO DEBE USARSE."

However, production means security, observability, backpressure, routing, autoscaling, and SLA behavior. MLX-LM itself warns that its server is not recommended for production. -> "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."

Assuming every quantization format is portable. -> Asumir que todos los formatos de cuantización son portátiles. GGUF, EXL2, EXL3, AWQ, GPTQ, FP8, FP4, MLX formats, and ONNX are not interchangeable. The right format is the one your engine has optimized kernels for. -> "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."

Ignoring model architecture. -> Ignorar la arquitectura del modelo. Dense models, MoE, hybrid attention, multimodal models, and long-context variants stress different parts of the engine. Broad support does not mean every optimization works equally. -> "Los modelos densos, MoE, atención híbrida, modelos multimodales y variantes de contexto largo estresan diferentes partes del motor. El soporte amplio no significa que todas las optimizaciones funcionen por igual."

Trusting benchmark charts without workload shape. -> Confiar en gráficos de benchmark sin la forma de la carga de trabajo. A chart for Llama 3.1 8B at 1K input / 128 output says little about a coding agent with 80K context running on Qwen 3.6 27B / Gemma 4 26B-A4B, or a RAG service with 500 concurrent users. -> "Un gráfico para Llama 3.1 8B con entrada de 1K / salida de 128 dice poco sobre un agente de codificación con contexto de 80K ejecutándose en Qwen 3.6 27B / Gemma 4 26B-A4B, o un servicio RAG con 500 usuarios concurrentes."

The opinionated final map -> ## El mapa final con opinión

Local AI user: LM Studio or Harbor for convenience. llama.cpp for control. MLX on Mac. ExLlamaV2/V3 for CUDA local performance. -> "Usuario de IA local: LM Studio o Harbor por conveniencia. llama.cpp para control. MLX en Mac. ExLlamaV2/V3 para rendimiento CUDA local."

Building a local agent: Any should work, but given what most people use; llama.cpp for portability. MLX if users are on Apple Silicon. vLLM if simulating production serving locally. -> "Construyendo un agente local: Cualquiera debería funcionar, pero dado lo que la mayoría usa; llama.cpp para portabilidad. MLX si los usuarios están en Apple Silicon. vLLM si simulas servicio de producción localmente."

Serving an internal team: Start with vLLM. Use SGLang if structured outputs, long context, multi-LoRA, MoE, or routing matter. -> "Sirviendo a un equipo interno: Comienza con vLLM. Usa SGLang si las salidas estructuradas, el contexto largo, multi-LoRA, MoE o el enrutamiento importan."

Serving customers at scale: Benchmark vLLM, SGLang, and TensorRT-LLM. If routing and disaggregation matter, SGLang and Dynamo deserve attention. -> "Sirviendo a clientes a escala: Evalúa vLLM, SGLang y TensorRT-LLM. Si el enrutamiento y la desagregación importan, SGLang y Dynamo merecen atención."

NVIDIA datacenter: TensorRT-LLM for max performance. vLLM for flexibility. SGLang for complex serving. Dynamo for fleet orchestration. -> "Centro de datos NVIDIA: TensorRT-LLM para máximo rendimiento. vLLM para flexibilidad. SGLang para servicio complejo. Dynamo para orquestación de flotas."

Apple Silicon: MLX for native development. llama.cpp for GGUF. Unified memory is a capacity superpower with bandwidth tradeoffs, not HBM. -> "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, app, browser, or Windows-native: llama.cpp, MLC LLM, ONNX Runtime GenAI, or OpenVINO, depending on stack. -> "Edge, aplicación, navegador o nativo de Windows: llama.cpp, MLC LLM, ONNX Runtime GenAI u OpenVINO, dependiendo del stack."

Final principle -> ## Principio final

Inference Engines have consequences. -> Los motores de inferencia tienen consecuencias.

Pick the engine after answering these: -> Elige el motor después de responder a estas preguntas:

What hardware do I actually have? -> ¿Qué hardware tengo realmente?
Does the model fit in fast memory, or only in system/unified memory? -> ¿El modelo cabe en memoria rápida, o solo en memoria de sistema/unificada?
Is decode or prefill the bottleneck? -> ¿Es decode o prefill el cuello de botella?
What context length and concurrency matter? -> ¿Qué longitud de contexto y concurrencia importan?
Are prompts shared enough for prefix caching? -> ¿Los prompts se comparten lo suficiente para el cache de prefijos?
Is the model dense, MoE, multimodal, or hybrid? -> ¿El modelo es denso, MoE, multimodal o híbrido?
Do I need local convenience, production serving, or fleet orchestration? -> ¿Necesito conveniencia local, servicio en producción u orquestación de flotas?
What quantization format has optimized kernels on my target engine? -> ¿Qué formato de cuantización tiene kernels optimizados en mi motor objetivo?
Is my interconnect PCIe, NVLink, NVSwitch, Ethernet, RDMA, or Thunderbolt? -> ¿Mi interconexión es PCIe, NVLink, NVSwitch, Ethernet, RDMA o Thunderbolt?
Am I optimizing latency, throughput, cost, privacy, portability, or developer speed? -> ¿Estoy optimizando latencia, rendimiento, costo, privacidad, portabilidad o velocidad de desarrollo?

The engine follows the answers. -> El motor sigue las respuestas.

Until next time. -> Hasta la próxima.

-Ahmad -> -Ahmad

We must also handle any <code-segment> tags. In this text, there are none visible. The only tags are <blockquote>, <p>, and <payload-block>. We need to ensure we preserve all payload-block tags exactly.

Note: The text has a link in "DO NOT use with Multi-GPUs" - we translated the link text to "múltiples GPUs". Also there is a link to Harbor: "Harbor" -> we keep URL, translate text to "Harbor" (proper noun, keep as is? Actually Harbor is a project name, so keep as Harbor. But the text says "Harbor" so we keep link text as "Harbor" (English name). That's fine.

Also note: In the "Common mistakes" section, there is a line: "Ollama is pleasant yet SHOULD NOT BE USED." We translated as "Ollama es agradable pero NO DEBE USARSE." (keep the emphasis)

Finally, ensure all markdown formatting: headings with ##, bold with **, etc. We must preserve them. For example, in "DO NOT use with [Multi-GPUs]..." we have a bold "DO NOT" - we translated as "NO lo uses" (no bold). But in original it's "DO NOT use" - we can keep the emphasis with bold or caps. In Spanish, "NO lo uses" is fine without bold. But to match, maybe use bold? The instruction says preserve formatting, but if we change text, we can adapt. I'll keep "NO USES" in all caps as in original note. For "DO NOT USE Ollama." we translated "NO USES Ollama." (all caps). That's fine.

Now, we need to output only the translated text, no explanations. Let's produce the full translation with all tags preserved.</think><blockquote>

<p>No eliges primero un motor de inferencia. Primero eliges una estrategia de hardware, la forma de la carga de trabajo y un modelo de servicio. El motor viene después.</p>

</blockquote>

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 autoalojados / IA local.

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 para consumidores
Flujos de trabajo de memoria unificada de Apple
Inferencia cuantizada
Servicio en producción
Orquestación distribuida
Ejecución optimizada por el fabricante en centros de datos

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.

Guía de decisión en una página

Portátil / edge / hardware extraño → llama.cpp
Flujos de trabajo centrados en Mac → MLX / MLX-LM
Inferencia local con una RTX → ExLlamaV2
2-4+ GPUs NVIDIA / CUDA → ExLlamaV3
Servicio general en producción → vLLM
Contexto largo / MoE / enrutamiento → SGLang
Máximo rendimiento 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 paso forward, muestrea tokens, mantiene el caché KV y transmite resultados. Los motores serios también manejan batching, planificación, 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 el caché KV inicial. Es intensivo en cómputo.

Decode genera un token a la vez, leyendo repetidamente los pesos y el 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 → el ancho de banda de memoria y el batching importan.
Prompt largo, respuesta corta: prefill domina → los kernels de atención y el prefill fragmentado importan.
Muchos usuarios: la calidad del planificador importa → batching continuo, paginación de caché, equidad.
Contexto largo: el caché KV domina → atención paginada, cuantización 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 pipeline, desagregación.

PagedAttention abordó la fragmentación del caché KV. FlashAttention usó mosaicos conscientes de IO para reducir el tráfico de HBM (memoria de alto ancho de banda). La decodificación especulativa redacta tokens baratos y los verifica en paralelo. El tema recurrente: el rendimiento de inferencia es movimiento de memoria más planificación.

Los verdaderos cuellos de botella

Ancho de banda de memoria, no solo tamaño de VRAM. La VRAM determina si cabe. 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 de GPU. La memoria unificada te permite cargar modelos que no cabrían en la VRAM de consumo. HBM te permite servirlos más rápido cuando el modelo cabe. Que quepa no es velocidad. Capacidad no es ancho de banda.

Crecimiento del caché KV. El 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 divide el caché KV en bloques, aumentando la utilización y soportando lotes más grandes.

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

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

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, las molestas sobrecargas del 2% se unen y exigen atención (sin juego de palabras).

Las familias de motores

Hay cuatro grandes familias:

Runtimes locales portátiles: llama.cpp, MLC LLM, ONNX Runtime GenAI, OpenVINO, herramientas tipo Ollama. Se preocupan por "hazlo funcionar aquí".

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

Motores de cuantización CUDA para consumidores: ExLlamaV2 y ExLlamaV3. Se preocupan por "hacer que mi caja 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, batching, 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, prefill/decode desagregados, enrutamiento y autoescalado.

llama.cpp: el rey de la portabilidad

llama.cpp es la respuesta cuando el hardware es extraño, limitado, offline, intensivo en CPU, orientado al edge o no es un nodo ordenado de centro de datos NVIDIA.

Soporta Apple Silicon vía ARM NEON, Accelerate y Metal; x86 vía 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.cpp domina el carril "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 Anthropic Messages, reranking, batching 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 de producción serio multi-nodo. 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 offline, GGUF o la descarga híbrida importen más que el servicio a escala de flota.

NO lo uses con múltiples GPUs

MLX y MLX-LM: el arma de Apple Silicon

MLX es el framework de arrays de Apple para Apple Silicon, y MLX-LM es el paquete 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 GPU acceso directo al mismo grupo de memoria. Los arrays de MLX viven en memoria unificada, y eliges el dispositivo al ejecutar la operación en lugar de mover arrays entre espacios de memoria separados.

Esto cambia la compensación de la inferencia local. En un sistema de GPU discreta, la pregunta es "¿cabe en la VRAM?" En una Mac con serie M y gran memoria unificada, la pregunta se convierte en "¿cabe en la memoria, y puede el sistema de memoria alimentar la GPU lo suficientemente rápido?" Los modelos cuantizados grandes 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 añade integración con Hugging Face Hub, cuantización, LoRA y fine-tuning 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 para consumidores, 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, batching dinámico, caché de prompts, deduplicación de caché KV, generación por lotes, streaming 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 usos: una caja con RTX 3090/4090/5090, asistente de codificación local, chat local, modelos cuantizados EXL2 y uso en estaciones de trabajo prosumer.

ExLlamaV3 extiende la filosofía hacia inferencia multi-GPU y MoE local. Añade el formato de cuantización EXL3 basado en QTIP, inferencia flexible con paralelismo de tensor y de expertos para hardware de consumo, un servidor compatible con OpenAI a través de TabbyAPI, batching dinámico continuo 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 tensor 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 de código abierto por defecto

vLLM es el primer motor que la mayoría de los equipos deberían evaluar para servir LLMs de código abierto en serio.

Ofrece gestión de memoria KV basada en PagedAttention, batching continuo, prefill fragmentado, 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 prefill/decode/encode desagregados.

También es flexible: paralelismo de tensor/pipeline/datos/expertos/contexto, streaming, salidas estructuradas, llamada a herramientas, 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 más.

Los documentos de vLLM señalan que los despliegues multi-nodo suelen usar Ray, y sin NVLink, el paralelismo de pipeline puede superar al de tensor. La trampa es asumir que vLLM elimina la necesidad de pensar en sistemas. Aún necesitas ajustar el batching, la longitud del contexto, la utilización de memoria de GPU, el diseño de 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 caché de prefijos RadixAttention, desagregación prefill-decode, decodificación especulativa, batching continuo, atención paginada, paralelismo de tensor/pipeline/expertos/datos, salidas estructuradas, prefill fragmentado y batching 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 el caché KV entre ellas. Esto evita que los lotes de prefill largos interrumpan el decode y eleven 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 quemar latencia, memoria y costo?"

TensorRT-LLM: máximo rendimiento NVIDIA

TensorRT-LLM es el stack de máximo rendimiento 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 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. Las 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, despliegue FP8/FP4, servicio multi-nodo y MoE a escala. Donde es incómodo: portabilidad AMD, Apple o Intel; modelos experimentales que cambian rápido; 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. Cambias portabilidad por rendimiento. Especialización afinada pero menos funciones.

El resto del campo

TGI es el servidor de producción de Hugging Face con trazado, métricas, paralelismo de tensor y batching continuo. Úsalo cuando la integración con HF y la simplicidad importen.

MLC LLM es el motor de despliegue universal centrado en 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 VS Code AI Toolkit. Soporta CPU, CUDA, DirectML, TensorRT-RTX, OpenVINO, QNN, WebGPU y GPU AMD. Mejor para despliegue 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 batching continuo y atención paginada. Mejor para hardware Intel.

LMDeploy es un conjunto de herramientas centrado en CUDA con TurboMind para rendimiento y PyTorch para accesibilidad. Más interesante para usuarios 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 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 despliegue de aplicaciones/ONNX.

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

Una RTX 3090 / 4090 / 5090: ExLlamaV2 para inferencia local EXL2. llama.cpp para GGUF o portabilidad. vLLM si sirves 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 pruebas enrutamiento o patrones de contexto largo.

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

Infraestructura de clase B200 / GB200 / GB300: Evalúa TensorRT-LLM, SGLang y vLLM. Añade Dynamo para orquestación a nivel de flota, enrutamiento consciente 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, nativo de aplicación: MLC LLM / WebLLM o ONNX Runtime GenAI.

Benchmarking: qué medir

Benchmark malo: "Obtuve 180 tok/s."

Benchmark bueno incluye:

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

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

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

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

Carga de trabajo: distribuciones de longitud de entrada/salida, concurrencia, streaming, prefijos compartidos, salida estructurada.

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

Reglas de Benchmarking:

Nunca compares motores usando solo tokens por segundo de un solo usuario.
Prueba tu distribución real de prompt y salida.
Prueba con concurrencia realista.
Separa prefill de decode.
Rastrea p95 y p99, no solo promedios.
Mide el margen de memoria en la longitud de contexto objetivo.
Prueba la reutilización de caché si tu aplicación tiene prefijos repetidos.
Evalúa la salida estructurada por separado; la gramática añade sobrecarga.
Evalúa LoRA y multi-LoRA por separado.
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 si cabe. El ancho de banda y el planificador determinan la velocidad. Una máquina con gran memoria unificada puede cargar 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 tensor en interconexión débil. Sin NVLink o NVSwitch, prueba el paralelismo de pipeline. Los documentos de vLLM lo señalan para configuraciones similares a L40S.

Ignorar el caché KV. El contexto largo y la concurrencia pueden hacer que el caché KV sea el factor limitante. PagedAttention, caché de prefijos, cuantización KV y 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 todos los formatos de cuantización son portátiles. 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. El soporte amplio no significa que todas las optimizaciones funcionen por igual.

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

El mapa final con opinión

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

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

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

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

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

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 a estas preguntas:

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

El motor sigue las respuestas.

Hasta la próxima.

-Ahmad