SGLang y RadixAttention: cuándo NO usar vLLM

5.1El problema que ataca RadixAttention

El prefix caching de vLLM (L2) reutiliza prefijos exactos entre peticiones. Pero muchos workloads reales tienen prefijos compartidos en forma de árbol, no de lista:

• Un agente que comparte system prompt + definiciones de tools, pero cada rama explora una tool distinta.
• Un few-shot donde varias peticiones comparten los primeros ejemplos pero divergen en el último.
• Un chatbot multi-turno donde la conversación se ramifica.

RadixAttention (Zheng et al., NeurIPS 2024) generaliza el cache de prefijos a un árbol radix del KV-cache: cada nodo es un trozo de tokens, y las ramas comparten físicamente los prefijos comunes. Cuando llega una petición, se busca el prefijo más largo ya cacheado en el árbol y se reutiliza su KV; solo se computa la parte nueva. Es prefix caching con estructura de árbol y políticas de evicción (LRU) sobre ese árbol.

Resultado (paper): hasta 6.4× de throughput en workloads prefix-heavy frente a sistemas previos; en mediciones H100 con Llama-3.1-8B/ShareGPT, ~29% sobre vLLM. Además el compressed FSM acelera ~1.6× la generación con structured output (JSON), porque comprime los estados del autómata que restringe la gramática.

5.2Cuándo gana SGLang y cuándo no

Gana cuando hay mucho solape de prefijos en árbol y/o structured output pesado:

• Agentes con system prompt + tools compartidos y muchas ramas.
• RAG donde el contexto recuperado se repite parcialmente.
• Pipelines con few-shot compartido.
• Generación masiva de JSON/gramáticas restringidas.

No gana (usa vLLM) cuando:

• Peticiones independientes sin prefijo común (cada prompt único).
• Workload puramente throughput de texto libre.
• Necesitas la madurez/estabilidad de vLLM en Blackwell (ver 5.4).

5.3Laboratorio L5.1 — vLLM vs SGLang en workload prefix-heavy (parte de C1)

Diseña una workload con prefijos en árbol y compáralos de forma justa.

Servidor SGLang (Blackwell):

1docker run --gpus all -p 30000:30000 --ipc=host \
2  lmsysorg/sglang:blackwell \
3  python -m sglang.launch_server \
4  --model-path Qwen/Qwen3-8B \
5  --host 0.0.0.0 --port 30000 \
6  --disable-cuda-graph          # <-- IMPRESCINDIBLE en Blackwell SM_120 (junio 2026)

Workload con prefijos ramificados (genérica, reutilizable):

1# lab_n1l5_prefix_tree.py — genera peticiones que comparten prefijos en árbol
2# Estructura: un SYSTEM común -> 8 "ramas" (contextos de tarea) -> 16 queries por rama.
3# vLLM cachea el SYSTEM; SGLang debería cachear SYSTEM + cada rama (árbol).
4SYSTEM = "Eres un agente con acceso a herramientas. " * 100
5BRANCHES = [f"Contexto de tarea {b}: " + ("detalle. " * 80) for b in range(8)]
6def build_requests():
7    reqs = []
8    for b, branch in enumerate(BRANCHES):
9        for q in range(16):
10            prompt = SYSTEM + branch + f"\nPregunta {q}: resuelve el subcaso {q}."
11            reqs.append(prompt)
12    return reqs   # 128 peticiones; comparten SYSTEM, y de 16 en 16 comparten también la rama

Mide el mismo build_requests() contra los dos servidores (cliente async como en L1.1, apuntando a :8000 para vLLM y :30000 para SGLang). Compara wall-time y throughput agregado. SGLang debería ganar más cuanto más profundo y ramificado sea el solape, porque reutiliza también el KV de cada rama, no solo del SYSTEM.

Líneas no triviales:

• La estructura SYSTEM→rama→query es justo donde el árbol radix añade valor sobre el prefix-list de vLLM.
• --disable-cuda-graph: en Blackwell SM_120 (2026) los cuda graphs de SGLang fallan; sin este flag el servidor no arranca o casca. (Es el coste de estar en hardware nuevo.)
• Comparación justa: mismo modelo, misma precisión, mismo conjunto de peticiones, mismo temperature=0.

5.4El caveat Blackwell (decisión de producción)

A junio de 2026, en SM_120: SGLang necesita --disable-cuda-graph (pierdes parte de su optimización) y NVFP4 en SGLang es menos estable que en vLLM. Por eso la recomendación práctica es: vLLM como motor por defecto en producción Blackwell; SGLang cuando tu workload es netamente prefix-heavy o structured-output-heavy y el speedup que mides lo justifica. Esa decisión, tomada con tus números del lab, es lo que C1 valida.

5.5Ejercicios

E1. Reproduce el experimento. ¿Cuál es tu speedup de SGLang vs vLLM en la workload ramificada? Mídelo también con BRANCHES de 1 sola rama (prefijo no ramificado): ¿se reduce la ventaja? ¿Por qué?

E2. Activa structured output (un esquema JSON) en ambos y compara tok/s. ¿Ves el efecto del compressed FSM?

E3. Decide y justifica por escrito (lab notebook): para un agente con 50 tools compartidas y muchas ramas, ¿vLLM o SGLang en tu 5090? Incluye el coste del --disable-cuda-graph.

5.6Trampas comunes

• Olvidar --disable-cuda-graph en SGLang Blackwell.
• Comparar con una workload sin solape de prefijos (SGLang no luce ahí).
• No igualar modelo/precisión/temperature entre motores.

5.7Referencias

• Zheng et al., "SGLang: Efficient Execution of Structured Language Model Programs" (NeurIPS 2024, arXiv 2312.07104). Docs SGLang. Benchmarks comparativos vLLM vs SGLang 2026.