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

Кратко

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь проделаем арифметику вслух, потому что стоимость понимания видео – это не более чем это умножение. Допустим, вы отправляете 10-минутный клип в Gemini на дефолтных 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 fps (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 fps она видит один кадр в секунду – она слепа к остальным двадцати девяти тридцатым каждой секунды, и любое событие короче секунды может исчезнуть между сэмплами. «Поддерживает один час» значит «кадры одного часа влезают в память», а не «воспринимает каждый момент часа».

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

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

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

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

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

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

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