🤖 AI

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

Il paper presenta LLM-Rosetta, un framework open-source basato su una rappresentazione intermedia "hub-and-spoke" che traduce bidirezionalmente e senza perdite le API di diversi fornitori di LLM, risolvendo il problema della frammentazione dell'ecosistema con un'overhead di conversione trascurabile.

Autori originali: Peng Ding

Pubblicato 2026-04-13

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Peng Ding

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

🌍 Il Problema: Un mondo di lingue diverse

Immagina di voler viaggiare in tutto il mondo per parlare con i "geni" dell'intelligenza artificiale (i Large Language Models o LLM).
Oggi, ogni grande azienda che crea questi geni (come OpenAI, Anthropic, Google) parla una lingua diversa e usa un dialetto unico per comunicare.

Se vuoi parlare con il "genio" di OpenAI, devi usare il suo dizionario specifico.
Se vuoi parlare con quello di Google, devi imparare un altro dizionario completamente diverso.
Se vuoi parlare con quello di Anthropic, serve ancora un altro manuale.

Il caos attuale:
Se un'azienda vuole usare tutti questi geni contemporaneamente, si trova di fronte a un incubo. Per farli parlare tra loro, dovrebbe costruire un "ponte" (un traduttore) per ogni possibile coppia.

Se ci sono 4 aziende, servono 6 ponti.
Se ci sono 10 aziende, servono 45 ponti!
È come se ogni volta che vuoi ordinare un caffè in una città diversa, dovessi imparare una nuova ricetta per ogni barista, invece di avere un menu universale. Questo rende tutto lento, costoso e fragile: se un barista cambia ricetta, tutti i ponti crollano.

💡 La Soluzione: LLM-Rosetta (Il "Rosetta Stone" Digitale)

Gli autori di questo paper hanno creato LLM-Rosetta, un sistema che risolve questo caos usando un'idea semplice ma potente: il "Hub-and-Spoke" (Il Mozzo e i Raggi).

