Видеоаналитика: на краю или в облаке – гид

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

Кратко

Система видеонаблюдения, в которой «есть аналитика», всё равно должна ответить на один архитектурный вопрос раньше любого другого: где именно идёт анализ – внутри камеры, на сервере в здании или в облаке – потому что это одно решение о размещении задаёт задержку, трафик интернета, форму затрат и риски приватности на всю жизнь системы. Детекция на камере (край) даёт реакцию за миллисекунды и отправляет наверх только крошечные метаданные, но ограничена скромным ИИ-чипом камеры; детекция в облаке даёт неограниченные вычисления и централизованное управление, но означает постоянную отдачу всего видео каждой камеры в интернет и хранение узнаваемых кадров на чужих серверах. Затраты ведут себя как два разных зверя: край – это в основном разовая покупка железа, которое затем работает почти бесплатно, а облако – это плата за камеру, которая не кончается и в которой доминируют аренда GPU и трафик отдачи. Эта статья проходит все три уровня простым языком, показывает арифметику трафика и облачного GPU для объекта на 40 камер, объясняет, почему большинство серьёзных систем делят работу, и даёт путь решения, который можно защитить и перед финансовым директором, и перед специалистом по защите данных.

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

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

Одно решение, три места для анализа

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

Держите одну вещь отдельно по ходу. Это не то же решение, что и где физически живёт ваша видеоплатформа (Video Management System, VMS) – софт, который записывает и управляет всеми камерами. У того вопроса о развёртывании (on-premises, облако или гибрид) своя статья – on-prem, облако и гибрид VMS. Можно писать локально, но анализировать в облаке, или писать в облаке, но детектировать на камере. Эта статья – про вычисления анализа конкретно, потому что именно у них самый тяжёлый аппетит к процессору, и потому именно их размещение двигает счёт.

Полезно держать в уме пять вопросов, проходя каждый уровень, потому что это пять счетов, которые каждый уровень платит в своей пропорции:

• Задержка – как быстро система реагирует, в миллисекундах, от события до тревоги.
• Трафик – сколько постоянной отдачи в интернет потребляет уровень.
• Форма затрат – платите один раз (железо) или вечно (аренда).
• Приватность и резидентность – покидает ли узнаваемое видео здание и какие законы до него дотягиваются.
• Возможности – насколько тяжёлую модель уровень реально тянет и с какой точностью.

Держите эти пять в поле зрения – и три уровня перестанут быть модными словами и станут ясным набором компромиссов.

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

Уровень 1 – Аналитика на камере (edge)

Одной строкой: маленький ИИ-чип внутри камеры сам выполняет детекцию, поэтому камера отдаёт смысл – «человек», «машина», «линия пересечена» – вместо сырых пикселей.

«Край» (edge) – это просто значит, что вычисления происходят на краю сети, там, где рождаются данные, – здесь, внутри камеры. Современная умная камера несёт выделенный NPU (Neural Processing Unit) – чип, построенный, чтобы эффективно считать математику ИИ-модели, и измеряемый в TOPS (триллионы операций в секунду). Числа реальны и актуальны: процессоры камер вроде серии CV у Ambarella дают свыше 20 TOPS для машинного зрения на устройстве (Ambarella), камеры Axis крутят deep-learning-аналитику на собственном кремнии ARTPEC-8, а ускоритель размером с монету Hailo-8 упаковывает 26 TOPS примерно в 2,5 ватта (Hailo). Этого достаточно, чтобы запустить квантованный детектор объектов – модель, ужатую под маленькое железо, – на 15–30 кадрах в секунду внутри камеры.

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

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

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

Цена всего этого – возможности. У чипа камеры фиксированный, скромный бюджет вычислений и потолок по питанию и теплу, поэтому он крутит одну-две лёгкие модели, а не большую или часто обновляемую. Нельзя легко запустить тяжёлую меж-камерную модель рассуждения или менять архитектуру каждый квартал на железе, прикрученном к стене. И точность, которую вы получаете, ограничена тем, что помещается. Это история про развёртывание и трафик; как сами модели детекции строят, обучают и ужимают под камеру, – это слой инженерии моделей, разобранный в развёртывании edge против облака в реальном времени в нашем разделе AI for Video Engineering – эта статья остаётся на том, где живут вычисления, а не как сделана модель.

