Детектор, трекер и сегментер реального времени на Jetson Orin

Кратко

Этот итоговый проект соединяет всё, чему учила глава 2, в одну работающую систему: маленький компьютер стоит рядом с камерой и в реальном времени рисует рамку вокруг каждого объекта, который видит, даёт каждому объекту устойчивую идентичность и удерживает её кадр за кадром, а затем обводит пиксельно точным контуром те объекты, которые важны. Компьютер – это NVIDIA Jetson Orin, плата размером с банковскую карту, которая выдаёт от 67 до 275 триллионов ИИ-операций в секунду, потребляя меньше энергии, чем настольная лампа, а три задачи ложатся на детектор (YOLO), трекер (ByteTrack) и облегчённую версию SAM 2 в роли сегментера. Сложность не в одной модели, а в том, чтобы все три делили один поток кадров внутри жёсткого временного бюджета, поэтому вторая иллюстрация статьи – диаграмма бюджета кадра – объясняет почти всё. Попутно мы показываем реальность Track B в 2026 году: как ИИ-ассистенты для кода вроде Cursor и новые DeepStream coding agents действительно ускоряют эту работу – и где именно они по-прежнему оставляют тяжёлую инженерию вам.

Почему Это Важно

Статья написана для продакт-менеджера, оценивающего функцию для видеонаблюдения, ритейла или робототехники, которому нужно понять, правда ли, что «всё это работает на одной дешёвой коробке рядом с камерой»; для основателя, взвешивающего edge-сборку против облачной подписки; и для инженера, который прочитал отдельные уроки главы 2 и хочет увидеть их собранными в развёртываемое целое. Она предполагает, что вы прочитали урок 2.2 о линейке детекторов YOLO, урок 2.8 о трекинге множества объектов и урок 2.4 о SAM 2 для видео, потому что этот итоговый проект соединяет их в один конвейер, а не выводит заново. К концу вы сможете объяснить четыре части edge-системы зрения, поставить обоснованные цифры по частоте кадров и энергопотреблению на реальную установку Jetson и отличить заявления об ИИ-ассистированной разработке, которые выдерживают проверку, от тех, что нет.

Что Такое «Real-Time На Edge» На Самом Деле

Прежде чем браться за модели, зафиксируем два слова, которые движут каждым решением в статье: «edge» и «real-time».

«Edge» – это противоположность «облака». Облачная система отправляет видео с камеры через интернет в дата-центр с мощными компьютерами, получает ответ и действует на нём. Edge-система думает на маленьком компьютере, который стоит прямо рядом с камерой – в той же комнате, часто в том же корпусе. Видео не покидает здание. Представьте разницу между тем, чтобы отправить фотографию эксперту по почте и ждать пометок, и тем, чтобы эксперт стоял у вас за плечом. Эксперт у плеча отвечает быстрее, не зависит от почты и не выпускает фотографию из рук. Эти три преимущества – меньшая задержка, отсутствие зависимости от сети и приватность – и есть причина, по которой столько видеопродуктов переносят свой ИИ на edge.

«Real-time» имеет здесь точное значение, и это не «быстро». Камера выдаёт свежую картинку, называемую кадром, в фиксированном ритме – 30 кадров в секунду – обычная частота для видеонаблюдения и конференций. Real-time означает, что система заканчивает всю обработку одного кадра до того, как придёт следующий. При 30 кадрах в секунду новый кадр приходит каждые 33 миллисекунды (одна секунда ÷ 30 кадров = 0,033 секунды = 33 мс). Значит, у всего конвейера – детекция, трекинг, сегментация и отрисовка – есть бюджет в 33 миллисекунды на кадр. Выйдите за бюджет – и кадры начнут накапливаться быстрее, чем вы их обрабатываете; система отстаёт, и живая картинка превращается в слайд-шоу. Вся инженерная задача этого итогового проекта – удержаться внутри конверта в 33 мс на компьютере размером со стопку визиток.

Полезный образ: бюджет кадра – это конвейерная лента с фиксированной скоростью. Каждые 33 миллисекунды приходит деталь. У вас ровно столько времени, чтобы осмотреть её, разметить и передать дальше. Нельзя попросить ленту замедлиться и нельзя позволить деталям накапливаться. Всё ниже – о том, как разместить трёх контролёров – детектор, трекер и сегментер – на одной ленте так, чтобы никто не отстал.

Четыре Части Edge-Системы Зрения

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

