Comprender la detección integral en Ultralytics YOLO26#

Los modelos de tipo de detección de YOLO26 —detección, segmentación, pose y OBB— vienen sin NMS por defecto: emiten las detecciones finales directamente desde el modelo, sin un paso posterior de Non-Maximum Suppression (NMS). Modelos anteriores como YOLOv8 y YOLO11 producen miles de predicciones superpuestas que un paso de NMS independiente debe filtrar, lo que añade latencia, complica los grafos de exportación y puede comportarse de forma incoherente en distintas plataformas de hardware.

Esto se conoce como detección de objetos de extremo a extremo y se activa por defecto. El resultado es un proceso de despliegue más sencillo y una menor latencia: YOLO26n se ejecuta hasta un 43 % más rápido que YOLO11n en inferencia ONNX en CPU (Intel Xeon CPU a 2,00 GHz).

Esta guía te explica qué ha cambiado, si necesitas actualizar tu código, qué formatos de exportación admiten inferencia integral y cómo migrar sin problemas desde modelos YOLO antiguos.

Para profundizar en la motivación detrás de este cambio arquitectónico, consulta la entrada del blog de Ultralytics sobre por qué YOLO26 elimina NMS.

Cómo funciona la detección integral#

YOLO26 utiliza una arquitectura de doble cabezal durante el entrenamiento. Ambos cabezales comparten el mismo esqueleto (backbone) y cuello (neck), pero producen salidas de formas diferentes:

Las formas anteriores corresponden a la detección, donde N es el tamaño de lote, nc es el número de clases (por ejemplo, 80 para COCO) y el recuento de 8400 anclajes es el valor en imgsz=640. Otras tareas amplían la salida uno a uno con datos adicionales por detección:

Durante el entrenamiento, ambos cabezales se ejecutan simultáneamente: el cabezal de uno a muchos proporciona una señal de aprendizaje más rica, mientras que el cabezal de uno a uno aprende a producir predicciones limpias y sin superposiciones. Durante la inferencia y la exportación, solo el cabezal de uno a uno está activo de forma predeterminada, produciendo hasta 300 detecciones por imagen en el formato [x1, y1, x2, y2, confidence, class_id].

Cuando llamas a model.fuse(), se combinan las capas Conv + BatchNorm para acelerar la inferencia y, en los modelos de extremo a extremo, también se elimina el cabezal de uno a muchos, lo que reduce el tamaño del modelo y las FLOPs. Para obtener más detalles sobre la arquitectura de doble cabezal, consulta la página del modelo YOLO26.

¿Necesito cambiar mi código?#

Usando la API de Python o la CLI de Ultralytics#

No se necesitan cambios. Si utilizas la API de Python de Ultralytics o la CLI estándar, todo funciona automáticamente: la predicción, la validación y la exportación gestionan los modelos de extremo a extremo de forma nativa.

from ultralytics import YOLO

# Load a YOLO26 model
model = YOLO("yolo26n.pt")

# Predict — no NMS step, no code changes
results = model.predict("image.jpg")

Usando código de inferencia personalizado#

Sí, el formato de salida es diferente. Si escribiste una lógica de postprocesamiento personalizada para YOLOv8 o YOLO11 (por ejemplo, al ejecutar inferencias con ONNX Runtime o TensorRT), tendrás que actualizarla para que admita la nueva forma de salida:

Para las tareas de segmentación, pose y OBB, YOLO26 adjunta datos específicos de la tarea a cada detección; consulta la tabla de formas de salida.

Con los modelos de extremo a extremo, el postprocesamiento se vuelve mucho más sencillo; por ejemplo, al utilizar ONNX Runtime:

import onnxruntime as ort

# Load and run the exported end-to-end model
session = ort.InferenceSession("yolo26n.onnx")
output = session.run(None, {session.get_inputs()[0].name: input_tensor})

# End-to-end output: (batch, 300, 6) → [x1, y1, x2, y2, confidence, class_id]
detections = output[0][0]  # first image in batch
detections = detections[detections[:, 4] > 0.25]  # confidence filter, no NMS

Cambiar al cabezal One-to-Many#

Si necesitas el formato de salida YOLO tradicional (por ejemplo, para reutilizar código de postprocesamiento basado en NMS existente), puedes cambiar al cabezal de uno a muchos cuando esté disponible configurando end2end=False:

from ultralytics import YOLO

model = YOLO("yolo26n.pt")

# Prediction with NMS (traditional behavior)
results = model.predict("image.jpg", end2end=False)

# Validation with NMS
metrics = model.val(data="coco.yaml", end2end=False)

# Export without end-to-end
model.export(format="onnx", end2end=False)

Compatibilidad del formato de exportación#

La mayoría de los formatos de exportación admiten la inferencia de extremo a extremo de forma nativa, incluidos ONNX, TensorRT, CoreML, OpenVINO, LiteRT y MNN.

Los siguientes formatos no admiten el extremo a extremo y recurren automáticamente al cabezal de uno a muchos: NCNN, RKNN, PaddlePaddle, ExecuTorch, IMX, Edge TPU y Qualcomm QNN.

Para Hailo, el exportador selecciona la ruta de salida de la cabeza cargada en lugar de un argumento, por lo que se rechaza end2end si se proporciona: un modelo de detección YOLO26 predeterminado mantiene sus salidas uno a uno sin NMS, mientras que un punto de control cuya cabeza ya es end2end=False compila la ruta tradicional con NMS de HailoRT.

Compromisos entre precisión y velocidad#

La detección de extremo a extremo ofrece importantes ventajas de despliegue con un impacto mínimo en la precisión:

En las cinco escalas de detección, la cabeza de uno a uno cuesta de 0,6 a 0,8 de mAP en COCO —de 40,9 a 40,1 para YOLO26n y de 57,5 a 56,9 para YOLO26x— a cambio de eliminar por completo la pasada de NMS. Si la máxima precisión es tu prioridad, vuelve a la cabeza de uno a varios con end2end=False.

Consulta las métricas de rendimiento de YOLO26 para ver pruebas comparativas detalladas en todos los tamaños de modelo (n, s, m, l, x).

Migración desde YOLOv8 o YOLO11#

Si estás actualizando un proyecto existente a YOLO26:

• Usuarios de la API / CLI de Ultralytics: No se necesitan cambios; solo actualiza el nombre del modelo a yolo26n.pt (o yolo26n-seg.pt, yolo26n-pose.pt, yolo26n-obb.pt)
• Código de postprocesamiento personalizado: Actualízalo para gestionar las nuevas formas de salida: (N, 300, 6) para detección, además de datos específicos de la tarea para segmentación, pose y OBB. Ten en cuenta también el cambio de formato de caja de xywh a xyxy
• Tuberías de exportación: Consulta la sección de compatibilidad de formatos para tu formato de destino
• TensorRT anterior a la 8.5.0: el extremo a extremo se deshabilita en todas las precisiones; actualiza TensorRT a la versión 8.5.0 o posterior para conservarlo
• Exportaciones cuantizadas: TensorRT 10.3.0 con quantize=8 en JetPack 6 y LiteRT con quantize=8 o quantize="w8a16" deshabilitan automáticamente el extremo a extremo; exporta a una precisión mayor para conservarlo
• Exportaciones en FP16: Si necesitas todas las salidas en FP16, exporta con end2end=False; consulta por qué output0 se queda en FP32
• iOS / CoreML: El extremo a extremo es totalmente compatible. Si necesitas soporte para Xcode Preview, utiliza end2end=False con nms=True
• Dispositivos Edge (NCNN, RKNN): Estos formatos vuelven automáticamente al modo one-to-many, así que incluye NMS en tu pipeline en el dispositivo

Conclusión#

La detección de extremo a extremo es el valor predeterminado en YOLO26 y no requiere cambios de código si utilizas la API de Python de Ultralytics o la CLI. Solo las tuberías de postprocesamiento personalizadas necesitan actualizarse para leer la nueva salida de (N, 300, 6) y omitir el paso de NMS, excepto para los formatos de exportación que recurren a la salida de uno a muchos (como NCNN y RKNN), los cuales siguen requiriendo NMS en el dispositivo. Para obtener pruebas comparativas detalladas de velocidad y precisión en todos los tamaños de modelo, consulta la página del modelo YOLO26, y para ver el conjunto completo de opciones y formatos de exportación, consulta la documentación del modo de exportación.

FAQ#