Отслеживание множества объектов в 2026 году – DeepSORT, ByteTrack, OC-SORT и трекеры, которые работают в рабочей системе

TL;DR

Отслеживание множества объектов (multi-object tracking, MOT) – задача сохранить один и тот же идентификатор за одним и тем же человеком, машиной или предметом на серии кадров видео. Это связующая нить между покадровым детектором объектов и любой функцией, которая должна рассуждать о траекториях. Почти каждая продакшен-система в 2026 году выбирает один из четырёх открытых трекеров: DeepSORT – классика 2017 года, которая ввела в обиход эмбеддинги внешнего вида; ByteTrack – «рабочая лошадка» 2022 года, работающая только с bounding box-ами и показавшая MOTA 80.3 на MOT17; OC-SORT – трекер 2023 года, использующий только моторику и исправляющий поведение ByteTrack на нелинейных траекториях; и BoT-SORT – трекер 2022/2023 года, добавляющий компенсацию движения камеры и эмбеддинги внешнего вида поверх ByteTrack и ставший дефолтным трекером в Ultralytics YOLO. Самое важное решение – не «какой алгоритм выбрать», а «насколько силён ваш детектор»: каждый современный трекер управляется детектором, и слабый детектор не спасёт никакая хитрая ассоциация. Эта статья проходит по конвейеру tracking-by-detection, четырём семействам трекеров, метрикам, которые реально стоит оптимизировать (HOTA, а не MOTA), и четырём типичным ошибкам, которые мы в Фора Софт переоткрываем заново на каждом проекте, где shipим трекинг в видеоконференции, видеонаблюдение, спортивную аналитику, ритейл и OTT-продукты.

Почему это важно

Если вашему видеопродукту нужно что-то посчитать, отследить или проанализировать – вам нужен трекер. Система видеонаблюдения, считающая людей у входа, должна отличать трёх разных людей, прошедших по одному разу, от одного человека, прошедшего трижды. Ритейл-аналитика, измеряющая время пребывания (dwell time), должна понимать, что покупатель у полки с хлопьями на 12-й секунде и тот же покупатель на 47-й – это один и тот же человек. Спортивная трансляция, накладывающая имена игроков на баскетбольную площадку, должна распознавать, что игрок в майке №23 в кадре 1 – это тот же самый игрок в кадре 1500, даже если он на полсекунды зашёл за спину №12. Интерфейс видеоконференции, подсвечивающий активного говорящего, должен удерживать рамку на нужном лице, когда два человека поменялись местами.

Все эти функции под капотом решают одну и ту же задачу – multi-object tracking (MOT), и все они одинаково страдают, если трекер ошибается. Технологии MOT существуют с 90-х, но выбор моделей, режимы сбоев, способы развёртывания и метрики оценки сильно изменились с 2022 года, а документация, с которой инженер начинает проект, как правило, отстаёт на три года.

Эта статья даёт актуальную картину 2026 года: какой трекер выбрать, почему ByteTrack и OC-SORT вытеснили DeepSORT из роли дефолтного решения, что измеряет HOTA там, где MOTA пропускала важные аспекты на протяжении десятилетий, и как избежать четырёх типичных ошибок в продакшене, из-за которых тонет большинство развёртываний.

Что такое multi-object tracking на самом деле

Видео – это последовательность кадров. Детектор объектов – YOLO, RT-DETR, Grounding DINO, тот, что вы выбрали в уроке об open-lexicon детекции – запускается на каждом кадре независимо и выдаёт список bounding box’ов, каждый со своим классом и confidence-скором. Детекции в кадре 1 и детекции в кадре 2 для детектора – это независимые объекты: он не помнит, что видел мгновением ранее. Трекер работает поверх детектора и объединяет покадровые детекции в траектории. У каждой траектории – стабильный track ID, небольшое целое число, означающее: «это тот же объект, что и на предыдущем кадре». Track ID – это как раз та связующая нить, которая превращает последовательность списков детекций в список траекторий, с которыми может работать downstream-код.

