Amazon SageMaker Instance Preference Lists sostituiscono i tentativi manuali per le GPU, ma non la pianificazione della capacità

Amazon ha introdotto le Amazon SageMaker instance preference lists, che consentono a una richiesta di addestramento di includere fino a cinque opzioni di calcolo ordinate, anziché un singolo tipo di istanza fisso. SageMaker AI verifica tali opzioni in ordine di priorità e avvia la prima configurazione con capacità disponibile.

La modifica affronta un problema operativo persistente. I job di addestramento SageMaker basati su GPU possono rimanere in attesa quando l'hardware richiesto non è disponibile. I team hanno risposto monitorando la capacità, reinviando i job o gestendo script che provano configurazioni alternative.

AWS ora sposta questa decisione di ritentativo nello scheduler gestito. Tuttavia, la funzionalità non crea capacità GPU né dimostra che acceleratori diversi eseguiranno correttamente un workload. Il suo valore dipende dalla capacità dei team di rendere il proprio codice di addestramento, gli obiettivi prestazionali e i controlli dei costi realmente flessibili rispetto all'hardware.

Questa distinzione mette sotto pressione una pratica cloud familiare: trattare un tipo di istanza come una proprietà fissa di ogni job. Google Cloud accoda già richieste flessibili di acceleratori tramite il suo Dynamic Workload Scheduler. Anche gli utenti di Azure Machine Learning pianificano in base a quote di calcolo specifiche per area geografica e famiglia. AWS sta ora rendendo la flessibilità hardware dichiarata una componente di primo piano dei singoli job SageMaker.

Cosa cambia AWS con Amazon SageMaker Instance Preference Lists

Una richiesta SageMaker può ora esprimere diverse configurazioni di calcolo accettabili senza richiedere un controller esterno per i ritentativi.

AWS ha annunciato la funzionalità il 15 settembre 2026, sia per i job di addestramento sia per quelli di elaborazione. È disponibile tramite API SageMaker, SDK, strumenti da riga di comando e console in ogni AWS Region in cui SageMaker AI è disponibile, secondo l'avviso dell'azienda sulla disponibilità regionale.

Una lista di preferenze contiene da due a cinque tipi di istanza in ordine di priorità. SageMaker convalida l'elenco, esegue una verifica in memoria e seleziona la prima configurazione con capacità disponibile. Solo una delle configurazioni elencate esegue il job.

Se nessuna è immediatamente disponibile, il job entra in una coda guidata dagli eventi. SageMaker ritenta al variare della capacità, anziché richiedere a un processo client di interrogare il servizio e reinviare le richieste. Il periodo di attesa totale può essere limitato con MaxPendingTimeInSeconds.

Questo timeout si applica all'intera lista di preferenze, non separatamente a ciascuna opzione. AWS afferma inoltre che entra in vigore solo quando almeno una configurazione elencata utilizza calcolo accelerato delle famiglie ml.p, ml.g o ml.trn.

Questo comportamento è importante perché una preferenza è più di un nome alternativo di istanza. I team possono assegnare un numero diverso di istanze a ogni opzione. Un job potrebbe preferire due nodi ml.g6.48xlarge, ma accettare quattro nodi ml.g5.48xlarge quando tale seconda configurazione offre un throughput aggregato adeguato.

AWS consente due modelli di conteggio. Un ResourceConfig.InstanceCount condiviso può applicarsi a ogni preferenza, oppure ogni preferenza può definire il proprio conteggio. Mescolare questi approcci non è valido, come spiega il riferimento API.

La funzionalità si collega inoltre a SageMaker Flexible Training Plans, che riservano capacità GPU supportata per un periodo definito. Un job di addestramento può collocare per prima una configurazione supportata da un piano corrispondente, quindi elencare successivamente alternative on-demand. Se l'opzione riservata non può essere predisposta, SageMaker procede con le preferenze rimanenti.

