Когда пилот ИИ выходит в продакшн, вопрос «где считать» перестаёт быть техническим и становится вопросом денег, рисков и регуляторики. Команды, которые довели агентов от пилота до продакшна, быстро упираются в одно: инференс и дообучение моделей требуют GPU, а GPU стоят дорого и в дефиците. Дальше развилка – ставить ускорители у себя или арендовать защищённое облако. Универсального ответа нет, есть критерии выбора.

On-premise: контроль и предсказуемая стоимость на длинной дистанции

Собственная GPU-стойка оправдана, когда нагрузка стабильна и высока. Если кластер инференса загружен на 60–70% круглосуточно, своё железо за 18–24 месяца обходится дешевле аренды – вы платите за капекс один раз, а не за каждый час работы карты. Второй аргумент – данные, которые по закону не покидают периметр. Для значимых объектов КИИ, медицинских и биометрических данных on-premise часто не выбор, а требование.

Цена контроля – операционная нагрузка. Вам нужны питание и охлаждение под 6–10 кВт на стойку, резерв по картам, MLOps-команда и план обновления парка. Дефицит ускорителей и санкционные ограничения на поставки делают планирование закупок отдельной дисциплиной: партию проще законтрактовать на год вперёд, чем докупить срочно. Поэтому инфраструктуру под GPU-нагрузки разумнее проектировать под конкретный профиль моделей, а не «с запасом на всякий случай».

Защищённое облако: скорость старта и эластичность

Облако выигрывает там, где нагрузка неравномерна или вы ещё не знаете её профиль. Пиковое дообучение раз в месяц, сезонные всплески, эксперименты с разными моделями – за это переплачивать капексом бессмысленно. Российские провайдеры предлагают аттестованные сегменты под 152-ФЗ и требования к ГИС, с физической изоляцией стоек и каналами в защищённом исполнении. Это снимает часть регуляторных вопросов, но не все: ответственность за обработку ПДн остаётся на операторе, и договор с провайдером её не перекладывает.

Ключевой риск облака – стоимость на масштабе и зависимость от поставщика. Час H100-класса кажется недорогим, пока вы не умножаете его на круглосуточный продакшн. Поэтому облако хорошо как стартовая площадка и буфер пиков, хуже – как постоянный дом для тяжёлого инференса.

Гибрид как рабочая норма

На практике побеждает не «или-или», а разделение по задачам. Чувствительные данные и стабильный высоконагруженный инференс держим on-premise; обучение, эксперименты и пиковые всплески выносим в защищённое облако. Так работает, например, ИИ-агент для документооборота: индекс и векторная база с конфиденциальными документами живут в периметре, а ресурсоёмкое переобучение запускается в облаке по расписанию.

Чтобы гибрид не превратился в зоопарк, нужны единый слой оркестрации (Kubernetes с поддержкой GPU), общий реестр моделей и сквозной мониторинг утилизации. Для проектов в госсекторе добавляется аттестация контура и требования по импортонезависимости – это мы закладываем на этапе архитектуры, а не латаем потом. Подробнее про регуляторную рамку – в разборе ИИ в ГИС и требований приказа №117.

Вывод

Выбор инфраструктуры под ИИ – это расчёт, а не вкусовщина. Считайте загрузку, горизонт окупаемости, класс данных и регуляторные ограничения. Стабильный тяжёлый инференс и чувствительные данные тянут к on-premise, неравномерные и экспериментальные нагрузки – в защищённое облако. Большинству зрелых внедрений подходит гибрид с понятной границей между контурами и единой оркестрацией поверх них.