Видео-VLM в 2026 – сэмплирование кадров против потоковой передачи токенов

Кратко

Видео-модель ИИ – то, что инженеры называют мультимодальной системой, или vision-language-моделью (VLM), способной «читать» движущиеся изображения так же, как текст, – на самом деле не смотрит ваше видео целиком. Она анализирует лишь несколько отдельных кадров, которые вы ей передали, преобразованных в набор чисел – токены. Два ключевых архитектурных решения определяют, будет ли модель дешёвой, быстрой и точной или дорогой, медленной и «забывающей»: сколько кадров извлекается из видео и сколько токенов выделяется на каждый кадр. Эта статья объясняет – для читателя без опыта в машинном обучении – два основных подхода 2026 года: «сэмплирование кадров» (взять несколько кадров и обработать их разом) и «потоковую передачу токенов» (подавать кадры непрерывно, отбрасывая старые), с реальной математикой токенов, актуальными цифрами от Google, Qwen от компании Alibaba и open-source-сообщества, а также практическим правилом выбора. К концу вы сможете прочитать требование вроде «позвольте пользователям задавать вопросы по этой двухчасовой записи» и сразу понять, во сколько это обойдётся и почему.

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

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

Главное, что нужно понять – видео-ВЛМ никогда не видит ваше видео

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

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

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

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

Сэмплирование кадров – выбор моментов, которые увидит модель

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

Зачем выбрасывать столько? Потому что соседние кадры почти идентичны. За одну секунду лекции показываются тридцать кадров одного и того же спикера на одном и том же слайде – хранить все тридцать – пустая трата ресурсов, и модель не извлекает из них ничего нового. У этой почти-двойственности есть название – временна́я избыточность, и именно из-за неё сэмплирование и работает. Хитрость в том, что избыточность неравномерна: у статичной лекции она огромна, а у быстрого спортивного клипа или погрузчика, поворачивающего за угол, её почти нет. Одна частота сэмплирования не может подойти обоим.

Модели Gemini от Google делают значение по умолчанию явным и задокументированным. По руководству Gemini API по пониманию видео (обновлено в апреле 2026 года), когда вы загружаете видео через Files API, оно сохраняется и сэмплируется на частоте 1 кадр в секунду, и вы можете переопределить это своим значением fps – ниже для статичного контента вроде лекций, выше для быстрого действия. Это предложение и есть вся история сэмплирования кадров для закрытой модели: вы выбираете fps, платформа оставляет столько кадров, а ваш счёт и ваша точность оба следуют из этого выбора. Полный набор закрытых передовых моделей и то, чем различается их обработка видео, – тема урока о закрытом фронтире.

Подводный камень сэмплирования – тот, который команды обнаруживают слишком поздно. Если важное событие длится меньше интервала между сэмплированными кадрами, модель может его просто не заметить. При частоте 1 кадр в секунду номер машины, видимый всего полсекунды, пока автомобиль проезжает мимо, может целиком оказаться между двумя сэмплами – модель видит пустую дорогу до и пустую дорогу после и с уверенностью сообщает, что машины не было. Инженеры называют это проблемой «иголки в стоге сена», поэтому совет «просто понизь fps, чтобы сэкономить» опасен, если не знать, как долго длятся важные события.

Токены на кадр – насколько дорога каждая картинка

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

Возьмём Gemini от Google – наиболее задокументированный случай. Согласно руководству по API Gemini по обработке видео, каждый сэмплированный кадр токенизируется в 258 токенов на кадр при разрешении по умолчанию или в 66 токенов на кадр при низком разрешении. К этому добавляется около 32 токенов в секунду на аудиодорожку, и Google в итоге указывает примерно 300 токенов в секунду видео при разрешении по умолчанию или около 100 токенов в секунду при низком разрешении. (Отдельная страница Google о подсчёте токенов приводит общую цифру «263 токена в секунду» для видео; расхождение связано с тем, включены ли в эту сумму звук и метаданные, а также с поколением модели. Когда две официальные страницы одного вендора дают разные данные, стоит опираться на более детальную разбивку по компонентам – 258 визуальных + 32 аудио – и рассматривать округлённые значения «в секунду» как приблизительные оценки.)

Теперь давайте пройдёмся по расчётам вслух, потому что стоимость анализа видео сводится к простому умножению. Допустим, вы отправляете 10-минутный клип в Gemini с частотой кадров по умолчанию – 1 кадр в секунду (1 fps) и стандартным разрешением. Десять минут – это 600 секунд, значит, система обработает 600 кадров:

600 кадров × 258 токенов/кадр   = 154 800 визуальных токенов
600 секунд × 32 токена/секунду  =  19 200 аудиотокенов
                                  ----------------------
                          итого ≈ 174 000 входных токенов

