Классический детектор объектов выдаёт тысячи перекрывающихся кандидатов, а потом код-«уборщик» (NMS) оставляет лучшие рамки. На мощной видеокарте этот этап почти незаметен, а на маленьком CPU вроде Raspberry Pi или мини-ПК он добавляет и задержку, и лишний код. Семейство YOLO26 от Ultralytics ориентировано именно на такие случаи: оно предлагает режим без NMS и проще квантуется. Разберём, что изменилось и как это попробовать у себя.
Что нового в YOLO26
По описанию Ultralytics и обзору на LearnOpenCV, ключевые изменения такие:
- Без NMS. Одно-к-одному голова модели сразу предсказывает фиксированный набор рамок, поэтому постобработка не нужна. При необходимости можно вернуть классическую схему «один-ко-многим + NMS».
- Убрана DFL (Distribution Focal Loss). Регрессия рамок упрощена; по заявлению авторов, это делает модель устойчивее к квантованию INT8/FP16 без заметной потери точности.
- Новые приёмы обучения: оптимизатор MuSGD, прогрессивная балансировка потерь (ProgLoss) и назначение меток с упором на мелкие объекты (STAL).
- Много задач: детекция, сегментация, классификация, позы, OBB (повёрнутые рамки), а также открытый словарь YOLOE-26 с текстовыми подсказками.
Размеры моделей и скорость
Для детекции на COCO при входе 640 пикселей документация приводит такие цифры (скорость — ONNX на CPU, замер на серверном Intel Xeon, не на одноплатнике):
- YOLO26n — 40,9 mAP, около 38,9 мс на CPU, 2,4 млн параметров;
- YOLO26s — 48,6 mAP, около 87,2 мс, 9,5 млн параметров;
- YOLO26m — 53,1 mAP, около 220 мс, 20,4 млн параметров;
- YOLO26l — 55,0 mAP, около 286 мс; YOLO26x — 57,5 mAP, около 526 мс.
Авторы заявляют ускорение на CPU до 43% относительно YOLO11n. Это маркетинговая цифра для конкретного сервера: на вашем железе результат будет другим, поэтому всегда замеряйте сами. Для Raspberry Pi разумно начинать с версии n или s и небольшого разрешения.
Практика: запуск и экспорт
Установка и простой запуск (веса скачаются автоматически; обратите внимание на лицензию — у Ultralytics это AGPL-3.0 либо коммерческая «Enterprise»):
pip install ultralytics
from ultralytics import YOLO
model = YOLO("yolo26n.pt")
# по умолчанию используется голова «один-ко-многим» с NMS
results = model("bus.jpg")
# голова без NMS: до 300 рамок на кадр
results = model.predict("bus.jpg", nms=False)
Экспорт в ONNX для переносимого запуска. Параметр nms=False экспортирует вариант без постобработки:
from ultralytics import YOLO
model = YOLO("yolo26n.pt")
model.export(format="onnx", nms=False) # yolo26n.onnx
По документации, у головы без NMS выход имеет форму (N, 300, 6), а у обычной — (N, nc + 4, 8400) и требует NMS. Перед тем как писать свой разбор вывода (например, на OpenCV DNN или ONNX Runtime), посмотрите реальную форму и первую строку результата на вашей модели — так вы убедитесь в порядке полей и системе координат:
import numpy as np, onnxruntime as ort
sess = ort.InferenceSession("yolo26n.onnx", providers=["CPUExecutionProvider"])
name = sess.get_inputs()[0].name
x = np.zeros((1, 3, 640, 640), dtype=np.float32) # пустой кадр для проверки
out = sess.run(None, {name: x})[0]
print(out.shape) # ожидаем (1, 300, 6)
print(out[0, :3]) # первые строки: рамка, уверенность, класс
Дальше остаётся отфильтровать строки по порогу уверенности (например, 0,25–0,5) — и никакого NMS. Документация также называет поддерживаемыми форматами TensorRT, CoreML, LiteRT и OpenVINO, так что один и тот же вес можно перенести на разные платформы.
Как проверить, что переход оправдан: возьмите 100–200 типичных кадров со своей камеры, прогоните их через yolo26n и yolo26s в обоих режимах (с NMS и без) и сравните три вещи — среднее время на кадр, число ложных срабатываний и пропущенные объекты. Если камера смотрит на сцену с небольшим числом объектов, 300 рамок на кадр с запасом хватит, и режим без NMS окажется выгоднее. Для плотных сцен (толпа, склад с мелкими предметами) стоит оставить классическую голову и проверить, не ограничивает ли лимит в 300 рамок.
Что это даёт на практике
- Меньше кода: не нужно тащить реализацию NMS в собственный проект на C++, Python или микроконтроллере с хост-платой.
- Стабильнее задержка: время постобработки больше не зависит от числа перекрывающихся кандидатов в кадре.
- Квантование: по заявлению авторов, без DFL INT8 и FP16 переносятся лучше — это важно для мобильных и встраиваемых NPU.
- Оговорка: режим без NMS в документации описан как чуть менее точный (например, 40,1 против 40,9 mAP у версии n), а максимум — 300 рамок на кадр.
Выводы
YOLO26 — не революция, а аккуратная инженерная доработка в сторону периферийных устройств. Если вы запускаете детекцию на слабом CPU, имеете дело с квантованием или хотите упростить конвейер, стоит сравнить версии n и s в режимах с NMS и без него на своих данных и своём железе. Проверьте и лицензию: для закрытых коммерческих проектов AGPL-3.0 может потребовать отдельного соглашения.
Добавить комментарий