Phase 17 - Lesson 06

SGLang y RadixAttention para Cargas de Trabajo con Uso Intensivo de Prefijos

SGLang trata la KV cache como un recurso reutilizable de primera clase almacenado en un árbol radix (radix tree). Mientras que vLLM agenda las solicitudes en orden FCFS (first-come, first-served), el agendador basado en cache (cache-aware scheduler) de SGLang prioriza las solicitudes con prefijos compartidos más largos: efectivamente un recorrido radix de búsqueda en profundidad (depth-first radix traversal) para que las ramas calientes (hot branches) permanezcan residentes en HBM. En Llama 3.1 8B con prompts de 1K similares a ShareGPT, SGLang alcanza ~16,200 tok/s frente a ~12,500 de vLLM, una ventaja de ~29%. En cargas de trabajo de RAG con uso intensivo de prefijos, la ventaja alcanza 6.4x. En cargas de trabajo de clonación de voz, la tasa de acierto de la cache superó el 86%. Desplegado en más de 400,000 GPUs en 2026 en xAI, LinkedIn, Cursor, Oracle, GCP, Azure y AWS. El detalle es que el factor de 6.4x se evapora cuando el orden de los prefijos no es consistente: el orden es la palanca del ingeniero.

Tipo: Aprender Lenguajes: Python (stdlib, simulador simplificado de cache en árbol radix + agendador basado en cache) Requisitos previos: Phase 17 · 04 (vLLM Serving Internals), Phase 14 (Agentic RAG) Tiempo: ~75 minutos

Objetivos de Aprendizaje

• Diagramar RadixAttention: cómo se almacenan los prefijos en un árbol radix y cómo se comparten los bloques de KV entre secuencias enraizadas en la misma rama.
• Explicar el agendamiento basado en cache y por qué FCFS es incorrecto para tráfico con uso intensivo de prefijos.
• Calcular la aceleración esperada para una carga de trabajo dada la tasa de acierto de la cache de prefijo y la distribución de longitud de los prompts.
• Nombrar la disciplina de ordenamiento de prompts que hace que la aceleración de 6.4x sea real en lugar de un beneficio desperdiciado.

El Problema

El servicio clásico de inferencia trata el prompt de cada solicitud como opaco. Incluso cuando 5,000 solicitudes de RAG comienzan con el mismo prompt de sistema de 2,000 tokens y el mismo preámbulo de recuperación, vLLM realiza el prefill de ese prefijo de 2,000 tokens 5,000 veces. La GPU realiza el mismo trabajo una y otra vez.

La observación: los prompts en cargas de trabajo agénticas y de RAG comparten prefijos largos casi siempre. Prompt de sistema, esquemas de herramientas, ejemplos de pocas demostraciones (few-shot), encabezados de recuperación, historial de conversación: todo se repite entre las solicitudes. Si almacenaras la KV cache de ese prefijo una vez y la reutilizaras, no tendrías que hacer el prefill de nuevo.

RadixAttention hace exactamente esto. Los tokens se indexan en un árbol radix; cada nodo posee bloques de KV para la secuencia de tokens en su ruta desde la raíz. Una nueva solicitud recorre el árbol: cualquier nodo cuyo token coincida reutiliza los bloques de KV de ese nodo. El costo del prefill se vuelve proporcional al sufijo "nuevo", no al prompt completo.

El desafío es el agendamiento. Si dos solicitudes comparten un prefijo de 2,000 tokens y una tercera comparte solo 200 tokens del mismo prefijo, deseas atender las dos solicitudes con mayor prefijo compartido juntas para que el prefijo largo permanezca en HBM. FCFS hace lo contrario: atiende a quien llegó primero, desalojando potencialmente la rama caliente antes de que llegue la siguiente solicitud con prefijo largo.

El Concepto

El árbol radix como un índice de KV

Un árbol radix (trie compacto) almacena secuencias de tokens. Cada nodo posee un rango de tokens y los bloques de KV calculados para ese rango. Los hijos extienden la secuencia uno o más tokens.

root
 |- "You are a helpful assistant..."  (2,000 tokens, 124 bloques de KV)
      |- "Context: <doc A>..."        (500 tokens, 31 bloques)
           |- "Question: Alice..."    (80 tokens, 5 bloques)
           |- "Question: Bob..."      (95 tokens, 6 bloques)
      |- "Context: <doc B>..."        (520 tokens, 33 bloques)

Llega una nueva solicitud con prompt de sistema + "Context: " + "Question: Carol". El agendador recorre el árbol: el prefijo del sistema coincide (124 bloques reutilizados), la rama del doc-A coincide (31 bloques reutilizados) y luego asigna bloques nuevos solo para "Question: Carol" (4 bloques). Costo del prefill: 4 bloques de tokens nuevos. Sin el árbol: 160 bloques. ~40x de ahorro en el prefill.

Agendamiento basado en cache (cache-aware)

La reutilización basada en el árbol radix no tiene sentido si la cache sufre desgaste continuo (thrashing). Dos políticas clave:

1. Despacho en profundidad (depth-first dispatch). Al elegir la siguiente solicitud de la cola, prefiere solicitudes enraizadas en la misma rama que el conjunto en ejecución actual. Esto mantiene la rama caliente fija.
2. LRU a nivel de rama, no de bloque. Desaloja ramas enteras (comenzando por las hojas menos utilizadas recientemente) en lugar de bloques individuales, de modo que la forma de la cache coincida con la forma del árbol radix.