Первая часть – детектор: модель, которая смотрит на один кадр и рисует рамку, называемую ограничивающей рамкой (bounding box), вокруг каждого распознанного объекта, прикрепляя метку («человек», «автомобиль», «посылка») и оценку уверенности от 0 до 1. Детектор – это глаза. В продакшене это почти всегда член семейства YOLO, подробно разобранного в уроке 2.2. YOLO – название расшифровывается как «You Only Look Once», «смотришь только один раз» – заслужил своё место на edge тем, что видит весь кадр за один проход, а не сканирует его по кусочкам, и это делает его достаточно быстрым, чтобы укладываться в бюджет кадра.

Вторая часть – трекер: детекция сама по себе даёт рамку в кадре 1 и рамку в кадре 2, но не знает, что это один и тот же человек. Трекер присваивает каждому обнаруженному объекту устойчивый номер-идентификатор и ведёт его сквозь кадры, чтобы система могла рассуждать о траектории, времени пребывания или направлении движения. Трекер – это память. Продакшен-трекеры – ByteTrack, DeepSORT, OC-SORT – тема урока 2.8. Мы используем здесь ByteTrack по причине, к которой ещё вернёмся: он почти бесплатен по вычислительной стоимости, а это огромно важно, когда бюджет – 33 миллисекунды.

Третья часть – сегментер: рамка говорит, где примерно объект; сегмент говорит точно, какие пиксели ему принадлежат, обводя его истинный контур. Сегментер – это инструмент точности. Вы не запускаете его на всём – это мгновенно сорвало бы бюджет – вы запускаете его только на тех немногих объектах, что важны правилу. Наш сегментер – облегчённая, ускоренная версия SAM 2, модели из урока 2.4. «Облегчённая» (distilled) означает маленькую модель, обученную копировать большую; почему это обязательно на edge – ниже.

Четвёртая часть – оркестратор: связующий код, который тянет кадры с камеры, передаёт каждый кадр трём моделям в правильном порядке, применяет бизнес-правила и рисует результат. Оркестратор – это сама конвейерная лента. Он неэффектен, и именно в нём большинство реальных проектов теряют свой временной бюджет, потому что модель, работающая 20 миллисекунд на бенчмарке, может работать 40 в плохо собранном конвейере, который копирует кадр туда-сюда между главным процессором и графическим чипом. Большая часть второй половины статьи – об оркестраторе, потому что три модели – лёгкая часть.

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

Знакомство С Железом: Семейство Jetson Orin

Плата, делающая всю эту работу, – NVIDIA Jetson Orin. Это маленький компьютер, построенный вокруг графического процессора – того же типа чипа, что отрисовывает видеоигры, – потому что математика ИИ-зрения и есть та математика, для которой создавались графические чипы: одна и та же простая операция, применённая к миллионам пикселей сразу. Jetson упаковывает эту способность в модуль, достаточно маленький, чтобы поместиться внутри корпуса камеры, и достаточно экономный, чтобы работать на энергии одной яркой лампочки.

Семейство выпускается в нескольких ступенях, и выбранная ступень решает, сколько из четырёх частей вы можете запустить одновременно и с какой частотой кадров. Цифры ниже – собственные опубликованные спецификации NVIDIA на 2026 год, после того как обновление JetPack 6.2 разблокировало более быстрый «Super Mode» на младших платах.

Самый маленький, Jetson Orin Nano 8GB (Super Mode), выдаёт 67 триллионов операций в секунду – записывается 67 TOPS, где TOPS – это триллион операций в секунду – используя 1024 графических ядра на частоте 1020 мегагерц, с пропускной способностью памяти 102 гигабайта в секунду, всё в пределах бюджета мощности, который можно задать на 7, 15 или 25 ватт. Для сравнения, 25 ватт – это примерно потребление зарядки для ноутбука. Средний Jetson Orin NX 16GB (Super Mode) достигает 157 TOPS в том же физическом форм-факторе, настраиваемый вплоть до режима 40 ватт. Вершина встраиваемой линейки, Jetson AGX Orin 64GB, выдаёт 275 TOPS при мощности до 60 ватт, а новейший модуль Jetson AGX Thor доходит до 800 TOPS для робототехнических задач, которым нужно одновременно держать несколько больших моделей. NVIDIA обязалась производить модули Orin до 2032 года, что важно для любого продукта, которому предстоит годами оставаться в эксплуатации.

