Большинство компаний, решивших пилить свой ИИ с нуля, закроют проект через год с убытком в десятки миллионов, потому что они не умеют считать. Топы мыслят категориями веб-разработки: наймем пару синьоров, дадим им задачи в Jira, через три месяца получим фичу. С машинным обучением это так не работает. Своя ML-команда или подрядчик: математика выбора при дефиците кадров давно перестала быть вопросом корпоративных амбиций, превратившись в вопрос элементарного финансового выживания.
Я регулярно смотрю на аналитику рынка труда. Дефицит ML-специалистов — это структурная дыра, которая сохранится минимум до 2030 года. Университеты не успевают клепать джунов, а джуны без мощной математической базы и менторства не превращаются в мидлов. В итоге мы имеем рынок, где на одну вакансию Senior ML приходится 1,2 резюме. Не прошедших скрининг кандидатов, а просто присланных бумажек, половина из которых — это мамкины промпт-инженеры, один раз запустившие файнтюн LLaMA по туториалу. Если вам нужен человек, способный собрать пайплайн компьютерного зрения, который не ляжет на потоке видео с десяти заводских камер, готовьтесь платить. Senior ML сегодня спокойно просит до 550 тысяч рублей в месяц на руки. И он будет выбирать проект, а не вы его.
Налог на иллюзии и реальная стоимость инхауса
Построение своего отдела часто начинается с классической ошибки: CTO берет желаемую зарплату инженера, умножает на двенадцать месяцев и идет защищать бюджет. Забывая при этом, что чистый оклад — это даже не половина реальной стоимости владения (TCO) сотрудником.
Сверху ложатся налоги и взносы. Дальше — железо. ML-инженер не будет кодить на базовом макбуке, ему нужен доступ к кластеру с GPU для экспериментов. И вот тут начинается самое интересное: профиль работы Data Scientist’а — это не линейное закрытие тикетов. Это гипотезы. Он может полтора месяца крутить архитектуру нейросети, подбирать гиперпараметры, чтобы в итоге прийти к вам и сказать: «на этих данных модель не сходится, нужно собирать новый датасет». Вы оплачиваете этот простой из своего кармана. Вы оплачиваете обучение модели, жгущее серверное время. Вы оплачиваете инфраструктуру и MLOps, потому что голая модель в Jupyter-ноутбуке ничего не стоит без обвязки, способной держать нагрузку в проде.
Давайте переведем это в строгие цифры. Оценим базовый TCO одного сеньора за год, учитывая риск его внезапного ухода.
def calc_ml_inhouse_tco_yearly(base_net_salary, tax_rate=0.43, hardware_gpu_cost=800000):
monthly_gross = base_net_salary * (1 + tax_rate)
yearly_payroll = monthly_gross * 12
# Риск: удержание и стоимость замены (Bus Factor = 1)
# По статистике средний срок жизни ML-инженера в не-BigTech компании — 1.2 года
hiring_agency_fee = monthly_gross * 2 # Оплата кадровикам за поиск замены
onboarding_loss = monthly_gross * 3 # Простой разработки во время онбординга
churn_probability = 0.8 # Вероятность, что человек уйдет или перегорит за год
risk_premium = churn_probability * (hiring_agency_fee + onboarding_loss)
total = yearly_payroll + hardware_gpu_cost + risk_premium
return total
# Для Senior ML с окладом 550 000 руб/мес на руки
tco = calc_ml_inhouse_tco_yearly(550000)
print(f"Yearly TCO: {tco:,.0f} RUB")
# Вывод: Yearly TCO: 15,005,600 RUB
Пятнадцать миллионов рублей в год за одну боевую единицу. И это без учета того, что один человек не вытянет полноценный продакшен — ему нужен Data Engineer для очистки данных и DevOps для деплоя.
Худшее во всей этой истории — риск потери экспертизы. Когда ваш ключевой data scientist пишет заявление на увольнение, потому что Яндекс или Сбер предложили ему в полтора раза больше, ваша разработка встает намертво. Он уходит, оставляя после себя зоопарк неструктурированных экспериментов, в которых новый человек будет разбираться месяцами. Архитектура инхаус-команды из двух человек обладает автобусным фактором (bus factor) равным единице: один попал под автобус (или схантили) — проект мертв.
Гибрид как стратегия выживания
Понимая эту математику, адекватный бизнес перестает играть в IT-империю и переходит к суровому прагматизму. Нанять ML-команду целиком оправдано только в одном случае: когда нейросеть — это ваш core-продукт. Если вы строите убийцу Midjourney или пишете свой автопилот для дронов, алгоритмы обязаны быть внутри контура, это ваше главное конкурентное преимущество (IP). Кровите деньгами, но нанимайте.
Во всех остальных сценариях — когда ИИ нужен для оптимизации логистических маршрутов, предсказания оттока клиентов, дефектоскопии деталей на конвейере или парсинга счетов-фактур — аутсорс ИИ кроет инхаус по всем метрикам. Нейросеть здесь — просто продвинутый инструмент снижения издержек.
Идеальная схема для энтерпрайза сегодня — это гибрид. Вы держите внутри компании сильного архитектора или тимлида (ядро инхаус). Этот человек глубоко погружен в бизнес-логику, понимает, откуда текут данные, и знает, где именно машинное обучение принесет деньги, а где достаточно регулярного выражения. А всю тяжелую работу — разметку гигантских массивов, тренировку тяжелых трансформеров, профилирование нагрузки на видеокартах — вы отдаете на аутстафф или забираете в виде готового заказного решения.
Матрица: Build против Buy
Чтобы прекратить холивары на совете директоров, я обычно кладу на стол простую таблицу оценки. Она отрезвляет.
Параметр | Своя команда (Build) | Подрядчик / Аутсорс ИИ (Buy) |
|---|---|---|
Time-to-market | 6-9 месяцев (поиск людей, онбординг, закупка GPU, первые фейлы на проде) | 1-3 месяца (приходят со своими претрейнами, фреймворками и кластерами) |
Цена ошибки (гипотеза не взлетела) | Миллионы на зарплаты, зависшее на балансе железо, сложный процесс увольнения | Ограничена стоимостью контракта на R&D (PoC-этап за фиксированную сумму) |
Непрерывность бизнеса | Разработка парализуется при увольнении Senior-специалиста | Гарантируется договором (замена разработчика — проблема вендора) |
Доступ к железу | Капитальные затраты (CAPEX) или конские счета за облако с первого дня | Вендор тренирует на своих мощностях, вы платите только за инференс-сервер |
Покупая чужую экспертизу, вы платите за кривую обучения, которую подрядчик уже прошел на десятках других проектов. Он уже знает, почему конкретная архитектура деградирует на плохом освещении с заводских камер, и не будет тратить ваши три миллиона рублей на перепроверку этого факта.
У нас в MoranaLabs мы решаем этот запрос индустрии через жесткое разделение зон ответственности. Мы не продаем процесс ради процесса. Мы забираем данные, проектируем архитектуру, обучаем модель на своих мощностях, а затем приходим к клиенту и разворачиваем оптимизированный инференс прямо на его железе (edge-вычисления), чтобы критичные данные не покидали периметр завода или банка. После нас остается не пачка сырых скриптов, а задокументированный бинарник и API, к которому могут обращаться штатные бэкендеры заказчика, вообще не понимающие, как работает градиентный спуск. Это не магия, это инженерный подход к делегированию, который оставляет бизнес с работающей системой, а не с раздутым зарплатным фондом.