Cloud, hybrid или on-prem: как выбрать контур для AI

Три варианта без маркетинга

Cloud AI — модель и часть сервисов работают у внешнего провайдера. Быстрый старт, широкий выбор сильных моделей, эластичное масштабирование. Цена и правила обработки зависят от поставщика и договора.

On-prem AI — inference и ключевые данные работают в инфраструктуре организации. Больше контроля над компонентами и сетевыми потоками, но вся эксплуатация становится вашей ответственностью.

Hybrid AI — данные и функции разделены. Например, закрытые документы и retrieval остаются в private-контуре, а обезличенная задача уходит в cloud-модель; либо основной inference работает локально, а cloud используется для разрешённых сложных случаев.

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

Начните с классификации данных

Составьте список потоков, а не одну метку «конфиденциально»:

• пользовательский ввод;
• системный prompt;
• найденные фрагменты документов;
• история диалога;
• tool calls и ответы интеграций;
• embeddings;
• логи и трассировки;
• наборы для eval;
• резервные копии.

Для каждого потока определите владельца, допустимые юрисдикции и поставщиков, срок хранения, права пользователей и способ удаления. Иногда главный документ нельзя отправлять в cloud, но извлечённые нечувствительные признаки можно. Иногда даже факт существования запроса закрыт.

Сравнивайте качество на своей задаче

Локальная модель, которая формально помещается на доступный GPU, может хуже выполнять длинные инструкции, tool use или русский язык. Cloud-модель может быть качественнее, но недопустима для части данных.

Нужен один eval-набор и минимум две допустимые архитектуры. Измеряйте task success, grounding, права, latency и стоимость. Не выбирайте модель по размеру, лидерборду или красивому общему benchmark.

On-prem не отменяет zero trust

NIST SP 800-207 прямо отделяет доверие от сетевого расположения. Сервер внутри офиса всё равно требует идентичностей пользователей и сервисов, минимальных прав, сегментации, журналов и проверки каждого запроса.

Если общий endpoint локальной модели доступен всем внутренним приложениям, он может стать удобным каналом извлечения данных. Если embeddings и логи лежат «внутри», но без ACL, периметр не спасает от ошибочного доступа сотрудника или скомпрометированного сервиса.

Кто будет эксплуатировать контур

Для on-prem нужно честно назначить владельцев:

• обновлений драйверов, runtime и моделей;
• CVE и цепочки поставки;
• capacity planning;
• мониторинга GPU, latency, ошибок и очередей;
• резервирования и восстановления;
• eval перед обновлением;
• реагирования на инцидент.

NVIDIA NIM, например, предусматривает liveness/readiness и метрики, но наличие endpoint не создаёт операционный процесс само по себе. Кто-то должен следить, что сервис не просто «жив», а готов принимать запросы и выдаёт допустимое качество.

Матрица выбора

Практический способ принять решение

1. Выберите один процесс, не «AI для всей компании».
2. Нарисуйте полный data flow.
3. Зафиксируйте запреты и обязательные требования.
4. Отбросьте архитектуры, которые им не соответствуют.
5. Остальные проверьте на одном eval-наборе и профиле нагрузки.
6. Посчитайте трёхлетний TCO, включая людей и простой.
7. Проверьте failure mode: что происходит при недоступности модели или сети.
8. Опишите смену поставщика и возврат данных.

Иногда вывод будет «cloud с enterprise-настройками». Иногда — закрытый on-prem. Часто — hybrid с очень небольшой разрешённой границей. Важно, чтобы решение вытекало из требований, а не из ощущения, что сервер в своей стойке автоматически безопасен.