Questa integrazione è limitata all'addestramento. I job di elaborazione ricevono lo stesso meccanismo di fallback ordinato, ma non possono associare preferenze a Flexible Training Plans.

Il caso d'uso per l'elaborazione resta comunque rilevante. SageMaker Processing esegue infrastruttura gestita per preparazione dati, feature engineering, valutazione e attività correlate. Questi job spesso tollerano una gamma hardware più ampia rispetto ai job di addestramento distribuito strettamente ottimizzati.

AWS presenta il cambiamento come un'alternativa ai cicli manuali di ritentativo e agli script di monitoraggio della capacità nel suo post di lancio. Questo è il beneficio immediato più chiaro. Una pipeline invia un solo job, mentre SageMaker gestisce la ricerca di capacità entro i confini dichiarati.

Lo scheduler non sceglie una macchina arbitraria che considera equivalente. Segue l'ordine del cliente. Ciò preserva un'utile divisione delle responsabilità: gli operatori decidono quali configurazioni sono valide e SageMaker decide quale opzione valida può iniziare per prima.

Si tratta di una piccola modifica dell'API con un'implicazione operativa più ampia. La flessibilità dell'infrastruttura può ora accompagnare la definizione del job invece di risiedere nel codice di orchestrazione circostante.

Perché la capacità GPU di SageMaker è diventata un problema di scheduling

La risorsa scarsa non è più solo una GPU; è la giusta configurazione di cluster nella giusta Region al momento giusto.

I team che addestrano modelli di AI discutono spesso degli acceleratori come unità intercambiabili, ma la capacità cloud è suddivisa tra famiglie di istanze, dimensioni, Region, pool di disponibilità, quote e modelli di prenotazione. Un cliente può essere autorizzato a richiedere una macchina senza che tale macchina sia pronta per un'allocazione immediata.

Questa frammentazione crea una gestione degli errori scomoda. Una pipeline può essere tecnicamente corretta e perdere comunque ore perché la configurazione selezionata non riesce ad avviarsi. Un ingegnere deve quindi decidere se attendere, cambiare hardware, modificare il numero di nodi o spostare il workload.

Prima delle liste di preferenze, i job di addestramento SageMaker indicavano un solo tipo di istanza all'invio. I team che accettavano alternative dovevano codificare questa flessibilità altrove. Alcuni costruivano funzioni di ritentativo attorno agli errori API. Altri inviavano diverse varianti e annullavano quelle perdenti dopo l'avvio di una di esse.

Entrambi gli schemi introducono lavoro di coordinamento. Più richieste attive possono complicare osservabilità e annullamento. Gli script di ritentativo sequenziali necessitano di gestione dello stato, regole di backoff, gestione dei timeout, autorizzazioni e protezione contro l'esecuzione duplicata.

Anche il monitoraggio della capacità diventa un ulteriore sistema di produzione. Il team deve mantenerlo quando cambia il comportamento degli SDK, rendere visibili i suoi errori e assicurarsi che un controller riavviato non avvii due volte lo stesso costoso job.

Amazon SageMaker instance preference lists assorbono una parte di questo piano di controllo. La richiesta del job include un insieme delimitato di risultati accettabili e il servizio gestito effettua la selezione quando trova capacità.

Questo modello riflette il comportamento di molti workload reali. Fine-tuning, valutazione, pre-elaborazione e sperimentazione sui modelli hanno spesso una configurazione preferita anziché una sola configurazione matematicamente obbligatoria. Un team potrebbe favorire GPU più recenti per la velocità, ma accettare GPU meno recenti quando il tempo di avvio conta di più.

Lo stesso principio vale per il numero di nodi. Due nodi più veloci e quattro nodi più lenti possono talvolta rispettare un obiettivo di completamento simile. Non sono intrinsecamente equivalenti, ma gli sviluppatori possono testarli e dichiararli entrambi accettabili.

