Когда наступает момент посчитать, сколько на самом деле стоит ИИ-проект: полная смета и скрытые расходы на инфраструктуру всегда оказываются холодным душем для менеджмента. Финансовый директор смотрит на итоговую Excel-таблицу, и у него дёргается глаз. Месяц назад дата-саентисты радостно отчитались об успешном пилоте дефектоскопии на производстве: 99.8% точности, красивые графики в Jupyter. Сегодня ИТ-департамент принёс счет за железо, чтобы раскатить этот пилот на десять конвейерных линий. Бюджет внедрения внезапно вырос с зарплатного фонда пары разработчиков до 100 миллионов рублей за серверную стойку, лицензии и систему охлаждения.
В Morana Labs, когда мы затаскиваем edge-вычисления, RL-агентов и high-load инференс на локальное железо заказчика, мы начинаем не с архитектуры трансформера. Мы начинаем со сметы на стойки. Данные промышленных предприятий не покидают периметр, поэтому облачные сказки здесь не работают. Смета ИИ-проекта всегда ломается о суровую физику.
Бизнес привык платить за написанный код. Но код нейросети ничего не стоит без кремния, который его исполняет. Инфраструктура из GPU-серверов, быстрых NVMe-хранилищ, коммутаторов InfiniBand и систем бесперебойного питания добавляет от 30 до 50 процентов к изначальной оценке. Скрытые расходы на инфраструктуру обнаруживаются, когда выясняется, что для инференса тяжелой модели в реалтайме нужна не игровая видеокарта, а кластер ускорителей уровня H100. К этому плюсуется охлаждение: стойка с современным железом жрёт десятки киловатт и требует прецизионных кондиционеров.
Архитектура тоже диктует цену. Когда мы выносим инференс на edge-устройства ближе к источнику данных — ставим тензорные сопроцессоры прямо на промышленные камеры или контроллеры роборуки — экономится пропускная способность сети. Но взамен приходит логистический ад. Обновление весов модели по воздуху (OTA) на тысяче распределенных девайсов, мониторинг температурного троттлинга на жаре цеха и защита от физического взлома требуют выстраивания полноценной системы управления флотом. Вы платите не за саму нейросеть, а за конвейер её бесперебойной доставки.
Обычный софт пишется один раз и работает десятилетиями. Модели машинного обучения живут в мире меняющейся энтропии. Как только вы задеплоили веса на продакшен, они начинают устаревать. Это значит, что бюджет не закрывается актом выполненных работ за R&D — он только открывается. Взять тот же computer vision на конвейере. Сегодня у вас яркие светодиодные лампы, завтра две из них перегорели, а послезавтра поставщик изменил оттенок пластика на деталях. Точность падает с 99% до 60%. Вам нужен дата-инженер, который соберет этот брак, разметит его заново, прогонит через кластер и выкатит обновленную модель на edge-устройство без остановки производства. Требуется непрерывный пайплайн автоматического переобучения, складирование терабайтов видеопотока и разметка свежих аномалий. И здесь начинается битва за выбор: покупать своё или арендовать чужое.
Капитальные затраты против облачной аренды
Облако кажется безопасным укрытием: платишь только за время утилизации. Но при постоянной, предсказуемой нагрузке облачная математика летит в пропасть. Если камеры гонят видеопоток 24/7, аренда инстанса с восемью топовыми GPU съест бюджет покупки собственного узла за 6-10 месяцев. Окупаемость локального сервера при постоянной загрузке наступает до смешного быстро.
Дьявол кроется в слове «загрузка». Покупать железо выгодно только тогда, когда оно молотит матрицы без остановки. Как не платить за простой GPU? Единственный способ — жесткое динамическое распределение ресурсов между инференсом и тренировкой. Когда производственная линия останавливается на ночь, планировщик должен автоматически отбирать освободившиеся карточки и отдавать их под тяжелые батч-джобы дообучения моделей. Иначе вы отапливаете улицу деньгами. Облако всё-таки дешевле только в одном сценарии: профиль нагрузки напоминает рваную пилу. Редкие спайки запросов, тяжелые эксперименты раз в месяц и долгие недели полного штиля.
def get_3yr_tco(gpu_util_p99: float, nodes: int) -> dict:
cloud_hourly = 8.50
onprem_capex = 350000
power_kw = 10.2
power_rate = 0.15
ops_monthly = 6000
cloud_tco = cloud_hourly * 24 * 365 * 3 * nodes * gpu_util_p99
onprem_power = power_kw * power_rate * 24 * 365 * 3 * nodes
onprem_ops = ops_monthly * 36
onprem_tco = (onprem_capex * nodes) + onprem_power + onprem_ops
monthly_savings = (cloud_tco - onprem_power - onprem_ops) / 36
roi_months = (onprem_capex * nodes) / monthly_savings if monthly_savings > 0 else float('inf')
return {
"cloud_3yr_usd": int(cloud_tco),
"onprem_3yr_usd": int(onprem_tco),
"roi_months": round(roi_months, 1)
}Этот скрипт — примитивная, но отрезвляющая модель, которую мы используем для первичной оценки целесообразности закупки. Стоимость владения (TCO) на горизонте трех лет вычисляется безжалостно: капитальные затраты на железо суммируются с операционными расходами на киловатты, зарплату инженера эксплуатации и амортизацию.
Формула TCO и реальная структура бюджета
Смета ИИ-проекта всегда состоит из четырех макроблоков. Первый — R&D и разработка, те самые зарплаты ML-команды, которые собственник видит на старте. Второй — CAPEX на аппаратное обеспечение: серверы, высокоскоростная сеть, Edge-контроллеры. Третий — регулярный OPEX: счета за электричество, аренда стойко-мест в ЦОДе, лицензии на оркестраторы. Четвертый, самый тяжелый в долгосроке — поддержка и DataOps, где зарыты зарплаты инженеров эксплуатации и стоимость безостановочной разметки новых данных.
Общая формула TCO за три года строится как сумма первоначальных капитальных расходов и тридцати шести месяцев операционных трат на поддержку железа и пайплайнов данных. Если вы не закладываете бюджет на дата-инженеров, которые будут чистить новые датасеты после изменения освещения в цеху, ваш проект гарантированно деградирует ровно через пару кварталов. Индустриальный ИИ — это не магия из пресс-релизов, сгенерированных очередным API. Это тяжелая физическая инфраструктура, расчет тепловыделения и жесточайший контроль издержек на масштабировании. Если вы не посчитали стоимость розетки, вы не посчитали ничего.