On-premise LLM для предприятия: как развернуть языковую модель в закрытом контуре

Капсула ответа. On-premise LLM — это открытая языковая модель (класса Qwen/Llama), развёрнутая на GPU-серверах предприятия, чаще всего в связке с RAG-поиском по внутренней документации. Данные и запросы не покидают периметр — это обязательное требование нацкомпаний, недропользователей и банков РК. Для пилота на одном домене документации достаточно сервера с 1–2 GPU; срок — 8–12 недель. Подход подтверждён в Казахстане: ТШО построил LLM-ассистента инженеров по 300+ спецификациям, КТЖ обрабатывает ИИ-помощниками 5 000+ нормативных документов, экосистема SKAI «Самрук-Казына» работает в закрытом контуре на суперкомпьютере Al FARABIUM.

ChatGPT и Copilot не проходят согласование ИБ на промышленном предприятии — и это обоснованно: производственные данные, нормативка с грифами и коммерческая тайна не должны уходить в зарубежные облака. Альтернатива — собственная LLM в контуре. Разбираем, как это устроено технически, что это стоит и какие грабли ждут на пути.

Зачем предприятию своя языковая модель?

Кейсы с подтверждённым спросом

• Поиск по технической документации. Инженер тратит 20–30% времени на поиск по стандартам (СТ РК, ГОСТ, API, ASME), внутренним СТП, паспортам и P&ID. Цена ошибки по устаревшей ревизии — от переделки проекта до инцидента. Именно эту задачу ТШО закрыл собственным ассистентом по 300+ спецификациям.
• Ассистент диспетчера и оператора: ответы по регламентам и инструкциям в момент принятия решения.
• Автоматизация документооборота: черновики актов, протоколов, отчётов, технической документации по ГОСТ 34/19 — по шаблонам предприятия.
• Комплаенс и расследования: сбор досье по инциденту из журналов, нормативки и переписки (банковский AML-вариант той же архитектуры).

Экономика: 0,5–1 час в день на инженера × 200–500 ИТР × полная стоимость часа $15–25 = $1–4 млн в год, плюс снижение риска ошибок по устаревшим документам.

Почему не облако

Критерий	Облачные LLM (OpenAI, Copilot)	On-premise LLM
Данные	Уходят в зарубежные ЦОД	Остаются в периметре
Согласование ИБ нацкомпании	Как правило, блокируется	Стандартная архитектура (бенчмарк — SKAI)
Закон РК «О персональных данных» (локализация БД)	Зона риска	Соответствует
Доступ к внутренним документам	Требует выгрузки наружу	RAG внутри контура
Стоимость при масштабе	Растёт с каждым токеном	Фиксированный CAPEX + сопровождение
Зависимость	Лицензионные и санкционные риски	Открытые модели, контроль у предприятия

Какую модель выбрать в 2026 году?

Открытые модели догнали проприетарные на корпоративных задачах, где главное — работа с предоставленным контекстом, а не «энциклопедичность». Практические ориентиры:

• Класс 7–14B параметров (Qwen, Llama и аналоги) — рабочая лошадка RAG-ассистентов: помещается на 1 GPU, быстрая, для поиска с цитированием её достаточно.
• Класс 30–80B — для сложных рассуждений, длинных документов, генерации документации; требует 2–4 GPU или квантизации.
• Специализированные компоненты: отдельная embedding-модель для поиска, reranker, vision-модель для чертежей и таблиц (P&ID, сканы паспортов).

Ключевой совет: не гнаться за размером. В RAG-системе 80% качества определяют поиск и подготовка документов, а не «интеллект» генератора. Русский язык открытые модели поддерживают уверенно; для казахского нужна дополнительная настройка пайплайна и контрольные наборы.

Как устроена архитектура RAG по техдокументации?

Корпус документов (PDF, DOCX, сканы, чертежи)
        │  парсинг: текст + таблицы + OCR + структура разделов
Индексация: чанкинг с сохранением иерархии (документ → раздел → пункт)
        │  embedding-модель → векторная БД (в контуре)
Запрос пользователя
        │  гибридный поиск (векторный + полнотекстовый) → reranker
LLM-генерация ответа СТРОГО по извлечённым фрагментам
        │  обязательное цитирование: документ, ревизия, пункт
Интерфейс: веб/чат + SSO/AD + права доступа по ролям + журналирование

Критичные детали, которые отличают работающую систему от демо:

1. Цитирование до пункта и ревизии. Инженер не поверит ответу без ссылки. Ответ без подтверждающего фрагмента должен явно помечаться — это главная защита от галлюцинаций.
2. Версионность документов. На предприятии один стандарт живёт в пяти ревизиях; система обязана отвечать по действующей и предупреждать об устаревших.
3. Права доступа. Ассистент отвечает только по документам, доступным конкретному пользователю, — иначе он превращается в канал утечки внутри компании.
4. Таблицы и чертежи. До половины инженерных ответов лежит в таблицах; парсинг таблиц и vision-обработка чертежей — обязательная часть пайплайна, а не «фаза 2».
5. Контрольный набор вопросов. 100–300 вопросов с эталонными ответами, согласованные с экспертами заказчика, — единственный объективный способ измерять качество и не деградировать при обновлениях.

Какое железо нужно и что это стоит?

