On-premise ИИ: как развернуть локальную LLM в компании, какая инфраструктура нужна и зачем отказываться от облака

Когда в 2024 году компании начали массово внедрять ChatGPT, вопрос о месте хранения данных казался второстепенным. Два с половиной года спустя картина изменилась: регуляторы ужесточили требования к персональным данным, утечки конфиденциальных промптов в облако стали реальными кейсами, а счета от OpenAI за API выросли на порядок при масштабировании. Параллельно с этим сообщество open-source выпустило серию моделей — Llama 4, Mistral Large 3, Qwen3, DeepSeek-V4 — которые в задачах корпоративного анализа документов, классификации заявок и генерации ответов уступают облачным лидерам не критично, а иногда и превосходят их в знании предметной области после дообучения.

Локальное развёртывание LLM — это не просто «запустить нейросеть на своём сервере». Это архитектурное решение, которое затрагивает инфраструктуру, безопасность, compliance, стоимость владения и интеграцию с существующими системами. В этой статье разберём полный цикл: от обоснования выбора on-premise до конкретной конфигурации сервера и интеграции с ERP.

Что такое on-premise LLM и какие инструменты для этого существуют

On-premise LLM — это большая языковая модель, которая работает на серверах компании, в её ЦОДе или на арендованном bare-metal, а не через API поставщика вроде OpenAI, Anthropic или Yandex GPT. Модель загружается как файл весов (обычно 4–70 GB в квантованном формате), запускается через inference-движок и предоставляет API, совместимый с OpenAI — то есть ваши приложения могут обращаться к ней так же, как к ChatGPT, но по внутреннему адресу.

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

Ollama. Самый простой способ начать: один бинарник, который скачивает модель из реестра и запускает её с REST API. Подходит для прототипов и небольших команд. Поддерживает Llama, Mistral, Qwen, Gemma, Phi и десятки других моделей из коробки. Запуск — одна команда: ollama run llama3.1.

vLLM. Производительный inference-движок с поддержкой PagedAttention, который позволяет обрабатывать тысячи параллельных запросов на одном GPU. Используется в production, когда речь идёт о корпоративном чат-боте для сотен сотрудников. Поддерживает распределённый инференс на нескольких GPU.

Text Generation Inference (TGI) от HuggingFace. Enterprise-решение с поддержкой streaming, quantization, speculative decoding и интеграцией с экосистемой HuggingFace. Хорошо подходит, если вы планируете дообучать модели на своих данных через их инфраструктуру.

llama.cpp. Лёгкий C++ inference-движок, который позволяет запускать модели даже на CPU без GPU — медленно, но возможно. Используется для edge-сценариев или когда GPU недоступен.

OpenWebUI. Веб-интерфейс, который работает поверх Ollama или другого API и даёт сотрудникам привычный чат с историей диалогов, загрузкой документов и административной панелью. По функциональности близок к ChatGPT Enterprise, но полностью локальный.

OpenClaw. Open-source AI-агент на Node.js, который вышел в конце 2025 года и за несколько месяцев набрал более 340 000 звёзд на GitHub. В отличие от обычных чат-ботов, OpenClaw не просто отвечает на вопросы — он выполняет действия: читает файлы, запускает shell-команды, управляет браузером, работает с cron-задачами и интегрируется с мессенджерами (Telegram, Slack, WhatsApp, Discord, Microsoft Teams, Signal, Matrix). Подключается к любым LLM — как облачным (Claude, GPT-5, Gemini), так и локальным через Ollama или vLLM. Имеет систему skills (плагинов) и sandbox-режим для безопасного выполнения команд. Для корпоративной среды это ключевой инструмент: сотрудник пишет в корпоративный чат «проверь статус заказа 12345 в 1С» — OpenClaw понимает запрос, обращается к Symfony-API, получает данные из 1С и возвращает ответ в тот же мессенджер.

Плюсы on-premise LLM перед облачными API

Когда облако всё ещё выигрывает

Честно: on-premise — не серебряная пуля. Облачные API остаются лучшим выбором в трёх случаях:

Нерегулярное использование. Если команда делает 500 запросов в месяц, аренда сервера с GPU обойдётся дороже, чем оплата API. Облако выигрывает при малых и непредсказуемых объёмах.

Сложные мультимодальные задачи. GPT-5, Claude 4 Opus и Gemini 2.5 Pro пока заметно превосходят open-source модели в анализе изображений, сложных рассуждений и длинном контексте (2M+ токенов). Если ваш сценарий — анализ сканов документов с таблицами и графиками, облако даёт лучшее качество.

Отсутствие DevOps-компетенции. Развёртывание и поддержка on-premise LLM требует инженера, который умеет работать с Docker, GPU, мониторингом и сетевой безопасностью. Если в штате такого специалиста нет и нет планов его искать — облачный API надёжнее.

Архитектура on-premise ИИ в корпоративной среде

Типичное решение, которое мы внедряем для клиентов, состоит из четырёх слоёв:

1. Слой данных. 1С, файловое хранилище, Confluence, почта — источники документов и знаний. Данные извлекаются через OData, API или парсеры, разбиваются на фрагменты (chunks) и индексируются.
2. Векторная БД. Qdrant или pgvector хранит эмбеддинги документов. При запросе система находит 3–5 релевантных фрагментов по смыслу.
3. Inference-сервер. Ollama или vLLM на выделенном сервере с GPU. Принимает запросы по HTTP, генерирует ответы, управляет очередью.
4. AI-агент (OpenClaw). Оркестратор, который принимает запросы из мессенджеров, понимает намерение пользователя, выбирает нужный skill, обращается к Symfony-API для получения данных, формирует контекст из векторной БД и отправляет в LLM. Возвращает результат в тот же канал — Telegram, Slack или Teams.
5. Интеграционный слой. Symfony-приложение, которое предоставляет API для 1С, управляет доступом, логирует запросы и служит мостом между OpenClaw и корпоративными системами.

Такая архитектура позволяет подключить LLM к существующим системам — ELMA365, SimpleOne, Битрикс24, 1С — без доработки самих учётных систем. Symfony выступает middleware: принимает webhook от BPM, обогащает контекст из векторной БД, отправляет в LLM, записывает ответ обратно в систему.

Какой сервер и инфраструктура нужны

Требования зависят от размера модели, ожидаемой нагрузки и допустимой задержки. Ниже — три типовые конфигурации, с которыми мы работаем.

CPU-only: когда GPU ещё не нужен

Модели в квантованном формате (Q4, Q5) можно запускать на CPU. Llama 4 8B на 16-ядерном процессоре выдаёт 5–10 токенов в секунду — медленно для чата, но приемлемо для пакетной обработки заявок или классификации документов. Это хороший способ начать пилот без инвестиций в GPU.

GPU: что важно знать

Для интерактивного чата с моделью 70B+ параметров нужен GPU с 24+ GB видеопамяти. RTX 4090 (24 GB) — бюджетный выбор для одной модели. Для enterprise-нагрузки — NVIDIA A100 (80 GB) или H100. Важно: модель должна полностью помещаться в VRAM, иначе производительность падает на порядок. Для 405B-моделей нужны два A100 с NVLink или четыре GPU поменьше.

Диск и сеть

SSD обязателен — модели весом 40–70 GB загружаются с HDD минутами, с SSD — секундами. Сетевая карта 1 Gbps достаточна для inference, но если вы планируете дообучение (fine-tune) — нужен 10 Gbps между сервером и хранилищем данных. Оперативная память: минимум 1.5× от размера модели в RAM. Для 70B Q4 (40 GB) — 64 GB RAM, для 405B Q4 (230 GB) — 384 GB RAM.

Какую модель выбрать: сравнение для корпоративных задач

Для российских компаний с акцентом на русский язык мы чаще всего рекомендуем Qwen3 72B — она лучше понимает русскую деловую лексику, чем Llama, и не уступает в логике. Для задач, где критична точность рассуждений (юридический анализ, сложные BPM-роутинги) — Mistral Large 3 или DeepSeek-V4.

Базы данных: где хранить знания для RAG

