AWS lancia SageMaker HyperPod Inference Gateway per il routing sensibile alla GPU

Amazon Web Services ha annunciato Amazon SageMaker HyperPod Inference Gateway il 18 settembre 2026, un sistema di routing nativo Kubernetes, sensibile alla GPU, per l’inferenza di grandi modelli linguistici che si distribuisce come unico componente aggiuntivo gestito per Amazon EKS sull’infrastruttura HyperPod esistente. AWS ha dichiarato che il gateway può ridurre la latenza del primo token fino all’82%.

Il problema di routing alla base del gateway

Secondo AWS, gli algoritmi di bilanciamento del carico predefiniti di Kubernetes come round-robin e least-connections non hanno visibilità sullo stato della GPU: quali pod hanno saturato le cache KV, quali sono a metà di generazioni a lungo contesto e quali hanno già caricato in memoria l’adattatore LoRA richiesto da una richiesta. L’azienda ha affermato che le richieste si accumulano dietro i pod occupati mentre la capacità inattiva rimane inutilizzata, la latenza del primo token supera i quattro secondi durante i picchi di traffico, l’utilizzo diventa irregolare e imprevedibile, e gli operatori sovradimensionano per compensare. AWS ha descritto uno scenario in cui un utente di chatbot che attendeva 4,4 secondi per il primo token lo riceve invece in meno di 800 millisecondi.

Architettura a due livelli

Il gateway utilizza un design a due livelli basato su primitive native di Kubernetes. AWS ha dichiarato che usa segnali GPU in tempo reale per assegnare ogni richiesta di inferenza al pod più adatto. Il livello 1 si installa direttamente su ogni HyperPod o cluster EKS come componente aggiuntivo amazon-sagemaker-hyperpod-inference e comprende tre componenti, tutti costruiti sull’estensione open-source Gateway API Inference. Envoy Gateway, un proxy di livello 7, termina il traffico HTTPS in ingresso ed espone un unico endpoint privato per cluster. Il Body-Based Router esamina il corpo di ogni richiesta compatibile con OpenAI, estrae il campo modello e indirizza la richiesta al pool di modello corretto, così un unico gateway può servire più modelli.

Il Endpoint Picker utilizza metriche Prometheus in tempo reale provenienti da ogni pod che serve modelli e applica un algoritmo di punteggio ponderato su valutatori che coprono l’utilizzo della cache KV, la profondità della coda, la permanenza dell’adattatore LoRA, il tasso di hit della cache di prefisso e le richieste in corso. Ogni valutatore ha un peso configurabile, consentendo di regolare il comportamento di routing per un carico di lavoro specifico, ad esempio chat sensibile alla latenza rispetto a batch ottimizzati per il throughput.

Il livello 2, il Global Inference Router, è indicato come in arrivo. AWS ha dichiarato che aggiungerà un coordinamento a livello di flotta tra più cluster e regioni, con failover cross-cluster, limitazione globale del rate e modellazione del traffico consapevole dei costi. Il livello 2 si basa sul livello 1, mentre il gateway per cluster di ciascun cluster continua a gestire il routing locale.

Distribuzione, gestione dei guasti e osservabilità

La distribuzione consiste in un unico comando aws eks create-addon e una risorsa personalizzata dichiarativa InferenceGatewayConfig che definisce i modelli e il comportamento di routing, con le distribuzioni dei server di modello esistenti scoperte tramite etichette dei pod. AWS ha affermato che l’installazione non richiede sidecar, service mesh né modifiche al codice dell’applicazione. Il gateway espone un endpoint standard compatibile con OpenAI su HTTP; secondo AWS, il codice client esistente funziona senza modifiche, senza cambiamenti al SDK e senza firma SigV4 per il traffico di inferenza.

Per i carichi di lavoro che servono adattatori LoRA finemente sintonizzati su un modello di base condiviso, il LoRA Affinity Scorer del Endpoint Picker indirizza le richieste di adattatore ai pod che hanno già l’adattatore richiesto residente nella memoria GPU; se nessun pod lo ha caricato, la richiesta viene inviata al pod con la maggiore capacità disponibile. AWS ha dichiarato che ciò elimina la latenza di scambio dell’adattatore.

