Uno script che addestra un modello sul portatile e un job che lo addestra in cloud si somigliano solo in apparenza: il secondo deve dichiarare dove sta il codice, quale ambiente lo esegue, quali dati riceve, su quale compute gira e sotto quale esperimento va archiviato. In Azure Machine Learning quella dichiarazione è il command job in YAML, versionato accanto al codice.

Il command job: il contratto fra il tuo codice e la piattaforma

Il command job è l’unità di lavoro base del modello a oggetti v2, e le sue chiavi ricorrono in ogni domanda: code è la cartella caricata, command la riga eseguita nel container, environment l’immagine con le dipendenze, compute il target, inputs e outputs dichiarano i dati, display_name ed experiment_name decidono come il job comparirà nello studio.

$schema: https://azuremlschemas.azureedge.net/latest/commandJob.schema.json
code: src
command: >-
  python train.py --data ${{inputs.training_data}} --learning-rate ${{inputs.lr}}
inputs:
  training_data:
    type: uri_folder
    path: azureml:credit-data@latest
    mode: ro_mount
  lr: 0.05
environment: azureml:credit-training-env@latest
compute: azureml:cpu-cluster
experiment_name: credit-default

Tre dettagli qualificano un candidato Associate. Gli input si passano allo script con le espressioni ${{inputs.nome}}, non incollando percorsi di storage. Gli asset si citano con azureml:nome:versione oppure azureml:nome@latest, ma in una pipeline di rilascio il pin esplicito è preferibile perché @latest rende il job non riproducibile. E mode decide come il dato arriva al compute: ro_mount, download o direct.

Da riga di comando: az ml job create -f job.yml, poi az ml job stream -n NOME per i log e az ml job show per lo stato. È ciò che uno step di GitHub Actions esegue dopo essersi autenticato ad Azure. Gli errori tipici sono riconoscibili: EnvironmentNotFound se il curated environment citato è deprecato, ComputeNotFound se il cluster non esiste più, QuotaExceeded se la quota di vCPU non basta per la VM richiesta.

Scegliere il compute senza pensarci ogni volta

Per il training hai tre strade. Il compute cluster è gestito da Azure Machine Learning, scala fra un minimo e un massimo di nodi, scende a zero da fermo, supporta VM low priority e può avere una managed identity system-assigned o user-assigned. La compute instance è single-node e serve allo sviluppo, non alle pipeline. Il serverless compute si ottiene omettendo la proprietà compute: Azure Machine Learning sceglie e gestisce la macchina, tu puoi comunque fissare instance_type e instance_count dentro resources e scegliere fra VM dedicate e spot con queue_settings e job_tier. Il serverless consuma la stessa quota di Azure Machine Learning Compute, quindi non aggira nulla; supporta il credential passthrough dell’utente e la user-assigned managed identity del workspace, ma non l’identità system-assigned.

AutoML: esplorazione automatica, non delega della decisione

AutoML lancia in parallelo molte prove combinando algoritmi, featurization e iperparametri; ogni iterazione produce un modello con un punteggio e il processo si ferma quando scattano i criteri di uscita. I task supportati sono classification, regression, forecasting di serie storiche, computer vision e NLP, e si configurano da SDK Python v2, CLI v2 o studio. La featurization automatica non è un passo esterno: le trasformazioni scelte diventano parte del modello e si riapplicano in inferenza. Per default AutoML costruisce anche ensemble, con metodi voting e stacking, che compaiono come ultime iterazioni del job.

Il punto MLOps è che AutoML resta un job come gli altri, da configurare in modo dichiarativo e da limitare esplicitamente: primary_metric e target_column_name definiscono l’obiettivo, training_data, validation_data e n_cross_validations la valutazione, e i limiti (timeout_minutes, trial_timeout_minutes, max_trials, max_concurrent_trials, enable_early_termination, exit_score) impediscono che un esperimento bruci budget per un guadagno marginale. Puoi restringere lo spazio con allowed_training_algorithms o escludere famiglie con blocked_training_algorithms, e chiedere l’interpretabilità con enable_model_explainability.

AutoML è la scelta giusta come baseline rapida su un problema ben definito, con una metrica primaria già concordata. Diventa un modo per non decidere quando serve a evitare di scegliere quella metrica, quando i vincoli reali di latenza, spiegabilità e dimensione del modello non compaiono in nessuna configurazione, o quando il vincitore va in produzione senza che nessuno abbia guardato i child job.

Addestramento distribuito: cosa cambia davvero con più nodi

Le due strategie sono data parallelism, dove ogni processo tiene una copia del modello e vede una porzione dei dati, e model parallelism, dove è il modello a essere spezzato perché non entra in una GPU. Nella grande maggioranza dei casi la risposta è data parallelism.

In v2 non serve un launcher esterno: si dichiara distribution nel job. Per PyTorch imposti type: pytorch e process_count_per_instance, di norma pari al numero di GPU per nodo, più instance_count per i nodi; se lo ometti parte un solo processo per nodo. Azure Machine Learning imposta poi MASTER_ADDR, MASTER_PORT, WORLD_SIZE e NODE_RANK su ciascun nodo e RANK e LOCAL_RANK per ogni processo: sono le variabili che torch.distributed.init_process_group legge con il metodo di inizializzazione env://. Su GPU il backend da usare è nccl. Per TensorFlow c’è type: tensorflow con worker_count e, per lo schema parameter server, parameter_server_count, e il servizio compila TF_CONFIG per ogni worker. DeepSpeed si abilita sopra la distribuzione PyTorch o MPI. Infine la scalabilità quasi lineare dipende dalla rete: le VM abilitate InfiniBand hanno una r nel nome dello SKU, e senza quell’hardware aggiungere nodi rende meno del previsto.

Da ricordare per l esame

  • Il command job dichiara code, command, environment, compute, inputs e outputs; gli input si consumano con ${{inputs.nome}}, gli asset si citano come azureml:nome:versione.
  • Il serverless compute si richiede omettendo compute; usa la stessa quota di Azure Machine Learning Compute e non supporta l’identità system-assigned.
  • AutoML copre classification, regression, forecasting, computer vision e NLP; la featurization automatica entra nel modello e si riapplica in inferenza.
  • I limiti di un job AutoML (max_trials, timeout_minutes, enable_early_termination, exit_score) sono il controllo di costo, non un dettaglio.
  • Per il distribuito si usa distribution con process_count_per_instance e instance_count; rank e world size li imposta Azure Machine Learning come variabili d’ambiente.