The Pulse
AWS aggiunge il caricamento differito SOCI ai job di training di SageMaker
AWS sta aggiungendo gli indici Seekable OCI ai job di training ed elaborazione di Amazon SageMaker AI, consentendo ai container di avviarsi prima che le loro immagini siano state scaricate completamente. Nei benchmark di AWS, un’immagine da
AI.info Team · Scritto con l’IA · verificato ·
Amazon Web Services ha annunciato il 27 ottobre che i job di training ed elaborazione di SageMaker AI possono usare gli indici Seekable OCI (SOCI) per avviare i container prima di scaricarne completamente le immagini. Anziché attendere l’arrivo di tutti i layer, SageMaker recupera i file necessari per avviare un container e scarica gli altri man mano che il job li utilizza. Secondo AWS, la modifica non richiede interventi sulla definizione del job, sull’entry point o sui canali dati.
Sei secondi per avviare un’immagine da 13,2 GB
Il ritardo su cui interviene SOCI si verifica prima che il codice del modello venga eseguito: di norma, i job di SageMaker scaricano e decomprimono l’intera immagine del container, poi la scrivono sull’istanza. Secondo AWS, le immagini per il deep learning superano spesso i 10 GB, rendendo l’attesa una componente ricorrente del tempo fatturabile dei job. L’attesa può incidere maggiormente negli esperimenti brevi, nelle attività di elaborazione e nelle ricerche di iperparametri composte da molti job.
Nel benchmark di AWS, il download convenzionale di un’immagine compressa da 13,2 GB ha richiesto un tempo mediano di 3 minuti e 42 secondi, contro circa sei secondi con il caricamento differito. Su otto immagini, da 1,8 GB a 35,4 GB, l’azienda ha misurato tempi di avvio con SOCI compresi tra 3 e 11 secondi, rispetto ai 48 secondi-7 minuti e 17 secondi dei download convenzionali. I test hanno utilizzato job di SageMaker AI su istanze CPU e GPU nelle regioni US West (Oregon) e US East (N. Virginia).
La prima epoca richiede comunque più tempo
Avviare prima il container non significa che tutti i file siano già disponibili in locale. AWS ha rilevato che la prima epoca di training ha richiesto da 3 a 16 secondi in più con un’immagine caricata in modo differito, perché i framework hanno scaricato i file man mano che li utilizzavano per la prima volta; le epoche successive sono state eseguite alla stessa velocità ottenuta con un download completo, al netto delle variazioni tra un’esecuzione e l’altra. Secondo AWS, per i job di training testati il risultato netto è stato una conclusione anticipata da 1 a 6 minuti.
Il risparmio dipende da ciò che un job legge prima di iniziare il lavoro effettivo. Se il codice di avvio esamina gran parte dell’immagine, ne calcola i checksum o la precarica, la prima epoca potrebbe dover attendere buona parte degli stessi dati che verrebbero scaricati con un download completo. I test di AWS hanno inoltre rilevato un beneficio netto minore quando i carichi di lavoro caricavano all’inizio pesi di modelli di grandi dimensioni o codice compilato: anche quei file dovevano essere scaricati prima dell’uso.
Immagini preindicizzate o build personalizzate
Gli utenti possono passare a un AWS Deep Learning Container con tag «-soci» oppure generare un indice per un’immagine personalizzata e archiviarlo in Amazon Elastic Container Registry. SageMaker verifica la presenza di un indice quando crea un job; se l’indice non esiste o il caricamento differito non riesce, il job ricorre invece a un download standard. Secondo AWS, il digest e le firme dell’immagine originale restano validi perché l’indice è archiviato come artefatto separato conforme a OCI.
AWS elenca opzioni preindicizzate per PyTorch Training, TensorFlow Training, vLLM e SGLang, con varianti ARM64 per alcuni framework. Per indicizzare immagini personalizzate servono un host Linux con containerd e SOCI snapshotter, oltre a Finch o nerdctl. Secondo AWS, il supporto è disponibile in tutte le regioni, ma le immagini devono trovarsi in repository ECR privati; le immagini scaricate tramite un registro Docker privato usando la modalità di accesso ai repository VPC di SageMaker non sono idonee.
Dove il caricamento differito può contare di più
Il benchmark suggerisce che i vantaggi maggiori riguardano le immagini di grandi dimensioni e i job che iniziano a lavorare dopo aver utilizzato solo una parte del loro contenuto. AWS segnala guadagni relativamente modesti per le immagini inferiori a circa 4 GB. Si tratta di una modifica mirata all’avvio dei job, non di un’accelerazione del ciclo di training, e il suo valore pratico dipenderà dalle dimensioni dell’immagine, dal comportamento all’avvio e dalla quantità di contenuto dell’immagine di cui un carico di lavoro ha bisogno immediatamente.