vLLM vs SGLang: qué motor elegir para agentes y RAG

vLLM vs SGLang: ¿cuál conviene elegir?

vLLM es la recomendación inicial para un despliegue general. SGLang merece la primera evaluación cuando predomina el contexto compartido. Estas recomendaciones se basan en las opciones de despliegue y los controles de caché documentados; no afirman que un motor sea siempre más rápido que el otro.

Si gestionas muchos chats cortos, compartir un prompt de sistema es motivo para evaluar SGLang, pero no para descartar vLLM. Ambos reutilizan el cómputo del prompt. Si estás lanzando una API sencilla y tienes poco tiempo para dedicar a la infraestructura, empieza con vLLM y exige una mejora demostrable de servicio o costo antes de cambiar.

RAG, o generación aumentada por recuperación, incorpora documentos recuperados al prompt de un modelo. Lo que permite aprovechar la caché de prefijos es que se repita el inicio del prompt, no que el sistema lleve la etiqueta RAG.

Fecha de verificación: 14 de octubre de 2026. Las últimas versiones estables identificadas durante esta revisión fueron vLLM 0.31.0, publicada el 5 de octubre, y SGLang 0.5.21, publicada el 2 de octubre. Las descripciones de funciones que siguen se basan en la documentación vigente de los proyectos; comprueba la combinación que necesitas en la versión que hayas fijado. Para esta comparativa no se ejecutó ninguna prueba de rendimiento de inferencia.

Las licencias se verificaron en la licencia de vLLM y el repositorio de SGLang. Las licencias de los pesos del modelo, la infraestructura y el trabajo de ingeniería son costos aparte. Ninguno de estos motores de código abierto tiene una tarifa de servicio alojado por token que se pueda comparar.

Qué hace cada motor de inferencia LLM y dónde están sus límites

vLLM: el punto de partida para servir modelos de uso general

vLLM es un motor de inferencia y servicio de modelos que carga sus pesos y programa las solicitudes según el hardware disponible. Entre sus componentes documentados están el procesamiento continuo por lotes, que admite nuevas solicitudes a medida que terminan otras, y PagedAttention, que organiza la caché de claves y valores del modelo en bloques, en lugar de reservar una gran región contigua por solicitud. La caché KV almacena el estado intermedio de atención para que el modelo siga generando sin recalcular todo su historial. Documentación de vLLM

Su atractivo como punto de partida es un despliegue bien definido: un modelo, una imagen oficial del servidor, una API e instrucciones explícitas de instalación por plataforma. Para un equipo de producto que desarrolla un endpoint de atención al cliente, es una base manejable desde la que medir la capacidad.

El límite está en la configuración que se haya validado. Disponer de una GPU compatible es solo el principio: la arquitectura del modelo, la cuantización, el backend de atención y las funciones solicitadas deben funcionar en conjunto. Hay una excepción de caché relevante para los servicios de evaluación: según vLLM, una solicitud que pide las probabilidades logarítmicas del prompt omite la caché de prefijos y vuelve a calcularlo. Por eso, un endpoint de puntuación puede comportarse de forma distinta a uno de chat aunque ambos usen el mismo documento. Guía de vLLM V1

El motor cuesta $0. Elígelo para servir modelos de uso general y gestionar una infraestructura heterogénea; no migres a él si tu instalación de SGLang ya cumple el objetivo de servicio y no le falta ninguna función necesaria.

SGLang: una opción sólida cuando los agentes repiten contexto

SGLang es un framework de inferencia de código abierto para modelos de lenguaje y multimodales que incluye las cargas de agentes entre sus prioridades declaradas. RadixAttention organiza el estado reutilizable del prompt en torno a prefijos compartidos. Su extensión HiCache añade memoria del host y almacenamiento detrás de la caché de GPU. Su interés práctico está en las herramientas documentadas para conservar y reutilizar contexto entre solicitudes repetidas. Repositorio de SGLang, diseño de HiCache

Imagina un agente que consulta una y otra vez la misma política de atención al cliente y luego responde preguntas diferentes. Ese escenario justifica evaluar SGLang mucho más que una gran cantidad de prompts simultáneos sin relación entre sí.

Sus límites están en el alcance local de la caché y la paridad de funciones entre backends. Los niveles de GPU y memoria del host de HiCache pertenecen a una instancia de inferencia. El almacenamiento solo se comparte cuando el backend elegido se configura para ello. Ampliar la caché del host no crea automáticamente una caché compartida por toda la infraestructura. Añadir niveles también implica gestionar presupuestos de memoria, transferencias y configuración. Alcance de la caché compartida de HiCache