AWS non è sola nel trasformare la scarsità in un'interfaccia di scheduling. La modalità Flex-start di Google Cloud accoda le richieste di acceleratori finché tutte le risorse richieste non diventano disponibili. Google la posiziona per job di addestramento che possono tollerare un orario di avvio flessibile.

I meccanismi differiscono. Il modello di Google enfatizza l'assegnazione e la durata di una richiesta di acceleratori. AWS consente a un job SageMaker di passare attraverso un insieme ordinato di tipi e conteggi. Entrambi gli approcci chiedono ai clienti di esprimere flessibilità anziché sondare ripetutamente la capacità.

Azure Machine Learning espone un'altra parte del vincolo. Le sue quote di calcolo sono gestite per Region e famiglia VM, con limiti separati per l'uso di workspace e sottoscrizione. Le famiglie GPU possono iniziare senza una quota predefinita di core dedicati, a seconda della sottoscrizione.

Questi sistemi mostrano perché la disponibilità degli acceleratori non può essere ridotta a una pagina di catalogo. Un'istanza elencata può essere supportata, ma non disponibile per uno specifico account, luogo, dimensione del job o finestra temporale.

Per i clienti AWS, la pressione immediata ricade sui team che mantengono logiche di provisioning personalizzate. Se un servizio di ritentativo si limita a scorrere i tipi di istanza SageMaker, la sua funzione centrale ora si sovrappone alla piattaforma.

La funzionalità mette inoltre sotto pressione gli standard interni rigidi che approvano esattamente un tipo di istanza per modello. Tali standard semplificavano benchmarking e governance, ma trasformano ogni carenza di capacità in un blocco. I team hanno ora un motivo per certificare diverse configurazioni per ciascun workload.

Questo non elimina l'orchestrazione. Le pipeline necessitano ancora di dipendenze, tracciamento degli artefatti, politiche di errore e convalida successiva all'esecuzione. Il cambiamento restringe il compito dell'orchestrazione, spostando in SageMaker una decisione ricorrente: quale configurazione accettabile può avviarsi.

La flessibilità sostituisce la logica di ritentativo, non i vincoli di capacità

Il meccanismo migliora la ricerca di infrastruttura disponibile, ma non può fornire infrastruttura che non esiste.

Quando arriva un job, SageMaker convalida la sua configurazione e la lista di preferenze rispetto alle risorse e ai limiti supportati. Lo scheduler verifica quindi le opzioni una sola volta nell'ordine dichiarato. La prima opzione disponibile prevale e inizia il provisioning.

Se ogni opzione non è disponibile, la coda guidata dagli eventi attende una variazione rilevante della capacità. Questo è più efficiente del polling continuo da parte del cliente, ma resta comunque una coda. Un job può rimanere in attesa fino alla scadenza del timeout.

Questo limite è importante quando si valuta l'affermazione di AWS secondo cui la funzionalità aiuta i job ad avviarsi prima. Il confronto è con un job vincolato a una configurazione non disponibile o con un sistema di ritentativo gestito dal cliente più lento. AWS non ha pubblicato benchmark indipendenti che mostrino miglioramenti mediani dei tempi di avvio tra Region, famiglie di istanze o dimensioni dei cluster.

Una lista non combina neppure capacità parziale da diverse voci. Se una preferenza richiede otto nodi, SageMaker deve poter predisporre quella configurazione selezionata. Il sistema sceglie una preferenza completa anziché assemblare un cluster eterogeneo da frammenti disponibili.

Questo distingue le preferenze delle istanze dai cluster eterogenei SageMaker. Un cluster eterogeneo esegue deliberatamente più gruppi di istanze all'interno di un unico job di addestramento. Una lista di preferenze rappresenta alternative reciprocamente esclusive, di cui solo una diventa l'ambiente di calcolo del job.

La distinzione protegge la coerenza dell'esecuzione. I framework di addestramento distribuito si aspettano generalmente una topologia nota una volta avviato il job. Selezionare una configurazione predefinita è più semplice che combinare dinamicamente architetture hardware, caratteristiche di rete e profili di memoria.

