Решение «просто возьмём VLM» – когда мультимодальная модель фронтира заменяет кастомный CV

Автор: Николай СапуновОбновлено: август 202627 мин чтения
Содержание статьи +

Кратко

Модель, способная обрабатывать и изображение, и текст – её называют vision-language model или VLM, – теперь может отвечать почти на любой вопрос о кадре видео без предварительного обучения, и это побуждает команды отказаться от кастомного пайплайна компьютерного зрения в пользу «просто взять VLM». Такой подход оправдан для задач с малым объёмом данных, меняющимися или трудноописуемыми категориями – но не работает для высокообъёмных, фиксированных задач в реальном времени. Граница здесь проходит в первую очередь по стоимости обработки одного кадра и по задержке в миллисекундах, а не по тому, какая модель «умнее». В статье вы найдёте простую арифметику: примерно на 100 000 кадрах в месяц универсальный VLM API перестаёт быть дешевле небольшого кастомного детектора, который вы развернули сами, а при частоте кадров видео облачный VLM вообще не укладывается в бюджет реального времени. Паттерн, который реально доходит до продакшена в 2026 году, – гибридный: дешёвая и быстрая кастомная модель фильтрует поток, а VLM анализирует лишь те редкие кадры, которые действительно оправдывают его стоимость.

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

Два года назад функция, распознающая содержимое кадра, означала сбор тысяч размеченных изображений, обучение собственной модели и её постоянную поддержку. Сегодня вы передаёте кадр в передовую мультимодальную модель и задаёте вопрос: «Есть ли погрузчик в пешеходной зоне?» – обычными словами и получаете рабочий ответ за один вызов API без необходимости обучения. Такой короткий путь стал реальностью и меняет подход к созданию видеопродуктов, но если применять его не по делу – он тихо сжигает бюджет, увеличивает задержку и порождает красивое демо, которое не выдерживает нагрузки в продакшене. Эта статья для продакт-менеджера, основателя или видеоинженера, которому нужно для конкретной фичи решить: использовать ли VLM-ускорение или строить кастомный пайплайн – и который хочет опираться на цифры стоимости и задержки, а не на хайп.

Два инструмента на столе

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

Первый инструмент – кастомная модель компьютерного зрения, которую часто называют детектором объектов. Наиболее распространённое семейство – YOLO (от «You Only Look Once»), а также более современные архитектуры, такие как RF-DETR. Вы заранее определяете, какие объекты модель должна распознавать – например, «человек», «транспорт», «каска» – собираете и размечаете соответствующие примеры, после чего обучаете модель. После обучения она обрабатывает кадр и возвращает точный список ограничивающих рамок: у каждой – координаты, метка категории и уровень уверенности. Представьте себе очень быстрого и крайне буквального работника, который выучил один конкретный список и выполняет только эту задачу – одинаково и без изменений каждый раз.

Второй инструмент – vision-language model (VLM), мультимодальный родственник чат-бота. Примеры – Google Gemini, OpenAI GPT и Anthropic Claude, а также модели с открытыми весами, такие как LLaVA и Qwen-VL. Вы показываете ему кадр и задаёте вопрос на обычном языке – он отвечает тем же языком. На ваших конкретных объектах его не обучали: он изучил визуальный мир в целом. Представьте эрудированного универсала, к которому можно обратиться с любым вопросом – но который иногда путается, повторяет одну и ту же мысль разными словами и берёт плату за каждый запрос.

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

Рисунок 1. Кастомный детектор возвращает фиксированный, воспроизводимый список рамок; VLM – гибкий естественный язык о чём угодно. Выбор определяется формой вывода, а не «умом» модели.

Решение – это на самом деле три числа

Этот выбор формулируют как «достаточно ли умён VLM?». Честная формулировка: «вписывается ли VLM в мой бюджет по стоимости, задержке и стабильности?». Почти в любой продакшен-фиче видео способность уже не узкое место – frontier VLM в 2026 году опишет почти любую сцену, которую вы покажете. Чего он не всегда может – описать её достаточно дёшево, достаточно быстро и одинаково дважды. Эти три параметра – стоимость за кадр, задержка за кадр и стабильность между прогонами – решают дело гораздо чаще, чем чистая точность.