LLM без контекста — это университетский выпускник, который не знает специфики вашей компании. Чтобы отвечать по внутренним документам, нужен RAG: векторный поиск по корпоративной базе знаний с подстановкой релевантных фрагментов в prompt.

Qdrant. Наша рекомендация для production. Rust-based, self-hosted, поддерживает фильтрацию метаданных, кластеризацию, гибридный поиск. Развёртывается через Docker за 15 минут. Хорошо масштабируется при росте до миллионов векторов.

pgvector. Расширение PostgreSQL. Плюс: не нужен отдельный сервис, данные хранятся рядом с основной БД приложения. Минус: производительность падает после 500K–1M векторов, нет встроенной репликации под нагрузку чтения. Хорош для пилотов и небольших порталов.

Chroma. Простая embedded-БД для прототипов. Не рекомендуем для production — нет кластеризации, слабая производительность под нагрузкой, ограниченное сообщество.

Пошаговое развёртывание: от Docker до интеграции с 1С

Типовой сценарий, который мы реализуем за 2–3 дня:

1. Подготовка сервера. Устанавливаем Ubuntu 22.04, Docker, Docker Compose. Настраиваем NVIDIA Container Toolkit, если используем GPU.
2. Запуск Ollama. docker run -d --gpus all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama. Загружаем модель: docker exec -it ollama ollama pull qwen3:72b.
3. Запуск Qdrant. docker run -d -p 6333:6333 -v qdrant_storage:/qdrant/storage qdrant/qdrant.
4. Индексация данных. Symfony-сервис читает документы из 1С (OData), Confluence (API), файлов (парсер), разбивает на chunks, генерирует эмбеддинги через локальную модель (BGE-M3 или тот же Ollama) и сохраняет в Qdrant.
5. API-шлюз. Symfony-приложение предоставляет endpoints для работы с данными: /api/ask (поиск по знаниям), /api/1c/order/{id} (данные из 1С), /api/bpm/task (заявки в BPM). Все endpoints защищены авторизацией и логируются.
6. Установка OpenClaw. curl -fsSL https://openclaw.ai/install.sh | bash, затем openclaw onboard --install-daemon. В конфиге ~/.openclaw/openclaw.json указываем локальную модель ollama/qwen3:72b и подключаем нужные каналы — Telegram-бот, Slack, или внутренний Mattermost.
7. Skills. Пишем корпоративные skills в виде Markdown-файлов с инструкциями: «для проверки статуса заказа используй API /api/1c/order/{id}», «для поиска по регламентам используй /api/ask». Сохраняем в ~/.openclaw/skills/ — OpenClaw автоматически подхватывает их.
8. Интеграция. Сотрудник пишет в корпоративный чат: «проверь заказ 12345» — OpenClaw определяет намерение, выбирает skill, делает запрос к Symfony-API, получает данные из 1С, формирует ответ и отправляет обратно в чат. Всё внутри сети компании.

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

OpenClaw vs традиционный корпоративный чат-бот

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

Сценарии использования в корпоративной автоматизации

Чат-бот для сотрудников через OpenClaw. Сотрудник пишет в корпоративный Telegram или Slack: «как оформить командировку?» — OpenClaw ищет ответ в векторной БД, находит актуальный регламент и присылает ссылку на конкретный пункт. Если нужно — создаёт заявку в ELMA365 через API. Заменяет 30–40% обращений в HR и IT-поддержку. В отличие от статичного FAQ, OpenClaw помнит контекст: «а какой срок подачи?» — он понимает, что речь всё ещё о командировке.

Автоматическая классификация заявок. Входящая заявка в BPM (ELMA365, SimpleOne) анализируется LLM: определяется категория, срочность, вероятный исполнитель. Точность — 85–92% после дообучения на истории компании.

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

Генерация ответов клиентам. На основе базы знаний и истории переписки LLM формирует черновик ответа менеджеру по продажам или в поддержку. Менеджер редактирует и отправляет — экономия 5–10 минут на каждое письмо.

Часто задаваемые вопросы

Можно ли запустить LLM на обычном офисном компьютере?

