O que precisa mudar no YOLO26 quando um detector deixa o notebook e passa a integrar uma câmera, um robô ou um sistema que deve responder em tempo real?
O YOLO26 foi organizado em torno dessa transição. A nova geração da Ultralytics combina uma saída end-to-end sem supressão de caixas duplicadas, uma cabeça de regressão mais simples e uma receita de treinamento que procura preservar a qualidade dessas mudanças. O ponto central não é uma peça isolada, mas a coordenação entre arquitetura, atribuição de rótulos e otimização.
Neste artigo, você entenderá como funcionam a cabeça dual, a remoção da Distribution Focal Loss (DFL), o STAL, a Progressive Loss e o MuSGD. Ao final, vamos interpretar uma inferência real com o YOLO26n e separar o que a demonstração comprova daquilo que ainda precisa ser medido em cada aplicação.
Código do Artigo
Acesse o código-fonte deste artigo gratuitamente.
Informe seu email para acessar o código:
✓ Seu código está pronto!
Abrir no Google Colab →O que é o YOLO26?
O YOLO26 é a geração de modelos de visão computacional apresentada pela Ultralytics em 2026. Na tarefa de detecção, a família mantém a ideia que tornou o YOLO relevante: processar a imagem como um detector de uma etapa, produzindo classes e posições sem uma segunda fase externa dedicada a examinar propostas de região.
Uma etapa, porém, não significa uma única operação. A imagem ainda atravessa diversas camadas, representações e escalas. A distinção é arquitetural: detectores de dois estágios, como o Faster R-CNN, primeiro geram regiões candidatas e depois classificam e refinam essas regiões. Um detector YOLO produz as previsões a partir de um fluxo único de extração e fusão de características.
Também convém interpretar o número com cautela. O nome YOLO designa uma escola de arquiteturas, não uma sequência linear criada pela mesma equipe. A linhagem original começou com o artigo You Only Look Once e chegou ao YOLOv3; depois, universidades, comunidades e empresas desenvolveram ramificações próprias. O YOLO26 pertence especificamente à linha da Ultralytics, assim como o YOLO11. Ele não é a vigésima sexta revisão de um mesmo projeto.
Essa distinção ajuda a avaliar a contribuição correta: o white paper oficial do YOLO26 apresenta uma formulação integrada para tornar a saída do detector mais direta, mas algumas ideias possuem antecedentes em outras linhagens. A inovação está tanto nos componentes quanto na forma como foram reunidos e validados.
Por que reorganizar o detector?
Um bom resultado no COCO não encerra o problema de implantação. Entre os tensores produzidos pela rede e a decisão tomada pela aplicação, podem existir pós-processamento, operadores difíceis de exportar, limites de memória e diferenças relevantes entre CPU, GPU e aceleradores especializados.
O YOLO26 reorganiza quatro pontos desse percurso:
- Caixas duplicadas: detectores densos podem produzir várias previsões para o mesmo objeto, exigindo um filtro posterior.
- Custo da cabeça de regressão: a DFL representa cada borda como uma distribuição discreta, o que amplia o número de saídas.
- Objetos pequenos sem candidatos: uma instância diminuta pode não conter nenhum ponto elegível da grade durante a atribuição de rótulos.
- Desalinhamento entre treino e inferência: o ramo que recebe supervisão abundante não é necessariamente aquele usado na saída end-to-end.
Esses problemas são interdependentes. Simplificar a cabeça pode reduzir o custo, mas também retirar uma representação útil. Exigir uma única correspondência por objeto facilita a inferência, mas torna o aprendizado inicial mais difícil. A proposta do YOLO26 é compensar cada simplificação com mudanças específicas no treinamento.
Como a cabeça dual permite inferência sem NMS?
Em um detector denso convencional, várias caixas próximas podem receber confiança elevada para o mesmo objeto. A supressão de não máximos, ou NMS, ordena essas previsões e elimina as redundantes conforme a sobreposição entre elas. O procedimento é eficaz, mas acrescenta pós-processamento e limiares ao pipeline.
O YOLO26 treina duas cabeças de detecção sobre as mesmas características:
- A cabeça one-to-many associa vários candidatos positivos a cada objeto. A supervisão é densa e fornece um sinal de aprendizado abundante.
- A cabeça one-to-one restringe a associação final a uma única previsão por objeto. Esse é o caminho padrão da inferência end-to-end.

