AWS aggiunge il partizionamento delle GPU NVIDIA agli endpoint di inferenza di SageMaker

Amazon Web Services (AWS) ha annunciato il supporto delle GPU NVIDIA Multi-Instance per Amazon SageMaker Inference il 6 novembre 2026, consentendo a più modelli isolati a livello hardware di condividere un acceleratore sugli endpoint in tempo reale, invece di assegnare un’intera GPU a ogni distribuzione.

La funzionalità risponde a due limiti dell’allocazione di una GPU intera. Il numero di acceleratori pone un tetto al numero di modelli che un’istanza può ospitare, indipendentemente dalla quantità ridotta di memoria o capacità di calcolo utilizzata da ciascun modello; inoltre, chi valuta una GPU più recente deve allocare l’intero dispositivo. Multi-Instance GPU (MIG), invece, assegna a ogni partizione una quota fissa di unità di calcolo e un blocco di memoria dedicato, garantendo l’isolamento a livello hardware. Poiché ogni modello rimane residente, questa soluzione evita anche il ritardo che si verifica quando un endpoint multi-modello carica un modello sul dispositivo condiviso per il primo utilizzo.

Il partizionamento è disponibile solo per gli endpoint in tempo reale che utilizzano componenti di inferenza, il sistema di SageMaker per distribuire più modelli su un unico endpoint e definire la capacità di calcolo assegnata a ciascuno. Gli endpoint a modello singolo, gli endpoint serverless e i pool di istanze eterogenee non possono essere partizionati. Anche i carichi di lavoro asincroni non rientrano nell’ambito della funzionalità, perché le invocazioni asincrone non possono indirizzare un componente di inferenza.

Salesforce ha contribuito a definire i requisiti e a convalidare l’implementazione iniziale. Richard Chang, architetto del software presso Salesforce, ha dichiarato che l’azienda si aspettava che MIG consentisse di consolidare i carichi di lavoro in modo sicuro, migliorare l’utilizzo delle GPU e ridurre i costi di inferenza, mantenendo prestazioni prevedibili e l’isolamento. Salesforce si sta preparando a convalidare il software con carichi di lavoro rappresentativi della produzione; questi vantaggi sono quindi attese, non risultati di produzione già rilevati.

Due campi API controllano il partizionamento

La documentazione per sviluppatori di SageMaker AI definisce due campi facoltativi: AcceleratorPartitionLayouts dichiara la suddivisione su una variante di produzione, e AcceleratorPartitionType seleziona il profilo utilizzato da un componente di inferenza. Non sono state introdotte nuove operazioni API, nuovi tipi di risorse o nuove azioni di AWS Identity and Access Management; se si omettono entrambi i campi, il comportamento degli endpoint esistenti rimane invariato.

La configurazione selezionata si applica in modo uniforme a ogni acceleratore di ogni istanza della variante. Nell’esempio di AWS, ciascuna delle otto A100 viene suddivisa su un ml.p4d.24xlarge in mig-4g.20gb, mig-2g.10gb e mig-1g.5gb partizioni, per un totale di 24 partizioni sull’endpoint. Ogni copia di un componente di inferenza occupa una partizione richiesta, mentre InvokeEndpoint continua a individuare i modelli tramite il nome del componente, senza un identificativo della partizione. Nei suoi test, AWS ha dichiarato che la suddivisione degli acceleratori ha aggiunto circa 17 secondi al provisioning.

L’isolamento riguarda la capacità di calcolo e la memoria della GPU, non l’intero host. I modelli sulla stessa istanza continuano a condividere CPU dell’host, memoria dell’host, archiviazione, rete e instradamento dell’endpoint. Se un componente richiede un profilo non presente nella configurazione, la richiesta viene rifiutata invece di assegnargli un’intera GPU. Per modificare la configurazione di un endpoint in esecuzione occorre creare un nuovo endpoint e migrare il traffico; per spostare un componente su un altro profilo è necessario crearne uno nuovo.