Модели до 8B параметров в квантованном формате (Q4) запускаются на CPU с 16 GB RAM — медленно, но работают. Для комфортной работы 70B-модели нужен серверный GPU. Но для пилота и тестирования гипотез подойдёт даже мощная рабочая станция.

Нужен ли интернет для работы on-premise LLM?

Нет. После загрузки модели сервер работает полностью автономно. Интернет нужен только для первоначальной загрузки весов и обновлений. Это одно из ключевых преимуществ для компаний с изолированными сетями или повышенными требованиями к безопасности.

Как обеспечить отказоустойчивость?

Для критичных сценариев разворачиваем два inference-сервера (Ollama/vLLM) за балансировщиком (Nginx или HAProxy). Если основной сервер падает — запросы переключаются на резервный. Модель и векторный индекс реплицируются. Qdrant поддерживает кластеризацию из коробки.

Чем OpenClaw отличается от n8n или Zapier?

OpenClaw — это не классический workflow-automation вроде n8n или Zapier. n8n требует, чтобы вы визуально собрали цепочку «если A, то B» — каждый шаг явно прописан. OpenClaw работает иначе: вы описываете цель естественным языком, а агент сам решает, какие инструменты и skills использовать. «Проверь статус заказа 12345 и если он просрочен — напиши менеджеру в Telegram» — OpenClaw сам определит последовательность: запрос к 1С, анализ даты, отправка сообщения. Это сокращает время настройки типовых сценариев с часов до минут.

Сколько стоит внедрение on-premise ИИ под ключ?

Пилот с 8B-моделью, индексацией 5 000 документов и интеграцией в корпоративный портал — от 200 000 ₽. Production-решение с 70B-моделью, GPU, отказоустойчивостью и интеграцией в 1С/ELMA365 — от 600 000 ₽. Ежемесячные расходы на bare-metal с GPU — от 45 000 ₽/мес. Точка безубыточности по сравнению с облачным API — при 80–120 тысячах токенов в день.

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

Да, через fine-tuning с использованием инструментов вроде Unsloth, Axolotl или собственного pipeline на PyTorch. Но для большинства корпоративных задач достаточно RAG — он даёт 80% эффекта при 20% затрат. Fine-tuning имеет смысл, когда нужно изменить стиль ответа, добавить узкую терминологию или повысить точность на специфических задачах (юридический анализ, медицинская диагностика).

Какие данные нельзя передавать даже в on-premise LLM?

On-premise решает проблему утечки данных к внешнему поставщику, но не отменяет внутренние политики доступа. Если модель развёрнута на общем сервере, к ней могут обращаться все сотрудники сети. Настройте авторизацию на уровне API, разграничение по ролям и аудит запросов. Для особо чувствительных данных — выделенный инстанс с ограниченным кругом доступа.

Итог

On-premise LLM — это уже не эксперимент, а зрелая инфраструктурная опция для компаний, которым важны конфиденциальность, предсказуемые затраты и независимость от внешних поставщиков. Open-source модели 2025–2026 года — Llama 4, Mistral Large 3, Qwen3, DeepSeek-V4 — закрывают 85–95% корпоративных задач: от чат-бота до анализа договоров. Оставшиеся 5–15% (сложная мультимодальность, ультрадлинный контекст) пока остаются за облаком — но и их open-source сообщество наращивает быстро.

Архитектура решения проста и повторяема: сервер с GPU (или CPU для пилота), Ollama или vLLM как inference-движок, Qdrant или pgvector для векторного поиска, Symfony как интеграционный слой, и OpenClaw как AI-агент, который связывает всё воедино через привычные мессенджеры. Внедрение занимает дни, а не месяцы — особенно если данные уже структурированы и интеграция с 1С настроена через OData.

Если вы планируете локальное развёртывание LLM в компании — напишите нам. Мы проведём аудит вашей инфраструктуры, подберём модель и железо под задачи и бюджет, развернём пилот с OpenClaw, настроим skills для работы с 1С и интегрируем с вашими системами — ELMA365, SimpleOne или Битрикс24. От пилота на CPU до кластера с GPU и отказоустойчивостью.