Задержка и точность по уровням: edge и облако

Это инженерное руководство, а не юридическая консультация. Уточняйте детали у квалифицированного юриста.

Коротко

Где вы запускаете аналитику видеонаблюдения – на камере, на сервере, которым владеете, или в далёком облаке – задаёт два числа, от которых зависит, работает ли система: как быстро приходит детекция и как часто она верна. Детекция на камере или рядом с ней отвечает примерно за 25–120 миллисекунд; та же детекция, отправленная в облако, отвечает за 300–800 миллисекунд, потому что часы тикает сетевой обмен, а не сама математика. Точность движется в обратную сторону, но меньше, чем думают: малая модель, помещающаяся на камере, набирает на несколько пунктов меньше крупной на эталонном тесте, а правильно настроенная edge-модель держится в пределах 3–8 процентов от полноразмерной – реальное преимущество облака в точности это рассуждение по многим камерам, а не поиск человека в одном кадре. Эта статья показывает бюджет задержки по этапам и потолок точности по уровням, чтобы вы поняли, когда миллисекунды важны, а когда нет.

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

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

Производительный взгляд на разделение «край–облако»

Этот блок разобрал уровни развёртывания по одному. Тезис – что место запуска аналитики определяет систему – живёт в статье аналитика на краю против облака. У уровней свои статьи: сама камера в ИИ на камере (edge), сервер, которым вы владеете, в edge-серверах и ИИ-приставках, и арендованный дата-центр в стоимости облачной видеоаналитики. Денежный взгляд на все четыре уровня на одной сетке – в экономике аналитики. Коммерческий обзор того же компромисса – в нашем блоге про edge AI против cloud ИИ для видеонаблюдения.

Эта статья делает то, чего не делают те: кладёт на стол два числа производительности – задержку и точность – для каждого уровня, чтобы вы подобрали уровень под то, что сценарию реально нужно. Статья про экономику отвечает на вопрос «сколько стоит?»; эта – на вопрос «достаточно ли быстро и достаточно ли часто верно?». Эти два вопроса обычно тянут в разные стороны, и искусство – знать, который из них ваш сценарий не может уступить. Цифры здесь – представительные для оборудования и моделей 2026 года; считайте их откалиброванной точкой старта для проверки на своей сцене, а не фиксированными гарантиями.

Два числа, а не одно

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

Первое число – задержка – время от того, как что-то произошло перед объективом, до того, как система подняла об этом руку. Полный путь зовут «glass-to-glass», когда его смотрит человек, и «задержкой детекции», когда по нему действует софт; в любом случае оно измеряется в миллисекундах (мс) и решает, успеет ли кто-нибудь вмешаться, пока событие ещё разворачивается. Механика транспортной половины этого пути относится к слою стриминга, разобранному в объяснении задержки glass-to-glass; здесь нас интересует половина про аналитику.

Второе число – точность – как часто система права, и это никогда не одна цифра. Она делится на precision (из поднятых тревог – сколько настоящих) и recall (из настоящих событий – сколько поймано). Система, настроенная на высокий recall, часто кричит «волки»; настроенная на высокий precision молчит, но кое-что пропускает. Честный способ назвать точность – пара precision/recall при заявленных условиях: сцена, освещение, угол, дистанция, – никогда не одинокий процент и никогда не «100 процентов».

Задержку задаёт в основном где сидят вычисления относительно камеры. Точность ограничивает в основном сколько вычислений уровень может потратить на кадр, что решает, насколько крупную модель он тянет. Эти два предложения – вся статья; остальное – арифметика за ними.

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

Задержка: четыре этапа, и один из них главный

Задержка детекции – сумма четырёх этапов, и фокус в том, чтобы увидеть: именно сетевые этапы, а не ИИ-математика, раздувают итог, когда анализ идёт вне объекта.

Первый этап – захват и кодирование: сенсор камеры экспонирует кадр, её чип его сжимает. Это занимает примерно 15–33 миллисекунды и одинаково на любом уровне, потому что происходит внутри камеры в любом случае. Второй этап – доставка кадра к вычислениям: ничего, если модель работает на камере, миллисекунда-другая по локальной сети, если на сервере в том же здании, и 40–200 миллисекунд, если кадру нужно пересечь интернет до облачного региона – больше и капризнее по сотовой связи. Третий этап – инференс, то есть ИИ-модель собственно смотрит на кадр: 8–30 миллисекунд для малой модели на чипе камеры, 10–25 миллисекунд для модели крупнее на графическом процессоре (GPU – чип для быстрого запуска ИИ-моделей). Четвёртый этап – доставка результата тому, что по нему действует: пара миллисекунд к локальному реле тревоги или ещё 40–200 миллисекунд обратно через интернет.

Прочтите эти этапы вместе – и вывод ясен: сам инференс это самый быстрый этап, в облаке часто даже быстрее, потому что облако работает на более крупном железе. Топит облачную задержку два сетевых пересечения, обёрнутых вокруг него. Разложим бюджет по уровням:

Таблица 1. Бюджет задержки детекции по этапам для одной и той же аналитики на трёх размещениях. Этап инференса похож везде – у облака даже самый быстрый чип – но два интернет-пересечения доминируют в облачном итоге. Сотовая связь или загруженные каналы толкают строку облака за 1 200 мс. Цифры – представительные для оборудования 2026 (NPU класса камеры, локальный GPU-сервер и облачный GPU-регион).

Сделаем арифметику наглядной на случае, который важнее всего. Человек на спокойном шаге проходит около 1,4 метра в секунду. За примерно 800 миллисекунд облачного обмена этот человек смещается примерно на:

1,4 м/с × 0,8 с ≈ 1,1 метра – больше полного шага за линию, которую вы наблюдали.

За примерно 60 миллисекунд детекции на камере тот же человек смещается примерно на 1,4 × 0,06 ≈ 8 сантиметров – фактически всё ещё стоит на линии. Этот разрыв – вся причина, по которой существует размещение по задержке.

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

Правило размещения: 200 миллисекунд и одна секунда

Эти цифры сворачиваются в правило, переживающее большинство споров. Если тревога должна сработать меньше чем за 200 миллисекунд, анализ обязан работать на камере или рядом – на интернет-обмен бюджета нет. Если бюджет 200 миллисекунд – одна секунда, подходит гибрид: детектируй на краю, подтверждай или обогащай в облаке. Если приемлемы несколько секунд, облако в порядке, и вы оптимизируете пропускную способность и стоимость, а не рефлексы. Полезная середина: «реальное время» в активном наблюдении значит отклик, измеряемый секундами – достаточно быстро, чтобы охранник действовал, пока событие разворачивается, – а полоса до 250 миллисекунд это место для автоматических реакций без человека в петле.

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

Одно успокоение перед выбором уровня: какой бы уровень ни произвёл детекцию, она доходит до системы управления видео (софт, который принимает и ведёт множество камерных потоков, – VMS) через один и тот же стандартный интерфейс – метаданные и события аналитики, заданные ONVIF Profile M. Уровень задаёт задержку и точность, но не контракт интеграции, так что аналитику можно перенести из облака на край, не перекладывая VMS. Коммерческий обзор того, как ONVIF ложится в систему безопасности, – в нашем блоге про профили ONVIF в системах безопасности; инженерная глубина – в ONVIF для инженеров.

Точность: уровень ограничивает модель, но не так, как вы думаете

Теперь второе число. Инстинкт говорит, что облако «точнее», потому что у него безграничные вычисления. Реальность интереснее, и у неё две части.

Первая часть верна: размер модели задаёт потолок точности, а бюджет вычислений уровня задаёт размер модели. Точность детекции объектов обычно меряют как mean average precision (mAP – единый процент, сводящий precision и recall по многим типам объектов в одно сравнимое число на стандартном тесте). На публичном бенчмарке COCO «nano»-модель, достаточно малая для чипа камеры, набирает около 40 процентов mAP, а «extra-large»-модель, которой нужен серьёзный GPU, – около 55 процентов; разрыв примерно в 15 процентных пунктов исходит чисто из того, что есть больше вычислений на кадр. Камера тянет несколько ватт; серверный GPU – сотни. Этот разрыв в мощности и есть потолок точности по уровням.

Вторая часть переворачивает инстинкт: для повседневных классов наблюдения разрыв почти закрывается, как только модель настроена. Поставить модель на камеру значит сжать её числа с полной точности до компактных целых – процесс под названием квантизация, – что меняет немного точности на много скорости. Сделанная грубо, она стоит 5–8 процентов mAP. Сделанная с калибровочными данными, взятыми с самих камер (несколько сотен кадров через день, ночь, погоду и толпу), потеря падает ниже 3 процентов, а инференс идёт на 30–50 процентов быстрее. Для классов, важнейших системе наблюдения – человек, машина, пакет, забытая сумка, – практический процент детекции на камере почти неотличим от той же модели в облаке.

Так где же облако действительно точнее? Не в поиске человека в одном кадре, а в рассуждении по кадрам и камерам: ре-идентификации того же человека через пятьдесят камер кампуса, описании необычной сцены большой визуально-языковой моделью, корреляции событий за смену. Эти модели слишком тяжелы для памяти камеры, так что они и есть реальная работа облака. Чистое разделение – детектируй на краю, рассуждай в облаке, – а внутренности обеих моделей живут в разделе ИИ, в дистилляции и квантизации для edge-видео-ИИ и линейке YOLO для продакшена.

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

Точность – диапазон, а не число, и биометрия это доказывает

Важнейшее правило точности в наблюдении: той самой точности не существует. Любая аналитика даёт диапазон precision/recall, который гнётся со сценой, и две повседневные аналитики это показывают.

Чтение автомобильных номеров – automatic number-plate recognition (ANPR, он же LPR) – среди самых зрелых аналитик, и в контролируемых полосах с хорошим светом может превышать 99 процентов. Но реальная точность обычно называется в 90–98 процентов и падает дальше с условиями, которые встречает каждый интегратор: быстрая машина смазывает символы, крутой угол камеры их растягивает, низкий свет или блик фар их вымывает, а грязный или погнутый номер ломает чтение. Та же аналитика, тот же софт – число движется на 10 пунктов и больше от одной сцены.

