guides
Как оценить стоимость проекта по разработке кастомной ML-модели для клиента
Практический фреймворк для оценки стоимости проектов по кастомным ML-моделям — от скоупинга работы с данными до постановки вех — чтобы не продешевить и не потерять клиента посреди проекта.
Вы озвучили клиенту цену $8000 за «простую модель классификации». Прошло три недели, вы всё ещё чистите его данные, требования поменялись уже дважды, и если посчитать реально потраченные часы, ваша ставка составляет около $12/час. Такое в ML-консалтинге происходит постоянно, и почти всегда это проблема ценообразования, а не навыков.
Сколько нужно брать за проект по кастомной ML-модели?
Большинство проектов по кастомным ML-моделям для небольших и средних клиентов укладываются в диапазон от $5000 до $60 000 — в зависимости от готовности данных, сложности модели и того, включены ли развёртывание и поддержка. Базовая модель классификации или регрессии на чистых данных, предоставленных клиентом, может стоить $5000-$15 000. Продакшн-система компьютерного зрения или NLP с работой над пайплайном данных, кастомной архитектурой и инфраструктурой развёртывания может обойтись в $25 000-$100 000+. Главный фактор, влияющий на цену, — не сама модель, а то, насколько «грязные» данные у клиента.
Почему фиксированные расценки не работают в ML-проектах
Софтверные проекты относительно предсказуемы: вы знаете функциональность, вы её реализуете, вы поставляете результат. С ML-проектами всё иначе. Вы на самом деле не знаете, достижима ли нужная точность модели, пока не изучите данные — а значит, вы называете фиксированную цену до того, как узнаёте реальный объём работы.
Это ловушка, в которую попадает большинство фрилансеров и небольших ML-студий. Они оценивают проект так, будто это веб-разработка, а потом выясняют, что «чистый CSV» клиента на самом деле на 40% состоит из пропущенных значений, метки противоречивы, а «быстрая модель» требует трёх итераций, чтобы достичь приемлемой точности. Если вам доводилось оценивать похожий проект, например разработку чат-бота, эта закономерность вам знакома — см. как оценить стоимость проекта по разработке чат-бота для клиента из малого бизнеса — логика там очень похожая.
Разбейте проект на фазы, а не на одну цифру
Решение — оценивать стоимость по фазам, каждая со своим объёмом работы и своим счётом. Это защищает вас от расширения объёма работ без соответствующей оплаты и даёт клиенту контрольные точки для оценки ценности перед тем, как выделять больше бюджета.
Фаза 1 — Discovery и аудит данных (фиксированная плата, $1500-$4000): оценка качества данных, определение метрик успеха, подтверждение реализуемости. Результат — документ со скоупом проекта, а не модель.
Фаза 2 — Подготовка данных и baseline-модель ($3000-$15 000): очистка, разметка и структурирование данных; создание простой базовой модели, доказывающей жизнеспособность подхода.
Фаза 3 — Разработка и настройка модели ($5000-$30 000): создание и итеративное улучшение продакшн-модели, проведение экспериментов, достижение согласованной целевой точности.
Фаза 4 — Развёртывание и передача ($2000-$15 000): упаковка модели в API или приложение, написание документации, обучение команды клиента.
Фаза 5 — Поддержка (ежемесячный ретейнер, $500-$5000/месяц): мониторинг дрейфа модели, периодическое переобучение, устранение багов.
Фазу 1 оценивайте как фиксированную плату. Фазы 2-4 оценивайте только после того, как вы реально увидели данные — вы не можете честно назвать цену на то, что не изучили.
Какие факторы на самом деле влияют на цену
Клиенты будут спрашивать «почему это стоит так дорого» — держите наготове конкретные ответы. Вот переменные, которые должны определять вашу цену, примерно в порядке значимости:
Качество и объём данных. Чистые, размеченные, достаточные по объёму данные могут сократить сроки вдвое. Отсутствие меток или крошечные датасеты (менее нескольких сотен примеров для большинства задач) часто означают, что сначала придётся строить пайплайн сбора данных, а это уже отдельная статья расходов.
Сложность модели. Логистическая регрессия или градиентный бустинг обходятся дёшево. Кастомная архитектура глубокого обучения, дообученная LLM или мультимодальная модель стоят значительно дороже как по вычислениям, так и по времени разработки.
Требуемая планка точности/производительности. Переход с 85% до 92% точности может потребовать столько же усилий, сколько все первые 85%. Зафиксируйте целевую цифру в письменном виде до старта работ.
Требования к развёртыванию. Передача Jupyter-ноутбука обходится дёшево. Real-time API, обрабатывающий тысячи запросов в день с мониторингом и автомасштабированием, — это совершенно другой проект.
Требования к комплаенсу и объяснимости. В здравоохранении, финансах и юридической сфере часто требуется объяснимость модели (SHAP-значения, аудиторские трейлы) — заложите на это дополнительное время.
Потребность в постоянном переобучении. Если распределение данных клиента меняется (сезонный спрос, новые продуктовые линейки), вам нужен план переобучения и ретейнер, а не разовая оплата.
Фиксированная цена vs. Time-and-Materials — что выбрать?
Используйте фиксированную плату только для Фазы 1 (Discovery), где объём работ действительно ограничен. Для всего остального оплата по факту затраченного времени или на основе вех защищает обе стороны лучше. Фиксированная цена на этапе разработки модели стимулирует вас срезать углы, как только вы выходите за рамки своей оценки — это плохо и для качества модели клиента, и для вашей маржи.
Если клиент настаивает на единой цифре для всего проекта (а многие так и делают), заложите буфер в 25-40% сверх вашей честной оценки, чтобы покрыть неизбежные сюрпризы с данными. Прямо пропишите это в предложении: «Данная оценка предполагает, что предоставленный датасет требует стандартной очистки; серьёзные проблемы с качеством данных, обнаруженные в ходе Фазы 1, будут оценены отдельно».
Пропишите это в техническом задании, а не только в смете
Цена без чётко ограниченного техзадания (SOW) — это то, откуда начинаются споры. Как минимум, ваше техзадание должно фиксировать:
Точную метрику успеха (точность, F1-score, задержку) и способ её измерения
Кто отвечает за очистку данных — вы, клиент или это разделено
Количество раундов итераций модели, включённых в стоимость, до того как начнут применяться дополнительные часы
Как выглядит «готово»: файл модели, эндпойнт API или полностью развёрнутая система
Включено ли постоянное переобучение или оно оплачивается отдельно
Если вы формализуете это для интеграции ML в существующий продукт, стоит почитать про как собирать требования клиента для брифа кастомного AI-чат-бота — процесс сбора требований почти идентичен для ML-проектов: зафиксируйте требования до того, как называть какую-либо цену.
Распространённые ошибки в ценообразовании, которых стоит избегать
Оценка проекта до того, как увидели образец данных. Всегда запрашивайте образец данных, прежде чем оценивать что-либо помимо Discovery.
Занижение цены из-за «это же просто скрипт». Клиенты платят не за строки кода — они платят за бизнес-результат (меньше ручных проверок, более быстрые решения, новый доход). Оценивайте стоимость исходя из этого результата.
Отсутствие целевой точности в письменном виде. Без чётко определённой планки фраза «модель недостаточно хороша» превращается в бесконечный неоплачиваемый цикл доработок.
Игнорирование затрат на вычисления. Обучение крупных моделей или инференс в масштабе стоит денег — выставляйте облачные расходы отдельной строкой или закладывайте их в свою ставку.
Пропуск разговора о поддержке. Модели деградируют. Если вы не продадите ретейнер на поддержку заранее, через полгода вам позвонит рассерженный клиент, когда точность незаметно упала, а никто за этим не следил.
Информирование клиента без лишних накладных расходов
Как только вы оценили проект и приступили к работе, регулярные статус-апдейты для клиента — это то, что оправдывает счета и предотвращает споры об объёме работ в дальнейшем. Если вы одновременно ведёте несколько ML- или автоматизационных проектов для разных клиентов, управление этой коммуникацией вручную быстро превращается в хаос — с той же проблемой сталкиваются агентства, ведущие Telegram-аутрич кампании в масштабе. CRMChat — это Telegram-нативная CRM, которая позволяет вести изолированные рабочие пространства для каждого клиента, так что апдейты по проекту, чек-ины по вехам и напоминания о счетах для каждого ML-проекта остаются разделёнными и никогда не смешиваются между аккаунтами. CRMChat также включает динамические последовательности сообщений, которые автоматически уведомляют клиента о переходе проекта на новый этап — удобно, если вы хотите, чтобы сообщение о завершении вехи отправлялось в момент, когда вы отмечаете Фазу 2 как выполненную в своей системе учёта, без необходимости вручную писать каждому клиенту по отдельности.
Для агентств, ведущих сразу несколько ML- или dev-проектов, изоляция клиентов имеет не меньшее значение, чем модель ценообразования. Ознакомьтесь с разбором дашборда отчётности для клиентов агентств аутрича — там показано, как агентства выстраивают такую отчётность по аккаунтам.
Простой чек-лист по ценообразованию перед отправкой сметы
Вы видели реальный образец данных клиента, а не просто их описание?
Есть ли письменная, числовая метрика успеха (а не «сделать точной»)?
Разбили ли вы проект минимум на 3 фазы с отдельными результатами?
Явно ли ваша смета разделяет разовую стоимость разработки и постоянную поддержку?
Добавили ли вы буфер в 25-40%, если клиент требует единую фиксированную цифру?
Указаны ли затраты на вычисления/инфраструктуру отдельной строкой от вашей оплаты труда?
Сделайте эти шесть вещей правильно — и вы вряд ли снова окажетесь работать над проектом за $12/час.
