Содержание статьи +
- Коротко
- Почему это важно
- Что вообще значит «ИИ на камере»
- Чип внутри: NPU, вендорские SoC и отдельные ускорители
- Жёсткая причина, почему камера остаётся маленькой: бюджет питания
- Какие модели реально помещаются
- Что камера отдаёт: метаданные, а не видео
- Разбор на числах: сколько полосы экономит модель на камере
- Пределы edge-вычислений
- Ключевые выводы
- Что почитать дальше
Это инженерное руководство, а не юридическая консультация. Уточняйте детали у квалифицированного юриста.
Коротко
Современная камера видеонаблюдения – это маленький компьютер с отдельным ИИ-чипом, и «ИИ на камере» означает, что камера сама смотрит своё видео и отправляет дальше смысл – «человек», «автомобиль», «пересечение линии», – а не пиксели. У этого чипа фиксированный и скромный бюджет, заданный мощностью, которую способен дать один сетевой кабель, поэтому камера запускает одну-две маленькие квантованные модели, а не большие датацентровые, и события уходят крошечными метаданными по стандарту ONVIF, а не полным видео. Выигрыш реален: реакция за миллисекунды, трафик на анализ меньше более чем на 99% и узнаваемое видео, которое может остаться внутри устройства. Эта статья объясняет, какой кремний на самом деле стоит в камере, какие модели помещаются, что камера отдаёт и какие жёсткие потолки решают, когда камеры достаточно, а когда работу нужно перенести на edge-сервер или в облако.
Почему это важно
Если вы покупаете или строите ИИ-систему видеонаблюдения, фраза «в камере уже есть ИИ» скрывает больше всего. Две камеры могут одинаково заявлять edge AI и при этом отличаться на порядок по тому, что они реально детектируют, сколько моделей запускают одновременно и можно ли их вообще обновить. Понимание того, что чип внутри умеет и чего не умеет – до того, как камеры повешены на стену и подключены к коммутатору, – отличает систему, которая растёт вместе с вами, от той, которую придётся демонтировать. Эта статья даёт понятную модель edge AI на камере, чтобы вы могли критично читать datasheet, задавать вендору правильные вопросы и заранее знать, какие задачи место на камере, а какие нет.
Что вообще значит «ИИ на камере»
Начнём с самой камеры, потому что вся статья держится на одном сдвиге в том, как её представлять. Современная сетевая камера видеонаблюдения – это не просто объектив и сенсор; это маленький самодостаточный компьютер, который смотрит на мир. Внутри работает операционная система, сжимается видео, идёт обмен с сетью, а в умной камере – выполняется искусственный интеллект над тем, что она видит.
Термин для этой последней части – edge AI. «Edge» («край») значит, что вычисления происходят на краю сети, прямо там, где рождаются данные, а не в далёком датацентре; «edge AI» – это просто запуск анализа на самом устройстве. Когда устройство – это камера, мы говорим на камере или на устройстве (on-device), чтобы отделить такой анализ от того, что идёт на отдельной коробке в локальной сети (edge-сервер) или в облаке. Эти три места разобраны по уровням в статье аналитика на краю против облака; здесь мы целиком внутри первого – камеры.
Вот ход, ради которого ИИ на камере стоит затрат. Камера без ИИ – это кран: она льёт сырое видео по трубе, чтобы его записали и, может быть, посмотрели. Камера с ИИ сначала смотрит на свой поток и описывает, что видит. Вместо непрерывного видео пустой парковки она может молчать, пока не въедет автомобиль, и тогда послать короткое сообщение: автомобиль, эта точка, 14:02:11, уверенность 0.91. Камера отправляет смысл, а не пиксели – а смысл в тысячи раз меньше видео, из которого он получен.
Чип внутри: NPU, вендорские SoC и отдельные ускорители
Работу ИИ делает специализированный чип – нейропроцессор (NPU, Neural Processing Unit), железо, созданное выполнять специфическую математику ИИ-модели куда эффективнее обычного процессора. Его производительность измеряют в TOPS – триллионах операций в секунду: грубая мера того, сколько ИИ-работы чип успевает за секунду. Камерный NPU даёт от единиц до низких десятков TOPS; держите это число в уме, потому что разрыв между ним и датацентровым чипом – это вся история про то, что помещается.
В большинстве профессиональных камер NPU – не отдельная деталь, а один блок на системе-на-кристалле (SoC) – едином куске кремния, объединяющем процессор изображения, кодер видео, главный процессор и ИИ-движок. Показательный пример – Ambarella CV72S: 4K-SoC для массовых охранных камер, который запускает современные нейросети, включая более новый тип transformer, потребляя меньше 3 ватт, и при этом имеет запас на параллельный запуск более чем одной сети, например трекинга людей рядом с другим детектором (Ambarella, CV72S, 2023). Axis встраивает собственный ИИ-блок, Deep Learning Processing Unit (DLPU), в свою линейку SoC ARTPEC; текущее поколение ARTPEC-9 выполняет аналитику на камере в несколько раз быстрее предыдущего и запускает модели «любого размера, лишь бы они помещались в память устройства» (документация для разработчиков Axis). Эта оговорка – весь предел edge AI в девяти словах, и мы к ней вернёмся.
Второй подход добавляет отдельный ИИ-чип рядом с главным процессором камеры. Hailo делает оба: семейство SoC для умных камер Hailo-15 на 7, 11 и 20 TOPS по уровням и ускоритель-компаньон Hailo-8, упаковывающий 26 TOPS примерно в 2,5 ватта в чип, достаточно маленький, чтобы встроить его внутрь камеры (Hailo). Цифры достаточно конкретны, чтобы закрепить мысль: старший Hailo-15 способен крутить средней величины модель детекции YOLO на полной частоте кадров при высоком разрешении входа – это серьёзный детектор, но именно детектор, запускаемый по одному-два за раз, а не целая комната их.
Картина в итоге такая. Камерный кремний строят вокруг производительности на ватт, а не сырой мощности, из-за ограничения, которое мы сейчас сделаем явным: у камеры очень мало мощности. Этот фокус покупает реальную способность – нынешние SoC крутят сегодняшние модели детекции в реальном времени, – но ставит потолок, который не сотрёт ни одно слово из datasheet.
| Чип (пример) | Тип | Производительность ИИ | Питание | Что крутит на камере |
|---|---|---|---|---|
| Ambarella CV72S | Камерный SoC (CVflow 3.0) | Класс «лучшая перф/ватт»; крутит transformer-сети | < 3 Вт | 4K, параллельные детекторы (напр. человек + маска) |
| Axis ARTPEC-9 (DLPU) | Камерный SoC + ИИ-блок | ~3× к прошлому поколению | Бюджет камеры | Модели любого размера, что влезают в память; TensorFlow Lite |
| Hailo-15H | Камерный vision SoC | 20 TOPS | Класс единиц ватт | Средний детектор YOLO на полной частоте кадров |
| Hailo-8 | Отдельный ускоритель (M.2) | 26 TOPS | ~2,5 Вт | Один-два встроенных детектора; TF / PyTorch / ONNX |
| NVIDIA Jetson AGX Orin | Модуль для edge-сервера (для контраста) | до 275 TOPS | 15–60 Вт | ~8 потоков камер, по несколько моделей – не на камере |
Таблица 1. Кремний от меньшего к большему. Первые четыре стоят внутри камеры и делят её узкий бюджет питания; Jetson включён лишь чтобы показать масштаб следующего уровня – его 15–60 Вт больше, чем получает вся PoE-камера, поэтому он живёт в коробке в сети, а не в камере. Цифры из документации вендоров (Ambarella, Axis, Hailo, NVIDIA); значения TOPS заявлены вендором и зависят от модели и размера входа.
Жёсткая причина, почему камера остаётся маленькой: бюджет питания
Прежде чем говорить о моделях, зафиксируем физический предел, потому что он объясняет все остальные. Большинство камер видеонаблюдения получают и данные, и электричество по одному Ethernet-кабелю через Power over Ethernet (PoE) – стандарт, подающий питание по той же жиле, что несёт сеть. На бумаге PoE щедр, на практике тесен. Распространённый уровень 802.3af (Type 1) даёт устройству после потерь в кабеле около 12,95 ватта; уровень 802.3at, «PoE+», поднимает это примерно до 25 ватт; новые уровни 802.3bt идут выше, но большинство фиксированных камер укладывают в нижние два (IEEE 802.3).
Теперь потратим этот бюджет. Из этих ~13 ватт камера должна питать сенсор, процессор очистки изображения, кодер видео, сетевой интерфейс, главный процессор – и ночью инфракрасную подсветку, которая сама может тянуть 2–5 ватт. ИИ-чипу достаётся только остаток. Именно поэтому камерные SoC проектируют делать свою работу меньше чем за 3–4 ватта суммарно: больше дать неоткуда. Камера не может нести прожорливый датацентровый ускоритель по той же причине, по которой телефон не запустит настольную видеокарту, – энергии и теплу некуда деться.
Этот единственный факт – несколько ватт, поделённых на всех, – корень каждого «предела edge AI» дальше в статье. Это не программный недостаток, который вендор закроет в следующем году; это физика на конце кабеля.
Какие модели реально помещаются
С зафиксированным бюджетом питания вопрос «какой ИИ способна крутить камера?» получает точный ответ: маленькую квантованную модель, обычно одну-две за раз. Важны обе части этой фразы.
«Маленькая» – это модель с относительно небольшим числом параметров, сделанная лёгкой. В видеонаблюдении это компактные детекторы объектов – лёгкие члены семейства YOLO («You Only Look Once», популярный дизайн детекции в реальном времени), такие как варианты n и s, а также MobileNet-SSD и EfficientDet-Lite, модели, изначально рассчитанные на телефоны и камеры, а не на серверы (отраслевой инструментарий и бенчмарки, 2025–2026). Рутинные задачи видеонаблюдения они делают хорошо: детектируют и классифицируют людей и транспорт, считают объекты, фиксируют пересечение линии. Тяжёлое открытое рассуждение, доступное большой модели в датацентре, они не делают.
«Квантованная» – это приём, который позволяет им поместиться. Модели обучают в числах высокой точности (32-битных с плавающей точкой) – точных, но громоздких. Квантование переписывает модель в меньших целых числах – обычно 8-битных, INT8, – что сжимает её след в памяти и позволяет NPU крутить её куда быстрее за небольшую, обычно приемлемую, потерю точности; современные детекторы построены так, что INT8-версия сохраняет почти ту же точность, что полная (отраслевой инструментарий, 2026). Axis, например, крутит на своём DLPU формат TensorFlow Lite и рекомендует поканальное квантование как более точный вариант (документация для разработчиков Axis). Камера обычно крутит такую модель на 15–30 кадрах в секунду – достаточно быстро, чтобы отслеживать реальное движение.
Граница, таким образом, не «ИИ или нет», а какой AI. Как эти детекторы проектируют, обучают и ужимают, чтобы они влезли в камеру, – это тема инженерии моделей, и она в другой части Learn: см. дистилляция и квантование для edge-видео-ИИ и линейку YOLO в проде в разделе AI for Video Engineering. Эта статья остаётся на вопросе видеонаблюдения: что камера делает с моделью, когда та уже на борту, и где это заканчивается.
Что камера отдаёт: метаданные, а не видео
Когда модель на камере срабатывает, камера выдаёт событие детекции – компактное описание того, что увидела. Одно событие – это от сотен байт до нескольких килобайт: тип объекта, координаты рамки, метка времени, часто оценка уверенности. Это и есть продукт edge AI, и его размер – источник его силы.
Сравним с видео. Камера на 4 мегапикселя отдаёт примерно 2 мегабита в секунду сжатого видео круглосуточно. Событие – это сообщение, которое поместилось бы в SMS. То есть камера, которая сама анализирует свой поток и шлёт только события, заменяет поток-брандспойт на 2 Mbps тонкой струйкой в килобиты в секунду – снижение далеко за 99% в трафике, нужном, чтобы понять, что камера видит. Видео всё ещё можно записывать, но анализу больше не нужно никуда ехать.
Именно это свойство позволяет edge AI масштабироваться. Поставьте на объект 100 камер и отправляйте их видео куда-то на анализ – и вам нужна полоса под 100 видеопотоков; пусть каждая камера анализирует себя и шлёт события – и трафик анализа почти незаметен. Полную арифметику разберём ниже.
Чтобы события были полезны, камера и принимающее их ПО должны договориться о формате – и для этого есть отраслевой стандарт. ONVIF – это общий язык, позволяющий камерам и ПО разных производителей работать вместе, и один профиль ONVIF сделан под аналитику. ONVIF Profile M стандартизирует метаданные и события, которые производит аналитика: общую классификацию объектов, а также определённые метаданные для геолокации, транспорта, номерного знака, лица и тела человека, и интерфейсы событий для подсчёта объектов, распознавания номеров и распознавания лиц (ONVIF, Profile M Specification v1.1, 2024). Важная для нас деталь – в самой области профиля: устройство, соответствующее Profile M, может быть edge-устройством, например IP-камерой, а его метаданные могут идти тремя путями – внутри видеопотока, через сервис событий ONVIF или по MQTT, лёгкому протоколу обмена сообщениями, распространённому в системах интернета вещей (ONVIF). Пример самого ONVIF показателен: камера с Profile M детектирует человека в комнате и шлёт событие по MQTT на платформу здания, а та регулирует термостат. Камера стала датчиком не только для охраны.
Та же осторожность, что и везде с ONVIF: соответствие гарантирует базу, а не каждую функцию. Камера и VMS, обе поддерживающие Profile M, надёжно обменяются стандартными метаданными; особая аналитика вендора или проприетарный атрибут всё ещё могут требовать его собственного SDK. Считайте профиль полом, на котором стоят обе стороны, а не потолком. Весь слой стандартов разобран в события, метаданные и интерфейс аналитики ONVIF, а коммерческий обзор – в профилях ONVIF в системах безопасности.
Разбор на числах: сколько полосы экономит модель на камере
Числа делают экономию конкретной. Возьмём одну камеру на 4 мегапикселя с примерно 2 Mbps непрерывного видео H.265 и спросим, сколько данных нужно отправить её анализу при двух раскладах.
Отправлять видео на анализ в другое место. Камера должна непрерывно стримить полный поток, потому что нельзя детектировать на видео, которое не получено:
2 Mbps × 1 месяц ≈ 2 Mbps × 2,6 млн секунд ÷ 8 ≈ 648 ГБ на камеру в месяц.
Анализировать на камере и слать только события. Камера смотрит свой поток и отдаёт метаданные. Даже при насыщенном среднем в несколько килобит в секунду:
~5 kbps × 2,6 млн секунд ÷ 8 ≈ 1,6 ГБ на камеру в месяц.
Та же камера, те же детекции – и падение примерно с 648 ГБ до меньше 2 ГБ в месяц, более чем на 99% меньше данных для анализа. Масштабируйте на объект из 100 камер, и разница – это выбор между провижинингом под примерно 200 Mbps непрерывной отдачи и почти ничем. Само видео по-прежнему можно писать локально; исчезает необходимость возить его только ради того, чтобы понять. Более глубокая экономика – как это связано с хранением и месячной стоимостью на камеру – разобрана в экономике видеоаналитики и хранении и расчёте ретенции.
Есть ещё три выигрыша, приходящих с тем, что работа остаётся на камере, и каждый – прямое следствие того, что данные никуда не едут. Задержка – пауза между событием и реакцией – падает до десятков миллисекунд, потому что нет сетевого round-trip к серверу; для пересечения периметра, которое должно немедленно включить отпугивание, эта скорость и есть смысл. Приватность улучшается по построению, потому что узнаваемое видео может остаться внутри камеры, а наружу уходят лишь абстрактные метаданные – уровень, который возит меньше всего данных, и раскрывает меньше всего. И устойчивость растёт: камера, детектирующая сама, продолжает работать при обрыве сети или отказе сервера, где система, зависящая от облака, слепнет.
Пределы edge-вычислений
Всё выше – аргумент за камеру. Вот аргумент против того, чтобы просить у неё слишком много, – набор потолков, в которые упирается любой честный edge-AI дизайн. Ни один не является дефектом, который залатают; каждый следует из бюджета в несколько ватт, поделённых на всех.
Первый потолок – вычисления. Единицы-десятки TOPS камерного NPU хорошо крутят одну-две лёгкие модели. Он не потянет большую модель, или много моделей разом, или тяжёлую новую архитектуру каждый квартал. Запас реален, но конечен, и «добавь ещё аналитику» – запрос, в котором чип может отказать.
Второй потолок – память, буквальный смысл процитированной выше строки Axis: камера крутит модели «любого размера, лишь бы они помещались в память устройства». У камеры мало рабочей памяти, и модель, слишком большая для загрузки, просто не запустится – нельзя подкачать ещё, как на сервере.
Третий потолок – модель в основном фиксирована после выбора. Обновить аналитику на парке камер – значит толкать новую прошивку или модели на сотни устройств по сети, по одному, у каждого свои нюансы совместимости – реальная эксплуатационная задача, а не клик. Камера, которая сегодня хорошо детектирует людей, но не потянет нужную через год модель поведения, – частый и дорогой сюрприз; вычисления уже заняты.
Четвёртый потолок – точность ограничена тем, что помещается. Никакой «100% точности» в видеоаналитике нет ни на каком железе, а маленькая модель камеры ставит потолок ниже, чем датацентровая. Качество детекции описывают два числа в противоречии – precision (доля тревог, которые реальны) и recall (доля реальных событий, которые пойманы), – и оба зависят от сцены, освещения, ракурса и настройки. Маленькая модель, хорошо настроенная под чистую сцену, может быть отличной; та же модель в бликах, под дождём или в толпе пропустит больше. Просите у любого вендора precision и recall в ваших условиях, а не единственное «99%». Реалистичные диапазоны по уровням разобраны в задержке и точности по уровням.
Последний потолок – охват. Камера видит свой вид и больше ничего. Вести одного человека через двадцать камер (re-identification), искать в месяце записей «красный грузовик» или крутить большую vision-language модель, отвечающую на открытые вопросы о сцене, – для этого нужно видеть сквозь камеры и сквозь время, чего одна камера структурно не может. Эта работа – для следующих уровней: выделенного edge-сервера или ИИ-приставки в локальной сети или облачной видеоаналитики, когда эластичные централизованные вычисления стоят полосы и денег.
Частая ошибка, которой стоит избегать
Самый дорогой паттерн, который мы видим, – покупка «ИИ-камер» по ярлыку, а не по спецификации. «Edge AI» на datasheet ничего не говорит о том, сколько у чипа TOPS, какие модели он способен загрузить, сколько крутит разом и – что забывают – можно ли эти модели обновить после покупки. Камера, выбранная за то, что сегодняшнее демо детектировало человека, становится тупиком в тот момент, когда проекту нужна классификация транспорта, поведение «праздношатание» или более новый детектор, – потому что вычисления и память уже потрачены. Лечение – относиться к чипу как к закупочному решению: спросите производительность NPU в TOPS, точные модели и частоту кадров, сколько моделей идёт параллельно, путь обновления модели и прошивки, и precision и recall в освещении как у вас. Камера, которую можно перенастроить, – это актив; та, которую нельзя, – устройство с фиксированной функцией под ярлыком ИИ.
Где здесь Фора Софт
Фора Софт строит ПО для видео реального времени, стриминга и компьютерного зрения с 2005 года, на счету 250+ сданных проектов, и аналитика на камере – слой, вокруг которого мы постоянно проектируем, потому что потолок чипа – это жёсткий вход, а не деталь. К нам приходят, когда штатная модель камеры не держит точность, которую требует сцена; когда парку нужна детекция на камере, питающая сервер или облако для межкамерной работы, которую устройство не тянет; или когда узнаваемое видео должно остаться на камере ради правила резидентности. Мы строим конвейер под бюджет – квантованный детектор под размер NPU, метаданные ONVIF Profile M в VMS и только более тяжёлый анализ, вынесенный с устройства, – и ведём разговор с того, как система ведёт себя под реальной нагрузкой: какую задержку вы удержите, какую полосу реально потребляете и какие реалистичные precision и recall в вашем освещении, а не в демо. Дизайн, уважающий несколько ватт на конце кабеля, лучше того, что их игнорирует.
Ключевые выводы
- Умная камера – это маленький компьютер с NPU, отправляющий смысл, а не пиксели.
- Мощность одного кабеля PoE – часто ~13 Вт на всех – ограничивает ИИ на камере.
- Камеры крутят маленькие квантованные детекторы (лёгкие YOLO, MobileNet-SSD) на 15–30 fps.
- Отправка метаданных вместо видео режет трафик анализа более чем на 99%.
- ONVIF Profile M несёт события камеры в VMS через поток, сервис событий или MQTT.
- Тяжёлое, межкамерное и архивное превышает камеру и уходит на сервер или в облако.