Типичный провал: покупка «ИИ-камер» без проверки, какие модели реально тянет чип и обновляются ли они, – камера, которая сегодня хорошо детектирует людей, но не может быть обновлена до модели поведения или транспорта, которая понадобится через год, потому что бюджет вычислений уже занят.

Уровень 2 – Edge-сервер (локальная ИИ-приставка)

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

Edge-сервер – средний уровень, и он существует, потому что две крайности каждая что-то оставляют на столе. Камера быстрая и приватная, но слабая; облако мощное, но далёкое и прожорливое к трафику. ИИ-коробка на объекте – часто на базе компактного ИИ-компьютера вроде NVIDIA Jetson AGX Orin, дающего до 275 TOPS в маленьком модуле (NVIDIA), или стоечного сервера с полноценным инференс-GPU – стоит в здании, тянет полнокачественные потоки по локальной сети и крутит модели куда тяжелее, чем смогла бы любая камера. Один Jetson AGX Orin тянет аналитику в реальном времени примерно по восьми потокам камер сразу, на каждый – несколько ИИ-моделей (NVIDIA); GPU-сервер масштабируется дальше.

Поскольку edge-сервер стоит в локальной сети (LAN), тяжёлое видео ходит только внутри здания, где трафик фактически бесплатен и быстр – гигабитная и десятигигабитная проводка обычна. Сорок камер могут лить полные потоки в коробку весь день, не трогая интернет-канал. Наверх – к центральной VMS или в облако – нужно отправить только результаты, те же компактные метаданные и клипы событий, ровно как у аналитики на камере. Так edge-сервер сохраняет вычислительную мускулатуру облака и дисциплину трафика края одновременно.

Он сохраняет и большую часть преимущества края по приватности: узнаваемое видео остаётся на железе, которым вы владеете, в одной юрисдикции, и вы выбираете, какие абстрактные данные, если вообще, уходят. Он добавляет задержку в десятки миллисекунд – короткий прыжок по LAN и обратно, – что медленнее камеры, но куда быстрее облака, и быстро достаточно почти для любой реакции наблюдения. И он отвечает на потолок возможностей камеры: можно крутить модели побольше, больше их числом, и обновлять централизованно на одной коробке вместо перепрошивки сотни камер.

Цена – коробка, которую надо купить, питать и обслуживать. Edge-сервер – реальная капитальная покупка, он ест питание и греет, и он точка отказа, если не заложить вторую. Вы также размеряете его вычисления заранее: упакуете слишком много камер или слишком тяжёлую модель на одну коробку – и частота кадров падает, а детекции опаздывают. GPU-экономика и преимущества по резидентности данных разобраны в edge-серверах и локальных ИИ-приставках.

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

Уровень 3 – Облачная аналитика

Одной строкой: камеры шлют полное видео в интернет в дата-центр провайдера, где мощные эластичные серверы крутят аналитику, а вы платите за вычисления и трафик помесячно.

Облачная аналитика – уровень с самой большой сырой мощью и наименьшими физическими ограничениями. У дата-центра фактически неограниченные GPU, которые можно арендовать по часам, так что можно крутить самые большие и новые модели, применять несколько к каждому потоку, дообучать на своих кадрах и рассуждать сразу по многим камерам и многим площадкам – тяжёлый анализ с длинным горизонтом, который камере и edge-коробке не по зубам. Управление по природе центральное: одна консоль, все площадки, модели обновляются в одном месте. Для аналитики, которой реально нужен масштаб дата-центра – большие vision-language-модели, меж-площадочный поиск, форензическая переобработка архива, – облако и есть их дом.

Первая цена этой мощи – трафик, и это ограничитель, решающий большинство облачных проектов. Чтобы анализировать видео в облаке, видео должно туда попасть – постоянно, для каждой камеры, потому что облако не детектирует на потоке, которого не получило. Одна 1080p-камера потребляет примерно 1–2 Мбит/с отдачи круглосуточно; 4-мегапиксельная – около 2–4 Мбит/с. Умножьте на число камер, и сумма растёт быстро. (Полную арифметику трафика и хранения смотрите в как работает хранение: расчёт ретенции.)

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