Эти ~174 000 токенов – то, за что вам выставляют счёт как за ввод. По представительной цене 2026 года для быстрой модели – Gemini 2.5 Flash указан как \$0,30 за миллион входных токенов – стоимость обработки этого десятиминутного видео составляет:

174 000 токенов ÷ 1 000 000 × $0,30 ≈ $0,052

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

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

Контекстное окно – жёсткий потолок, в который всё упирается

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

Здесь два числа сталкиваются с реальностью. Модели с контекстным окном в 1 миллион токенов – крупные передовые модели 2026 года – по данным Google, могут вместить около одного часа видео при разрешении по умолчанию или около трёх часов при низком разрешении. Подсчитаем: час – это 3600 секунд, и при ~300 токенах в секунду получается около 1 080 000 токенов – почти на пределе; если снизить до ~100 токенов в секунду при низком разрешении, то же окно растягивается примерно до трёх часов.

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

Как открытые модели сжимают кадры – гонка по сжатию токенов

Закрытые модели вроде Gemini скрывают токенизатор за API. Открытые модели – те, что можно скачать и запустить самостоятельно, – делают его доступным, и именно в этом заключается ключевая инженерия 2026 года: как они снижают токеновую стоимость каждого кадра. Понимание этого приёма объясняет, почему открытые видеомодели продолжают становиться дешевле, не теряя в качестве.

Qwen2.5-VL от Alibaba – открытая vision-language-модель, выпущенная в версиях с 3, 7 и 72 миллиардами параметров, демонстрирует стандартный подход. Её визуальный энкодер обрабатывает кадр как сетку мелких фрагментов – та же концепция, что описана во введении в Vision Transformer, – после чего объединяет каждый блок 2×2 фрагментов в один токен перед передачей в языковую модель, сокращая объём данных в четыре раза на входе. Дополнительно модель использует сэмплирование с динамической частотой кадров и схему позиционного кодирования (внутреннее представление модели о том, когда произошёл каждый кадр; Qwen называет это абсолютным временным кодированием через mRoPE), чтобы корректно обрабатывать видео с разной скоростью съёмки и при этом сохранять привязку событий к реальным таймкодам. В результате, по данным команды Qwen, модель эффективно укладывает длинное видео в фиксированный бюджет токенов: в их конфигурации до 768 сэмплированных кадров сжимаются так, что каждые два кадра занимают 64 токена, максимум – 24 576 видеотокенов – всё видео помещается в объём, который передовые модели тратят на девяносто секунд необработанного видео.

Открытое сообщество движется дальше. Исследователи из OpenGVLab сообщают, что InternVL3.5 преобразует каждую плитку изображения в 1024 сырых визуальных токена, а затем применяет шаг под названием pixel shuffle, чтобы сжать их до 256 токенов – а версия «Flash» сжимает их ещё сильнее, до 64 токенов на плитку, то есть в шестнадцать раз. Паттерн везде один и тот же: тратить токены там, где важна детализация, и сильно сжимать там, где она не нужна – и модель почти не замечает разницы. Для продуктовой команды урок не в самом механизме, а в его последствиях: стоимость токенов в открытых видеомоделях быстро снижается, и именно поэтому фраза «мы не можем позволить себе запускать VLM на каждой камере» – это ответ 2024 года, который к 2026-му может оказаться устаревшим.

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

Два подхода – выбор кадров против потоковой передачи токенов

Теперь – сердце статьи. Существует два принципиально разных подхода к подаче видео в модели, и почти каждый продукт построен на одном из них. Этот выбор – не мелочь: он определяет, сможет ли функция работать в реальном времени, какую длину видео она способна обработать и сколько это будет стоить.

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

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

Академическая и продакшен-работа здесь развивается стремительно. VideoLLM-online (CVPR 2024) стал одним из первых потоковых решений, способным обрабатывать 5–10 кадров в секунду на одной потребительской видеокарте и проактивно вносить голосовые комментарии в поток – описывая происходящее по мере его развития, а не ожидая вопроса. Более новые системы, такие как Dispider (2025), разбивают задачу на три постоянно работающих компонента: лёгкий модуль, который непрерывно отслеживает происходящее, второй – определяющий когда следует ответить, и третий – формирующий сам ответ. Такой подход позволяет модели реагировать в нужный момент, не прерывая поток. StreamingVLM (2025) ориентирован на стабильное понимание, по сути, бесконечных видеопотоков. Названия будут меняться, но суть останется прежней. Если функция должна отвечать пока видео ещё играет, это потоковая функция, и архитектуры, основанные на выборке кадров, с такой задачей не справятся.

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

Разбор на примере – одна функция, два способа

Сделаем это конкретным на примере одной функции, реализованной двумя способами: «оповестить оператора охраны, когда кто-то входит в запретную зону».

