Arquitectura de YOLO explicada: de YOLOv3 a YOLO26#

Todos los modelos YOLO de Ultralytics se construyen en tres etapas: un backbone que extrae características, un neck que las fusiona entre escalas y un head que predice cajas y clases. Esta guía documenta los módulos que componen cada etapa y cómo han cambiado de YOLOv3 a YOLO26, vinculando cada componente con su definición en los archivos de configuración de ultralytics/cfg/models/ y con las clases de módulos de 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 o capas 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 de modelos documenta este formato —incluido cómo repeats y args escalan con los multiplicadores de profundidad y anchura de la variante—, junto con el sistema completo de resolución de módulos. Esta guía se centra en los propios módulos y en cómo han cambiado de una versión a otra.

Las tres etapas#

Todos los modelos YOLO de Ultralytics procesan la imagen mediante 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, normalización por lotes y una activación SiLU, aplicadas secuencialmente. Todos los módulos más grandes que aparecen a continuación se construyen componiendo bloques Conv.

Diagramas de arquitectura#

Cada versión mantiene el mismo esqueleto de backbone → neck → head y modifica etapas concretas. Las pestañas siguientes muestran la estructura de cada versión: las etapas del backbone y del neck siguen las configuraciones de ultralytics/cfg/models/, mientras que los heads de YOLOv3 y YOLOv5 se representan en su forma original basada en anclajes, en lugar del head de variante u sin anclajes que incluyen realmente sus configuraciones de paquete. Recorrer las pestañas muestra qué añadió cada generación. En resumen, la progresión es la siguiente: YOLOv3 es un detector basado en anclajes que solo utiliza FPN; YOLOv5 añade la ruta PAN ascendente y SPPF; YOLOv8 cambia al bloque C2f, con un head sin anclajes y DFL; YOLO11 incorpora la atención C2PSA y el bloque C3k2; y YOLO26 añade un residual SPPF y hace que el head no use 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 el pooling 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 sin anclajes YOLOv3u y YOLOv5u: los mismos backbones Darknet-53 y C3, con el head Detect de YOLOv8, descritos en Head de detección.

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

El backbone apila un bloque CSP (parcial entre etapas) repetido entre capas de reducción de resolución Conv con stride 2. 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 y 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 las apila directamente, sin división CSP, y detecta a tres escalas (strides 8, 16 y 32).

C3 (YOLOv5)#

El C3 de YOLOv5 divide la entrada entre dos convoluciones 1x1: cv1 alimenta secuencialmente bloques Bottleneck n (kernels (1, 1) y después (3, 3)), mientras que cv2 los evita. Las dos rutas se concatenan y se fusionan mediante una tercera 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 recibe 2 mapas de características.

C2f (YOLOv8)#

El C2f de YOLOv8 ("Bottleneck CSP con 2 convoluciones, más rápido") cambia qué características llegan a la convolución de fusión:

1. cv1 = Conv(c1, 2 * c, 1) y después chunk(2) divide la salida en dos tensores de c canales.
2. Los bloques Bottleneck(c, c) n (kernels (3, 3), (3, 3)) se ejecutan secuencialmente; cada uno recibe la salida del bloque anterior.
3. Todos los tensores intermedios 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 cada salida intermedia del bottleneck.

C3k2 (YOLO11 y YOLO26)#

YOLO11 y YOLO26 utilizan C3k2, una subclase de C2f que sustituye la unidad repetida. Cada uno de los bloques n se convierte, según los indicadores del constructor, en:

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

El segundo argumento YAML establece c3k, salvo cuando la escala es m, l o x, que lo fuerzan a True; así es como un único yolo11.yaml sirve para las cinco variantes. Por tanto, [-1, 2, C3k2, [512, False]] construye internamente Bottleneck en n y s, pero internamente C3k en m, l y x; 512 es el número de canales antes del escalado, que el multiplicador de anchura de la variante convierte en 128 en n y en 768 en x. En los módulos CSP, el campo repeats —aquí 2, antes de escalarlo mediante el multiplicador de profundidad de la variante— se convierte en el número de repeticiones internas del bloque, en lugar de apilar módulos independientes.

Pooling espacial: SPP → SPPF#

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

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

Atención espacial: 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 (atención sensible a la posición): 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 multi-cabeza seguida de una red feed-forward de dos capas (Conv(c, 2 * c, 1) → Conv(2 * c, c, 1)), ambas con una conexión residual. YOLO26 mantiene el mismo backbone C3k2 + C2PSA.

Neck: FPN + PAN#

El neck fusiona los mapas de características P3/P4/P5 del backbone con una red piramidal de características (FPN) descendente, seguida de una red de agregación de rutas (PAN) ascendente. En la sección head de YAML, FPN es nn.Upsample + Concat (transporta información semántica hacia resoluciones mayores) y PAN es Conv + Concat con stride 2 (transporta la 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 fusión ejecuta el mismo módulo que utiliza el backbone. Las tres salidas fusionadas alimentan el head. YOLOv3 es la excepción: su neck solo utiliza FPN descendente (su head YAML no tiene reducción de resolución con stride 2), sin la ruta PAN ascendente que introdujo YOLOv5.

Head de detección: 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 entre versiones: de basado en anclajes a sin anclajes y, finalmente, sin NMS.

Detect sin anclajes y desacoplado#

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

El head Detect (head.py) no utiliza anclajes y está desacoplado: ejecuta dos ramas paralelas por nivel de pirámide y predice directamente en 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 tanto, cada punto de anclaje genera salidas no = nc + 4 * reg_max. Al eliminar los anclajes predefinidos, se eliminan de los hiperparámetros que deben ajustarse los tamaños y las proporciones de aspecto de las cajas de anclaje.

Pérdida focal de distribución (DFL)#

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

YOLO26: sin NMS y sin DFL#

YOLO26 establece dos parámetros 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 posprocesamiento de supresión de no máximos (NMS). Consulta la Guía de detección de extremo a extremo para obtener información sobre exportación y migración.
• reg_max: 1 — con un 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 grafo ONNX exportado.

En sus cinco tamaños de modelo (n/s/m/l/x), YOLO26 alcanza entre 40.9 y 57.5 mAP en COCO, con una latencia de TensorRT de 1.7 a 11.8 ms en una T4, según se indica en el artículo de YOLO26.

Resumen por versiones#

Para obtener información detallada de cada modelo, tablas de rendimiento y ejemplos de uso, consulta las páginas individuales de YOLOv3, YOLOv5, YOLOv8, YOLO11 y YOLO26.

Inspecciona la arquitectura por tu cuenta#

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)

Al ejecutar el fragmento en tres generaciones se muestran numéricamente los cambios. Son 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 muestra reg_max=1, end2end=True y una capa DFL Identity, la firma arquitectónica de su head sin NMS y sin DFL.

Conclusión#

Entre versiones, la arquitectura YOLO cambió una etapa cada 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 utilizar anclajes y, después, al diseño de extremo a extremo de YOLO26 sin NMS y sin DFL.

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

Preguntas frecuentes#