No treinamento, as duas cabeças compartilham as representações da imagem. Na inferência end-to-end, a saída one-to-one segue para a aplicação sem NMS. Fonte: Sigmoidal, elaborado a partir do white paper da Ultralytics.
A analogia de uma seleção editorial é útil. A cabeça one-to-many entrega várias fotografias semelhantes para que um editor escolha uma delas; a cabeça one-to-one aprende a entregar apenas a fotografia final. A primeira facilita o aprendizado. A segunda reduz o trabalho depois que o modelo já foi treinado.
No modo padrão, end2end=True, o YOLO26 usa a cabeça one-to-one e limita a saída a até 300 detecções por imagem. Isso não significa que o NMS tenha sido abolido em todas as configurações. A documentação oficial preserva o caminho one-to-many, selecionável com end2end=False no mesmo checkpoint durante predição, validação ou exportação, para cenários em que a infraestrutura executa NMS de forma eficiente e a prioridade é extrair um pequeno ganho de AP.
Portanto, a escolha não é entre um caminho “correto” e outro “errado”. É um compromisso explícito entre uma saída mais simples e a melhor acurácia obtida pela configuração convencional.
Por que o YOLO26 removeu a DFL?
Uma caixa delimitadora pode ser descrita por quatro distâncias a partir de um ponto de referência: esquerda, topo, direita e base. Em gerações anteriores da Ultralytics, cada distância era modelada como uma distribuição sobre intervalos discretos. A Distribution Focal Loss transformava essa distribuição em uma estimativa contínua da borda.
Essa formulação oferece granularidade, mas impõe dois custos. Primeiro, a cabeça precisa prever vários valores para cada lado da caixa, em vez de apenas uma distância. Segundo, a régua discreta possui um suporte finito. Em resoluções maiores, um objeto extenso pode exigir uma distância além do alcance representado naquela escala.

