Arquitetura YOLO explicada: do YOLOv3 ao YOLO26#

Todos os modelos Ultralytics YOLO são compostos por três estágios: um backbone que extrai características, um neck que as combina entre escalas e um head que prevê caixas e classes. Este guia documenta os módulos que compõem cada estágio e como eles mudaram do YOLOv3 ao YOLO26, relacionando cada componente à sua definição nos arquivos de configuração em ultralytics/cfg/models/ e às classes de módulo em ultralytics/nn/modules/.

Cada modelo é definido declarativamente em um arquivo YAML como uma lista ordenada de camadas, em que cada camada segue o formato [from, repeats, module, args]: de quais camadas recebe entradas, quantas vezes o módulo se repete, a classe da camada (Conv, C3k2, SPPF, Detect, …) e seus argumentos de inicialização. O Guia de configuração YAML de modelos documenta esse formato — incluindo como repeats e args são escalados de acordo com os múltiplos de profundidade e largura da variante — além de descrever por completo o sistema de resolução de módulos. Este guia se concentra nos próprios módulos e em como eles mudaram de uma versão para outra.

Os três estágios#

Todos os modelos Ultralytics YOLO processam a imagem por três estágios sequenciais, cada um com uma função distinta:

A unidade fundamental é o bloco Conv (definido em conv.py): uma convolução 2D, normalização em lote e uma ativação SiLU, aplicadas em sequência. Todos os módulos maiores abaixo são compostos por blocos Conv.

Diagramas da arquitetura#

Cada versão mantém a mesma estrutura de backbone → neck → head e altera etapas específicas. As abas abaixo mostram a estrutura de cada versão: as etapas de backbone e neck seguem as configurações em ultralytics/cfg/models/, enquanto as heads do YOLOv3 e do YOLOv5 são representadas na forma original, baseada em âncoras, em vez da head da variante u sem âncoras que as configurações dos pacotes realmente incluem. Percorrer as abas mostra o que cada geração acrescentou. Em resumo, a progressão é a seguinte: o YOLOv3 é um detector baseado em âncoras que usa apenas FPN; o YOLOv5 acrescenta o caminho PAN de baixo para cima e SPPF; o YOLOv8 muda para o bloco C2f, com uma head sem âncoras e DFL; o YOLO11 insere a atenção C2PSA e o bloco C3k2; e o YOLO26 acrescenta um residual SPPF, remove o DFL e adiciona uma head opcional sem NMS.

Os diagramas do YOLOv3 e do YOLOv5 mostram o head original baseado em âncoras. O pacote ultralytics inclui as configurações sem âncoras YOLOv3u e YOLOv5u — com os mesmos backbones Darknet-53 e C3, mas usando o head Detect do YOLOv8 — descritas em Head de detecção.

Blocos do backbone: Bottleneck → C3 → C2f → C3k2#

O backbone empilha um bloco CSP (Cross-Stage Partial) repetitivo entre camadas de redução da resolução Conv com stride 2. Esse bloco repetitivo foi o que mais mudou entre as versões. Todos os blocos abaixo estão em block.py; c1/c2 são os canais de entrada/saída, e c = 0.5 * c2 é a largura oculta.

Bottleneck (YOLOv3)#

A unidade básica é Bottleneck: duas camadas Conv (kernels padrão (3, 3)) com uma soma residual opcional quando shortcut=True e c1 == c2. O backbone Darknet-53 do YOLOv3 empilha essas unidades diretamente, sem divisão CSP, e detecta em três escalas (strides 8, 16 e 32).

C3 (YOLOv5)#

O C3 do YOLOv5 divide a entrada entre duas convoluções 1x1: cv1 alimenta n blocos Bottleneck sequenciais (kernels (1, 1) e depois (3, 3)), enquanto cv2 os contorna. Os dois caminhos são concatenados e combinados por um terceiro 1x1 Conv:

def forward(self, x):
    # C3: caminho bottleneck m(cv1(x)) concatenado com o caminho alternativo cv2(x), depois combinado por cv3
    return self.cv3(torch.cat((self.m(self.cv1(x)), self.cv2(x)), 1))

Somente a saída do bottleneck final chega à convolução de combinação; portanto, cv3 recebe 2 mapas de características.

C2f (YOLOv8)#

O C2f do YOLOv8 ("Bottleneck CSP com 2 convoluções, mais rápido") altera quais características chegam à convolução de combinação:

1. cv1 = Conv(c1, 2 * c, 1) e, em seguida, chunk(2) divide a saída em dois tensores com c canais.
2. Os blocos n Bottleneck(c, c) (kernels (3, 3), (3, 3)) são executados sequencialmente, cada um recebendo a saída do bloco anterior.
3. Todos os tensores intermediários n + 2 são concatenados e combinados por cv2 = Conv((2 + n) * c, c2, 1).