Вот практический вывод с показанной арифметикой. Детектор YOLO, достаточно маленький для real-time, требует порядка нескольких TOPS устойчивой производительности, чтобы держать 30 кадров в секунду. У Orin Nano с 67 TOPS, следовательно, комфортный запас для одного детектора и трекера на одной камере и ровно столько, чтобы остался запас на эпизодический вызов сегментации. Orin NX с 157 TOPS – более чем вдвое больше – естественный дом для многокамерной сборки или системы, сегментирующей агрессивнее. Цифра TOPS – это не обещание частоты кадров; это потолок. Что вы получите на деле, зависит от модели, точности вычислений и качества оркестратора – об этом вся остальная статья.

Таблица 1. Семейство Jetson Orin в 2026 году. Колонка «подходит для» – эмпирическое правило для нагрузки «детектор + трекер + эпизодический сегментер», как в этом итоговом проекте; ваши реальные цифры зависят от размера модели, точности и качества конвейера. Источник: спецификации модулей NVIDIA Jetson и бенчмарки JetPack 6.2 Super Mode.

Один Шаг, Который Заставляет Всё Влезть: TensorRT И Квантизация

Модель, обученная на большом компьютере, без изменений не уложится в бюджет кадра на Jetson. Две трансформации заставляют её влезть, и пропуск любой из них – самая частая причина, по которой edge-проект промахивается по таймингу.

Первая – TensorRT. Обученная модель – это описание миллионов мелких математических шагов. TensorRT – инструмент NVIDIA, который берёт это описание и переписывает его под один конкретный чип, как переводчик переписывает фразу, чтобы она звучала естественно на другом языке, а не дословно. Он делает три вещи: сливает много мелких шагов в меньшее число крупных, чтобы чип реже стартовал и останавливался (это называется слияние слоёв, layer fusion), выбирает самую быструю доступную процедуру для каждой операции именно на этом чипе (авто-тюнинг ядер) и может снизить числовую точность вычислений (калибровка точности), что ведёт ко второй трансформации.

Вторая – квантизация. Свежеобученная модель хранит каждое число как 32-битное значение с плавающей точкой – очень точно, но расточительно. Такая точность почти никогда не нужна, чтобы распознать человека. Квантизация округляет эти числа до меньшего формата. Два важных на Jetson – это FP16 (16 бит, половинная точность) и INT8 (8-битные целые). Представьте, как описать цвет: можно задать его до шести знаков после запятой, а можно сказать «средне-синий» – и чтобы отличить человека от автомобиля, «средне-синего» вполне достаточно. Выигрыш велик и хорошо измерен. На Jetson Orin Nano детектор YOLOv8-nano работает примерно за 27 миллисекунд на кадр в FP16 и примерно за 23 в INT8; на более крупном Orin NX квантизация в INT8 поднимает ту же модель примерно с 52 кадров в секунду до примерно 65. По опубликованным бенчмаркам 2026 года INT8 обычно даёт прирост пропускной способности на 40–80% по сравнению с FP16, и он же позволяет младшим моделям вообще поместиться в ограниченную память платы.

Есть и цена, и её нужно измерять, а не предполагать. Округление чисел может стоить немного точности. Для устойчивого детектора вроде YOLO падение обычно меньше одного процентного пункта точности детекции, когда INT8 сделан с правильной калибровкой – когда инструменту конвертации скармливают несколько сотен репрезентативных изображений, чтобы он выучил правильные диапазоны округления. Пропустите калибровку – и потеря точности может быть серьёзной. Это самая важная цифра, которую нужно поставить на тестовый стенд перед тем, как закладывать INT8: измерьте точность детектора в FP16, измерьте снова в INT8 на вашем видео и убедитесь, что разрыв приемлем для вашего правила.

«Частая ошибка – выдавать бенчмарковую частоту кадров за свою. Страница вендора говорит «65 FPS YOLOv8 на Orin NX». Это цифра детектора в одиночку, на бенчмарковом потоке изображений, когда больше ничего не запущено. Ваша система ещё декодирует видео, запускает трекер, иногда сегментер, применяет правила и рисует наложения – и делает это, пока режим мощности и температура платы колеблются. Реальные установки регулярно оказываются вдвое ниже заголовочной цифры, как только в дело вступает полный конвейер. Закладывайте бюджет на весь конвейер, на вашем железе, на вашем видео, в том корпусе, где он реально будет жить.»

