Link to this sectionExplicación de la arquitectura YOLO: de YOLOv3 a YOLO26#

Cada modelo Ultralytics YOLO se construye a partir de tres etapas: un backbone que extrae características, un neck que las fusiona a través de escalas y un head que predice cajas y clases. Esta guía documenta los módulos que componen cada etapa y cómo cambiaron desde YOLOv3 hasta YOLO26, rastreando cada componente hasta su definición en los archivos de configuración bajo ultralytics/cfg/models/ y las clases de módulo 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 la capa (Conv, C3k2, SPPF, Detect, …) y sus argumentos de constructor. La Guía de configuración de modelos YAML documenta este formato, incluyendo cómo los 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.

Link to this sectionLas 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, batch normalization y una activación SiLU, aplicadas en secuencia. Cada módulo más grande a continuación se construye componiendo bloques Conv.

Link to this sectionDiagramas de arquitectura#

Cada versión mantiene el mismo esqueleto backbone → neck → head y cambia etapas específicas. Las pestañas a continuación muestran la estructura por versión: las etapas de backbone y 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 u-variant sin anclajes que incluyen realmente sus configuraciones de paquete. Al revisar las pestañas se observa lo que añadió cada generación. En resumen, la progresión es: YOLOv3 es un detector basado en anclajes solo con FPN; YOLOv5 añade la ruta PAN ascendente y SPPF; YOLOv8 cambia al bloque C2f con un head DFL sin anclajes; YOLO11 inserta la atención C2PSA y el bloque C3k2; y YOLO26 añade un residual SPPF y hace que el head no necesite NMS ni DFL. Los colores de los nodos siguen la convención de los diagramas de documentación: verde para entrada, azul para backbone, gris pizarra para pooling espacial y atención, naranja para neck, morado para head y 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— descritos en Detection Head.

Link to this sectionBloques de backbone: Bottleneck → C3 → C2f → C3k2#

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

Link to this sectionBottleneck (YOLOv3)#

La unidad base es Bottleneck: dos capas Conv (kernels por defecto (3, 3)) con una suma residual opcional cuando shortcut=True y c1 == c2. El backbone Darknet-53 de YOLOv3 apila estos directamente, sin división CSP, y detecta en tres 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))

Solo la salida del bottleneck final llega a la conv de fusión, por lo que cv3 ve 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), luego chunk(2) divide la salida en dos tensores de c canales.
2. n bloques Bottleneck(c, c) (kernels (3, 3), (3, 3)) se ejecutan secuencialmente, cada uno alimentado con la salida del bloque anterior.
3. Todos los n + 2 tensores intermedios se concatenan y fusionan mediante cv2 = Conv((2 + n) * c, c2, 1).

Donde C3 pasa 2 mapas de características a su conv de fusión, C2f pasa n + 2: cada salida intermedia de bottleneck se reutiliza.

Link to this sectionC3k2 (YOLO11 y YOLO26)#

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

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

El segundo argumento 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 que 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 la cuenta de repetición interna del bloque en lugar de apilar módulos separados.

Link to this sectionSpatial Pooling: 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.

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

Link to this sectionSpatial Attention: C2PSA (YOLO11+)#

YOLO11 añadió C2PSA después de SPPF. Es un bloque CSP cuya rama activa es una pila de n módulos PSABlock (Position-Sensitive Attention): cv1 = Conv(c1, 2 * c, 1) divide las características, una mitad pasa a través de la pila PSABlock, y cv2 = Conv(2 * c, c1, 1) fusiona la concatenación. Cada PSABlock aplica atención multi-head seguida de una red feed-forward 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 C3k2 + C2PSA.

Link to this sectionNeck: FPN + PAN#