Зачем это нужно? Потому что почти ни одна полезная видеофункция не работает на покадровых детекциях без идентификаторов. Невозможно посчитать машины, пересекающие линию, без устойчивых ID – каждая машина была бы учтена десятки раз, попадая в несколько кадров. Невозможно оценить теннисную подачу без устойчивых ID – неясно, какая детекция принадлежит подающему, а какая – принимающему. Невозможно зафиксировать драку в потоке CCTV без устойчивых ID – правило «одни и те же два человека находились в метре друг от друга более двух секунд» работает только при сохранении идентичности. Любая видеофункция ИИ, связанная с движением, ожиданием, подсчётом, хореографией или взаимодействием, – это downstream-трекер.

Задача на первый взгляд проста – сопоставить боксы в одном кадре t с боксами в следующем кадре t+1, – но быстро усложняется. Объекты закрывают друг друга; модель ошибается на отдельных кадрах; объекты движутся неравномерно; камера смещается; два похожих объекта обмениваются идентификаторами; один объект распадается на две детекции; две детекции одного объекта сливаются. История MOT – это в основном история того, как становиться устойчивее ко всему перечисленному.

Нажмите, чтобы увеличить

Tracking-by-detection – конвейер, который победил

К 2022 году почти каждый значимый опубликованный трекер пришёл к одному и тому же базовому решению – tracking-by-detection. Конвейер состоит из четырёх этапов, и почти каждый современный трекер отличается лишь выбором компонентов на каждом из них.

Первый этап – детекция. Современный детектор выдаёт по одному bounding box на объект на кадр, с указанием класса и confidence-скора. Качество детектора оказывает решающее влияние на всё последующее: трекер, построенный на детекторе с recall 95%, и трекер на детекторе с recall 80% работают в принципиально разных условиях, и разрыв между ними значительно превосходит любой выигрыш, который можно получить за счёт улучшений в алгоритме ассоциации. Именно поэтому каждая статья после 2022 года приводит результаты трекера, работающего с фиксированным публичным детектором (часто YOLOX-X или сопоставимой моделью) – чтобы сравнение отражало качество самого трекера, а не детектора.

Второй этап – предсказание движения. Для каждого существующего трека трекер предсказывает, где окажется объект в следующем кадре, на основе истории его движения. Каноническим инструментом для этого является фильтр Калмана – алгоритм 1960 года, который моделирует состояние объекта (обычно (x, y, aspect_ratio, height, dx, dy, dh, dr)) как гауссиан с обновляемыми на каждом кадре средним и ковариацией в рамках модели постоянной скорости. Современные трекеры используют фильтр Калмана или его близкие аналоги; различия между ними заключаются в выборе вектора состояния и параметров шума, а не в самом алгоритме.

Третий этап – ассоциация. На основе предсказанных позиций треков и новых детекций трекер вычисляет матрицу стоимости для каждой пары «существующий трек – новая детекция» и решает задачу о назначении. Стоимость может быть геометрической (IoU между предсказанным боксом и боксом детекции), внешней (косинусное расстояние между глубокими признаками двух боксов) или представлять собой взвешенную комбинацию этих метрик. Задачу решает алгоритм Венгерского метода (Kuhn, 1955), находящий оптимальное однозначное соответствие за O(n³) и выполняющийся за микросекунды на масштабах, характерных для задач трекинга.

Четвёртый этап – управление жизненным циклом треков. Новые детекции, не привязанные к существующим трекам, становятся новыми треками. Существующие треки, не нашедшие совпадений, помечаются как неподтверждённые и после нескольких кадров неподтверждённости удаляются. Только что созданные треки обычно помечаются как tentative и должны пройти несколько кадров стабильной детекции, прежде чем стать confirmed. Параметры жизненного цикла – порог появления, порог исчезновения, максимальное количество кадров неподтверждённости – настройки, которые имеют гораздо большее значение, чем принято считать.

Каждый трекер ниже – это иной выбор внутри этого четырёхэтапного скелета. ByteTrack изменяет порог детекции на третьем этапе. OC-SORT корректирует поведение фильтра Калмана после пропущенной детекции. DeepSORT добавляет глубокие признаки внешнего вида в матрицу стоимости. BoT-SORT включает компенсацию движения камеры в фильтр Калмана и эмбеддинги в матрицу стоимости. Скелет остаётся прежним – меняются только «мышцы».

