Когда компания принимает решение использовать ИИ - для консультанта на сайте, автоматизации поддержки, анализа документов или другой задачи - первый технический вопрос звучит так: «Где будет работать модель?». Ответ на него влияет на всё остальное: бюджет, скорость запуска, безопасность и возможности масштабирования.

Неправильный выбор дорого обходится. Компания, которая начала с облачной модели и обрабатывает конфиденциальные данные через внешний API, может столкнуться с регуляторными проблемами. Компания, которая вложила миллионы в GPU-серверы для задачи, которую можно решить облачным API за 20 000 рублей в месяц, потратила ресурсы впустую. А компания, которая не рассмотрела гибридный подход, упустила возможность получить лучшее из двух миров.

Разберём каждый вариант подробно, с реальными цифрами и примерами.

Облачное развертывание означает, что языковая модель работает на серверах провайдера, а ваше приложение обращается к ней через API. Вы отправляете текстовый запрос, получаете ответ и платите за каждый обработанный токен (слово или его часть).

Основные облачные провайдеры для российских компаний:

• YandexGPT - линейка моделей от Яндекса. Данные обрабатываются на серверах в России, что упрощает выполнение требований по локализации. Доступны версии YandexGPT Lite (быстрый, для простых задач) и YandexGPT Pro (для сложных задач). Оплата в рублях через Яндекс Облако
• DeepSeek API - облачный доступ к мощным моделям DeepSeek V3 и DeepSeek R1. Одни из самых доступных по цене среди моделей топового качества. Отличные результаты на задачах рассуждения и генерации кода
• Другие провайдеры - доступ к моделям через совместимые API-интерфейсы, различные региональные и международные сервисы

Преимущества облачного развертывания:

• Мгновенный старт. Регистрация, получение API-ключа, первый запрос - за часы, а не недели. Не нужно закупать оборудование, настраивать серверы, устанавливать программное обеспечение. Для проверки гипотезы или MVP это бесценно
• Доступ к самым мощным моделям. Облачные провайдеры предлагают модели, которые невозможно или нецелесообразно запускать на собственном оборудовании. Модели с сотнями миллиардов параметров требуют кластеры из десятков GPU
• Оплата по потреблению. Нет фиксированных затрат на инфраструктуру. Если в один месяц у вас 1000 запросов, а в другой - 100 000, вы платите пропорционально. Для бизнесов с сезонностью или непредсказуемой нагрузкой это принципиально
• Автоматические обновления. Провайдер обновляет модели, устраняет ошибки и повышает качество без вашего участия. Вы автоматически получаете доступ к новым версиям
• Нулевые операционные расходы. Не нужна команда инженеров для обслуживания GPU-серверов, мониторинга, обновления драйверов и библиотек

Недостатки облачного развертывания:

• Данные покидают ваш контур. Каждый запрос к API содержит данные - вопросы пользователей, фрагменты документов, персональные данные. Эти данные передаются на серверы провайдера. Для компаний, работающих с конфиденциальной информацией (персональные данные, коммерческая тайна, медицинские данные), это серьёзный риск
• Растущие затраты при масштабировании. Оплата по потреблению выгодна при низких объёмах. Но если ваше приложение обрабатывает 100 000 запросов в день, ежемесячный счёт может достигать сотен тысяч рублей. На определённом объёме собственная инфраструктура становится дешевле
• Зависимость от провайдера (vendor lock-in). Каждый провайдер имеет свой формат API, свои особенности работы моделей, свои ограничения. Миграция между провайдерами требует переписывания интеграции и тестирования качества на новой модели
• Ограничения по скорости. API-вызовы добавляют сетевую задержку (latency). Для интерактивных сценариев (чат в реальном времени) это может быть критично. Кроме того, провайдеры устанавливают лимиты на количество запросов в минуту (rate limits)
• Доступность. Облачные сервисы могут быть недоступны из-за технических проблем на стороне провайдера, санкционных ограничений или блокировок. Ваш сервис перестаёт работать, и вы не можете это контролировать

Стоимость облачного развертывания: пример расчёта. Допустим, AI-консультант на сайте обрабатывает 500 обращений в день. Средняя длина диалога - 3 обмена сообщениями. Каждое сообщение требует около 2000 токенов (входные + выходные). Итого: 500 x 3 x 2000 = 3 000 000 токенов в день, или около 90 миллионов токенов в месяц. Стоимость через YandexGPT Pro - порядка 15 000-30 000 рублей в месяц. Через DeepSeek API - ещё дешевле. Это значительно меньше, чем стоимость GPU-сервера.