Пройдёмся по каждому числу с реальной арифметикой. Цифры ниже основаны на Google Gemini 2.5 Flash как опорном VLM, поскольку это один из наиболее доступных frontier-вариантов с опубликованными ценами; выводы применимы и к GPT, и к Claude, которые стоят дороже за обработку изображений, а не дешевле.

Число первое: стоимость за кадр и точка безубыточности

Кастомный детектор требует крупных первоначальных затрат и почти ничего – после. Вы платите за сбор данных, разметку, обучение модели и сервер для её запуска. Далее каждый обработанный кадр почти бесплатен – вы платите лишь за электричество и долю GPU, который и так арендуете. VLM API – полная противоположность: никаких вложений вперёд, но небольшая пошлина за каждый кадр – навсегда.

Чтобы сравнить их, нужна пошлина за кадр. VLM не воспринимает изображение как единое целое – он разбивает его на квадратные тайлы и тарифицирует каждый отдельно. Gemini считает один тайл равным 258 токенам, где токен – это малая единица текста или данных изображения, по которой тарифицируются модели. Кадр стандартной чёткости 960×540 пикселей даёт шесть тайлов.

Покажем эту арифметику вслух – так же, как будем представлять каждое число в статье:

Размер кадра:        960 × 540 пикселей
Единица обрезки:     floor(min(960, 540) / 1.5) = floor(360) = 360 px
Тайлов по ширине:    960 / 360 = 2.67  ->  3 тайла
Тайлов по высоте:    540 / 360 = 1.5   ->  2 тайла
Всего тайлов:        3 × 2 = 6 тайлов
Токенов изображения: 6 × 258 = 1 548 токенов на кадр

Gemini 2.5 Flash стоит около 0,30 доллара за миллион входных токенов (опубликованная ставка на середину 2026 года). Добавьте короткий промпт и короткий ответ – и один проанализированный кадр обойдётся примерно так:

Входное изображение:  1 548 токенов
Входной промпт:         ~60 токенов
Выходной ответ:         ~40 токенов  (по $2.50 / 1M на выход)
Стоимость ≈ (1 608 × $0.30 + 40 × $2.50) / 1 000 000
         ≈ ($0.000482 + $0.000100)
         ≈ $0.00058 за кадр

То есть около шести сотых цента за кадр. Звучит ничтожно – и при малом объёме так и есть. Беда в том, что видео состоит из огромного числа кадров. Одна камера со скромной частотой 5 кадров в секунду даёт 432 000 кадров в день, или около 13 миллионов в месяц. Обработка каждого кадра через VLM обошлась бы в:

13 000 000 кадров × $0.00058 ≈ $7 540 в месяц — на одну камеру.

Теперь поставьте рядом кастомный детектор. Реалистичная одноразовая сборка – разметка, обучение и четверть бюджетного GPU-сервера – обходится примерно в $8 000–$20 000, после чего стоимость обработки одного кадра составляет доли цента, поскольку нет платы за вызов. Важна именно точка перелома. Отраслевые рекомендации 2026 года, включая опубликованный фреймворк решений Roboflow, устанавливают эмпирическое правило примерно на уровне 100 000 изображений в месяц: ниже этой отметки обычно выигрывает удобство VLM без настройки; выше – почти нулевая стоимость детектора на кадр, и разрыв быстро растёт с увеличением объёма. Одна загруженная камера пересекает эту границу за день.

Урок не в том, что «VLM дорогой». Он в том, что стоимость VLM растёт линейно с количеством кадров, а стоимость детектора – почти не меняется, поэтому выбор оптимальной модели полностью зависит от того, сколько кадров вам действительно нужно проанализировать. Именно поэтому ниже представлен гибридный подход.

Число второе: задержка за кадром и стена реального времени

