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

Кратко

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

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

Статья предназначена для продакт-менеджера, оценивающего функцию видеонаблюдения, ритейла или робототехники, которому важно понять, правда ли, что «всё это работает на одной дешёвой коробке рядом с камерой»; для основателя, выбирающего между 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 миллисекунды (1 секунда ÷ 30 кадров = 0,033 секунды = 33 мс). Это означает, что на весь конвейер – детекцию, трекинг, сегментацию и отрисовку – отводится ровно 33 миллисекунды на кадр. Превысите этот лимит – и кадры начнут накапливаться быстрее, чем система их обрабатывает: она отстанет, а «живое» видео превратится в слайд-шоу. Вся инженерная задача этого итогового проекта – уложиться в эти 33 мс на компьютере размером со стопку визиток.

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

Четыре части системы зрения на краю

Каждая система в этом итоговом проекте, а также почти каждый готовый продукт компьютерного зрения для 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, достаточно компактный для работы в реальном времени, требует порядка нескольких 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 после обновления JetPack 6.2 на Orin Nano 8GB ускоряется с 4,4 до 6,3 кадров в секунду – результат полезен для эпизодических вызовов, но всё ещё недостаточен для обработки каждого кадра. Именно поэтому его запускают выборочно и переиспользуют результаты.

Инженерный паттерн, делающий сегментацию доступной на 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 миллисекунд времени GPU в секунду – меньше половины доступного бюджета, оставляя достаточно ресурсов для трекера (почти бесплатного), эпизодического вызова сегментации по отмеченному человеку и наложения. Один 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-функцию компьютерного зрения и хотите получить обоснованную оценку частоты кадров, энергопотребления и стоимости до формирования бюджета – это именно тот вопрос, на который мы помогаем ответить.

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

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

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

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