L'integrazione con Training Plan aggiunge un ulteriore livello decisionale. Una preferenza può puntare a un piano riservato corrispondente, mentre le voci successive usano capacità on-demand. AWS valuta per prima l'opzione riservata quando gli operatori la collocano per prima.

Quella sequenza offre alle organizzazioni un modo diretto per privilegiare la capacità prepagata senza renderla l’unica opzione del job. Tuttavia, il fallback può modificare il risultato economico. Un’alternativa on-demand può avere un costo effettivo diverso e un numero maggiore di nodi può amplificare tale differenza.

La funzionalità non sembra nemmeno sostituire Managed Spot Training. Managed Spot Training affronta un compromesso diverso utilizzando capacità EC2 Spot interrompibile. AWS afferma che questo approccio può ridurre i costi di calcolo, mentre le interruzioni possono prolungare il tempo di completamento e richiedere checkpointing.

Le preferenze delle istanze riguardano principalmente la selezione iniziale della capacità tra configurazioni accettabili. Il training Spot riguarda il modello di acquisto e il rischio di interruzione dopo che un workload ha ottenuto risorse di calcolo. I team devono valutare queste dimensioni separatamente.

Il caso d’uso migliore è quindi un job sensibile ai riavvii ma flessibile rispetto all’hardware. Si consideri una pipeline di valutazione notturna che può essere eseguita su diverse generazioni di GPU. Mancare la finestra di reporting mattutina è importante, ma utilizzare l’acceleratore in assoluto più veloce non lo è.

Il team può certificare diverse configurazioni, ordinarle in base al proprio equilibrio preferito tra tempo di completamento e spesa prevista, quindi impostare un periodo massimo di attesa. SageMaker seleziona all’interno di questo perimetro testato.

I grandi run di pretraining presentano un caso più complesso. I loro schemi di comunicazione, requisiti di memoria, comportamento dei checkpoint e topologia possono essere ottimizzati attorno a un singolo acceleratore e interconnessione. Un fallback nominalmente supportato potrebbe rendere il job più lento, più costoso o instabile.

Il nuovo scheduler non può decidere se quel fallback resti scientificamente o economicamente valido. Tale valutazione resta in capo al proprietario del workload.

Le liste di preferenze delle istanze Amazon SageMaker sono quindi dichiarative, non adattive in senso ampio. SageMaker risponde ai segnali di capacità, ma non esegue benchmark del modello, non riscrive le impostazioni distribuite né ottimizza la lista in funzione di una scadenza.

Questo resta comunque significativo. I servizi gestiti creano valore quando sottraggono a ogni cliente una responsabilità ripetitiva e ben delimitata e la implementano una sola volta. Il fallback della capacità segue questo schema, purché il cliente fornisca limiti di compatibilità realistici.

La compatibilità e il costo restano responsabilità dell’operatore

Il rischio più importante non è che SageMaker scelga la preferenza sbagliata; è che un team dichiari accettabile una preferenza non sicura.

AWS avverte esplicitamente che SageMaker non convalida la compatibilità tra tipi diversi. Il servizio non determina se un container supporti ogni architettura GPU, se i relativi driver siano compatibili o se la sua configurazione distribuita richieda il networking Elastic Fabric Adapter.

Un job può quindi superare la convalida della richiesta e fallire comunque dopo il provisioning. Questo risultato consuma tempo di avvio e può indebolire il beneficio atteso del fallback automatico.

Il comportamento dei framework merita particolare attenzione. Le capacità CUDA, le librerie di comunicazione collettiva, i formati a precisione mista, gli output del compilatore e i kernel specifici del dispositivo possono variare tra generazioni di acceleratori. Non si dovrebbe presumere che un container testato su hardware H100 si comporti in modo identico su hardware A100 o L40S.

