On-prem LLM — это запуск языковых моделей на вашей инфраструктуре, когда данные и запросы не покидают периметр компании. Подходит, когда чувствительные данные нельзя отправлять во внешние API, поток запросов высокий, а к безопасности и доступу есть строгие требования.
Мы проектируем такие системы целиком: self-hosted inference, RAG в закрытом контуре, контроль доступа, мониторинг и интеграции — с возможностью начать с гибридной архитектуры и переносить нагрузку внутрь по мере роста.
Разница не в «лучше/хуже», а в том, где обрабатываются данные и кто отвечает за инфраструктуру.
Open-source модели под self-hosting через vLLM, llama.cpp или Ollama, с квантизацией и батчингом под целевую нагрузку. Модель подбирается под задачу, а не наоборот.
Локальные embeddings и векторная база (pgvector / Qdrant), retrieval и генерация ответа без выхода данных наружу. Это позволяет строить RAG по базе знаний на чувствительных документах.
Изоляция сети, аутентификация и авторизация, права доступа на уровне данных и retrieval, шифрование, журналирование запросов и ответов.
Конфигурация GPU и память рассчитываются под целевой поток и требования к задержке; стоимость считается per-request и сопоставляется с облаком.
Метрики latency, throughput, утилизации GPU, доступности и качества ответов; алерты на деградацию и контроль стоимости.
Подключение к внутренним системам и процессам — поддержка, документооборот, риск-операции — через тот же контур. Подробнее об интеграции — на странице интеграция ИИ.
On-prem оценивается по инфраструктурным и риск-метрикам в дополнение к качеству ответов.
Обезличенный пример: клиенты под NDA, метрики приведены диапазонами и проверяются на пилоте под конкретные требования.
Компания с регуляторными ограничениями не может отправлять документы и обращения с персональными данными во внешние API, но хочет внедрить RAG и автоматизацию.
Self-hosted inference (vLLM) и RAG в закрытом контуре, локальные embeddings и векторная база, контроль доступа, журналирование и мониторинг; гибридная маршрутизация для несекретных задач.
Данные остаются в периметре; latency и стоимость per-request выходят на целевые значения под прогнозируемый поток; качество подтверждается на eval-датасете под задачу.
Требуются вложения в GPU и эксплуатацию; на отдельных сложных задачах качество сверяется с облаком; конфигурация рассчитывается под реальный поток.
Когда on-prem LLM оправдана?
Когда данные нельзя или рискованно отправлять во внешние API (152-ФЗ, банковская и врачебная тайна, внутренняя безопасность), при высоком и предсказуемом потоке запросов, где собственная инфраструктура дешевле платы за API, и при требовании работать без выхода в интернет. Если ни одно из условий не выполняется, облако обычно проще и дешевле на старте.
Какие данные нельзя отправлять во внешние API?
Это определяется вашей правовой оценкой, но обычно к чувствительным относят персональные данные под 152-ФЗ без оснований для трансграничной передачи, банковскую и врачебную тайну, данные ГИС и существенную коммерческую тайну. Для таких данных inference и хранение остаются в закрытом контуре.
Будет ли качество хуже, чем у облачных моделей?
Для многих прикладных задач (RAG-ответы, классификация, извлечение полей) современные open-source модели в закрытом контуре дают достаточное качество. На сложных рассуждениях топовые облачные модели могут быть сильнее. Подход — подобрать модель под конкретную задачу и проверить качество на eval-датасете, а не отталкиваться от общих рейтингов.
Какая инфраструктура нужна?
Зависит от модели и нагрузки: серверы с GPU под inference, хранилище для моделей и векторной базы, сеть и контроль доступа. Конкретная конфигурация (число и тип GPU, объём памяти) рассчитывается под целевой поток запросов и требования к latency на аудите.
Можно ли начать с гибридной архитектуры?
Да, и часто это оптимальный старт. Чувствительные данные обрабатываются в закрытом контуре, а несекретные или пиковые задачи могут уходить в облако через слой маршрутизации. Так можно начать быстро и переносить нагрузку в on-prem по мере роста объёма и требований.
Как контролировать стоимость inference?
Через выбор модели под задачу, квантизацию, батчинг запросов, кэширование, маршрутизацию (мелкие задачи — лёгкой моделью) и мониторинг утилизации GPU. Стоимость считается per-request и сопоставляется с альтернативой в облаке для конкретного потока.