Корпоративный AI: on-premise или облако, как выбрать

Когда компания выходит за рамки экспериментов, появляется практический вопрос: где должен работать её AI? От ответа зависят безопасность, стоимость и доступные модели, а изменить решение потом трудно, если не заложить это заранее.

Единственно верного варианта нет. В статье сравниваются четыре основных подхода и даны критерии выбора.

Четыре варианта

• Публичное облако. Модели доступны как управляемый сервис, например на AWS, Microsoft Azure или Google Cloud. Вы платите за использование и быстро начинаете.
• Частное облако. Выделенная среда, которой управляет провайдер или вы сами, с более сильной изоляцией от других клиентов.
• On-premise. Модели работают на ваших серверах, в вашем дата-центре. Данные не покидают вашу инфраструктуру.
• Гибрид. Разные задачи выполняются в разных местах: чувствительные данные остаются внутри, остальное идёт в облако.

Сравнение

Критерий	Публичное облако	Частное облако	On-premise
Время до старта	Дни	Недели	От недель до месяцев
Контроль над данными	Зависит от договора и настроек	Высокий	Полный
Выбор моделей	Самый широкий	Средний	Модели, которые можно запустить самим
Начальные затраты	Низкие	Средние	Высокие
Стоимость при постоянной высокой нагрузке	Может сильно вырасти	Средняя	Часто ниже
Нужная команда	Небольшая	Средняя	Сильная инфраструктурная команда
Масштабирование	Простое	Ограничено тарифом	Ограничено вашим оборудованием

Критерии выбора

1. Данные

Начните отсюда. Перечислите данные, которых коснётся система, и классифицируйте их: открытые, внутренние, конфиденциальные, персональные. Затем проверьте, что допускают договоры, регуляторы и законы о защите данных в странах, где вы работаете. Некоторые данные могут быть обязаны оставаться в определённом месте или на вашей инфраструктуре, и это сразу решит вопрос.

2. Качество моделей

Самые сильные модели часто доступны только как сервис. Модели с открытыми весами, которые можно запустить самостоятельно, заметно улучшились, но проверяйте их на своих задачах, а не по опубликованным рейтингам. Для многих задач, например классификации или поиска по документам, небольшой модели вполне достаточно.

3. Стоимость и нагрузка

Облачные сервисы берут плату за использование, поэтому подходят для неравномерной или небольшой нагрузки. Своё оборудование стоит денег, даже когда простаивает, поэтому окупается только при постоянной высокой нагрузке. Сравнивайте полную стоимость: оборудование, электричество, сотрудники и обновления, а не только цену сервера. Самая частая ошибка — покупать GPU под нагрузку, которой ещё нет.

4. Команда

Модель на своих серверах нужно установить, обновлять, контролировать и защищать. Если для этого нет людей, кажущаяся экономия исчезает. Облачный сервис снимает значительную часть этой работы, но не настройку, контроль доступа и мониторинг.

5. Скорость и доступность

Если нужны ответы с минимальной задержкой рядом с данными или система должна работать без интернета, это говорит в пользу локального запуска. Если нужно выдерживать внезапные пики, проще в облаке.

Частые заблуждения

• «On-premise автоматически безопасен». Данные остаются внутри, но теперь вы отвечаете за обновления, доступ и мониторинг. Плохо обслуживаемый сервер не безопаснее хорошо настроенного облачного сервиса.
• «Облако всегда обучается на наших данных». Условия различаются у потребительских и бизнес-предложений и у разных провайдеров. Прочитайте договор: как данные используются для обучения, как долго и где хранятся.
• «Выбор делается навсегда». Нет, если это заложить. Тонкий слой между приложениями и моделью позволяет заменить одну модель или площадку другой.

Почему часто выбирают гибрид

Мало у какой компании данные только одного типа. Частая схема — отправлять повседневные задачи в облачную модель, а конфиденциальные данные направлять в модель внутри периметра компании. Слой маршрутизации применяет это правило автоматически, по классификации данных, и записывает каждый вызов.

Цена — дополнительная сложность: две среды для поддержки и модели, которые ведут себя по-разному. Поэтому начните с одной и добавьте вторую, когда этого потребует конкретная задача.

Как принять решение

1. Классифицируйте данные для первых сценариев.
2. Оцените нагрузку: число запросов, пики, рост.
3. Напишите набор тестовых задач на основе реальной работы.
4. Попробуйте на нём две-три модели-кандидата, включая одну, которую можно запустить самим.
5. Посчитайте полную стоимость на ближайшие два-три года.
6. Выберите самый простой вариант, который отвечает требованиям к данным.
7. С самого начала отделите приложения от конкретной модели, чтобы к решению можно было вернуться.

Итог

Данные задают границы, а внутри этих границ вы взвешиваете качество, стоимость и имеющуюся команду. Большинству компаний разумно начинать с самого простого варианта, который допускают их данные, и держать архитектуру готовой к изменениям.

Тот же выбор касается систем RAG и AI-агентов. Чтобы спланировать среду, смотрите услугу Корпоративный AI-контур.

Источники

• AI Risk Management Framework, NIST