Arquitectura de YOLO explicada: de YOLOv3 a YOLO26#

Todos los modelos YOLO de Ultralytics se componen de tres etapas: un backbone que extrae características, un neck que las fusiona a distintas escalas y una 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, y rastrea cada componente hasta su definición en los archivos de configuración de ultralytics/cfg/models/ y las clases de módulo 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(s) la alimentan, cuántas veces se repite el módulo, la clase de capa (Conv, C3k2, SPPF, Detect, …) y sus argumentos de construcción. La guía de configuración YAML de modelos documenta este formato —incluido cómo repeats y args se escalan según los múltiplos de profundidad y anchura de la variante—, así como 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 hacen pasar la imagen por 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 en secuencia. Todos los módulos más grandes que se describen a continuación se construyen componiendo bloques Conv.

Diagramas de arquitectura#

Cada versión mantiene el mismo esqueleto de red troncal → cuello → cabeza y modifica etapas concretas. Las pestañas de abajo muestran la estructura de cada versión: las etapas de la red troncal y del cuello siguen las configuraciones de ultralytics/cfg/models/, mientras que las cabezas de YOLOv3 y YOLOv5 se representan en su forma original basada en anclas, en lugar de usar la cabeza de la variante u sin anclas que incluyen realmente sus configuraciones de paquete. Al recorrer las pestañas, verás qué añadió cada generación. En resumen, la evolución es la siguiente: YOLOv3 es un detector basado en anclas que solo usa FPN; YOLOv5 añade la ruta PAN ascendente y SPPF; YOLOv8 cambia al bloque C2f con una cabeza sin anclas y DFL; YOLO11 incorpora atención C2PSA y el bloque C3k2; y YOLO26 añade un bloque residual SPPF, elimina DFL y añade una cabeza opcional sin NMS.

Los diagramas de YOLOv3 y YOLOv5 muestran la head original basada en anclajes. El paquete ultralytics incluye las configuraciones sin anclajes YOLOv3u y YOLOv5u: los mismos backbones Darknet-53 y C3, pero con la head Detect de YOLOv8, descrita 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 están en block.py; c1/c2 son los canales de entrada/salida y c = 0.5 * c2 es la anchura oculta.

Bottleneck (YOLOv3)#