Четыре семейства трекеров, важных в 2026 году

Любое продакшен-развёртывание в 2026 году выбирает одно из четырёх открытых семейств. Рассмотрим их в хронологическом порядке – каждое следующее решало проблему, унаследованную от предыдущего.

DeepSORT – классика 2017 года, давшая эмбеддинги внешнего вида

DeepSORT был опубликован в 2017 году Николаем Вёйке, Алексом Бьюли и Дитрихом Паулюсом как расширение SORT (2016). Сам SORT – Simple Online and Realtime Tracking – уже представлял собой хорошую основу: фильтр Калмана для предсказания движения, расстояние IoU для ассоциации и венгерский алгоритм для сопоставления. Он работал на сотнях кадров в секунду на CPU, но терял идентичность объектов при перекрытиях, поскольку опирался только на геометрию. Вклад DeepSORT заключается в добавлении второй матрицы стоимости поверх IoU – косинусного расстояния между глубокими свёрточными признаками внешнего вида детекций и галереями признаков каждого трека. Эти признаки извлекала небольшая CNN, обученная на задаче person re-identification на датасете MARS. В результате получился первый трекер, способный сохранять идентичность объектов при коротких перекрытиях, и он доминировал в научной литературе в течение следующих четырёх лет.

Показатели DeepSORT на MOT17 – стандартном бенчмарке для отслеживания пешеходов – составляют 60,3 MOTA, 61,2 IDF1 и 48,8 HOTA при использовании сильного детектора YOLOX-X. Эти цифры приведены в современной форме (метрика HOTA была опубликована в 2020 году); сама метрика тогда ещё не существовала, но ретроспективная оценка – так сейчас сравнивают результаты в этой области.

В 2026 году у DeepSORT две практические роли. Первая – это трекер, который использует каждый учебник и к которому первым тянется junior-инженер. Вторая – паттерн appearance-features, который он ввёл, стал фундаментом для BoT-SORT, StrongSORT и Deep OC-SORT. Однако оригинальный DeepSORT больше не является дефолтным выбором для новых проектов: трекеры 2022 года превосходят его по всем метрикам и при этом не менее просты в развёртывании.

ByteTrack – рабочая лошадка 2022 года в задачах детекции

ByteTrack был представлен на ECCV 2022 Ифу Чжаном и коллегами. Это одна из самых влиятельных работ в области tracking-by-detection после DeepSORT. Вклад может показаться незначительным: достаточно ассоциировать не только уверенные, но и все детекции.

Каждый предыдущий трекер отбрасывал детекции с уровнем уверенности ниже порога (обычно 0.5) до этапа ассоциации. Наблюдение ByteTrack: детекции с низкой уверенностью – это, как правило, всё ещё реальные объекты, которые детектор «увидел едва заметно» из-за частичного перекрытия, размытия движения или необычной позы. Отбрасывание таких детекций приводит к потере именно тех боксов, которые трекеру необходимы для сохранения идентичности при перекрытии.

Процедура ByteTrack: сначала высокоуверенные детекции сопоставляются с существующими треками по IoU; затем несопоставленные треки пытаются сопоставить с низкоуверенными детекциями – снова по IoU. Высокоуверенные детекции без совпадений становятся новыми треками; низкоуверенные без совпадений отбрасываются.

Полный алгоритм – меньше пятидесяти строк на Python. Никаких признаков внешнего вида, никакой глубокой нейросети, кроме самого детектора, никаких обучаемых компонентов. Просто меняется порядок использования детекций. Результат на MOT17: 80,3 MOTA, 77,3 IDF1, 63,1 HOTA – превзошёл все предыдущие трекеры, включая DeepSORT, всех предшественников BoT-SORT и весь класс трекеров с appearance-эмбеддингами. Урок: детектор всё это время выполнял основную работу, а умный каскад по confidence улавливал большую часть оставшейся ценности.

