Addestrare, leggere e perfezionare le esecuzioni
Avvia un'esecuzione cloud con un budget definito, valutala tramite le curve per epoca e fai fine-tuning senza che l'ottimizzatore predefinito ignori il tuo learning rate.
Una GPU cloud viene addebitata per ogni minuto in cui un'esecuzione destinata a fallire continua, e l'errore di fine-tuning più frequente non costa nulla ma spreca silenziosamente l'esecuzione: l'ottimizzatore predefinito ignora il learning rate impostato. In questa lezione addestrerai un modello reale sul dataset medical pills, ne analizzerai le curve applicando una regola decisionale e lo sottoporrai a fine-tuning in modo che le impostazioni vengano effettivamente applicate.
Pratico
Avvia un'esecuzione#
Fai clic su New Model nella pagina di un progetto o dataset. La scheda Cloud Training ti guida nella configurazione di queste impostazioni:

| Impostazione | Predefinita | Modificalo quando |
|---|---|---|
| Modello base | Scegli un modello nella sezione Official (consigliato YOLO26) | Per il fine-tuning, scegli l'esecuzione precedente nella sezione My Models |
| Dataset | — | Attiva sempre Save Dataset Version per associare l'esecuzione ai relativi dati |
| Epoche | 100 | Test rapido (10–20) o dataset molto grandi |
| Dimensione del batch | -1 (adatta automaticamente il batch alla memoria della GPU) | Ti servono due esecuzioni per un confronto esatto |
| Dimensione dell'immagine | 640 | Gli oggetti sono piccoli: aumentala (il cursore si ferma a 1280; l'editor YAML accetta fino a 4096) |
| Impostazioni avanzate | Valori predefiniti | Oltre 50 argomenti model.train() in YAML, inclusi ottimizzatore, learning rate e aumento dei dati |
Gli argomenti sono gli stessi accettati in locale da model.train(...) e in seguito la pagina del modello mostra un comando yolo train copiabile con i valori non predefiniti.
Scegli la GPU e definisci il budget dell'esecuzione#
| Fascia | Esempi (VRAM, prezzo orario) | Adatto a |
|---|---|---|
| Economica | RTX 2000 Ada (16 GB, $0.24), RTX A5000 (24 GB, $0.27), RTX 4090 (24 GB, $0.69) | Test rapidi, modelli nano e small |
| Media | L40S (48 GB, $0.86), RTX 5090 (32 GB, $0.99), A100 SXM (80 GB, $1.49) | Modelli medi, batch più grandi |
| Predefinita | RTX PRO 6000 (96 GB, $2.09) | La maggior parte dei carichi di lavoro |
| Fascia alta | H100 SXM (80 GB, $3.29), H200 SXM (141 GB, $4.39) | Dataset di grandi dimensioni quando il tempo è importante |
| Pro ed Enterprise | B200 (180 GB, $5.89), B300 (288 GB, $7.39) | I job più impegnativi |
La scheda dei costi stima durata e prezzo prima dell'avvio: circa $0.23 per 1.000 immagini × YOLO26n × 100 epoche sulla RTX PRO 6000 predefinita e circa $1.56 per 5.000 immagini × YOLO26s × 100 epoche su una H100 SXM, che addestra circa 3.4× più velocemente di una RTX 4090. La fatturazione si basa sul tempo GPU effettivo: le esecuzioni completate, annullate e non riuscite vengono addebitate non appena la GPU si avvia; un'esecuzione richiede un saldo che copra la stima (almeno 15 minuti di tempo GPU) e le esecuzioni attive si interrompono se il saldo diventa negativo. Per i job lunghi, attiva la ricarica automatica in Settings > Billing. Se selezioni una GPU meno costosa della RTX PRO 6000, puoi ricevere gratuitamente un upgrade a quest'ultima quando la capacità gestita da Ultralytics è inattiva, mantenendo la tariffa selezionata.
Regole decisionali: prova un nuovo dataset con 10–20 epoche sulla GPU predefinita. Passa a una H100 o H200 quando un'esecuzione dura ore e qualcuno ne aspetta il risultato. Scegli una GPU meno costosa, non una più veloce, quando l'utilizzo della GPU rimane basso.
Monitora l'esecuzione#
La scheda Train della pagina del modello trasmette dati in streaming in tre sottoschede. Charts traccia le metriche, le perdite di training e convalida e il tasso di apprendimento per epoca; Console conserva le ultime 2.000 righe e interrompe subito l'esecuzione in caso di traceback o errore CUDA out-of-memory; System mostra utilizzo, memoria e temperatura della GPU:


