Оптимизация затрат – 25 рычагов для видео-ИИ в масштабе

Кратко

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

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

В видео-продукте инференс – стоимость запуска ИИ-модели, в отличие от её обучения – это не строчка в бюджете, а обычно ТА САМАЯ строчка, потому что видео превращает время в оплачиваемую работу со скоростью, которой текстовые продукты не видят. Час видео, отправленный во флагманскую модель в полном разрешении, – это примерно миллион входных токенов ещё до того, как кто-то прочитает хоть слово ответа, а детектор, следящий за камерой, работает тридцать раз в секунду без остановки. Ошибитесь в структуре затрат – и функция, прекрасно выглядящая на демо, станет причиной, по которой юнит-экономика никогда не сойдётся; сделайте правильно – и та же функция окупает себя и финансирует следующую. Этот урок написан для продакт-менеджера, который должен защитить ИИ-бюджет, основателя, выбирающего, куда потратить ограниченный запас прочности, и инженера, которому надо реально снизить счёт, не сломав продукт. Это операционный спутник к уроку про модель затрат, который показывает, как измерить стоимость ИИ в видео; этот же показывает полное меню способов её сократить.

Одна идея: рычаги перемножаются, а не складываются

Прежде чем перейти к списку, удержите идею, ради которой список стоит читать. Рычаги затрат перемножаются. Если один рычаг урезает счёт до трети, второй независимый рычаг тоже урезает его до трети, и третий делает то же – суммарный эффект не «сэкономили треть трижды», а треть от трети от трети, то есть одна двадцать седьмая от того, с чего вы начали. Три скромные, ничем не примечательные перемены, каждая – «выигрыш в 3 раза», превращают счёт в $135 000 в счёт в $5 000.

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

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

Откуда на самом деле берётся счёт за video AI

Нельзя оптимизировать то, чего вы не нашли, поэтому начните с того, в какие единицы превращаются ваши деньги. Каждая ИИ-стоимость в видео-продукте сводится к одной из нескольких единиц – токены (для текстовых и мультимодальных моделей), минуты аудио, сгенерированные секунды (для моделей, создающих видео), GPU-часы (когда вы хостите модель сами) и хранимые байты, – и урок про модель затрат разбирает каждую с ценами 2026 года. Один факт, который надо унести в эту статью, – как быстро видео производит эти единицы: токенайзер Google Gemini превращает час видео в стандартном разрешении примерно в 1,08 миллиона входных токенов (около 300 токенов на каждую секунду съёмки, умножить на 3 600 секунд), так что одна загрузка пользователя может стоить дороже целого дня трафика текстового чат-бота. Именно поэтому первое семейство рычагов – отправлять в модель меньше самого видео – для видео сдвигает счёт сильнее всего.

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

Семейство 1 – Обрабатывать меньше видео (рычаги 1–5)

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

Рычаг 1 – выбирайте кадры, а не обрабатывайте все. Вместо каждого кадра отправляйте разреженную выборку. Простейший вариант берёт один кадр в секунду (сокращение в 30 раз на потоке 30 fps); умный вариант, адаптивная выборка ключевых кадров, выбирает кадры, которые действительно изменились или к которым относится вопрос пользователя, – и исследования показывают, что это и дешевле, и точнее равномерной выборки, потому что тратит внимание модели там, где есть информация. Опубликованные методы «эффективной выборки видео», отсекающие временно избыточные кадры, сокращают время до первого токена модели до 4 раз с минимальной потерей точности. Техника подробно разобрана в уроке про выборку кадров в video VLM.

Рычаг 2 – понижайте разрешение до того, как модель увидит кадр. Модель, тарифицируемая по визуальным токенам, берёт больше за больше пикселей. Большинство флагманских мультимодальных API дают режим «низкого» разрешения медиа, который токенизирует каждый кадр грубее, а большинству задач понимания видео – есть ли человек, что он делает, безопасно ли это – не нужен 4K, чтобы ответить. Отправка кадра 480p вместо 1080p может урезать число токенов на кадр в несколько раз без заметной потери на той задаче, которую вы реально решаете.

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

Рычаг 4 – ставьте дорогую модель за дешёвый триггер. Самый расточительный паттерн в video ИИ – гонять большую модель по расписанию (каждую секунду, каждый клип), когда почти ничего не происходит. Замените расписание событием. Почти бесплатный детектор движения, звуковой триггер или крошечный on-device классификатор решает, когда стоит присмотреться, и только тогда запускается дорогая vision-language модель или облачный API. На потоке наблюдения, который интересен два процента времени, такая «привратниковая» логика сокращает вызовы дорогой модели примерно в пятьдесят раз. Это самый крупный структурный рычаг для постоянно работающего видео.

