Explicación de la arquitectura YOLO: de YOLOv3 a YOLO26#

Cada modelo de Ultralytics YOLO se compone de tres etapas: un backbone que extrae características, un neck que las fusiona a través de distintas escalas y un head que predice cajas y clases. Esta guía documenta los módulos que forman cada etapa y cómo han cambiado desde YOLOv3 hasta YOLO26, rastreando cada componente hasta su definición en los archivos de configuración en ultralytics/cfg/models/ y en las clases de módulos en ultralytics/nn/modules/.

Cada modelo se define de forma declarativa en un archivo YAML como una lista ordenada de capas, donde cada capa sigue el formato [from, repeats, module, args]: qué capa(s) la alimentan, cuántas veces se repite el módulo, la clase de capa (Conv, C3k2, SPPF, Detect, …) y sus argumentos de constructor. La Guía de configuración YAML del modelo documenta este formato —incluyendo cómo repeats y args escalan con los múltiplos de profundidad y anchura de la variante— junto con el sistema de resolución de módulos al completo. Esta guía se centra en los módulos en sí y en cómo han cambiado de una versión a otra.

Las tres etapas#

Cada modelo Ultralytics YOLO enruta la imagen a través de tres etapas secuenciales, cada una con una función distinta:

La unidad fundamental es el bloque Conv (definido en conv.py): una convolución 2D, una normalización por lotes y una activación SiLU, aplicadas en secuencia. Todos los módulos más grandes que se muestran a continuación se construyen componiendo bloques Conv.

Diagramas de arquitectura#

Cada versión mantiene el mismo esqueleto de backbone → neck → head y cambia etapas específicas. Las pestañas siguientes muestran la estructura por versión: las etapas del backbone y el neck siguen las configuraciones en ultralytics/cfg/models/, mientras que los heads de YOLOv3 y YOLOv5 se dibujan en su forma original basada en anclajes en lugar del head sin anclajes de la variante u que sus configuraciones de paquete realmente incluyen. Al recorrer las pestañas se puede ver lo que añadió cada generación. En resumen, la progresión es: YOLOv3 es un detector basado en anclajes exclusivo para FPN; YOLOv5 añade la ruta PAN ascendente y SPPF; YOLOv8 cambia al bloque C2f con un head sin anclajes y con DFL; YOLO11 inserta la atención de C2PSA y el bloque C3k2; y YOLO26 añade un residuo en SPPF y hace que el head no requiera NMS ni DFL. Los colores de los nodos siguen la convención de los diagramas de la documentación: verde para la entrada, azul para el backbone, gris pizarra para la agrupación espacial y la atención, naranja para el neck, y morado para el head y la salida.

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

Los diagramas de YOLOv3 y YOLOv5 muestran el head original basado en anclajes. El paquete ultralytics incluye las configuraciones YOLOv3u y YOLOv5u sin anclajes —los mismos backbones Darknet-53 y C3 con el head Detect de YOLOv8— descritas en Detection Head.

Bloques de backbone: Bottleneck → C3 → C2f → C3k2#

El backbone apila un bloque CSP (Cross-Stage Partial) repetido entre capas de submuestreo de paso 2 Conv. Ese bloque repetido es lo que más ha cambiado entre versiones. Todos los bloques siguientes se encuentran en block.py; c1/c2 son los canales de entrada/salida y c = 0.5 * c2 es la anchura oculta.

Bottleneck (YOLOv3)#

La unidad base es Bottleneck: dos capas Conv (kernels predeterminados (3, 3)) con una suma residual opcional cuando shortcut=True y c1 == c2. El backbone Darknet-53 de YOLOv3 los apila directamente, sin división CSP, y detecta a tres escalas (pasos 8, 16, 32).

C3 (YOLOv5)#

YOLOv5's C3 divide la entrada entre dos convoluciones 1x1: cv1 alimenta n bloques secuenciales Bottleneck (kernels (1, 1) y luego (3, 3)), mientras que cv2 los omite. Ambas rutas se concatenan y fusionan mediante un tercer 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))

Solo la salida del bottleneck final llega a la convolución de fusión, por lo que cv3 ve 2 mapas de características.

C2f (YOLOv8)#

YOLOv8's C2f ("CSP Bottleneck with 2 convolutions, faster") modifica qué características llegan a la convolución de fusión:

