La estrategia de batching determina los SLO
En la arquitectura de serving de LLM, lo que más directamente afecta los SLO es la forma en que se construye el batching. Sin importar cuántas GPUs de alto rendimiento se apilen, para satisfacer simultáneamente las tres métricas de TTFT (Time To First Token), ITL (Inter-Token Latency) y aggregate throughput, es necesario diseñar la estrategia de batching en función de la forma de llegada de solicitudes, la distribución de la longitud de entrada, la distribución de la longitud de salida y los patrones de ocupación de la caché KV. En este artículo organizamos las características de cinco técnicas empleadas en producción a partir de 2026 —continuous batching, chunked prefill, PagedAttention, RadixAttention y sorted batching—, su impacto en los SLO, y su combinación con la caché de prompts.
Continuous Batching
Continuous batching (también conocido como iteration-level scheduling) es un método que re-decide la composición del batch en cada paso del decode. A diferencia del static batching tradicional que "no agrega nuevos requests hasta que todos los requests del mismo batch se completan", el continuous batching "saca inmediatamente los requests completados e inserta nuevos requests en los slots vacíos". Como resultado, la utilización de GPU no se ve fácilmente afectada por el sesgo en la longitud de requests, y el effective throughput se multiplica especialmente por 2-4x en cargas de trabajo de chat donde la varianza de la longitud de salida es grande.
Sin embargo, solo con continuous batching queda el problema de que prefill y decode colisionan en el mismo paso. El prefill de un request con un prompt largo (más de 8K tokens) tarda varios cientos de ms o más, durante lo cual el decode de otros requests se detiene. Este prefill stall crea la cola larga (long tail) de la distribución de ITL.
Chunked Prefill
Chunked prefill es un mecanismo que divide los prompts largos en pequeños chunks (típicamente 512-2048 tokens) y procesa simultáneamente "1 chunk de prefill + decode de otros requests" en cada iteración. Esto distribuye la carga de prefill en múltiples pasos, y el jitter de ITL se reduce drásticamente. Es una funcionalidad esencial en sistemas que necesitan mantener el ITL p99 por debajo de 50 ms, con soporte estándar en vLLM, SGLang y TensorRT-LLM.
Si el tamaño del chunk es demasiado pequeño, el overhead de kernel launch se vuelve dominante; si es demasiado grande, el decode se interrumpe. Como regla empírica de KGA, 4096-8192 tokens para H200 y 8192-16384 tokens para B200 son puntos de partida razonables. Al mezclar prefill con uso intensivo de cómputo y decode con uso intensivo de memoria, se aprovechan simultáneamente el cómputo y la memoria de la GPU, lo que también tiene el efecto secundario de un MFU más alto que el procesamiento individual.
PagedAttention
PagedAttention es un método que gestiona la caché KV dividiéndola en páginas de tamaño fijo (típicamente con 16 tokens), y es el núcleo de vLLM. Reduce drásticamente la fragmentación de memoria y obtiene una capacidad efectiva 2-4 veces mayor en términos de uso de memoria física. A 2026, no solo vLLM sino también la mayoría de TensorRT-LLM, SGLang y DeepSpeed-Inference adoptan mecanismos de paginación similares.
PagedAttention también es importante como base para el "prefix sharing": múltiples requests que usan el mismo system prompt referencian la misma página, por lo que físicamente se mantiene una sola KV. Sin embargo, el prefix caching de vLLM original está en "unidades de prefix que coinciden exactamente", y los sistemas como RadixAttention tienen ventaja en la optimización de coincidencias parciales y entre tenants.
RadixAttention
RadixAttention, propuesta por SGLang, gestiona la caché KV con una estructura de árbol radix, haciendo posible compartir "cualquier fragmento de prefix arbitrario". Detecta automáticamente estructuras de intercambio anidadas como system prompt, ejemplos few-shot, definiciones de herramientas y contexto común de tenants, y consolida la KV física en un solo lugar.
En benchmarks de medición real, en el chat multi-turno que incluye system prompt compartido (promedio de 8 turnos, 256 sesiones simultáneas), RadixAttention produce una reducción del 40-60% en el costo de prefill en comparación con el prefix caching de vLLM, y una mejora del 30-45% en el TTFT mediano. En cargas de trabajo de agentes que incluyen definiciones largas de herramientas, hay casos donde la diferencia es de 2-3x.
Por otro lado, el diseño de la política de eviction es difícil, y si se aplica LRU de forma simple, el TTFT se dispara cuando tenants activos e inactivos se intercambian. En KGA, según la situación, seleccionamos entre LRU ponderado con prioridad asignada por tenant, o hard partitioning que asigna particiones de tenant de forma fija.
Sorted Batching
Sorted batching es una estrategia de "agrupar requests con longitudes de entrada o de salida restante similares en el mismo batch". El continuous batching naive produce ineficiencias de padding y padding mask cuando se mezclan largas y cortas, pero sorted batching alivia esto. A 2026, es más una funcionalidad implementada por el enrutador/scheduler de la capa superior que una función implementada de forma estándar en los frameworks de serving.
El diseño de separar endpoints dedicados para respuestas cortas (clasificación, reranking, summarization corta) y endpoints para respuestas largas (generación de reportes, generación de código de formato largo) y aplicar sorted batching en cada uno es el más simple, con mejoras medibles de effective throughput del 20-35%.
Resumen del impacto en los SLO
- TTFT: chunked prefill y prefix caching/RadixAttention son dominantes. Si están ambos presentes, el TTFT p50 está alrededor de 100 ms, y el p99 también se puede mantener por debajo de 500 ms.
- ITL: continuous batching y chunked prefill son efectivos. Sin chunked prefill, el ITL p99 puede superar fácilmente los 200 ms.
- Throughput: se maximiza con el conjunto de tres puntos: lograr eficiencia de memoria con PagedAttention, rellenar slots con continuous batching, y eliminar el desperdicio de prefill con RadixAttention.
- Cola p99: se protege con sorted batching y control de admisión. En picos de QPS, se necesita una política de admisión que ponga en cola los requests de baja prioridad.
Estrategia de caché de prompts
Cuando se diseña la caché de prompts en un stack de producción, hay cuatro ejes.
System prompt sharing. El system prompt común a todos los tenants se precalienta al inicio para que permanezca residente. Con RadixAttention, el estándar es lanzar una solicitud de `warmup` en el script de inicio para cargarlo en el árbol KV.
Tenant partitioning. En el caso de multi-tenant mezclado tipo SaaS, que el contexto del tenant A y el tenant B se mezclen puede ser problemático desde la perspectiva de seguridad/compliance. Dado que RadixAttention no es un aislamiento criptográfico, en dominios estrictos como finanzas y salud, es necesario un diseño que aísle los procesos (o grupos de GPU) por tenant y limite la capa compartida a "solo el system prompt no confidencial".
TTL y eviction. Para agentes de chat con sesiones largas, es efectivo el diseño de guardar la KV intermedia de la conversación multi-turno en una caché temporal y evictarla N minutos después de la interrupción de la conversación. En los casos de clientes de KGA, el TTL se configura en 15-30 minutos para equilibrar la presión de memoria y el costo de re-prefill.
Cross-request dedup. En sistemas de agentes, hay muchos patrones donde la misma respuesta de herramienta se pasa a múltiples llamadas de LLM, y al hacer dedup de esta respuesta de herramienta por huella digital y cargarla solo una vez en el árbol KV, el TTFT se reduce en más del 30%.
Ejemplo de configuración: vLLM + chunked prefill + prefix caching
```python llm = LLM( model="Qwen/Qwen3-72B-Instruct", tensor_parallel_size=8, kv_cache_dtype="fp8", enable_prefix_caching=True, enable_chunked_prefill=True, max_num_batched_tokens=8192, max_num_seqs=256, gpu_memory_utilization=0.92, block_size=16, preemption_mode="recompute", ) ```
Si `max_num_seqs` se vuelve demasiado grande, el swap se produce frecuentemente por presión de memoria, por lo que en operaciones reales se calcula hacia atrás a partir de los supuestos de QPS y la longitud de salida p99. Como valor empírico de KGA, QPS_pico × longitud_salida_p99 / tasa_decode_esperada se convierte aproximadamente en el límite superior.
Resumen
La estrategia de batching no es algo donde "se elige una de las cinco técnicas individualmente", sino que "la respuesta correcta de 2026 es incluir todo y ajustar los parámetros según los SLO". Si se quiere proteger el TTFT, chunked prefill y RadixAttention; si se quiere proteger el ITL, chunked prefill y sorted batching; si se quiere aumentar el throughput, continuous batching y PagedAttention; si se quiere proteger el aislamiento de tenants, hard partitioning y eviction consciente del tenant. Diseñando la arquitectura en estos cuatro ejes, es perfectamente posible alcanzar el SLO de aggregate 2500 tok/s y TTFT p99 dentro de 400 ms incluso con un modelo de 70B en una configuración de 8 GPUs H200 SXM.