🤖 AI

LLM-Rosetta: A Hub-and-Spoke Intermediate Representation for Cross-Provider LLM API Translation

Le papier présente LLM-Rosetta, un framework open-source basé sur une représentation intermédiaire de type « hub-and-spoke » qui permet une conversion bidirectionnelle et transparente entre les API de différents fournisseurs de modèles de langage, résolvant ainsi la fragmentation de l'écosystème tout en garantissant une fidélité sans perte et une faible latence.

Auteurs originaux : Peng Ding

Publié 2026-04-13

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Peng Ding

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous voyagez dans un monde où chaque pays a sa propre langue, sa propre monnaie et ses propres règles de conduite. C'est exactement la situation actuelle avec les Intelligences Artificielles (IA) génératives.

Aujourd'hui, si vous voulez utiliser une IA, vous devez choisir un fournisseur : OpenAI (ChatGPT), Anthropic (Claude), Google (Gemini), etc. Le problème ? Chacun parle une "langue" technique différente. Si vous construisez une application pour OpenAI, elle ne comprendra pas les ordres d'Anthropic. Pour passer de l'un à l'autre, vous devriez théoriquement construire un traducteur spécial pour chaque paire possible (OpenAI vers Anthropic, Anthropic vers Google, etc.). C'est un cauchemar logistique, comme devoir apprendre 10 langues différentes juste pour voyager entre 5 pays.

Voici comment LLM-Rosetta résout ce problème de manière élégante.

🌍 L'Analogie du "Hub-and-Spoke" (Le Rayon de Roue)

Imaginez un grand aéroport international.

Sans LLM-Rosetta : Vous devriez construire des vols directs entre chaque ville. Si vous avez 4 villes (fournisseurs), vous avez besoin de 6 liaisons directes. Si vous en avez 10, c'est 45 liaisons ! C'est le problème de la complexité quadratique ( $O(N^2)$ ).
Avec LLM-Rosetta : On construit un hub central (un grand aéroport de transit). Tous les avions atterrissent d'abord ici, se déchargent, et repartent vers leur destination.
- Au lieu de 45 liaisons, vous n'avez plus besoin que de 10 liaisons (chaque ville vers le hub).
- Ce "Hub", c'est ce qu'on appelle une Représentation Intermédiaire (IR). C'est une "langue neutre" universelle que tous les fournisseurs peuvent comprendre.

🗣️ La Langue Neutre : Le "Rosetta"

Le génie de ce projet, c'est qu'ils ont découvert que, malgré les différences de grammaire (la façon dont les données sont écrites), toutes ces IA parlent en fait la même "langue sémantique".

Peu importe si vous demandez à l'IA d'écrire un poème ou de résoudre un problème de maths, le cœur de la demande est toujours le même :

Qui parle ? (Utilisateur, Système, Assistant).
Quel est le contenu ? (Du texte, une image, un fichier).
Quels outils utiliser ? (Une calculatrice, une recherche web).
Comment répondre ? (Vite, lentement, avec des détails).

LLM-Rosetta a créé un dictionnaire universel (le "Hub") qui capture ces 4 éléments essentiels. Il définit :

9 types de contenu (texte, image, outil, raisonnement, etc.).
10 types d'événements pour gérer le flux de données (comme quand l'IA écrit mot par mot).

🛠️ Comment ça marche ? (Le Traducteur Modulaire)

Au lieu d'avoir un gros traducteur géant et compliqué, LLM-Rosetta utilise une approche modulaire, comme un atelier de mécanique avec des outils spécialisés :

Le Récepteur : Quand une demande arrive (par exemple, de Google), le système la reconnaît.
Le Démontage (Conversion vers le Hub) : Des modules spécialisés démontent la demande de Google :
- Un module s'occupe du texte.
- Un autre s'occupe des images.
- Un autre gère les outils.
- Ils transforment tout cela en la "langue neutre" du Hub.
Le Remontage (Conversion vers la cible) : Si vous voulez envoyer cette demande à Anthropic, d'autres modules reprennent la "langue neutre" et la reconstruisent dans le format qu'Anthropic comprend.

C'est comme si vous achetiez un meuble en kit chez IKEA (le Hub), et que vous aviez des instructions pour le monter soit en version "Scandinave", soit en version "Japonaise", sans avoir à redessiner le meuble entier à chaque fois.

⚡ Pourquoi c'est impressionnant ?