Проходим По Бюджету Кадра

Это сердце итогового проекта. У нас 33 миллисекунды на кадр при 30 кадрах в секунду. Потратим их шаг за шагом для однокамерной установки на Orin NX. Точные числа меняются с моделью и платой; форма бюджета – нет.

Первая статья расхода – декодирование. Камера не шлёт сырые пиксели – она шлёт сжатое видео, так же как стриминговый сервис, чтобы сэкономить трафик. Кадр нужно распаковать, прежде чем любая модель сможет его прочитать. На платах Jetson есть выделенный аппаратный декодер, называемый NVDEC, который делает это, не трогая графические ядра, поэтому он почти ничего не стоит из нашего ИИ-бюджета – порядка 1–2 миллисекунд, и, что важно, он работает параллельно с ИИ-обработкой предыдущего кадра. Именно поэтому так важно держать кадр на чипе всё время.

Вторая статья расхода – детекция, и она крупная. Детектор YOLO, квантованный в INT8 и скомпилированный TensorRT, работает примерно за 12–18 миллисекунд на кадр на Orin NX для модели малого-среднего размера. Это уже больше половины бюджета, что сразу объясняет, почему именно вокруг детектора подбирают плату.

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

Четвёртая статья расхода – сегментация, и хитрость в том, что вы платите её не на каждом кадре. Запуск полного SAM 2 на каждом кадре стоил бы больше всего бюджета сам по себе. Вместо этого вы запускаете сегментер только тогда, когда правило просит точный контур – скажем, на том одном отслеживаемом человеке, что только что пересёк линию – и часто лишь раз в несколько кадров, переиспользуя результат между ними. Облегчённый сегментер вроде NanoSAM работает за единицы миллисекунд на Orin, когда ему дают подсказку-рамку от детектора, который вы уже запустили. Размазанная по кадрам, его средняя стоимость падает до низких единиц миллисекунд. Почему облегчённая версия обязательна – ниже.

Пятая статья расхода – правила и наложение: решить, срабатывает ли отслеживаемый, возможно сегментированный объект под условие, и нарисовать рамки и контуры на выходном кадре. На графическом чипе это самое большее несколько миллисекунд.

Сложим для однокамерного случая на Orin NX: примерно 2 (декод) + 15 (детекция) + 1 (трекинг) + 3 (сегментация, размазанная) + 3 (правила и отрисовка) ≈ 24 миллисекунды. Это влезает в бюджет 33 миллисекунды с запасом около 9 миллисекунд – и запас это не гордость от безделья, а предохранительная маржа, которая поглощает загруженный кадр с сорока объектами, мгновенный тепловой троттлинг или вторую камеру. Дисциплина в том, чтобы держать сумму комфортно ниже бюджета, никогда не ровно на нём.

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

Детектор Подробно – YOLO На Orin

Детектор забирает самый большой кусок бюджета, поэтому заслуживает наибольшей заботы. Три выбора решают его стоимость: какой размер YOLO, какая точность и какое входное разрешение.

Размер модели – это регулятор, а не переключатель. Семейство YOLO выпускается в размерах от «nano» (самый маленький и быстрый) через «small», «medium» и крупнее. Модель nano в INT8 на Orin Nano уверенно держит выше 30 кадров в секунду на одной камере; medium даёт лучшую точность на мелких или далёких объектах, но съедает больше бюджета. Правильный выбор – самая маленькая модель, которая всё ещё детектирует объекты, важные вашему правилу, на той дистанции, на которой они появляются. Выбирайте её, тестируя на вашем видео, а не читая таблицу лидеров, потому что точность из таблицы измеряется на универсальном наборе данных, который может не иметь ничего общего с видом вашей камеры.

Точность мы разобрали: компилируйте в INT8 с правильной калибровкой, проверяйте разрыв точности на собственном видео, держите FP16 как запасной вариант, если разрыв слишком велик.

Входное разрешение – тихо дорогой регулятор. Детектор не видит ваш полный кадр 1080p – он уменьшает каждый кадр до фиксированного квадрата – обычно 640 на 640 пикселей – прежде чем смотреть. Больший входной квадрат находит более мелкие объекты, но стоит больше времени, примерно пропорционально площади: переход с 640 на 1280 по каждой стороне учетверяет число пикселей и примерно учетверяет время детекции. Многие edge-проекты, которые «не могут вытянуть частоту кадров», просто запускают больший вход, чем нужно их правилу. Если ваши объекты крупные в кадре, меньший входной квадрат может вернуть несколько миллисекунд без значимой потери точности.

