SGLang
Por qué importa
En profundidad
Para entender SGLang, conviene comprender el problema al que se enfrenta cada motor de Inferencia. La decodificación autoregresiva genera un token a la vez, y cada token debe leer todos los pesos del modelo más la KV Cache de todo lo generado hasta el momento, lo que limita la decodificación por el ancho de banda de la memoria y no por el cómputo. Por tanto, la palanca importante no son los FLOPs en bruto, sino cuántas solicitudes puedes agrupar en un batch y cuánto trabajo redundante evitas. SGLang ataca ambos frentes: agrupa y programa solicitudes de forma eficiente como cualquier motor moderno, y va más allá al reconocer que el tráfico real de producción está lleno de estructuras compartidas — el mismo prompt de sistema, los mismos ejemplos few-shot, el mismo historial de chat — que los motores ingenuos vuelven a calcular desde cero para cada solicitud.
RadixAttention y reutilización de prefijos
RadixAttention es la contribución definitoria de SGLang. El motor mantiene la KV Cache en un árbol radix indexado por secuencias de tokens, de modo que cuando llega una nueva solicitud cuyo prompt comparte un prefijo con algo calculado recientemente — un prompt de sistema, un documento, un turno anterior de la conversación —, el motor reutiliza las entradas existentes de la caché en vez de volver a calcularlas. SGLang combina esto con una programación consciente de la caché que prefiere ejecutar en la misma réplica solicitudes con prefijos superpuestos, elevando las tasas de aciertos. En cargas con prompts compartidos largos o mucho tráfico de varios turnos, esto puede reducir la latencia y aumentar considerablemente el rendimiento frente a un servicio sin estado. La idea está relacionada con lo que los proveedores de API venden como Prompt Caching, pero aquí sucede automáticamente dentro del motor, y otros motores, incluido vLLM, han adoptado desde entonces sus propios mecanismos de reutilización de prefijos.
Salida estructurada a gran velocidad
La otra característica destacada de SGLang es la Salida estructurada rápida. La decodificación restringida obliga al modelo a seguir una gramática o un esquema JSON enmascarando los tokens ilegales en cada paso, y las implementaciones ingenuas añaden una sobrecarga perceptible por token. SGLang la optimiza con una máquina comprimida de estados finitos para la gramática y una técnica que salta hacia adelante por los tramos deterministas de la salida — claves fijas, corchetes, espacios en blanco —, emitiendo varios tokens a la vez en lugar de uno por uno. Esto importa más de lo que parece: los pipelines de agentes, la Llamada de Funciones y los trabajos de extracción de datos generan volúmenes enormes de JSON, y una aceleración de 2–5 veces en esa decodificación se traduce directamente en agentes más baratos y ágiles.
SGLang frente a vLLM
La comparación evidente es con vLLM, el otro motor dominante de código abierto para el Servicio de Modelos. Ambos están basados en Python, ambos realizan batching continuo, paralelismo tensorial entre GPU, cuantización y decodificación especulativa, y ambos exponen una API compatible con OpenAI. vLLM es el proyecto más antiguo y tiene el ecosistema mayor, además de estar construido alrededor de PagedAttention, su enfoque por bloques para gestionar la memoria de la KV Cache; SGLang suele adelantarse en tráfico abundante en prefijos y salida estructurada gracias a RadixAttention y su pila de decodificación restringida. Los benchmarks entre ambos cambian con cada lanzamiento, familia de modelos y generación de hardware, por lo que la respuesta para los profesionales es aburrida pero cierta: preselecciona ambos y mide sobre tu propia carga. Muchas plataformas de inferencia admiten discretamente ambos backends precisamente por esta razón.
Más rápido no significa más inteligente
Una idea equivocada común es que cambiar de motor de servicio modifica lo que el modelo puede hacer. No es así. SGLang es una capa para servir, no un modelo ni un framework de entrenamiento — los mismos pesos servidos mediante SGLang, vLLM o cualquier otro motor producen esencialmente las mismas respuestas. Cuando alguien informa que un modelo se volvió "mejor" o "peor" tras cambiar de motor, el verdadero culpable suele ser una configuración distinta de Cuantización, una ventana de contexto truncada o valores predeterminados de muestreo modificados, como la temperatura. Lo que compra un buen motor es eficiencia: más solicitudes por GPU, menor tiempo hasta el primer token, más tokens por segundo. Esa es una historia de costos y latencia de producto, no de capacidad, y por eso elegir un motor es una decisión de infraestructura y no de calidad del modelo.
El efecto DeepSeek
La notoriedad de SGLang aumentó drásticamente con la llegada de modelos de Mezcla de expertos muy grandes, en especial V3 y R1 de DeepSeek, que son durísimos de servir: cientos de miles de millones de parámetros totales, paralelismo de expertos entre muchas GPU y un diseño de atención que rompe las suposiciones incorporadas en pilas de servicio más antiguas. SGLang invirtió pronto y con fuerza en admitir bien estos modelos, y se convirtió en un motor de referencia para despliegues a escala de DeepSeek tanto en la comunidad abierta como entre proveedores de inferencia. Esa reputación perduró: cuando aparece un gran modelo nuevo de pesos abiertos, la compatibilidad de SGLang desde el primer día es algo que los profesionales buscan activamente, igual que vigilan la compatibilidad de vLLM. Los orígenes del proyecto en el ecosistema LMSYS — la misma comunidad detrás de Chatbot Arena — también le dieron credibilidad entre los investigadores desde el primer día.