LLM on-premises или облачный AI: реальная модель принятия решений для предприятий

Выбор между развёртыванием LLM on-premises и облачным AI — это не технологический спор. Это решение в области управления рисками. За последние два года разрыв в качестве между передовыми облачными API и моделями с открытыми весами, работающими on-premises, резко сократился. А вот разрыв в управляемости никуда не делся: отправляя данные в облачный API, вы не полностью контролируете, что с ними происходит, кто может получить к ним доступ и не изменятся ли условия обслуживания.

Для большинства организаций этот разрыв допустим. Для некоторых (особенно в регулируемых отраслях, секторах, связанных с государством, и на рынках со строгими требованиями к локализации данных) — нет. В этой статье предлагается практическая модель принятия решения.

Что облачный AI на самом деле означает для ваших данных

Когда вы обращаетесь к облачному LLM API, ваш запрос передаётся из вашей системы в инфраструктуру поставщика, обрабатывается на его оборудовании, после чего возвращается ответ. Поставщики существенно различаются в обращении с этими данными: одни по умолчанию используют запросы для обучения будущих моделей (от этого нужно отказываться вручную), другие предлагают корпоративные тарифы с явными гарантиями отказа от обучения, третьи предоставляют выделенную инфраструктуру, где ваши данные никогда не попадают в общие системы.

Прежде чем внедрять AI в любой процесс, работающий с конфиденциальной информацией, обязательно разберитесь в условиях используемого тарифа API. «Корпоративное соглашение» — не синоним выражения «ваши данные изолированы».

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

Разрыв в производительности сокращается быстрее, чем кажется

Два года назад локальное развёртывание означало заметный компромисс по возможностям: open-weight модели, работавшие на разумном оборудовании, существенно отставали от передовых облачных моделей.

Это изменилось. Семейства open-weight моделей, такие как Qwen, DeepSeek, Llama, Mistral и gpt-oss от OpenAI, после квантования и развёртывания через vLLM или SGLang на одном multi-GPU узле хорошо справляются с большинством корпоративных NLP-задач: анализ документов, классификация, суммаризация, извлечение данных и RAG-конвейеры. Передовые облачные модели по-прежнему впереди в самых сложных задачах рассуждения, программирования и длительной агентной работы, но для большинства сценариев корпоративной автоматизации разрыв больше не решающий.

Изменилась и стоимость оборудования. Хорошо настроенный локальный сервер инференса окупается по сравнению с облачными API, когда нагрузка стабильная и большая, обычно от сотен миллионов токенов в месяц, в зависимости от модели и оборудования. Дальше предельная стоимость каждого дополнительного запроса близка к нулю. Для массовой обработки документов (частый корпоративный сценарий) экономика теперь явно на стороне локального развёртывания.

Четыре реальных фактора решения

Чувствительность данных

Если какие-либо данные в процессе подпадают под HIPAA, GDPR, требования к резидентности данных, адвокатскую тайну, режим государственной тайны или аналогичные ограничения, решение по умолчанию — on-premises. Вопрос не в том, удастся ли подписать с поставщиком соглашение об обработке данных: обычно удаётся. Вопрос в том, можете ли вы гарантировать, что данные никогда не попадут в инфраструктуру вне вашего контроля. Такую гарантию даёт только развёртывание on-premises.

Объём и стоимость

При небольших объёмах (исследовательские сценарии, небольшие команды, нерегулярное использование) облачные API — рациональный выбор. Операционные затраты на поддержку собственной инфраструктуры инференса при таком масштабе не оправдываются экономией. Когда объём превышает точку безубыточности (обычно 50 000–100 000 токенов в день), экономика меняется. В корпоративном масштабе (миллионы токенов в день) on-premises — единственная экономически обоснованная архитектура.

Регуляторная среда

Организации в здравоохранении, финансовых услугах, оборонных контрактах, госсекторе и юридических услугах, как правило, работают в рамках регулирования, требующего доказуемого контроля над данными. Облачный AI можно привести в соответствие с помощью достаточной договорной базы, но on-premises соответствует требованиям структурно: вам не нужно полагаться на то, что поставщик выполнит свои обязательства.

Конкретные примеры: PDPL ОАЭ требует резидентности персональных данных жителей ОАЭ. Индийский DPDP Act вводит аналогичные требования. EU AI Act установит дополнительные требования к управлению AI-системами высокого риска. Эти требования никуда не исчезнут.

Глубина настройки

Облачные API предлагают ограниченные возможности настройки: системные промпты, генерацию с дополнением извлечёнными данными (RAG) и дообучение на некоторых платформах. Развёртывание on-premises даёт полный контроль над весами модели, позволяя дообучать модель на любом уровне, внедрять предметную лексику и вносить архитектурные изменения, невозможные через границу API.

Если ваш сценарий требует глубокой адаптации к предметной области (медицинская терминология, проприетарная логика процессов, внутренняя структура документов), on-premises — лучший выбор и с точки зрения чистых возможностей, а не только управляемости.

Гибридный подход

Большинство зрелых корпоративных AI-архитектур в итоге становятся гибридными: on-premises для чувствительных, высоконагруженных или глубоко настроенных рабочих нагрузок и облачные API для нечувствительных, исследовательских сценариев или пиковых нагрузок.

Архитектурная задача здесь — маршрутизация. Нужен слой политик, который классифицирует входящие запросы по чувствительности данных и направляет их в подходящую точку инференса — внутреннюю или внешнюю — автоматически, последовательно и с возможностью аудита. Это одна из задач, которые решает CloudFusion™ в мультиоблачных развёртываниях.

Вопрос зависимости от поставщика

Поставщики облачного AI меняли цены, выводили модели из эксплуатации, изменяли условия обслуживания, а в некоторых случаях уходили с отдельных рынков без заблаговременного уведомления. Строя критически важные бизнес-процессы на API поставщика, вы принимаете эту зависимость.

Развёртывание on-premises переворачивает зависимость: веса модели принадлежат вам, инфраструктура под вашим контролем, а решения поставщика не влияют на вашу работу. Обратная сторона — нагрузка по сопровождению ложится на вас: оборудование, обновления моделей, исправления безопасности и настройка производительности становятся вашей ответственностью.

Принятие решения

Для большинства организаций решение определяют три вопроса:

1. Есть ли в этом процессе данные с регуляторным или договорным запретом на выход за пределы вашей инфраструктуры? Если да: on-premises.

2. Каков прогнозируемый суточный объём токенов при полном развёртывании? При стабильно высоком объёме (сотни миллионов токенов в месяц) локальное развёртывание выгоднее. При малом или неравномерном объёме облако проще и экономичнее.

3. Насколько ваше конкурентное преимущество зависит от уникального для вашей организации поведения модели? Потребность в глубокой настройке говорит в пользу on-premises. Стандартные задачи NLP — в пользу облака.

Если хотя бы один из этих вопросов указывает на on-premises, считайте это жёстким архитектурным требованием, а не предпочтением. Переделка системы, изначально построенной под облачные API, в развёртывание, соответствующее регуляторным требованиям, обходится значительно дороже, чем правильная архитектура с самого начала.