Трекер Подробно – Почему ByteTrack Подходит Для Edge

Задача трекера – идентичность: продолжать называть одного и того же человека «трек 7», пока он движется, даже когда детектор ненадолго теряет его за колонной. Конкретная находчивость ByteTrack, полностью разобранная в уроке 2.8, в том, что он не выбрасывает рамки детектора с низкой уверенностью. Большинство трекеров оставляют только те рамки, в которых детектор уверен, и отбрасывают остальные; ByteTrack делает второй проход сопоставления, пытающийся привязать оставшиеся низко-уверенные рамки к существующим трекам. В итоге человек, который ненадолго стал размытым или наполовину скрытым – и потому дал детекцию с низкой уверенностью – сохраняет свою идентичность вместо того, чтобы считаться новым. На стандартном бенчмарке MOT17 этот подход достигает оценки точности трекинга 80,3, близко к вершине поля, оставаясь достаточно лёгким, чтобы работать в реальном времени.

Почему это важно именно для edge – из-за стоимости. ByteTrack не запускает собственную нейросеть; это геометрия и бухгалтерия на главном процессоре. Значит, он не конкурирует с детектором и сегментером за графический чип и добавляет хорошо меньше миллисекунды на кадр. Трекеры, которые запускают нейросеть, чтобы распознать внешний вид каждого объекта – DeepSORT классический пример – устойчивее, когда объекты похожи, но добавляют вторую модель в ваш бюджет. На плате, где детектор уже съедает половину бюджета, почти нулевая стоимость ByteTrack обычно – правильный компромисс. Тянитесь к трекеру по внешности только тогда, когда ваша сцена этого по-настоящему требует: много почти одинаковых объектов, пересекающих пути, где одна геометрия путает их идентичности.

Сегментер Подробно – Почему SAM 2 Нужно Облегчать

SAM 2 – модель, которая по точке или рамке выдаёт пиксельно точный контур объекта и – её главная фишка – отслеживает этот контур сквозь видео, используя внутреннюю память о том, как объект выглядел раньше. Она замечательна, и в исходном виде слишком медленна для edge. Опубликованные измерения дают полному SAM 2 около одного кадра в секунду на мобильном устройстве, потому что сам механизм памяти, делающий её хорошей на видео, – это и её самая медленная часть. Один кадр в секунду против бюджета в 30 кадров в секунду – это провал.

Решение – дистилляция: обучение маленькой быстрой модели имитировать выходы большой. Несколько облегчённых вариантов теперь существуют именно для этой работы. NanoSAM – дистиллированная модель Segment Anything, построенная для работы в реальном времени на Jetson Orin с TensorRT, по отчётам примерно в пять раз быстрее и без того маленькой MobileSAM с малой потерей точности. EdgeTAM, модель «track anything» 2025 года для устройств, держит 16 кадров в секунду на топовом телефоне и работает более чем в двадцать раз быстрее стандартного SAM 2, заменив дорогой шаг памяти на более лёгкий. EdgeSAM достигает 30+ кадров в секунду на телефонах, GPU Jetson и ARM-устройствах. Собственные бенчмарки Super Mode от NVIDIA показывают, что базовый SAM 2 поднимается с 4,4 до 6,3 кадров в секунду на Orin Nano 8GB после обновления JetPack 6.2 – полезно для эпизодических вызовов, но всё ещё далеко от использования на каждом кадре, и именно поэтому вы запускаете его выборочно и переиспользуете результаты.

Инженерный паттерн, делающий сегментацию доступной на edge, таков: никогда не сегментировать вслепую, никогда не сегментировать всё, никогда не сегментировать каждый кадр. Пусть дешёвый детектор и почти бесплатный трекер решат, какие один-два объекта важны в эту секунду, отдайте сегментеру подсказку-рамку только для них, запустите облегчённый вариант и переиспользуйте полученный контур несколько кадров, пока объект едва меняет форму. Сделанная так, пиксельно точная сегментация стоит несколько миллисекунд в среднем, а не сжигает весь бюджет.

Оркестратор – Где Проекты На Самом Деле Теряют Время

Три модели – хорошо изученные строительные блоки. Оркестратор – код, перемещающий кадры между ними – это место, где реальные проекты тихо теряют половину производительности, и это часть, которую ни один бенчмарк за вас не измеряет.

