SageMaker training job e algoritmi built-in

Un SageMaker training job è un lavoro di addestramento gestito: definisci un Estimator con tipo e numero di instance, i canali di input che leggono i dati da Amazon S3, la destinazione S3 per gli artefatti del modello e un IAM role. SageMaker fa provisioning del cluster, esegue il container, salva model.tar.gz su S3 e smonta tutto. Per l’input scegli l’input mode in base alla dimensione del dataset: File copia tutto sul volume prima di partire, mentre Pipe e FastFile fanno streaming da S3 evitando di aspettare la copia su dataset molto grandi.

Gli algoritmi built-in sono container mantenuti da AWS: non scrivi codice di training, passi solo i dati nel formato atteso (CSV, libsvm o RecordIO-protobuf) e gli hyperparameter. XGBoost è gradient boosting su alberi, prima scelta per dati tabulari (classificazione, regressione, ranking), robusto e spesso vincente sui problemi strutturati. Linear Learner addestra modelli lineari/logistici, gestisce sia regressione sia classificazione (anche multiclasse) e in un solo job allena in parallelo più modelli con iperparametri diversi scegliendo il migliore sulla validation.

Script mode e container custom da ECR

Quando ti serve una rete neurale o logica custom, usa lo script mode: fornisci il tuo entry_point (uno script Python) e SageMaker lo esegue dentro il framework container gestito da AWS per TensorFlow, PyTorch, scikit-learn o Hugging Face. Ottieni la flessibilità del framework senza costruire immagini.

Se hai dipendenze particolari, un runtime non supportato o una toolchain proprietaria, porti la tua immagine (bring your own container) e la pubblichi su Amazon ECR: SageMaker la esegue purché rispetti il contratto dei path (/opt/ml/input, /opt/ml/model, /opt/ml/output). Il criterio di scelta è per sforzo crescente: built-in (zero codice) → script mode (flessibilità sul framework) → container ECR custom (controllo totale). Scegli il livello più basso che soddisfa il requisito.

Automatic model tuning e distributed training

L’automatic model tuning (hyperparameter tuning job) lancia molti training job esplorando range di iperparametri per ottimizzare una objective metric. Le strategie di ricerca:

  • Bayesian: impara dai trial precedenti per proporre la combinazione successiva, efficiente in numero di job. È la scelta di default nella maggior parte degli scenari.
  • Random e Grid: esplorazione non guidata; Grid è esaustivo e costoso.
  • Hyperband: usa early stopping per fermare i trial scarsi, ottimo per algoritmi iterativi (deep learning).

La objective metric va coerente col problema: RMSE/MSE per la regressione, F1 o recall per la classificazione sbilanciata (l’accuracy inganna quando le classi sono squilibrate). Per gli algoritmi built-in le metriche sono predefinite; per gli script custom le estrai dai log via regex. Per accelerare job pesanti aumenta instance_count e usa il distributed training con librerie data parallel (dataset grande) o model parallel (modello troppo grande per una singola GPU).

Managed spot training e checkpointing

Il managed spot training usa istanze Spot e riduce i costi di training fino a circa il 90%. Poiché le Spot possono essere interrotte, imposta il MaxWaitTime (tempo totale, attesa inclusa) maggiore o uguale al MaxRuntime dell’addestramento: se sono uguali il job non ha margine per aspettare capacità e fallisce. Per non ripartire da zero dopo un’interruzione, abilita il checkpointing salvando i checkpoint su S3: al riavvio SageMaker li ripristina e il training riprende. È la combinazione chiave per addestramenti lunghi ed economici.

Trappole tipiche d’esame

  • Costi di training da ridurre su job lungo → managed spot training con checkpointing su S3: attiva le Spot instance e imposta MaxWaitTime > MaxRuntime, altrimenti il job non tollera le interruzioni.
  • Dati tabulari, massimo risultato con minimo codice → XGBoost built-in: non serve script mode né container ECR per un problema strutturato classico.
  • Classi sbilanciate nel tuning → objective metric F1 o recall, non accuracy: l’accuracy resta alta anche ignorando la classe minoritaria e falsa l’ottimizzazione.
  • Runtime non standard o dipendenze custom → immagine su Amazon ECR (BYOC): se basta cambiare framework resta sullo script mode, l’ECR custom solo quando serve controllo totale.
  • Molte combinazioni di iperparametri con budget limitato → strategia Bayesian (o Hyperband): convergono con meno job rispetto a Grid/Random.
  • Dataset enorme che rallenta l’avvio → input mode Pipe/FastFile invece di File: evita di copiare tutto sul volume prima di iniziare il training.