Entendendo a Detecção End-to-End no Ultralytics YOLO26#

Se estás a atualizar para o YOLO26 a partir de um modelo anterior como o YOLOv8 ou o YOLO11, uma das maiores mudanças que vais notar é a remoção da Non-Maximum Suppression (NMS). Os modelos YOLO tradicionais produzem milhares de previsões sobrepostas que necessitam de um passo de pós-processamento NMS separado para filtrar até às deteções finais. Isto adiciona latência, complica os grafos de exportação e pode comportar-se de forma inconsistente em diferentes plataformas de hardware.

O YOLO26 adota uma abordagem diferente. Produz as deteções finais diretamente a partir do modelo — sem ser necessária filtragem externa. Isto é conhecido como detetção de objetos end-to-end, e está ativado por predefinição em todos os modelos YOLO26. O resultado é um pipeline de implementação mais simples, menor latência e inferência até 43% mais rápida em CPUs.

Este guia te orienta sobre o que mudou, se você precisa atualizar seu código, quais formatos de exportação suportam inferência end-to-end e como migrar suavemente de modelos YOLO antigos.

Para uma análise mais profunda da motivação por trás desta mudança arquitetónica, consulta a publicação no blog da Ultralytics sobre o motivo pelo qual o YOLO26 remove o NMS.

Como a Detecção End-to-End Funciona#

O YOLO26 utiliza uma arquitetura de cabeça dupla durante o treino. Ambas as cabeças partilham a mesma espinha dorsal e o mesmo pescoço, mas produzem saídas de formas diferentes:

As formas acima são para deteção. Outras tarefas estendem a saída de um para um com dados adicionais por deteção:

Durante o treino, ambas as cabeças funcionam em simultâneo — a cabeça de um para muitos fornece um sinal de aprendizagem mais rico, enquanto a cabeça de um para um aprende a produzir previsões limpas e sem sobreposições. Durante a inferência e a exportação, apenas a cabeça de um para um está ativa por predefinição, produzindo até 300 deteções por imagem no formato [x1, y1, x2, y2, confidence, class_id].

Quando chamas model.fuse(), este agrupa as camadas Conv + BatchNorm para uma inferência mais rápida e, nos modelos end-to-end, também remove a cabeça de um para muitos — reduzindo o tamanho do modelo e os FLOPs. Para mais detalhes sobre a arquitetura de cabeça dupla, consulta a página do modelo YOLO26.

Preciso Alterar Meu Código?#

Usando a API Python ou CLI da Ultralytics#

Não são necessárias alterações. Se utilizas a API Python da Ultralytics ou a CLI padrão, tudo funciona automaticamente — a previsão, a validação e a exportação lidam com modelos end-to-end de raiz.

from ultralytics import YOLO

# Load a YOLO26 model
model = YOLO("yolo26n.pt")

# Predict — no NMS step, no code changes
results = model.predict("image.jpg")

Usando Código de Inferência Personalizado#

Sim, o formato de saída é diferente. Se escreveste lógica de pós-processamento personalizada para o YOLOv8 ou o YOLO11 (por exemplo, ao executar inferência com ONNX Runtime ou TensorRT), precisas de a atualizar para lidar com a nova forma de saída:

Para tarefas de segmentação, pose e OBB, o YOLO26 adiciona dados específicos da tarefa a cada deteção — consulta a tabela de formas de saída.

Onde N é o tamanho do lote e nc é o número de classes (por exemplo, 80 para o COCO).

Com os modelos end-to-end, o pós-processamento torna-se muito mais simples — por exemplo, ao utilizar o ONNX Runtime:

import onnxruntime as ort

# Load and run the exported end-to-end model
session = ort.InferenceSession("yolo26n.onnx")
output = session.run(None, {session.get_inputs()[0].name: input_tensor})

# End-to-end output: (batch, 300, 6) → [x1, y1, x2, y2, confidence, class_id]
detections = output[0][0]  # first image in batch
detections = detections[detections[:, 4] > conf_threshold]  # confidence filter — that's it!

Mudando para o Cabeçote Um-para-Muitos#