Третья цена – задержка. Отправить кадр в дата-центр, дождаться модели и получить ответ – это добавляет сетевой поход туда-обратно, обычно сотни миллисекунд, иногда больше при заторе или расстоянии, поверх самой обработки. Для пакетного инсайта («сколько машин въехало сегодня») эта задержка не важна; для отпугивания в реальном времени она может быть разницей между остановкой события и просто его записью.

Четвёртая цена – приватность и резидентность, и для наблюдения она самая острая. На облачном уровне узнаваемое видео реальных людей покидает здание и оседает на серверах третьей стороны, возможно, в другой стране. По Общему регламенту ЕС о защите данных (GDPR, Reg. (EU) 2016/679) эти кадры – персональные данные, а передача персональных данных за пределы ЕС законна, только если для страны назначения есть решение об адекватности (ст. 45) или приняты надлежащие гарантии вроде стандартных договорных условий (ст. 46) – правила главы V. Если облачная аналитика выполняет распознавание лиц или любую биометрическую идентификацию, планка поднимается выше: биометрические данные, обрабатываемые «с целью однозначной идентификации физического лица», – это особая категория по ст. 9 GDPR, которую Европейский совет по защите данных считает несущей повышенный риск и обычно требующей явного согласия и оценки воздействия на защиту данных (DPIA) (EDPB, Guidelines 3/2019; EDPB, Guidelines 05/2022). Практическое следствие конкретно: с облачной аналитикой вы должны знать, в каком регионе лежит видео, и подтвердить законное основание, прежде чем отдать наверх хоть один кадр. Это инженерный гид, а не юридическая консультация; уточняйте детали у квалифицированного юриста.

Типичный провал: пилот, который безупречно анализировал четыре камеры, а на сорока забивает канал отдачи, крутит четырёхзначный месячный счёт за GPU, который никто не заложил, и тихо перемещает биометрические кадры в юрисдикцию, которую политика приватности запрещает.

Пять счетов рядом

Вот всё сравнение на одном экране – версия, которую держат рядом при оценке. Читайте по столбцу, если уже знаете своё ограничение (жёсткая цель по задержке, тонкий канал, правило резидентности), или по строке, если взвешиваете уровни поровну.

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

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

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

Пример: 40 камер, три уровня

Числа делают компромиссы конкретными, поэтому оценим один реальный объект – 40 камер, каждая 4-мегапиксельная на ~2 Мбит/с в H.265 – с непрерывной детекцией объектов на каждом уровне. Арифметика проста, и вы контролируете каждый ввод.

Трафик к аналитике. Это величина, которая кусается, только когда видео должно пересечь интернет ради анализа.

Для облачной аналитики каждая камера отдаёт полное видео наверх, постоянно:

2 Мбит/с × 40 камер = 80 Мбит/с постоянной отдачи, 24 часа в сутки.

Эти 80 Мбит/с – ограничитель: они сами по себе могут забить бизнес-канал и потребовать апгрейда ещё до того, как оплачена хоть одна детекция.

Для аналитики на камере и на edge-сервере полное видео никогда не пересекает интернет. Камеры анализируют локально (или отдают видео коробке в LAN), а наверх уходят только метаданные и редкий клип события. Если каждая камера отдаёт пару событий в минуту, метаданные – порядка килобит в секунду, поэтому восходящий трафик всего объекта падает с 80 Мбит/с примерно до 2 Мбит/с или меньше – снижение намного больше чем на 95%. Те же камеры, те же детекции, другое место для «смотрения».

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

Счётчик облачного GPU. Теперь повторяющаяся стоимость вычислений, которую добавляет облако. Облачные ИИ-серверы арендуют по часам. Базовый инференс-инстанс – AWS g6.xlarge с одним NVIDIA L4 GPU – стоит около $0,80 в час по on-demand (AWS). Работая каждый час месяца:

$0,80 × 730 часов ≈ $584 за GPU в месяц.

Сколько камер тянет один GPU, зависит от модели и частоты кадров; детекцию в наблюдении часто крутят на 5–15 fps, а не 30, что растягивает GPU дальше. Возьмём консервативно 15 потоков на GPU:

$584 ÷ 15 потоков ≈ $39 за камеру в месяц – только за вычисления детекции.

Для всех 40 камер вы арендуете около трёх таких GPU:

3 GPU × $584 ≈ $1750 в месяц ≈ $21 000 в год – до апгрейда канала, до хранения, до egress.