C'est rapide : La traduction prend moins de temps qu'un clignement d'œil (moins de 100 microsecondes). C'est si rapide que vous ne le remarquerez même pas.
C'est fidèle : Le système peut faire un aller-retour parfait. Vous pouvez envoyer une demande à OpenAI, la convertir, puis la reconvertir en OpenAI, et tout sera exactement pareil (y compris les petits détails techniques).
C'est fluide : Même quand l'IA "réfléchit" et écrit mot par mot (streaming), le traducteur suit le rythme sans casser le flux.
C'est déjà utilisé : Ce n'est pas juste une théorie. Ce système est déjà utilisé au Laboratoire National d'Argonne (aux États-Unis) pour permettre aux chercheurs d'utiliser n'importe quelle IA sans changer leur code.

En résumé

LLM-Rosetta est comme un passeport universel et un traducteur simultané pour le monde des IA. Au lieu de forcer les développeurs à apprendre la langue de chaque fournisseur, il leur donne une seule langue commune. Cela rend le monde des IA beaucoup plus ouvert, flexible et facile à utiliser, permettant de changer de fournisseur d'IA aussi facilement que de changer de fournisseur d'électricité.

C'est une solution simple à un problème complexe : ne pas réinventer la roue à chaque fois, mais construire un hub central.

Titre : LLM-Rosetta : Une représentation intermédiaire de type "Hub-and-Spoke" pour la traduction d'API LLM multi-fournisseurs

1. Problématique

L'écosystème des Grands Modèles de Langage (LLM) est actuellement fragmenté. Chaque fournisseur majeur (OpenAI, Anthropic, Google, etc.) expose ses propres formats d'API propriétaires, définissant des schémas distincts pour les messages, les appels d'outils, le streaming et les contrôles de génération.

Le problème de complexité combinatoire ( $O(N^2)$ ) : Pour connecter $N$ fournisseurs entre eux, une approche naïve nécessite de développer $\binom{N}{2}$ adaptateurs bilatéraux. Chaque adaptateur doit gérer la construction des requêtes, l'analyse des réponses, la correspondance des événements de streaming et la sérialisation des appels d'outils.
Conséquences : Cette fragmentation force les développeurs à écrire du code spécifique à chaque fournisseur, rendant la portabilité des applications difficile et entravant l'adoption d'architectures multi-fournisseurs. Les solutions actuelles (comme LiteLLM) utilisent souvent le format d'un seul fournisseur comme "langue franche", ce qui entraîne une perte de fonctionnalités spécifiques aux autres fournisseurs et ne permet pas une conversion bidirectionnelle fidèle.

2. Méthodologie et Architecture

Les auteurs observent que, malgré des divergences syntaxiques importantes, les API LLM partagent un noyau sémantique commun. Le défi pratique réside dans la surface combinatoire des variations syntaxiques, et non dans une incompatibilité sémantique profonde.

Pour résoudre cela, LLM-Rosetta propose une architecture Hub-and-Spoke (Rayon et Moyeu) basée sur une Représentation Intermédiaire (IR) :

Représentation Intermédiaire (IR) :
- C'est un schéma neutre vis-à-vis des fournisseurs, conçu comme l'union des fonctionnalités de tous les fournisseurs supportés.
- Modèle de contenu : Défini par 9 types de parties de contenu (Texte, Image, Audio, Fichier, Appel d'outil, Résultat d'outil, Raisonnement, Refus, Citation).
- Schéma d'événements de streaming : Défini par 10 types d'événements normalisés (début/fin de flux, blocs de contenu, deltas de texte/raisonnement, appels d'outils, statistiques d'usage).
- L'IR capture les messages, les parties de contenu, les appels d'outils, les traces de raisonnement et les contrôles de génération.
Architecture de conversion par composition d'Opérations (Ops-composition) :
- Au lieu d'implémenter un convertisseur monolithique pour chaque fournisseur, le système décompose la logique de conversion en 4 modules orthogonaux :
  1. ContentOps : Conversion des parties de contenu individuelles.
  2. MessageOps : Conversion des séquences de messages (rôles, structure de conversation).
  3. ToolOps : Conversion des définitions et choix d'outils.
  4. ConfigOps : Conversion des paramètres de génération et de configuration.
