The Pulse

AWS aggiunge a SageMaker HyperPod l’instradamento basato sulle GPU

AWS ha introdotto un Inference Gateway nativo per Kubernetes per SageMaker HyperPod, che instrada le richieste agli LLM utilizzando segnali in tempo reale delle GPU. Il gateway punta a ridurre la latenza del primo token e ad aumentare il th

AI.info Team · Scritto con l’IA · verificato · 2026-09-18

L’instradamento round-robin incontra flotte di GPU disomogenee

AWS sta aggiungendo ad Amazon SageMaker HyperPod un sistema di instradamento delle richieste che tiene conto delle GPU, affrontando un limite del normale bilanciamento del carico di Kubernetes: la distribuzione round-robin considera equivalenti tutti i pod che servono i modelli, anche quando le GPU sottostanti, le code, gli stati della cache e la memoria disponibile sono diversi.

Il nuovo Amazon SageMaker HyperPod Inference Gateway fa passare le richieste attraverso un livello di instradamento nativo per Kubernetes, che legge le informazioni sul modello dalla richiesta e seleziona un pod per servirla utilizzando segnali in tempo reale dell’infrastruttura e del server del modello. Il sistema può ridurre la latenza del primo token fino all’82% senza richiedere modifiche ai server dei modelli o alle applicazioni client, afferma AWS.

L’annuncio, pubblicato da AWS il 18 settembre 2026, segue il rilascio della versione v2.0.0-eksbuild.2 dell’add-on SageMaker HyperPod Inference per Amazon EKS. Le note di rilascio di AWS datano il rilascio dell’add-on al 10 settembre e indicano il gateway come sua principale novità.

Tre livelli di instradamento sostituiscono la distribuzione alla cieca

Il gateway utilizza un router basato sul corpo della richiesta per leggere il campo model in una richiesta di inferenza. Può anche risalire da un adattatore LoRA al suo modello di base, per poi impostare intestazioni di instradamento che collegano la richiesta all’HTTPRoute Kubernetes corretto e al pool di inferenza specifico del 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 i prefissi in cache e la presenza dell’adattatore LoRA richiesto nella memoria della GPU. La documentazione di AWS descrive ogni scheduler come dotato di un proprio selettore di endpoint, consentendo a modelli diversi di usare politiche di instradamento separate.

La progettazione separa il deployment dalla gestione del traffico. L’Inference Operator di SageMaker HyperPod continua a distribuire e orchestrare i carichi di lavoro che servono i modelli, mentre il gateway gestisce l’instradamento delle richieste a monte di tali carichi. 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.

I vantaggi maggiori arrivano con hardware eterogeneo

AWS ha confrontato il gateway con una configurazione di riferimento Kubernetes round-robin usando quattro modelli da 8 miliardi a 235 miliardi di parametri. L’azienda ha valutato generazioni diverse di GPU, traffico a raffiche, prefissi dei prompt condivisi e una flotta uniforme con traffico stabile.

Nel test con GPU eterogenee e Llama 3.1 8B, AWS riferisce una riduzione del 97% del tempo al primo token sia al 95º 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, una riduzione del 97% al 99º percentile e un aumento del throughput del 50%.

Anche i carichi di lavoro a raffiche hanno mostrato grandi differenze di latenza. Llama 3.1 70B ha registrato una riduzione del 94% della latenza del primo token al 95º percentile e del 98% al 99º percentile, riferisce AWS. Per Qwen3 235B, il risultato al 99º percentile è migliorato dell’89%, mentre il throughput medio è rimasto paragonabile a quello del round-robin.

Il gateway ha prodotto vantaggi minori quando il traffico ha attraversato una flotta uniforme in condizioni stabili. I risultati di quel test sono stati comparabili, riferisce AWS: ciò significa che il beneficio del sistema dipende dalle condizioni che generano un utilizzo disomogeneo, anziché dal solo instradamento.

Cache e adattatori per evitare lavoro ripetuto

AWS usa l’instradamento anche per conservare il risultato di calcoli che altrimenti verrebbero ripetuti. Le richieste con prefissi dei prompt condivisi possono essere dirette ai pod che hanno già il prefisso in cache, riducendo il lavoro necessario per le conversazioni a più turni e per i carichi di lavoro di domande e risposte sui documenti.

L’instradamento degli adattatori LoRA affronta un problema analogo. Quando un pod che serve il modello ha già caricato l’adattatore richiesto nella memoria della GPU, il gateway può inviargli la richiesta invece di costringere un altro pod a caricarlo. Se nessun pod ha l’adattatore in memoria, il selettore di endpoint invia la richiesta a un pod con capacità disponibile.

Queste politiche rendono il gateway diverso da un semplice bilanciatore del carico della CPU o della rete. La decisione di instradamento dipende non solo dal modello indicato nella richiesta, ma anche dallo stato corrente del processo che serve il modello e dai dati che ha già preparato.

Un solo add-on, con un’impostazione di sicurezza da configurare

AWS distribuisce il gateway attraverso l’add-on EKS SageMaker HyperPod Inference, anziché come installazione separata. Gli amministratori definiscono l’instradamento mediante una risorsa personalizzata InferenceGatewayConfig e lo abilitano su una risorsa InferenceEndpointConfig. La configurazione non richiede sidecar, service mesh o modifiche al codice delle applicazioni.

La gestione del perimetro operativo è meno automatica dell’instradamento stesso. Per impostazione predefinita, gli endpoint del gateway non prevedono autenticazione o autorizzazione a livello di singola richiesta, afferma la documentazione di AWS. A meno che i clienti non configurino l’autenticazione JWT nella risorsa del gateway, l’accesso è limitato dalla VPC circostante e dai controlli di rete.

Il gateway, previsto per ciascun cluster, è disponibile nelle AWS Regions in cui è disponibile l’add-on di inferenza SageMaker HyperPod. AWS indica tra le aggiunte previste 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 nel dettaglio i componenti di instradamento del gateway e i requisiti di autenticazione.