Appearance
DualPath: el cuello de botella oculto en la inferencia de agentes LLM
El verdadero cuello de botella no es el que crees
Los sistemas modernos de inferencia LLM enfrentan una restricción inesperada: no es el cómputo lo que es lento, es el movimiento de datos. Esto se vuelve dolorosamente obvio cuando escalas un sistema agéntico, donde los agentes de IA iteran a través de múltiples pasos de razonamiento, llamando herramientas y actualizando contexto. Cada turno requiere que ventanas de contexto masivas sean cargadas, procesadas y mantenidas sincronizadas entre GPUs. El cómputo en sí termina rápidamente, pero el sistema espera a que los datos lleguen desde el almacenamiento externo.
Para entender por qué las ventanas de contexto masivas son tanto una bendición como una maldición, consulta nuestro artículo El mito del contexto infinito: por qué el problema no son solo los tokens.
Este problema se revela gradualmente a medida que añades más agentes concurrentes a un sistema. Inicialmente, añadir agentes aumenta el rendimiento porque las GPUs que estaban ociosas ahora tienen trabajo. Pero en algún punto alrededor de 512 a 1.024 agentes concurrentes, añadir más deja de ayudar. El cuello de botella ya no es el cómputo; son los enlaces de red que alimentan datos desde el almacenamiento hacia los motores de procesamiento.
El rendimiento se estabiliza a medida que el tamaño del lote crece, revelando que algo distinto al cómputo GPU limita el rendimiento.
El culpable específico es el KV-Cache: los tensores de clave y valor almacenados que reducen la recomputación durante la inferencia. Para cargas de trabajo agénticas con contextos de 30K a 64K tokens, esta caché es enorme. Cargarla desde el almacenamiento a las GPUs domina la latencia total. Cuando tienes cientos de agentes ejecutándose simultáneamente, todos necesitando su KV-Cache aproximadamente al mismo tiempo, una sola ruta de red se convierte en un punto de estrangulamiento.
Hemos explorado en profundidad el problema del KV-Cache en Compactación rápida del KV Cache mediante Attention Matching: contextos largos al fin viables.
Por qué los sistemas actuales desperdician recursos
La mayoría de los sistemas de inferencia desplegados usan una arquitectura desagregada: algunas GPUs se especializan en la etapa de prefill (procesar el contexto completo del agente para computar los estados de atención iniciales), mientras que otras se especializan en la decodificación (generar uno o pocos tokens nuevos a la vez). Esta separación tiene sentido para la eficiencia, pero crea un desequilibrio de recursos en cómo se usa el ancho de banda de almacenamiento.
Todos los datos del KV-Cache fluyen a través de una sola ruta: desde el almacenamiento externo directamente a los motores de prefill. Las interfaces de red en el lado de prefill se saturan, trabajando a máxima capacidad. Mientras tanto, las interfaces de red de almacenamiento en el lado de decode permanecen mayormente ociosas. Has invertido en hardware y conectividad de red costosa para esos motores de decode, pero apenas tocan la red de almacenamiento.
Este es el tipo de desperdicio que es difícil de detectar en los diseños tempranos. El sistema sigue funcionando; simplemente no está usando lo que has pagado.
Izquierda: La arquitectura actual fuerza todo el KV-Cache a través de las NICs de almacenamiento de prefill, dejando las NICs de almacenamiento de decode infrautilizadas. Derecha: DualPath distribuye la carga.
La idea DualPath: dejar de forzar todo por el mismo camino
La idea central es engañosamente simple: deja de forzar todos los datos del KV-Cache por la misma ruta. En su lugar, carga parte de ellos directamente en los motores de decode. Esos motores luego transfieren lo que los motores de prefill necesitan a través de una ruta de red secundaria.
Esto suena como si pudiera complicar las cosas, pero en realidad resuelve múltiples problemas.
Primero, distribuye la demanda de ancho de banda de almacenamiento. Los motores de prefill y decode ahora comparten el trabajo de lectura desde el almacenamiento, así que ningún lado se satura.
Segundo, las transferencias entre motores usan RDMA sobre la red de cómputo, que está construida para alto rendimiento y no interfiere con las comunicaciones sensibles a latencia que requiere la ejecución GPU. La red de almacenamiento y la red de cómputo operan independientemente, así que mover datos por una ruta no obstruye la otra.
El avance fundamental está en reformular el problema. En lugar de "nuestra red de almacenamiento está congestionada", el sistema ahora enfrenta "¿cómo enrutamos datos eficientemente entre motores?" Eso es un problema de scheduling, y los problemas de scheduling son resolubles.
Esta mentalidad de repensar la arquitectura en lugar de simplemente escalar recursos es la misma filosofía detrás de Más grande ya no escala: activar solo lo necesario.
Orquestando múltiples rutas de datos
Tener dos rutas solo funciona si el sistema toma decisiones inteligentes sobre qué solicitudes toman qué camino. Un planificador global resuelve continuamente un pequeño problema de optimización en tiempo real: dada la carga actual en las NICs de almacenamiento del lado de prefill, la capacidad disponible en el lado de decode, y el overhead de las transferencias entre motores, ¿qué solicitudes entrantes deberían cargar su KV-Cache por qué ruta?
El planificador opera a granularidad de solicitud, tomando decisiones a medida que llegan nuevas solicitudes de agentes. Considera:
- La carga a través de los motores de prefill y decode
- La capacidad de red entre grupos de motores
- Un margen de seguridad para evitar congestión
Si las NICs de almacenamiento de decode tienen capacidad libre, algo del trabajo de prefill se enruta a través de decode primero. Si esas NICs también están saturadas, las solicitudes van directamente a prefill como antes.
Más allá de la decisión de enrutamiento global, el sistema también gestiona la carga dentro de clústeres GPU individuales. Un mecanismo de cuota de cómputo asegura que el trabajo de prefill y decode no se maten de hambre mutuamente en hardware compartido. Si una GPU tiene ciclos disponibles, el planificador equilibra entre procesar nuevas solicitudes de prefill y continuar el trabajo de decodificación ya en vuelo. Esto previene que un tipo de operación monopolice recursos y deje al otro ocioso.
El planificador global selecciona qué motor de prefill recibe datos, considerando la distribución de carga y la capacidad de red disponible.
El rol del planificador es crucial. Sin él, las rutas duales crean caos de scheduling. Con él, el hardware infrautilizado se convierte en una herramienta para reequilibrar el sistema.
Rendimiento en cargas de trabajo de producción
Las pruebas de DualPath en cargas de trabajo agénticas reales revelan mejoras sustanciales. La evaluación cubre tres modelos: DeepSeek 27B y 660B, y Qwen 32B. Cada prueba simula agentes con contextos que van desde 30K a 64K tokens, añadiendo nuevo contexto y generando output en múltiples rondas, creando patrones de solicitud multi-turno realistas.
Resultados offline
Los resultados muestran ganancias de rendimiento en todas las configuraciones:
| Configuración | Mejora DualPath |
|---|---|
| 1.024 agentes concurrentes, contexto 64K, modelo grande | Hasta 1,87x |
| Modelos pequeños y medianos | Mejora consistente |
| Diferentes tamaños de lote | Ganancias sostenidas |
N/A indica que el sistema base no pudo completar la prueba. DualPath maneja escenarios donde la arquitectura original falla.
Los resultados varían con cómo configuras la ratio prefill-decode (cuántas GPUs asignas a cada etapa). DualPath se beneficia más cuando ambos grupos de motores tienen algo de capacidad ociosa, dando al planificador espacio para enrutar alrededor del cuello de botella. A medida que la ratio se desplaza fuertemente hacia un lado, la mejora decrece porque el desequilibrio se convierte en la restricción en lugar de la saturación de ancho de banda.
Robustez ante patrones variables
Los patrones de contexto variables muestran que la optimización es robusta:
- Ya sea que los agentes añadan 100 tokens o 1.000 tokens a su contexto
- Ya sea que la longitud de generación sea 64 o 256 tokens
- DualPath mantiene su ventaja en todos los casos
Esta consistencia importa porque las cargas de trabajo reales son heterogéneas.
Servicio online
Para servicio online, donde las solicitudes llegan continuamente y los sistemas deben cumplir SLOs de latencia, DualPath promedia una mejora de rendimiento de 1,96x sin violar los objetivos de latencia:
- Time-to-first-token (tiempo hasta el primer token): dentro de límites aceptables
- Time-to-first-scheduled-token: dentro de límites aceptables
- Time-per-output-token: dentro de límites aceptables
Todo se mantiene conforme mientras las tasas de llegada aumentan.
Si estás evaluando cómo desplegar estos modelos en tu propia infraestructura, consulta nuestra guía completa Los 10 mejores LLMs locales en Quad NVIDIA DGX Spark, donde el ancho de banda de almacenamiento es exactamente el tipo de cuello de botella que DualPath resuelve.
Principios de diseño que generalizan
DualPath tiene éxito porque reconoce una dinámica fundamental: cuando un recurso se convierte en cuello de botella y otro permanece ocioso, la restricción no es el recurso escaso en sí, es la suposición de que todo el tráfico debe usar el mismo camino. El sistema no necesitaba hardware nuevo; necesitaba permiso para enrutar alrededor del cuello de botella.
Este patrón se extiende más allá de la inferencia. Muchos sistemas distribuidos tienen cuellos de botella asimétricos que persisten no porque sean irresolubles, sino porque el enrutamiento directo se volvió canónico tempranamente. Un buen sistema pregunta: ¿qué pasa si el hardware infrautilizado se convierte en una estación intermedia?
La lección más amplia es que los cuellos de botella de E/S en sistemas a gran escala son frecuentemente problemas de scheduling disfrazados. Cuando el ancho de banda de almacenamiento se agota en una parte de la red mientras otra parte permanece tranquila, la restricción real es cuán inteligentemente puedes distribuir solicitudes entre los recursos disponibles. DualPath demuestra que incluso en sistemas de inferencia especializados y de alto rendimiento, un mejor planificador puede reclamar casi 2x del rendimiento desperdiciado.
Este principio de repensar la arquitectura de memoria en agentes es central también en La Arquitectura Ausente en la IA Agentiva: la Memoria.
Para los investigadores que construyen sistemas de IA a gran escala, la lección es medir los cuellos de botella reales en lugar de asumirlos. La utilización de GPU se ve bien hasta que mides los patrones de E/S de almacenamiento. La utilización de red se ve equilibrada hasta que segmentas por tipo de tráfico y fuente. DualPath emergió porque alguien midió la asimetría y preguntó si era inevitable.
Implicaciones para el despliegue agéntico
Este trabajo tiene implicaciones directas para cualquiera que opere sistemas de agentes de IA en producción:
Audita tu ancho de banda de almacenamiento. Antes de comprar más GPUs, verifica si tus NICs de almacenamiento están saturadas. Podrías estar pagando por cómputo que nunca puede alimentarse a velocidad completa.
Separa tus redes. La red de almacenamiento y la red de cómputo deben ser independientes. DualPath explota esta separación; si tus redes están mezcladas, pierdes la ventaja.
Invierte en scheduling inteligente. El hardware ocioso no es necesariamente desperdicio — puede ser capacidad de reserva para enrutar alrededor de cuellos de botella. La clave es un planificador que sepa cuándo y cómo usarlo.
Mide antes de escalar. La suposición de que "más GPUs = más rendimiento" se rompe cuando el cuello de botella está en otra parte. Instrumenta tu sistema para identificar dónde realmente se detiene el flujo de datos.
Para un enfoque complementario sobre cómo gestionar el contexto de los agentes de manera eficiente, lee Context Engineering: La Arquitectura de la IA Confiable.
Conclusión
DualPath no es un truco de hardware ni una optimización marginal. Es un cambio conceptual: reconocer que en los sistemas de inferencia agéntica, el movimiento de datos — no el cómputo — es el recurso escaso, y que los recursos existentes pero ociosos pueden convertirse en la solución.
Con hasta 1,96x de mejora de rendimiento sin hardware adicional, DualPath demuestra que la próxima generación de optimizaciones de inferencia no vendrá de chips más rápidos, sino de una orquestación más inteligente del flujo de datos.
Para el ecosistema de agentes de IA que está madurando rápidamente — desde OpenClaw hasta los sistemas empresariales multi-modelo — entender y resolver estos cuellos de botella ocultos será la diferencia entre sistemas que escalan y sistemas que se estancan.
Referencias
- DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference. Resumen vía AIModels.fyi.
- NVIDIA. "NCCL: NVIDIA Collective Communications Library." nvidia.com, 2025.
- vLLM Project. "High-Throughput LLM Serving with Paged Attention." vllm.ai, 2025.
- DeepSeek. "DeepSeek-V3 Technical Report." deepseek.com, 2025.
- Alibaba Cloud / Qwen Team. "Qwen3.5 Model Family." qwen.ai, 2026.