vLLM se ha convertido en una de las piezas más conocidas para servir modelos de lenguaje a gran escala, pero hablar de «vLLM» como si ofreciera exactamente la misma arquitectura en cualquier hardware puede llevar a confusión. En NVIDIA, AMD o determinadas plataformas aceleradas, el proyecto se apoya en backends y kernels específicos para cada hardware. En Apple Silicon, vLLM-Metal utiliza MLX como backend de cálculo, mientras que proyectos como vllm-mlx siguen una estrategia independiente basada directamente en MLX. El objetivo es parecido, pero las capas que hacen posible la inferencia son diferentes.
Las claves de vLLM, vLLM-Metal y vllm-mlx en 30 segundos
- vLLM nació alrededor de una arquitectura de serving que aprovecha batching continuo, gestión paginada de la memoria KV y atención optimizada.
- vLLM-Metal conserva partes importantes de vLLM, pero utiliza MLX para ejecutar los modelos sobre Apple Silicon.
vllm-mlxes un proyecto independiente que construye un servidor de inferencia nativo sobre MLX.- En Apple Silicon, el modelo de memoria unificada cambia algunas decisiones respecto a una GPU NVIDIA con memoria dedicada.
- La compatibilidad, los kernels disponibles y el formato de los modelos pueden ser tan importantes como el propio motor de serving.
La distinción resulta especialmente útil ahora que los Mac con Apple Silicon se utilizan cada vez más para ejecutar modelos localmente. A primera vista, una máquina con una GPU NVIDIA y un Mac Studio pueden ejecutar el mismo modelo y exponer una API compatible con OpenAI. Pero que la API sea la misma no significa que el camino que recorre cada token hasta convertirse en una respuesta sea idéntico.
De hecho, el propio proyecto vLLM mantiene una separación explícita entre plataformas. Su documentación actual contempla NVIDIA CUDA, AMD ROCm, Intel XPU y Apple Silicon mediante vLLM-Metal, entre otras opciones. En el caso de Apple, la documentación especifica que vLLM-Metal utiliza MLX en lugar de PyTorch como backend de cálculo.
vLLM está pensado alrededor del serving, no solo de ejecutar un modelo
La principal diferencia de vLLM frente a una implementación básica de inferencia es que intenta resolver también el problema de servir muchos modelos o muchas peticiones de forma eficiente.
Entre sus piezas están el planificador de peticiones, el batching continuo y la gestión paginada de la caché KV, la memoria que el modelo necesita para conservar información de los tokens ya procesados durante una generación.
Eso importa especialmente cuando varias personas utilizan simultáneamente un mismo modelo. El objetivo no consiste simplemente en conseguir que una petición individual termine rápido, sino en utilizar el hardware de forma eficiente mientras llegan nuevas solicitudes.
En una GPU NVIDIA, este trabajo se apoya en una larga cadena de software y kernels optimizados para CUDA. La plataforma de vLLM incluye soporte específico para NVIDIA y también implementaciones para AMD mediante ROCm.
Por eso, cuando se habla de «vLLM sobre NVIDIA», buena parte del rendimiento depende de todo lo que existe por debajo del servidor: CUDA, kernels especializados, operaciones fusionadas, gestión de memoria y las capacidades concretas de la GPU.
El servidor es solo una parte de la historia.
vLLM-Metal conserva vLLM, pero cambia el motor de cálculo
Aquí es donde aparece vLLM-Metal.
El proyecto se define como un plugin de hardware mantenido por la comunidad para ejecutar vLLM sobre Apple Silicon. Su arquitectura actual es bastante explícita: el servidor de vLLM aporta la API, el planificador y el gestor de bloques paginados; mlx_lm proporciona las capas de los modelos y vLLM-Metal se encarga de la ruta de atención adaptada al hardware de Apple.
Eso significa que la idea del diagrama compartido es correcta, pero necesita un pequeño matiz.
No sería simplemente:
Apple Silicon → MLX + PyTorch → vLLM-Metal
El proyecto actual indica que MLX es el backend de cálculo principal, mientras que vLLM aporta la infraestructura de serving. La documentación oficial de vLLM también recalca esta diferencia respecto a las instalaciones convencionales.
Y el desarrollo está avanzando con bastante rapidez. vLLM-Metal incorporó en 2026 un kernel Metal paginado de longitud variable para atención y posteriormente añadió optimizaciones específicas para las unidades NAX de los chips M5 durante el prefill. El proyecto también mantiene una matriz propia de modelos compatibles.
Eso cambia la lectura de Apple Silicon. No se trata simplemente de ejecutar una versión lenta de vLLM pensada originalmente para NVIDIA. Hay código específico que intenta aprovechar las características de la plataforma.
Y luego está vllm-mlx, que toma otro camino
vllm-mlx es un proyecto diferente.
Su objetivo es ofrecer un servidor de inferencia para Apple Silicon construido directamente alrededor de MLX. Proporciona batching continuo, caché KV paginada, caché de prefijos y APIs compatibles con OpenAI y Anthropic, entre otras funciones.
Aquí aparece una diferencia arquitectónica interesante.
Mientras vLLM-Metal reutiliza componentes del proyecto vLLM y conecta esos componentes con MLX, vllm-mlx construye su propia implementación de serving alrededor del ecosistema MLX.
Los dos pueden terminar ofreciendo una experiencia bastante parecida para el usuario:
POST /v1/chat/completions
↓
modelo
↓
respuestaPero debajo pueden estar haciendo cosas diferentes.
Es una situación parecida a la que existe entre dos motores que ofrecen la misma API. Desde la aplicación puede parecer que son intercambiables. Cuando se llega a la memoria, los kernels, la caché, la cuantización o la planificación de peticiones, las diferencias aparecen rápidamente.
El verdadero cuello de botella puede estar en los kernels
Aquí hay una parte especialmente interesante para entender por qué una implementación de IA puede rendir de forma muy diferente sobre un hardware u otro.
Un modelo de lenguaje no ejecuta una única operación. Cada token pasa por una enorme cantidad de operaciones matemáticas, y el rendimiento final depende de que esas operaciones tengan implementaciones eficientes para el hardware concreto.
En NVIDIA existe un ecosistema de kernels CUDA extremadamente desarrollado. En Apple Silicon, MLX proporciona sus propias primitivas y kernels Metal.
vLLM-Metal está precisamente desarrollando kernels específicos para determinadas partes del recorrido. Su documentación destaca, por ejemplo, la atención paginada, las rutas de prefill y decode y optimizaciones para determinados modelos híbridos.
Esto hace que una comparación del tipo «el mismo modelo funciona a X tokens por segundo en un Mac y a Y en una NVIDIA» tenga poco valor si no se especifican versión del motor, cuantización, modelo, longitud de contexto, número de peticiones simultáneas y hardware.
Dos sistemas pueden ejecutar el mismo modelo y estar haciendo un trabajo bastante diferente por debajo.
La madurez de los kernels también puede convertirse en un límite. En MLX existen operaciones optimizadas para sus formatos y arquitecturas, pero la cobertura de modelos y operaciones continúa evolucionando. La propia matriz de vLLM-Metal diferencia entre funcionalidades soportadas, experimentales y no soportadas.
La cuantización introduce otra diferencia importante
Hay otro detalle que suele quedar oculto cuando se comparan motores: cómo se representa el modelo cuantizado.
En el ecosistema de Apple, MLX tiene sus propios formatos y parámetros de cuantización. mlx-lm permite convertir modelos de Hugging Face a formatos MLX y ofrece diferentes modos, incluidos affine, MXFP4, NVFP4 y MXFP8. También incorpora conversiones desde determinados formatos como AWQ y GPTQ hacia representaciones que MLX pueda utilizar.
Por tanto, decir que «MLX solo acepta su propia cuantización» sería demasiado tajante. Existe compatibilidad y conversión con otros formatos.
Pero sí hay una consecuencia práctica: no todos los artefactos cuantizados del ecosistema de IA son intercambiables directamente entre motores.
Esto puede importar mucho cuando se construye infraestructura alrededor de un modelo. Elegir un runtime no es únicamente elegir qué API utilizar. También puede condicionar qué modelos, checkpoints y formatos de cuantización resultan más cómodos de desplegar.
El propio ecosistema MLX continúa trabajando en compatibilidad con formatos externos. Por ejemplo, mlx-lm mantiene soporte de conversión para AWQ y GPTQ, mientras existen solicitudes abiertas para ampliar la compatibilidad con determinadas cuantizaciones de GGUF de menos de 3 bits.
Apple Silicon cambia también la conversación sobre memoria
La otra gran diferencia está en la arquitectura de memoria.
Una GPU NVIDIA dedicada suele trabajar con su propia memoria de vídeo, mientras que Apple Silicon utiliza memoria unificada compartida entre CPU y GPU. Esto cambia cómo se plantea el despliegue de modelos grandes en un Mac.
Para determinadas cargas locales, disponer de mucha memoria unificada permite cargar modelos que resultarían difíciles de ejecutar en una GPU de consumo con una cantidad de VRAM mucho menor.
Pero tampoco significa que la memoria unificada convierta automáticamente un Mac en un sustituto de una infraestructura de GPU para centros de datos. El rendimiento depende del ancho de banda, las unidades de cálculo, los kernels, la arquitectura del modelo y el patrón de acceso a memoria, además de la concurrencia.
Por eso MLX resulta especialmente interesante: está diseñado teniendo en cuenta las características de Apple Silicon desde el principio.
Y vLLM-Metal intenta combinar esa ejecución específica con una infraestructura de serving que ya conoce buena parte de las necesidades de producción.
No hay un ganador universal: depende del lugar donde se ejecuta
La comparación más útil, por tanto, no es «vLLM contra MLX».
Es algo más parecido a esto:
| Entorno | Capa de cálculo | Capa de serving |
|---|---|---|
| NVIDIA | CUDA y kernels específicos | vLLM |
| AMD | ROCm y kernels específicos | vLLM |
| Apple Silicon + vLLM-Metal | MLX + Metal | vLLM + vLLM-Metal |
| Apple Silicon + vllm-mlx | MLX | vllm-mlx |
La tabla simplifica una arquitectura que en realidad tiene más componentes, pero sirve para entender la diferencia fundamental.
El nombre del servidor no determina por sí solo el rendimiento. El hardware y el backend condicionan buena parte de lo que ocurre debajo.
Eso es especialmente importante ahora que Apple Silicon está entrando en escenarios de inferencia local y servidores compactos. Un Mac mini o un Mac Studio pueden utilizarse para cargas muy diferentes de las que justifican un servidor con múltiples GPU NVIDIA.
Para una aplicación local con una o pocas peticiones, la prioridad puede ser cargar un modelo grande con una cantidad razonable de memoria y consumir poco. Para una API con cientos de usuarios simultáneos, la prioridad cambia hacia batching, utilización del acelerador, latencia, caché y escalado horizontal.
En el primer escenario, MLX puede tener mucho sentido. En el segundo, las capacidades de serving de vLLM y la infraestructura de aceleradores profesionales pueden resultar más relevantes.
Y ahí está probablemente la idea más importante que deja esta comparación: no basta con preguntar qué framework es mejor.
Hay que preguntar para qué hardware se ha construido, qué backend utiliza, qué kernels tiene disponibles, cómo gestiona la memoria, qué formatos de modelos admite y, sobre todo, qué tipo de carga se quiere ejecutar.
Porque dos motores pueden tener exactamente el mismo objetivo, servir un LLM, y estar resolviendo problemas técnicos muy diferentes.
Preguntas frecuentes
¿vLLM funciona en un Mac con Apple Silicon?
Sí. vLLM ofrece actualmente soporte para Apple Silicon mediante el plugin vLLM-Metal, que utiliza MLX como backend de cálculo y Metal para la aceleración de la GPU.
¿Es vLLM-Metal igual que vLLM sobre NVIDIA?
No. Comparte componentes de serving de vLLM, pero vLLM-Metal utiliza MLX y kernels Metal adaptados a Apple Silicon. En NVIDIA, vLLM utiliza el ecosistema CUDA y sus implementaciones específicas para GPU.
¿Qué es vllm-mlx?
Es un proyecto independiente que proporciona un servidor de inferencia para Apple Silicon construido alrededor de MLX. Incluye funciones como batching continuo, caché KV paginada y APIs compatibles con OpenAI y Anthropic.
¿MLX puede utilizar modelos cuantizados de otros formatos?
Sí, aunque no todos los formatos son directamente intercambiables. mlx-lm incorpora conversiones desde formatos como AWQ y GPTQ y mantiene su propia representación y modos de cuantización.