Задержка – это временной интервал между моментом захвата кадра и тем, когда система выдаёт ответ по нему. Для одних задач пара секунд – норма, для других – фатальна. Именно это одно число выводит VLM за рамки большого класса видеозадач, как бы ни сошлась математика стоимости.

Маленький кастомный детектор создан для скорости. Самый компактный вариант YOLO11 обрабатывает кадр примерно за 1,5 миллисекунды на серверном GPU, а на edge-устройстве вроде NVIDIA Jetson Orin выдаёт 28–41 кадр в секунду в зависимости от точности (бенчмарки 2026). Этого достаточно, чтобы успевать за живым видео и реагировать в том же кадре – например, линия сварочного контроля, которая должна остановить конвейер до того, как дефект уедет дальше, или система безопасности, обязанная немедленно зафиксировать человека в опасной зоне.

Облачный VLM работает в другом часовом поясе. Кадру нужно добраться до дата-центра, пройти очередь, быть обработанным моделью с миллиардами параметров и вернуться обратно. Такой цикл обычно занимает секунды, а не миллисекунды. Рекомендация Roboflow 2026 года для продакшена прямолинейна: облачные VLM «редко подходят для жёстких требований к задержке» и лучше всего применимы в пакетной обработке или сценариях с участием человека (human-in-the-loop), где задержка в несколько секунд на кадр допустима.

Вот стена – без обиняков. Если функция обязана успевать за живым видеопотоком – аналитика в реальном времени, автономное управление, всё, где опоздавший ответ – это уже неверный ответ, – облачный VLM не справится с покадровой обработкой, точка. Неважно, насколько он умён. Правильный ответ, пришедший через три секунды после события, – это провал. Поэтому большинство разговоров «просто возьмём VLM для живого видео» заканчиваются не вопросом возможностей, а вопросом задержек.

Число третье: стабильность и что даёт детерминизм

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

Для многих признаков вариативность не представляет опасности. Если VLM описывает дефект одежды как «свободная нить у левой манжеты» в одном прогоне и «разлохмаченный шов на левом рукаве» в другом – человек, читающий отчёт, поймёт оба варианта. Но как только система начинает принимать автоматические решения – годен/брак, тревога/игнор, занести для аудитора – недетерминизм превращается в риск. Системам комплаенса и контроля качества часто требуется доказать, что один и тот же вход всегда приводит к одному и тому же решению; модель, которая «обычно» согласна сама с собой, такого гарантировать не может.

Сбой проявляется особенно остро в задачах подсчёта и пространственных рассуждений – тех, на которых постоянно опираются визуальные признаки. Исследование 2026 года GroundCount показало, что vision-language модели систематически галлюцинируют при подсчёте объектов, демонстрируя точность «существенно ниже, чем в других задачах визуального рассуждения» – и эта слабость сохраняется даже у самых современных reasoning-VLM, поскольку она обусловлена способом интеграции пространства и смысла, а не дефектами конкретной архитектуры. Отдельный бенчмарк 2026 года OmniSpatial выявил, что как открытые, так и закрытые VLM демонстрируют «значительные ограничения» в пространственных рассуждениях – в оценке относительного положения, перспективы и динамических связей. Практический вывод прост и важен: не спрашивайте у VLM точные количества или точные позиции. Спросите – и он часто будет уверенно ошибаться. Обученный детектор или специализированная модель глубины дают такие данные надёжно; VLM же предназначены для интерпретации смысла, а не для точных измерений.

«Частая ошибка: задать VLM вопрос, на который надёжно ответит только детектор. «Сколько людей в кадре?» и «Коробка левее паллеты?» кажутся простыми, поэтому их часто передают VLM. Подсчёт и точные пространственные отношения – как раз те задачи, где VLM чаще всего галлюцинирует (GroundCount, OmniSpatial, 2026). Используйте детектор для подсчёта и локализации; оставьте VLM вопросы типа «что происходит и важно ли это?». Приём 2026 года, когда их нужно объединить, – подавать рамки детектора в промпт VLM, чтобы модель рассуждала на основе реальных координат, а не угадывала. Именно так удалось повысить точность подсчёта на несколько пунктов в работе GroundCount.»

