Сколько стоит MVP: разбор реальных бюджетов на AI-продукты

TL;DR: Смету AI-MVP считают одним из двух способов — по этапам работ или по составу команды на срок. Смешивать их нельзя: получите двойной счёт. От обычного софта AI-MVP отличают четыре скрытые статьи расходов: разметка данных с контролем качества, стоимость инференса, регрессионный набор для оценки модели и пересчёт эмбеддингов при смене модели. Честная смета — это baseline на правилах, фиксированная цена за обвязку и таймбокс на исследование.

Главная ошибка в сметах: двойной счёт

Сначала про ошибку, которую я вижу почти в каждой смете от подрядчиков. В документе перечислены этапы — исследование, подготовка данных, обучение модели, разработка интерфейса — и у каждого стоит цена. А ниже отдельной строкой: «команда, 3 месяца». И всё это суммируется.

Это двойной счёт. Стоимость этапа и есть стоимость людей, которые этот этап делают. Если вы платите за этап «разработка модели» и отдельно за ML-инженера, который её разрабатывает, — вы платите дважды за одну и ту же работу.

Существует ровно две взаимоисключающие модели расчёта.

Модель 1: по этапам

Смета — это список работ с трудоёмкостью. Каждая строка: задача, оценка в часах или днях, ставка, итог. Итоговая цена — сумма строк. Ставки исполнителя уже «зашиты» в цены этапов.

Модель 2: по команде × срок

Смета — это состав команды и длительность: ML-инженер, бэкенд-разработчик, продакт на полставки, два месяца. Цена = сумма ставок × время. Этапы тут не тарифицируются отдельно — они внутри этого времени.

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

Чем AI-MVP отличается от обычного

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

Из этого критерия растут все отличия в смете.

1. Разметка данных

Если модель учится на ваших примерах, эти примеры кто-то должен разметить. И это не «посадить студента на выходные». Нормальный процесс:

Инструкция разметчику. Документ с критериями и примерами пограничных случаев. Без него десять разметчиков разметят десять разных датасетов. Его пишет ML-инженер, и это дни работы.
Двойная разметка. Процент выборки размечают два человека независимо — так измеряется согласованность и ловятся ошибки.
Арбитраж. Расхождения разбирает третий, более опытный человек. Это ещё одна ставка.

В смете разметка должна быть разбита на: написание инструкции, сама разметка (объём × цена за единицу), контроль качества. Одна строка «разметка, N тысяч» — признак того, что про качество не думали.

2. Стоимость инференса

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

затраты = документов в месяц
        × вызовов модели на документ
        × средних токенов на вызов (вход + выход)
        × цена за 1 млн токенов / 1 000 000

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

# Числа — для примера счёта, цены возьмите из прайса провайдера
docs_per_month = 10_000        # документов в месяц
calls_per_doc = 3              # классификация + извлечение + проверка
tokens_per_call = 2_000        # вход + выход
price_per_million = ...        # из прайса: цена за 1 млн входных токенов

monthly_cost = (docs_per_month * calls_per_doc * tokens_per_call
                / 1_000_000) * price_per_million

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

3. Регрессионный набор

Как вы узнаете, что модель стала лучше после правки промпта или смены версии? Нужен фиксированный набор примеров с эталонными ответами и метрика. Собрать его — это работа: отобрать репрезентативные случаи, включить каверзные, разметить эталоны, написать скрипт оценки. Без регрессионного набора каждое изменение — игра в рулетку, а споры «стало лучше или хуже» решаются мнением.

4. Пересчёт эмбеддингов

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

Таблица факторов удорожания

Собрал в одну таблицу то, что отличает смету AI-MVP от сметы обычного софта:

Фактор	Почему дорожит	Как контролировать
Разметка данных	Инструкция, двойная разметка, арбитраж	Считать объём × цену за единицу + строка на контроль
Инференс	Каждый запрос пользователя стоит токенов	Формула выше, подстановка цен из прайса
Регрессионный набор	Сбор примеров, эталоны, скрипт оценки	Отдельная строка, обязательна к MVP
Смена модели	Пересчёт эмбеддингов, перепроверка качества	Фиксировать модель до релиза, оценивать миграцию отдельно
Рост контекста в RAG	Входные токены растут с базой знаний	Ограничивать число фрагментов, следить за метриками
Исследовательская неопределённость	Заранее неизвестно, достигнет ли модель качества	Таймбокс на PoC вместо фиксированной оценки

Чего не должно быть в смете MVP

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

MLOps-контур