O YOLO26 substitui a distribuição discreta por quatro distâncias regressadas diretamente. A mudança reduz a dimensionalidade da cabeça e remove o suporte fixo da DFL. Fonte: Sigmoidal, elaborado a partir do white paper da Ultralytics.
O YOLO26 define reg_max=1, remove a DFL e utiliza regressão direta com perda L1. A cabeça fica menor, especialmente em relação ao restante dos modelos compactos, e deixa de depender da mesma representação discreta.
Seria incorreto concluir que remover DFL sempre aumenta a acurácia. Na ablação incremental do white paper, retirar apenas esse componente do baseline YOLO11s reduz a AP de 47,0 para 46,4. A qualidade é recuperada com a nova perda, o STAL e os refinamentos da arquitetura e da receita de treinamento. Em outras palavras, a simplificação funciona como parte de um sistema, não como uma substituição isolada e gratuita.
Como o treinamento compensa uma saída mais restrita?
Três mecanismos completam a reorganização: o STAL protege objetos pequenos durante a seleção de candidatos, a Progressive Loss transfere gradualmente a ênfase entre as cabeças e o MuSGD adapta a atualização ao tipo de parâmetro.
STAL: objetos pequenos continuam participando
Imagine os pontos centrais de uma grade sobre a imagem. Para objetos grandes, vários pontos caem dentro da caixa verdadeira e podem ser selecionados como candidatos. Uma caixa muito pequena, porém, pode ficar entre esses pontos e não conter nenhum deles. Nesse caso, a instância existe na anotação, mas deixa de oferecer sinal naquela etapa do treinamento.
O Small-Target-Aware Label Assignment cria uma região auxiliar mínima para a seleção. Essa região aumenta a chance de encontrar candidatos, mas não altera a caixa verdadeira usada na atribuição final e na regressão. O modelo não aprende que o objeto é maior; ele apenas deixa de ignorá-lo antes que o aprendizado comece.
Na ablação apresentada pelos autores, o STAL com tamanho de referência 16 elevou a AP de objetos pequenos de 29,0 para 29,6 e a AP geral de 46,6 para 46,8. O ganho é específico e mensurável, não uma solução universal para qualquer escala. Valores de referência diferentes não repetiram o mesmo resultado.
Progressive Loss: uma passagem de bastão entre as cabeças
A cabeça one-to-many aprende com maior facilidade no começo porque recebe muitos positivos. A one-to-one enfrenta uma tarefa mais restrita, mas é justamente ela que produzirá a saída end-to-end. Manter a mesma importância para os dois ramos durante todas as épocas criaria um desalinhamento entre aquilo que recebe mais supervisão e aquilo que será implantado.
A Progressive Loss aplica uma política curricular. No início, favorece a supervisão densa; ao longo do treinamento, transfere linearmente o peso para a cabeça one-to-one. O ramo final não fica desligado: ele participa desde a primeira época e assume progressivamente o papel principal. Assim, o treinamento começa com sinais abundantes e termina alinhado ao regime de inferência.
MuSGD: regras distintas para estruturas distintas
Pesos de convoluções são matrizes ou tensores multidimensionais; vieses e escalas de normalização são parâmetros unidimensionais. O MuSGD separa esses grupos: combina de forma ponderada as atualizações Muon e SGD nos pesos estruturais e preserva o SGD convencional para os parâmetros simples.
No experimento controlado de detecção do paper, o MuSGD alcançou 47,4 mAP em 500 épocas, enquanto o SGD de referência chegou a 47,0 em 600. É uma redução de 16,7% no número de épocas sob aquela receita, não uma promessa de convergência idêntica em qualquer conjunto de dados.
O que os benchmarks realmente mostram?
A família de detecção possui cinco escalas, do YOLO26n ao YOLO26x. A tabela abaixo reúne os números publicados para imagens de 640 pixels no COCO val2017:
| Modelo | mAP 50–95 | mAP 50–95 end-to-end | CPU ONNX | T4 TensorRT | Parâmetros |
|---|---|---|---|---|---|
| YOLO26n | 40,9 | 40,1 | 38,9 ms | 1,7 ms | 2,4 M |
| YOLO26s | 48,6 | 47,8 | 87,2 ms | 2,5 ms | 9,5 M |
| YOLO26m | 53,1 | 52,5 | 220,0 ms | 4,7 ms | 20,4 M |
| YOLO26l | 55,0 | 54,4 | 286,2 ms | 6,2 ms | 24,8 M |
| YOLO26x | 57,5 | 56,9 | 525,8 ms | 11,8 ms | 55,7 M |
Fonte: documentação oficial do Ultralytics YOLO26. Latência de CPU medida com ONNX e latência de GPU com TensorRT em instância Amazon EC2 P4d; lote 1. Parâmetros correspondem ao modelo fundido após model.fuse(), que remove a cabeça auxiliar one-to-many; o checkpoint completo de treinamento pode apresentar contagem maior.
O benchmark e as ablações foram publicados pela própria organização que desenvolve o modelo. Eles oferecem evidência técnica e condições de reprodução, mas não substituem uma avaliação independente nem um teste no domínio da aplicação.
Três leituras são importantes. Primeiro, o caminho end-to-end permanece entre 0,6 e 0,8 ponto de AP abaixo do convencional nessa tabela. Segundo, a diferença de latência entre modelos cresce com a escala; comparar apenas “YOLO26” sem indicar a variante é pouco informativo. Terceiro, os números não são transferidos automaticamente para outro processador, backend, resolução ou tamanho de lote.
A Ultralytics também reporta o YOLO26n como até 43% mais rápido que o YOLO11n em CPU ONNX, sob o hardware e o protocolo descritos na documentação. O termo “até” é decisivo. Para uma implantação real, meça o pipeline completo, incluindo decodificação da imagem, pré-processamento, inferência, transferência de memória e consumo da saída.
Como testar o YOLO26 em Python?
O notebook complementar instala uma combinação reproduzível de dependências, obtém a imagem oficial bus.jpg da Ultralytics e carrega o checkpoint compacto yolo26n.pt. O núcleo da inferência cabe em quatro linhas:
from ultralytics import YOLO
modelo = YOLO("yolo26n.pt")
resultado = modelo("bus.jpg")[0]
resultado.save(filename="resultado_yolo26.jpg")
O construtor baixa o peso oficial na primeira execução. Em seguida, o modelo processa a imagem e devolve um objeto Results, que reúne caixas, classes e confianças. O método save renderiza essas informações sobre a imagem original.