El motor cuesta $0. Elígelo cuando la repetición de contexto tenga suficiente peso como para dedicarle ajustes; no cambies solo por la palabra «agentes» si tus prompts rara vez comparten un prefijo exacto.

Caché de prefijos y RadixAttention: conviene probar SGLang primero

SGLang merece prioridad en la evaluación de cargas con ramificaciones y contexto repetido; vLLM ya dispone de la capacidad esencial de caché. No se trata de enfrentar PagedAttention con la posibilidad de usar caché. PagedAttention organiza la memoria; la caché de prefijos permite reutilizar cómputo. Automatic Prefix Caching de vLLM contempla expresamente las preguntas repetidas sobre documentos largos y las conversaciones de varios turnos. Caché de prefijos de vLLM

El prefill es el trabajo de leer el prompt antes de empezar a generar. La decodificación consiste en generar los tokens nuevos. Un acierto de caché puede evitar repetir el prefill, pero no elimina la decodificación necesaria para redactar una respuesta nueva. Por eso, una respuesta larga con poca entrada compartida puede beneficiarse poco de la reutilización de prefijos de cualquiera de los dos motores.

En un producto de chats cortos, coloca las políticas estables y las descripciones de herramientas antes del contenido variable de la solicitud, siempre que lo permita el formato de prompt que espera el modelo. Mantén estables la serialización y el orden de los documentos. Una marca de tiempo distinta cerca del inicio puede impedir reutilizar todo el contenido posterior, aunque sea idéntico. Piensa en un camino compartido: una vez que las rutas se separan, encontrar el mismo paisaje más adelante no hace que el recorrido anterior haya sido el mismo.

El RAG de contexto largo exige otra comprobación: ¿el contexto se puede reutilizar o simplemente es largo? Las preguntas repetidas sobre un manual que no cambia son un buen caso para usar caché. Un buscador que combina pasajes diferentes en distinto orden en cada solicitud quizá solo pueda conservar su breve prefijo de sistema. Mide ambos casos por separado antes de invertir en almacenamiento jerárquico.

Según la documentación de SGLang, RadixAttention está activado de forma predeterminada y se controla con --disable-radix-cache; HiCache requiere una decisión adicional de configuración. En ambos motores, revisa la configuración efectiva en lugar de deducir el comportamiento de la caché por el nombre del proyecto. Argumentos del servidor de SGLang

Funciones para agentes: empate en JSON; hay que validar adaptadores y modelos borrador

Necesitar JSON no basta para dar la victoria a ninguno de los dos motores. Ambos admiten generación restringida por un esquema. Deja que el modelo elija los valores, limita la estructura y valida el resultado antes de ejecutar una acción.

Salida JSON estructurada

vLLM admite JSON Schema mediante response_format y las opciones de structured_outputs. SGLang también admite JSON Schema y utiliza XGrammar como backend de gramática predeterminado. Son restricciones de decodificación, no simples instrucciones para que el modelo «devuelva JSON». Salidas estructuradas de vLLM, salidas estructuradas de SGLang

En un agente de soporte, un esquema puede exigir una acción y un identificador de ticket. No puede demostrar que ese ticket pertenece al usuario que hace la solicitud ni que la acción elegida está justificada. Esas comprobaciones deben seguir en el código de la aplicación. Prueba en conjunto tus esquemas reales, el modo de razonamiento y el comportamiento del streaming: que un motor admita cada elemento por separado no demuestra que la combinación funcione correctamente.

Resultado: empate para las necesidades habituales de JSON. Mantén el motor que ya operas, salvo que las solicitudes con esquemas representativos revelen una diferencia concreta.

Decodificación especulativa

La decodificación especulativa es una opción de ajuste en ambos proyectos; no garantiza una mejora de velocidad. Un mecanismo de borrador propone tokens y el modelo objetivo los verifica. Las propuestas útiles que se aceptan pueden reducir el trabajo secuencial de generación, pero preparar el borrador, verificarlo y mantenerlo en memoria también tiene un costo.

vLLM documenta EAGLE, predicción de múltiples tokens, modelos borrador independientes y métodos de n-gramas y sufijos. SGLang también documenta EAGLE, predicción de múltiples tokens, modelos borrador y NGRAM. La combinación de borrador, modelo objetivo, hardware y nivel de tráfico importa más que la presencia de una función en una lista. Métodos de vLLM, métodos de SGLang