ByteTrack – хороший выбор по умолчанию для любого проекта, где детектор работает хорошо, объекты не сильно меняют свой внешний вид, а камера не совершает резких движений. Он примерно вдвое быстрее DeepSORT (поскольку не использует feature-extractor) и в 3–5 раз быстрее BoT-SORT. Реализация по умолчанию – github.com/ifzhang/ByteTrack под лицензией MIT, и она интегрирована в Ultralytics YOLO в виде bytetrack.yaml.

OC-SORT – трекер 2023 года, исправляющий нелинейные траектории

OC-SORT – Observation-Centric SORT – был представлен на CVPR 2023 Цзинкуном Цао и коллегами. В статье описывается конкретный режим отказа любого трекера на основе фильтра Калмана, включая ByteTrack: после нескольких кадров перекрытия предсказанная фильтром Калмана позиция начинает дрейфовать, поскольку он продолжает использовать предположение о постоянной скорости, пока не поступят новые наблюдения для коррекции. Когда объект вновь становится видимым и трекер должен его идентифицировать, предсказанная позиция уже сильно отклоняется от реальной, и сопоставление оказывается неудачным.

Решение OC-SORT – observation-centric re-update. Когда потерянный трек снова ассоциируется с детекцией после k кадров пропуска, трекер не просто обновляет фильтр Калмана новым наблюдением. Он возвращается, восстанавливает траекторию между последним и новым наблюдениями, используя оба конца, и переобновляет фильтр так, будто всё это время получал согласованные наблюдения. Состояние в момент повторной ассоциации определяется на основе двух реальных концов разрыва, а не на основе дрейфующего предсказания. В статье также добавлен компонент observation-centric momentum, использующий направление недавних наблюдений непосредственно в матрице стоимости.

Цифры OC-SORT на MOT17 – 78,0 MOTA, 77,5 IDF1, 63,2 HOTA – находятся на уровне ByteTrack по основным метрикам, но относительный прирост значительно выше на бенчмарках с нелинейным движением. На DanceTrack, где присутствуют акробатика и танец, нарушающие предположение о постоянной скорости, OC-SORT опережает ByteTrack более чем на десять пунктов по HOTA. Результат на DanceTrack особенно важен для любых продуктов, связанных с нелинейным движением: танцевальные уроки, гимнастика, паркур, дрон-съёмка, отслеживание животных, а также всё, что в спортивной трансляции связано со сменой направления.

OC-SORT также не использует признаки внешнего вида. Как и ByteTrack, он управляется детектором и работает с той же скоростью, что и сам детектор. Реализация по умолчанию – github.com/noahcao/OC_SORT – доступна под лицензией MIT. Deep OC-SORT, расширение 2023 года от Маджолино и коллег, добавляет адаптивный признак внешнего вида и достигает 64,9 HOTA на MOT17 – долгое время это был лучший опубликованный результат (SOTA).

BoT-SORT – трекер 2022 года, ставший стандартным в Ultralytics

BoT-SORT был опубликован в 2022 году Ниром Ахароном, Роем Орфайгом и Бен-Ционом Бобровским. По словам авторов, это «более сильный SORT» – он построен на той же основе, что и ByteTrack, но включает два улучшения. Первое – camera-motion compensation: перед применением модели Калмана трекер оценивает, как изменилась позиция камеры между кадрами (с помощью разреженного оптического потока и алгоритма выравнивания изображений ECC), и корректирует предсказанное состояние с учётом этого смещения. Именно этот шаг позволяет BoT-SORT эффективно работать на съёмках с рук и с дронов, где предположение о постоянной скорости нарушается не из-за движения объектов, а из-за движения самой камеры относительно них. Второе улучшение – appearance embeddings: в варианте BoT-SORT-ReID добавляется экстрактор признаков для повторной идентификации (BoT-ResNet50, обученный на стандартных датасетах person Re-ID), а также вводится стоимость по внешнему виду при ассоциации объектов.