Рычаг 5 – урезайте промпт и ограничивайте вывод. Текстовые токены тоже стоят денег – с обеих сторон. Раздутый системный промпт, повторяемый на каждом вызове, или безлимитный ответ утекают деньгами в масштабе. Урежьте инструкции до того, что модели реально нужно, и поставьте жёсткий максимум на длину вывода – выходные токены обычно самые дорогие (часто в четыре-восемь раз дороже входных), так что ответ, разросшийся до 2 000 токенов там, где хватило бы 200, – это десятикратный перерасход по самой дорогой строке.

Семейство 2 – Запускать модель поменьше (рычаги 6–10)

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

Рычаг 6 – направляйте простую работу на дешёвый класс. Флагманские модели не вдвое дороже своих маленьких собратьев – обычно они дороже в 8–30 раз. Класс «Flash» или «mini» за $0,30 за миллион входных токенов делает рутинные 90% видео-задач – базовое описание, простая модерация, чистка транскрипта, – для которых флагман за $2,50 и выше был избыточен. Роутер – это маленький быстрый классификатор, который читает каждый запрос и отправляет его в самую дешёвую способную справиться модель. Open-source фреймворк RouteLLM, опубликованный на ICLR 2025, сообщает о сохранении 95% качества GPT-4 при снижении стоимости примерно на 85% на стандартном бенчмарке – за счёт отправки во флагман только по-настоящему сложных запросов.

Рычаг 7 – каскад: сначала дешёвая модель, эскалация только при сомнении. Каскад – честный родственник роутера. Вместо того чтобы предсказывать, какая модель нужна запросу, он сначала запускает дешёвую, проверяет уверенность результата и эскалирует на дорогую только тогда, когда дешёвая не уверена. Опубликованные каскады достигают около 97% точности флагманской модели примерно за четверть её стоимости. Плата – задержка на эскалируемом меньшинстве, что делает каскады отличным выбором для офлайн- и batch-работы и аккуратным для реального времени. Хорошо выставить порог уверенности помогает дисциплина измерений из урока про оценочные стенды.

Рычаг 8 – меняйте флагманский API на маленькую открытую модель там, где позволяет качество. Для высокообъёмных, чётко очерченных задач открытая модель на 1–7 миллиардов параметров, которую вы хостите сами, может быть драматически дешевле за вызов, чем закрытый API, – как только объём достаточно велик, чтобы держать железо загруженным. Точка окупаемости и вопрос «открытое против закрытого» – тема урока про форматы артефактов моделей; смысл по стоимости здесь в том, что за определённым устойчивым объёмом владеть моделью выгоднее, чем арендовать её потокенно.

Рычаг 9 – дистиллируйте меньшего ученика. Дистилляция обучает новую, меньшую модель-«ученика» копировать большую-«учителя», давая по-настоящему меньшую и быструю модель, а не сжатую копию – Distil-Whisper, дистиллированная речевая модель, примерно вдвое меньше и в шесть раз быстрее, оставаясь в пределах одного процента точности оригинала. Механизм, цена и когда за этим тянуться – в уроке про дистилляцию и квантизацию; как рычаг стоимости она уменьшает модель, которую вам надо обслуживать.

Рычаг 10 – квантизуйте модель. Квантизация хранит те же числа модели в меньшем числе бит – переход с шестнадцати на восемь бит урезает память модели примерно вчетверо обычно ценой менее одного процента точности, что позволяет ей работать на меньшем и более дешёвом чипе и быстрее на нём. Дистилляция и квантизация складываются друг с другом (сначала дистилляция, потом квантизация ученика), и обе разобраны в уроке про сжатие.

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

Семейство 3 – Обслуживать модель эффективнее (рычаги 11–15)

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

Рычаг 11 – непрерывный батчинг. GPU экономичнее всего, когда работает над многими запросами сразу, но наивный батчинг заставляет быстрые запросы ждать медленных. Непрерывный батчинг (continuous batching) вставляет новые запросы в батч в момент освобождения слота, держа GPU заполненным. Серверный движок vLLM на непрерывном батчинге сообщает о пропускной способности до 23 раз выше наивной – то есть один GPU делает работу многих по цене одного.