AWS confronta una partizione H100 con una A100 intera

AWS ha confrontato una mig-3g.40gb partizione H100 con una A100-40GB intera, utilizzando Llama-3.1-8B-Instruct su endpoint SageMaker in tempo reale destinati alla produzione. Entrambe le configurazioni utilizzavano una replica del modello, container, tokenizer e configurazioni client identici; genai-bench ha generato cinque profili di traffico, con livelli di concorrenza da 2 a 512. La guida ai profili di NVIDIA assegna al profilo H100 testato tre delle sette quote di streaming multiprocessor e quattro delle otto unità di memoria. Le due configurazioni hanno capacità di memoria comparabili, ma quote di calcolo diverse.

Nel complesso dei test, AWS ha riportato un numero di token in uscita al secondo superiore del 53%-89% con la partizione H100, al livello di carico in cui il vantaggio economico di ciascuno scenario era massimo. La latenza tra token è risultata inferiore dell’8,9%-42,1% e il tempo al primo token del 5,6%-47,5%. Al massimo livello di concorrenza, nei carichi di lavoro con 6.000 e 8.000 token, l’A100 non ha rispettato la scadenza di elaborazione per un terzo o metà delle richieste, mentre la partizione non ne ha mancata nessuna.

L’analisi dei costi di AWS, presentata come confronto caso per caso e non come verdetto universale, ha rilevato un costo per milione di token in uscita inferiore del 18%-34% una volta superato il punto di pareggio specifico per il carico di lavoro. Tale soglia è stata raggiunta con una concorrenza pari a 64 per i prompt da 100 token e pari a 4 per quelli da 8.000 token. Al di sotto della soglia, l’A100 intera restava più economica; per i carichi di lavoro con input brevi o bassa concorrenza, la vecchia GPU intera potrebbe quindi essere la scelta più adatta. Il confronto del costo unitario divideva i prezzi delle istanze on demand per il numero di unità testate su ciascuna istanza.

Hardware supportato e limiti operativi

Il lancio comprende quattro famiglie di istanze, con numero di partizioni e profili determinati dall’acceleratore:

Il partizionamento delle GPU è disponibile nelle regioni Stati Uniti orientali (Virginia settentrionale), Stati Uniti orientali (Ohio), Stati Uniti occidentali (Oregon), Asia Pacifico (Singapore), Asia Pacifico (Tokyo), Europa (Francoforte) ed Europa (Irlanda), in base alla disponibilità di istanze nella regione e alla quota degli endpoint. Nessuna partizione si estende su più acceleratori, quindi i modelli che richiedono una GPU intera o più GPU necessitano ancora di dispositivi interi.

I clienti continuano a pagare l’istanza GPU completa: il partizionamento può aumentare la capacità utilizzabile, ma non ne riduce il prezzo orario. Gli endpoint partizionati e i relativi componenti di inferenza, inoltre, non pubblicano su CloudWatch metriche di utilizzo di GPU, CPU o memoria, anche se restano disponibili le metriche relative alle invocazioni e alla latenza. Per P4d, il mig-1g.10gb profilo richiede il driver R525 di NVIDIA o una versione più recente e AWS invita i clienti a usare un’AMI di inferenza più recente, perché l’immagine predefinita non lo include.

Ai fini della pianificazione della capacità, il lancio suddivide ciascun acceleratore supportato in diverse dimensioni GPU fisse, ma una distribuzione più densa e isolata a livello hardware comporta la fatturazione dell’istanza completa, configurazioni che non possono essere modificate sul posto e una telemetria di utilizzo ridotta. Il benchmark di AWS mostra il valore di misurare il traffico effettivo: nei test, la partizione H100 ha offerto vantaggi in termini di prestazioni e costi con carichi più pesanti e contesti più lunghi, mentre i risultati del punto di pareggio indicavano che una A100 intera costava meno per i carichi più leggeri.