Цифры BoT-SORT на MOT17 – 80,5 MOTA, 80,2 IDF1, 65,0 HOTA – на момент публикации являются лучшими по всем трём основным метрикам. Реализация по умолчанию – github.com/NirAharon/BoT-SORT, доступна под лицензией MIT. Гораздо важнее для команд, работающих в продакшене: с 2024 года BoT-SORT стал трекером по умолчанию в Ultralytics YOLO, его конфигурация находится в ultralytics/cfg/trackers/botsort.yaml. Если вы вызываете model.track() на моделях Ultralytics без указания трекера – запускается BoT-SORT. Сообщество выбрало BoT-SORT-ReID в качестве стандартного решения для отслеживания пешеходов и транспортных средств общего назначения.

Цена – производительность. BoT-SORT-ReID примерно на 30 процентов медленнее ByteTrack из-за использования feature-экстрактора и оценки движения камеры. Для большинства продакшен-развёртываний эта дополнительная нагрузка допустима – отслеживание пешеходов и транспортных средств в одиночном потоке на современном CPU всё ещё работает со скоростью 30+ кадров в секунду, – но в плотных сценах или при обработке множества потоков одновременно накладные расходы накапливаются.

Нажмите, чтобы увеличить

Метрики, которые на самом деле важны – MOTA, IDF1 и почему HOTA пришла на смену

Десятилетие сообщество ранжировало трекеры по MOTA – Multiple Object Tracking Accuracy. Мету MOTA ввели в 2008 году Бернардин и Штифельхаген как одну величину, объединяющую ложные срабатывания, пропуски объектов и ошибки идентификации. Метрика оказалась достаточно эффективной, чтобы стать ключевой на MOTChallenge – ведущем бенчмарке для отслеживания пешеходов, – и тем показателем, который всегда значился в заголовке каждой статьи о трекерах с 2008 по 2020 год.

У MOTA был известный недостаток: она сильно смещена в сторону качества детекции. Трекер, идеально детектирующий объекты, но постоянно путающий идентификаторы при перекрытии, мог бы набрать почти такой же балл, как и трекер, никогда не ошибающийся с ID – потому что компонент identity-switch в формуле MOTA незначителен по сравнению с компонентами ложных срабатываний и пропусков. Сообщество отреагировало, введя IDF1 – F1-меру по идентичности, которая гораздо жёстче наказывает ошибки сопоставления ID. IDF1 – подходящая метрика для задач, где идентичность имеет критическое значение (multi-target re-identification, трекинг конкретного человека), но она перешла в другую крайность: игнорировала качество детекции.

Развязка наступила в 2020 году с появлением HOTA – Higher Order Tracking Accuracy, предложенной Джонатоном Луйтеном и коллегами. HOTA представляет собой сбалансированную комбинацию detection score (DetA – насколько хорошо трекер вообще обнаруживает объекты) и association score (AssA – насколько точно он сохраняет идентичность между детекциями одного и того же ground-truth объекта). Эти две составляющие объединяются геометрически: HOTA вычисляется как корень из произведения DetA × AssA, – поэтому трекер, сильный в одном аспекте, но слабый в другом, получает штраф. Кроме того, HOTA отдельно вычисляет и выводит два промежуточных показателя, что позволяет автору статьи чётко показать, по какому направлению – обнаружению или ассоциации – новый трекер продемонстрировал прогресс.

К 2026 году HOTA стала основной метрикой, по которой оценивается работа трекеров. MOTA по-прежнему фигурирует в каждой таблице, но лидерборды MOTChallenge, DanceTrack и SportsMOT ранжируют трекеры исключительно по HOTA. Если вы хотите выбрать одну цифру для сравнения – смотрите на HOTA.

Цифры с лидерборда MOTChallenge (MOT17 test set, private detection) для четырёх рассмотренных трекеров:

Цифры подтверждают сказанное выше: ByteTrack и OC-SORT практически идентичны на MOT17; BoT-SORT-ReID – на шаг впереди; DeepSORT остаётся исторической базой. На DanceTrack картина иная – OC-SORT опережает ByteTrack более чем на десять пунктов по HOTA. На SportsMOT наибольшую роль играют appearance-features в BoT-SORT-ReID. Правильный трекер зависит от данных, а не от позиции в лидерборде.

Выбор подходящего трекера – пошаговый разбор