Регулярный злодей – копирование кадра туда-сюда. У графического чипа и главного процессора отдельная память. Каждый раз, когда кадр пересекает границу между ними, его нужно скопировать, а копия кадра высокого разрешения стоит реального времени. Наивный конвейер копирует кадр на главный процессор, чтобы запустить трекер, обратно на графический чип, чтобы запустить сегментер, снова обратно, чтобы нарисовать – и эти копии легко стоят больше, чем сам ИИ. Решение – держать кадр на графическом чипе от декода до наложения и перемещать через границу только маленькие результаты (горстку рамок, несколько контуров). Это разница между детектором, который на бенчмарке 15 миллисекунд, выдающим в вашем конвейере 24 миллисекунды, и выдающим 40.

Есть два способа построить оркестратор, и выбор – одно из самых последствийных решений в проекте.

Первый – NVIDIA DeepStream, готовый фреймворк конвейера, построенный именно для этого. DeepStream построен на GStreamer – давно существующей системе сборки медиа-конвейеров как цепочки стадий-плагинов. Его стадии чисто ложатся на наши четыре части: стадия декода кормит стадию пакетирования (nvstreammux), группирующую кадры с одной или многих камер, затем стадия инференса (nvinfer) запускает детектор на TensorRT, стадия трекинга (nvtracker) присваивает идентичности, а стадия экранного отображения рисует результат. Критически, DeepStream держит кадр на графическом чипе сквозь все эти стадии по дизайну, так что дисциплину «без копий» вы получаете бесплатно. Это правильный выбор по умолчанию для любого серьёзного многокамерного развёртывания.

Второй – кастомный конвейер, обычно на Python с библиотекой Ultralytics для детектора и собственным связующим кодом для остального. Это быстрее прототипировать, легче читать и полностью гибко – Ultralytics поддерживает детекцию, сегментацию и оценку позы из коробки, тогда как интеграция трекера в DeepStream настроена в основном на детекцию и требует доработки для сегментации. Цена в том, что теперь вы сами отвечаете за дисциплину «без копий», и её легко нарушить. Кастомный конвейер – правильный выбор для одной камеры, раннего прототипа или системы, чья логика слишком необычна, чтобы выразить её в конфигурационных файлах DeepStream.

# Набросок однокамерного edge-конвейера (Ultralytics + ByteTrack).
# Детектор запускает движок TensorRT INT8; track=True включает ByteTrack;
# сегментация вызывается только на выбранных треках, не на каждом объекте.
from ultralytics import YOLO

detector = YOLO("yolov8n.engine")          # заранее скомпилированный движок TensorRT INT8

# stream=True выдаёт один результат на кадр без буферизации всего видео;
# persist=True сохраняет идентичности треков между кадрами (ByteTrack).
for result in detector.track(source="rtsp://camera/stream",
                             tracker="bytetrack.yaml",
                             stream=True, persist=True):
    for box in result.boxes:
        track_id = int(box.id) if box.id is not None else None
        # Бизнес-правило здесь: пересечение линии, время пребывания, вход в зону.
        # Только когда правило сработало, запрашиваем точную маску для этого трека:
        if rule_fires(track_id, box):
            mask = segment_one(result.orig_img, box.xyxy)   # вызов облегчённого SAM 2
            raise_alert(track_id, mask)

Набросок выше намеренно мал, и эта малость – суть: модели – несколько строк; инженерия – всё вокруг них – компиляция движка, калибровка INT8, удержание кадров на чипе, выбор момента rule_fires и сегментация одного трека вместо всех.

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

Масштабирование На Много Камер

Одна камера – учебный случай. Реальные установки видеонаблюдения и ритейла смотрят много камер с одной платы, и арифметику масштабирования стоит увидеть, потому что она прощает больше, чем кажется сначала.

Причина, по которой одна плата может обслуживать много камер, – пакетирование (batching). Вместо запуска детектора по разу на камеру конвейер собирает по одному кадру с каждой из, скажем, восьми камер и запускает детектор разом на всех восьми вместе. Графический чип куда эффективнее обрабатывает восемь кадров за один проход, чем восемь кадров за восемь проходов, потому что меньше времени тратит на старты и остановки. Опубликованная цифра делает мысль наглядной: Orin NX 16GB, запускающий маленький детектор YOLOv8 в INT8, может обслуживать порядка сорока потоков камер примерно по пять кадров в секунду каждый. Пять кадров в секунду достаточно для многих правил видеонаблюдения – человек не пересекает дверной проём за одну пятую секунды – и это показывает, что частота кадров на камеру – регулятор, который вы меняете против числа камер.

