Link to this sectionExplicação da arquitetura YOLO: do YOLOv3 ao YOLO26#

Todo modelo Ultralytics YOLO é construído a partir de três estágios: um backbone que extrai características, um neck que as funde através de 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 para o YOLO26, rastreando cada componente até sua definição nos arquivos de configuração em ultralytics/cfg/models/ e nas classes de módulos em ultralytics/nn/modules/.

Cada modelo é definido declarativamente em um arquivo YAML como uma lista ordenada de camadas, onde cada camada segue o formato [from, repeats, module, args]: quais camadas a alimentam, quantas vezes o módulo se repete, a classe da camada (Conv, C3k2, SPPF, Detect, …) e seus argumentos de construtor. O Guia de Configuração YAML do Modelo documenta este formato — incluindo como repeats e args escalam com os múltiplos de profundidade e largura da variante — juntamente com o sistema de resolução de módulos completo. Este guia foca nos módulos em si e como eles mudaram de versão para versão.

Link to this sectionOs Três Estágios#

Todo modelo Ultralytics YOLO roteia a imagem através de 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, batch normalization e uma ativação SiLU, aplicadas em sequência. Cada módulo maior abaixo é construído compondo blocos Conv.

Link to this sectionDiagramas de Arquitetura#

Cada versão mantém o mesmo esqueleto backbone → neck → head e altera estágios específicos. As abas abaixo mostram a estrutura por versão: os estágios de backbone e neck seguem as configs em ultralytics/cfg/models/, enquanto os heads do YOLOv3 e YOLOv5 são desenhados em sua forma original baseada em âncoras, em vez da variante u sem âncoras que suas configurações de pacote realmente enviam. Percorrer as abas mostra o que cada geração adicionou. Em resumo, a progressão é: o YOLOv3 é um detector baseado em âncoras exclusivo de FPN; o YOLOv5 adiciona o caminho PAN de baixo para cima e SPPF; o YOLOv8 muda para o bloco C2f com um head sem âncoras DFL; o YOLO11 insere atenção C2PSA e o bloco C3k2; e o YOLO26 adiciona um resíduo SPPF e torna o head livre de NMS e livre de DFL. As cores dos nós seguem a convenção do diagrama da documentação: entrada verde, backbone azul, pooling espacial e atenção em ardósia, neck laranja, head e saída roxos.

flowchart TD
    IN[Input 640x640]:::start --> ST[Conv stem<br/>5x stride-2 down to P1-P5]:::proc
    ST --> BB[Darknet-53 backbone<br/>stacked Bottleneck]:::proc
    BB --> FPN[Neck FPN only<br/>top-down Upsample + Concat]:::decide
    FPN --> HD[Detect head<br/>3 scales, anchor-based]:::out
    HD --> O[Predictions + NMS]:::out
    classDef start fill:#4CAF50,color:#fff
    classDef proc fill:#2196F3,color:#fff
    classDef decide fill:#FF9800,color:#fff
    classDef out fill:#9C27B0,color:#fff

Os diagramas do YOLOv3 e YOLOv5 mostram o head original baseado em âncoras. O pacote ultralytics envia as configs YOLOv3u e YOLOv5u sem âncoras — os mesmos backbones Darknet-53 e C3 com o head Detect do YOLOv8 — descritos em Detection Head.

Link to this sectionBlocos de Backbone: Bottleneck → C3 → C2f → C3k2#

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

Link to this sectionBottleneck (YOLOv3)#

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

Link to this sectionC3 (YOLOv5)#

YOLOv5's C3 splits the input across two 1x1 convolutions: cv1 feeds n sequential Bottleneck blocks (kernels (1, 1) then (3, 3)), cv2 bypasses them. The two paths are concatenated and fused by a third 1x1 Conv:

def forward(self, x):
    # C3: bottleneck path m(cv1(x)) concatenated with bypass cv2(x), then fused by cv3
    return self.cv3(torch.cat((self.m(self.cv1(x)), self.cv2(x)), 1))

Apenas a saída final do bottleneck alcança a convolução de fusão, então cv3 vê 2 mapas de características.

Link to this sectionC2f (YOLOv8)#

YOLOv8's C2f ("CSP Bottleneck with 2 convolutions, faster") changes which features reach the fusion conv:

1. cv1 = Conv(c1, 2 * c, 1), então chunk(2) divide a saída em dois tensores de canal c.
2. n blocos Bottleneck(c, c) (kernels (3, 3), (3, 3)) rodam sequencialmente, cada um alimentado pela saída do bloco anterior.
3. Todos os n + 2 tensores intermediários são concatenados e fundidos por cv2 = Conv((2 + n) * c, c2, 1).

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

Link to this sectionC3k2 (YOLO11 e YOLO26)#

O YOLO11 e o YOLO26 usam C3k2, uma subclasse de C2f que troca a unidade de repetição. Cada um dos n blocos se torna, dependendo das flags do construtor:

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

O segundo argumento YAML define c3k; por exemplo, [-1, 2, C3k2, [512, True]] constrói um módulo C3k2 em 512 canais de saída cujos blocos internos são C3k (já que c3k=True). Para módulos CSP, o campo repeats — aqui 2, antes de ser escalado pelo múltiplo de profundidade da variante — torna-se a contagem de repetição interna do bloco em vez de empilhar módulos separados.

Link to this sectionPooling Espacial: SPP → SPPF#

At the end of the backbone, a spatial-pyramid-pooling block widens the receptive field. YOLOv5 replaced the original multi-kernel SPP with SPPF (Spatial Pyramid Pooling - Fast): a single MaxPool2d(kernel_size=5, stride=1, padding=2) applied n = 3 times in sequence, with the input and all three pooled outputs concatenated and fused by a 1x1 Conv. This is mathematically equivalent to SPP(k=(5, 9, 13)) but cheaper, because the chained 5x5 pools cover the larger kernels' receptive fields.

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

Link to this sectionAtenção Espacial: C2PSA (YOLO11+)#

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

Link to this sectionNeck: FPN + PAN#

O neck funde 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 de head do YAML, FPN é nn.Upsample + Concat (levando informações semânticas para baixo para resoluções mais altas) e PAN é Conv + Concat com stride-2 (levando 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 YOLO26 — então cada ponto de fusão executa o mesmo módulo que o backbone usa. As três saídas fundidas alimentam o head. O YOLOv3 é a exceção: seu neck é apenas FPN de cima para baixo (seu head YAML não possui downsampling de stride-2), sem o caminho PAN de baixo para cima que o YOLOv5 introduziu.

Link to this sectionDetection Head: Baseado em Âncora → Sem Âncora → Livre de NMS#

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

Link to this sectionDetect desacoplado, sem âncoras#

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

O head Detect (head.py) é sem âncoras e desacoplado: por nível de pirâmide, ele executa dois ramos paralelos e prevê diretamente nos pontos da grade, em vez de contra caixas de âncora.

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

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

Link to this sectionDistribution Focal Loss (DFL)#

O YOLOv8 e YOLO11 regridem 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 de Generalized Focal Loss). O módulo DFL remodela os canais de caixa 4 * reg_max para (4, reg_max), aplica um softmax sobre os bins reg_max e assume o índice do bin esperado — cada índice de bin ponderado por sua probabilidade softmax, depois somado — como a coordenada prevista. Isso é implementado como uma convolução 1x1 fixa cujos pesos são os índices de bin arange(reg_max), então a soma ponderada é um único produto escalar.

Link to this sectionYOLO26: Livre de NMS, Livre de DFL#

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

• end2end: True — Detect faz uma cópia profunda de seus ramos para um head um-para-um (one2one_cv2/one2one_cv3) que produz uma única previsão por objeto, removendo o passo de pós-processamento Non-Maximum Suppression (NMS). Veja o guia de Detecção End-to-End para detalhes de exportação e migração.
• reg_max: 1 — com um bin, self.dfl torna-se nn.Identity() e no = nc + 4; o head regride coordenadas diretamente e nenhuma operação DFL aparece no grafo ONNX exportado.

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

Link to this sectionResumo Versão por Versão#

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

Link to this sectionInspecione a Arquitetura Você Mesmo#

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

from ultralytics import YOLO

# Load a pretrained model
model = YOLO("yolo11n.pt")

# Fuse Conv + BatchNorm layers so counts match the published specs
model.fuse()

# Print a summary: layers, parameters, gradients, GFLOPs
model.info()

# Inspect the detection head (the last module in the network)
head = model.model.model[-1]
print(type(head).__name__, "| reg_max:", head.reg_max, "| end2end:", head.end2end)