Рычаг 12 – переиспользуйте KV-кэш (PagedAttention). Когда модель генерирует текст, она держит бегущую память диалога – KV-кэш; плохое управление этой памятью растрачивает большую часть мощности GPU. PagedAttention в vLLM хранит её эффективно и позволяет запросам её делить – отсюда значительная часть прироста выше. Механизм объяснён в уроке про сервинг.

Рычаг 13 – спекулятивное декодирование. Маленькая «черновая» модель угадывает несколько следующих токенов, а большая проверяет их все за один параллельный проход вместо генерации по одному. Вывод математически идентичен запуску одной большой модели, но приходит в 2–3 раза быстрее – теперь стандартная функция в vLLM, SGLang и TensorRT-LLM. Более быстрая генерация на том же железе – это меньшая стоимость за результат.

Рычаг 14 – используйте специализированный серверный рантайм. Гонять модель через исследовательский фреймворк – растрата железа. Продакшен-рантайм – vLLM, NVIDIA TensorRT-LLM или SGLang – применяет оптимизации выше и ещё несколько автоматически. Выбор между ними – ядро урока про сервинг.

Рычаг 15 – подбирайте GPU под модель. Гонять маленькую модель на топовой датацентровой карте – платить за мощность, которую вы не можете использовать. Квантизованную модель на 7 миллиардов параметров, которая комфортно влезает в карту среднего класса за долю часовой ставки флагмана, и надо там запускать. Подбирайте чип под объём памяти модели, а не под самое мощное, что есть.

Семейство 4 – Платить меньше за единицу вычислений (рычаги 16–20)

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

Рычаг 16 – используйте batch API для всего, что не реальное время. И OpenAI, и Google предлагают пакетный режим, который выполняет ваши задания в окне 24 часа за фиксированную скидку 50% на вход и выход. Любая видео-задача, которой не нужен мгновенный ответ – ночная модерация дневных загрузок, массовая транскрипция архива, генерация описаний для бэк-каталога – должна идти через batch. Это буквальное вдвое уменьшение счёта за изменение в расписании.

Рычаг 17 – кэшируйте промпт. Когда многие вызовы делят один длинный префикс – фиксированный системный промпт, свод правил, справочный документ – кэширование промпта хранит этот префикс, чтобы вам не выставляли полную цену за его повторную обработку каждый раз. В API Anthropic попадание в кэш стоит 10% от обычной цены входа – скидка 90% на повторяемую часть; другие крупные API предлагают ту же идею. Для промпта модерации видео, отправляющего одну и ту же многостраничную политику на каждом вызове, это почти бесплатные деньги.

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

Рычаг 19 – запускайте прерываемую работу на spot-GPU. Облачные провайдеры продают свободные мощности – spot или preemptible инстансы – на 60–90% ниже on-demand цен с оговоркой, что их могут отозвать почти без предупреждения. Это делает их идеальными для работы, которую можно поставить на паузу и возобновить: batch-транскрипция, обработка архива, офлайн-анализ. Постройте задание так, чтобы оно делало контрольные точки и переповторы, – и запускаете его за долю on-demand стоимости. (Spot – не тот инструмент для живого видеозвонка, который не терпит прерывания.)

Рычаг 20 – резервируйте мощность под устойчивый базис. Случай, обратный spot: дно спроса, которое и так работает 24/7. Под этот предсказуемый базис контракт committed-use или reserved на 1 или 3 года покупает те же GPU на 20–70% ниже on-demand – в зависимости от провайдера и срока. Большинство команд приходят к смеси: зарезервированная мощность под постоянный пол, on-demand под обычные пики и spot под прерываемую batch-работу, – так что ни один тарифный режим не оплачивает всю неровную нагрузку целиком.

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

Семейство 5 – Проектировать и управлять под стоимость (рычаги 21–25)

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

Рычаг 21 – масштабируйтесь до нуля на serverless-GPU. Простаивающий GPU, который вы арендуете по часам, тарифицируется независимо от того, пришёл запрос или нет. Serverless GPU-платформы тарифицируют посекундно за реальную работу и масштабируются до нуля между запросами, так что функция со всплесковым или непредсказуемым трафиком ничего не стоит, пока простаивает. Плата – холодный старт (cold start), секунды на загрузку модели при возврате трафика, от долей секунды для маленьких моделей до десятков секунд для больших, – так что serverless лучше подходит всплесковым нагрузкам, чем стабильно высоким.

