On-prem AI: настройка с нуля за 6 недель

Практическое руководство для CTO и инфраструктурных команд: как спроектировать и развернуть AI-контур на собственном оборудовании. Внутри --- требования к железу, архитектурные паттерны, сетевая топология, безопасность, соответствие 152-ФЗ и пошаговый план запуска за 6--8 недель.

Локальный AI: зачем on-prem для бизнеса

Облачные LLM-сервисы удобны для прототипов, но для промышленной эксплуатации в российском B2B есть три причины выбрать собственную инфраструктуру.

1. Регуляторные требования. 152-ФЗ и 242-ФЗ обязывают хранить и обрабатывать персональные данные граждан РФ на территории России. Если AI-агент работает с заявками клиентов, карточками CRM, договорами --- данные не должны покидать контролируемый периметр. On-prem исключает риски трансграничной передачи.

2. Контроль над данными и моделями. Собственный контур позволяет: хранить корпоративные документы, регламенты и прайсы в закрытой сети; использовать дообученные модели без ограничений API-провайдеров; контролировать версии моделей и индексов; вести полный аудит-лог обращений.

3. Предсказуемая экономика. При объёме более 50 000 запросов в месяц стоимость on-prem инференса в пересчёте на запрос оказывается ниже, чем подписки на облачные API. Капитальные затраты окупаются за 4--8 месяцев при стабильной нагрузке.

Архитектура on-prem AI-контура

Базовая архитектура состоит из четырёх уровней: инференс, хранение и поиск, оркестрация, защитный периметр.

Уровень 1: Инференс (GPU-серверы)

GPU-серверы --- ядро инфраструктуры. На них работают языковая модель (LLM), модель эмбеддингов и модель ре-ранкинга.

Минимальная конфигурация для пилота (до 50 пользователей):

Промышленная конфигурация (100+ пользователей, несколько агентов):

Выбор модели. Для большинства B2B-сценариев (ответы на вопросы, классификация, суммаризация) достаточно моделей 7--13B. Модели 70B+ нужны для сложных мультишаговых рассуждений и генерации длинных документов. Рекомендуемые фреймворки инференса: vLLM, TGI (Text Generation Inference), llama.cpp для лёгких нагрузок.

Уровень 2: Хранение и поиск

Векторная БД (Qdrant / Milvus). Хранит эмбеддинги документов, регламентов, прайсов. Обеспечивает гибридный поиск: dense (семантический) + BM25 (лексический) + rerank. Для пилота достаточно одной ноды Qdrant; при масштабе --- кластер из 3 нод с репликацией.

PostgreSQL. Метаданные документов, конфигурации агентов, сессии пользователей, аудит-лог. Рекомендуется вынести в отдельную виртуальную машину с ежедневным бэкапом.

MinIO (S3-совместимое хранилище). Исходные файлы (PDF, DOCX, XLSX), версии индексов, модели. On-prem альтернатива облачному S3, полностью в контролируемом периметре.

Размеры хранения (ориентировочно):

Уровень 3: Оркестрация

AI-Agent Service. Микросервис, который принимает запросы, выполняет RAG-пайплайн (поиск -> ре-ранк -> генерация), управляет контекстом диалога. Технологии: Python (LangChain / LlamaIndex) или Go для высоконагруженного проксирования.

n8n / оркестратор. Управляет потоками: вебхуки от CRM, таймеры SLA, уведомления, эскалации. В on-prem разворачивается как Docker-контейнер с PostgreSQL-бэкендом.

Типовой RAG-пайплайн:

1. Приём запроса через API Gateway.
2. Извлечение контекста из сессии (PostgreSQL).
3. Генерация эмбеддинга запроса (GPU Node 2).
4. Гибридный поиск по Qdrant (dense + BM25).
5. Ре-ранкинг top-K документов (GPU Node 2).
6. Генерация ответа с цитатами (GPU Node 1, LLM).
7. Логирование запроса, ответа, источников (PostgreSQL + MinIO).
8. Отправка ответа клиенту / CRM.

Уровень 4: Защитный периметр

API Gateway. Единая точка входа: аутентификация (JWT / API-ключи), rate limiting, маршрутизация запросов. Рекомендуемые решения: Kong, APISIX, Traefik --- все работают on-prem.

WAF / Reverse Proxy. Защита от инъекций, DDoS, сканирования. Nginx с модулем ModSecurity или HAProxy с ACL-правилами.