Se precisares do formato de saída YOLO tradicional (por exemplo, para reutilizar código de pós-processamento baseado em NMS existente), podes mudar para a cabeça de um para muitos quando esta estiver disponível, definindo end2end=False:

from ultralytics import YOLO

model = YOLO("yolo26n.pt")

# Prediction with NMS (traditional behavior)
results = model.predict("image.jpg", end2end=False)

# Validation with NMS
metrics = model.val(data="coco.yaml", end2end=False)

# Export without end-to-end
model.export(format="onnx", end2end=False)

Compatibilidade de Formato de Exportação#

A maioria dos formatos de exportação suporta inferência end-to-end de raiz, incluindo ONNX, TensorRT, CoreML, OpenVINO, LiteRT e MNN.

Os seguintes formatos não suportam end-to-end e recorrem automaticamente à cabeça de um para muitos: NCNN, RKNN, PaddlePaddle, ExecuTorch, IMX, Edge TPU e Qualcomm QNN.

Para o Hailo HEF, o passo de compilação ocorre fora de model.export(format=...) após uma exportação ONNX. Utiliza os registos DFC do Hailo, o script de modelo .alls e o JSON de NMS correspondentes ao teu modelo de deteção exato; se um grafo YOLO26 end-to-end não for suportado pela tua cadeia de ferramentas Hailo, exporta o modelo ONNX com end2end=False e compila a cabeça de deteção tradicional.

Compensações de Precisão e Velocidade#

A deteção end-to-end oferece vantagens significativas de implementação com um impacto mínimo na precisão:

Para a maioria das aplicações do mundo real, a diferença de ~0.5 mAP é negligenciável, especialmente quando se consideram os ganhos de velocidade e simplicidade. Se a precisão máxima for a tua principal prioridade, podes sempre recorrer à cabeça de um para muitos utilizando end2end=False.

Consulta as métricas de desempenho do YOLO26 para benchmarks detalhados em todos os tamanhos de modelo (n, s, m, l, x).

Migrando do YOLOv8 ou YOLO11#

Se você está atualizando um projeto existente para o YOLO26, aqui está uma lista de verificação rápida para garantir uma transição suave:

• Utilizadores da API / CLI da Ultralytics: Não são necessárias alterações — basta atualizar o nome do modelo para yolo26n.pt (ou yolo26n-seg.pt, yolo26n-pose.pt, yolo26n-obb.pt)
• Código de pós-processamento personalizado: Atualiza para lidar com as novas formas de saída — (N, 300, 6) para deteção, além de dados específicos da tarefa para segmentação, pose e OBB. Tem também em atenção a alteração do formato da caixa de xywh para xyxy
• Pipelines de exportação: Verifica a secção de compatibilidade de formatos para o teu formato de destino
• TensorRT + INT8: No JetPack 6, o TensorRT 10.3.0 desativa automaticamente o end-to-end com quantize=8 — utiliza uma versão diferente do TensorRT para manter o end-to-end
• Exportações FP16: Se precisares de todas as saídas em FP16, exporta com end2end=False — consulta por que razão o output0 permanece em FP32
• iOS / CoreML: O end-to-end é totalmente suportado. Se precisares de suporte para a Pré-visualização do Xcode, utiliza end2end=False com nms=True
• Dispositivos de borda (NCNN, RKNN): Esses formatos retornam automaticamente para um-para-muitos, então inclua NMS em seu pipeline no dispositivo

Conclusão#

A deteção end-to-end é a predefinição no YOLO26 e não requer alterações de código se utilizares a API Python da Ultralytics ou a CLI. Apenas os pipelines de pós-processamento personalizados precisam de ser atualizados para ler a nova saída (N, 300, 6) e remover o passo NMS — exceto para os formatos de exportação que recorrem à saída de um para muitos (como NCNN e RKNN), que ainda requerem NMS no dispositivo. Para benchmarks detalhados de velocidade e precisão em todos os tamanhos de modelo, consulta a página do modelo YOLO26 e, para o conjunto completo de opções e formatos de exportação, consulta a documentação do modo Export.

FAQ#