🤖 AI

INFRAMIND: Infrastructure-Aware Multi-Agent Orchestration

INFRAMIND es un marco basado en el aprendizaje por refuerzo que optimiza la orquestación de LLM multiagente mediante la adaptación dinámica de la planificación de topología, el enrutamiento de modelos y la programación de solicitudes a las condiciones de infraestructura en tiempo real, mejorando significativamente la precisión, reduciendo la latencia y manteniendo estrictos objetivos de nivel de servicio bajo cargas de alta concurrencia.

Autores originales: Ahasan Kabir, Jiaqi Xue, Mengxin Zheng, Qian Lou

Publicado 2026-06-11

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Ahasan Kabir, Jiaqi Xue, Mengxin Zheng, Qian Lou

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que diriges la cocina de un restaurante con mucho movimiento. Tienes un equipo de chefs (los modelos de IA) con diferentes niveles de habilidad: algunos son chefs maestros que pueden cocinar platos complejos perfectamente pero tardan mucho tiempo, mientras que otros son cocineros de línea rápidos que pueden manejar pedidos sencillos con rapidez.

En la forma en que funcionan la mayoría de los sistemas de IA actualmente (lo que el artículo llama "Ceguera de Infraestructura"), el gerente asigna los pedidos basándose únicamente en lo que el cliente quiere, ignorando el estado actual de la cocina.

El Problema: El Gerente "Ciego"

Si un cliente pide un filete complejo, el gerente envía ciegamente el pedido al Chef Maestro porque ese chef es el mejor haciendo filetes. Pero el gerente no observa que el Chef Maestro ya está sepultado bajo otros 100 pedidos, creando una fila enorme. Mientras tanto, un Cocinero de Línea muy capaz que podría haber manejado el filete sin problemas está de brazos cruzados sin hacer nada, porque el gerente no hace nada.

Esto causa dos grandes problemas:

El Cuello de Botella: La línea del Chef Maestro se vuelve tan larga que el cliente espera 30 minutos por un filete que podría haber estado listo en 5 minutos.
Talento Desperdiciado: El Cocinero de Línea se queda ocioso, aunque podría haber ayudado, porque el gerente nunca verifica si está libre.

En el mundo de la IA, esto sucede cuando múltiples agentes de IA trabajan juntos. Si una IA se queda atrapada en una "cola" (esperando para ser procesada), toda la cadena de razonamiento se ralentiza y el sistema desperdicia costosa potencia de cómputo.

La Solución: INFRAMIND (El Gerente "Inteligente")

El artículo presenta INFRAMIND, un nuevo sistema que actúa como un gerente de cocina superinteligente que observa constantemente el estado en vivo de la cocina. Toma tres decisiones de manera diferente:

1. El Planificador (El Diseñador del Menú)

Forma Antigua: Decide la estructura de la receta basándose solo en el pedido. "Este es un plato complejo, así que necesitamos un plan de 5 pasos con el Chef Maestro".
INFRAMIND: Mira la cocina primero. "El Chef Maestro está saturado. Simplifiquemos el plan. Usaremos una receta más corta y sencilla que el Cocinero de Línea pueda manejar rápidamente".
Analogía: Si la cocina es caótica, el gerente cambia de un menú de degustación de 10 tiempos a un sándwich rápido y delicioso. Si la cocina está tranquila, lo da todo con la elegante comida de 10 tiempos.

2. El Ejecutor (El Corredor de Pedidos)

Forma Antigua: Envía cada solicitud al "mejor" modelo, independientemente de qué tan ocupado esté.
INFMIND: Revisa la fila en cada paso. "La línea del Chef Maestro está llena, pero la del Cocinero de Línea está vacía. Enviemos este paso al Cocinero de Línea. Además, como ahorramos tiempo al saltarnos la larga fila, pidámosle al Cocinero de Línea que piense un poco más profundamente ('DeepThink') para asegurar que la respuesta siga siendo de alta calidad".
Analogía: En lugar de obligar a un cliente a esperar en una larga fila para un VIP, el gerente lo dirige a un carril rápido donde hay un miembro del personal capaz esperando, asegurando que obtenga un gran resultado sin la espera.

3. El Programador (La Lista de Prioridades)

Forma Antigua: Primero en llegar, primero en ser atendido. Si un cliente con un plazo de 5 minutos llega después de un cliente con un plazo de 1 hora, el lento es atendido primero.
INFRAMIND: Utiliza la regla de "El Plazo Más Próximo Primero" (Earliest Deadline First). Observa el límite de tiempo del cliente. "¡Este cliente necesita la comida en 2 minutos! Pásenlo al frente de la fila, incluso si llegó después".
Analogía: Es como el triaje de una sala de emergencias. La persona con la necesidad más urgente es tratada primero, no la que llegó primero.

Los Resultados: Por Qué Importa

El artículo probó este sistema en cinco tareas difíciles diferentes (como matemáticas, programación y acertijos de lógica) bajo distintos niveles de tráfico (desde una cocina tranquila hasta una hora punta).