Сетевая топология. Рекомендуется разделение на три VLAN:

• DMZ --- API Gateway, WAF, доступен из корпоративной сети.
• App --- агенты, оркестратор, n8n. Доступ только из DMZ.
• Data --- GPU-ноды, Qdrant, PostgreSQL, MinIO. Доступ только из App.

Между VLAN --- межсетевой экран с правилами по портам и протоколам. Логирование всего трафика между зонами.

Приватный контур ИИ: безопасность и соответствие 152-ФЗ

Чек-лист безопасности on-prem AI

Доступ и аутентификация:

• RBAC/ACL: роли (admin, operator, viewer), минимальные привилегии.
• MFA для административного доступа к серверам и панелям управления.
• API-ключи с ротацией каждые 90 дней; JWT с коротким TTL (15--60 мин).
• SSH-доступ только по ключам, отключить парольную аутентификацию.

Шифрование:

• TLS 1.3 на всех внутренних и внешних соединениях.
• Шифрование дисков (LUKS / BitLocker) на серверах с данными.
• Шифрование бэкапов перед отправкой на удалённое хранение.

Аудит и мониторинг:

• Журнал доступа: кто, когда, к каким данным обращался.
• Логирование всех запросов к LLM: промпт, ответ, источники, timestamp.
• Alerting на аномалии: всплеск запросов, доступ в нерабочее время, обращения к защищённым полям.
• Хранение логов минимум 6 месяцев (требование регулятора).

Обезличивание и PII:

• Маскирование ПДн в промптах перед передачей в LLM (ФИО, телефон, ИНН, паспорт).
• Словарь «красных полей» с регулярными выражениями для автоматического обнаружения.
• Карта соответствия (токен <-> реальное значение) --- в отдельном защищённом хранилище.
• Невозможность re-identification на выходных данных.

Соответствие 152-ФЗ: ключевые требования

Локализация (242-ФЗ). Все ПДн граждан РФ --- хранение, систематизация, накопление, извлечение --- на серверах в РФ. On-prem по определению соответствует этому требованию.

Уведомление Роскомнадзора. Перед началом обработки ПДн уведомите регулятора (реестр операторов). При изменении состава данных или целей --- обновите уведомление.

Обезличивание (Приказ РКН 140). С 01.09.2025 действуют утверждённые методы обезличивания. Для AI-проектов: используйте псевдонимизацию/токенизацию при инжесте документов, ведите журнал обезличивания, оценивайте linkage-risk при слиянии наборов.

DPIA (оценка воздействия). Для AI-пилота проведите экспресс-оценку рисков: какие ПДн обрабатываются, какие угрозы, какие меры защиты. Документ --- основа для проверки.

Пошаговый план развёртывания (6--8 недель)

Неделя 1: Аудит и планирование

• Определить сценарии AI (какие агенты, какие данные, какие интеграции).
• Провести аудит текущей инфраструктуры: серверы, сеть, СХД.
• Оценить объём данных для RAG-индекса (количество документов, форматы).
• Согласовать бюджет на оборудование и лицензии.
• Назначить ответственного за ПДн (DPO), утвердить политику обработки.
• Подать уведомление в Роскомнадзор (если не подано).

Неделя 2: Закупка и подготовка оборудования

• Закупить / выделить GPU-сервер(ы) по спецификации.
• Подготовить серверную: питание (2N), охлаждение (GPU выделяют 300--700W на карту), UPS.
• Настроить VLAN: DMZ, App, Data. Правила межсетевого экрана.
• Установить ОС (Ubuntu 22.04 LTS / RHEL 9), драйверы NVIDIA, CUDA Toolkit.
• Настроить SSH по ключам, отключить парольный доступ.

Неделя 3: Развёртывание базовых сервисов

• Развернуть Docker / Kubernetes (k3s для малых кластеров).
• Установить PostgreSQL с настройкой бэкапов.
• Развернуть MinIO, создать бакеты для документов и моделей.
• Установить Qdrant, настроить коллекции и репликацию.
• Развернуть API Gateway (Kong / Traefik) с TLS-терминацией.
• Настроить n8n с PostgreSQL-бэкендом.

Неделя 4: Инференс и RAG-пайплайн

• Загрузить веса LLM (Llama 3 / Mistral / Qwen) на GPU-сервер.
• Развернуть vLLM / TGI, проверить инференс (latency, throughput).
• Загрузить модель эмбеддингов (семейства e5 или bge) и ре-ранкер.
• Реализовать RAG-пайплайн: инжест документов -> чанкинг -> эмбеддинг -> индексация -> поиск -> ре-ранк -> генерация.
• Первые тесты на реальных документах: точность ответов, цитаты, латентность.

