Le differenze fondamentali tra gateway e tracer

Un gateway può bloccare una chiamata a un modello prima che raggiunga il provider, mentre un tracer può solo registrarla dopo che la risposta è stata restituita. Questa distinzione è cruciale per il controllo dei costi e la sicurezza.

Il gateway detiene le chiavi del provider, consentendo di intercettare chiamate provenienti da laptop, agenti di programmazione o script non instrumentati da alcun SDK. Quando il gateway e il tracer si fondono, il fornitore di osservabilità diventa una dipendenza runtime: un suo eventuale outage interrompe tutte le chiamate al modello.

Storia recente: l’ascesa delle pasarelle integrate (2026)

Nel 2026, LangSmith, Langfuse, Opik e Braintrust hanno introdotto una pasarella davanti ai provider di modelli. Il motivo principale è il controllo: una semplice traccia non può impedire una chiamata, mentre una pasarella lo può.

Negli ultimi due anni, i team hanno tipicamente usato due strumenti distinti:

    • Una pasarela tra l’applicazione e i provider, responsabile della gestione delle chiavi API, della traduzione tra le API dei vari provider e del retry delle chiamate fallite. LiteLLM, proxy open‑source, è diventato lo standard de facto.
    • Un tracer (es. LangSmith, Langfuse) che registra ogni chiamata al modello, ogni chiamata a tool esterni e i passaggi di recupero, fornendo un’interfaccia visuale per gli ingegneri.

Questa separazione aveva senso: il gateway doveva essere veloce e supportare le API di ogni provider, mentre il tracer richiedeva interfacce ricche, storage per payload di grandi dimensioni e un SDK per avvolgere il codice dell’applicazione.

Documentazione e integrazioni

Langfuse continua a promuovere la configurazione a due livelli, con un’integrazione specifica per il LiteLLM Proxy che inoltra le chiamate al tracer. Tuttavia, a partire dal 2026, i fornitori di tracer hanno iniziato a sviluppare le proprie pasarelle.

Quattro lanci in sei mesi

Le principali uscite recenti includono:

    • LangChain ha annunciato la pasarela LLM di LangSmith in beta privata a maggio 2026, aprendo la beta pubblica il 30 luglio e integrandola nelle implementazioni cloud dei clienti.
    • Braintrust ha ritirato il suo precedente proxy di IA, indirizzando gli utenti verso una nuova pasarela in preview, gratuita fino al rilascio generale.
    • Comet ha lanciato la pasarela LLM di Opik come endpoint beta compatibile con il formato OpenAI.
    • Il 4 novembre 2026 Langfuse ha aperto la sua pasarela di IA in beta pubblica, sia su Langfuse Cloud sia per deployment self‑hosted, rilasciata sotto licenza MIT e scritta in Rust.
    • MLflow, inizialmente uno strumento di gestione del ciclo di vita del machine learning, offre da più tempo una pasarela di IA con alert e limiti di budget.

Rischi e motivazioni

Le pasarelle esistono da anni e i rischi operativi sono ben documentati. La novità è che aziende il cui core business era il tracciamento delle chiamate stanno ora inserendo un punto di controllo obbligatorio, aumentando la loro dipendenza dalla piattaforma.

Perché il budget deve essere nella catena di richiesta

Un tracer registra una chiamata solo dopo che il provider ha risposto e i token sono stati fatturati. Questo è sufficiente per costruire grafici di spesa, ma non permette di fermare il consumo. Controllare il budget, bloccare un modello o rimuovere un segreto da un prompt richiede l’intervento prima che la chiamata raggiunga il provider.

LangChain sottolinea questo punto nella sua release post, descrivendo un flusso tipico: gateway indipendente + prodotto di protezione + strumento di osservabilità. Quando una chiamata supera il budget, il gateway risponde con HTTP 402 invece di inoltrare la richiesta.

Copertura totale delle chiamate

Un SDK traccia solo le rotte di codice instrumentate. Le chiamate provenienti da script portatili, notebook o agenti di programmazione che usano chiavi API copiate rimangono invisibili. Una pasarela che conserva le chiavi del provider vede tutte le chiamate, perché non esiste alcun percorso alternativo per raggiungere il provider.

Langfuse progetta la sua pasarela con questa logica: ogni chiave è associata a un utente o a un servizio e può includere metadati (team, centro di costo). Solo la pasarela conserva la credenziale del provider; gli amministratori decidono a quali modelli può accedere ogni chiave.

Cosa aggiunge una pasarela a uno strumento di tracciamento

I fornitori di tracer sostengono il punto di vista opposto: una pasarela indipendente non è sufficiente. Langfuse afferma che una pasarela autonoma può solo contabilizzare token e costi, mentre la sua pasarela integra ogni chiamata in una traccia completa, accettando l’header W3C traceparent per collegare la chiamata alla traccia avviata dall’applicazione.

Di default registra uso e costo, ma non il contenuto di prompt o risposte, preservando la privacy.

Vantaggi tecnici

    • Una pasarela indipendente fornisce una lista piatta di risposte.
    • Una traccia completa, grazie al SDK, può correlare chiamate a tool, passaggi di recupero e risultati, posizionando ogni chiamata della pasarela nel contesto corretto.

Considerazioni commerciali nascoste

Chi gestisce la pasarela controlla le chiavi dei provider e i report di spesa, dati cruciali per finanza e piattaforme. Questo rende più difficile sostituire una pasarela rispetto a un semplice visualizzatore di tracce.

LangSmith vende Gateway Credits, consentendo ai clienti di chiamare modelli ospitati (es. Kimi) senza usare le proprie chiavi. Langfuse, invece, dichiara di non rivendere token, ma il controllo delle credenziali rimane un punto di leva commerciale.

Limitazioni attuali delle pasarelle beta

Le pasarelle sono ancora giovani e presentano limitazioni documentate:

    • Langfuse supporta solo OpenAI e Anthropic; Amazon Bedrock, Google Vertex AI e Google AI Studio sono in roadmap.
    • Non converte tra formati API: un client OpenAI può chiamare solo modelli OpenAI.
    • La versione self‑hosted chiama solo URL ufficiali, escludendo Azure OpenAI, Bedrock o proxy interni.
    • Non offre ancora limiti di richieste o caching delle risposte.
    • Opik descrive la sua pasarela come orientata a sviluppo e testing; i prezzi di Braintrust non sono ancora pubblici.

Prospettive future

Man mano che le pasarelle si matureranno, ci si aspetta:

    • Supporto multi‑provider e conversione di formati API.
    • Implementazione di limiti di richiesta, caching e policy più granulari.
    • Integrazione più stretta con sistemi di gestione dei costi e di sicurezza a livello aziendale.

Conclusioni

L’unione di gateway e tracer sta trasformando la gestione dei LLM, offrendo un controllo più rigido sui costi, sulla sicurezza e sulla visibilità delle chiamate. Tuttavia, questa centralizzazione porta con sé rischi di dipendenza e potenziali lock‑in commerciali. Le aziende dovranno valutare attentamente le trade‑off tra flessibilità, sicurezza e costi operativi mentre il mercato delle pasarelle evolve.