Anche la memoria rappresenta un limite. Un workload che rientra nella capacità di un acceleratore può superare la memoria del dispositivo su un altro, anche quando il throughput teorico aggregato sembra simile. Aumentare il numero di nodi non risolve automaticamente i vincoli di memoria per dispositivo.

Anche la topologia distribuita influenza le prestazioni. Sostituire due nodi ad alta larghezza di banda con quattro nodi più lenti modifica il volume di comunicazione, l’overhead di sincronizzazione e l’esposizione ai guasti. Un numero equivalente di GPU o una stima approssimativa della capacità di calcolo non garantiscono lo stesso tempo di completamento.

Gli esempi di AWS illustrano l’intento, non una formula di equivalenza universale. Un esempio elenca due istanze ml.g6.48xlarge prima di quattro istanze ml.g5.48xlarge. Il cliente deve decidere se tale relazione sia valida per il proprio modello, batch size, schema di rete e stack software.

I team dovrebbero eseguire benchmark di ogni configurazione elencata utilizzando la stessa immagine container, lo stesso percorso dei dati e lo stesso launcher distribuito impiegati in produzione. Il record di approvazione risultante dovrebbe includere runtime, verifiche di convergenza, utilizzo, tasso di errore e convalida dell’output.

Anche la politica dei costi richiede la stessa disciplina. L’ordine di preferenza esprime una priorità, non un tetto di spesa. Un fallback con più istanze può avviarsi prima producendo però una fattura complessiva superiore all’opzione preferita.

Al contrario, hardware meno recente può richiedere più tempo e annullare un apparente risparmio per istanza. La misura rilevante è il risultato completo del job, inclusi ritardo di avvio, tempo di esecuzione, tentativi ripetuti, storage e qualsiasi impatto sulle scadenze a valle.

Il lancio introduce inoltre un requisito di osservabilità. I team devono registrare quale preferenza è stata selezionata, per quanto tempo il job è rimasto in attesa, perché le alternative sono state ordinate in quel modo e se le prestazioni effettive hanno corrisposto al benchmark.

Senza questi record, la selezione automatica diventa opaca. Gli ingegneri potrebbero osservare una maggiore variabilità nei tempi di esecuzione o nei costi senza sapere che la famiglia di istanze sottostante è cambiata tra un’esecuzione e l’altra.

Potrebbero essere necessari anche aggiornamenti alle regole di governance. AWS supporta policy di identità che limitano i tipi di istanza SageMaker. L’elenco delle preferenze approvate da un’organizzazione deve rimanere entro tali controlli, le quote dell’account e la disponibilità regionale.

La capacità riservata introduce un’altra potenziale incomprensione. Una preferenza Flexible Training Plan può offrire un impegno di capacità più solido, ma un fallback non trasforma una prenotazione non disponibile in ulteriore capacità riservata. Sposta il job verso un percorso on-demand separatamente accettabile.

I processing job richiedono una propria revisione. Un fallback CPU può avere senso per alcune trasformazioni, ma può anche modificare drasticamente il tempo di completamento. I team dovrebbero evitare di elencare un’opzione CPU solo perché l’API lo consente.

L’assenza di dati pubblicati sul campo è la maggiore incertezza attuale. AWS ha descritto il flusso di pianificazione e le regole di configurazione, ma i clienti non dispongono ancora di evidenze ampie sui miglioramenti dei tempi di avvio in diverse condizioni di scarsità.

Le misurazioni utili dovrebbero confrontare la funzionalità con il baseline esistente di ciascun team. Ciò include il tempo dall’invio all’esecuzione, la percentuale di job che utilizzano un fallback, i tassi di timeout, il consumo totale di calcolo e gli incidenti operativi causati da modifiche di configurazione.

Queste misurazioni riveleranno se la flessibilità della capacità GPU di SageMaker elimina un lavoro manuale reale o se sposta semplicemente la variabilità in un livello meno visibile.

Tre segnali mostreranno se la funzionalità funziona nella pratica