Un'esecuzione che non fornisce risultati per 4 ore viene contrassegnata come non riuscita. Il checkpoint migliore viene caricato periodicamente, quindi un'esecuzione annullata conserva la migliore epoca raggiunta fino a quel momento; gli avvisi Slack possono avvisarti quando le esecuzioni vengono completate o non riescono.
Esempio pratico: addestrare, trasmettere in streaming e analizzare un'esecuzione#
Puoi addestrare ovunque e monitorare comunque l'esecuzione in Platform. Con una chiave API ottenuta da Settings > API Keys ed esportata come ULTRALYTICS_API_KEY, un project del formato username/project trasmette grafici, console e checkpoint migliore nel progetto:
from ultralytics import YOLO
# export ULTRALYTICS_API_KEY="..." first to stream this run into your Platform project
model = YOLO("yolo26n.pt")
results = model.train(data="medical-pills.yaml", epochs=10, imgsz=320, project="username/pill-inspection", name="v1-baseline")
print(f"mAP50-95 {results.box.map:.3f}, best checkpoint: {model.trainer.best}") Class Images Instances Box(P R mAP50 mAP50-95)
all 23 399 0.97 0.957 0.977 0.659
mAP50-95 0.659, best checkpoint: .../runs/detect/username/pill-inspection/v1-baseline/weights/best.ptLo stesso comando viene eseguito sulle GPU di Platform quando fai clic su New Model; in locale, su una CPU di laptop, ha richiesto meno di due minuti con imgsz=320. results.csv dell'esecuzione contiene le serie per epoca tracciate dalla sottoscheda Charts, quindi bastano poche righe per trasformare "osserva le curve" in una regola:
import pandas as pd
df = pd.read_csv("results.csv") # the per-epoch metrics behind the Charts subtab
df.columns = df.columns.str.strip()
m = df["metrics/mAP50-95(B)"]
best_epoch = int(df.loc[m.idxmax(), "epoch"])
recent_gain = m.iloc[-1] - m.iloc[-4] # change over the last 3 epochs
val_loss = df["val/box_loss"]
print(f"epochs={len(df)} best mAP50-95={m.max():.3f} at epoch {best_epoch}")
print(f"gain over last 3 epochs: {recent_gain:+.3f}")
print(f"val box loss: {val_loss.iloc[0]:.3f} -> {val_loss.iloc[-1]:.3f}")
if recent_gain < 0.005 and val_loss.iloc[-1] >= val_loss.iloc[-4]:
print("verdict: plateaued - stop, and fix the data before training longer")
elif best_epoch == len(df):
print("verdict: still improving at the last epoch - more epochs should help")
else:
print("verdict: converged - keep best.pt")epochs=10 best mAP50-95=0.659 at epoch 10
gain over last 3 epochs: +0.028
val box loss: 1.367 -> 1.045
verdict: still improving at the last epoch - more epochs should helpLa migliore è l'ultima epoca, mAP50-95 è aumentato di 2.8 punti nelle ultime tre epoche e la perdita di convalida continua a diminuire: questa esecuzione di 10 epoche si è interrotta presto e un'esecuzione più lunga o un fine-tuning sarà utile. Usa gli stessi tre segnali nella sottoscheda Charts di qualsiasi esecuzione su Platform: la posizione della migliore epoca, il miglioramento recente e l'andamento della perdita di convalida.
Eseguire il fine-tuning a partire da un modello precedente#
Scegli il modello precedente in My Models come modello di base; Platform crea un nuovo modello che parte da quel checkpoint e lascia invariato quello precedente. Di solito si consiglia un tasso di apprendimento più basso, ma con il valore predefinito optimizer: auto il training sceglie autonomamente ottimizzatore e tasso di apprendimento e ignora lr0. La console lo indica nelle prime righe:
optimizer: 'optimizer=auto' found, ignoring 'lr0=0.01' and determining best 'optimizer' and 'lr0' automatically...
optimizer: AdamW(lr=0.002, momentum=0.9) with parameter groups 114 weight(decay=0.0), 126 weight(decay=0.0005), 126 bias(decay=0.0)Imposta esplicitamente optimizer in Advanced Settings e il valore verrà mantenuto. Il fine-tuning del modello delle pillole per altre 5 epoche con optimizer: SGD e lr0: 0.001 registra:
optimizer: SGD(lr=0.001, momentum=0.937) with parameter groups 114 weight(decay=0.0), 126 weight(decay=0.0005), 126 bias(decay=0.0)
all 23 399 0.969 0.962 0.983 0.687mAP50-95 è passato da 0.659 a 0.687. Nella prossima lezione sottoporrai questo modello candidato a un processo di approvazione.

Per riprodurre un'esecuzione precedente, apri la tabella Training Configuration nella pagina del modello, scegli Copy JSON e incollalo in Advanced Settings. La guida al fine-tuning illustra il congelamento dei layer, mentre la guida all'ottimizzazione degli iperparametri tratta le esplorazioni sistematiche.
Insidie#
Sintomo: imposti lr0: 0.001 e la console mostra ignoring 'lr0=...'. Soluzione: con optimizer: auto, l'addestramento sceglie autonomamente l'ottimizzatore e il tasso di apprendimento. Imposta optimizer su SGD o AdamW insieme a lr0, quindi verifica la riga optimizer: nella console.
Sintomo: la scheda secondaria System mostra un utilizzo della GPU ben al di sotto dell'80% per tutta l'esecuzione. Soluzione: il collo di bottiglia è il caricamento dei dati, non la GPU, quindi una GPU più veloce costa soltanto di più. Scegli una GPU meno costosa oppure aumenta la dimensione del batch, se la memoria lo consente.
Sintomo: la mAP50-95 di convalida è stabile da 10 epoche, mentre la loss di convalida aumenta lentamente. Soluzione: annulla l'esecuzione. Il miglior checkpoint ottenuto finora viene conservato e il prossimo miglioramento arriverà dai dati (lezioni 3 e 4), non da altre epoche.
Mostra la soluzione
Esempio svolto sulle pillole mediche: la baseline di 10 epoche raggiunge il picco all'epoca 10 con mAP50-95 pari a 0.659, in aumento di +0.028 nelle ultime tre epoche, mentre la perdita di box in convalida scende da 1.367 a 1.045; il verdetto è quindi 'continuare'. Invece di riaddestrare da zero, esegui il fine-tuning: modello di base v1-baseline in My Models, 5 epoche, Advanced Settings optimizer: SGD e lr0: 0.001. La console conferma SGD(lr=0.001, momentum=0.937) e mAP50-95 raggiunge 0.687. Il costo sulla GPU predefinita è di pochi centesimi; la scheda dei costi mostra la stima prima che tu faccia clic su Start Training, mentre Settings > Billing mostra l'addebito effettivo in seguito.