Вот дерево решений, которое мы в Фора Софт используем, когда проект запрашивает фичу трекинга. Четыре вопроса.

Первый вопрос: движется ли камера? Если камера установлена на телефоне, дроне, body-камере, видеорегистраторе или любом другом подвижном устройстве, фильтр Калмана с моделью постоянной скорости, используемый в ядре ByteTrack и OC-SORT, будет накапливать ошибку, поскольку прогнозы строятся в координатах изображения, а не реального мира. Компенсация движения камеры в BoT-SORT – это решение проблемы. Выбирайте BoT-SORT для любой подвижной камеры.

Второй вопрос: нарушает ли движение предположение о постоянной скорости? Танцы, гимнастика, паркур, движение животных, быстрый спорт – всё, где объекты резко меняют направление, ломает работу предсказания Калмана. Observation-centric re-update в OC-SORT – это решение. Используйте OC-SORT для танцев, спорта, animal-tracking и любых сцен с резкими сменами направления.

Третий вопрос: сколько одновременных потоков и насколько плотна сцена? Трекеры на основе внешнего вида (BoT-SORT-ReID, Deep OC-SORT, StrongSORT) извлекают глубокий признак для каждой детекции на каждом кадре. На CPU это становится основной нагрузкой – BoT-SORT-ReID при шестнадцати потоках 1080p полностью загружает сервер. Если бюджет предполагает «много потоков, скромное железо» – выбирайте ByteTrack: он не использует анализ внешнего вида, работает с той же скоростью, что и детектор, и отлично подходит для плотной retail-аналитики и масштабного видеонаблюдения.

Четвёртый вопрос: насколько важно сохранение идентичности при длительных перекрытиях? Если приложение допускает короткие потери идентификатора (подсчёт машин, время пребывания, плотность толпы), то подойдут трекеры, основанные только на движении (ByteTrack, OC-SORT). Если же идентичность должна сохраняться более пяти секунд при перекрытиях (трекинг объекта интереса, спортивная аналитика, передача между камерами) – необходимы трекеры, использующие признаки внешнего вида (BoT-SORT-ReID, Deep OC-SORT, StrongSORT). Для надёжного сохранения идентичности при длительных перекрытиях выбирайте BoT-SORT-ReID.

По нашему опыту, восемьдесят процентов проектов выбирают ByteTrack (быстрый, простой, надёжный) или BoT-SORT-ReID (немного медленнее, но точнее – это дефолтное решение в Ultralytics). OC-SORT – особый случай. DeepSORT в 2026 году редко оказывается лучшим выбором: каждая задача, где он раньше хорошо работал, теперь решается лучше одним из трёх перечисленных.

Численный пример – стоимость трекинга на видео 1280 × 720 при 30 кадрах в секунду

Считаем для одного потока на современном Intel-серверном CPU, с детектором YOLOv8-S и двадцатью пешеходами в кадре.

YOLOv8-S детекция (вход 640 × 640, 20 детекций): ~14 миллисекунд на кадр. ByteTrack ассоциация (20 детекций, 20 активных треков): ~0,4 мс на кадр. BoT-SORT-ReID извлечение внешних признаков (BoT-S50, 20 кропов): ~18 мс на кадр. BoT-SORT-ReID ассоциация: ~0,6 мс на кадр.

Итоги пайплайна на кадр: ByteTrack: 14 + 0,4 = 14,4 мс на кадр. BoT-SORT-ReID: 14 + 18 + 0,6 = 32,6 мс на кадр.

Кратко: ByteTrack – 432 мс на CPU, BoT-SORT-ReID – 978 мс на CPU.

Один поток ByteTrack использует около 43 % одного ядра, а один поток BoT-SORT-ReID – почти всё ядро. На шестнадцатиядерном сервере это позволяет запустить тридцать пять одновременных потоков ByteTrack или шестнадцать потоков BoT-SORT-ReID. Разница напрямую отражается на облачном счёте: при тарифах AWS c7i.4xlarge (16 vCPU, ~$0.71/час по on-demand), стоимость одного потока ByteTrack составляет около $0.020 в час, а BoT-SORT-ReID – около $0.044 в час. Абсолютные значения невелики, но при масштабе в тысячи камер разница в стоимости становится существенной.