Enquanto C3 passa 2 mapas de características para sua convolução de combinação, C2f passa n + 2 — cada saída intermediária do bottleneck é reutilizada.

C3k2 (YOLO11 e YOLO26)#

YOLO11 e YOLO26 usam C3k2, uma subclasse de C2f que substitui a unidade repetitiva. Dependendo das flags de inicialização, cada um dos blocos n se torna:

• um Bottleneck simples (padrão, c3k=False),
• um bloco C3k (c3k=True) — uma variante C3 com tamanho de kernel configurável, ou
• um par Bottleneck + PSABlock (attn=True).

O segundo argumento YAML define c3k, a menos que a escala seja m, l ou x, casos em que o valor é forçado para True — é assim que um único yolo11.yaml atende às cinco variantes. Portanto, [-1, 2, C3k2, [512, False]] constrói elementos internos Bottleneck em n e s, mas elementos internos C3k em m, l e x; 512 é a contagem de canais antes do escalonamento, que o múltiplo de largura da variante transforma em 128 em n e 768 em x. Nos módulos CSP, o campo repeats — aqui igual a 2, antes de ser escalonado pelo múltiplo de profundidade da variante — se torna a contagem de repetições internas do bloco, em vez de empilhar módulos separados.

Pooling espacial: SPP → SPPF#

No final do backbone, um bloco de pooling de pirâmide espacial amplia o campo receptivo. O YOLOv5 substituiu o SPP original, com vários kernels, por SPPF (Spatial Pyramid Pooling - Fast): um único MaxPool2d(kernel_size=5, stride=1, padding=2) aplicado n = 3 vezes em sequência, com a entrada e todas as três saídas do pooling concatenadas e combinadas por um 1x1 Conv. Isso é matematicamente equivalente a SPP(k=(5, 9, 13)), mas tem menor custo, pois os poolings encadeados 5x5 cobrem os campos receptivos dos kernels maiores.

O YOLO26 passa uma flag de atalho (SPPF, [1024, 5, 3, True]); como c1 == c2 == 1024 está na camada mais profunda, SPPF adiciona uma conexão residual (return y + x).

Atenção espacial: C2PSA (YOLO11+)#

O YOLO11 adicionou C2PSA depois de SPPF. É um bloco CSP cujo ramo ativo é uma pilha de módulos n PSABlock (atenção sensível à posição): cv1 = Conv(c1, 2 * c, 1) divide as características, metade passa pela pilha PSABlock e cv2 = Conv(2 * c, c1, 1) combina a concatenação. Cada PSABlock aplica atenção multi-head seguida de uma rede feed-forward de duas camadas (Conv(c, 2 * c, 1) → Conv(2 * c, c, 1)), ambas com uma conexão residual. O YOLO26 mantém o mesmo backbone C3k2 + C2PSA.

Neck: FPN + PAN#

O neck combina os mapas de características P3/P4/P5 do backbone com uma Feature Pyramid Network (FPN) de cima para baixo, seguida por uma Path Aggregation Network (PAN) de baixo para cima. Na seção head do YAML, a FPN é nn.Upsample + Concat (leva informações semânticas a resoluções mais altas), e a PAN é Conv + Concat com stride 2 (leva informações de localização de volta para cima):

# YOLO11 head (FPN top-down, then PAN bottom-up)
- [-1, 1, nn.Upsample, [None, 2, "nearest"]]
- [[-1, 6], 1, Concat, [1]] # cat backbone P4
- [-1, 2, C3k2, [512, False]] # 13
# ... second upsample + concat to P3 ...
- [-1, 1, Conv, [256, 3, 2]]
- [[-1, 13], 1, Concat, [1]] # cat head P4 (PAN)
- [-1, 2, C3k2, [512, False]] # 19

O neck reutiliza o bloco de backbone da sua geração — C3 no YOLOv5, C2f no YOLOv8, C3k2 no YOLO11 e no YOLO26 —, de modo que cada ponto de fusão executa o mesmo módulo usado pelo backbone. As três saídas combinadas alimentam o head. O YOLOv3 é a exceção: seu neck usa apenas FPN de cima para baixo (o head YAML não tem redução da resolução com stride 2), sem o caminho PAN de baixo para cima introduzido pelo YOLOv5.

Head de detecção: baseado em âncoras → sem âncoras → sem NMS#

O head transforma os três mapas de características combinados em previsões para a tarefa de detecção. Seu design mudou entre as versões: de baseado em âncoras para sem âncoras e, por fim, sem NMS.

Detect sem âncoras e desacoplado#

O YOLOv3 e o YOLOv5 originais usavam um head baseado em âncoras e acoplado: caixas de âncora predefinidas e um ramo compartilhado para previsões de caixas e classes. Os repositórios independentes ultralytics/yolov3 e ultralytics/yolov5 mantêm esse design baseado em âncoras. Em vez disso, o pacote principal ultralytics inclui as variantes sem âncoras YOLOv3u e YOLOv5u — com os mesmos backbones Darknet-53 e C3, mas usando o head Detect sem âncoras do YOLOv8 — e as configurações yolov3.yaml e yolov5.yaml documentadas aqui correspondem a essas variantes u, não ao design histórico.

