The Pulse
AWS aggiunge a SageMaker HyperPod il routing basato sulle GPU
AWS ha introdotto un Inference Gateway nativo per Kubernetes per SageMaker HyperPod, che instrada le richieste agli LLM usando dati in tempo reale sulle GPU. Il gateway punta a ridurre la latenza del primo token e ad aumentare il throughput
AI.info Team ·
Il routing round-robin si confronta con parchi GPU disomogenei
AWS aggiunge ad Amazon SageMaker HyperPod il routing delle richieste basato sulle GPU, affrontando un limite del normale bilanciamento del carico di Kubernetes: la distribuzione round-robin tratta ogni pod che serve modelli come equivalente, anche quando le GPU sottostanti, le code, gli stati delle cache e la memoria disponibile sono diversi.
Il nuovo Amazon SageMaker HyperPod Inference Gateway inoltra le richieste attraverso un livello di routing nativo per Kubernetes, che legge le informazioni sul modello dalla richiesta e seleziona un pod che fornisce il servizio usando segnali in tempo reale provenienti dall’infrastruttura e dal server del modello. AWS afferma che il sistema può ridurre la latenza del primo token fino all’82% senza richiedere modifiche ai server dei modelli o alle applicazioni client.
L’annuncio, pubblicato da AWS il 18 settembre 2026, segue il rilascio della versione v2.0.0-eksbuild.2 dell’add-on Amazon EKS SageMaker HyperPod Inference. Le note di rilascio di AWS datano il rilascio dell’add-on al 10 settembre e indicano il gateway come sua principale nuova funzionalità.
Tre livelli di routing sostituiscono la distribuzione alla cieca
Il gateway usa un router basato sul corpo della richiesta per leggere il campo model in una richiesta di inferenza. Può anche ricondurre un adattatore LoRA al suo modello di base, quindi impostare intestazioni di routing che collegano la richiesta al corretto HTTPRoute di Kubernetes e al pool di inferenza specifico per il modello.
All’interno del pool, un selettore di endpoint assegna un punteggio ai pod candidati. Il sistema di valutazione può considerare la lunghezza della coda, l’utilizzo della KV-cache, l’affinità con la cache dei prefissi e la presenza dell’adattatore LoRA richiesto nella memoria della GPU. La documentazione di AWS spiega che ogni scheduler esegue il proprio selettore di endpoint, consentendo a modelli diversi di adottare criteri di routing distinti.
La progettazione separa la distribuzione dalla gestione del traffico. L’Inference Operator di SageMaker HyperPod continua a distribuire e orchestrare i carichi di lavoro che forniscono i modelli, mentre il gateway gestisce il routing delle richieste davanti a tali carichi. AWS afferma che il gateway non dipende da uno specifico server di modelli o livello di orchestrazione e può funzionare con server compatibili con OpenAI, come vLLM, SGLang e TGI.
AWS segnala i maggiori miglioramenti con hardware eterogeneo
AWS ha testato il gateway confrontandolo con una configurazione di riferimento Kubernetes con distribuzione round-robin, usando quattro modelli da 8 a 235 miliardi di parametri. L’azienda ha valutato generazioni di GPU miste, traffico a raffiche, prefissi di prompt condivisi e un parco uniforme con traffico costante.
Nel test con GPU miste e Llama 3.1 8B, AWS segnala una riduzione del 97% sia nel tempo al primo token al 95º percentile sia al 99º percentile, con un aumento del throughput dell’8%. Su Qwen3 32B, lo stesso tipo di test ha prodotto una riduzione del 98% della latenza del primo token al 95º percentile, del 97% al 99º percentile e un aumento del throughput del 50%.
Anche i carichi di lavoro a raffiche hanno mostrato notevoli differenze di latenza. AWS segnala una riduzione del 94% della latenza del primo token al 95º percentile e del 98% al 99º percentile per Llama 3.1 70B. Per Qwen3 235B, il risultato al 99º percentile è migliorato dell’89%, mentre il throughput medio è rimasto paragonabile a quello della distribuzione round-robin.
Il gateway ha prodotto miglioramenti più contenuti quando il traffico è stato gestito da un parco uniforme in condizioni stabili. AWS segnala risultati paragonabili in questo test, il che significa che il vantaggio del sistema dipende dalle condizioni che generano un utilizzo disomogeneo, non dal solo routing.
La gestione di cache e adattatori punta a evitare di ripetere il lavoro
AWS usa il routing anche per preservare calcoli che altrimenti andrebbero ripetuti. Le richieste con prefissi di prompt condivisi possono essere indirizzate a pod che hanno già il prefisso in cache, riducendo il lavoro necessario per le conversazioni a più turni e i carichi di lavoro di domande e risposte su documenti.
Il routing degli adattatori LoRA affronta un problema correlato. Se un pod che fornisce il servizio ha già caricato l’adattatore richiesto nella memoria della GPU, il gateway può inoltrargli la richiesta invece di costringere un altro pod a caricarlo. Se nessun pod ha l’adattatore già caricato, il selettore di endpoint invia la richiesta a un pod con capacità disponibile.
Questi criteri distinguono il gateway da un semplice bilanciatore di carico CPU o di rete. La decisione di routing dipende non solo dal modello indicato nella richiesta, ma anche dallo stato corrente del processo che fornisce il modello e dai dati che ha già preparato.
Un solo add-on, con un’impostazione di sicurezza che i clienti devono configurare
AWS distribuisce il gateway tramite l’add-on SageMaker HyperPod Inference EKS, anziché come installazione separata. Gli amministratori definiscono il routing con una risorsa personalizzata InferenceGatewayConfig e abilitano il routing del gateway su una risorsa InferenceEndpointConfig. AWS afferma che la configurazione non richiede sidecar, service mesh o modifiche al codice dell’applicazione.
Il perimetro operativo è meno automatico del routing vero e proprio. La documentazione di AWS dichiara che, per impostazione predefinita, gli endpoint del gateway non prevedono autenticazione o autorizzazione a livello di richiesta. A meno che i clienti non configurino l’autenticazione JWT nella risorsa del gateway, l’accesso è limitato dai controlli della VPC e della rete circostante.
Il gateway per singolo cluster è disponibile nelle Regioni AWS in cui è disponibile l’add-on di inferenza SageMaker HyperPod. AWS indica come funzionalità future un router di inferenza globale, la suddivisione del traffico canary e il controllo del flusso basato sulle priorità, ma queste funzionalità non fanno parte del rilascio del 18 settembre.
L’annuncio di AWS descrive i test delle prestazioni e il modello di configurazione, mentre la documentazione di SageMaker illustra i componenti di routing del gateway e i requisiti di autenticazione.