Большинство компаний начинают работу с языковыми моделями через внешний API: подключили ChatGPT или аналог, автоматизировали несколько процессов, получили первые результаты. Это работает — до тех пор, пока ИИ остаётся вспомогательным инструментом на периферии бизнеса.
Как только модель начинает обрабатывать внутренние документы, клиентские данные или операционные показатели, возникают три проблемы одновременно. Первая — compliance: юридический и security-отделы блокируют передачу чувствительных данных во внешние сервисы. Вторая — интеграция: встроить внешний API в продукты, внутренние системы и ролевые модели доступа технически сложно и ненадёжно. Третья — экономика: при росте числа запросов стоимость токенов становится трудно прогнозируемой статьёй расходов, которая может достигать десятков тысяч долларов в месяц.
| Параметр | Phase 1 | Phase 2 |
|---|---|---|
| Серверы DGX | 2 DGX + 2 management nodes | 3 DGX A100 (DGX01, DGX02, DGX03) |
| GPU | 16× A100 (2 ноды по 8) | Расширенный worker-слой |
| Хранилище | 100 ТБ Lustre/DDN | 100 ТБ Lustre/DDN |
| Оркестрация | Kubernetes | Kubernetes |
On-premise LLM — это не «перенос ChatGPT внутрь компании», а построение отдельного архитектурного слоя. Модель и вся инфраструктура разворачиваются внутри контролируемого периметра: собственный дата-центр, colocation или private cloud. Данные не покидают инфраструктуру, все запросы логируются, доступ разграничивается по ролям. Для регулируемых отраслей — финансов, телекома, здравоохранения — это часто единственный способ вообще использовать ИИ в операционных процессах.
On-premise LLM разворачивается внутри корпоративного периметра: собственный дата-центр, colocation или private cloud.
Конкретный пример — проект для телеком-компании из региона MENA. Задача формулировалась не как «развернуть кластер», а как создать единую GenAI-платформу, на которой разные команды могут запускать обучение и инференс, работать с данными и развивать сценарии без разрозненных решений. Реализация шла в две фазы. В первой Kubernetes развернули на двух серверах DGX плюс двух управляющих нодах — итого 16 GPU A100. Во второй фазе worker-слой расширили до трёх DGX A100. Хранилище построено на базе Lustre поверх DDN с общим объёмом 100 ТБ — единое пространство для датасетов, чекпоинтов и артефактов. Наблюдаемость обеспечивают Prometheus и Grafana для метрик GPU и нод, централизованные логи собирает OpenSearch.
Тестирование распределённого обучения проводилось на двух нодах по четыре GPU каждая: исходный датасет объёмом 20 ГБ после препроцессинга сократился примерно до 10 ГБ, задание завершилось успешно. Для инференса использовали Llama-3-3-70B-Instruct — при нагрузке 100–200 запросов платформа показала throughput 300–700 токенов в секунду. Контролировались три ключевые метрики задержки: TTFT (время до первого токена), TPOT (время между токенами) и ITL (межтокенная задержка).
После развёртывания компания получает не отдельный сервис, а базу для итеративного добавления сценариев: ассистенты для техподдержки и продаж с доступом к внутренним знаниям, суммаризация и классификация обращений в контакт-центре, корпоративный поиск по документам через RAG, доменная адаптация модели под терминологию компании. Новые сценарии добавляются без перестройки инфраструктуры, а расходы растут предсказуемо вместе с нагрузкой — в отличие от токенной тарификации внешних провайдеров.
On-premise LLM оправдан не для всех. Он имеет смысл там, где модель уже стала частью операционной системы бизнеса: регулируемые отрасли с требованиями комплаенса, контакт-центры с большим потоком обращений, организации с несколькими продуктами и командами, которым нужна единая ИИ-платформа. На этапе экспериментов и первых пилотов внешний API по-прежнему остаётся быстрым и дешёвым способом проверить гипотезу.
