Escolhe o tamanho de modelo Ultralytics YOLO
Compara YOLO26 n, s, m, l e x, testa-os no hardware de destino e escolhe o menor tamanho que se enquadre no teu limite de latência.
Escolhe um modelo demasiado grande e uma aplicação de câmara de 30 FPS funciona a 12 FPS; escolhe um demasiado pequeno e abdicas da precisão adicional que um modelo maior ofereceria sem custos numa GPU. Como o tamanho que treinas é o tamanho que implementas, faz esta escolha antes da longa sessão de treino.
O YOLO26 está disponível em cinco tamanhos — n, s, m, l e x — para as sete tarefas: deteção, segmentação, segmentação semântica, classificação, pose, OBB e profundidade. Nesta lição, vais converter uma taxa de fotogramas num orçamento em milissegundos, medir dois tamanhos na tua máquina com o modo Benchmark e escolher.
Prático
Conhece a gama#
Estes são os valores oficiais de deteção COCO da documentação YOLO26, todos a 640 píxeis:
| Modelo | Parâmetros (M) | FLOPs (B) | mAP50-95 | CPU ONNX (ms) | T4 TensorRT10 (ms) |
|---|---|---|---|---|---|
yolo26n | 2.4 | 5.5 | 40.9 | 38.9 | 1.7 |
yolo26s | 9.5 | 20.9 | 48.6 | 87.2 | 2.5 |
yolo26m | 20.4 | 68.4 | 53.1 | 220.0 | 4.7 |
yolo26l | 24.8 | 86.8 | 55.0 | 286.2 | 6.2 |
yolo26x | 55.7 | 194.4 | 57.5 | 525.8 | 11.8 |
Há um tamanho para cada tarefa — basta trocar o sufixo, como em yolo26s-seg.pt, yolo26s-sem.pt, yolo26s-depth.pt, yolo26s-cls.pt, yolo26s-pose.pt ou yolo26s-obb.pt. A migrar um projeto antigo? A comparação entre YOLO11 e YOLO26 mostra o que muda.
Interpreta a tabela como «quanto custa passar ao tamanho seguinte?»:
| Passagem | Ganho de mAP | FLOPs adicionais | Multiplicador de latência na CPU |
|---|---|---|---|
| n → s | +7.7 | ×3.8 | ×2.2 |
| s → m | +4.5 | ×3.3 | ×2.5 |
| m → l | +1.9 | ×1.3 | ×1.3 |
| l → x | +2.5 | ×2.2 | ×1.8 |
A primeira passagem oferece a melhor relação custo-benefício; depois de m, cada ponto de precisão COCO fica mais caro. Além disso, COCO, com 80 classes variadas, é mais difícil do que a maioria dos projetos reais: numa tarefa específica, como detetar um produto numa correia transportadora, n e s costumam ficar a um ponto de m.
Começa pelo orçamento#
O teu orçamento de latência de inferência é 1000 ms ÷ FPS pretendidos, e o modelo tem de o partilhar com a descodificação, o desenho e a tua própria lógica. Pontos de partida habituais:
| Meta | Começa com |
|---|---|
| Telemóvel, Raspberry Pi, navegador ou outro dispositivo pequeno de IA de edge | n |
| CPU de portátil ou computador de secretária, 10–30 FPS | n; depois, s se houver margem |
| Uma única GPU, vídeo em tempo real | s ou m |
| Processamento em lote offline, priorizando a precisão | l ou x |
Exemplo prático: medir dois tamanhos#
O modo de benchmark exporta o modelo, valida-o em coco8 e mede o tempo de inferência na tua máquina. format=onnx limita a execução a um formato para terminar em segundos; deixa-o de fora para comparar todos os formatos de exportação.
yolo benchmark model=yolo26n.pt imgsz=640 format=onnx
yolo benchmark model=yolo26s.pt imgsz=640 format=onnxResultados reais na CPU de um portátil Apple M5 Pro:
| Format Status❔ Size (MB) metrics/mAP50-95(B) Inference time (ms/im) FPS |
| 1 ONNX ✅ 9.5 0.6693 13.87 72.08 | <- yolo26n
| 1 ONNX ✅ 36.5 0.6654 30.87 32.39 | <- yolo26sComparando com um orçamento de 30 FPS (33 ms):
yolo26n, 13.87 ms: cabe no orçamento, com 19 ms de sobra para descodificação e desenho.yolo26s, 30.87 ms: cabe tecnicamente, sem margem para mais nada. O mesmo benchmark demorou 60 ms enquanto outros processos estavam a ser executados na máquina.Size (MB): o tamanho do ficheiro ONNX, importante para as transferências da aplicação e a memória móvel.metrics/mAP50-95(B): ignora-o aqui.coco8tem quatro imagens de validação: suficientes para confirmar que a exportação funciona, mas muito poucas para classificar a precisão.
Decisão: treina primeiro yolo26n e mantém yolo26s com um imgsz inferior como alternativa.
Evita estes erros#
Sintoma: um modelo que rodava a 70 FPS no teu portátil roda a 8 FPS no dispositivo de borda. Solução: faz benchmark no dispositivo que vai executar o modelo, sob uma carga realista — com outros processos, descodificação da câmara e o formato de runtime real.
Sintoma: "s foi mais rápido que n" nas tuas notas. Causa: uma execução usou imgsz=480 ou um formato diferente. Solução: compara os tamanhos com o mesmo imgsz, formato e batch, e altera uma variável de cada vez.
Não treines x a pensar que vais reduzi-lo mais tarde para n com poda de modelos ou quantização: uma arquitetura mais pequena exige novo treino. Escolhe primeiro o tamanho; considera a quantização um aumento de velocidade adicional ao tamanho adequado, não um substituto.
A análise mais aprofundada da latência — processamento em lotes, quantização e escolha do ambiente de execução — faz parte de Otimização de custos e latência no curso de Produção, e o guia de métricas de desempenho explica cada valor de precisão.
Mostrar solução
Budget: 30 FPS on a laptop CPU -> 33 ms per frame, shared with decode and drawing
Measured: ONNX at 640 -> yolo26n 13.9 ms (19 ms headroom), yolo26s 30.9 ms (none; 60 ms under load)
Decision: train yolo26n first. If accuracy on our val set falls short,
try yolo26s at imgsz=480 and re-benchmark before committing.