1. cv1 = Conv(c1, 2 * c, 1), y luego chunk(2) divide la salida en dos tensores de canales c.
2. Los bloques n Bottleneck(c, c) (kernels (3, 3), (3, 3)) se ejecutan secuencialmente, y cada uno recibe la salida del bloque anterior.
3. Todos los tensores intermedios de n + 2 se concatenan y se fusionan mediante cv2 = Conv((2 + n) * c, c2, 1).

Mientras que C3 pasa 2 mapas de características a su convolución de fusión, C2f pasa n + 2; se reutiliza la salida de cada bottleneck intermedio.

C3k2 (YOLO11 y YOLO26)#

YOLO11 y YOLO26 utilizan C3k2, una subclase de C2f que intercambia la unidad de repetición. Cada uno de los bloques de n se convierte, dependiendo de los flags del constructor, en:

• un Bottleneck plano (por defecto, c3k=False),
• un bloque C3k (c3k=True) —una variante de C3 con un tamaño de kernel configurable— o
• un par Bottleneck + PSABlock (attn=True).

El segundo argumento de YAML establece c3k; por ejemplo, [-1, 2, C3k2, [512, True]] construye un módulo C3k2 a 512 canales de salida cuyos bloques internos son C3k (dado c3k=True). Para los módulos CSP, el campo repeats —aquí 2, antes de ser escalado por el múltiplo de profundidad de la variante— se convierte en el recuento de repeticiones internas del bloque en lugar de apilar módulos separados.

Spatial Pooling: SPP → SPPF#

Al final del backbone, un bloque de agrupación de pirámide espacial amplía el campo receptivo. YOLOv5 reemplazó el SPP original de múltiples kernels por SPPF (Spatial Pyramid Pooling - Fast): un único MaxPool2d(kernel_size=5, stride=1, padding=2) aplicado n = 3 veces en secuencia, con la entrada y las tres salidas agrupadas concatenadas y fusionadas por un 1x1 Conv. Esto es matemáticamente equivalente a SPP(k=(5, 9, 13)) pero más económico, porque las agrupaciones encadenadas de 5x5 cubren los campos receptivos de los kernels más grandes.

YOLO26 pasa un flag de atajo (SPPF, [1024, 5, 3, True]); dado c1 == c2 == 1024 en la capa más profunda, SPPF añade una conexión residual (return y + x).

Spatial Attention: C2PSA (YOLO11+)#

YOLO11 añadió C2PSA después de SPPF. Es un bloque CSP cuya rama activa es una pila de módulos n PSABlock (Position-Sensitive Attention): cv1 = Conv(c1, 2 * c, 1) divide las características, una mitad pasa por la pila PSABlock y cv2 = Conv(2 * c, c1, 1) fusiona la concatenación. Cada PSABlock aplica atención multicabezal seguida de una red de alimentación directa de dos capas (Conv(c, 2 * c, 1) → Conv(2 * c, c, 1)), cada una con una conexión residual. YOLO26 mantiene el mismo backbone de C3k2 + C2PSA.

Neck: FPN + PAN#

El neck fusiona los mapas de características P3/P4/P5 del backbone con una Feature Pyramid Network (FPN) de arriba hacia abajo seguida de una Path Aggregation Network (PAN) de abajo hacia arriba. En la sección YAML del head, FPN es nn.Upsample + Concat (que transporta información semántica hacia resoluciones más altas) y PAN es un Conv + Concat de paso 2 (que transporta información de localización de vuelta hacia arriba):

# 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

El neck reutiliza el bloque del backbone de su generación —C3 en YOLOv5, C2f en YOLOv8, C3k2 en YOLO11 y YOLO26—, por lo que cada punto de unión ejecuta el mismo módulo que usa el backbone. Las tres salidas fusionadas alimentan el head. YOLOv3 es la excepción: su neck es exclusivamente FPN de arriba hacia abajo (su head en YAML no tiene submuestreo de paso 2), sin la ruta PAN de abajo hacia arriba que introdujo YOLOv5.

Detection Head: de basado en anclajes → sin anclajes → sin NMS#

El head convierte los tres mapas de características fusionados en predicciones para la tarea de detección. Su diseño ha cambiado a lo largo de las versiones, pasando de estar basado en anclajes a no tener anclajes y, finalmente, a no requerir NMS.

Detect desacoplado y sin anclajes#