Рычаг 22 – выбирайте правильного провайдера и убирайте потери вокруг вычислений. Тот же GPU H100 арендуется примерно за $2–3 в час у специализированного «neocloud» и около $7 в час у гиперскейлера – разрыв 40–85% за идентичный кремний. Помимо заметной ставки кусают скрытые издержки: плата за egress (вывод данных) при перемещении видео из облака, простаивающее хранение записей, которые никто больше не посмотрит, и переразмеренные инстансы. Аудит этого часто больший выигрыш, чем сама ставка GPU, потому что видео тяжёлое, а egress тарифицируется по гигабайтам.

Рычаг 23 – используйте гибридную топологию edge-плюс-облако. Гоните постоянную, дешёвую, чувствительную к задержке работу на устройстве, снявшем видео, или рядом с ним – камере, телефоне, on-premise боксе – и оставьте облаку редкую, тяжёлую, сложную работу. Инференс на устройстве имеет почти нулевую предельную стоимость после покупки железа, держит чувствительные кадры локально и полностью убирает счёт за трафик. Где проходит граница edge-против-облака – тема урока про задержку и развёртывание.

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

Рычаг 25 – заведите бюджеты стоимости по каждой функции и алерты на дрейф. Это рычаг, который делает остальные двадцать четыре устойчивыми. Помечайте каждый вызов модели функцией, которой он служит, ставьте целевую удельную стоимость на пользователя или на час видео для каждой функции, следите за фактической стоимостью против цели в проде и алертите, когда любая функция её превышает. Затраты подкрадываются – модель подменили, промпт разросся, цикл переповторов дал сбой, – и без приборов первым сигналом будет счёт. Как говорит урок про модель затрат, дисциплина измерять до оптимизации важнее любой отдельной техники.

«Частая ошибка. Оптимизировать до измерения и верить, что множители всегда складываются в произведение. Команды тянутся за умным рычагом – спекулятивным декодированием, кастомным роутером – до того, как поставили приборы на то, куда реально уходят деньги, и потом оптимизируют 5%, пока нетронутыми лежат 80%. Вторая половина ловушки – арифметика: рычаги перемножаются только когда они независимы. Направление рутины на более дешёвую модель и последующая квантизация этой модели оба снижают стоимость со стороны модели и частично пересекаются – перемножение их заявленных множителей дважды считает экономию. Урезание числа токенов (рычаг количества) и переход на batch API (рычаг цены) независимы и действительно перемножаются. Прежде чем праздновать «план на 50×», проверьте, что каждый рычаг действует на свою часть счёта, и сверьте итог с реальным измерением, а не с таблицей оптимистичных коэффициентов.»

Разбор примера – стек из трёх рычагов

Сделаем перемножение конкретным на нагрузке, которую мы видим часто: UGC-платформа гоняет «описать и промодерировать каждое загруженное видео», разобранную как инженерную задачу в уроке про модерацию в реальном времени. Допустим, платформа принимает 50 000 часов видео в месяц.

Наивный счёт. Отправляем каждый час во флагманскую модель в полном разрешении. Один час – это около 1,08 миллиона входных токенов (тот самый факт токенизации видео в Gemini), и при цене входа флагмана для большого контекста $2,50 за миллион токенов это:

за час:    1 080 000 токенов × $2,50 / 1 000 000  =  $2,70
за месяц:  $2,70 × 50 000 часов                   =  $135 000

(Выход – короткое описание, несколько центов в час, пренебрежимо против входа.) Итак, точка старта – $135 000 в месяц.

Рычаг 1 – обрабатывать меньше видео. Переходим на низкое разрешение медиа и адаптивную выборку кадров. Консервативно это урезает число входных токенов примерно до трети – около 360 000 токенов в час вместо 1 080 000:

за час:    360 000 × $2,50 / 1 000 000  =  $0,90
за месяц:  $0,90 × 50 000               =  $45 000

Сокращение в 3 раза, без изменения, какая модель и как тарифицируется. $45 000 в месяц.

Рычаг 2 – роутинг на более дешёвый класс. Большинство загрузок рутинны; только доле нужен флагман. Направляем 90% клипов в модель класса Flash за $0,30 за миллион входных токенов и оставляем 10% на флагмане за $2,50. Смешанная цена входа:

смесь:  (0,90 × $0,30) + (0,10 × $2,50)  =  $0,27 + $0,25  =  $0,52 за миллион
за час: 360 000 × $0,52 / 1 000 000      =  $0,187
за месяц: $0,187 × 50 000                =  $9 360