Компромисс явный и его стоит сказать прямо: суммарная работа в секунду примерно фиксирована пропускной способностью платы, и вы делите её между камерами и частотой кадров. Одна камера на 30 кадрах в секунду или тридцать камер по одному кадру в секунду тянут из одного бюджета. Выберите точку на этой кривой, которая реально нужна вашему правилу. Правило распознавания номеров у ворот требует высокой частоты на немногих камерах; правило «был ли кто-то в этой запретной зоне» по складу требует низкой частоты на многих. Подобрать плату – значит выбрать, где на этой кривой вы сидите, плюс запас.

Track B – Как ИИ-Ассистенты Помогают Это Строить (И Где Нет)

Этот итоговый проект несёт тему Track B всего курса: ИИ-ассистированные инструменты, которые видеоинженер реально использует, чтобы строить продукт, в отличие от ИИ-функций внутри него. Встраиваемое зрение – показательный тест, потому что это именно тот специализированный, привязанный к железу труд, где маркетинговые заявления и реальность расходятся – так что стоит быть точным с обоими.

Начнём с того, что в 2026 году действительно помогает. ИИ-ассистенты для кода – Cursor, GitHub Copilot, Claude Code – стали стандартным оснащением, и на этом типе проекта они заслуживают место конкретными, ограниченными способами. Они отлично справляются с шаблонным кодом оркестратора: собрать конвейер GStreamer или Ultralytics, написать разбор аргументов и загрузку конфигурации, сгенерировать загрузчик калибровочных изображений для INT8 и набросать связующий код оценки правил. NVIDIA встроила эту идею прямо в инструментарий: релиз DeepStream 2026 года добавил coding agents, генерирующих развёртываемый оптимизированный многокамерный конвейер из текстового описания – «принять четыре потока RTSP, детектировать людей, отслеживать их, оповещать при входе в зону» – что убирает часы кропотливой конфигурации, которую раньше копировали с форумов. Для сборочной работы эти инструменты – реальный множитель.

Теперь граница, сказанная так же прямо. Тяжёлое, критичное к производительности ядро edge-зрения – там, где сегодняшние ассистенты слабее всего, и притворяться иначе – значит тратить бюджет. Написание или ручная оптимизация собственной процедуры для графического чипа – CUDA-ядра – самый ясный пример: рецензируемые оценки 2026 года показывают, что даже передовые модели всё ещё с трудом выдают корректные, быстрые CUDA-ядра из коробки, отставая от устоявшихся компиляторных инструментов. Причина структурная, не временная: сделать edge-конвейер быстрым зависит от фактов, которые ассистент не видит из вашего кода – точная плата, её текущее тепловое состояние, где происходят копии памяти через границу чипа, как калибровка INT8 взаимодействует с вашим конкретным видео. Ассистент работает внутри фиксированного окна контекста (от 128 000 до миллиона токенов текста в 2026 году) и не может следить за вашей настройкой мощности nvpmodel или вашими таймингами кадров. Он уверенно предложит конвейер, который выглядит правильным и копирует кадр трижды.

Так что рабочий паттерн, выдерживающий проверку, – разделение труда. Пусть ассистент напишет каркас, конфигурацию, шаблонный код и первый черновик конвейера – а вы проверьте его дисциплину «без копий» сами, профилируя. Держите человека-инженера твёрдо во главе четырёх решений, определяющих, уложится ли система в бюджет кадра: размер модели, точность и калибровка, входное разрешение и путь памяти сквозь конвейер. Ассистент ускоряет те 80%, что являются сборкой; те 20%, что являются инженерией производительности, всё ещё ваши, и на edge эти 20% – вся игра.

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

Разбор Примера – Подбор И Питание Площадки На Четыре Камеры

Поставим числа на конкретное задание: небольшая торговая точка, четыре камеры, правило, отмечающее, когда отслеживаемый человек входит в дверь склада, с точным контуром, нарисованным на отмеченном человеке для клипа на проверку.