Con Tráfico Bajo: INFRAMIND fue más preciso que los sistemas antiguos porque sabía que tenía tiempo extra y podía usar a los "Chefs Maestros" para un pensamiento profundo. También fue hasta 7 veces más rápido.
Con Tráfico Alto (La Hora Punta): Aquí es donde los sistemas antiguos fallaron. Seguían enviando pedidos a los mismos chefs ocupados, haciendo que las líneas se volvieran tan largas que el sistema colapsaba (el 99% de las solicitudes no lograban terminar a tiempo). INFRAMIND, sin embargo, mantuvo la cocina funcionando sin problemas. Mantuvo una tasa de éxito del 99.9% incluso cuando los otros sistemas caían por debajo del 50%.

La Conclusión

INFRAMIND corrige la "ceguera" de los sistemas de IA actuales. No solo pregunta: "¿Qué IA es la más inteligente?". Pregunta: "¿Qué IA es la más inteligente Y está disponible ahora mismo?". Al observar el tráfico y las colas en tiempo real, equilibra la velocidad y la calidad automáticamente, asegurando que los sistemas de IA no se queden atrapados en atascos incluso cuando están bajo una carga pesada.

Resumen Técnico: INFRAMIND

1. Declaración del Problema: Ceguera de Infraestructura

Los sistemas actuales de orquestación de modelos de lenguaje de gran tamaño (LLM) multi-agente sufren un modo de fallo crítico denominado ceguera de infraestructura. Si bien los métodos existentes (por ejemplo, MoA, GPTSwarm, MasRouter) han avanzado en el aprendizaje de topologías y selección de modelos adaptables a la tarea basados en características estáticas de la consulta, operan sin observar el estado de ejecución de la infraestructura de servicio.

En clústeres de GPU compartidos que sirven múltiples modelos (por ejemplo, a través de vLLM o SGLang), esta ceguera conduce a una subutilización sistemática de recursos y explosiones de latencia:

Desequilibrio de Colas: Los modelos "preferidos" acumulan colas de solicitudes profundas mientras que alternativas igualmente capaces permanecen inactivas.
Retrasos Compuestos: En los flujos de trabajo multi-agente, un cuello de botella en cualquier paso retrasa a cada agente descendente, causando que la latencia se multiplique.
Decisiones Estáticas: Las decisiones de enrutamiento se toman basándose en regímenes de información de tiempo de entrenamiento que están desconectados de las condiciones de tiempo de ejecución (profundidad de cola, presión del KV-cache y latencias).
Razonamiento Inflexible: Los sistemas no logran adaptarse a la profundidad del razonamiento (por ejemplo, cambiar de "DeepThink" a "Flash") basándose en la capacidad disponible, dejando recursos ociosos sin aprovechar o sobrecargando los que ya están congestionados.

El desafío central es que las señales de infraestructura son dinámicas y ruidosas, pero deben impulsar tres decisiones acopladas: planificación (topología/roles), enrutamiento por paso (selección de modelo/estrategia) y programación (priorización de colas).

2. Metodología: Marco de Trabajo INFRAMIND

Los autores proponen INFRAMIND, el primer orquestador multi-agente consciente de la infraestructura de extremo a extremo. Integra métricas de sistema en tiempo real en cada capa del stack de orquestación, formulado como un Proceso de Decisión de Markov Restringido (CMDP) y resuelto mediante Aprendizaje por Refuerzo (RL).

Componentes Principales

Planificador Consciente de la Infraestructura:
- Función: Determina la estructura de razonamiento (topología, número de agentes, roles) al llegar la consulta ( $t=0$ ).
- Mecanismo: A diferencia del trabajo previo que depende únicamente de los embeddings de la consulta, el planificador condiciona sus decisiones en un resumen de la carga actual del sistema ( $z_0$ ) y el presupuesto restante.
- Implementación: Utiliza un controlador en cascada donde la Modulación Lineal por Características (FiLM) inyecta vectores de estado del sistema (presupuesto, profundidad de cola, latencia E2E, KV cache) en el embedding de la consulta. Esto sesga al planificador hacia grafos más simples bajo congestión y hacia topologías más ricas cuando hay capacidad disponible.
Ejecutor Consciente de la Infraestructura:
- Función: Selecciona el modelo específico y la estrategia de razonamiento (Flash, Conciso, DeepThink) para cada paso del agente.
- Mecanismo: Opera con una arquitectura de doble vía:
  - Vía Semántica: Procesa la consulta y los embeddings de rol (lo que la tarea necesita).
  - Vía de Recursos: Procesa el presupuesto restante y las métricas de sistema en vivo (lo que el sistema puede entregar).