Распознавание лиц делает правило невозможным игнорировать, и поэтому раздел никогда не называет одну цифру. Национальный институт стандартов и технологий США ведёт давний Face Recognition Vendor Test – ближайшее к независимому арбитру, что есть у области. Его измеренные выводы прямы: при фиксированной настройке ложного совпадения частоты ошибок различаются по демографическим группам в десятки раз, внутригрупповые частоты ложных срабатываний охватывают огромные диапазоны по алгоритмам, и любое расхождение растёт на изображениях низкого качества. Урок не в том, что распознавание лиц не работает; в том, что его точность – распределение, формируемое субъектом и условиями, так что любой вендорский «99 с чем-то процентов» это лабораторное число, ничего не говорящее про вашу камеру в сумерках. Поскольку данные лиц и номеров биометричны, они ещё и правовой барьер, а не только вопрос производительности – EU AI Act (Регламент (ЕС) 2024/1689) относит удалённую биометрическую идентификацию в реальном времени к высокому риску, а закон штата Иллинойс о биометрической приватности (BIPA, 740 ILCS 14) требует согласия до захвата, и эти ограничения действуют, какой бы уровень ни запускал модель. Глубокая проработка обоих живёт в Блоке 6; ремесло настройки – в настройке аналитики: ложные тревоги и точность.

Ещё один факт производительности переживает любой уровень: детекторы поднимают ложные тревоги, и лекарство редко в более крупной модели. Сочетание детекции с трекером, навязывающим временную согласованность – объект должен продержаться несколько кадров, прежде чем зачтётся, – резко режет ложные срабатывания, потому что ошибка в один кадр никогда не доходит до оператора. Здоровое развёртывание держит меньше примерно пяти ложных тревог на камеру в неделю, а модели дрейфуют, так что это число ползёт вверх через 12–18 месяцев без переобучения. Ничто из этого не чинится сменой уровня; это чинится настройкой, поэтому точность – операционная дисциплина, а не строка из спецификации.

Частая ошибка

Самая дорогая ошибка производительности, что мы видим, – называть число бенчмарка как полевую гарантию: пообещать «55 процентов mAP» или «99 процентов совпадения лиц» из даташита, а потом смотреть, как развёрнутая система теряет детекции в дальнем конце тусклой парковки. Её близнец – класть критичную к задержке аналитику в облако ради экономии: вести тревогу периметра или вторжения через 600-миллисекундный обмен, потому что облачная модель набрала на волосок больше, – и обнаружить, что лишняя точность бесполезна, когда тревога приходит после того, как нарушитель уже внутри. Лечение одно для обоих: называйте точность диапазоном precision/recall, измеренным на своём видео, ставьте бюджет задержки, который сценарий реально требует, и размещайте каждую аналитику на уровне, отвечающем обоим – детекцию у камеры, где важны рефлексы, рассуждение в облаке, где важно суждение, а секунды – норма.

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

Фора Софт строит ПО для видео в реальном времени, стриминга и компьютерного зрения с 2005 года, на 250+ выпущенных проектах, и первое, что мы фиксируем на проекте наблюдения, – контракт производительности: бюджет задержки, которому каждая тревога обязана уложиться, и precision/recall, который каждая аналитика обязана держать в реальной сцене, а не в демо. К нам приходят, когда облачный пилот, выглядевший точным, оказывается слишком медленным, чтобы по нему действовать, когда edge-модель, хорошо набравшая на бенчмарке, дрейфует в ложные тревоги через год, или когда никто не может сказать, каким детекциям реально нужны рефлексы до 200 миллисекунд, а какие подождут облачного рассуждения. Мы меряем каждый этап бюджета задержки и точность каждой аналитики под реальной нагрузкой – реальный свет, реальные углы, реальное число камер – и ведём с честным диапазоном, что модель держит в ваших условиях, а не с лучшим числом бенчмарка. Размещение детекции у камеры и резерв облака под рассуждение по камерам регулярно дают и более быстрые тревоги, и более ровную точность, чем одноуровневый дизайн, построенный на цифре из даташита.

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

• Задержку задаёт место вычислений; точность ограничена бюджетом вычислений уровня на кадр.
• Детекция на краю отвечает за ~25–120 мс; та же детекция в облаке – за ~300–800 мс.
• Облако медленно из-за сетевого обмена, а не из-за ИИ-математики.
• Настроенная edge-модель держится в ~3–8% mAP от полноразмерной облачной на частых классах.
• Реальный плюс облака в точности – рассуждение по камерам, а не детекция в одном кадре.
• Точность – диапазон precision/recall, гнущийся со сценой, светом и углом, никогда не «100%».

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

• Аналитика на краю против облака: решение, определяющее систему
• Экономика аналитики: компромиссы трафика, вычислений и хранения
• Настройка аналитики: ложные тревоги, точность и реальность оператора