Comexp Research Lab совместно с ГК «Барс» адаптировали модель распознавания TAPe+ML для системы ночного видения «Ночной глаз», которую ставят на лодки и катера. Инженерный итог укладывается в три числа: локальная поставка уменьшилась с 28-30 МБ до 4,2 МБ, модель целиком помещается во внутренней памяти процессора, а один кадр обрабатывается на одном ядре CPU за 8,6-15,8 мс. Видеокарта и облако в этой схеме не участвуют.
Кейс полезен тем, кто встраивает компьютерное зрение в серийное оборудование и не хочет тащить на борт дискретный ускоритель, стабильный канал связи и оплату внешнего инференса. Ниже - путь от облачного API к локальному исполнению, разбор датасета (RGB, ночные кадры, тепловизор), результаты испытаний на воде и границы подхода. Цифры взяты из публичного разбора проекта (материал о «Ночном глазе»), независимых замеров в открытом доступе нет.
Что за проект «Ночной глаз» и почему там вообще понадобился локальный AI
«Ночной глаз» решает задачу распознавания объектов в темноте на малых судах. Модель TAPe+ML работает на бортовом мини-ПК RDBox: 28-30 МБ в исходной локальной поставке и загрузка ядра 30-60% в том же режиме. После переработки библиотек и исполнения поставка сократилась до 4,2 МБ, и модель стала помещаться во внутренней памяти процессора.
Кому и зачем нужна система ночного видения на воде
Ночью на воде у оператора мало вводных: горизонт теряется, огни и буи сливаются с бликами, камера качается вместе с корпусом. К этому добавляются ресурсные ограничения. На борту ограничены питание и место под электронику, а охлаждение зависит от температуры за бортом и от того, насколько плотно набит корпус.
Дискретная видеокарта в такой системе - это дополнительные ватты, тепло, цена и ещё один узел, который может отказать от влаги и вибрации. Облако на воде тоже не гарантия: связь пропадает вдали от берега и в плохую погоду, а видеопоток с катера не всегда уместно отправлять на чужой сервер. Локальный инференс снимает оба ограничения сразу, но переносит всю нагрузку на процессор, который на борту занят и другими задачами.
Почему облачный API не подошёл
Причины отказа от внешнего сервиса для этого кейса складываются из четырёх пунктов.
- Задержка. Кадр должен уходить по каналу, обрабатываться на сервере и возвращаться с результатом. На нестабильном мобильном канале время ответа непредсказуемо, а для навигационной подсказки важна предсказуемость, а не средняя скорость.
- Покрытие. На воде связь зависит от расстояния до берега, рельефа и погоды. Система, которая перестаёт видеть при пропадании сети, не подходит для судна.
- Приватность видеопотока. Постоянная трансляция картинки с катера на внешний сервер означает, что маршрут и обстановка вокруг судна уходят третьей стороне.
- Стоимость и зависимость. Платный инференс привязан к тарифам и доступности чужого сервиса, а изменения на стороне провайдера влияют на продукт, который вы уже продали.
Для стационарных задач с проводным интернетом и питанием от сети облачный API остаётся рабочим вариантом: он снимает вопросы производительности и обновления моделей. Разница в том, что камера на столбе и камера на катере живут в разных условиях по связи и энергии.
TAPe+ML: что это за модель и почему её пришлось оптимизировать
TAPe+ML - модель распознавания, выбранная для проекта «Ночной глаз». Публичные материалы описывают её как основу бортового распознавания, без детального раскрытия архитектуры. Известен практический результат: исходная локальная поставка весила 28-30 МБ, и этого хватало, чтобы держать ядро мини-ПК RDBox загруженным на 30-60%.
Почему размер поставки важнее размера весов
Когда говорят о «размере модели», обычно имеют в виду файл весов. На встраиваемом устройстве мегабайты набираются из всей цепочки:
- веса модели;
- рантайм, который эти веса исполняет;
- зависимости рантайма: математические библиотеки, работа с памятью, обработка изображений;
- обвязка ввода-вывода: захват кадра с камеры, запись результата, логи;
- системные библиотеки, которые приходится тянуть вместе с остальным.
Каждый лишний компонент увеличивает не только объём на диске, но и время холодного старта, число страниц памяти, которые нужно поднять, и поверхность для ошибок. Для бортовой системы важен именно весь набор, потому что именно он должен уместиться в ограниченную память и не мешать остальным подсистемам.
Загрузка ядра 30-60%: почему это плохой запас
Тридцать процентов на ядро выглядят безобидно, пока не посмотреть, что ещё делает тот же процессор. На судне это навигация, телеметрия, связь, интерфейс оператора, запись и передача данных. Распознавание кадров идёт непрерывно, а не короткими всплесками, поэтому его загрузка - это постоянный фон, поверх которого накладываются пики от остальных задач.
Практические последствия: меньше запаса на пиковые сценарии, выше средняя температура корпуса, сложнее пройти по бюджету питания, выше риск, что при добавлении новых классов объектов система упрётся в потолок. Запас по процессору на борту - это не роскошь, а условие, при котором систему можно развивать, а не переписывать с нуля.
Как модель ужали с 28-30 МБ до 4,2 МБ
В публичных материалах названы две линии работы: переработка библиотек и переработка исполнения. Конкретный список библиотек и версий не раскрыт, поэтому дальше - логика задачи и то, что подтверждено числами.
| Параметр | До | После |
|---|---|---|
| Объём локальной поставки | 28-30 МБ | 4,2 МБ |
| Загрузка ядра CPU | 30-60% | не раскрыто |
| Размещение параметров | с постоянным обменом с оперативной памятью | во внутренней памяти процессора, обмен после загрузки не нужен |
| Время на кадр | не раскрыто | 8,6-15,8 мс на одном ядре CPU |
Что убирали из библиотек и зачем
Логика сжатия поставки простая: чем меньше внешних зависимостей и чем они легче, тем меньше занимает пакет и тем проще уложить его во внутреннюю память процессора. Работа идёт по категориям, а не по одной библиотеке.
- Рантайм. Лишние модули, поддержка форматов и путей исполнения, которые в бортовом сценарии не используются, вырезаются или отключаются на этапе сборки.
- Математические библиотеки. Тяжёлые реализации операций можно заменить на более компактные или собрать только нужные ядра вычислений.
- Обвязка ввода-вывода. Захват кадра и запись результата нуждаются в небольшом наборе функций, а стандартные библиотеки часто тащат заметно больше.
Тот же принцип, только для языковых моделей, разбирается в материале о ускорении MoE-инференса в llama.cpp без изменения весов: прирост даёт работа с исполнением и памятью, а не переобучение модели.
Исполнение во внутренней памяти процессора: что это даёт
Внутренняя память процессора (кэш) работает на порядки быстрее оперативной, но она маленькая. Модель на 4,2 МБ в неё помещается, модель на 28-30 МБ - нет, и тогда параметры приходится постоянно подтягивать из RAM.
Каждое обращение к оперативной памяти добавляет задержку и, что важнее для бортовой системы, делает её непредсказуемой: результат зависит от того, чем в этот момент заняты контроллер памяти и остальные ядра. Когда параметры лежат во внутренней памяти, обмен с RAM после загрузки модели прекращается. Обработка становится ровнее по времени, а процессор меньше греется на пересылке данных.
Именно это, а не только экономия дискового пространства, объясняет, зачем инженеры гнались за 4,2 МБ. Порог в несколько мегабайт здесь не косметический: он отделяет схему, которая укладывается в кэш, от схемы, которая вынуждена жить в оперативной памяти.
8,6-15,8 мс на кадр на одном ядре CPU
Арифметика простая: 1000 мс, делённые на 8,6 мс, дают около 116 кадров в секунду, на 15,8 мс - около 63. Это верхняя оценка пропускной способности самого инференса, а не всего конвейера. В реальной системе к нему добавляются захват кадра, препроцессинг, постобработка и передача результата потребителю, поэтому итоговый FPS ниже.
Значимее другое: обработка идёт на одном ядре. Остальные ядра остаются под навигацию, телеметрию, связь и интерфейс. Разброс 8,6-15,8 мс показывает, что время на кадр зависит от содержимого сцены и объёма работы на конкретном кадре, а не держится на одной константе. Для задач, где решение нужно принимать за десятки миллисекунд, такой диапазон рабочий.
Датасет: RGB, ночные кадры и тепловизор
Качество датасета в таких проектах почти всегда весит больше, чем выбор архитектуры. Модель на 4,2 МБ не вытянет то, чему её не научили: если в обучающих данных нет ночи на воде, никакое сжатие этого не исправит.
Почему ночь на воде становится сложным сценарием для CV
Дневные датасеты для распознавания плохо переносятся на ночную воду. Причины накапливаются:
- низкая освещённость: контраст между объектом и фоном падает до единиц процентов яркости;
- блики и отражения от воды, которые модель может принять за объекты;
- туман, брызги и влага на оптике, размывающие границы;
- качка, из-за которой объект смещается между кадрами и меняет ракурс;
- движущиеся объекты на движущейся платформе: своё смещение складывается с чужим;
- мелкие далёкие объекты, которые занимают считаные пиксели.
Каждый пункт по отдельности решаем, вместе они дают домен, где модель ведёт себя иначе, чем на COCO-подобных наборах.
Как сочетать RGB и тепловизор
Логика комбинации модальностей простая. RGB даёт цвет, текстуру и детали, но деградирует при недостатке света. Тепловизор строит картинку по температуре: он видит объект там, где обычная камера уже не различает ничего, зато теряет мелкие детали и хуже работает в жару, когда разница температур между объектом и фоном мала.
Ночи на воде в датасете отведён отдельный слой, наряду с обычными RGB-кадрами и тепловизионными данными. Схема объединения модальностей (на уровне входа, признаков или результатов) - отдельное инженерное решение, и в публичных материалах проекта она не раскрыта. Объёмы датасета, соотношение классов и методика разметки тоже не опубликованы, а именно они определяют, насколько уверенно модель поведёт себя на новых водоёмах.
Испытания на воде: что показали и что осталось за кадром
Испытания проводились на воде, и их результат отражён в цифрах: 30-60% загрузки ядра до переработки поставки и 8,6-15,8 мс на кадр на одном ядре после. Это подтверждает, что схема работает в реальных условиях, а не только на стенде.
Какие условия на воде проверяли
Для такой системы репрезентативность испытаний определяется набором факторов, которые стоит уточнять отдельно:
- время суток: полностью тёмное время, сумерки, рассвет;
- волнение и качка: от штиля до заметной волны;
- скорость судна: на стоянке и на ходу;
- дистанция до объекта и его размер в кадре;
- погода: дождь, туман, брызги на оптике.
Публичные материалы не детализируют, в каких из этих условий проводились прогоны и сколько они длились. Это не претензия к проекту, а стандартная ситуация для коммерческого кейса.
Что не раскрыто в публичных материалах
Открытые вопросы, которые имеет смысл адресовать вендору до покупки похожего решения:
- точность и полнота распознавания по каждому классу объектов, а не общая оценка;
- поведение при высокой температуре и в тропических условиях, где тепловизионный контраст мал;
- энергопотребление в рабочем режиме и вклад вычислительного блока в общий бюджет;
- стоимость интеграции: сколько стоит встроить систему в существующий борт и что придётся менять;
- протокол испытаний: методика, длительность, число прогонов, контрольные сценарии.
Для производителя оборудования такие цифры - повод запросить полный протокол, а не отказ от технологии. Тот же принцип применим к любым громким метрикам: разбор заявлений об эффективности ускорителей показывает, что без методики и сценария цифра ничего не доказывает.
Ограничения подхода: где одного ядра CPU хватит, а где нет
Схема с одним ядром CPU закрывает конкретный класс задач, и у неё есть потолок. Названные ограничения стоит учитывать до того, как считать экономию на железе.
- Набор классов. Расширение списка распознаваемых объектов почти всегда увеличивает и модель, и время на кадр. Запас в 4,2 МБ не бесконечный.
- Разрешение и объём сцены. Чем больше пикселей на входе и чем больше объектов в кадре, тем выше нагрузка.
- Зависимость от датасета. Домен, которого нет в обучающих данных, даёт ошибки, которые нельзя списать на процессор.
- Очень быстрые сцены. При высокой скорости судна и быстром изменении обстановки бюджет в 8,6-15,8 мс на кадр становится ощутимым.
- Обучение на устройстве. Дообучение на борту такая схема не предполагает: модель готовят заранее.
Когда CPU-инференса достаточно
Подход подходит, если сходятся несколько условий:
- число классов объектов умеренное и меняется редко;
- сценарий стабильный: одни и те же типы целей, схожие условия съёмки;
- требования к задержке измеряются десятками миллисекунд, а не единицами;
- питание и охлаждение ограничены, а канал связи ненадёжен;
- видеопоток нежелательно выносить за пределы устройства.
Под это описание попадают бортовые системы, автономные камеры, промышленные датчики и встраиваемые модули, где важен предсказуемый отклик без внешних зависимостей.
Когда без GPU или облака не обойтись
Потолок у схемы появляется при росте сложности: десятки и сотни классов, видео высокого разрешения, тяжёлые мультимодальные модели, обучение на устройстве, сцены с плотным потоком объектов. Здесь CPU-инференс либо не уложится в бюджет времени, либо займёт столько ядер, что остальным подсистемам ничего не останется.
Гибридные схемы часто практичнее крайностей: лёгкая модель на CPU для постоянного фонового контроля плюс ускоритель или облако для тяжёлых эпизодических задач. Выбор зависит от того, что дешевле в конкретном продукте: ватты и цена ускорителя или задержка и зависимость от сети.
Что дальше: расширение набора объектов и развитие проекта
Заявленное направление развития «Ночного глаза» - расширение набора распознаваемых объектов. Конкретные классы и сроки в публичных материалах не названы, поэтому планировать под них интеграцию пока рано.
Общий тренд при этом виден: компьютерное зрение уходит с дискретных ускорителей и из облака в сторону встраиваемых решений, где модель живёт рядом с датчиком. Похожую логику видно и в мобильном AI: например, в кейсе компактной модели Bonsai для умных очков на Snapdragon ставка сделана на локальный запуск вместо обращения к чужому серверу. Разница в том, что очки и катер предъявляют к железу разные требования по теплу и питанию.
Практический чек-лист для своего проекта
Порядок действий, если вы хотите повторить такой путь в своём продукте:
- Опишите классы объектов и требования к задержке в миллисекундах. Без этого невозможно понять, укладывается ли схема в один CPU.
- Посчитайте бюджет по питанию и теплу для вычислительного блока в худших условиях эксплуатации, а не в лаборатории.
- Оцените, что на устройстве уже занимает процессор: навигация, связь, интерфейс. Свободный запас важнее средней загрузки.
- Соберите датасет из своего домена, включая ночь, плохую погоду, качку и малоконтрастные кадры.
- Измерьте размер всей поставки, а не только весов, и проверьте, помещается ли она во внутреннюю память процессора.
- Запросите у вендора протокол испытаний с методикой и условиями, прежде чем принимать цифры на веру.
Кейс «Ночного глаза» показывает, что порог входа в бортовое компьютерное зрение сегодня определяется не наличием видеокарты, а дисциплиной в работе с памятью и зависимостями. Четыре с половиной мегабайта и одно ядро CPU оказались достаточными для задачи, где ещё недавно по умолчанию предполагался внешний сервер.