SGLang: servir un LLM local a varios utilisateurs

#Qué hace SGLang

SGLang se presenta como un framework de alto rendimiento para servir LLM y modelos multimodales, diseñado para una inferencia de baja latencia y alta tasa de procesamiento, desde una sola GPU hasta grandes clústeres distribuidos. El proyecto afirma contar con despliegues en producción que generan trillones de tokens cada día en más de 400.000 GPU en todo el mundo, y está alojado en LMSYS, una organización de código abierto sin ánimo de lucro.

Compatible con las API de OpenAI y Hugging Face, SGLang admite una amplia gama de modelos (Llama, Qwen, DeepSeek, GLM, Mistral, Gemma) y de hardware (GPU NVIDIA, AMD, CPU Intel Xeon, TPU Google, NPU Ascend). A fecha del 28 de septiembre de 2026, la última versión es v0.5.20, publicada el 18 de septiembre de 2026.

#Instalar y lanzar el servidor

La instalación recomendada por la documentación oficial se realiza con uv, más rápido que el pip tradicional. El flag --prerelease=allow es necesario porque algunas dependencias de SGLang solo publican versiones preliminares en PyPI.

pip install --upgrade pip
pip install uv
uv pip install --prerelease=allow sglang

La ejecución en un contenedor Docker sigue siendo la vía más reproducible para un despliegue en servidor, con el puerto 30000 utilizado por defecto para la API.

docker run --gpus all \
    --shm-size 32g \
    -p 30000:30000 \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=<secret>" \
    --ipc=host \
    lmsysorg/sglang:latest \
    python3 -m sglang.launch_server --model-path meta-llama/Llama-3.1-8B-Instruct --host 0.0.0.0 --port 30000

La documentación especifica que SGLang exige ahora CUDA 13: las imágenes y los paquetes wheel de CUDA 12 (cu129) se han retirado desde que PyTorch 2.14 dejó de publicar compilaciones para CUDA 12.9, y la versión 0.5.19 sigue siendo la última que ofrece una opción para CUDA 12. Por tanto, un despliegue en hardware más antiguo debe mantener fija esa versión o verificar el controlador de GPU antes de actualizar.

#RadixAttention y el caché de prefijos

La clave del rendimiento prometido por SGLang es RadixAttention: los prefijos de secuencias ya calculados (un prompt de sistema compartido, el inicio de una conversación de varios turnos) se organizan en un árbol radix y se reutilizan entre solicitudes, en lugar de recalcularse en cada llamada. El anuncio original del proyecto, en enero de 2024, afirmaba que este mecanismo permitía una inferencia hasta 5 veces más rápida: una cifra anunciada por el proyecto a partir de su propio banco de pruebas de entonces, no una medición independiente reciente en tu hardware.

Esta mejora beneficia sobre todo a los escenarios con prefijos compartidos: varios usuarios que hacen consultas con el mismo prompt de sistema, un agente que relee el mismo contexto en cada turno o el uso de few-shot con los mismos ejemplos. Un flujo de solicitudes sin ningún prefijo común (preguntas totalmente independientes, sin historial) se beneficia mucho menos de RadixAttention.

El runtime combina RadixAttention con un planificador de CPU sin sobrecarga, la desagregación prefill-decode, la decodificación especulativa, la planificación continua de solicitudes (continuous batching) y la atención paginada (paged attention): un conjunto de técnicas de optimización en lugar de un mecanismo aislado.

#Ajustar la concurrencia y la memoria

Tres parámetros de lanzamiento regulan la forma en que SGLang atiende a varios usuarios en paralelo. --mem-fraction-static fija la fracción de memoria GPU reservada para los pesos del modelo y la caché KV; la documentación recomienda reducirla en caso de error por falta de memoria; de lo contrario, se calcula automáticamente a partir de la memoria GPU disponible.

Sin límite explícito en --max-running-requests, SGLang acepta tantas solicitudes como permita la memoria del caché KV, lo que puede degradar la latencia por solicitud bajo carga alta en lugar de rechazar amablemente nuevas conexiones. Fijar un límite explícito, coherente con la VRAM disponible, es el primer ajuste que se debe hacer antes de abrir el servidor a varios usuarios reales.

#Cuándo elegir SGLang en lugar de vLLM o Ollama

Las tres herramientas responden a necesidades diferentes. Ollama se dirige al uso personal de un solo usuario y requiere muy poco aprendizaje inicial; SGLang y vLLM se orientan al servicio para múltiples usuarios en GPU de servidor, con filosofías similares (caché de prefijos, batching continuo), pero con trayectorias y ecosistemas distintos.

Un solo usuario, equipo personal

Ollama o llama.cpp siguen siendo más fáciles de instalar y ejecutar en CPU o GPU de consumo, sin configurar un servicio de red.

Varios usuarios, sistema ya construido alrededor de vLLM

Seguir con vLLM evita una migración; nuestra guía específica cubre su despliegue en producción.

Varios usuarios, prioridad a la tasa de procesamiento con prefijos compartidos

SGLang, con RadixAttention, es el candidato natural — si se dispone de un GPU CUDA compatible.

