On-premise означает, что система работает на оборудовании, которое стоит у вас или в вашем дата-центре, и вы им управляете. Облако означает, что она работает на чужом оборудовании, а вы платите за использование. Разница видна не в архитектуре, а в том, кто отвечает за доступность и кто имеет физический доступ к данным.

Когда облако не обсуждается

  • Обработка информации ограниченного доступа, где внешние сервисы запрещены.
  • Объекты критической информационной инфраструктуры с требованиями по категорированию.
  • Данные, которые по договору с вашими клиентами не могут покидать периметр.
  • Производство, где сеть до внешнего мира физически отсутствует.

В этих случаях спор заканчивается до начала: система разворачивается на месте, и вопрос только в том, хватит ли мощности.

Что считать при выборе

  • Стоимость. Облако дешевле на старте и дороже на длинной дистанции при постоянной нагрузке. Свой сервер — наоборот: капитальные затраты сразу, потом только обслуживание.
  • Пиковая нагрузка. Если нагрузка неровная, облако выигрывает: платите за пики, а не за постоянную мощность.
  • Люди. Свой сервер требует администратора. Если его нет и не будет, облако честнее.
  • Доступность. Облачный провайдер обещает время безотказной работы договором. Свой сервер настолько надёжен, насколько надёжны ваша сеть и питание.
  • Скорость запуска. В облаке стенд поднимается за час, своё железо ждут неделями.

Отдельный случай: языковые модели

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

Практическая проверка: попросите подрядчика показать, что система работает при физически отключённом интернете. Если работает — данные наружу не уходят.

Гибридный вариант

Часто разумно разделить: то, что содержит персональные данные и коммерческую тайну, держать на месте, а вычислительно тяжёлое и не чувствительное — в облаке. Граница проводится по данным, а не по компонентам, и её надо описать до начала разработки, иначе она размоется сама.

Что важно заложить заранее

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

Частые вопросы

Что дешевле?

На горизонте до года обычно облако, дальше при постоянной нагрузке — своё оборудование. Точка окупаемости считается по вашей нагрузке.

Можно ли перейти из облака на свой сервер позже?

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

Насколько мощное железо нужно для языковой модели?

Зависит от размера модели и числа пользователей. Мы считаем это на обследовании и называем конфигурацию до закупки.

Смотрите также: частные LLM в закрытом контуре и своя LLM или ChatGPT API Ещё по теме: сколько видеопамяти нужно для своей модели.