- Decisión: Fusiona estas señales para seleccionar conjuntamente un modelo y una estrategia. Por ejemplo, si la cola de un modelo grande está saturada, el ejecutor puede redirigir a un modelo más pequeño que esté inactivo y compensar utilizando una estrategia "DeepThink", aprovechando el tiempo ahorrado al saltarse la cola para mantener la precisión.
Programador de Prioridad Consciente del Presupuesto:
- Función: Gestiona el orden de las solicitudes dentro de la cola local de cada modelo.
- Mecanismo: Implementa una política de Fecha Límite Temprana (EDF). A cada consulta se le asigna una fecha límite basada en su tiempo de llegada y presupuesto de tiempo. Cada llamada de agente hereda esta fecha límite.
- Impacto: Evita que las solicitudes con presupuestos ajustados sean bloqueadas por otras más relajadas (bloqueo de cabeza de línea), asegurando que las consultas urgentes sean atendidas primero.

Enfoque de Entrenamiento

Los tres componentes se entrenan conjuntamente como una única política de RL jerárquica bajo una restricción de presupuesto compartida.

Objetivo: Maximizar la calidad (tasa de resolución) sujeto a un presupuesto de latencia.
Optimización: Utiliza un multiplicador de Lagrange ( $\lambda$ ) para descubrir automáticamente el compromiso entre calidad y latencia. El ejecutor utiliza PPO (Optimización de Política Próxima) para trayectorias por paso, mientras que el planificador utiliza REINFORCE sobre los retornos del episodio.
Adaptación: El sistema se entrena a través de diversos niveles de presupuesto y tasas de llegada de Poisson, permitiéndole aprender a adaptarse a diferentes regímenes de congestión.

3. Contribuciones Clave

Identificación de la Ceguera de Infraestructura: El artículo cuantifica empíricamente cómo ignorar el estado de la infraestructura en tiempo de ejecución conduce a desequilibrios de colas, latencias evitables y subutilización de recursos en sistemas multi-agente.
Orquestación de Extremo a Extremo Consciente de la Infraestructura: Introducción de INFRAMIND, que unifica la planificación, la ejecución y la programación en una única política de RL que condiciona sus decisiones en telemetría en tiempo real (profundidad de cola, KV cache, latencia).
Ganancias de Rendimiento: Demostró mejoras significativas en precisión, latencia y cumplimiento de los Objetivos de Nivel de Servicio (SLO) a través de diversos benchmarks y condiciones de carga.

4. Resultados Experimentales

El sistema fue evaluado en cinco benchmarks (MBPP, HumanEval, GSM-Hard, MATH, MMLU-Pro) utilizando un conjunto heterogéneo de cinco modelos (de 3B a 32B de parámetros) servidos en GPUs compartidas.

Carga Baja ( $\mu=10$ req/min): INFRAMIND logró hasta un +7.6 puntos porcentuales (pp) más de precisión que la base más fuerte (MasRouter) mientras reducía la latencia hasta en 7×. Por ejemplo, en MATH, alcanzó un 82.0% de precisión frente al 74.4% de MoA.
Carga Alta ( $\mu=100$ req/min): Aquí es donde el valor del sistema es más pronunciado.
- Cumplimiento de SLO: INFRAMIND mantuvo hasta un 99.9% de cumplimiento de SLO (consultas completadas dentro del presupuesto de 300s) en HumanEval.
- Colapso de las Bases: Todas las bases cayeron por debajo del 50% de cumplimiento de SLO bajo carga alta. MoA y GPTSwarm cayeron por debajo del 12% en la mayoría de los benchmarks, con latencias que superaban los 1,000 segundos.
- Latencia: INFRAMIND mantuvo latencias por debajo de 300s en todos los benchmarks, mientras que las bases migraron hacia zonas de "congestión severa".
Pools de Caja Negra/Híbridos: El enfoque se extendió a pools de solo API y híbridos (mezclando modelos de caja blanca y de API) utilizando proxies del lado del cliente para las señales de congestión. INFRAMIND mantuvo un rendimiento robusto donde las bases colapsaron, demostrando que la conciencia de la infraestructura no requiere acceso privilegiado al servidor, solo una señal correlacionada con la capacidad de respuesta.

5. Significado y Reivindicaciones

El artículo afirma que INFRAMIND aborda una brecha fundamental en los sistemas multi-agente de LLM: la desconexión entre la inteligencia a nivel de tarea y la realidad de la infraestructura. Al hacer de la conciencia de la infraestructura un ciudadano de primera clase en las capas de planificación, ejecución y programación, el sistema equilibra automáticamente la calidad frente a la latencia sin necesidad de reglas codificadas a mano.

Los autores sostienen que este enfoque es crítico para los flujos de trabajo multi-agente de producción que se ejecutan en clústeres de GPU compartidos (por ejemplo, suites internas empresariales o despliegues a escala web), donde la contención de colas y la presión del caché son los principales impulsores de la latencia de cola. El marco se presenta como una solución general que puede desplegarse en diferentes backends de servicio (vLLM, SGLang o proveedores de API) para mejorar significativamente el cumplimiento de los SLO y la utilización de recursos.