Когда компании пора строить свой LLM-кластер, а не пользоваться внешними API

На раннем этапе внедрения LLM в компании выглядят как быстрый выигрыш: подключается внешний API (например, ChatGPT), ускоряется работа с текстами, автоматизируются ответы, появляются первые сценарии аналитики и агентных пайплайнов через Make или n8n.

До определённого масштаба этого достаточно.

По мере роста компании LLM перестаёт быть вспомогательным инструментом и становится частью операционных процессов. В системе появляются чувствительные данные, требования к контролю доступа, необходимость стабильной работы, интеграции во внутренние сервисы и вопросы экономики при больших объёмах запросов.

В этот момент модель «внешний API по подписке» начинает ограничивать развитие.

On-prem LLM как архитектурный слой

On-premise LLM — это модель и инфраструктура, развёрнутые внутри контролируемого контура компании: собственный дата-центр, colocation или private cloud.

Это принципиально отличается от использования внешнего API.

On-prem модель даёт:

• контроль над данными и их размещением;

• контроль над доступами, ролями и сценариями использования;

• возможность встроить LLM в процессы как внутренний сервис, а не как внешний инструмент.

Речь идёт не о «переносе ChatGPT внутрь», а о построении AI-платформы как части корпоративной архитектуры.

Когда внешний LLM перестаёт работать

Переход к on-prem не происходит «по желанию». Обычно это реакция на конкретные ограничения.

1. Работа с чувствительными данными

Как только в LLM начинают попадать внутренние документы, клиентские данные, операционные показатели, возникает вопрос контроля.

Для внешних API это означает:

• ограничения со стороны security и legal;

• невозможность использовать модель в ряде процессов;

• необходимость ручных обходных решений.

On-prem снимает этот блок: данные остаются внутри периметра, что ускоряет внедрение AI в процессы.

2. LLM становится частью системы

Следующий этап — интеграция модели в продукты и внутренние инструменты:

• роли и уровни доступа;

• интеграции с внутренними системами;

• работа внутри интерфейсов сотрудников;

• возврат результата обратно в бизнес-системы.

В такой архитектуре важно, чтобы данные не уходили во внешние сервисы.

On-prem даёт:

• контроль над доступами и источниками данных;

• возможность логирования и аудита;

• предсказуемое поведение модели в рамках заданных сценариев.

3. Рост объёмов и экономика

На старте API-модель выглядит оптимальной: нет инфраструктуры, нет капитальных затрат.

На масштабе ситуация меняется:

• расходы на токены могут достигать десятков тысяч долларов;

• бюджет становится менее предсказуемым;

• стоимость каждого нового сценария зависит от внешнего тарифа.

Собственная инфраструктура в этом случае даёт управляемую экономику и предсказуемость затрат.

Кому подходит on-prem LLM

On-prem решения обычно появляются там, где LLM становится частью операционной системы бизнеса:

• регулируемые отрасли с требованиями комплаенса;

• компании с большими объёмами внутренних данных;

• контакт-центры и массовый сервис;

• организации с несколькими продуктами и командами;

• компании с прогнозируемым ростом нагрузки.

Кейс: LLM-платформа для телеком-компании (MENA)

В проекте для телеком-компании из региона MENA задача формулировалась не как «развернуть кластер», а как построить платформу для GenAI внутри корпоративного периметра.

Цель — создать контур, в котором разные команды могут:

• запускать обучение и инференс;

• работать с данными;

• развивать AI-сценарии без разрозненных решений.

Реализация была разбита на фазы.

Основные этапы

• фиксация целей и требований на уровне бизнес-процессов;

• проектирование контура: вычисления, данные, безопасность, эксплуатация;

• развёртывание платформы в периметре компании;

• интеграции с внутренними системами;

• организация хранения и структурирование данных;

• настройка метрик, логов и дашбордов;

• тестирование сценариев обучения и инференса под нагрузкой;

• передача документации и выстраивание эксплуатации.

Техническая реализация

Фазность и вычислительные ресурсы

Phase 1:

• Kubernetes развёрнут на 2 DGX + 2 management nodes

• 16 GPU A100 (2 compute-ноды по 8× A100)

Phase 2:

• расширение worker-слоя до 3× DGX A100 (DGX01, DGX02, DGX03)

Данные и хранилище

• Lustre-backed DDN storage

• общий путь /scratch для датасетов, чекпоинтов и артефактов

• объём: 100 TB shared storage

Наблюдаемость

• Prometheus + Grafana (метрики, GPU, ноды)

• централизованные логи: OpenSearch

Тестирование

Distributed training:

• сценарий: 2 ноды × 4 GPU

• объём данных: 20 GB → ~10 GB после препроцессинга

• job завершён успешно

Инференс:

• модель: Llama-3-3-70B-Instruct

• нагрузка: 100–200 запросов

• throughput: 300–700 tok/s

• контроль: TTFT / TPOT / ITL

Что даёт такая платформа

После развёртывания компания получает не отдельный сервис, а базу для развития AI-функций.

Типовые направления:

1. Внутренние AI-ассистенты

Ассистенты для техподдержки, продаж, операционных и юридических команд с доступом к внутренним знаниям.

2. Контакт-центр

• подсказки операторам

• суммаризация диалогов

• классификация обращений

• ускорение обработки тикетов

3. RAG и корпоративный поиск

Единая точка доступа к документам и знаниям:
запрос → ответ с источниками.

4. Доменная адаптация моделей

Донастройка под терминологию, продукты и типовые обращения компании.

5. Масштабирование

• добавление моделей

• рост нагрузки

• расширение compute и storage без перестройки архитектуры

6. Регулярный продакшн-цикл

• тестирование

• мониторинг

• регресс-прогоны

• контроль качества

Результат на уровне бизнеса

On-prem LLM-платформа даёт три ключевых эффекта:

• новые AI-сценарии добавляются итерациями без пересборки инфраструктуры (предсказуемый time-to-value);

• появляется прозрачность системы: нагрузка, узкие места, причины деградации;

• расходы становятся управляемыми при росте использования.

Вывод

Внешние LLM-API эффективны на этапе экспериментов и первых сценариев.

Когда AI становится частью процессов, появляются требования к контролю данных, интеграциям, стабильности и экономике. В этот момент возникает необходимость в собственной инфраструктуре.

On-prem LLM — это не альтернатива API, а следующий этап развития: переход от использования модели как инструмента к построению AI как системного слоя внутри компании.