Se busca compatibilidad con el cliente de Ollama sin instalar Ollama

SGLang expone una API compatible con la CLI y la biblioteca Python de Ollama, lo que permite reutilizar scripts existentes sin ejecutar el propio servidor de Ollama.

Para una visión más amplia de las arquitecturas de inferencia (llama.cpp, vLLM, Exllama), la comparativa de backends del sitio detalla las ventajas e inconvenientes más allá del caso concreto de SGLang.

#Lo que el hardware exige

La guía de inicio rápido de SGLang es explícita: una GPU NVIDIA compatible con CUDA sm80 o superior (A10, A100, L4, L40S, H100) es un requisito previo para la vía de instalación estándar en Linux, la plataforma recomendada. El proyecto anuncia además compatibilidad con una gama más amplia de hardware —GPU AMD (MI355, MI300), CPU Intel Xeon, TPU de Google, NPU Ascend— mediante vías de instalación específicas y distintas de la vía principal para GPU NVIDIA.

#El coste en memoria por solicitud

«Atender a varios usuarios» se traduce muy concretamente en un consumo de VRAM que aumenta con el número de solicitudes activas, no solo con el tamaño del modelo. La caché KV que gestionan --mem-fraction-static y --max-total-tokens almacena, para cada token ya generado de una solicitud, dos vectores (clave y valor) por capa de atención. La fórmula general es: bytes por token = 2 × número de capas × cabezas de atención KV × dimensión de una cabeza × bytes por valor (2 en FP16/BF16, 1 en FP8).

Cálculo ilustrativo para una arquitectura similar a Llama-3.1-8B-Instruct (32 capas, 8 cabezas KV en atención agrupada, dimensión de cabeza de 128): en FP16, esto da 2 × 32 × 8 × 128 × 2 = 131 072 bytes por token, es decir, aproximadamente 128 KB por token. Para una solicitud con 8 192 tokens de contexto (prompt y respuesta acumulados), la caché KV de esta única solicitud ocupa entonces aproximadamente 1 GB de VRAM, antes incluso de contar los pesos del modelo. En una GPU de 24 GB con aproximadamente 16 GB reservados para los pesos en Q4 y los recursos básicos del runtime, el margen restante solo deja espacio para unas pocas solicitudes activas simultáneas con ese tamaño de contexto, lo que explica por qué un límite explícito en --max-running-requests evita una degradación en lugar de un rechazo controlado de las nuevas conexiones.

#Seguridad y observabilidad

Por defecto, la API de SGLang iniciada con sglang.launch_server no exige autenticación: cualquiera que acceda al puerto 30000 puede enviar solicitudes. La opción --api-key establece una clave que el servidor exige también en su endpoint compatible con OpenAI; sin ella, exponer el servidor más allá de localhost o de una red interna de confianza equivale a dejar abierto el acceso a la inferencia y, por tanto, al gasto de GPU asociado.

Para la monitorización en producción, la opción --enable-metrics (desactivada por defecto) publica métricas en formato Prometheus en un endpoint /metrics: tasa de solicitudes, latencia de inferencia, velocidad de generación de tokens y eficiencia de la caché, disponibles para su recopilación periódica en lugar de deducir el estado del servidor únicamente a partir de los registros.

• Principios de seguridad de un servidor de inferencia expuesto
• Fuente: referencia de los argumentos del servidor (--api-key, --enable-metrics)

#Solución de problemas: síntomas, causa, corrección

#Límites y aspectos que requieren atención

La cifra «hasta 5 veces más rápido» que todavía acompaña la presentación de RadixAttention procede del anuncio inicial del proyecto en enero de 2024: ilustra la aportación del mecanismo en el banco de pruebas de aquella época, no una mejora garantizada en un despliegue reciente con modelos y GPU diferentes. El dimensionamiento real depende del grado en que las solicitudes comparten prefijos, del modelo elegido y de la GPU utilizada: hay que medirlo con tu propio tráfico en lugar de deducirlo del anuncio original.

El paso obligatorio a CUDA 13 (la versión 0.5.19 es la última que ofrece una opción para CUDA 12) hace aconsejable comprobar el controlador de la GPU y la versión de CUDA instalada antes de actualizar a una versión reciente, para evitar que falle la instalación en un servidor que siga usando CUDA 12.

La frecuencia de publicación del proyecto también debe vigilarse para un despliegue en producción: SGLang lanza versiones menores cada dos o tres semanas aproximadamente (v0.5.20 el 18 de septiembre de 2026, v0.5.19 el 5 de septiembre, v0.5.18 el 22 de agosto), lo que exige fijar una versión específica en las imágenes Docker en lugar de seguir la etiqueta latest en un servicio en producción, para evitar un cambio de comportamiento inesperado durante un redespliegue.

• Desplegar vLLM en producción
• vLLM: ¿qué es, para quién y cuándo usarlo?
• llama.cpp vs vLLM vs Exllama
• Fuente: documentación oficial de SGLang
• Fuente: README oficial del repositorio SGLang
• Fuente: referencia de los argumentos del servidor