Есть ещё одна облачная статья, о которой забывают: egress, плата за выход данных из облака. Для ориентира AWS берёт около $0,09 за ГБ за исходящий интернет-трафик после первых 100 ГБ (AWS). Вытяните месяц видео одной камеры обратно (≈ 648 ГБ) – и это примерно $58 egress поверх всего остального.

Edge-уровни, напротив, – в основном разовая трата. Аналитика на камере встроена в цену камеры: умная камера дороже «глупой», но детекция потом работает за $0 в месяц. Edge-сервер – капитальная покупка в несколько тысяч долларов, которая, раз куплена, тоже работает только за стоимость питания. Форма та же, что нашла статья о моделях развёртывания для хранения: высокая ступень, затем плоская линия для края; низкий старт, затем бесконечный подъём для облака. Для непрерывной тяжёлой аналитики облачный счёт за вычисления обгоняет стоимость edge-железа в первый же год.

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

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

Задержка и точность: честные диапазоны

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

Задержка ограничена физикой, и уровни расходятся чисто. Детекция на камере реагирует за десятки миллисекунд, потому что ничего не покидает устройство. Edge-сервер добавляет короткий прыжок по LAN, всё ещё десятки миллисекунд. Облачная аналитика добавляет интернет-поход – обычно сотни миллисекунд, больше при расстоянии или заторе – ещё до старта модели. Для дашборда, считающего сегодняшний поток, эта задержка незаметна. Для вторжения на периметр, которое должно зажечь свет и сирену до того, как нарушитель дойдёт до двери, она – всё. Решите сначала, ваша задача – реакция в реальном времени или инсайт постфактум, потому что это одно может определить уровень.

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

Точность – там, где кусается редакционное правило раздела: «100% точности» в видеоаналитике нет ни на одном уровне. Качество детекции отчитывают двумя числами в напряжении – precision (точность, доля тревог системы, которые реальны) и recall (полнота, доля реальных событий, которые система ловит), – и оба зависят от сцены, освещения, ракурса камеры и того, как настроена модель. Для грубого ориентира хорошо настроенный детектор объектов может дать precision выше 0,8 (мало ложных тревог) и recall около 0,9 (мало пропусков) в благоприятной сцене и заметно меньше в бликах, дожде или толпе. Уровень влияет на потолок: облако крутит более тяжёлую и точную модель, чем чип камеры, но тяжёлая модель, плохо настроенная под сцену, всё равно проигрывает лёгкой, настроенной хорошо. Реалистичные диапазоны precision и recall по уровням разбирает задержка и точность по уровням; инженерия моделей за этими числами живёт в нашем разделе AI for Video Engineering. Дисциплина отсюда: спрашивайте у любого поставщика precision и recall в вашем освещении, никогда не одиночное «99%».

Где стандарт: ONVIF Profile M – это мост

Одна успокаивающая мысль связывает три уровня, и это часть, которой владеет этот раздел. Где бы ни шёл анализ – камера, edge-коробка или облако, – результат должен дойти до вашей VMS в форме, которую она понимает, и для ровно этого есть отраслевой стандарт. ONVIF – это общий язык, позволяющий камерам и софту разных производителей работать вместе, и один профиль ONVIF создан для аналитики. ONVIF Profile M стандартизирует метаданные и события, которые производит аналитика: классификацию объектов и конкретные метаданные для геолокации, транспорта, номерного знака, лица и тела человека, плюс интерфейсы событий для подсчёта объектов, распознавания номеров и распознавания лиц (ONVIF, Profile M Specification v1.1, 2024).

Деталь, делающая Profile M мостом для этой статьи, – в его собственном определении: продукт, соответствующий Profile M, может быть edge-устройством (например, IP-камерой) или сервисом (например, серверным или облачным приложением), а клиентом Profile M может быть VMS, NVR или облачный сервис (ONVIF). Простыми словами, стандарт спроектирован так, чтобы один и тот же интерфейс метаданных работал, произошла ли детекция на камере, на edge-сервере или в облаке. Метаданные могут идти через видеопоток, через службу событий ONVIF или по MQTT – лёгкому протоколу обмена сообщениями, частому в системах интернета вещей, – так что edge-камера может даже толкнуть детекцию прямо в платформу автоматизации здания (ONVIF). Выбор уровня, значит, не обязан запирать вас в чужой приватный формат: если аналитика и VMS обе говорят на Profile M, детекции приходят в стандартной форме независимо от того, где их посчитали.

