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

Кратко

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

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

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

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

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

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

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

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

Нельзя оптимизировать то, чего не видишь, поэтому начните с анализа того, в какие единицы превращаются ваши деньги. Каждая стоимость, связанная с ИИ в видеопродукте, сводится к одной из нескольких метрик: токены (для текстовых и мультимодальных моделей), минуты аудио, сгенерированные секунды (для моделей, создающих видео), GPU-часы (если модель размещается самостоятельно) и хранимые байты. урок про модель затрат подробно разбирает каждую из них с ценами на 2026 год.

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

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

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

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

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

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

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

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

Рычаг 5 – урезайте промпт и ограничивайте вывод. Текстовые токены стоят денег – и с входной, и с выходной стороны. Раздутый системный промпт, который повторяется при каждом вызове, или неограниченный ответ – всё это приводит к лишним расходам в масштабах. Сокращайте инструкции до необходимого минимума и устанавливайте жёсткий лимит на длину ответа: выходные токены, как правило, самые дорогие (часто в 4–8 раз дороже входных). Ответ, растянувшийся до 2000 токенов, когда хватило бы 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% точности флагманской модели примерно за четверть её стоимости. Платой становится задержка на том небольшом числе случаев, где происходит эскалация – поэтому каскады отлично подходят для офлайн- и пакетной обработки, а в реальном времени их стоит использовать с осторожностью. Правильно подобрать порог уверенности помогает дисциплина измерений из урока про оценочные стенды.

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

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

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

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

Семейство 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-плюс-облако. Выполняйте постоянную, недорогую и чувствительную к задержкам задачи на устройстве, снявшем видео, или рядом с ним – на камере, телефоне, локальном сервере – а оставьте в облаке редкие, тяжёлые и сложные вычисления. Инференс на устройстве почти не требует дополнительных затрат после покупки оборудования, хранит чувствительные кадры локально и полностью исключает расходы на трафик. Где проходит граница между 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 – обрабатывать меньше видео. Используем низкое разрешение медиа и адаптивную выборку кадров. Такой подход позволяет сократить количество входных токенов примерно до трети – с 1 080 000 до 360 000 в час.

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

Сокращение в три раза без изменения модели и тарификации. $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-вычислители исключаются, но кэширование, маршрутизация и быстрый серверный стек остаются в игре.

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

Нагрузка стабильна в течение суток? Если да – стоит зарезервировать вычислительную мощность для базового уровня.

А если нагрузка всплесковая и непредсказуемая? Тогда serverless с масштабированием до нуля и 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 видео-ИИ