GigaChat on-premise: переносим внутреннего AI-ассистента с облака на своё железо

Несколько месяцев назад мы запустили внутреннего AI-ассистента на GigaChat API в облаке - про этот кейс писали в январе. Работало, клиент был доволен, жизнь шла своим чередом. А потом подошла служба безопасности и вежливо поинтересовалась, куда именно уходят запросы пользователей и что там в этих запросах бывает.

Вопрос справедливый. В запросах бывало разное: имена, должности, внутренние коды систем, иногда фрагменты документов. Формально - персональные данные и коммерческая тайна в одном флаконе. GigaChat обрабатывает данные на российской инфраструктуре Сбера, и с точки зрения 152-ФЗ это не автоматически катастрофа, но требует отдельного разговора с юристами и оформления соответствующих отношений с оператором. Клиент решил не углубляться в юридические дебри и поставил задачу: переходим на on-premise.

Примерно в это время Сбер анонсировал GigaChat API 2.0 с корпоративными тарифами именно под такой сценарий - развёртывание на собственной инфраструктуре. Совпало удачно.

Что изменилось в API 2.0

Ключевое для нашего кейса - два момента. Первый: расширенное контекстное окно. В предыдущей версии мы постоянно упирались в лимит при работе с длинными документами - приходилось чанковать агрессивно и терять связность ответов. Новое окно позволяет грузить в контекст заметно больше, что для RAG-сценариев напрямую улучшает качество.

Второй: появился вменяемый путь для корпоративного деплоя. Раньше on-premise был скорее темой для переговоров на уровне крупных контрактов, сейчас это оформленный продукт с документацией, лицензионной схемой и внятными требованиями к железу. Это не значит, что всё стало просто - это значит, что появилась стартовая точка для разговора.

Требования к GPU: реальность vs ожидания

Здесь начинается самая интересная часть диалога с клиентом. Официальные минимальные требования к развёртыванию модели корпоративного уровня - это не то, что можно закрыть одной картой, завалявшейся в сервере.

Для полной модели речь идёт о нескольких A100 или их отечественных аналогах. Клиент посмотрел на прайс и немного потускнел. Обсудили варианты: можно брать более лёгкую версию модели с меньшими требованиями к VRAM - качество хуже, но для хелпдеск-сценария может быть достаточно. Можно смотреть на отечественные ускорители - Яндекс и другие игроки уже продают GPU-серверы под такие задачи, но там своя история с доступностью и ценообразованием.

В итоге пришли к промежуточному решению: для пилота берём облачный GPU у отечественного провайдера с данными только в его периметре, параллельно прорабатываем покупку собственного железа. Не идеально с точки зрения «всё у себя», но юридически ситуация становится значительно чище - данные остаются у российского оператора с понятным договором.

Время отклика: чего ждать

Честно: on-premise на собственном железе - это не автоматически «быстрее, чем облако». Облачная версия GigaChat работала у нас на хорошо отмасштабированной инфраструктуре Сбера, с очередями и балансировкой. Наш пилотный сервер - один экземпляр модели без кластеризации.

При небольшой параллельной нагрузке (несколько одновременных запросов) время отклика сопоставимо с облаком или чуть хуже. При пиковой нагрузке - хуже заметно, потому что запросы выстраиваются в очередь к одному инстансу. Для внутреннего хелпдеска с несколькими сотнями пользователей это пока не критично - пики нагрузки небольшие и кратковременные. Но если задача - встроить ассистента во что-то с высокой интерактивностью, архитектуру нужно планировать иначе.

Отдельный момент - прогрев модели после рестарта. Первые запросы после загрузки заметно медленнее. Для продакшена это означает либо постоянно держать модель прогретой, либо мириться с задержками при плановых перезапусках.

Соответствие политике обработки ПДн

Вот тут on-premise действительно снимает головную боль. Данные не покидают периметр - ни в облако, ни к третьей стороне. Журналы запросов хранятся там, где их хранить положено по внутренним политикам. Аудит доступа к модели ложится в стандартную систему мониторинга.

Для клиентов, которые работают с персональными данными и уже попали под внимание регулятора после первых оборотных штрафов - это не абстрактный аргумент, а конкретное снятие риска. Особенно если в запросах к ассистенту могут оказаться данные физических лиц.

Дополнительный бонус - возможность точнее контролировать, что модель знает и чего не знает. В облаке модель получает обновления на стороне провайдера. В on-premise версия фиксированная, и если что-то поменялось в поведении - это только то, что поменяли мы.

Где сейчас

Пилот работает третью неделю. Качество ответов на хелпдеск-запросы сопоставимо с облачной версией - для нашего сценария облегчённая модель справляется. Железо у клиента в процессе согласования бюджета, пока держимся на арендованном GPU.

Главный вывод на этом этапе: on-premise GigaChat - это реальный путь, не маркетинг. Но это путь с инфраструктурными затратами, которые нужно честно закладывать. Кто думает, что это просто «поставить контейнер» - ошибается. Кто думает, что это принципиально неподъёмно для среднего бизнеса - тоже, если подходить поэтапно.

По итогам полноценного квартала на своём железе напишем предметнее.