Gana el motor cuya configuración de borrador hayas validado para tu modelo. Activa la especulación después de establecer una referencia y compara la latencia de respuesta y la capacidad total. Déjala desactivada si el trabajo adicional no compensa con tu carga de producción.

Multi-LoRA para adaptar el comportamiento a cada cliente

Ambos pueden servir varios adaptadores LoRA: pequeños conjuntos de pesos de ajuste fino que personalizan un modelo base compartido. vLLM permite registrar adaptadores mediante --lora-modules, con controles de concurrencia y rango. SGLang ofrece --lora-paths y --max-loras-per-batch; el valor predeterminado documentado por lote es de 8 adaptadores. No es un límite al número total de clientes. LoRA en vLLM, LoRA en SGLang

Para un producto de escritura personalizado por cliente, prueba la distribución de adaptadores que esperas, incluidos los que aún no estén cargados y los cambios frecuentes. La opción de carga solapada de SGLang puede ocultar las transferencias, pero su documentación también advierte que puede reducir la agrupación en lotes del prefill con varios adaptadores y aumentar la latencia hasta el primer token. Más opciones no implican automáticamente más capacidad.

La mejor opción es conservar el motor cuyo funcionamiento con adaptadores ya hayas validado. Multi-LoRA, por sí solo, no justifica un cambio. Vale la pena probar SGLang cuando el cuello de botella sea la carga de adaptadores o una carga de trabajo que dependa mucho de la caché. Para TPU, consulta la matriz de funciones del propio backend: la guía de SGLang-JAX sigue indicando que multi-LoRA está en desarrollo. Matriz de SGLang para TPU

Compatibilidad de hardware: vLLM es el punto de partida para una infraestructura heterogénea

Ambos proyectos declaran compatibilidad con NVIDIA, AMD, TPU y CPU. El límite real depende de la combinación de backend y modelo. Una lista general de hardware compatible no garantiza que todas las configuraciones de GPU, adaptadores o métodos de decodificación se puedan trasladar sin cambios.

• NVIDIA: vLLM documenta la instalación en GPU con CUDA; el repositorio de SGLang enumera familias para centros de datos y RTX. Las imágenes de la versión actual deben ser compatibles con el controlador del host. Instalación de vLLM en GPU, lista de hardware de SGLang
• AMD: ambos documentan el despliegue con ROCm. SGLang incluye Instinct MI300X, MI325X, MI350X y MI355X, con una guía de instalación independiente. Usa la imagen de ROCm y la configuración del modelo que correspondan. Guía de SGLang para AMD
• Google TPU: vLLM remite a la instalación independiente de tpu-inference. La guía de TPU de SGLang utiliza el backend independiente SGLang-JAX e incluye v6e y v7. Son rutas de despliegue distintas que requieren comprobar sus propias funciones. Instalación de vLLM en TPU, guía de SGLang para TPU
• CPU: vLLM documenta Intel/AMD x86 y ARM AArch64 entre sus opciones de CPU. La guía de SGLang para servidores CPU está dirigida específicamente a Intel AMX en procesadores Xeon Scalable de cuarta generación o posteriores. «Compatible con CPU» no significa que ambos cubran las mismas plataformas. Guía de CPU de vLLM, guía de CPU de SGLang

Una diferencia operativa concreta puede decidir el próximo despliegue: vLLM 0.31.0 publica una imagen con CUDA 12.9 además de la predeterminada con CUDA 13.0. La guía de instalación actual de SGLang exige CUDA 13 e indica que su serie de imágenes con CUDA 12 terminó en 0.5.19. Si tu infraestructura todavía no puede pasar a un entorno con controladores compatibles, revisa ese punto antes de comparar resultados de rendimiento. Artefactos de la versión de vLLM, instalación de SGLang

Servidores compatibles con OpenAI: migrar el cliente es más fácil que migrar la carga

Ambos motores pueden atender a un cliente que utilice chat completions al estilo de OpenAI. Los dos documentan /v1/chat/completions y /v1/completions, lo que reduce las piezas de integración que hay que sustituir en la aplicación. Eso no significa que todos los endpoints, extensiones, analizadores de llamadas a herramientas o comportamientos del modelo sean intercambiables. Servidor de vLLM, API de SGLang

Una plantilla de chat convierte los mensajes etiquetados por rol en la secuencia de tokens que espera el modelo. Consérvala al comparar motores. De lo contrario, podrías estar comparando dos prompts distintos sin darte cuenta. Mantén también la misma revisión del modelo, el tokenizador, los parámetros de muestreo y el límite de salida.

