MapFlow, de l'Université de Pékin, permet aux modèles de réutiliser l'attention des uns et des autres

Les agents multimodèles sont devenus une architecture courante. Le modèle A planifie, le modèle B détaille et rédige la synthèse. Les questions complexes vont au modèle puissant, les simples reviennent au modèle léger et peu coûteux. L'idée est claire : la qualité là où elle est nécessaire, l'économie là où elle est possible. Mais ce schéma comporte un poste de dépenses caché, dont on parle rarement dans les présentations.

Où l'argent se perd

Imaginez un scénario typique. Un grand modèle vient de traiter un long document : un contrat, une base de code ou un export de logs. Il a construit une représentation interne du texte et la conserve dans le cache KV. Puis un petit modèle entre en jeu. Il doit répondre à une question de précision ou mettre en forme le rapport final. Le cache du grand modèle ne lui convient pas : une autre architecture implique d'autres dimensions, d'autres couches et d'autres têtes d'attention. Le petit modèle refait donc honnêtement passer le même document depuis zéro et dépense du temps et de l'argent en préremplissage.

Sur des requêtes courtes, cela passe inaperçu. Sur un long contexte, avec plusieurs transmissions pour une même tâche et un grand flux d'utilisateurs, le préremplissage répété représente une part sensible de la latence et de la facture GPU. En clair, vous payez plusieurs fois pour une seule lecture, une fois pour chaque modèle de la chaîne.

Ce que propose MapFlow

L'équipe de l'Université de Pékin a présenté MapFlow. D'après le titre et le début de la description, l'idée est de ne pas tout recalculer, mais de réutiliser l'attention entre modèles. Au lieu de recalculer côté modèle récepteur, les résultats déjà obtenus par le modèle précédent sont projetés dans son espace.

Par analogie : un collègue a rédigé des notes détaillées sur un long document ; vous ne relisez pas l'original, vous traduisez ses notes dans votre langage et vous travaillez avec elles. Le nom semble refléter la même idée : « map » pour la projection, « flow » pour le flux d'information d'un modèle à l'autre.

Une réserve importante. Dans l'extrait dont nous disposons, on ne trouve ni le mécanisme concret de projection, ni chiffres sur l'accélération et la perte de qualité, ni liste des paires de modèles prises en charge. Ces détails sont décisifs, il est donc trop tôt pour juger de l'utilité pratique de la méthode. Pour l'instant, on peut dire que la direction est la bonne et que le problème est réel.

Pourquoi c'est important en pratique

Le coût des systèmes agentiques est déterminé surtout non par un appel de modèle isolé, mais par le nombre de répétitions du contexte entre les appels. Aujourd'hui, pour économiser en partie, on dispose du cache de préfixes au sein d'un même modèle et des familles de modèles partageant un tokenizer. Un transfert d'attention inter-modèles couvrirait le cas où la chaîne comprend des modèles différents, par exemple un grand pour la planification et un petit pour l'exécution.

Si la méthode fonctionne en conditions réelles, trois groupes en profiteront :

• les équipes dont les agents travaillent sur de longs documents et des dépôts de code, où le contexte est lu à de multiples reprises ;
• les services avec routage « modèle puissant — modèle faible », où le handoff a lieu à chaque requête ;
• les fournisseurs d'inférence, pour qui le préremplissage coûte cher.

Limites et que faire dès maintenant

Les principales questions posées à toute méthode de ce type sont connues d'avance. Quelle qualité est perdue lors de la projection entre architectures différentes ? Faut-il réentraîner un adaptateur pour chaque paire de modèles ? L'approche est-elle compatible avec les moteurs d'inférence populaires comme vLLM et SGLang ? Et que se passe-t-il côté mémoire s'il faut conserver le cache d'un modèle pendant que l'autre travaille ? Tant que les réponses manquent, on ne l'envoie pas en production.

La conclusion pratique pour le développeur est simple et n'exige pas d'attendre l'article complet. Mesurez combien de tokens votre agent préremplit de nouveau lors du passage entre modèles, et quelle part de la latence et du coût cela représente. Si cette part est notable, suivez MapFlow et les travaux apparentés. Si vos contextes sont courts, le problème ne vous concerne pas encore et il n'y a rien à optimiser ici.

En attendant des détails et des résultats reproductibles, considérez MapFlow comme un signal : le marché se heurte au coût de la relecture, et les chercheurs commencent à chercher des solutions au niveau de l'attention elle-même, et pas seulement au niveau des proxys de cache et des prompts.