Счет за инфраструктуру прилетает в пятницу вечером. Месяц назад вы выкатили новую модель компьютерного зрения в прод. До этого дата-саентисты игрались с ней в Jupyter, жгли пару карточек по запросу, и это стоило копейки. Теперь модель обрабатывает видеопоток с камер 24/7. В графе «Compute» облачного провайдера вместо привычных трехсот тысяч рублей светится пять миллионов. За один месяц.
Арендовать GPU для постоянного ML-инференса — это финансовое самоубийство, которое рынок почему-то привык считать индустриальным стандартом.
Именно здесь ломаются красивые презентации про гибкость и масштабируемость. Когда на повестке дня стоит своя GPU-инфраструктура или аренда облака: TCO-расчёт на 3 года для ML, половина IT-директоров смотрит только на CAPEX. Они видят ценник на сервер с восемью H100, хватаются за сердце и уходят подписывать договор с облаком. Это ошибка, которая стоит бизнесу десятков миллионов.
Математика без иллюзий: CAPEX против OPEX
Возьмем типовую задачу. Нам нужна нода на восемь карт Nvidia A100 80GB. В российских реалиях аренда такой машины по резервируемой модели обойдется примерно в 350 рублей в час за карту, то есть около 2.5 миллионов рублей в месяц за сервер. On-demand тариф улетит еще выше. Умножаем на три года непрерывной работы — получаем 90 миллионов рублей чистых операционных расходов. И это только железо, без учета исходящего трафика и быстрых дисков. За эти деньги вы просто арендовали вычислительные мощности, которые в конце срока вам не принадлежат.
Теперь считаем собственный металл.
Покупка аналогичного сервера на восемь A100 обойдется сейчас примерно в 18 миллионов рублей. Но голый сервер в офисе не работает. Считаем полную стоимость владения: сервер жрет около 5 киловатт под нагрузкой. Размещение в нормальном Tier III дата-центре с учетом питания, охлаждения и порта съест еще около 150 тысяч рублей в месяц. Закладываем ЗИП, страховку от простоя, зарплату инженера на обслуживание. За три года набегает еще около 6 миллионов OPEX. Итого 24 миллиона против 90.
Точка безубыточности проходится на седьмом месяце.
Конечно, свое железо связывает капитал и устаревает за те самые два-три года. Но в случае постоянного инференса, когда утилизация чипов стабильно держится выше 60%, покупка железа — единственный способ не разориться. Облако удобно для экспериментов. Облако прощает ошибки архитектуры. Но облако всегда наказывает рублем за постоянную нагрузку. Здесь возникает вторая проблема — безопасность и суверенитет. Когда вы гоните сырые промышленные данные или клиентскую базу через сторонний дата-центр, вы теряете над ними контроль. В энтерпрайзе безопасники просто не дадут добро на вынос чувствительной информации за периметр.
Наш подход в Morana Labs строится на жестком разделении: предсказуемая базовая нагрузка всегда крутится на железе клиента внутри его контура, а непредсказуемые пики улетают в облако. Это гибридная архитектура.
Выглядит это так: мы ставим локальный кластер, который переваривает 90% ежедневного трафика. Когда случается внезапный наплыв данных, очередь начинает расти. В этот момент автоматика поднимает спотовые инстансы в облаке, обрабатывает излишек и сразу гасит машины. База работает по себестоимости электричества, пики срезаются эластичностью. На уровне оркестрации это решается банальными tolerations в манифестах Kubernetes.
apiVersion: apps/v1
kind: Deployment
metadata:
name: inference-worker
spec:
template:
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
preference:
matchExpressions:
- key: environment
operator: In
values:
- on-premise
- weight: 10
preference:
matchExpressions:
- key: environment
operator: In
values:
- cloud-burst
tolerations:
- key: "cloud-burst"
operator: "Exists"
effect: "NoSchedule"Этот кусок конфигурации спасает бюджеты. Мы заставляем планировщик до последнего пытаться впихнуть поды на локальное железо, и только при жесткой нехватке ресурсов разрешаем ему уходить на облачные ноды.
Ловушка распределенного обучения
Но есть один сценарий, где покупка собственного железа может стать фатальной ошибкой. Это distributed-training больших моделей.
Как только вам нужно обучить foundation-модель, вам перестает хватать одной ноды. Вам нужно десять, двадцать серверов. И тут в игру вступает сеть. Карточки должны общаться между собой на безумных скоростях, иначе они будут простаивать в ожидании весов. Вам нужен Infiniband или топовый RoCE. Стоимость коммутаторов, трансиверов и оптики для такой сети легко удваивает смету всего кластера. Собирать Infiniband-фабрику ради того, чтобы обучить модель за два месяца, а потом оставить этот кластер гнить под редкими задачами файнтюна — дилетантство.
Инференс не требует такой интерконнект-сети.
Поэтому для тяжелого распределенного обучения аренда облачных H100 с уже настроенной сетью на несколько недель обойдется кратно дешевле, чем попытка построить свой мини-суперкомпьютер. Каждый инструмент имеет свою цену и свою зону применения. Постоянный инференс и работа с приватными данными требуют железа на балансе. Эпизодическое обучение и скачкообразные нагрузки требуют облака. Считать экономику нужно не по прайс-листу провайдера, а по реальному профилю нагрузки системы в проде, где p99 latency и утилизация GPU диктуют правила игры.