Та же осторожность, что и везде с ONVIF: соответствие гарантирует базовый уровень, а не каждую функцию. Два продукта, разделяющие Profile M, надёжно обменяются стандартными метаданными; особая аналитика поставщика или проприетарный атрибут всё равно могут требовать его собственного SDK. Считайте профиль полом, на котором стоят обе стороны, а не потолком. Полный слой стандартов – в событиях, метаданных и интерфейсе аналитики ONVIF и в коммерческом обзоре профили ONVIF в системах безопасности.

Как выбрать: путь решения

Уровни ясны; выбор – короткая серия вопросов, взятых по порядку. Начните с жёстких ограничений, которые исключают уровень целиком, и только потом взвешивайте мягкие предпочтения.

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

Вторые ворота – задержка. Решите, задача – реакция в реальном времени или инсайт постфактум. Если миллисекунды двигают действие – отпугивание, аварийную остановку, немедленную тревогу, – анализ должен быть на краю (камера или сервер). Если задача – отчётность, поиск или анализ трендов, задержка облака безвредна, а его мощь желанна.

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

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

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

Частая ошибка, которой стоит избегать

Самый дорогой паттерн, что мы видим, – выбор уровня по демо, а не по развёртыванию – и у него два лица. Первое – поднять всё в облако, потому что пилот на четыре камеры прошёл легко, а потом обнаружить на сорока, что канал отдачи забит, аренда GPU имеет запятую, egress появляется, когда следователь тянет кадры, а биометрическое видео тихо пересекло границу, которую политика запрещает. Второе – обратный рефлекс: настаивать на чистой аналитике на камере для каждой задачи, а потом не мочь запустить более тяжёлый меж-камерный поиск, который реально нужен операциям, потому что настенный чип камеры никогда его не потянул бы. Лекарство – дисциплина, вокруг которой построена статья: решать по пяти счетам против вашей цели по задержке, вашего канала, ваших правил комплаенса и вашей модели, на полном масштабе, а не на пилотном. Для большинства систем ответ – смесь, и это не компромисс; это дизайн, совпадающий со счетами.

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

Фора Софт строит софт реального времени, стриминга и компьютерного зрения с 2005 года, в 250+ выпущенных проектах, и деление «край против облака» – решение, которое мы принимаем с клиентами постоянно, потому что готовые платформы аналитики навязывают свой ответ. Команды приходят к нам, когда модели на камере не тянут точность, которую требует сцена, когда мультиплощадочному парку нужна edge-детекция, питающая облачный поиск без отправки каждого потока наверх, или когда биометрическая аналитика должна остаться на объекте, чтобы удовлетворить правило резидентности, которое облачный продукт не может выполнить. Мы строим кастомный конвейер аналитики – детекция на камере или edge-сервере, метаданные ONVIF Profile M в VMS и только важные события в облако – и рамка, с которой мы ведём, всегда о том, как система ведёт себя под реальной нагрузкой: какую задержку вы держите, какой трафик реально потребляете и реалистичные precision и recall в вашем освещении, а не в демо. Дизайн, переживающий худший день, бьёт тот, что блестит на пилоте.

Главное

• Где идёт аналитика – камера, edge-сервер или облако – задаёт задержку, трафик, форму затрат и приватность раньше любой функции.
• Аналитика на камере реагирует за миллисекунды и шлёт только метаданные, но крутит лишь лёгкие модели на фиксированном чипе.
• Edge-сервер держит всё видео в LAN и крутит тяжёлые модели на объекте – мощная, приватная, экономная по трафику середина.
• Облачная аналитика даёт больше всего мощи, но гонит каждую камеру наверх 24/7 и платит за GPU и трафик каждый месяц.
• Облачный анализ 40 камер может стоить ~$21 000/год только за GPU, до трафика, хранения и egress.
• Решайте приватность/резидентность и задержку первыми; большинство серьёзных систем в итоге делят работу между краем и облаком.

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

• Карта видеоаналитики: что система может детектировать
• Гибридный паттерн обработки edge-cloud
• On-prem, облако и гибрид VMS – три модели развёртывания