El neck fusiona los mapas de características P3/P4/P5 del backbone con una Feature Pyramid Network (FPN) descendente seguida de una Path Aggregation Network (PAN) ascendente. En la sección de head del YAML, FPN es nn.Upsample + Concat (llevando información semántica hacia resoluciones más altas) y PAN es Conv de stride 2 + Concat (llevando 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 de 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 solo FPN descendente (su head en YAML no tiene submuestreo de stride 2), sin la ruta PAN ascendente que introdujo YOLOv5.

Link to this sectionDetection 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 través de las versiones, de basado en anclajes a sin anclajes y sin NMS.

Link to this sectionHead Detect desacoplado y sin anclajes#

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

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

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

Cada punto de anclaje emite, por tanto, no = nc + 4 * reg_max salidas. Eliminar los anclajes predefinidos elimina los tamaños y relaciones de aspecto de las cajas de anclaje de los hiperparámetros que deben ajustarse.

Link to this sectionDistribution Focal Loss (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 un único escalar (la forma integral de Generalized Focal Loss). El módulo DFL remodela los 4 * reg_max canales de caja a (4, reg_max), aplica un softmax sobre los bins de reg_max y toma el índice de bin esperado —cada índice de bin ponderado por su probabilidad softmax, luego sumado— como la coordenada predicha. Esto se implementa como una convolución fija 1x1 cuyos pesos son los índices de bin arange(reg_max), de modo que la suma ponderada es un producto escalar único.

Link to this sectionYOLO26: sin NMS, sin DFL#

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

• end2end: True — Detect copia profundamente sus ramas en un head uno a uno (one2one_cv2/one2one_cv3) que produce una única predicción por objeto, eliminando el paso de post-procesamiento de Non-Maximum Suppression (NMS). Consulta la guía de Detección de extremo a extremo para obtener detalles 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 coordenadas directamente y ninguna operación DFL aparece en el gráfico ONNX exportado.

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

Link to this sectionResumen versión a versión#

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

Link to this sectionInspecciona la arquitectura tú mismo#

El método model.info() imprime un resumen de capas, parámetros y FLOPs, y la lista de módulos analizados 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 a través de tres generaciones muestra los cambios numéricamente. Estas son salidas de modelos fusionados reales del paquete ultralytics, que coinciden con los recuentos de parámetros y FLOPs publicados en cada página de modelo:

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

Link to this sectionConclusión#

A través 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 la head pasó de estar basada en anclas a ser anchor-free, y luego al diseño end-to-end sin NMS y sin DFL de YOLO26.

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

Link to this sectionFAQ#

Link to this section¿Cuáles son las tres etapas de una arquitectura YOLO?#

Un modelo YOLO tiene un backbone que extrae características de la imagen a pasos de 8, 16 y 32, un neck que fusiona esas características a través de escalas con FPN y PAN, y una head que predice cajas delimitadoras (bounding boxes) y puntuaciones de clase. Cada modelo Ultralytics YOLO desde YOLOv3 hasta YOLO26 sigue este diseño de tres etapas.

Link to this section¿Cuál es la diferencia entre los bloques C2f y C3k2?#

C2f (YOLOv8) es un bloque CSP que concatena las salidas de cada Bottleneck interno — n + 2 mapas de características — antes de su convolución de fusión, donde el antiguo C3 pasa solo 2. C3k2 (YOLO11 y YOLO26) es una subclase de C2f que puede reemplazar cada Bottleneck con un bloque C3k (una variante de C3 con un tamaño de kernel configurable) cuando su indicador c3k está activado. Ambos están definidos en block.py.

Link to this section¿Qué cambió en la arquitectura entre YOLOv8 y YOLO11?#

YOLO11 realiza tres cambios estructurales en YOLOv8: reemplaza el bloque de backbone y neck C2f por C3k2, inserta un bloque de autoatención C2PSA después de SPPF, y cambia la rama de clasificación de la head a convoluciones separables en profundidad más ligeras. Ambos mantienen la misma head Detect anchor-free y desacoplada con regresión DFL reg_max=16, por lo que los cambios reducen los recuentos de parámetros y FLOPs mientras aumentan la precisión en lugar de rediseñar la interfaz de detección.

Link to this section¿Es YOLO anchor-free?#

Los modelos modernos Ultralytics YOLO son anchor-free. YOLOv8, YOLO11 y YOLO26 utilizan una head Detect anchor-free y desacoplada con ramas separadas para la regresión de cajas y la clasificación. Los YOLOv3 y YOLOv5 originales estaban basados en anclas, pero Ultralytics los distribuye como las variantes YOLOv3u y YOLOv5u, cuyas configuraciones utilizan la misma head anchor-free que YOLOv8.

Link to this section¿Eliminó YOLO26 el NMS?#

Sí — YOLO26 establece end2end=True, lo que le da a Detect una head uno a uno que produce una única predicción por objeto y elimina el paso de posprocesamiento de Non-Maximum Suppression requerido por modelos anteriores. Consulta la guía de detección End-to-End para más detalles.

Link to this section¿Qué es la Distribution Focal Loss (DFL) y por qué YOLO26 la eliminó?#

DFL realiza la regresión de cada coordenada de caja como una distribución softmax sobre reg_max bins (16 por defecto en YOLOv8 y YOLO11) y toma el valor esperado como la coordenada, en lugar de predecir un único escalar. YOLO26 establece reg_max=1, por lo que la capa DFL se convierte en una operación de identidad, la head realiza la regresión de coordenadas directamente y no aparece ninguna operación DFL en los gráficos ONNX o TensorRT exportados.

Link to this section¿Cómo puedo ver la arquitectura de un modelo YOLO específico?#

Carga el modelo en Python y llama a model.info() para obtener un resumen de capas, parámetros y GFLOPs. Las capas analizadas se encuentran en model.model.model — por ejemplo, model.model.model[-1] es la head Detect, que expone atributos como reg_max y end2end. La arquitectura completa está definida en el archivo de configuración YAML del modelo.