O head Detect (head.py) não usa âncoras e é desacoplado: em cada nível da pirâmide, executa dois ramos paralelos e prevê diretamente nos pontos da grade, em vez de usar caixas de âncora.

• Ramo de caixas (cv2): Conv(x, c2, 3) → Conv(c2, c2, 3) → Conv2d(c2, 4 * reg_max, 1).
• Ramo de classes (cv3): no YOLO11 e no YOLO26, dois blocos separáveis em profundidade (DWConv + 1x1 Conv) → Conv2d(c3, nc, 1); o YOLOv8 usa a variante legada, com duas camadas 3x3 Conv → Conv2d(c3, nc, 1).

Cada ponto de âncora emite, portanto, no = nc + 4 * reg_max saídas. A remoção das âncoras predefinidas elimina os tamanhos e as proporções das caixas de âncora dos hiperparâmetros que precisam ser ajustados.

Perda focal de distribuição (DFL)#

O YOLOv8 e o YOLO11 fazem a regressão de cada uma das 4 coordenadas da caixa como uma distribuição sobre reg_max = 16 bins, em vez de um único escalar (a forma integral da Perda Focal Generalizada). O módulo DFL remodela os canais 4 * reg_max da caixa para (4, reg_max), aplica softmax aos reg_max bins e usa como coordenada prevista o índice esperado do bin — cada índice ponderado pela probabilidade do seu softmax, e depois somado. Isso é implementado como uma convolução fixa 1x1, cujos pesos são os índices dos bins arange(reg_max), de modo que a soma ponderada corresponde a um único produto escalar.

YOLO26: sem NMS e sem DFL#

O YOLO26 define dois parâmetros YAML que o head lê diretamente:

• end2end: True — Detect faz uma cópia profunda dos ramos para um head um-para-um (one2one_cv2/one2one_cv3), que aprende uma única previsão por objeto. Essa configuração YAML cria ambos os heads de treinamento; em tempo de execução, nms=False seleciona o head um-para-um e remove a etapa de pós-processamento de supressão não máxima (NMS). Consulte o guia de detecção ponta a ponta para ver detalhes de inferência e exportação.
• reg_max: 1 — com um único bin, self.dfl se torna nn.Identity() e no = nc + 4; o head faz a regressão direta das coordenadas, e nenhuma operação DFL aparece no grafo ONNX exportado.

Entre seus cinco tamanhos de modelo (n/s/m/l/x), o YOLO26 alcança 40.9-57.5 mAP no COCO, com latência de 1.7-11.8 ms no T4 usando TensorRT, conforme relatado no artigo do YOLO26.

Resumo versão por versão#

Para ver detalhes de cada modelo, tabelas de desempenho e exemplos de uso, consulte as páginas individuais do YOLOv3, YOLOv5, YOLOv8, YOLO11 e YOLO26.

Inspecione a arquitetura por conta própria#

O método model.info() imprime um resumo das camadas, dos parâmetros e dos FLOPs, e a lista de módulos analisada está disponível em model.model.model.

from ultralytics import YOLO

# Carregar um modelo pré-treinado
model = YOLO("yolo11n.pt")

# Funda as camadas Conv + BatchNorm para que as contagens correspondam às especificações publicadas
model.fuse()

# Imprima um resumo: camadas, parâmetros, gradientes, GFLOPs
model.info()

# Inspecione o head de detecção (o último módulo da rede)
head = model.model.model[-1]
print(type(head).__name__, "| reg_max:", head.reg_max, "| DFL layer:", type(head.dfl).__name__)

Executar o trecho de código em três gerações mostra as mudanças em números. Estas são saídas reais de modelos fundidos do pacote ultralytics, que correspondem às contagens de parâmetros e FLOPs publicadas em cada página de modelo:

O YOLO26n informa reg_max=1 e uma camada DFL Identity. Por padrão, a previsão e a validação usam o modo um-para-muitos com NMS; defina nms=False para inferência sem NMS. Ambos os heads são treinados.

Conclusão#

Entre as versões, a arquitetura YOLO mudou uma etapa de cada vez: o backbone passou de Darknet-53 para blocos C3, C2f e C3k2 baseados em CSP, com atenção C2PSA; o neck manteve a estrutura FPN + PAN, enquanto SPP passou a ser SPPF; e a head passou de baseada em âncoras para sem âncoras, chegando então ao design do YOLO26 sem DFL, com uma head opcional sem NMS para ponta a ponta.

Para definir arquiteturas personalizadas, consulte o Guia de configuração YAML de modelos ou compare os modelos nas páginas de modelos. Se tiver dúvidas, entre em contato pelo GitHub ou pelo Discord.

Perguntas frequentes#