L’adozione dovrebbe essere giudicata in base ai risultati dei job, non dal numero di team che aggiungono un secondo tipo di istanza alla propria configurazione.

Il primo segnale è la frequenza dei fallback abbinata al tempo di avvio. I team dovrebbero misurare con quale frequenza SageMaker seleziona un’opzione diversa dalla prima preferenza e come ciò modifica la latenza dall’invio all’avvio.

Un tasso elevato di fallback con attese più brevi sosterrebbe l’affermazione centrale di AWS. Mostrerebbe che la capacità esiste nell’insieme più ampio anche quando il tipo preferito è limitato.

Un tasso elevato di fallback senza attese più brevi indebolirebbe questa tesi. Potrebbe significare che le alternative elencate condividono lo stesso collo di bottiglia regionale, che i cluster richiesti sono troppo grandi o che la coda guidata dagli eventi non migliora materialmente l’assegnazione per quel workload.

Il secondo segnale è la variabilità delle prestazioni e dei costi tra le configurazioni selezionate. Ogni fallback dovrebbe essere collegato a runtime, utilizzo, stato di completamento e consumo totale di risorse.

Risultati stabili rafforzerebbero l’argomento a favore del trattamento dell’infrastruttura come insieme di preferenze. Deviazioni rilevanti mostrerebbero che le alternative non erano realmente equivalenti, anche se ciascuna configurazione poteva tecnicamente eseguire il container.

Questo è particolarmente importante per le pipeline ricorrenti. Un team può accettare un’esecuzione più lenta durante un esperimento urgente, ma rifiutare un’imprevedibilità persistente in una pianificazione giornaliera di produzione.

Il terzo segnale riguarda il modo in cui AWS espande la funzionalità e la telemetria circostante. I clienti dovrebbero monitorare eventi di selezione più ricchi, spiegazioni più chiare degli stati di attesa, strumenti di ordinamento consapevoli dei costi e una più ampia integrazione con i controlli delle pipeline.

Sarebbe importante anche il supporto per policy più articolate. Gli operatori potrebbero alla fine voler imporre vincoli quali una scadenza, un limite di spesa o il requisito che il throughput del fallback rimanga entro un intervallo testato. L’attuale lista ordinata codifica queste valutazioni manualmente.

Le risposte dei concorrenti forniscono un contesto di supporto, ma le prove decisive verranno dalle operazioni dei clienti. Google tratta già la scarsità di acceleratori come un problema di pianificazione attraverso Dynamic Workload Scheduler. Azure espone i limiti di quota che determinano se i job gestiti possono essere eseguiti.

La mossa distintiva di AWS consiste nell’inserire diverse configurazioni accettabili direttamente in una richiesta di training o processing SageMaker. Se i clienti otterranno avvii più rapidi senza variabilità inaccettabile, questo modello diventerà difficile da ignorare per le piattaforme ML gestite.

Il test a breve termine è semplice. Selezionate un workload flessibile rispetto all’hardware, eseguite benchmark di ogni configurazione candidata e definite un tempo massimo di attesa prima di abilitare il fallback automatico. Confrontate quindi almeno diverse esecuzioni con il precedente processo di tentativi ripetuti.

Registrate il tipo di istanza scelto, la durata in coda, il tempo di esecuzione, lo stato di completamento e l’uso totale delle risorse. Non considerate un avvio riuscito come l’intero risultato.

Le liste di preferenze delle istanze Amazon SageMaker rendono la gestione della capacità meno manuale, ma premiano la preparazione. I team che convalidano le proprie alternative possono eliminare codice infrastrutturale fragile. I team che inseriscono fallback speculativi potrebbero soltanto automatizzare la scoperta dell’incompatibilità.

La domanda utile non è se cinque opzioni siano migliori di una. È se la vostra organizzazione possa definire cinque risultati realmente accettabili, ordinarli deliberatamente e misurare cosa accade quando SageMaker sceglie tra essi.