Immagina un grande Hub centrale (un aeroporto internazionale) e diversi Raggi (i voli) che partono da lì.
Invece di costruire ponti diretti tra ogni città, tutti i viaggiatori atterrano prima in questo aeroporto centrale, dove viene loro data una lingua universale (l'Intermedia Representation o IR), e poi ripartono verso la loro destinazione.

Come funziona in pratica?

La Lingua Universale (L'IR):
Gli autori hanno scoperto che, anche se le "grammatiche" (i formati tecnici) sono diverse, il significato è lo stesso. Tutti i geni AI fanno le stesse cose:
- Ricevono un messaggio (chi parla?).
- Vedono immagini o testo.
- Usano strumenti (come calcolatrici o motori di ricerca).
- Pensano prima di rispondere (il "ragionamento").
LLM-Rosetta crea un dizionario universale che cattura questi concetti fondamentali. Non importa se il fornitore usa la parola "messaggio" o "contenuto", o se mette le immagini in una lista o in un blocco: LLM-Rosetta sa che sono la stessa cosa.
I Traduttori Modulari (Gli "Ops"):
Invece di avere un traduttore gigante e complicato per ogni azienda, LLM-Rosetta usa piccoli mattoncini modulari.
- Un mattoncino traduce solo il testo.
- Un altro traduce solo le immagini.
- Un altro traduce solo gli strumenti.
Per aggiungere un nuovo fornitore (es. una nuova azienda AI), non devi riscrivere tutto il sistema. Basta assemblare questi mattoncini in un nuovo modo. È come costruire con i LEGO: se vuoi aggiungere un nuovo colore, non devi rifare tutto il castello, aggiungi solo quel pezzo.
Andata e Ritorno (Bidirezionalità):
Molti sistemi attuali traducono solo in una direzione (es. da Google a OpenAI). LLM-Rosetta è speciale perché funziona in due direzioni:
- Puoi inviare una richiesta a Google, trasformarla nel formato universale, e poi rimandarla a OpenAI.
- Puoi prendere la risposta di OpenAI, trasformarla e rimandarla a Google.
- Inoltre, gestisce perfettamente le risposte che arrivano a "pezzi" (streaming), come quando un video si carica a scatti, assicurandosi che non si perda nulla.

🚀 Perché è importante?

Velocità: Il sistema è incredibilmente veloce. Traduce le richieste in meno di un millesimo di secondo (100 microsecondi). È così veloce che non ti accorgerai nemmeno che c'è un traduttore in mezzo.
Flessibilità: Se un'azienda cambia il suo formato domani, basta aggiornare il "mattoncino" specifico per quell'azienda, senza rompere tutto il resto.
Realtà: Non è solo teoria. È già usato in un laboratorio nazionale (Argonne National Laboratory) per permettere ai ricercatori di usare diversi AI senza impazzire con la programmazione.

🎭 L'Analogia Finale: Il Ristorante Internazionale

Immagina un ristorante dove i clienti arrivano da tutto il mondo.

Senza LLM-Rosetta: Il cameriere dovrebbe imparare 10 lingue diverse e scrivere 10 menu diversi per ogni cliente. Se il cliente vuole cambiare ordine, il cameriere deve rifare tutto il menu.
Con LLM-Rosetta: Il cameriere ha un menu universale (l'IR).
1. Il cliente italiano parla al cameriere.
2. Il cameriere traduce la richiesta nel "Menu Universale" (es: "1 Pizza, 1 Vino").
3. La cucina (il motore AI) prepara la pizza.
4. Il cameriere prende la pizza e la serve al cliente italiano, ma se arriva un cliente giapponese, traduce lo stesso "Menu Universale" nel formato giapponese.

In sintesi: LLM-Rosetta è il ponte che rende il mondo delle Intelligenze Artificiali un unico villaggio globale, dove non importa chi parla, perché tutti capiscono la stessa lingua fondamentale.

1. Il Problema: Frammentazione e Complessità Combinatoria

L'ecosistema dei Large Language Model (LLM) è caratterizzato da una rapida proliferazione di provider (OpenAI, Anthropic, Google, ecc.), ognuno dei quali espone formati API proprietari e divergenti.

Frammentazione: Non esiste un formato wire universale. Le API differiscono nella struttura dei messaggi, nelle chiamate agli strumenti (tool calls), nel streaming e nei controlli di generazione.
Il problema $O(N^2)$ : Per collegare $N$ provider, un approccio ingenuo richiederebbe $\binom{N}{2}$ adattatori bilaterali. Ogni adattatore deve gestire la costruzione delle richieste, il parsing delle risposte, la mappatura degli eventi di streaming e la serializzazione delle chiamate agli strumenti.
Conseguenze: Questo porta a un'integrazione combinatoria onerosa, bloccando le applicazioni su singoli vendor e rendendo difficile la portabilità o l'architettura multi-provider. Le soluzioni attuali (wrapper SDK come LiteLLM) spesso adottano il formato di un singolo provider come "lingua franca", perdendo funzionalità specifiche degli altri o non supportando la conversione bidirezionale.

2. Metodologia: Rappresentazione Intermedia (IR) Hub-and-Spoke

Gli autori osservano che, nonostante le divergenze sintattiche sostanziali, le principali API LLM condividono un nucleo semantico comune. La sfida pratica risiede nella superficie combinatoria delle variazioni sintattiche, non in incompatibilità semantiche profonde.

Per risolvere questo, LLM-Rosetta adotta il pattern Hub-and-Spoke (già consolidato nell'infrastruttura dei compilatori come LLVM):

Rappresentazione Intermedia (IR): Un formato neutrale che cattura il nucleo semantico condiviso.
Architettura: Invece di $N \times N$ adattatori, si implementano $N$ convertitori (spoke) che mappano ogni formato provider verso/da l'IR centrale (hub), riducendo la complessità a $O(N)$ .

Design dell'IR

L'IR è definito come un insieme di strutture dati tipizzate organizzate in moduli:

Modelli di Contenuto (9 tipi): Definiscono le unità atomiche: TextPart, ImagePart, AudioPart, FilePart, ToolCallPart, ToolResultPart, ReasoningPart (pensiero/catena di pensiero), RefusalPart, CitationPart.
Messaggi: Container etichettati per ruolo (System, User, Assistant, Tool).
Strumenti: Definizioni di strumenti (nome, descrizione, schema JSON) e configurazioni di scelta.
Configurazione di Generazione: Parametri di campionamento (temperature, top-p), budget di ragionamento, formati di risposta.
Eventi di Streaming (10 tipi): Normalizza i diversi schemi SSE (Server-Sent Events) dei provider in eventi IR standardizzati (es. stream_start, content_block_start, text_delta, tool_call_delta, finish, usage).

Architettura a Composizione di Operazioni (Ops-Composition)

Invece di convertitori monolitici, ogni convertitore provider è assemblato da quattro moduli ortogonali:

ContentOps: Converte le singole parti di contenuto (testo, immagini, tool).
MessageOps: Gestisce la sequenza dei messaggi, la mappatura dei ruoli e la struttura della conversazione.
ToolOps: Converte le definizioni e le configurazioni degli strumenti.
ConfigOps: Gestisce i parametri di generazione e caching.
Questa separazione permette di isolare le peculiarità sintattiche di un provider (es. l'annidamento dei "parts" di Google) dalle preoccupazioni a livello di messaggio, facilitando il riutilizzo dei moduli e i test unitari.

3. Contributi Chiave

Caratterizzazione Empirica: Dimostrazione che le divergenze sono prevalentemente sintattiche e che un IR neutrale può rappresentare fedelmente i formati di OpenAI (Chat e Responses), Anthropic e Google.
IR Tipizzato e Architettura Modulare: Introduzione di un IR con 9 tipi di contenuto e 10 tipi di eventi di streaming, supportato da un'architettura di conversione modulare che garantisce l'estendibilità incrementale.
Conversione Bidirezionale con Streaming: Supporto completo per la conversione richiesta/risposta in entrambe le direzioni (Provider $\leftrightarrow$ IR $\leftrightarrow$ Provider) e gestione dello streaming a livello di chunk con contesto stato (stateful context management).
Validazione Empirica: Implementazione di 1.364 test, passaggio del suite di conformità "Open Responses" e deploy in produzione presso l'Argonne National Laboratory.

4. Risultati e Valutazione

L'articolo presenta una valutazione rigorosa su quattro dimensioni:

Fidelità del Round-Trip (RQ1): In modalità "preserve" (conservazione metadati), la conversione $A \to IR \to A$ è lossless (uguaglianza strutturale). In modalità "strip" (rimozione metadati specifici), tutti i campi semanticamente rilevanti sono preservati.
Correttezza dello Streaming (RQ2): Tutti i convertitori gestiscono correttamente l'ordinamento degli eventi e l'accumulo dei dati (es. argomenti dei tool) nonostante le differenze negli schemi SSE dei provider.
Traduzione Cross-Provider (RQ3): La traduzione tra provider diversi (es. OpenAI $\to$ Anthropic) preserva il contenuto semantico (testo, ruoli, parametri strumenti). Le funzionalità specifiche di un provider senza equivalente nell'altro vengono perse (con avvisi), ma il contenuto condiviso è intatto.
Overhead delle Prestazioni (RQ4):
- L'overhead di conversione è sub-millisecondo (mediana < 100 µs).
- Richieste semplici: ~21-24 µs.
- Confronto con LiteLLM: LLM-Rosetta è competitivo. Per payload semplici è persino più veloce (24 µs vs 28 µs di LiteLLM), mentre per scenari complessi (multi-turn, tool calls) l'overhead è di 1.6x-2.2x, ma rimane trascurabile rispetto ai tempi di rete e inferenza (50-500 ms).
- Il costo aggiuntivo del "due hop" (Provider $\to$ IR $\to$ Provider) è giustificato dalla bidirezionalità e dalla neutralità del provider.

5. Significato e Impatto

Interoperabilità Reale: LLM-Rosetta risolve il problema della frammentazione API senza richiedere ai provider di cambiare i loro formati, agendo come un motore di traduzione runtime.
Deploy in Produzione: Il sistema è già utilizzato come strato di traduzione in ARGO-PROXY presso l'Argonne National Laboratory, sostituendo circa 2.000 righe di codice di mappatura ad-hoc e supportando lo streaming bidirezionale tra OpenAI, Anthropic e Google.
Complementarità: A differenza di framework come LangChain (che astraggono a livello applicativo) o wrapper come LiteLLM (che privilegiano un formato), LLM-Rosetta opera a livello di formato API grezzo, potendo essere integrato dentro questi framework per gestire la conversione dei payload.
Futuro: L'architettura modulare permette di aggiungere nuovi provider con sforzo minimo. Sebbene attualmente copra solo le API di chat principali, il design basato su unioni semantiche è pronto per espandersi a nuovi tipi di contenuto (video, dati strutturati) e pattern di interazione.

In sintesi, LLM-Rosetta dimostra che è possibile costruire un ponte interoperabile ed efficiente tra ecosistemi LLM frammentati sfruttando un nucleo semantico comune, offrendo una soluzione scalabile, performante e open-source per la gestione multi-provider.