Treinar, interpretar e ajustar execuções
Inicia uma execução na nuvem com um orçamento definido, avalia-a pelas curvas por época e faz o ajuste fino sem que o otimizador predefinido ignore a tua taxa de aprendizagem.
Uma GPU na nuvem é cobrada por cada minuto de uma execução condenada ao fracasso, e o erro mais comum no ajuste fino não custa nada, mas desperdiça silenciosamente a execução: o otimizador predefinido ignora a taxa de aprendizagem que definiste. Nesta lição, treinas um modelo real com o conjunto de dados de comprimidos médicos, interpretas as curvas com uma regra de decisão e fazes o ajuste fino para que as tuas definições sejam realmente aplicadas.
Prático
Iniciar uma execução#
Clica em Novo modelo na página de um projeto ou conjunto de dados. O separador Treino na nuvem apresenta as seguintes definições:

| Parâmetro | Padrão | Quando alterar |
|---|---|---|
| Modelo base | Escolhe uma opção em Oficial (recomendamos YOLO26) | Se fores fazer um ajuste fino, escolhe a execução anterior em Os meus modelos |
| Conjunto de dados | — | Ativa sempre Guardar versão do conjunto de dados para fixar os dados usados na execução |
| Épocas | 100 | Teste rápido (10–20) ou conjuntos de dados muito grandes |
| Tamanho do lote | -1 (ajusta-se automaticamente à memória da GPU) | Precisas de duas execuções para fazer uma comparação exata |
| Tamanho da imagem | 640 | Os objetos são pequenos: aumenta o tamanho (o controlo deslizante vai até 1280; o editor YAML aceita até 4096) |
| Definições avançadas | Predefinições | Mais de 50 argumentos model.train() em YAML, incluindo o otimizador, a taxa de aprendizagem e o aumento de dados |
Os argumentos são os mesmos que model.train(...) aceita localmente, e a página do modelo mostra mais tarde um comando yolo train que podes copiar, com os valores não predefinidos.
Escolher a GPU e definir o orçamento da execução#
| Categoria | Exemplos (VRAM, preço por hora) | Adequado para |
|---|---|---|
| Económica | RTX 2000 Ada (16 GB, $0.24), RTX A5000 (24 GB, $0.27), RTX 4090 (24 GB, $0.69) | Testes rápidos, modelos nano e pequenos |
| Intermédia | L40S (48 GB, $0.86), RTX 5090 (32 GB, $0.99), A100 SXM (80 GB, $1.49) | Modelos médios, lotes maiores |
| Padrão | RTX PRO 6000 (96 GB, $2.09) | A maioria das tarefas |
| Gama alta | H100 SXM (80 GB, $3.29), H200 SXM (141 GB, $4.39) | Grandes conjuntos de dados quando o tempo é importante |
| Pro e Enterprise | B200 (180 GB, $5.89), B300 (288 GB, $7.39) | Os trabalhos mais exigentes |
O cartão de custos estima a duração e o preço antes de começares: cerca de $0.23 para 1,000 imagens × YOLO26n × 100 épocas na RTX PRO 6000 predefinida, e cerca de $1.56 para 5,000 imagens × YOLO26s × 100 épocas numa H100 SXM, que treina aproximadamente 3.4× mais depressa do que uma RTX 4090. A faturação baseia-se no tempo real de GPU: as execuções concluídas, canceladas e falhadas são cobradas assim que uma GPU começa a trabalhar; uma execução precisa de saldo suficiente para cobrir a estimativa (pelo menos 15 minutos de tempo de GPU); e as execuções ativas são interrompidas se o saldo ficar negativo. Por isso, ativa o carregamento automático em Settings > Billing para trabalhos longos. Se selecionares uma GPU mais barata do que a RTX PRO 6000, podes receber uma atualização gratuita para essa GPU quando a capacidade gerida pela Ultralytics estiver inativa, continuando a pagar a tarifa da GPU selecionada.
Regras de decisão: testa um novo conjunto de dados com 10–20 épocas na GPU predefinida. Passa para uma H100 ou H200 quando uma execução demora horas e alguém está à espera. Escolhe uma GPU mais barata, não uma mais rápida, quando a utilização da GPU se mantém baixa.
Acompanha a execução#
O separador Train da página do modelo transmite dados em três subtabs. Charts apresenta métricas, perdas de treino e validação, e a taxa de aprendizagem por época; Console mantém as últimas 2,000 linhas e interrompe a execução imediatamente se detetar um traceback ou um erro de falta de memória CUDA; System mostra a utilização, a memória e a temperatura da GPU:


Uma execução que não apresenta resultados durante 4 horas é marcada como falhada. O melhor checkpoint é carregado periodicamente, por isso uma execução cancelada mantém a melhor época alcançada até então, e os alertas do Slack podem avisar-te quando as execuções terminam ou falham.
Exemplo prático: treinar, acompanhar e interpretar uma execução#
Podes treinar em qualquer lugar e continuar a acompanhar a execução na Platform. Com uma chave de API de Settings > API Keys exportada como ULTRALYTICS_API_KEY, um project do formato username/project transmite gráficos, consola e o melhor checkpoint para esse projeto:
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.ptO mesmo comando é executado nas GPUs da Platform quando clicas em New Model; localmente, demorou menos de dois minutos numa CPU de portátil com imgsz=320. O results.csv da execução contém as séries por época apresentadas no subtab Charts, por isso bastam algumas linhas para transformar «acompanhar as curvas» numa regra:
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 helpA melhor época é a última, o mAP50-95 subiu 2.8 pontos nas últimas três épocas e a perda de validação continua a diminuir: esta execução de 10 épocas parou cedo, e uma execução mais longa ou um ajuste fino serão úteis. Usa os mesmos três sinais no subtab Charts de qualquer execução da Platform: a posição da melhor época, o ganho recente e a direção da perda de validação.
Ajustar o modelo a partir de um modelo anterior#
Seleciona o teu modelo anterior em My Models como modelo base; a Platform cria um novo modelo que começa nesse checkpoint e não altera o modelo antigo. O conselho habitual é usar uma taxa de aprendizagem mais baixa, mas, com o valor predefinido optimizer: auto, o treino escolhe o próprio otimizador e a própria taxa de aprendizagem, ignorando lr0. A consola indica isso nas primeiras linhas:
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)Define optimizer explicitamente em Advanced Settings para aplicar o valor. O registo do ajuste fino do modelo de pílulas durante mais 5 épocas com optimizer: SGD e lr0: 0.001 é:
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.687O mAP50-95 subiu de 0.659 para 0.687. Na próxima lição, vais submeter este modelo candidato a um critério de promoção.

Para reproduzir uma execução anterior, abre a tabela Training Configuration na página do modelo, escolhe Copy JSON e cola o conteúdo em Advanced Settings. O guia de ajuste fino aborda o congelamento de camadas, e o guia de ajuste de hiperparâmetros aborda varrimentos sistemáticos.
Armadilhas#
Sintoma: você define lr0: 0.001, e o console exibe ignoring 'lr0=...'. Solução: com optimizer: auto, o treinamento escolhe o otimizador e a taxa de aprendizado. Defina optimizer como SGD ou AdamW, junto com lr0, e depois confirme a linha optimizer: no console.
Sintoma: a aba secundária System mostra utilização da GPU bem abaixo de 80% durante toda a execução. Solução: o gargalo está no carregamento de dados, não na GPU, então uma GPU mais rápida só custa mais. Escolha uma GPU mais barata ou aumente o tamanho do lote, se a memória permitir.
Sintoma: o mAP50-95 de validação ficou estável por 10 épocas, enquanto a perda de validação continua aumentando. Solução: cancele. O melhor checkpoint até agora será mantido, e o próximo ganho virá dos dados (lições 3 e 4), não de mais épocas.
Mostrar solução
Exemplo de resposta para as pílulas médicas: o modelo de referência de 10 épocas atinge o pico na época 10, com mAP50-95 de 0.659, um aumento de +0.028 nas últimas três épocas e a perda de caixas de validação a diminuir de 1.367 para 1.045; por isso, o veredito é «continuar». Em vez de treinar de raiz, faz um ajuste fino: modelo base v1-baseline em My Models, 5 épocas, Advanced Settings optimizer: SGD e lr0: 0.001. A consola confirma SGD(lr=0.001, momentum=0.937), e o mAP50-95 chega a 0.687. O custo na GPU predefinida é de alguns cêntimos; o cartão de custos apresenta a estimativa antes de clicares em Start Training, e Settings > Billing mostra o valor efetivamente cobrado.