Начнём с частоты кадров на камеру, которая нужна правилу. Вход человека в дверь – не быстрое событие; восьми кадров в секунду более чем достаточно, чтобы поймать пересечение и проследить человека до выхода. Четыре камеры по восемь кадров в секунду – это всего 32 прохода детекции в секунду (4 камеры × 8 кадров = 32). Пакетированные на Orin NX 16GB с 157 TOPS, с маленьким детектором YOLO в INT8 стоимостью порядка 15 миллисекунд на пакетный проход, детектор потребляет примерно 32 × 15 = 480 миллисекунд времени графического чипа в секунду – меньше половины односекундного бюджета, оставляя комфортное место трекеру (почти бесплатному), эпизодическому вызову сегментации на отмеченном человеке и наложению. Один Orin NX 16GB покрывает эту площадку с запасом; Orin Nano был бы тесен на четырёх камерах и лучше подходит под одну-две.

Теперь питание, потому что обещание edge – отчасти обещание энергии. Запустим Orin NX в режиме 25 ватт под эту нагрузку. Двадцать пять ватт непрерывно – это 25 ватт × 24 часа = 600 ватт-часов, или 0,6 киловатт-часа в день. При репрезентативной цене электричества 15 центов за киловатт-час это 0,6 × 0,15 = 9 центов электричества в день, около $33 в год, за коробку, которая обрабатывает четыре потока камер, не отправляя в облако ни одного кадра. Поставьте это против облачной подписки на видеоаналитику с ценой за камеру в месяц, и эксплуатационная стоимость edge-сборки для многих площадок – погрешность округления. Капитальная стоимость платы и инженерия развёртывания – вот реальная цифра, которую нужно взвесить, и именно на этот вопрос подбора построена загружаемая ниже памятка.

«Частая ошибка – игнорировать корпус и тепло. Каждый бенчмарк в этой статье предполагает, что плата может отвести своё тепло. Jetson в режиме MAXN Super, превышающий тепловой бюджет, троттлит себя до меньшей частоты, чтобы остаться в безопасности, и ваша реальная частота кадров падает вместе с ним – молча. Плата на открытом стенде попадает в свои цифры; та же плата, запечатанная в герметичный корпус камеры на солнечной стене, может и нет. Проверяйте частоту кадров в реальном корпусе, в реальной среде, при реальной температуре окружающего воздуха, прежде чем подписываться. Тепловой дизайн – часть ИИ-дизайна.»

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

Фора Софт строит видеопродукты в видеонаблюдении, ритейл-аналитике, телемедицине, e-learning и видеоконференциях, и edge-паттерн из этого итогового проекта повторяется в большинстве из них: детектор, трекер, выборочный сегментер и оркестратор, которому нужно уложиться в жёсткий бюджет кадра на ограниченном железе. Работа, решающая, поедет ли такая система, – редко выбор модели; это та неэффектная инженерия, на которой эта статья настаивает: компиляция и калибровка моделей под целевую плату, удержание кадров на графическом чипе, подбор компромисса «число камер против частоты кадров» под реальное правило и валидация частоты кадров внутри реального корпуса, а не на стенде. Наши команды относятся к ИИ-ассистированному инструментарию так, как рекомендует эта статья – как к ускорителю сборки, где человек владеет критичным к производительности ядром. Если вы оцениваете edge-функцию зрения и хотите обоснованную оценку частоты кадров, энергопотребления и стоимости до того, как закладывать бюджет, – это именно тот вопрос, на который мы помогаем ответить.

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

• Real-time на 30 fps значит закончить все модели до прихода следующего кадра – за 33 мс.
• Четыре части повторяются в любой edge-системе: детектор, трекер, выборочный сегментер, оркестратор.
• TensorRT плюс квантизация INT8 – шаг, заставляющий модели влезть; всегда проверяйте разрыв точности.
• Детектор доминирует в бюджете; ByteTrack почти бесплатен; сегментируйте только то, что нужно правилу.
• Оркестратор теряет время на копиях кадра – держите кадры на чипе, перемещайте только результаты.
• ИИ-ассистенты ускоряют сборку конвейера; решения по модели, точности и пути памяти остаются за человеком.

Что Читать Дальше

• Линейка YOLO в продакшене – v8, v9, v10, v11, v12 – детектор в центре этого конвейера, подробно.
• Трекинг множества объектов – DeepSORT, ByteTrack, OC-SORT – почему ByteTrack почти бесплатен и когда платить за внешность.
• Компьютерное зрение в ритейле, промышленности и интеллектуальная видеоаналитика – вертикаль, превращающая этот конвейер в продукт.