La unidad básica 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 bloque C3 de YOLOv5 divide la entrada entre dos convoluciones 1x1: cv1 alimenta secuencialmente bloques Bottleneck n (kernels (1, 1) y luego (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: la ruta bottleneck m(cv1(x)) se concatena con la ruta alternativa cv2(x) y, a continuación, cv3 las fusiona
    return self.cv3(torch.cat((self.m(self.cv1(x)), self.cv2(x)), 1))

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

C2f (YOLOv8)#

El bloque 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, a continuación, 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 usan C3k2, una subclase de C2f que sustituye la unidad repetida. Según los indicadores del constructor, cada uno de los bloques n pasa a ser:

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

El segundo argumento YAML establece c3k, salvo que la escala sea m, l o x, en cuyo caso se fuerza a True: así, un único yolo11.yaml sirve para las cinco variantes. Por eso, [-1, 2, C3k2, [512, False]] crea componentes internos Bottleneck en n y s, pero componentes internos C3k en m, l y x; 512 es el número de canales antes del escalado, que el múltiplo de anchura de la variante convierte en 128 en n y en 768 en x. En los módulos CSP, el campo repeats —aquí vale 2 antes de escalarse con el múltiplo 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 de pirámide espacial amplía el campo receptivo. YOLOv5 sustituyó el SPP original, con varios kernels, por SPPF (pooling de pirámide espacial rápido): un único MaxPool2d(kernel_size=5, stride=1, padding=2) aplicado n = 3 veces seguidas; después, la entrada y las tres salidas del pooling se concatenan y se fusionan mediante un Conv 1x1. Esto es matemáticamente equivalente a SPP(k=(5, 9, 13)), pero tiene un coste menor porque los pooling encadenados 5x5 cubren los campos receptivos de los kernels más grandes.

YOLO26 activa un indicador de conexión residual (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 y posteriores)#

YOLO11 añadió C2PSA después de SPPF. Es un bloque CSP cuya rama activa consiste en 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 conserva el mismo backbone C3k2 + C2PSA.

Neck: FPN + PAN#

El neck fusiona los mapas de características P3/P4/P5 del backbone mediante 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 (transmite la información semántica hacia resoluciones más altas) y PAN es Conv + Concat con stride 2 (transmite la información de localización 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 de 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 usa el backbone. Las tres salidas fusionadas alimentan la head. YOLOv3 es la excepción: su neck solo usa FPN descendente (su head YAML no tiene reducción de resolución con stride 2) y carece de la ruta PAN ascendente que introdujo YOLOv5.

Head de detección: basada en anclajes → sin anclajes → sin NMS#

La head convierte los tres mapas de características fusionados en predicciones para la tarea de detección. Su diseño ha evolucionado entre versiones: primero se basaba en anclajes, después dejó de basarse en anclajes y, por último, prescindió de NMS.

Detect sin anclajes y desacoplada#

Las versiones originales de YOLOv3 y YOLOv5 usaban una head basada en anclajes y acoplada: 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, pero con la head Detect de YOLOv8, también sin anclajes. Las configuraciones yolov3.yaml y yolov5.yaml que se documentan aquí corresponden a estas variantes u, no al diseño histórico.

La head Detect (head.py) no usa anclajes y está desacoplada: en cada nivel de la pirámide ejecuta dos ramas paralelas y predice directamente en puntos de la cuadrícula, en lugar de hacerlo con respecto 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 usa la variante heredada, con dos capas 3x3 Conv → Conv2d(c3, nc, 1).

Por tanto, cada punto de anclaje genera no = nc + 4 * reg_max salidas. Al eliminar los anclajes predefinidos, también se eliminan de los hiperparámetros que hay que ajustar 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 intervalos, en lugar de como un único escalar (la forma integral de Generalized Focal Loss). El módulo DFL reajusta la forma de los canales de caja 4 * reg_max a (4, reg_max), aplica una softmax sobre los intervalos reg_max y toma como coordenada predicha el índice esperado del intervalo: multiplica cada índice por su probabilidad softmax y suma los resultados. Esto se implementa como una convolución fija 1x1, cuyos pesos son los índices de los intervalos arange(reg_max), de modo que la suma ponderada se reduce a un único producto escalar.

YOLO26: sin NMS y sin DFL#

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

• end2end: True: Detect copia en profundidad sus ramas a una head uno a uno (one2one_cv2/one2one_cv3) que aprende una única predicción por objeto. Esta opción YAML crea ambas heads de entrenamiento; en tiempo de ejecución, nms=False selecciona la head uno a uno y elimina el paso de posprocesamiento supresión no máxima (NMS). Consulta la guía de detección de extremo a extremo para obtener información sobre la inferencia y la exportación.
• reg_max: 1: con un solo intervalo, self.dfl se convierte en nn.Identity() y no = nc + 4; la head regresa las coordenadas directamente y el grafo ONNX exportado no incluye ninguna operación DFL.

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 entre 1.7 y 11.8 ms en TensorRT sobre T4, según se indica en el artículo de YOLO26.

Resumen por versión#

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

Inspecciona la arquitectura por tu cuenta#

El método model.info() muestra 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

# Cargar un modelo preentrenado
model = YOLO("yolo11n.pt")

# Fusiona las capas Conv + BatchNorm para que los recuentos coincidan con las especificaciones publicadas
model.fuse()

# Imprime un resumen: capas, parámetros, gradientes, GFLOPs
model.info()

# Inspecciona la head de detección (el último módulo de la red)
head = model.model.model[-1]
print(type(head).__name__, "| reg_max:", head.reg_max, "| DFL layer:", type(head.dfl).__name__)

Al ejecutar el fragmento en tres generaciones, los cambios se aprecian numéricamente. Se trata de resultados reales de modelos fusionados del paquete ultralytics, que coinciden con los recuentos de parámetros y FLOPs publicados en cada página del modelo:

YOLO26n indica reg_max=1 y una capa DFL Identity. La predicción y la validación usan por defecto la estrategia uno a muchos con NMS; establece nms=False para realizar inferencias sin NMS. Se entrenan ambas heads.

Conclusión#

A lo largo de las distintas versiones, la arquitectura YOLO fue cambiando una etapa cada vez: la red troncal pasó de Darknet-53 a bloques C3, C2f y C3k2 basados en CSP, con atención C2PSA; el cuello mantuvo su estructura FPN + PAN mientras SPP pasó a ser SPPF; y la cabeza pasó de estar basada en anclas a no usar anclas y, después, al diseño de YOLO26 sin DFL, con una cabeza opcional de extremo a extremo sin NMS.

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 con nosotros en GitHub o Discord.

Preguntas frecuentes#