Execução validada com Ultralytics 8.4.118, usando end2end=True: cinco detecções, sendo um ônibus e quatro pessoas. Imagem original: Ultralytics; inferência e renderização: Sigmoidal.
A execução sequencial do notebook confirmou que o modelo opera com end2end=True por padrão. Na imagem, ele retornou cinco detecções: um ônibus e quatro pessoas. A tabela produzida no próprio notebook permite examinar cada classe, confiança e coordenada, em vez de depender apenas da visualização.
Esse resultado comprova que a integração funciona e que o caminho oficial reproduz uma saída coerente. Ele não mede generalização. Uma fotografia canônica não revela o comportamento em baixa iluminação, oclusões severas, câmeras aéreas, defeitos industriais ou classes ausentes do COCO.
Como avaliar o YOLO26 no seu domínio?
O teste responsável começa com dados representativos da aplicação. Separe imagens anotadas que cubram iluminação, distância, ângulo, densidade de objetos e falhas esperadas. Depois, avalie precisão, recall e mAP por classe, com atenção especial aos casos cujo erro possui maior custo operacional.
Em paralelo, registre latência e memória no hardware de destino. Uma GPU de datacenter pode inverter a comparação observada em uma CPU embarcada; um backend com NMS eficiente pode tornar a cabeça convencional atraente; uma exportação específica pode introduzir operadores ou conversões adicionais.
Também é necessário considerar a licença. A Ultralytics oferece o software sob AGPL-3.0 e uma licença Enterprise. Antes de incorporar o modelo a um produto fechado ou serviço comercial, verifique qual regime corresponde à arquitetura de distribuição do sistema.
Esse cuidado vale para qualquer geração do YOLO. O artigo sobre detecção de objetos com YOLOv9 mostra a mesma distinção fundamental: uma demonstração confirma o percurso técnico; uma avaliação com dados próprios determina se o modelo serve à aplicação.
Em quais tarefas a família YOLO26 está disponível?
O ecossistema atual inclui modelos para detecção, segmentação de instâncias, segmentação semântica, estimativa de profundidade, classificação, pose e caixas orientadas. Há ainda a extensão YOLOE, voltada à detecção com vocabulário aberto. As variantes compartilham a experiência de treinamento e implantação da biblioteca, mas não possuem cabeças e funções de perda idênticas.
Neste artigo, todos os mecanismos e números de inferência se referem à detecção convencional. Não se deve transferir automaticamente uma conclusão da tabela de detecção para segmentação, pose ou profundidade.
O que já foi anunciado sobre o YOLO27?
A roadmap oficial da Ultralytics prevê a apresentação do YOLO27 no Ultralytics YOLO Vision, em setembro de 2026. A direção divulgada é ampliar a família para visão e linguagem, com um front-end YOLO alimentando uma camada de modelo de linguagem no chamado YOLO-VLM.
Até o momento desta publicação, isso é um anúncio de roadmap, não um modelo lançado. Ainda não há pesos e resultados oficiais suficientes para comparar o YOLO27 com o YOLO26 de maneira reproduzível. A formulação responsável, portanto, é tratar visão-linguagem como a direção anunciada e reservar qualquer conclusão de desempenho para o lançamento.
Takeaways
- O YOLO26 prioriza uma saída de produção mais direta: a cabeça one-to-one permite inferência end-to-end sem NMS por padrão.
- A cabeça convencional permanece disponível:
end2end=Falseusa o ramo one-to-many com NMS quando a maior AP é prioritária. - A remoção da DFL simplifica a regressão: quatro distâncias diretas substituem distribuições discretas, mas a mudança precisa do restante da receita para recuperar qualidade.
- STAL evita candidatos vazios para alvos pequenos: a região de seleção aumenta, enquanto a caixa verdadeira permanece inalterada.
- Progressive Loss alinha treino e implantação: a supervisão migra gradualmente do ramo denso para a cabeça usada na inferência.
- MuSGD adapta a atualização à estrutura dos parâmetros: os resultados publicados são promissores, mas continuam condicionados à receita avaliada.
- A demonstração não substitui validação: o dado, o backend e o hardware da aplicação continuam sendo o teste decisivo.