Пайплайны переобучения, версионирование моделей, автоматический деплой, мониторинг дрифта — всё это нужно, когда продукт живёт и модель регулярно обновляется. На MVP достаточно: скрипт обучения, скрипт оценки, ручной деплой. Строить MLOps до подтверждения ценности — значит автоматизировать процесс, которого, возможно, не будет.

Дообучение модели

Для большинства задач MVP хватает готовой модели с хорошим промптом или few-shot-примерами. Дообучение оправдано, когда точно измерено, что промптинг не даёт нужного качества — а измерено может быть только регрессионным набором. Если дообучение в смете, а регрессионного набора нет, порядок перепутан.

Своя GPU-инфраструктура

Аренда железа, настройка серверов, дежурства — это месяцы работы DevOps. На MVP пользуйтесь API провайдеров или облачными инстансами по факту. Своё железо начинает экономить при стабильной высокой нагрузке, а у MVP нагрузка — это то, что ещё предстоит найти.

Как я строю смету: три принципа

Принцип 1: Сначала baseline на правилах

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

Работает это и для смежных задач: например, перед тем как платить за ML-извлечение текста из сканов, проверьте, что дают готовые инструменты распознавания — в статье про OCR в 2026 я разбирал, где порог «достаточно хорошо».

Принцип 2: Фикс на обвязку, таймбокс на исследование

Обвязка — API, интерфейс, интеграции, деплой — оценивается хорошо и должна идти по фиксированной цене. Исследовательская часть — достигнет ли модель нужного качества — в часах не оценивается вообще, честная цена это «таймбокс две недели, на выходе метрики и решение go/no-go». Смета, где исследование оценено фиксом, означает либо заложенный втридорога риск, либо обещание результата, которого никто гарантировать не может.

Принцип 3: Concierge при неподтверждённом спросе

Если главная неизвестная — нужен ли продукт вообще, а не сработает ли модель, — не стройте смету на разработку. Запустите concierge-вариант: снаружи продукт выглядит как работающий AI, внутри первые десятки запросов обрабатываете вы сами или оператор. Стоимость — недели вместо месяцев, зато спрос проверен до инвестиций в разработку. Как это вписывается в современный подход к MVP, описано в статье про минимальное доказательство ценности.

Как проверить чужую смету: четыре вопроса

Покажите смету подрядчика этим вопросам. Ответы скажут больше, чем цифры.

Какая модель расчёта: по этапам или по команде? Если в смете есть и цены этапов, и стоимость команды — ищите двойной счёт, попросите пересчитать одним способом.
Как измеряется качество модели? Ответ «потестируем вручную» — красный флаг. Правильный ответ содержит регрессионный набор, метрику и целевое значение.
Что заложено в эксплуатацию? Должна прозвучать формула стоимости инференса с подстановкой цен провайдера, а не одно число «сервер, N в месяц».
Что будет, если модель не достигнет качества за отведённое время? Хорошие варианты: таймбокс с точкой go/no-go, откат на baseline, concierge-режим. Плохой вариант: «дотянем за дополнительный бюджет».

FAQ

Можно ли сделать AI-MVP совсем дёшево?

Можно, если сузить рамки до PoC: готовые данные, готовая модель без дообучения, минимальный API без интерфейса. Но назовите это честно — это проверка технической осуществимости, а не продукт для пользователей.

Что дороже: разработка модели или разработка продукта вокруг неё?

Почти всегда обвязка: интерфейс, интеграции, сценарии ошибок, деплой. Модель в MVP — это недели, продукт вокруг неё — месяцы. Если в смете самая дорогая строка — «разработка модели», а продуктовая разработка оценена впритык, оценки стоит перепроверить.

Нужен ли в команде дата-саентист на полный день?

На MVP чаще достаточно ML-инженера, который умеет работать с готовыми моделями и API. Отдельный исследователь нужен, когда задача нестандартная и PoC показал, что готовые подходы не проходят по качеству.

Когда MVP превращается в продукт и смета меняется?

Когда подтверждены спрос и качество модели. Вот тогда в смете появляются MLOps, мониторинг, оптимизация стоимости инференса — всё то, что на MVP правильно было вычеркнуть.

Как заложить риск неопределённости в бюджет?

Не процентом «на всякий случай», а структурой: baseline на правилах как страховка, таймбокс на исследование с точкой go/no-go, поэтапная оплата. Так риск ограничен суммой до первой точки решения, а не размазан по всему проекту.

Если выбираете фреймворк для обвязки такого MVP, мой разбор FastAPI и Django для AI-продуктов поможет не переплатить за разработку на старте.

Нужна помощь с оценкой или проверкой сметы AI-MVP? Напишите мне — разберём вашу задачу и посчитаем честно.