Un paper publicado en Hugging Face presenta FlashRT, un sistema que usa un agente de codificación para optimizar el desarrollo de aplicaciones multimodales en tiempo real: agentes de voz, generación de video interactiva, pipelines donde modelos distintos se concatenan en múltiples GPU.

El problema operativo es conocido para quien escala estas cosas en producción. No basta tener buenos modelos: tienes que decidir dónde hacer correr cada pieza (colocación), cómo hacer fluir los datos entre un modelo y otro (streaming), y cómo paralelizar dentro de cada modelo individual. Hoy estas decisiones las toma un experto a mano, para cada aplicación.

FlashRT hace este trabajo con un agente de codificación. Toma una implementación de referencia escrita por el desarrollador, la transforma en una representación intermedia, la valida con un intérprete, y luego prueba iterativamente distintas optimizaciones midiendo resultados en el hardware. Según el paper (publicado el 20 de julio de 2026), en GPU NVIDIA B200 consigue hasta 70x de reducción de latencia y 2.8x de throughput. En AMD MI355X, donde la optimización experta es menos madura, llega a 3.6x de throughput y supera la implementación experta de vLLM-Omni en 65% de latencia.

Esto continúa el hilo que ya hemos contado: en los sistemas agentivos en producción, la orquestación importa más que el modelo. Aquí la idea va más allá. El agente no solo orquesta el runtime, optimiza el despliegue mismo.

En detalle

Qué había antes.

Los sistemas de serving modernos (vLLM, TensorRT-LLM y similares) optimizan la inferencia de un único modelo. Cuando combinas modelos heterogéneos en un pipeline, como hace un agente de voz (ASR, LLM, TTS), las decisiones de optimización se vuelven específicas de la aplicación: dónde colocar cada modelo, cómo hacer fluir los datos en streaming entre uno y otro, cómo paralelizar cada modelo internamente. Los compiladores de auto-paralelismo existentes se basan en suposiciones fijas sobre la carga de trabajo y en transformaciones limitadas. Resultado: para cada nueva aplicación, un experto debe reescribir la implementación a mano.

Cómo funciona FlashRT.

FlashRT es un harness, un arnés para agentes de codificación. El proceso tiene cuatro fases:

1. El agente transforma el código de referencia en una representación intermedia (IR) que captura las dependencias entre los datos y los scopes de estado persistente.
2. Un intérprete secuencial valida esta IR: la hace correr para verificar que hace lo que debe.
3. El agente ejecuta análisis estáticos para identificar transformaciones candidatas (distintas formas de colocar, paralelizar, hacer fluir los datos).
4. Para cada candidata, el agente implementa, verifica y mide en un ciclo iterativo guiado por resultados concretos (latencia, throughput) en el hardware target.

La novedad está en haber delegado a un agente genérico de codificación el trabajo que antes requería un experto de sistemas para cada aplicación. Los autores llaman a este enfoque “chain-of-program”: el agente recibe instrucciones estructuradas sobre cómo transformar el código, no un prompt libre.

Los números en contexto.

Los resultados declarados por el paper:

• En NVIDIA B200: hasta 70x de reducción de latencia y 2.8x de throughput mejorado, en aplicaciones que incluyen video world model y LLM multimodales.
• En AMD MI355X: misma reducción de latencia máxima, 3.6x de throughput. Para Qwen3-Omni text-to-audio, 65% menos de latencia que la implementación experta de vLLM-Omni.

El dato en AMD es el más interesante. En plataformas donde la optimización manual es menos madura, el enfoque agentico recupera más terreno. Es una señal de que la optimización guiada por agente escala mejor donde faltan años de trabajo experto acumulado.

Limitaciones.

El paper salió hace pocos días y tiene un upvote en Hugging Face Daily Papers: la cobertura independiente es aún mínima. Los números son auto-reportados por los autores, medidos en hardware específico (B200, MI355X) que no es accesible para cualquiera. El repo es público en GitHub, pero no está claro cuán simple es reproducir los resultados fuera de los benchmarks del paper. Como siempre con papers de sistemas, la verdadera prueba viene cuando otros lo intentan con su propio pipeline.