I comportamenti di guasto documentati coprono guasti dei pod, esaurimento del pool, guasti del cluster e guasti regionali. In caso di guasto di un pod, il Endpoint Picker esclude i pod con metriche obsolete e instrada verso pod sani, riprendendo automaticamente quando le metriche riprendono. In caso di esaurimento del pool, il gateway restituisce HTTP 429 con intestazione Retry-After mentre l’autoscaling aggiunge capacità. In caso di guasto del cluster, il Global Inference Router rileva un heartbeat obsoleto e reindirizza il traffico entro 35 secondi, con un aumento graduale quando il cluster viene reintrodotto. In caso di guasto regionale, il routing cross-region si attiva automaticamente, il che, secondo AWS, comporta una latenza più elevata ma nessun impatto sulla disponibilità.

Il gateway emette metriche a livello di pod, pool, cluster e flotta: utilizzo della cache KV, profondità della coda, richieste in corso e permanenza dell’adattatore tramite Prometheus a livello di pod; totali delle richieste, istogrammi di durata e conteggi dei token tramite Prometheus e Grafana a livello di pool; media della cache KV, tasso di errore e latenza P99 tramite Amazon CloudWatch a livello di cluster; e decisioni di routing, eventi di failover e hit di limitazione del rate tramite CloudWatch a livello di flotta.

Risultati dei benchmark segnalati da AWS

AWS ha dichiarato di aver eseguito benchmark su quattro modelli con parametri da 8 Miliardi a 235 Miliardi su istanze p5.48xlarge con GPU H100 e istanze g5 con GPU A10G. tutto il traffico è stato instradato tramite Application Load Balancer interni, replicando il percorso di una richiesta di produzione, con un gruppo di nodi client dedicato che genera carico controllato e server di modello isolati su un gruppo di nodi server separato. Ogni risultato utilizza la configurazione di routing predefinita del gateway senza ottimizzazioni ed è misurato rispetto a una baseline Kubernetes round-robin sulle stesse repliche del modello, secondo AWS.

Nei risultati riportati, una flotta di GPU a generazione mista ha ridotto la latenza time-to-first-token P95 e P99 del 97% ciascuna per Llama-3.1-8B, con un aumento del throughput dell’8%, e del 98% e 97% per Qwen3-32B, con un aumento del throughput del 50%. Con traffico a picchi, Llama-3.1-70B ha registrato riduzioni P95 e P99 del 94% e 98% con un throughput superiore del 12%, mentre Qwen3-235B ha mostrato una latenza P95 comparabile e un P99 ridotto dell’89%. Con prefissi di prompt condivisi, la latenza P95 e P99 di Llama-3.1-8B è diminuita del 26% e del 43%.

AWS ha dichiarato che, su una flotta completamente uniforme con traffico costante, il gateway offre prestazioni pari al round-robin, e ha definito risultati comparabili come differenze entro la varianza da esecuzione a esecuzione. L’azienda ha affermato che i miglioramenti sono maggiori dove il round-robin ha maggiori difficoltà: hardware misto, domanda a picchi e prefissi di prompt condivisi.

Disponibilità e roadmap

AWS descrive il gateway come conforme alla Kubernetes Gateway API e alla sua Inference Extension, configurato tramite una singola definizione di risorsa personalizzata, e compatibile con qualsiasi server di modelli compatibile con OpenAI, inclusi vLLM, SGLang e TGI. La gestione avviene tramite kubectl, GitOps, Helm e ArgoCD, con installazione, aggiornamenti e rollback gestiti attraverso il ciclo di vita dell’add-on EKS.

Il routing di livello 1 per cluster è disponibile dal 18 settembre 2026, nelle regioni in cui l’add-on di inference è disponibile. Oltre al Global Inference Router, gli elementi della roadmap di AWS includono lo splitting del traffico canary, che indirizzerà una percentuale di traffico verso nuove versioni di modello utilizzando risorse personalizzate InferenceModelRewrite, e il controllo del flusso che classifica le richieste come Critical, Standard o Sheddable con controllo di ammissione per banda.