Un paper publié sur Hugging Face présente FlashRT, un système qui utilise un agent de coding pour optimiser le développement d’applications multimodales en temps réel : agent vocal, génération vidéo interactive, pipelines où différents modèles doivent être chaînés sur plusieurs GPU.

Le problème opérationnel est connu de ceux qui mettent à l’échelle ces systèmes en production. Il ne suffit pas d’avoir de bons modèles : tu dois décider où faire tourner chaque morceau (placement), comment faire circuler les données entre un modèle et l’autre (streaming), et comment paralléliser à l’intérieur de chaque modèle. Aujourd’hui, ces décisions sont prises manuellement par un expert, pour chaque application.

FlashRT confie ce travail à un agent de coding. Il prend une implémentation de référence écrite par le développeur, la transforme en une représentation intermédiaire, la valide avec un interprète, puis essaie itérativement différentes optimisations en mesurant les résultats sur le matériel. Selon le paper (publié le 20 juillet 2026), sur GPU NVIDIA B200, il obtient jusqu’à 70x de réduction de latence et 2.8x de débit. Sur AMD MI355X, où l’optimisation experte est moins mature, il atteint 3.6x de débit et surpasse l’implémentation experte de vLLM-Omni de 65% sur la latence.

Cela poursuit le fil que nous avons déjà raconté : dans les systèmes agentiques en production, l’orchestration compte plus que le modèle. Ici, l’idée va plus loin. L’agent n’orchestre pas seulement le runtime, il optimise le déploiement lui-même.

En détail

Ce qu’il y avait avant.

Les systèmes de serving modernes (vLLM, TensorRT-LLM et similaires) optimisent l’inférence d’un seul modèle. Quand tu combines des modèles hétérogènes dans un pipeline, comme le fait un agent vocal (ASR, LLM, TTS), les décisions d’optimisation deviennent spécifiques à l’application : où placer chaque modèle, comment faire circuler les données en streaming entre l’un et l’autre, comment paralléliser chaque modèle en interne. Les compilateurs d’auto-parallélisme existants reposent sur des hypothèses fixes sur la charge de travail et des transformations limitées. Résultat : pour chaque nouvelle application, un expert doit réécrire l’implémentation à la main.

Comment fonctionne FlashRT.

FlashRT est un harness, une imbracature pour les agents de coding. Le processus comprend quatre phases :

1. L’agent transforme le code de référence en une représentation intermédiaire (IR) qui capture les dépendances entre les données et les portées d’état persistant.
2. Un interprète séquentiel valide cette IR : la fait tourner pour vérifier qu’elle fait ce qu’elle doit faire.
3. L’agent exécute des analyses statiques pour identifier les transformations candidates (différentes façons de placer, paralléliser, faire circuler les données).
4. Pour chaque candidate, l’agent implémente, vérifie et mesure dans une boucle itérative guidée par les résultats concrets (latence, débit) sur le matériel cible.

La nouveauté réside dans le fait d’avoir délégué à un agent générique de coding le travail qui nécessitait autrefois un expert en systèmes pour chaque application. Les auteurs appellent cette approche « chain-of-program » : l’agent reçoit des instructions structurées sur comment transformer le code, pas un prompt libre.

Les chiffres en contexte.

Les résultats annoncés par le paper :

• Sur NVIDIA B200 : jusqu’à 70x de réduction de latence et 2.8x d’amélioration du débit, sur des applications incluant les world models vidéo et les LLM multimodaux.
• Sur AMD MI355X : même réduction de latence de crête, 3.6x de débit. Pour Qwen3-Omni text-to-audio, 65% de latence en moins par rapport à l’implémentation experte de vLLM-Omni.

Le chiffre sur AMD est le plus intéressant. Sur les plateformes où l’optimisation manuelle est moins mature, l’approche agentique rattrape plus de terrain. C’est un signal que l’optimisation guidée par l’agent évolue mieux là où manquent des années de travail experte accumulée.

Limites.

Le paper est sorti il y a quelques jours et a un upvote sur Hugging Face Daily Papers : la couverture indépendante est encore minime. Les chiffres sont auto-déclarés par les auteurs, mesurés sur un matériel spécifique (B200, MI355X) qui n’est pas accessible à tout le monde. Le repo est public sur GitHub, mais il n’est pas clair à quel point il est simple de reproduire les résultats en dehors des benchmarks du paper. Comme toujours avec les papers de systèmes, la vraie preuve arrive quand d’autres essaient de l’utiliser sur leur propre pipeline.