Si ya tienes un cliente de vLLM, revisa los campos antiguos de salida restringida antes de migrar o actualizar. La documentación indica que guided_json y otros campos relacionados se eliminaron en 0.12.0; el código actual debe usar el formato admitido de structured_outputs o response_format. Un cuerpo de solicitud desactualizado puede parecer un problema de compatibilidad entre motores. Nota de migración de vLLM

Resultado: empate en la interfaz básica del cliente; vLLM sigue siendo la recomendación inicial por operación. La prueba de aceptación debe cubrir turnos completos del agente, incluidos los argumentos de herramientas enviados por streaming, los errores y los reintentos; no basta con obtener una respuesta de texto correcta.

Cómo ejecutar cada servidor LLM en una nube con GPU

Empieza con un contenedor de versión fija y un modelo pequeño para una prueba básica; después introduce el modelo de producción y ajusta el presupuesto de memoria. Los ejemplos siguientes adaptan los comandos de Docker y de arranque documentados por los proyectos para un host Linux con GPU NVIDIA, Docker, el runtime de contenedores de NVIDIA y un controlador compatible con la imagen. Se contrastaron con la documentación, pero no se ejecutaron en una GPU alquilada. Docker de vLLM, inicio rápido de SGLang

El modelo Qwen/Qwen3-0.6B de estos ejemplos sirve para comprobar que la integración funciona; no es una recomendación sobre la calidad de las respuestas de tu agente. Ejecuta un solo motor a la vez en el mismo puerto. El límite de contexto es una configuración explícita del ejemplo, no el máximo anunciado del modelo.

Contenedor de vLLM

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  vllm/vllm-openai:v0.31.0 \
  --model Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 8192 \
  --enable-prefix-caching

Contenedor de SGLang

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  lmsysorg/sglang:v0.5.21 \
  python3 -m sglang.launch_server \
  --model-path Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --context-length 8192

Tras la inicialización, ejecuta esta solicitud en el host con GPU:

curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Qwen/Qwen3-0.6B",
    "messages": [{"role": "user", "content": "Say hello."}],
    "max_tokens": 64
  }'

Los ejemplos vinculan el puerto del host a la interfaz de loopback. Coloca una puerta de enlace de la aplicación con autenticación delante del servidor antes de atender a usuarios remotos. Esto es especialmente relevante en vLLM: su documentación indica que --api-key no autentica todas las rutas del servidor HTTP. Alcance de la autenticación de vLLM

El worker de vLLM documentado por Runpod

Runpod ofrece en su Hub un worker de vLLM documentado y listo para desplegar. Esta vía rápida a la nube respalda la recomendación inicial por facilidad operativa. El paquete del worker es un artefacto de despliegue independiente: verifica la versión del motor que incluye en lugar de asumir que coincide con la última versión del proyecto original. Guía de despliegue de Runpod

Para SGLang, la vía reproducible en la nube que se describe aquí es su contenedor oficial en un host con GPU compatible. La opción rápida de Runpod mencionada arriba corresponde específicamente al worker de vLLM que documenta Runpod.

Diferencia de precio: la misma GPU cuesta lo mismo

Con la misma capacidad alquilada, ninguno de los dos motores es más barato. El 14 de octubre de 2026, la página de precios vigente de Runpod mostraba una A100 PCIe de 80 GB a $1.79/hora para Pods. Es el precio de una GPU dedicada, no la tarifa del worker de Serverless. Es el costo de infraestructura común que se usa en el cálculo siguiente. Precios de Runpod

Con un mes presupuestario de 730 horas, mantener una GPU aprovisionada continuamente cuesta $1,306.70/mes, tanto con vLLM como con SGLang. Dos cuestan $2,613.40/mes. Estas cifras no incluyen almacenamiento, cargos de red, redundancia ni ingeniería.

Tomemos una carga hipotética de soporte como referencia: 50,000 solicitudes al mes, cada una con 2,000 tokens de entrada y 200 tokens de salida. Eso equivale a 100 millones de tokens de entrada y 10 millones de tokens de salida entregados. Si una GPU puede atender esa carga dentro del tiempo de respuesta requerido, la factura de GPU de cualquiera de los motores es de $0.13067 por cada 1,000 tokens de salida entregados. El denominador son los tokens de salida, aunque la factura también cubre la lectura de la entrada.