- Un convertisseur spécifique à un fournisseur est assemblé en combinant des implémentations de ces 4 modules. Cela permet d'ajouter un nouveau fournisseur avec un effort indépendant des fournisseurs existants ( $O(N)$ au lieu de $O(N^2)$ ).
Fonctionnalités clés :
- Conversion bidirectionnelle : Supporte la traduction Requête $\leftrightarrow$ IR $\leftrightarrow$ Réponse.
- Gestion du streaming : Traduction au niveau des chunks (SSE) avec gestion d'état contextuel pour réordonner les événements si nécessaire.
- Modes de métadonnées :
  - Mode "Strip" (par défaut) : Supprime les métadonnées spécifiques au fournisseur pour une IR propre.
  - Mode "Preserve" : Conserve les attributs spécifiques dans des champs dédiés pour permettre des aller-retours sans perte (lossless round-trip).

3. Contributions Clés

Caractérisation empirique : Démonstration que la divergence entre les API majeures est principalement syntaxique et peut être résolue par un noyau sémantique commun.
Architecture modulaire : Introduction du motif de composition d'Opérations (Ops) qui isole les préoccupations spécifiques aux fournisseurs, facilitant la maintenance et les tests unitaires.
Support complet du streaming : Gestion robuste des différences fondamentales dans les schémas d'événements SSE (ex: les deltas implicites d'OpenAI vs les événements typés d'Anthropic).
Implémentation open-source : Un framework complet écrit en Python (environ 23 000 lignes de code) supportant quatre standards : OpenAI Chat Completions, OpenAI Responses, Anthropic Messages et Google GenAI.

4. Résultats et Évaluation

L'évaluation repose sur 1 364 tests unitaires et une validation en production.

Fidélité des aller-retours (Round-trip) :
- En mode "Preserve", LLM-Rosetta garantit une égalité structurelle parfaite (lossless) pour les requêtes et réponses.
- En mode "Strip", toutes les données sémantiques applicatives sont préservées, tandis que les métadonnées internes sont supprimées.
- Le système passe la suite de conformité Open Responses (6 tests) et couvre tous les cas d'usage (texte, multimodal, outils, raisonnement).
Traduction inter-fournisseurs :
- Les tests de conversion croisée (ex: Anthropic $\to$ Google) montrent que le contenu sémantique (texte, rôles, paramètres d'outils) est préservé.
- Les fonctionnalités sans équivalent (ex: cache control d'Anthropic) sont silencieusement ignorées avec des avertissements, mais ne brisent pas la conversion.
Performance :
- Surcharge de conversion : Inférieure à 100 µs (médiane) pour un aller-retour complet. Les requêtes simples prennent 21-24 µs, les conversations complexes jusqu'à 77 µs.
- Comparaison avec LiteLLM : LLM-Rosetta est compétitif. Pour du texte simple, il est même plus rapide (24 µs contre 28 µs pour LiteLLM). Pour des scénarios complexes, la surcharge est de 1,6 à 2,2 fois, mais reste négligeable par rapport au temps de réseau et d'inférence (ms à s).
- La surcharge est négligeable (< 0,01 % de la latence totale).
Déploiement en production :
- Déployé au Argonne National Laboratory dans le cadre du projet Argo-Proxy.
- A permis de remplacer 2 000 lignes de code de mappage ad hoc, offrant une prise en charge bidirectionnelle et un streaming normalisé pour OpenAI, Anthropic et Google.

5. Signification et Impact

LLM-Rosetta représente une avancée significative pour l'interopérabilité des LLM :

Indépendance vis-à-vis des fournisseurs : Il permet aux applications de basculer ou de combiner des fournisseurs sans réécriture majeure du code, brisant le verrouillage fournisseur (vendor lock-in).
Approche sémantique vs syntaxique : Contrairement aux wrappers qui imposent le format d'un fournisseur, LLM-Rosetta définit une norme neutre, préservant les fonctionnalités uniques de chaque fournisseur lors des conversions bidirectionnelles.
Complémentarité : Il ne remplace pas les frameworks d'application (comme LangChain) mais peut servir de moteur de traduction de bas niveau au sein de ceux-ci ou des passerelles API.
Futur : L'architecture est conçue pour évoluer avec l'écosystème. Bien que les modalités non-chat (embeddings, fine-tuning) ne soient pas encore couvertes, le mécanisme d'extension (provider_extensions) permet d'intégrer des fonctionnalités non standardisées.

En conclusion, LLM-Rosetta démontre qu'une représentation intermédiaire bien conçue peut résoudre efficacement le problème de fragmentation des API LLM, offrant une solution robuste, performante et prête pour la production.