Как считать стоимость AI-обработки видео: оплата по секундам без обязательной подписки

Практический разбор единицы потребления, предоплаченных кредитов, возвратов при сбоях и асинхронной обработки.

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

У AI-обработки видео другая экономика. Себестоимость возникает почти при каждом запуске и обычно растёт вместе с длительностью материала. Поэтому логичная продуктовая модель — брать деньги за фактическое потребление, но реализовать её честно сложнее, чем просто умножить минуты на цену.

Нужно решить:

Ниже — схема, к которой мы пришли при разработке сервиса обработки видео.

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

Два файла с расширением MP4 могут отличаться в сотни раз:

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

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

Упрощённую себестоимость одной задачи можно представить так:

cost = duration × ai_rate + encoding + storage + traffic + expected_failure_cost

В конкретном продукте формула может учитывать разрешение, число кадров, модель или тип результата. Важно не копировать чужую единицу тарификации, а найти собственный главный драйвер затрат.

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

Мы выбрали начатую секунду:

constcredits=Math.ceil(durationMs/1000);

Если видео длится 12,1 секунды, задача требует 13 кредитов. Такая схема:

Миллисекунды нужно нормализовать в одном месте на сервере. Нельзя позволять браузеру окончательно определять цену: клиентские метаданные можно подменить, а разные браузеры иногда по-разному округляют длительность.

Браузер может показать предварительную оценку, но сервер должен повторно проверить входные данные и рассчитать окончательное списание по единому правилу.

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

Stripe в документации по billing credits описывает кредитную модель как один из вариантов usage-based billing: клиент заранее покупает объём, а затем расходует его на конкретную услугу. Важно, что такие кредиты — не электронный кошелёк и не деньги для переводов третьим лицам, а право потребить услугу внутри продукта. Это же различие стоит явно закрепить в условиях сервиса.

У кредитов есть четыре продуктовых преимущества:

Но есть и обязательства:

Хранить только текущий баланс недостаточно. После первого спорного возврата будет невозможно ответить, почему у пользователя именно такое число кредитов.

Минимальная запись в журнале содержит:

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

Пример ключей:

consume:task_123refund:task_123purchase:payment_456support:ticket_789

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

Есть два рабочих подхода.

Система временно блокирует нужный объём, а после успеха превращает резерв в окончательное списание. При неудаче резерв снимается.

Плюсы:

Минусы:

Система списывает кредиты перед обращением к дорогому провайдеру. Если задача не завершилась, отдельная операция возвращает ту же сумму.

Плюсы:

Минусы:

Для первого релиза мы выбрали списание с компенсацией. Ключевое условие — возврат является не изменением старой записи, а новой положительной операцией с уникальным ключом refund:taskId.

Внешний AI-провайдер может закончить вычисление, но это ещё не значит, что пользователь получил результат.

Практическая цепочка выглядит так:

uploaded → queued → processing → saving → completed

Задача становится completed только после того, как результат сохранён в хранилище продукта и доступен через контролируемую ссылку скачивания.

Если провайдер вернул файл, но копирование в собственное хранилище оборвалось, для пользователя задача ещё не выполнена. Списывать деньги за «успех, который нельзя скачать» — плохой продуктовый договор.

Полезно заранее оформить таблицу решений:

Последние два пункта важны: продукт оплатил успешное вычисление и хранение результата. Возврат должен компенсировать техническую неудачу сервиса, а не отсутствие интереса после успешной обработки.

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

Надёжнее разделить загрузку, запуск и получение результата:

Cloudflare в документации Workflows описывает эту модель как durable execution: состояние сохраняется между шагами, а отдельные операции можно повторять после временного сбоя. Для больших файлов документация R2 рекомендует прямую или multipart-загрузку вместо проксирования всего видео через приложение.

Такая архитектура влияет не только на надёжность, но и на деньги. Если шаг сохранения можно безопасно повторить, временная ошибка хранилища не превращается в дорогой повторный запуск AI.

Автоматический retry полезен только для идемпотентных операций.

Безопасно повторять:

Опасно автоматически повторять:

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

Если внешнее API не поддерживает идемпотентность, шаг отправки лучше не повторять автоматически. Задачу безопаснее завершить ошибкой и вернуть кредиты, чем создать неизвестное число платных вычислений.

Видео тяжёлое и часто содержит личные данные. Бессрочное хранение увеличивает расходы, риски и объём обязательств.

Нужно отдельно определить сроки для:

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

Короткий срок хранения работает только при хорошем интерфейсе:

Usage-based модель вызывает доверие, когда пользователь понимает расчёт заранее.

До кнопки запуска стоит показать:

Плохой вариант — написать «от одного кредита», а окончательную сумму показать после обработки. Хороший — ещё до списания вывести: «Видео 2:14, потребуется 134 кредита».

Статус задачи тоже должен описывать реальный этап, а не бесконечное processing:

Если задача упала, интерфейс должен явно сообщить, что кредиты возвращены. Пользователь не обязан сравнивать баланс вручную.

Пакеты решают сразу две задачи: уменьшают количество платежей и дают продукту запас маржи на колебания себестоимости.

Но скидка за большой пакет имеет смысл только после расчёта:

gross_margin = revenue - ai_cost - payment_fee - storage_and_traffic - expected_refunds - support_cost

Ошибка — смотреть только на тариф внешнего AI API. Маленькие платежи сильнее чувствуют фиксированную часть комиссии. Длинные видео повышают вероятность сетевого сбоя. Неудачная задача может потребовать и возврата кредитов, и уже понесённых расходов у провайдера.

Для начала достаточно трёх-четырёх пакетов с понятным объёмом в минутах. Не стоит имитировать подписку скрытым сгоранием баланса, если продукт позиционируется как pay-as-you-go.

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

Минимальный набор метрик:

Особенно полезно разделять ошибки по этапам. Сбой до вызова AI почти ничего не стоит. Сбой после дорогого вычисления, но до сохранения результата — одна из самых неприятных категорий для маржи.

Кредитная модель — не универсальный ответ.

Лучше выбрать подписку или контрактный тариф, если:

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

Оплата по факту использования кажется простой только на лендинге. Внутри продукта это договор между измерением, биллингом, асинхронной обработкой, хранением и компенсацией ошибок.

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

Если ответы видны до запуска, а журнал операций и workflow выдерживают повторы, pay-as-you-go становится не только способом монетизации, но и преимуществом продукта. Пользователь платит за понятный объём работы, а команда видит экономику каждой выполненной задачи, а не среднюю температуру по подпискам.

Материал подготовлен с AI-помощью, существенно отредактирован и проверен автором на основе практической разработки продукта.