Es un cálculo de costos, no una medición de capacidad. Si la carga no cabe en una GPU, ese resultado no se aplica.

El punto que cambia la comparación es aquel en el que una configuración necesita una réplica adicional para cumplir el mismo objetivo de servicio. Si SGLang necesita una GPU y vLLM necesita dos, SGLang ahorra $1,306.70/mes. Si las mediciones de capacidad arrojan la relación inversa, vLLM ahorra la misma cantidad. Si ambos necesitan una, el ahorro de infraestructura es cero.

Con un presupuesto de migración de 8 horas a una tarifa supuesta de $100/hora, el costo es de $800. Retirar una GPU de ese tipo recupera la inversión en aproximadamente 0.61 meses, antes de considerar cualquier diferencia en la operación continua. Sin retirar una réplica ni obtener una mejora de servicio a la que se asigne valor, «más rápido» puede no generar retorno económico alguno.

Gana en precio la configuración que cumple el objetivo con el menor costo operativo total. No se puede dar un umbral de tráfico fiable a favor de un motor sin medir antes la capacidad de tu carga de trabajo que permite cumplir los objetivos de servicio.

Rendimiento: cuenta el trabajo completado dentro del objetivo de latencia

Esta comparativa no establece un ganador universal en rendimiento. Un resultado publicado por un proyecto corresponde a un modelo, hardware, precisión, longitud de solicitudes y versión concretos. Mejorar un kernel no equivale a mejorar el servicio de extremo a extremo, y el rendimiento del prefill no es el rendimiento de generación de tokens de salida. Ninguno de esos resultados justifica una afirmación general de que «SGLang es más rápido» o «vLLM es más rápido».

Usa como punto de partida las herramientas de los propios proyectos: la CLI de pruebas de rendimiento de vLLM y la guía de pruebas del servicio de SGLang. La comparación necesita ejecuciones con caché caliente y fría, además de reproducir el tipo de carga que genera tu producto.

Mide cuatro situaciones por separado: chats cortos que comparten un prompt de sistema estable; preguntas repetidas sobre el mismo documento largo; prompts RAG largos cuyos pasajes recuperados cambian; y tu combinación real de esquemas, llamadas a herramientas y adaptadores. Conserva tanto el ritmo de llegada de las solicitudes como la concurrencia. Una ráfaga de solicitudes simultáneas y un flujo constante pueden revelar cuellos de botella distintos.

Registra las solicitudes completadas, los tokens de salida entregados, los errores y la latencia hasta el primer token. Revisa también las latencias p95 y p99, correspondientes a los percentiles 95 y 99: un buen promedio puede ocultar respuestas muy lentas en el extremo de la distribución. Cuenta como fallos las salidas que no superen las comprobaciones de esquema o de corrección de la aplicación; no son capacidad útil.

Gana el despliegue de menor costo que se mantiene dentro de esos criterios de aceptación. Una afirmación de velocidad basada en otro modelo o en una versión anterior es motivo para hacer esta comparación, no una respuesta a ella.

Cómo cambiar de motor sin romper la integración y con opción de volver atrás

Migra la capa de servicio solo cuando el beneficio medido supere los costos de migración y operación. Si lo único que cambia es el backend de generación, los datos de la aplicación y el almacén de recuperación normalmente pueden quedarse donde están. El trabajo se concentra en el empaquetado del modelo, las extensiones de las solicitudes, el análisis de las salidas y el comportamiento del despliegue.

No cambies un despliegue de vLLM que funciona bien solo para obtener caché de prefijos o restricciones JSON: ya ofrece ambas. Tampoco cambies uno de SGLang que funciona bien solo porque aquí vLLM sea la recomendación inicial. El conocimiento operativo que ya tiene el equipo forma parte de la comparación de costos.

Si todavía no has resuelto si necesitas un servidor de producción compartido, lee Ollama vs vLLM. Esa comparativa aborda la decisión previa entre un flujo cómodo para trabajar con modelos locales y una capa de servicio para solicitudes que se solapan.

El siguiente paso es capturar tráfico pico representativo, fijar los tiempos máximos de respuesta y la tasa de errores aceptables, y comparar versiones fijas de ambos motores en el mismo hardware antes de ampliar la infraestructura.

Preguntas frecuentes

Usa la lista de verificación para auditar flujos de trabajo empresariales con IA para identificar qué flujo necesita un servidor de modelos compartido y suscríbete al boletín para seguir los próximos cambios en las herramientas.