Сценарий	Конфигурация	Порядок затрат
Пилот: один домен, 300–1 000 документов, 10–50 пользователей	1 сервер, 1–2 GPU (класс L40S/A100)	Десятки тыс. $ CAPEX на железо; пилот целиком — $50–120 тыс.
Промышленная эксплуатация: вся НТД, сотни пользователей	2–4 GPU-сервера с резервированием	$0,5–1,5 млн с интеграциями (СЭД, ТОиР, SSO) и сопровождением

GPU-серверы обычно проходят отдельной строкой сметы и остаются активом предприятия. Эксплуатационные расходы — сопровождение пайплайна, обновление индексов, дообучение и мониторинг качества (типично 15–25% стоимости системы в год).

Как пройти согласование ИБ: чек-лист

• Развёртывание в сегменте, согласованном с ИБ; без исходящего трафика из контура (обновления моделей — через контролируемый процесс).
• Журналирование всех запросов и ответов (это же — материал для улучшения системы).
• Разграничение доступа: SSO/AD, роли, наследование прав от СЭД.
• Для систем, интегрируемых с госсистемами или КВОИКИ, — готовность к испытаниям на соответствие Единым требованиям ИБ (закладывать журналирование, разграничение доступа и криптографию по СТ РК в архитектуру заранее — это сокращает цикл сделки на месяцы).
• NDA и обезличивание на этапе пилота; персональные данные — с учётом требований локализации БД на территории РК.

Поэтапный план внедрения: от демо до промышленной эксплуатации

Этап 0 — демо на открытых документах (2 недели). Прежде чем трогать внутреннюю документацию, систему можно проверить на открытых СТ РК и ГОСТ: задать инженерные вопросы уровня «минимальный радиус гиба трубы Ду150 из стали 09Г2С по такому-то СТП» и оценить качество цитирования. Это бесплатная для заказчика проверка концепции.

Этап 1 — пилот на одном домене (8–12 недель). Выбор домена с измеримой болью (например, стандарты одного технического управления, 300–1 000 документов), парсинг и индексация, настройка пайплайна, составление контрольного набора вопросов с экспертами заказчика, опытная эксплуатация с группой 10–50 пользователей. Выход: измеренное качество ответов, статистика использования, решение о тираже.

Этап 2 — тираж (4–9 месяцев). Вся НТД, интеграции (СЭД, ТОиР, SSO), права доступа по ролям, плагины в рабочие инструменты, регламент актуализации индексов, обучение пользователей, SLA.

Команда проекта со стороны заказчика: владелец продукта (обычно руководитель технического департамента), 2–3 инженера-эксперта для контрольного набора и валидации (2–4 часа в неделю), представитель ИБ, администратор инфраструктуры. Больше не нужно — основную работу делает подрядчик.

Типовые ошибки внедрения

1. «Загрузим всё и сразу». Старт со всей НТД компании топит проект в парсинге. Правильно: один домен с измеримой болью (например, стандарты одного управления), затем тираж.
2. Оценка качества «на глазок». Без контрольного набора вопросов спор «стало лучше или хуже» нерешаем.
3. Игнорирование процесса актуализации. Документы обновляются еженедельно; без инкрементальной переиндексации система устаревает за квартал.
4. Ассистент ради ассистента. Если ответ не встроен в рабочий процесс (плагин в Word, ссылка в СЭД, кнопка в АРМ) — пользователи вернутся к привычному поиску по папкам.

FAQ

Чем on-premise LLM отличается от «своего ChatGPT»?

Принципиально — контуром: модель, индексы и журналы живут на серверах предприятия. Функционально — специализацией: корпоративный ассистент отвечает по документам компании с цитированием, а не «обо всём».

Можно ли дообучить модель на наших данных?

Чаще всего это не нужно: RAG решает задачу доступа к знаниям без дообучения. Fine-tuning оправдан для стиля документов и терминологии — после того, как RAG-базис работает.

Какая точность ответов достижима?

На контрольных наборах по корпоративной документации хорошо настроенный RAG даёт корректный ответ с правильной цитатой в подавляющем большинстве случаев; ключевая метрика — доля ответов с верной ссылкой на действующую ревизию. Точные цифры фиксируются на вашем контрольном наборе в пилоте.

Сколько длится проект?

Пилот — 8–12 недель: парсинг домена, настройка пайплайна, контрольный набор, опытная эксплуатация. Тираж на всю НТД с интеграциями — 4–9 месяцев.

Нужно ли согласие на обработку персональных данных для корпоративного ассистента?

Если в корпус документов попадают персональные данные сотрудников или клиентов — да, обработка должна соответствовать Закону РК «О персональных данных»: локализация БД на территории РК (on-premise это закрывает автоматически), разграничение доступа, журналирование. На этапе проектирования корпус классифицируется, и чувствительные категории документов подключаются с отдельными политиками доступа.

Что будет с системой через год?

При наличии сопровождения — станет точнее (дообучение на журналах запросов, расширение корпуса, обновление моделей по мере выхода новых открытых релизов). Без сопровождения — деградирует: устаревшие индексы, неактуальные ревизии документов, падение доверия пользователей. Сопровождение — обязательная часть бюджета, типично 15–25% стоимости системы в год.

---

105 Industrial AI (ТОО «105kz», 105.kz) разворачивает LLM-ассистентов в закрытом контуре предприятий Казахстана. Демо на открытых СТ РК/ГОСТ — за 2 недели: решение Private LLM · запросить демо.