Если нужно больше потоков на сервере, правильным решением будет не «перейти на лёгкий трекер», а снизить частоту кадров трекинга. Большинство функций трекинга (подсчёт, время пребывания, обнаружение падений) отлично работают при 10 fps. Запуск трекера на каждом третьем кадре с интерполяцией ID между ними снижает нагрузку в 3 раза практически без потери точности.

Где запускать – браузер, edge или сервер

Решение о топологии развёртывания применяется к трекерам так же, как и к моделям поз в уроке об отслеживании позы. Одну и ту же модель можно развернуть в трёх разных местах – с совершенно разными компромиссами.

В браузере трекер работает внутри вкладки пользователя в WebAssembly. Ни у одного из четырёх рассматриваемых трекеров нет first-party браузерной реализации, но ByteTrack и OC-SORT – motion-only и компактные – портированы на JavaScript и ONNX Runtime Web. Подходит для browser-based жестовых и эргономических фич. BoT-SORT-ReID с appearance-features в 2026 году слишком тяжёл для типичных браузерных бюджетов.

На edge трекер работает на компактном устройстве рядом с камерой – например, NVIDIA Jetson Orin Nano, Intel NUC или Hailo-8L AI-ускоритель. Все четыре трекера легко размещаются на Jetson Orin Nano вместе с детектором YOLOv8-S. ByteTrack – оптимальный выбор по пропускной способности (больше потоков на устройство). BoT-SORT-ReID – выбор по точности (один-два потока, но с более высокой идентификацией). Edge – стандартный вариант для ИИ-камер безопасности, интеллектуального анализа видео, ритейла и промышленного компьютерного зрения.

На сервере трекер работает в облаке рядом с детектором. RT-DETR или YOLOv11 на GPU в паре с ByteTrack или BoT-SORT-ReID на CPU – проверенная схема. Задержка складывается из сетевого round-trip (обычно 30–100 мс) и времени инференса. Серверный режим – стандартная конфигурация для платформ спортивной аналитики, broadcast contribution, обработки записанного материала пакетами и любых функций, которым требуются самые мощные детекторы.

Выбор между тремя вариантами обычно не очевиден. Use case определяет топологию, а топология – трекер.

Нажмите, чтобы увеличить

Четыре продакшен-ошибки, которые топят фичи трекинга

В Фора Софт мы внедрили множество трекинг-фич в видеопродукты. Четыре режима отказа регулярно повторяются. Они не являются новыми – каждую команду ждёт их «переоткрытие», – но стоимость этого переоткрытия высока, поэтому стоит назвать их вслух.

Первая ошибка – обвинять трекер в том, что на самом деле проблема детектора. Когда трекер теряет идентичности или ошибается в подсчёте, возникает соблазн поменять трекер. Но обычно проблема не в нём, а в детекторе. YOLOv8-N, обученный на COCO, пропустит большинство мелких пешеходов на разрешении 1080p, и ни один трекер не сможет восстановить идентичность через пропущенные детекции. Всегда начинайте с анализа детектора: если recall на ваших данных ниже девяноста процентов, исправляйте детектор, прежде чем трогать трекер. Переход с ByteTrack на BoT-SORT-ReID добавит пару пунктов HOTA; переход с YOLOv8-N на YOLOv8-X – десять.

Вторая ошибка – использование DeepSORT в 2026 году. DeepSORT был актуален в 2018-м. Сейчас – редко. Каждая задача, где он раньше показывал хорошие результаты, теперь решается лучше: быстрее и точнее – через ByteTrack, или точнее и с такой же простотой внедрения – через BoT-SORT-ReID. Причина, по которой DeepSORT до сих пор жив, – туториалы, которые junior-разработчики находят на первых проектах, как правило, трёхлетние. Стандартом для новых проектов стал ByteTrack; если требуются appearance-features – дефолтный выбор – BoT-SORT-ReID. За последние два года мы переписали пайплайны с DeepSORT на ByteTrack для трёх клиентов, и каждый раз это был чистый апгрейд по latency, throughput и HOTA одновременно.

