On-premise vs cloud AI: матрица решения для российского бизнеса 2026
Полный фреймворк выбора между облачным и self-hosted AI. По 9 критериям с конкретными порогами. Plus гибридный подход и когда какой комбинации использовать.
On-premise vs cloud AI — решение по четырём осям: чувствительность данных (152-ФЗ закрывает ПДн в облаке), масштаб команды (on-premise окупается от ~25 человек с регулярной нагрузкой), in-house DevOps-ёмкость и compliance с регулятором. Хорошее правило: если хотя бы 20% задач касается ПДн или госконтрактов — нужна on-premise часть.
Что мы сравниваем
Cloud AI: OpenAI, Anthropic, Google Gemini (через VPN/прокси для РФ), GigaChat, YandexGPT, Yandex Cloud ML.
On-premise AI: self-hosted развёртывание (Llama / Qwen / DeepSeek / Gemma) в собственном серверном контуре. В нашем случае — стек AGmind.
Гибрид: часть процессов работает с облачным API, часть — с локальной моделью. Между ними — router который выбирает куда отправлять запрос на основе типа данных и задачи.
Критерий 1: чувствительность данных
| Тип данных | Cloud | On-premise | Гибрид |
|---|---|---|---|
| Маркетинговые материалы, FAQ, открытые продукты | ✓ | ✓ | — |
| Внутренние регламенты без ПДн | ✓ | ✓ | — |
| Договоры с контрагентами (юрлица) | условно | ✓ | ✓ |
| ПДн клиентов, сотрудников | ✗ (152-ФЗ) | ✓ | ✓ (только on-prem ветка) |
| Биометрия, медицина, гос.тайна | ✗ | ✓ | ✗ |
Правило: если хотя бы 20% задач касается чувствительных данных — нужна on-premise часть. Если 80%+ — полностью on-premise. Подробнее про 152-ФЗ — в отдельной статье.
Критерий 2: масштаб и нагрузка
Cloud выгоден когда:
- Команда до 15 человек с эпизодическим использованием AI
- Нагрузка 1-5 тысяч запросов в день
- Нет потребности в кастомизации модели
- Нужен быстрый старт (1-2 дня)
On-premise выгоден когда:
- Команда от 25 человек с регулярной нагрузкой
- 20+ тысяч запросов в день
- Нужны fine-tuning, специфичные prompt-инженерные настройки
- Готовы к проекту 4-6 недель
Точка перехода — около 30 человек или 10k запросов/день. Подробный расчёт в статье про стоимость.
Критерий 3: доступность и SLA
Cloud:
- Стандартный SLA 99.9% от провайдера
- Случались крупные даунтаймы у OpenAI (3-6 часов в год в 2024-2025)
- Зависимость от внешнего канала связи
On-premise:
- SLA определяется вами и вашим внедренцем (типично 99.5-99.9%)
- Никакая внешняя сторона не может уронить
- Зависимость от внутренней инфраструктуры (электричество, охлаждение, сеть)
Если AI критичен для бизнеса (clients-facing, real-time decisions) — on-premise даёт больше контроля. Если AI вспомогательный — cloud достаточно.
Критерий 4: стоимость
При нагрузке для 30-человечной команды (250M входных + 70M выходных токенов в месяц):
| Вариант | Год 1 | Год 2 | Год 3 |
|---|---|---|---|
| Cloud (ChatGPT Enterprise + API + addons) | 3.0-4.2M ₽ | 3.0-4.2M ₽ | 3.0-4.2M ₽ |
| On-premise (CAPEX + минимальный SLA) | 2.0-3.5M ₽ | 0.6M ₽ | 0.6M ₽ |
| Гибрид (60% on-prem, 40% cloud) | 2.5-3.8M ₽ | 1.5-2.0M ₽ | 1.5-2.0M ₽ |
Точка окупаемости on-premise — 9-14 месяцев. После этого cloud — чистый минус, on-premise — почти ноль OPEX.
Критерий 5: качество модели
В 2026 году разрыв между cloud-flagship и open-source моделями небольшой:
| Бенчмарк | Лучший cloud | Лучший open | Разница |
|---|---|---|---|
| MMLU (общие знания) | GPT-4o (88%) | Llama 3.3 70B (84%) | 4% |
| HumanEval (код) | Claude 4 (92%) | DeepSeek R1 (91%) | 1% |
| MATH (математика) | GPT-4 + reasoning (88%) | DeepSeek R1 (87%) | 1% |
| MT-Bench (диалог) | Claude 4 (9.1) | Llama 3.3 70B (8.9) | 0.2 |
Реальная разница на бизнес-задачах — 0-5%. Разница ощущается в:
- Длинные сложные multi-turn разговоры (cloud чуть лучше)
- Узкоспециальные задачи на cutting edge моделей (vision на новейшем GPT-4-vision-preview)
- Code-ассистенты при работе с ультра-специфичными библиотеками
В большинстве business-кейсов open-source on-premise решает задачи равно или лучше (после fine-tuning).
Критерий 6: скорость отклика
| Метрика | Cloud | On-premise (DGX Spark) |
|---|---|---|
| TTFT (time-to-first-token) | 200-500 мс | 150-200 мс |
| TPS (steady state) | 30-80 toks/sec | 23-50 toks/sec |
| Rate limits | Да (могут блокировать пиковую нагрузку) | Нет |
| Доступность при пиковой нагрузке | Может быть очередь | Контроль над пропускной способностью |
Cloud быстрее в TPS, on-premise быстрее в TTFT (за счёт отсутствия сетевой задержки). Для real-time приложений (голос, чат с клиентами) on-premise часто предпочтительнее.
Критерий 7: кастомизация и fine-tuning
Cloud:
- Few-shot promtping в API
- Fine-tuning через провайдера (OpenAI Fine-tuning, Yandex Cloud ML) — медленно, дорого, ограничения по контексту
- Невозможен полный domain fine-tuning
On-premise:
- LoRA fine-tuning на ваших данных за день
- Полный fine-tuning при необходимости
- Любая интеграция с внутренними инструментами
- Кастомные tokenizers, кастомные prompt templates
Для узких отраслевых задач (медицина, юриспруденция, специфичная терминология) on-premise — единственный путь к высокому качеству.
Критерий 8: vendor lock-in
Cloud: высокий lock-in. Промпты оптимизированы под конкретную модель, интеграции через API провайдера, attention к специфичным фичам. Миграция = переписать значительную часть workflow.
On-premise: околонулевой lock-in. Open-source стек, любая модель меняется одной командой, форматы открытые, никто не может «отключить» вашу систему за рубежом.
Критерий 9: команда и compexity
Cloud: не нужна экспертиза по DevOps, инфраструктуре, GPU. Любой разработчик подключается к API за час.
On-premise: требуется DevOps на инфраструктуру (или внешний внедренец), понимание GPU/драйверов, мониторинг. Через внедренца — эта сложность снимается с вашей команды.
Если у вас сильный IT-отдел — on-premise понятнее. Если IT минимальный — cloud проще на старте, но создаёт зависимость.
Когда подходит гибридная архитектура?
Редко имеет смысл «полностью cloud» или «полностью on-premise». Реалистичный setup:
On-premise часть (50-70% задач):
- Документы клиентов, договоры, ПДн
- Внутренние регламенты и базы знаний
- Customer-facing бот на сайте (data residency)
- Юр.отдел, HR, финансы
Cloud часть (30-50% задач):
- Креативные задачи (copywriting, маркетинг)
- Поиск общих знаний, актуальной информации
- Multimodal задачи на cutting edge (новейшие vision-модели)
- Прототипирование новых идей
Router определяет куда отправить запрос:
- Если данные содержат маркеры ПДн → on-premise
- Если запрос требует internet-knowledge → cloud
- Если задача creative → cloud
- Default → on-premise (consrvative)
Реализовано в Dify через workflow с условной логикой.
Чек-лист принятия решения
Пройдитесь по нему — он подскажет правильный ответ для вашей компании.
[ ] Команда от 25 человек? → on-premise или гибрид
[ ] Регулярная нагрузка 10k+ запросов/день? → on-premise или гибрид
[ ] Хотя бы 20% задач — чувствительные данные? → нужна on-premise часть
[ ] Госконтракты, регулируемая отрасль? → on-premise обязательно
[ ] Компания до 15 человек, эпизодическая нагрузка? → cloud
[ ] Стартап с runway < 12 мес? → cloud
[ ] Нужны cutting-edge модели (новые мультимодальные)? → cloud или гибрид
[ ] Готовы к проекту 4-6 недель? → on-premise возможен
[ ] Есть собственная DevOps-команда? → on-premise упрощается3+ галочки в сторону «on-premise» = on-premise или гибрид. 3+ в сторону «cloud» = cloud. Mix = гибрид.
Итог
Чистый «on-premise vs cloud» — упрощение. Большинство зрелых компаний в 2026 приходят к гибридной модели: on-premise для чувствительных данных и регулярных задач, cloud для creative и cutting-edge.
Если хочется проектировать гибрид под вашу конкретную ситуацию — пилот за 2-3 недели включает архитектурный аудит и рекомендации по разделению нагрузки. От 100 000 ₽.
Глубже про экономику — в статье про стоимость. Про compliance — в статье про 152-ФЗ. Про grаbли при внедрении — в топ-7 ошибок.