Построенная на сэмплировании кадров, эта задача – ночная. Каждое утро система берёт восьмичасовую запись прошлой ночи, сэмплирует её со скоростью 1 кадр в секунду (28 800 кадров) и – поскольку это превышает объём любого одного контекстного окна – разбивает на фрагменты, отправляет каждый из них модели и объединяет ответы. В результате получается аккуратный отчёт: «Вход зафиксирован в 02:14 и 03:48». Такой подход дешёв в расчёте на камеру и прост в реализации. Но он бесполезен для предотвращения нарушений, ведь ответ приходит с опозданием на восемь часов.

Построенная на потоковой передаче токенов, та же функция отслеживает живой поток. Кадры поступают по несколько в секунду, модель поддерживает скользящую память за последние одну–две минуты, и в тот момент, когда человек пересекает линию, она срабатывает – за доли секунды, пока это ещё имеет значение. Это дороже (модель работает непрерывно, а не раз в день) и сложнее в реализации (требуется потоковая инфраструктура из уроков про конвейер ИИ реального времени). Но это единственная версия, которая действительно выполняет свою задачу.

Ни один не «лучше». Это ответы на разные вопросы. Таблица ниже – руководство к выбору.

Где сэмплирование кадров ошибается – и как это исправляет 2026 год

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

Ответ 2026 года – адаптивное, учитывающее запрос сэмплирование: вместо того чтобы вслепую брать один кадр в секунду, конвейер смотрит на то, что спросил пользователь, и тратит бюджет кадров там, где вероятен ответ. Свежие исследования делают выигрыш конкретным. Методы «отбора ключевых клипов», берущие короткие релевантные сегменты вместо отдельных равномерных кадров, сообщают о приросте точности до примерно 8–10 процентных пунктов над равномерным сэмплированием на бенчмарках длинного видео. Другие системы 2026 года обучают политику сэмплирования – небольшую вспомогательную модель, решающую, какие кадры извлечь, – и некоторые сообщают, что находят нужные ключевые кадры, сэмплируя чуть больше 1% видео. Механизм разнится; направление неизменно. К 2026 году вопрос «как сэмплировать кадры?» смещается от «выбери fps» к «пусть кадры выбирает модель поменьше», и экономия достаточно велика, чтобы стоило спросить ваших инженеров, какой подход использует функция для длинного видео.

Бенчмарк, отслеживающий этот прогресс, – Video-MME, оценка на 900 видео, охватывающая короткие, средние и длинные клипы. Таблица лидеров – полезная проверка заявлений вендоров: на 2026 год лучшие общие результаты группируются в районе середины 80-х процентов, передовые закрытые модели вроде Gemini 2.5 Pro показывают около 84–85% в целом, а самый сложный срез «длинное видео, без субтитров» остаётся заметно ниже – напоминание о том, что обработка длинного видео всё ещё остаётся нерешённой задачей, и любой вендор, заявляющий о её полном решении, заслуживает скепсиса.

Частая ошибка – путать «длинный контекст» с «видит всё»

Ошибка, которую мы видим чаще всего, – прочитать фразу «контекстное окно на 1 миллион токенов, поддерживает видео в 1 час» и сделать вывод, что модель смотрит этот час так, как это делал бы человек. Нет. При частоте 1 кадр в секунду она видит только один кадр за секунду – она «слепа» к остальным 29/30 времени каждой секунды, и любое событие короче секунды может просто исчезнуть между кадрами. «Поддерживает один час» означает, что кадры за этот час помещаются в память, а не то, что модель воспринимает каждый момент этого часа.

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

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

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

Ключевые выводы

• Видео-ВЛМ никогда не видит ваше видео целиком – только сэмплированные кадры в виде токенов; именно этот конвейер определяет стоимость и точность.
• Стоимость складывается из двух умножений: сэмплированные кадры × токены на кадр, плюс обработка звука. Gemini использует около 258 токенов на кадр при частоте 1 кадр в секунду.
• Десятиминутное видео в стандартных настройках – примерно 174 000 токенов, что обойдётся в пять центов на быстрой модели 2026 года.
• Контекстное окно – жёсткий лимит: модель с ёмкостью 1 млн токенов может вместить около одного часа видео при стандартном разрешении и до трёх часов – при низком.
• Сэмплирование кадров позволяет анализировать всё записанное видео целиком; потоковая обработка справляется с бесконечным живым видео, но со временем забывает отдалённое прошлое.
• Выбирайте частоту кадров исходя из длительности самого короткого важного события: 1 кадр в секунду пропускает всё, что длится менее секунды.

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

• CLIP и контрастное обучение vision-language – введение для каждого инженера видео-ИИ – основные идеи эмбеддингов и токенов, на которых построен этот урок.
• Открытый фронтир – LLaVA, Qwen-VL, LLaVA-NeXT и поле открытых мультимодальных моделей – открытые модели, приёмы компрессии токенов которых мы подробно разобрали здесь.
• Multimodal RAG по видео-архиву – как искать в часах видео, когда даже окна на 1M токенов оказываются недостаточными.