FCFS viola ambas. Una solicitud que comparte 2,000 tokens se coloca detrás de una solicitud que comparte 50, y luego la rama de 2,000 tokens se desaloja para admitir la solicitud de 50 tokens.

Números de benchmark que debes memorizar

• Llama 3.1 8B, H100, prompts de 1K de ShareGPT: SGLang ~16,200 tok/s vs vLLM ~12,500 (ventaja de ~29%).
• RAG con uso intensivo de prefijos (mismo sistema + mismo documento, variando solo la pregunta): hasta 6.4x en SGLang.
• Cargas de trabajo de clonación de voz: tasa de acierto de la cache de prefijos del 86.4%.
• Tasas de acierto en producción en clientes de SGLang: 50-99% dependiendo de la disciplina de prompts.
• Desplegado en más de 400,000 GPUs en 2026.

La trampa del ordenamiento

El factor de 6.4x depende de un ordenamiento consistente de las plantillas de prompts. Si tu cliente construye prompts como [sistema, herramientas, contexto, historial, pregunta] en algunas solicitudes y [sistema, contexto, herramientas, historial, pregunta] en otras, el árbol no podrá encontrar el prefijo compartido. Lo que parece un prefijo compartido para un humano son dos secuencias distintas para el árbol radix.

La palanca del ingeniero: la plantilla de tu prompt es una clave de cache. Fija el orden. Coloca todo lo inmutable (sistema, herramientas, esquemas) primero. Coloca el contexto de recuperación después. Coloca la pregunta del usuario al final. No intercales contenido dinámico en el prefijo.

Caso real de investigación: mover el contenido dinámico fuera del prefijo cacheable elevó la tasa de acierto de la cache de un despliegue del 7% al 74% con un solo cambio.

Dónde gana y pierde RadixAttention

Gana:

• RAG (mismo preámbulo de recuperación, pregunta variable).
• Agentes (mismos esquemas de herramientas, consulta variable).
• Chat con prompts de sistema largos.
• Cargas de trabajo de voz/visión con preámbulos repetidos.

Pierde (regresa al rendimiento de vLLM):

• Generación de paso único (single-shot) con prompts únicos (autocompletar código, chat abierto sin prompt de sistema).
• Prompts dinámicos donde cada solicitud intercala contenido único en el prefijo.

Por qué esto es un problema del agendador, no solo del kernel

Puedes implementar la reutilización de KV como un truco del kernel. La perspectiva de SGLang es que la reutilización solo compensa si el agendador mantiene la rama caliente residente. Una política ingenua de "reutilizar si está disponible" desgastará la cache bajo carga mixta. El agendador indexado por árbol radix es lo que convierte el truque del kernel en una ventaja de producción del 29%.

Interacción con vLLM

Los dos sistemas no son competidores estrictos. En 2026, vLLM agregó cache de prefijos (--enable-prefix-caching) y un enrutador basado en cache (vLLM Router escrito en Rust). La brecha se redujo pero no desapareció por completo: la pila de SGLang está diseñada con prioridad radix; vLLM lo incorporó como extensión. Para cargas de trabajo dominadas por la reutilización de prefijos, SGLang sigue siendo el predeterminado. Para servicios de uso general sin patrones de prefijo marcados, vLLM sigue siendo igual o mejor.

Use It

El archivo code/main.py implementa una KV cache simplificada en árbol radix más un agendador con dos políticas: FCFS y basado en cache. Ejecuta la misma carga de trabajo a través de ambos, informando la tasa de acierto de la cache de prefijos y la diferencia de rendimiento. Luego ejecuta una carga de trabajo con "orden mezclado" para mostrar el colapso de la aceleración de 6.4x.

Ship It

Esta lección produce outputs/skill-radix-scheduler-advisor.md. Dada una descripción de la carga de trabajo (forma de plantilla de prompt, patrón de recuperación, número de inquilinos concurrentes), genera una recomendación de ordenamiento de prompts y una recomendación de adopción o no de SGLang.

Exercises

1. Ejecuta code/main.py. Compara FCFS y el agendador basado en cache en la misma carga de trabajo. ¿De dónde proviene la diferencia: ahorro en prefill, ahorro en decodificación o retraso en la cola?
2. Modifica la carga de trabajo para que los prompts permuten aleatoriamente los bloques [sistema, herramientas, contexto]. Ejecuta nuevamente. ¿Qué ocurre con la tasa de acierto? ¿Por qué?
3. Calcula el costo en HBM de mantener un prompt de sistema de 2,000 tokens residente como una rama radix en Llama 3.1 8B. Compáralo con el costo de un lote de 16 secuencias sin reutilización de prefijos.
4. Lee el artículo de SGLang RadixAttention. Explica en tres frases por qué la política de desalojo LRU basada en el árbol supera a la política LRU basada en bloques bajo tráfego intensivo en prefijos.
5. Un cliente informa una tasa de acierto en la cache de solo el 8%. Nombra tres causas probables y el diagnóstico que ejecutarías para cada una.

Key Terms

Further Reading

• SGLang GitHub — código fuente y documentación.
• SGLang documentation — detalles de RadixAttention y agendamiento.
• SGLang paper — Efficiently Programming Large Language Models (arXiv:2312.07104) — la referencia de diseño.
• LMSYS blog — SGLang with RadixAttention — números de benchmark y justificación del agendador.
• vLLM — Prefix Caching — implementación similar a radix del propio vLLM, para comparación.