Сводная таблица сравнения

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

КритерийКастомный детектор (YOLO, RF-DETR)Vision-language model (Gemini, GPT, Claude)
КатегорииФиксированы; новая требует переобученияОткрыты; спросите что угодно обычным языком
Задержка за кадр~1,5 ms (серверный GPU) – ~25 ms (edge)Секунды (облачный круг)
Форма стоимостиБольшая одноразовая сборка, почти ноль за кадрНоль настройки, пошлина за кадр навсегда
Перелом экономикиВыигрывает выше ~100K кадров/месВыигрывает ниже ~100K кадров/мес
СтабильностьДетерминирован – одинаковый вывод каждый разВероятностен – формулировки и рамки плавают
Подсчёт / точная позицияНадёжноСклонен к галлюцинациям (избегать)
Время до первой версииНедели (данные, разметка, обучение)Часы (API + промпт)
Постоянная зависимостьВы владеете всей системойПривязка к API, ценам и поведению вендора
Редкие / невиданные объектыНет – отнесёт к ближайшему известномуДа – опишет невиданное при обучении

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

Дерево решений, которое можно пройти в уме

Когда вы оцениваете одну конкретную фичу, всё решают шесть вопросов. Отвечайте по порядку и останавливайтесь на первом ясном ответе.

Первый: можете ли вы заранее выписать полный список того, что фича должна распознавать? Если нет – потому что категории открыты, меняются по сезонам или включают редкие хвостовые случаи, которые невозможно перечислить, – естественен VLM, ведь ему не нужен предзаданный список. Если можете – дальше.

Второй: должна ли фича успевать за живым видео? Если опоздавший ответ – это неверный ответ, нужна задержка детектора в миллисекунды; облачный VLM не влезет в бюджет. Если задержка в пару секунд на кадр допустима – можно двигаться дальше.

Третий вопрос: будете ли вы обрабатывать более 100 000 кадров в месяц? Выше этой отметки выгоднее становится фиксированная стоимость детектора за кадр – запас растёт с каждой новой камерой. Ниже – как правило, дешевле использовать VLM без настройки. Дальше.

Четвёртый вопрос: зависит ли автоматическое решение с требованием аудита или комплаенса напрямую от вывода? Если да – детерминизм детектора будет стоить дорого: придётся доказать, что один и тот же вход всегда приводит к одному и тому же решению. Если же вывод проверяет человек, небольшая вариативность VLM допустима.

Пятый: есть ли у вас специалисты по машинному обучению и ресурсы, чтобы собрать данные, разметить их, обучить модель и поддерживать её в рабочем состоянии? Если нет – VLM выводит фичу в продакшен за дни, а не за недели. Если есть – детектор станет лучшим фундаментом на долгосрочной перспективе. Последний вопрос.

Шестой: нужно ли фиче понимание сверх того, где находятся объекты – контекст, связи, чтение текста на сцене, способность заметить, что что-то выглядит не так? Если да – это уже задача VLM; детектор выдаёт только рамки. Если же нужны лишь положение и идентификация известных объектов, детектор – проще и дешевле.

Рисунок 2. Шесть вопросов, идущих сверху вниз, помогают почти всегда решить, что выбрать – детектор или VLM. Останавливайтесь на первой ветке, дающей однозначный ответ.

Паттерн, который реально работает: гибридная фильтрация

На практике лучшие команды редко ограничиваются одним инструментом. Они строят воронку: дешёвые быстрые модели обрабатывают поток кадров, а дорогие и умные анализируют лишь те, что заслуживают внимания. Это самая полезная идея статьи – и её стоит изложить конкретнее.

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

Первый этап – дешёвый фильтр. Крошечный детектор движения или миниатюрная кастомная YOLO работает прямо на чипе камеры и отбрасывает около 99% кадров, где ничего значимого не происходит. Он быстр и почти бесплатен – отвечает лишь на один вопрос: есть ли здесь вообще человек? Ничего дорогого не запускается, пока этот фильтр не сработает.

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

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