On-premise (локальное) развертывание означает, что языковая модель работает на ваших собственных серверах или в вашем управляемом облаке. Вы загружаете open-source модель, устанавливаете необходимое программное обеспечение и обслуживаете всю инфраструктуру самостоятельно.

Основные open-source модели для локального развертывания:

• Llama 3.1 (Meta) - одна из самых производительных открытых моделей. Доступна в размерах 8B, 70B и 405B параметров. Модель 8B работает на одной потребительской видеокарте, 70B - на сервере с 2-4 GPU
• Mistral / Mixtral - французская компания, известная эффективными моделями. Mixtral использует архитектуру Mixture of Experts (MoE), которая обеспечивает производительность большой модели при меньших вычислительных затратах
• Qwen 2.5 (Alibaba) - отличное качество генерации на многих языках, включая русский. Серия моделей от 0.5B до 72B параметров
• DeepSeek V3 / R1 - модели с открытыми весами. DeepSeek R1 демонстрирует выдающиеся результаты в задачах, требующих рассуждений. Можно развернуть на собственных серверах

Преимущества on-premise развертывания:

• Полный контроль над данными. Данные никогда не покидают ваш периметр. Запросы пользователей, документы, персональные данные обрабатываются на ваших серверах и никуда не передаются. Это единственный вариант, соответствующий требованиям некоторых регуляторов
• Предсказуемые фиксированные затраты. После покупки (или аренды) оборудования нет зависимости от объёма запросов. Обработайте 1000 или 1 000 000 запросов в день - стоимость инфраструктуры не изменится. При больших объёмах это значительно дешевле облака
• Никакого vendor lock-in. Open-source модели не принадлежат одному провайдеру. Вы можете сменить Llama на Qwen или Mistral, не меняя инфраструктуру. Модели работают на стандартном оборудовании (NVIDIA GPU), инструменты развертывания универсальны
• Возможность дообучения (fine-tuning). Локальная модель может быть дообучена на ваших специфических данных для повышения качества ответов в конкретной предметной области. Облачные API обычно не предоставляют такой гибкости
• Минимальная задержка. Когда модель работает в вашей сети, нет сетевой задержки на обращение к внешнему API. Для приложений, где каждая миллисекунда на счету, это критично
• Полная автономность. Сервис продолжает работать при отключении интернета, санкционных ограничениях или проблемах у облачного провайдера

Недостатки on-premise развертывания:

• Значительные начальные инвестиции. GPU-сервер с 2-4 видеокартами NVIDIA A100 или H100 стоит от 2 до 10 миллионов рублей. Аренда GPU-сервера в дата-центре - от 100 000 до 500 000 рублей в месяц. Это оправданно только при большом объёме запросов
• Требуется команда экспертов. Развертывание, настройка и обслуживание GPU-инфраструктуры требует специалистов в области MLOps, DevOps и системного администрирования. Установка драйверов, CUDA, оптимизация инференса - это не тривиальные задачи
• Ручное обновление моделей. Когда выходит новая версия модели, вам нужно самостоятельно её скачать, протестировать и развернуть. Нет автоматических обновлений
• Качество ниже топовых облачных моделей. Открытые модели развиваются быстро, но самые мощные коммерческие модели по-прежнему превосходят открытые по ряду задач (особенно в сложных рассуждениях и мультимодальных сценариях). Разрыв сокращается, но пока существует
• Масштабирование требует закупки оборудования. Если нагрузка выросла в 3 раза, вам нужно докупить серверы, настроить балансировку и убедиться в достаточности мощностей. Это занимает недели или месяцы

Стоимость on-premise: пример расчёта. Для запуска модели Llama 3.1 70B (одна из самых востребованных для бизнес-задач) потребуется сервер с 2x NVIDIA A100 80GB. Аренда в Яндекс Облаке (GPU-инстанс) - около 300 000 рублей в месяц. Покупка собственного сервера - от 4 миллионов рублей единовременно плюс 50 000-100 000 рублей в месяц на колокацию и обслуживание. При объёме 50 000 запросов в день on-premise вариант окупится за 8-12 месяцев по сравнению с облачным API.

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

Типичные гибридные сценарии:

• Облачная LLM + локальные эмбеддинги. Языковая модель (генерация ответов) работает через облачный API, а модель эмбеддингов (создание векторов для поиска) развернута на вашем сервере. Эмбеддинги обрабатывают большой объём данных, но не отправляют ответы пользователям, поэтому риски ниже, а экономия на токенах значительна
• Локальная LLM для конфиденциальных данных + облачная для обычных. Запросы, содержащие персональные данные или коммерческую тайну, обрабатываются локальной моделью. Все остальные запросы направляются в облако для лучшего качества ответов
• Облачная LLM для генерации + локальный RAG. Вся база знаний, эмбеддинги и векторный поиск работают на ваших серверах. В облако отправляется только сформированный промпт с найденными фрагментами - без передачи полного массива данных
• Локальная LLM как fallback. Основная работа идёт через облачный API. Если облачный сервис недоступен, система автоматически переключается на локальную модель. Качество ответов может быть ниже, но сервис продолжает работать

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

Чтобы выбрать модель развертывания для вашего проекта, оцените его по пяти ключевым критериям.

1. Чувствительность данных. Какие данные будет обрабатывать ИИ? Если это публичная информация (FAQ, описания товаров, контент сайта) - облако полностью подходит. Если это персональные данные клиентов, медицинские карты, финансовые документы или государственная тайна - необходим on-premise или гибрид с локальной обработкой конфиденциальных данных. Ключевой вопрос: готовы ли вы к тому, что фрагменты обрабатываемых данных передаются на серверы стороннего провайдера?

2. Объём запросов. Сколько запросов в день будет обрабатывать система? До 1000 запросов в день - облако практически всегда дешевле и проще. От 1000 до 10 000 - зависит от стоимости конкретных моделей, стоит посчитать. Свыше 10 000 - on-premise или гибрид начинают окупаться. Свыше 50 000 - on-premise почти наверняка выгоднее.

3. Бюджет и сроки. Облако: минимальные начальные затраты, быстрый старт (дни), растущие операционные расходы. On-premise: значительные начальные инвестиции (1-10 миллионов рублей), долгий запуск (недели-месяцы), фиксированные операционные расходы. Если нужно запустить MVP за неделю - только облако. Если планируете работать с ИИ годами при стабильно высокой нагрузке - on-premise экономичнее.

4. Команда и компетенции. Есть ли в штате инженеры с опытом работы с GPU, Docker, Kubernetes, CUDA, моделями машинного обучения? On-premise требует команду из 1-3 специалистов для развертывания и обслуживания. Если таких специалистов нет - облако или гибрид с минимальным локальным компонентом. Привлечение внешней команды (как Промолитика) для настройки on-premise - тоже рабочий вариант.

5. Требования к качеству модели. Для простых задач (классификация, извлечение сущностей, суммаризация) открытые модели (Llama, Qwen, Mistral) показывают отличные результаты. Для сложных задач (многошаговые рассуждения, генерация длинных связных текстов, работа с таблицами и графиками) облачные модели по-прежнему лидируют. Оцените сложность вашей конкретной задачи, а не абстрактные бенчмарки.

Для ряда отраслей on-premise развертывание - не предпочтение, а необходимость, продиктованная регуляторными требованиями или характером данных.

Банки и финансовые организации. Требования ЦБ РФ по защите информации, 152-ФЗ «О персональных данных», PCI DSS для платёжных данных. Передача клиентских данных (номера счетов, суммы транзакций, кредитные скоринги) на внешние серверы создаёт неприемлемые риски. Банки развертывают модели в собственных дата-центрах или в сертифицированных облаках с повышенным уровнем безопасности.

Здравоохранение. Медицинские данные (диагнозы, истории болезней, результаты анализов) относятся к специальной категории персональных данных. 323-ФЗ «Об основах охраны здоровья граждан» и требования Минздрава накладывают строгие ограничения на обработку и хранение медицинской информации. AI-системы для анализа медицинских записей, помощи врачам в диагностике или работе с электронными медицинскими картами должны работать в защищённом контуре.

Государственные учреждения. Обработка документов с грифом «Для служебного пользования» и выше невозможна через внешние облачные сервисы. Государственные информационные системы подчиняются требованиям ФСТЭК и ФСБ по защите информации. On-premise развертывание на сертифицированном оборудовании - единственный путь.

Оборонная промышленность. Очевидные требования к секретности. Даже факт обращения к внешнему API может быть недопустим.

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

Промышленные предприятия. Компании с конкурентно значимыми ноу-хау (формулы, технологические процессы, чертежи) предпочитают обрабатывать свои данные локально, даже если формально не обязаны.

Одно из ключевых преимуществ архитектуры RAG (Retrieval-Augmented Generation) - она делает систему модель-агностичной. Это означает, что замена языковой модели не требует переделки всей системы.

Как это работает. В RAG-архитектуре система состоит из трёх независимых компонентов:

• Хранилище знаний (векторная база с эмбеддингами документов) - не зависит от языковой модели
• Поисковый компонент (создание эмбеддинга запроса + поиск ближайших документов) - зависит только от модели эмбеддингов
• Генеративный компонент (языковая модель, формирующая ответ на основе найденных документов) - единственная часть, привязанная к конкретной LLM

При миграции с облачной модели на локальную достаточно заменить генеративный компонент. Хранилище знаний и поисковый компонент остаются без изменений. На практике это означает замену одного API-вызова на другой - обычно десятки строк кода.

Пример миграции: компания начинает с облачного YandexGPT Pro для генерации ответов. База знаний (эмбеддинги через Voyage AI, хранение в pgvector) работает на собственном сервере. Через год нагрузка выросла, и компания развертывает Llama 3.1 70B на GPU-сервере. Замена: один HTTP-клиент (YandexGPT API) заменяется на другой (локальный vLLM API). Всё остальное - промпты, логика поиска, векторная база - остаётся прежним.

Именно поэтому мы в Промолитике рекомендуем RAG-архитектуру: она не привязывает вас к конкретной модели или провайдеру и позволяет мигрировать между облаком и on-premise по мере развития бизнеса.

Рассмотрим два сценария для компании со средним объёмом запросов - 5000 обращений к AI в день (около 150 000 в месяц).

Сценарий A: полностью облачный.

• Модель: YandexGPT Pro или DeepSeek API
• Стоимость токенов: около 40 000-80 000 рублей в месяц (при средней длине запроса)
• Инфраструктура: сервер для приложения и базы данных - 15 000-30 000 рублей в месяц
• Итого: 55 000-110 000 рублей в месяц, или 2-4 миллиона за 3 года
• Начальные затраты: минимальные (настройка и интеграция - 200 000-500 000 рублей)

Сценарий B: on-premise LLM + облачные эмбеддинги.

• Модель: Llama 3.1 70B на арендованном GPU-сервере
• GPU-сервер: 250 000-400 000 рублей в месяц
• Облачные эмбеддинги (Voyage AI): 10 000-20 000 рублей в месяц
• Инфраструктура приложения: 15 000-30 000 рублей в месяц
• Итого: 275 000-450 000 рублей в месяц, или 10-16 миллионов за 3 года
• Начальные затраты: настройка и развертывание - 500 000-1 500 000 рублей

В этом сценарии облако дешевле. Но если объём вырастет до 50 000 запросов в день, облачные токены будут стоить 400 000-800 000 рублей в месяц, а стоимость GPU-сервера не изменится. Точка безубыточности зависит от конкретных моделей и объёмов, поэтому считать нужно для каждого проекта индивидуально.

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

Этап 1: валидация на облаке (1-3 месяца). Разверните MVP с облачной моделью (YandexGPT, DeepSeek). Проверьте бизнес-гипотезу: реально ли ИИ приносит ценность? Помогает ли AI-консультант конвертировать лиды? Ускоряет ли поддержку? На этом этапе важен результат, а не экономия на инфраструктуре. Расходы на облако при тестировании - тысячи рублей в месяц.

Этап 2: продакшен на облаке (3-12 месяцев). Если гипотеза подтвердилась - масштабируйте решение. Подключите полноценную базу знаний (RAG), настройте интеграции с CRM, начните собирать метрики. На этом этапе облако по-прежнему оптимально: объёмы растут, но ещё не достигли точки, где on-premise выгоднее.

Этап 3: гибрид или on-premise (12+ месяцев). Когда объёмы стабилизировались на высоком уровне и стоимость облака стала значимой статьёй расходов - пора рассмотреть миграцию. Благодаря RAG-архитектуре это безболезненный процесс: меняется только генеративный компонент. Многие компании останавливаются на гибриде: локальная модель для основной нагрузки, облачная - для пиков.

Этот подход минимизирует риски: вы не инвестируете в дорогую инфраструктуру до подтверждения бизнес-ценности, но сохраняете гибкость для миграции, когда это станет экономически оправданным.

Нет универсально правильного выбора между облаком и on-premise. Есть правильный выбор для вашей конкретной ситуации. Облако идеально для старта, проверки гипотез и небольших объёмов. On-premise необходим для конфиденциальных данных, регулируемых отраслей и высоких нагрузок. Гибрид даёт максимальную гибкость.

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

В Промолитике мы помогаем выбрать модель развертывания, спроектировать архитектуру с учётом будущей миграции и развернуть решение - от облачного MVP до полностью локальной инсталляции. Свяжитесь с нами для бесплатной консультации.