Третья ошибка – оставить гиперпараметры фильтра Калмана и lifecycle по умолчанию на данных, для которых трекер не настроен. Каждый рассмотренный трекер опубликован с гиперпараметрами, подстроенными под MOT17: пешеходы, преимущественно прямолинейное движение, хорошее освещение, статичные камеры. Применяя эту конфигурацию к дрон-съёмке спорта или к видеонаблюдению за автомобилями на шоссе, вы получаете неверные шумовые члены в фильтре Калмана, неподходящий порог max-unconfirmed-frames и неправильный порог appearance-threshold. Лечение – настройка. Конкретно: track_buffer (насколько долго потерянный трек остаётся активным на случай возвращения) и match_thresh (порог IoU для второго прохода ассоциации) – два параметра, влияющих больше всего. Мы традиционно проводим grid-поиск по ним на отдельной записи из реального развёртывания перед релизом.

Четвёртая ошибка – доверять track ID на стыке камер. Track ID локален для одной камеры и одного запуска трекера. Тот же человек, переходящий с камеры A на камеру B, получит разные ID от двух трекеров, и никакая хитрость single-camera-трекинга эту проблему не решит. Cross-camera identity – это отдельная задача, person re-identification или multi-camera multi-target tracking, – она требует отдельной Re-ID модели, общей feature-галереи и глобального графового решателя. Мы рассмотрим cross-камеры в следующем уроке; пока – если ваше приложение работает с несколькими камерами, не предполагайте, что single-камера трекер с этим справится.

Нажмите, чтобы увеличить

Где здесь Фора Софт

Мы в Фора Софт разделили трекинг на полдюжины категорий продуктов. В видеоконференциях используем лёгкий ByteTrack на стороне SFU для поддержания стабильных ID участников, которые меняют ракурс камеры в ходе звонка – эти ID подают данные в downstream-функции, такие как определение активного говорящего и автоматическое составление резюме встреч. В ритейле и intelligent video analytics применяем BoT-SORT-ReID на edge-устройствах Jetson для анализа времени пребывания, длины очередей и выявления отсутствия товара на полках – здесь важна визуальная информация, поскольку покупатели часто заслоняют друг друга, а модель внешнего вида устраняет неоднозначность идентификации. В OTT и broadcast contribution используем BoT-SORT-ReID на облачных GPU для спортивных оверлеев и трекинг-дэшбордов игроков, где перекрытия более продолжительные, а требования к точности выше. В e-learning применяем ByteTrack для отслеживания нескольких студентов в записи урока, передавая их траектории в функции мониторинга внимания. В системах видеонаблюдения и безопасности используем BoT-SORT-ReID для детекции падений, драк и несанкционированных проникновений: признаки внешнего вида позволяют сохранять идентичность объекта при длительных перекрытиях на статичной камере. На каждом проекте трекер – это решение номер два; решения нулевое и первое – детектор и топология.

Ключевые выводы

• Tracking-by-detection – доминирующая парадигма: все современные трекеры построены по одному и тому же принципу, но с разными «мышцами».
• ByteTrack – стандарт 2026 года: быстрый, простой, работает только на движении, с лицензией MIT.
• BoT-SORT-ReID – выбор по точности и стандарт Ultralytics в 2024–2026 годах.
• OC-SORT – оптимален для нелинейного движения (танцы, спорт, животные).
• DeepSORT – историческая основа; не рекомендуется для новых проектов.
• HOTA, а не MOTA – метрика для оптимизации: она уравновешивает качество детекции и ассоциации.
• Качество трекера напрямую зависит от качества детектора; начните с улучшения детектора.

Что читать дальше

• YOLO в продакшене – v8, v9, v10, v11, v12 – детектор, питающий трекер.
• OpenPose, MediaPipe Pose, RTMPose, ViTPose – стек отслеживания позы для видео в 2026 – пайплайн распознавания позы, использующий ByteTrack на третьем этапе.
• Latency, развёртывание и real-time vs batch – фреймворк выбора топологии, который мы применяем.