Этап 1 — Фильтр движения / крошечный детектор  →  отбрасывает ~99% кадров, on-device, ~бесплатно
Этап 2 — Кастомный детектор + геометрия         →  точная локализация и проверка зоны на прошедших
Этап 3 — VLM, структурированный промпт          →  суждение о контексте на редком заслужившем кадре

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

Рисунок 3. Гибридная воронка: дешёвая быстрая модель слева фильтрует поток, чтобы дорогой умный VLM справа видел лишь редкие кадры, оправдывающие его цену и задержку.

Ещё две гибридные формы, которые стоит знать

Воронка-фильтр – самый распространённый паттерн, но две другие встречаются достаточно часто, чтобы их выделить.

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

Вторая – детектор для типовых случаев, VLM для редких. Функция сортировки документов направляет стандартные формы на быструю обработку детектором и передаёт в VLM только те документы, в которых он не уверен. А VLM распознаёт незнакомые макеты и определяет, что это за документы. Эти неуверенные случаи становятся новыми обучающими данными, и со временем детектор «впитывает» всё больше редких случаев, а к VLM обращаются всё реже. Система становится дешевле и всё более автономной по мере работы.

Все три формы объединены одним принципом: пусть дешёвая модель решает, когда запускать дорогую. Когда хочется «просто взять VLM» и применить его ко всему потоку, исправление почти никогда не в отказе от VLM – а в том, чтобы поставить перед ним фильтр.

Когда «просто возьмём VLM» – действительно верный выбор

Было бы ошибкой трактовать это как «VLM для демо, детекторы для продакшена». Есть реальные кейсы, где использование VLM без кастомной модели – абсолютно верное инженерное решение в 2026 году.

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

Честная позиция: граница смещается каждый квартал. VLM становятся быстрее и дешевле, а тренд 2026 года – модели поменьше, работающие менее чем за секунду и даже on-device, что втянет больше near-real-time задач в сферу VLM. Но базовая физика не меняется: модель, обученная выполнять одну узкую задачу, всегда будет быстрее и дешевле на кадр, чем универсальный инструмент, которому поручают всё. А универсальный инструмент всегда остаётся гибче специалиста. Решение не в том, что лучше, – а в том, что сегодня вписывается в три ключевых параметра этой фичи.

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

Мы разрабатываем видеопродукты для видеоконференцсвязи, стриминга, OTT-платформ, видеонаблюдения, e-learning и телемедицины, и вопрос «детектор или VLM?» регулярно возникает при создании каждой ИИ-функции. Паттерн, к которому мы постоянно возвращаемся, – гибридная архитектура: небольшая модель на устройстве, фильтрующая входные данные для мощной VLM. Это единственный подход, который одновременно укладывается в ограничения реального времени и остаётся экономически эффективным. В системе видеонаблюдения недорогой фильтр помогает держать стоимость камер на приемлемом уровне, пока VLM обрабатывает редкие, но сложные случаи; в e-learning и телемедицине, где объём данных меньше, а каждый фрагмент важен, VLM зачастую работает самостоятельно. Инженерная ценность, которую мы создаём, заключается в том, чтобы точно определить эту границу для конкретной задачи, а затем построить фильтрацию так, чтобы дорогая модель анализировала только те кадры, которые действительно оправдывают её использование.

Главное

  • Выбор определяется стоимостью за кадр, задержкой и стабильностью – а не тем, какая модель «умнее».
  • Облачный VLM не укладывается в бюджет для живого видео; для реального времени нужен кастомный детектор.
  • При примерно 100 000 кадров в месяц хостимый кастомный детектор становится дешевле, чем использование VLM API.
  • Никогда не запрашивайте у VLM точные количества или координаты – он склонен к галлюцинациям при подсчёте и в пространственной локализации.
  • Доезжающий паттерн – это гибрид: дешёвый и быстрый детектор фильтрует поток, а VLM обрабатывает редкие кадры.
  • «Просто возьмём VLM» – подходящее решение для небольших, динамичных или контекстно-зависимых задач, которые могут позволить себе задержку в несколько секунд.

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

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.