Это ещё сокращение в ~4,8 раза – и оно независимо от первого рычага, потому что рычаг 1 изменил количество токенов, а рычаг 2 – цену за токен. Около $9 400 в месяц.

Рычаг 3 – запустить через batch API. Модерации загрузок не нужен ответ в ту же секунду; несколько часов – нормально. Batch API выполняет те же задания за фиксированную скидку 50%:

за месяц:  $9 360 × 0,50  =  $4 680

Менее $4 700 в месяц – и снова независимо, потому что batch-скидка – рычаг цены, складывающийся поверх и сокращения количества токенов, и выбора класса модели.

Три рычага вместе свели счёт со $135 000 до примерно $4 680 – сокращение в 29 раз – и ни один из них не тронул продукт, который видит пользователь. Четвёртый рычаг, кэширование общего промпта модерации, помог бы лишь пропорционально тому, какую долю каждого вызова занимает повторяемая политика против токенов видео; здесь видео доминирует, так что он добавляет мало. Последний пункт и есть дисциплина: складывайте рычаги, действующие на ваш доминирующий расход, и не записывайте себе в актив рычаги, действующие на и без того малую часть счёта.

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

Какие рычаги под какую нагрузку

Рычаги не универсальны; правильный набор зависит от формы работы. Простой способ выбрать – задать четыре вопроса по порядку. Должно ли это быть в реальном времени? Если да – batch API и spot-GPU отпадают, но кэширование, роутинг и быстрый серверный стек остаются. Повторяется ли вход? Если да – кэширование промпта и семантическое кэширование среди ваших крупнейших выигрышей; если каждый запрос уникален, они почти ничего не дают. Постоянна ли нагрузка круглые сутки? Если да – резервируйте мощность под базис. Всплесковая ли она и непредсказуемая? Если да – serverless scale-to-zero и spot-мощность не дадут вам платить за простой. Прогоните любую новую функцию через эти четыре вопроса до того, как строить, – и вы выберете правильное семейство рычагов ещё до первой строки серверного кода.

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

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

Мы строим видео-продукты в конференц-связи, стриминге и OTT, e-learning, телемедицине и видеонаблюдении, и в каждом из них ИИ-счёт решают эти рычаги, а не выбор модели сам по себе. Наша практика – поставить приборы на стоимость по каждой функции до любой оптимизации, затем проработать дешёвые высокорычажные ходы первыми: обрабатывать меньше видео через выборку кадров и контроль разрешения, ставить дорогие модели за дешёвые триггеры на постоянных потоках, направлять рутину на меньший класс и переносить каждое не-реального-времени задание на batch API за полцены с кэшированием общих промптов. Для self-hosted нагрузок мы обслуживаем модель на эффективном рантайме с непрерывным батчингом и подобранными по размеру GPU, смешиваем зарезервированную мощность под устойчивый пол со spot под прерываемую batch-работу и выносим постоянную, чувствительную к задержке работу на edge, где предельная стоимость падает к нулю. Вертикали меняют, какие рычаги доминируют – поток наблюдения живёт или умирает на запуске-по-событию, OTT-архив – на предвычислении артефактов один раз, функция живой конференц-связи – на кэшировании и быстром серверном стеке, – но метод один: измерять, складывать независимые рычаги и измерять снова.

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

• Рычаги затрат перемножаются, а не складываются – три независимых выигрыша «в 3 раза» дают сокращение в 27 раз, а не в 9.
• Для видео крупнейшее семейство – «обрабатывать меньше»: выборка кадров, понижение разрешения, обрезка и запуск дорогих моделей по дешёвым триггерам.
• Направляйте простые 90% работы на более дешёвый класс модели; оставьте флагман по-настоящему сложному меньшинству.
• Самым дешёвым рычагам не нужно железо: batch API режет стоимость вдвое, кэширование промпта – на 90% повторяемого входа.
• Сопоставляйте тарифный режим с нагрузкой – spot для прерываемой работы, резерв под устойчивый пол, serverless под всплесковой спрос.
• Заведите бюджеты по функциям и измеряйте до оптимизации; нельзя урезать число, за которым вы не следите.

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

• Модель затрат – сколько на самом деле стоит ИИ в видео в масштабе
• vLLM + Triton + TensorRT – инференс-сервинг для video AI
• Дистилляция + квантизация для edge видео-ИИ