Представим вполне разумного заказчика. На предприятии несколько лет работает видеоаналитика. Научились отличать нужное событие от похожих, разобрались с ракурсами камер, настроили зоны, пережили первые ложные тревоги. Служба эксплуатации наконец перестала воспринимать каждое уведомление как просьбу сходить и проверить, что опять сломалось.
Потом предприятие решает заменить программную платформу. Причины обычные: другой видеокомплекс, требования ИТ, объединение площадок, новые условия поддержки. Камеры остаются. Задача остаётся. Работать аналитика должна по-прежнему.
И тут выясняется, что переносить почти нечего. Есть файл нейросети, несколько настроек и предложение заново оплатить интеграцию. А иногда — заново разработать весь сценарий. Получается странная покупка: заказчик инвестировал в решение своей задачи, а приобрёл право пользоваться им только внутри определённой коробки.
Я считаю, что мы как отрасль слишком привыкли к такому положению дел. Хотелось бы договориться о другом принципе:
Разработчик должен иметь возможность продавать своё решение на любой совместимой платформе, заказчик — выбирать платформу без потери уже оплаченной аналитики, а интегратор — переносить работающие решения, а не разрабатывать их заново.
Вокруг этого принципа мы в VL развиваем VL Exchange — инициативу открытого межвендорного обмена моделями и исполняемыми сценариями видеоаналитики. Это наше предложение рынку и экспериментальные спецификации. Отрасль их ещё не согласовала, универсальную совместимость мы ещё не доказали. Но саму проблему уже можно обсуждать предметно, со спецификациями, пакетами и испытаниями.
Нейросеть переехала. А решение где?
Возьмём условную задачу: человек оказался в опасной зоне работающего оборудования. Именно условную — здесь я не описываю конкретное внедрение и не обещаю готовый экспорт такого детектора.
Сначала модель находит человека. Затем система определяет положение относительно зоны. Нужно решить, какую точку объекта проверять: центр прямоугольника, точку опоры, результат геометрического преобразования. Дальше появляются состояние оборудования, допустимое время присутствия, кратковременные перекрытия, повторные уведомления. А в конце — событие, которое поймёт служба охраны труда и примет корпоративная система.
Уберите из этой цепочки несколько договорённостей — и внешне похожая аналитика начнёт вести себя иначе. Одна реализация считает нарушение по первому кадру, другая ждёт устойчивого наблюдения. Одна сохраняет состояние при пропуске детекции, другая сбрасывает таймер. Обе честно рисуют человека и зону. Результат для заказчика разный.
Поэтому детектор, модель и готовый сценарий нужно различать. Модель выполняет определённое преобразование входных данных. Бизнес-детектор может использовать несколько моделей и дополнительную логику. Сценарий связывает наблюдения с контекстом, временем и правилами формирования событий. Количество файлов с весами мало говорит о количестве решённых задач.
При переносе важно сохранить всю нужную цепочку: входные данные, подготовку изображения, вычисление модели, обработку результата, контекст, сценарную логику и событие. Пока часть этой цепочки существует только в голове разработчика исходной системы, совместимость остаётся личной договорённостью между двумя инженерами.
Но у нас же есть ONNX, API и ONVIF
Есть, и это хорошая новость. Без существующих технологий обмен был бы ещё труднее. Вопрос в том, на каком уровне они помогают.
ONNX описывает вычислительный граф, операции, входы и выходы модели. Часть подготовки данных и обработки результата можно включить в граф. На практике часть часто остаётся снаружи. Тогда передать файл недостаточно: принимающая сторона должна знать порядок каналов, нормализацию, масштабирование, интерпретацию выхода и соответствие классов.
Любимая инженерная ловушка — RGB и BGR. Формы совпали, типы совпали, модель запускается, ошибок в журнале нет. Просто вход теперь означает немного другое. Особенно неприятны такие ошибки на задачах, где результат выглядит правдоподобно и неправильность обнаруживается через некоторое время.
API помогает вызвать уже работающее решение и забрать ответ. Иногда этого достаточно, и переносить исполнение вообще не нужно. Но если исходную платформу выводят из эксплуатации или обработка должна уйти в изолированный контур, наличие API ещё не объясняет, как запустить тот же компонент в другой среде.
RTSP управляет доставкой потоковых данных. Он помогает получить видео, но не определяет поведение прикладного сценария. У ONVIF область шире, чем подключение камеры: Profile M включает интерфейсы метаданных, событий и конфигурации аналитики. Эти возможности полезны для интеграции. Передача исполняемой логики с зависимостями и проверочным набором остаётся отдельной задачей.
Мы не предлагаем выкинуть существующие форматы и придумать всё заново. VL Exchange должен использовать их там, где они подходят, и описать недостающие договорённости вокруг переносимого решения. Собственное расширение файла ради собственного расширения файла рынку вряд ли требуется.
За что приходится платить второй раз
В переносе обычно повторяется вполне конкретная работа. Нужно выяснить фактический интерфейс модели, написать адаптер, сопоставить классы и координаты, восстановить правила сценария, разобраться с временем и состоянием. Затем собрать проверки и доказать, что система выдаёт ожидаемые события. Иначе получается новый алгоритм с тем же названием.
Я намеренно не буду обещать, что открытый пакет сократит эту работу на определённый процент. У нас нет основания объявлять общую экономию для любого проекта. На небольшом классификаторе и на сложном сценарии с трекингом цена переноса разная.
Можно, однако, отделить работу, которая действительно нужна на новом объекте, от повторного восстановления уже известной логики. Проверка ракурсов камер, производительности и качества на видео заказчика никуда не исчезает. Заново угадывать порядок классов или смысл таймера при каждом переносе совершенно необязательно.
Для интегратора это возможность накапливать работающие решения и компетенции, которые переживают смену платформы. Для разработчика — продавать один продукт через несколько каналов, сохраняя ответственность за его поведение. Для заказчика — выбирать инфраструктуру и условия обслуживания, сохраняя полезность прежних вложений.
Здесь есть коммерческая оговорка, которую нельзя прятать в примечания. Формат пакета не выдаёт права на использование чужой разработки. Чтобы оплаченная аналитика могла переехать, лицензия правообладателя должна разрешать такой перенос: на каких условиях, на какую установку, с каким числом одновременных запусков и порядком переоформления. Этот принцип нужно закреплять и технически, и в договоре. Иначе у нас будет прекрасно переносимый архив, который нельзя законно запустить.
Сопротивляться переносу становится всё страннее
На мой взгляд, появление ИИ делает ставку на трудность переноса всё менее убедительной. Когда у инженера есть разрешённый доступ к коду и документации, ИИ помогает разобрать интерфейс, подготовить адаптер, преобразовать структуры данных, предложить проверки. Работа, ради которой раньше приходилось долго разбираться в чужом проекте в одиночку, получает вполне практичного помощника.
Это инженерная оценка направления развития, а не обещание, что любая аналитика теперь переезжает за вечер. У меня нет надёжной общей метрики экономии именно на переносе сценариев видеоаналитики. ИИ может аккуратно переписать функцию и всё равно потерять смысл временного окна, поведение при обрыве потока или условие выдачи события. Коммерческих прав на чужую разработку он тоже не добавляет. Адаптер нужно проверять, лицензию — соблюдать.
При этом ИИ и low-code не обязаны конкурировать. В визуальном редакторе VL ИИ может помогать собирать или изменять пайплайн, а разработчик — видеть, какие блоки используются, как они связаны и где проходит логика обработки. Мне такое сочетание кажется удобнее для обсуждения и сопровождения, чем получать большой объём сгенерированного кода и каждый раз разбираться, что он делает.
Повторный запрос к ИИ не гарантирует, что получится тот же сценарий. А чтобы понять и проверить сгенерированный код, может понадобиться его ревизия. Визуальная схема тоже не освобождает от проверки: внутри блока может быть сложная логика, а правильные на вид связи ещё не гарантируют правильное событие. Нужно различать повторяемость генерации и повторяемость работы уже зафиксированного решения: для последней важны версии компонентов, среда и входные данные.
Но защищать бизнес главным образом тем, что другой инженер долго не разберётся в нашей интеграции, становится всё страннее. Можно каждый раз восстанавливать договорённости с помощью всё более сильных инструментов. Можно один раз явно описать их и проверять выполнение. Второй путь выглядит разумнее для рынка: меньше ресурсов уходит на повторное выяснение того, что производитель уже знает о своём продукте.
В нашей же отрасли есть близкая параллель. ONVIF прямо описывает возможность сочетать совместимое ПО и устройства разных производителей, сохраняя при необходимости собственные API для дополнительных функций. Общий интерфейс не требует одинаковых камер. Для покупателя расширяется выбор, интегратор получает понятную основу подключения, производитель — возможность включиться в существующую систему. Отличаться качеством изображения, эксплуатацией и дополнительными возможностями никто не запрещает.
У разработчиков программ есть другой знакомый пример — Open Container Initiative. OCI разделяет спецификации образа, исполнения и распространения. Благодаря согласованному описанию поставки инструменты могут работать с общим форматом вместо собственного варианта упаковки для каждой пары систем. Из этого не следует, что любой контейнер запустится на любой архитектуре или что все облака одинаковы. Согласованный слой просто позволяет строить разные продукты поверх общей основы.
Даже привычный USB полезно вспомнить именно как инженерную дисциплину. USB-IF развивает совместимость устройств и проверки соответствия. Общие правила подключения оставляют производителю множество способов сделать хорошее или плохое устройство. А наличие проверок напоминает: одного похожего разъёма для доказательства совместимости недостаточно. С модельным пакетом ситуация очень похожая — нужен определённый профиль и воспроизводимый тест.
Эти примеры не доказывают, что VL Exchange автоматически станет успешным стандартом. Они показывают рабочий принцип: общий интерфейс способен расширять выбор и уменьшать повторную интеграционную работу, сохраняя пространство для конкуренции. Выигрыш не обязан одинаково распределяться между всеми участниками. Тем, кто зарабатывает преимущественно на трудности выхода из своей системы, переносимость может быть неудобна. Но для конкуренции качеством модели, продукта, поддержки и внедрения она создаёт больше возможностей.
Что предлагаем передавать
В публичной части VL Exchange два формата. VL Model Package, или VLMP, описывает пакет модели компьютерного зрения. VL Scenario Package, VLSP, — пакет исполняемого сценария. Для стороннего производителя не требуется повторять внутреннюю архитектуру VL или поддерживать наш визуальный редактор.
Главная задача VL Exchange — повторно использовать готовую аналитику: передать модель или сценарий из системы одного производителя в совместимую систему другого. Не так важно, написал ли разработчик решение вручную, собрал из блоков или создал с помощью ИИ. Важно передать то, что нужно для его работы и проверки, и убедиться, что принимающая платформа поддерживает нужный профиль, а лицензия разрешает перенос.
VLMP должен передавать модель вместе с явным описанием интерфейса и условий её применения. Какие входы она принимает, как они готовятся, какая среда исполнения нужна, что означает результат, какие классы используются, как проверяется корректность. В пакет входят необходимые артефакты, манифест и проверочные примеры. Конкретный профиль ограничивает обязательные возможности, чтобы принимающая система могла честно ответить, что она поддерживает.
VLSP переносит прикладную логику. В текущем экспериментальном направлении это исполняемый Python-код со спецификацией интерфейса: входных данных, результата и состояния. Платформа передаёт предусмотренные наблюдения и контекст, сценарий возвращает результат по согласованным правилам. Временные окна, порядок вызовов, сброс состояния и ошибки должны иметь определённый смысл, а не зависеть от привычек автора адаптера.
Один и тот же пакет не обязан работать на любой машине. Профиль может требовать конкретную версию среды, определённый вычислительный backend или доступную память. Совместимость означает поддержку заявленных требований. Неподходящую среду нужно обнаружить до исполнения, а не молча заменить вычисления «примерно похожими».
Критерий проверки тоже вполне земной: взять один неизменённый пакет, выполнить в двух независимых системах, сопоставить результаты на заранее заданных входах и в пределах заранее заданных допусков. Если во второй системе пришлось переписать логику внутри пакета, мы проверили разработку адаптации. Для доказательства переноса нужен другой результат.
Открытые правила и закрытая разработка
Ещё одно привычное недоразумение: если спецификация открытая, значит автор обязан бесплатно отдать исходный код и веса. Из открытости интерфейса такой обязанности не следует.
Правообладатель определяет условия распространения своего решения. Можно публиковать открытый пример, можно продавать защищённый пакет. Спецификация объясняет принимающей стороне, как проверить поставку и использовать её в разрешённых пределах. Она не отменяет авторские права и не делает коммерческую модель общественным достоянием.
Для сценариев мы уже испытывали защищённую поставку с шифрованием содержимого, подписью лицензии и разрешением для конкретной установки. Есть экспериментальные online и offline режимы. Offline нужен в том числе промышленным контурам без доступа к внешней сети; обязательного подключения к облаку VL у межвендорного обмена быть не должно.
Но несколько разных гарантий нельзя складывать в одно красивое слово «защита». Контрольная сумма помогает обнаружить изменение относительно известного эталона. Подпись связывает данные с доверенным издателем. Лицензия определяет право исполнения. Шифрование ограничивает доступ к содержимому поставки. Изоляция уменьшает полномочия исполняемого кода. Каждый механизм отвечает на свой вопрос.
Особенно осторожно стоит говорить о защите весов. При локальном исполнении модель должна стать доступна вычислительной среде. Администратор, который управляет этой средой, потенциально может получить доступ и к памяти, и к ключам. Базовая модель угроз VL Exchange предполагает доверенного администратора конечной системы. Абсолютной защиты от него мы не обещаем.
То же относится к Python. Зашифрованная поставка усложняет простое копирование архива без разрешения, но во время исполнения код доступен среде. Подпись подтверждает происхождение, а не безвредность программы. Принимающей платформе нужны изоляция процесса, ограничения файловой системы и сети, контроль зависимостей и ресурсов. Наш экспериментальный исполнитель сам по себе такой изоляцией не является.
Что уже проверили и чего пока нет
В испытаниях 30 октября 2026 года один неизменённый VLMP-пакет с синтетическим классификатором цветовых каналов прошёл через отдельный исполнитель и настоящий загрузчик CustomModel из образа Box 5. На пяти проверочных входах результаты совпали; проверяли также порядок, повторные вызовы и неизменность файлов.
Обе интеграции использовали общий SDK типов и семейство ONNX Runtime. Это разные способы загрузки и управления исполнением, но не доказательство независимости всех компонентов. Сам пример проверяет интерфейс, а не качество распознавания производственных событий.
Для VLSP в испытаниях 31 октября один сценарный ZIP выполнили две независимо написанные локальные host-реализации. Прошли пятнадцать шагов проверочной последовательности; в сравнении совпали девяносто из девяноста сопоставлений, включая состояние, события, сброс и ошибку порядка. Защищённое исполнение проверяли с offline-лицензией и с тестовым online-сервером на локальном компьютере.
Это ещё не проверка на платформе другого производителя. В эти результаты нельзя незаметно дописать промышленную готовность, работу на GPU, любые модели или готовую инфраструктуру коммерческого лицензирования. Следующий существенный шаг — воспроизведение независимым участником, который не помогал нам писать первый исполнитель.
Публичный комплект должен позволять начать с синтетических данных, прочитать спецификацию интерфейса без закрытого SDK, запустить валидатор и получить сопоставимый отчёт. Затем можно обсуждать реальный пилот и ограничения конкретной платформы. Принимать пакет на веру только потому, что у него правильная аббревиатура, не предлагается.
Почему VL этим занимается
Мы разрабатываем видеоаналитику и платформенные инструменты, поэтому сталкиваемся с обеими сторонами задачи. Нужно подключать внешние разработки, а собственные решения хочется использовать шире одной программной среды. Каждый отдельный проект можно закрыть индивидуальным адаптером. Но масштабируется при таком подходе в основном очередь к инженерам.
Мне интересен рынок, на котором хорошее прикладное решение может продаваться независимо от выбора платформы. Производители тогда конкурируют качеством исполнения, управлением, надёжностью и поддержкой. Разработчики аналитики — качеством решения задачи. У интегратора появляется переносимый результат работы. У заказчика — больше вариантов продолжения проекта.
Есть ещё одна вещь, важная для небольших команд. Если разработчик создал детектор или сценарий, заказчику полезно видеть не только название платформы, но и автора аналитики. Условная подпись «Analytics by Detector Lab» рядом с результатом — простой способ сохранить имя команды, даже когда её решение работает на чужой платформе. Небольшому разработчику это помогает стать узнаваемым и находить новых заказчиков без необходимости строить собственную платформу.
В экспериментальном профиле VL Exchange мы предлагаем передавать сведения об авторе вместе с пакетом, чтобы поддерживающая этот профиль платформа могла показывать их на видео и сохранять в данных события. Честно: вендор технически может убрать подпись или вообще не поддерживать её. Формат не заставит показывать её силой. Поэтому условия атрибуции стоит согласовывать заранее, а с производителем, который намеренно убирает имя разработчика без согласования, я бы предпочёл не работать.
Это не означает, что различия платформ исчезнут. Останутся производительность, интерфейсы, средства эксплуатации, требования безопасности и ответственность за внедрение. Но часть различий можно перестать оплачивать как повторное создание уже работающей логики.
Поэтому мы приглашаем разработчиков платформ, авторов моделей и интеграторов обсуждать конкретные интерфейсы и проверять пакеты в собственных исполнителях. Для первого участия не нужно передавать нам коммерческую модель или исходники своего продукта. Достаточно ограниченного профиля, разрешённого тестового примера и честного протокола: что выполнилось, что не совпало, какие требования оказались лишними или недостаточными.
Статус VL Exchange сегодня — Draft / Experimental. Открытую инициативу делает полезной возможность независимой реализации и влияния на правила. Если в итоге пакет сможет корректно прочитать только VL, поставленную задачу мы не решили.
Хорошая видеоаналитика должна переживать смену платформы. Давайте проверим, что для этого нужно, на работающих решениях.
VL Exchange и готовые решения
Инициатива VL Exchange · Техническое описание VLMP и VLSP · Каталог детекторов VL
Спецификации и примеры VL Exchange на GitHub
Продолжить обсуждение можно на работающих примерах: в репозитории собраны интерфейсы пакетов, схемы данных и проверки для независимых реализаций.
- Начать с README: English README · Русский README.
- Пакет модели VLMP: Русский · English.
- Пакет сценария VLSP: Русский · English.
- Синтетические примеры: модель и сценарий.
- Предложить изменение или описать результат в Issues.
Статус — Draft / Experimental. Условия лицензирования спецификаций и справочного кода находятся на согласовании; публикация файлов не заменяет лицензию на их использование. Условия коммерческих пакетов определяет их правообладатель.
