Как развернуть LLM в закрытом контуре: пошаговое руководство

Компания получает доступ к GPT-4 через API. Через два месяца выясняется, что сотрудники отправляли в промпты фрагменты конструкторской документации, персональные данные клиентов и тексты внутренних регламентов. Знакомая ситуация? Именно так обычно начинается разговор о развёртывании LLM on-premise — не с технического интереса, а с конкретного инцидента.

Эта статья — практическое руководство для тех, кто уже решил, что локальная LLM для компании нужна, но пока не понимает, с какого конца подступиться. Разберём выбор модели, инфраструктуру, инструменты инференса и типовые ошибки — без рекламы и без иллюзий.

Путь запроса в закрытом контуре: пользователь → API-gateway → vLLM → модель → ответ. Точки контроля ИБ выделены

Интерес к LLM в закрытом контуре вырос не из-за моды. Причины практические: ужесточение требований регуляторов (152-ФЗ, отраслевые стандарты ИБ), рост стоимости облачных API при масштабировании, а также нежелание отдавать конфиденциальные данные третьей стороне — даже если эта сторона обещает их не хранить.

Но между решением «нам нужна своя LLM» и работающим сервисом лежит цепочка нетривиальных инженерных решений. Поставить Docker-контейнер с моделью — это не развёртывание. Это эксперимент. Развёртывание LLM on-premise — это когда модель устойчиво обслуживает пользователей, укладывается в бюджет по железу, не деградирует под нагрузкой и вписывается в ИБ-инфраструктуру: сегментация сети, логирование, контроль доступа.

Ключевой критерий: данные чувствительны, объём запросов предсказуем, а требования к качеству ответов измеримы. Если задача размыта — «пусть ИИ нам что-нибудь полезное подскажет» — пилот почти гарантированно провалится вне зависимости от модели.

Выбор модели — решение, на которое тратят больше всего времени. И часто зря, потому что выбирают по бенчмаркам, а не по реальным требованиям задачи. Разберём три наиболее зрелых семейства open-source LLM для on-premise.

Стартовый вопрос → приоритет задачи → рекомендация модели

Квантизация LLM — это снижение точности числовых представлений весов модели. Вместо 16-битных чисел (FP16) используются 8-битные (INT8), 4-битные (INT4) или промежуточные форматы. Зачем? Чтобы модель поместилась в меньший объём видеопамяти и работала быстрее.

Цифры говорят сами за себя: модель на 70 миллиардов параметров в FP16 требует около 140 ГБ VRAM. В формате INT4 — примерно 35–40 ГБ. Разница — между кластером из нескольких GPU и одним A100 80 ГБ.

7B, 13B, 70B — требования к VRAM при разных уровнях квантизации и подходящие GPU

Когда модель выбрана и квантизована, нужен движок, который будет её обслуживать: принимать запросы, управлять очередями, эффективно использовать GPU. Два основных варианта — vLLM и TGI (Text Generation Inference от Hugging Face).

Важный контекст: в декабре 2025 года Hugging Face перевёл TGI в режим maintenance mode. Новые фичи больше не добавляются, принимаются только баг-фиксы. Для новых проектов HF рекомендует vLLM или SGLang. TGI по-прежнему стабилен и проверен — но вектор развития сместился.

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

Внедрение LLM в закрытом контуре — проект, а не разовая установка. Весь путь от идеи до пилота занимает 2–4 недели при наличии железа и компетенций.

С чего начинать

Развёртывание LLM в закрытом контуре — реалистичная задача для организации с профильными ИТ-компетенциями. Но это инженерный проект, а не покупка «коробочного решения».

Наиболее реалистичный путь: выберите одну конкретную задачу с измеримым результатом. Возьмите модель 7–8B (Llama 3.x или Qwen 2.5) в INT4. Разверните vLLM на сервере с GPU уровня RTX 4090 или A10G. Подключите к реальному процессу. Замерьте результат. И только после подтверждения гипотезы — масштабируйте.