Microsoft ha pubblicato un’architettura di riferimento per gestire il traffico degli agenti su Azure Kubernetes Service. Il progetto separa il routing delle chiamate LLM in tre decisioni: quale modello deve rispondere, con quali regole deve essere gestita la richiesta e quale replica GPU deve elaborarla. I diversi componenti convergono in un unico endpoint compatibile con OpenAI, offrendo alle applicazioni un’interfaccia uniforme.
Il punto di partenza non è il chatbot tradizionale, ma il carico generato dagli agenti. Una singola attività può produrre centinaia di chiamate LLM durante un ciclo plan-act-observe, anche per operazioni semplici come compilare gli argomenti di uno strumento, superare un controllo binario o preparare un riepilogo. Affidare ogni passaggio a un modello di fascia alta aumenta costi e tempi di risposta in proporzione alla lunghezza del ciclo. Anche il bilanciamento round-robin può creare inefficienze, accodando una risposta da 200 token dietro un prefill da 100.000 token mentre un altro pod resta libero.
La prima scelta è affidata a RouteLLM, che analizza il prompt e stima se un modello meno costoso possa offrire una qualità paragonabile a quella del modello più potente. Il router utilizza una tecnica di fattorizzazione matriciale addestrata su preferenze umane. Agentgateway, proxy open source compatibile con OpenAI, applica invece autenticazione, limiti per agente, monitoraggio dei costi e guardrail senza interpretare semanticamente le richieste. Il terzo livello, la Gateway API Inference Extension, osserva lo stato operativo delle GPU e assegna la chiamata alla replica più adatta.
L’Endpoint Picker considera l’occupazione della KV cache e la profondità della coda esposte da vLLM. Nel percorso self-hosted, agentgateway lo interroga direttamente tramite ext-proc, evitando la necessità di un gateway Gateway API separato. KAITO attiva i pool di nodi GPU e gestisce vLLM, mentre il percorso forte raggiunge Azure OpenAI e quello debole viene indirizzato ai pod serviti nel cluster. Le metriche di routing, costo e utilizzo delle GPU confluiscono in Azure Managed Prometheus e Grafana per una vista operativa combinata.
La variabile decisiva è la soglia di escalation di RouteLLM. Nella coppia di modelli usata per i test, il router ha raggiunto circa il 95% della qualità di GPT-4 misurata su MT-Bench, inviando al modello più potente soltanto il 26% delle chiamate. Il risparmio dichiarato arriva all’85% rispetto all’invio di tutto il traffico al modello forte. Microsoft precisa però che il risultato dipende dalla coppia impiegata nell’addestramento e non si trasferisce automaticamente, per esempio, a phi-4-mini e GPT-5.1. La soglia deve quindi essere calibrata sul traffico reale. Anche il prompt caching complica il calcolo: gli input già memorizzati costano meno, mentre il passaggio frequente tra modelli raffredda entrambe le cache.
L’implementazione richiede cautela sulle versioni. La configurazione è stata verificata end-to-end su AKS a metà 2026 con Inference Extension v1.0.0 e agentgateway v1.3.1, ma nomi dei campi, flag e risorse CRD possono cambiare rapidamente. InferencePool e InferenceObjective appartengono, per esempio, a gruppi API differenti. I tre livelli open source operano nel cluster, mentre il serving KAITO, Azure OpenAI e lo stack di osservabilità sono gestiti da Azure.
L’adozione può procedere per gradi. Un solo modello ospitato dietro pochi agenti richiede soprattutto agentgateway per la governance. Chi esegue in proprio un’unica classe di modello può combinare KAITO e Inference Extension, senza aggiungere il routing semantico. RouteLLM entra in gioco quando esiste un divario di prezzo netto tra modello forte e debole e una quota consistente delle richieste è semplice. Microsoft indica inoltre Foundry model router come versione gestita del livello semantico; il posizionamento sensibile allo stato delle GPU, invece, non dispone ancora di un’opzione gestita e deve continuare a operare dentro il cluster.