Executar o snippet através de três gerações mostra as mudanças numericamente. Estas são saídas reais de modelo fundido do pacote ultralytics, correspondendo às contagens de parâmetros e FLOPs publicadas em cada página do modelo:

O YOLO26n relata reg_max=1, end2end=True e uma camada DFL Identity — a assinatura arquitetural de seu head livre de NMS e livre de DFL.

Link to this sectionConclusão#

Entre as versões, a arquitetura YOLO mudou um estágio 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 sua estrutura FPN + PAN enquanto o SPP se tornou SPPF; e o head passou de baseado em âncoras para livre de âncoras, e depois para o design de ponta a ponta sem NMS e sem DFL do YOLO26.

Para definir arquiteturas personalizadas, consulte o Guia de Configuração YAML do Modelo ou compare modelos nas páginas de modelos. Para perguntas, entre em contato pelo GitHub ou Discord.

Link to this sectionFAQ#

Link to this sectionQuais são os três estágios de uma arquitetura YOLO?#

Um modelo YOLO possui um backbone que extrai características da imagem nos strides 8, 16 e 32, um neck que funde essas características através de escalas com FPN e PAN, e um head que prevê caixas delimitadoras e pontuações de classe. Todos os modelos Ultralytics YOLO, do YOLOv3 ao YOLO26, seguem esse design de três estágios.

Link to this sectionQual é a diferença entre os blocos C2f e C3k2?#

C2f (YOLOv8) é um bloco CSP que concatena as saídas de cada Bottleneck interno — n + 2 mapas de características — antes de sua convolução de fusão, onde o C3 mais antigo passa apenas 2. C3k2 (YOLO11 e YOLO26) é uma subclasse de C2f que pode substituir cada Bottleneck por um bloco C3k (uma variante do C3 com um tamanho de kernel configurável) quando seu sinalizador c3k está ativado. Ambos são definidos em block.py.

Link to this sectionO que mudou na arquitetura entre o YOLOv8 e o YOLO11?#

O YOLO11 faz três mudanças estruturais no YOLOv8: substitui o backbone e o bloco neck C2f por C3k2, insere um bloco de autoatenção C2PSA após o SPPF e alterna a ramificação de classificação do head para convoluções separáveis em profundidade mais leves. Ambos mantêm o mesmo head Detect desacoplado e livre de âncoras com regressão DFL reg_max=16, portanto, as mudanças reduzem as contagens de parâmetros e FLOPs enquanto aumentam a precisão, em vez de redesenhar a interface de detecção.

Link to this sectionO YOLO é livre de âncoras?#

Os modelos Ultralytics YOLO modernos são livres de âncoras. YOLOv8, YOLO11 e YOLO26 usam um head Detect desacoplado e livre de âncoras com ramificações separadas para regressão de caixa e classificação. O YOLOv3 e o YOLOv5 originais eram baseados em âncoras, mas a Ultralytics os distribui como as variantes YOLOv3u e YOLOv5u, cujas configurações usam o mesmo head livre de âncoras do YOLOv8.

Link to this sectionO YOLO26 removeu o NMS?#

Sim — o YOLO26 define end2end=True, o que dá ao Detect um head um-para-um que produz uma única previsão por objeto e remove a etapa de pós-processamento de Non-Maximum Suppression necessária em modelos anteriores. Veja o guia de Detecção de Ponta a Ponta para detalhes.

Link to this sectionO que é Distribution Focal Loss (DFL) e por que o YOLO26 a removeu?#

A DFL regride cada coordenada de caixa como uma distribuição softmax sobre reg_max bins (16 por padrão no YOLOv8 e YOLO11) e utiliza o valor esperado como a coordenada, em vez de prever um único escalar. O YOLO26 define reg_max=1, então a camada DFL se torna uma operação de identidade, o head regride as coordenadas diretamente e nenhuma operação DFL aparece nos gráficos ONNX ou TensorRT exportados.

Link to this sectionComo posso ver a arquitetura de um modelo YOLO específico?#

Carregue o modelo em Python e chame model.info() para um resumo de camada, parâmetros e GFLOPs. As camadas analisadas estão em model.model.model — por exemplo, model.model.model[-1] é o head Detect, expondo atributos como reg_max e end2end. A arquitetura completa é definida no arquivo de configuração YAML do modelo.