Неделя 5: Интеграции и безопасность

• Подключить CRM (SberCRM / Bitrix24 / 1C) через вебхуки / REST API.
• Настроить RBAC: роли, права, API-ключи.
• Внедрить маскирование PII в пайплайне (словарь «красных полей»).
• Настроить аудит-лог: запись всех запросов, ответов, доступов.
• Провести экспресс-DPIA, оформить результаты.

Неделя 6: Закрытое тестирование

• Подключить 5--10 пользователей (внутренние).
• Собрать обратную связь: качество ответов, скорость, удобство.
• Тюнинг промптов, настройка параметров поиска (top-K, порог релевантности).
• Нагрузочное тестирование: параллельные запросы, пиковая нагрузка.
• Проверить failover: что происходит при падении GPU-ноды, Qdrant, PostgreSQL.

Недели 7--8: Пилот и масштабирование

• Расширить доступ до 30--50 пользователей.
• A/B-тестирование: группа с AI-агентом vs. без.
• Замерить KPI: время ответа, точность, удовлетворённость.
• Финализировать документацию: runbook, процедура обновления моделей.
• Подготовить план масштабирования: дополнительные GPU, расширение индекса, новые сценарии.

Типичные ошибки при on-prem развёртывании

1. Недооценка охлаждения. GPU A100 потребляет до 400W. Четыре карты в одном сервере --- это 1600W только GPU. Без адекватного охлаждения серверной карты throttle-ят и производительность падает на 30--50%.

2. Отсутствие мониторинга GPU. Без метрик утилизации GPU (nvidia-smi, DCGM) невозможно понять, нужны ли дополнительные карты или текущие загружены на 20%.

3. Монолитный пайплайн. Если LLM, эмбеддинги и ре-ранкинг работают в одном процессе, падение одного компонента роняет всю систему. Разделяйте на микросервисы с health-check и автоперезапуском.

4. Игнорирование версионирования. Без контроля версий моделей и индексов невозможно откатить изменения при деградации качества. Используйте теги (v1.0, v1.1) и хранение в MinIO.

5. Безопасность «потом». Маскирование PII, аудит-лог и RBAC внедряют на этапе проектирования, а не после запуска. Ретрофит безопасности в готовую систему стоит в 3--5 раз дороже.

Стоимость on-prem AI (ориентировочно)

При объёме 100 000+ запросов/мес. стоимость запроса на on-prem составляет 0.5--2 руб., тогда как облачные API --- 3--10 руб./запрос. Окупаемость пилотной конфигурации --- 4--6 месяцев.

Когда on-prem не нужен

On-prem --- не универсальное решение. Облачный AI подходит, если:

• объём запросов менее 10 000 в месяц (дешевле платить за API);
• данные не содержат ПДн и коммерческой тайны;
• нужен быстрый прототип без капитальных вложений;
• нет инфраструктурной команды для поддержки серверов.

В этих случаях рассмотрите гибридную архитектуру: критичные данные on-prem, некритичные задачи --- через облачный API с обезличиванием.

Итоги

On-prem AI --- это полный контроль над данными, соответствие 152-ФЗ, предсказуемые расходы и независимость от внешних провайдеров. Развёртывание занимает 6--8 недель при правильном планировании. Ключевые решения: выбор GPU под целевую модель, проектирование сетевых зон, внедрение безопасности с первого дня.

Хотите развернуть AI на собственной инфраструктуре? Мы проведём аудит ваших процессов, подберём архитектуру и запустим пилот за 6--8 недель. Оставьте заявку или свяжитесь с нами.

Связанные материалы

Регуляторика:

• 152-ФЗ и внедрение AI: хранение данных, on-prem, обезличивание --- полный разбор правовых требований
• 152-ФЗ и чат-боты: как не нарушить закон --- практический гайд для чат-ботов

Технические детали:

• Как работает RAG на реальных документах SMB в РФ --- архитектура RAG-пайплайна
• Pipeline чат-ботов: Qdrant + Neo4j --- компоненты поиска и графа знаний

Кейсы:

• Кейс --- Дистрибуция: -41% времени ответа --- пример внедрения AI-агента
• Кейс --- Сервис: -28% TTR --- оптимизация поддержки с RAG