El YOLOv3 y YOLOv5 originales utilizaban un head acoplado y basado en anclajes: cajas de anclaje predefinidas y una rama compartida para las predicciones de cajas y clases. Los repositorios independientes ultralytics/yolov3 y ultralytics/yolov5 conservan ese diseño basado en anclajes. En su lugar, el paquete principal ultralytics incluye las variantes sin anclajes YOLOv3u y YOLOv5u —los mismos backbones Darknet-53 y C3 con el head sin anclajes Detect de YOLOv8—, y las configuraciones yolov3.yaml y yolov5.yaml documentadas aquí corresponden a estas variantes con u, y no al diseño histórico.

El head de Detect (head.py) no utiliza anclajes y está desacoplado: por cada nivel de la pirámide ejecuta dos ramas paralelas y predice directamente sobre los puntos de la cuadrícula en lugar de hacerlo frente a cajas de anclaje.

• Rama de cajas (cv2): Conv(x, c2, 3) → Conv(c2, c2, 3) → Conv2d(c2, 4 * reg_max, 1).
• Rama de clases (cv3): en YOLO11 y YOLO26, dos bloques separables en profundidad (DWConv + 1x1 Conv) → Conv2d(c3, nc, 1); YOLOv8 utiliza la variante heredada, dos capas 3x3 Conv → Conv2d(c3, nc, 1).

Por lo tanto, cada punto de anclaje emite salidas de no = nc + 4 * reg_max. Eliminar los anclajes predefinidos prescinde de los tamaños y las relaciones de aspecto de las cajas de anclaje dentro de los hiperparámetros que es necesario ajustar.

Distribution Focal Loss (DFL)#

YOLOv8 y YOLO11 regresan cada una de las 4 coordenadas de la caja como una distribución sobre bins de reg_max = 16 en lugar de un único escalar (la forma integral de Generalized Focal Loss). El módulo DFL remodela los canales de cajas de 4 * reg_max a (4, reg_max), aplica un softmax sobre los bins de reg_max y toma el índice de bin esperado —donde cada índice de bin se pondera por su probabilidad de softmax y luego se suma— como la coordenada predicha. Esto se implementa como una convolución fija de 1x1 cuyos pesos son los índices de los bins arange(reg_max), de modo que la suma ponderada es un único producto escalar.

YOLO26: sin NMS, sin DFL#

YOLO26 establece dos parámetros de YAML que el head lee directamente:

• end2end: True — Detect copia en profundidad sus ramas en un head uno a uno (one2one_cv2/one2one_cv3) que produce una única predicción por objeto, eliminando el paso de postprocesamiento de Non-Maximum Suppression (NMS). Consulta la Guía de detección de extremo a extremo para obtener detalles sobre la exportación y la migración.
• reg_max: 1 — con un solo bin, self.dfl se convierte en nn.Identity() y no = nc + 4; el head regresa las coordenadas directamente y no aparece ninguna operación DFL en el gráfico de ONNX exportado.

A través de sus cinco tamaños de modelo (n/s/m/l/x), YOLO26 alcanza entre 40.9 y 57.5 de mAP en COCO con una latencia de 1.7-11.8 ms en T4 TensorRT, tal como se informa en el documento de YOLO26.

Resumen versión a versión#

Para obtener detalles por modelo, tablas de rendimiento y ejemplos de uso, consulta las páginas individuales de YOLOv3, YOLOv5, YOLOv8, YOLO11 y YOLO26.

Inspecciona la arquitectura tú mismo#

El método model.info() imprime un resumen de capas, parámetros y FLOPs, y la lista de módulos analizada está disponible en 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)

Ejecutar el fragmento de código en tres generaciones muestra los cambios numéricamente. Se trata de salidas reales de modelos fusionados del paquete ultralytics, que coinciden con los recuentos de parámetros y FLOPs publicados en cada página de modelo:

YOLO26n informa de reg_max=1, end2end=True y una capa DFL Identity, la firma arquitectónica de su head sin NMS y sin DFL.

Conclusión#

A lo largo de las versiones, la arquitectura YOLO cambió una etapa a la vez: el backbone pasó de Darknet-53 a bloques C3, C2f y C3k2 basados en CSP con atención C2PSA; el neck mantuvo su estructura FPN + PAN mientras que SPP se convirtió en SPPF; y el head pasó de estar basado en anclajes a no tenerlos, para finalmente adoptar el diseño de extremo a extremo sin NMS y sin DFL de YOLO26.

Para definir arquitecturas personalizadas, consulta la Guía de configuración YAML del modelo o compara modelos en las páginas de modelos. Si tienes preguntas, ponte en contacto en GitHub o Discord.

FAQ#