Корпоративный GPT в закрытом контуре: от страхов к внедрению

Когда реально нужен закрытый контур (а когда — нет)

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

Но есть ситуации, когда альтернативы закрытому контуру просто нет. Мы в CrmAI разработали чек-лист из семи признаков — если вы узнаёте себя хотя бы в трёх пунктах, стоит серьёзно рассмотреть on-premise развёртывание.

Мифы о безопасности облачных решений

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

Миф первый: «OpenAI читает все наши запросы». На самом деле, при использовании API (не веб-интерфейса) данные по умолчанию не используются для обучения моделей. Это прописано в условиях сервиса и можно дополнительно подтвердить через DPA (Data Processing Agreement).

Миф второй: «Данные хранятся вечно». У большинства провайдеров есть чёткие политики retention — данные удаляются через 30 дней или даже быстрее. Некоторые сервисы предлагают zero-retention режим.

Миф третий: «Облако = отсутствие контроля». Существуют промежуточные решения: Azure OpenAI Service, AWS Bedrock, private endpoints. Данные остаются в вашем виртуальном облаке, не смешиваются с другими клиентами, вы контролируете геолокацию серверов.

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

Архитектура корпоративного GPT

Когда мы говорим о корпоративном GPT в закрытом контуре, речь идёт не просто об установке модели на сервер. Это целая экосистема компонентов, которые должны работать вместе. Ниже — состав этой экосистемы по слоям.

Основные компоненты системы

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

Варианты развёртывания

Выбор способа развёртывания зависит от масштаба, имеющейся инфраструктуры и компетенций команды. Ниже — три базовых подхода, которые реально используются.

Bare metal (физические серверы). Максимальная производительность, полный контроль, но и максимальная сложность. Нужно самим закупать оборудование, настраивать охлаждение (GPU серьёзно греются), заботиться о резервировании. Подходит для очень крупных компаний с собственным ЦОД или для ситуаций, когда требования безопасности исключают любую виртуализацию.

Kubernetes-кластер. Наиболее распространённый вариант. Гибкое масштабирование, удобное управление, можно использовать как собственное оборудование, так и арендованные GPU-серверы в частном облаке. Требует компетенций в DevOps/MLOps. Мы в CrmAI чаще всего рекомендуем именно этот подход.

Виртуализация (VMware, Proxmox). Компромиссный вариант для компаний, где уже есть виртуальная инфраструктура. Проще в управлении, чем Kubernetes, но может быть сложнее с проброском GPU. Хорошо работает для пилотных проектов и небольших нагрузок.

Требования к железу

Самый частый вопрос: «Сколько нужно GPU?». Ответ зависит от выбранной модели и ожидаемой нагрузки. Приведу ориентировочные цифры для типовых сценариев.

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

И отдельная история — охлаждение. Одна NVIDIA H100 потребляет до 700 Вт под нагрузкой. Кластер из восьми таких карт — это 5-6 кВт только на GPU, не считая остального оборудования. Нужно серьёзно продумать систему охлаждения или размещать оборудование в специализированном ЦОД.

Выбор модели для закрытого контура

Когда ChatGPT недоступен, приходится выбирать из open-source или локально развёртываемых решений. Хорошая новость: за последние два года качество открытых моделей выросло настолько, что для большинства бизнес-задач они уже не уступают GPT-3.5, а лучшие приближаются к GPT-4.

Разберём основных игроков и их особенности — особенно с точки зрения работы на русском языке, потому что это часто становится камнем преткновения.

Что выбрать: практические рекомендации

Исходя из нашего опыта внедрений, вот несколько практических советов.

Для большинства задач начните с Qwen 2.5 или Llama 3.1 в размере 70B. Это sweet spot между качеством и ресурсами. Модели работают достаточно быстро на двух A100 и справляются с большинством бизнес-задач: ответы на вопросы, суммаризация, генерация текстов, работа с документами.

Если русский язык критичен и бюджет позволяет — рассмотрите GigaChat. Сбер предлагает варианты on-premise развёртывания для крупных заказчиков. Модель отлично понимает русский, включая специфику деловой переписки, юридический язык, разговорную речь. Плюс есть сертификаты для работы с персональными данными.

Для пилота с ограниченным бюджетом — Qwen 2.5 7B или Llama 3.1 8B. Эти модели можно запустить даже на игровой видеокарте RTX 4090. Качество будет ниже, чем у больших моделей, но для проверки концепции и понимания, какие задачи вообще можно решить — вполне достаточно.

Если нужна максимальная скорость ответа — смотрите на Mistral. Архитектура Mixture of Experts позволяет получать ответы быстрее при том же качестве. Особенно актуально для сценариев реального времени: чат-боты, голосовые ассистенты.

Лицензионные нюансы

Обратите внимание на лицензии — не все «открытые» модели можно использовать без ограничений. Llama 3.1 требует согласия с условиями Meta и имеет ограничения для компаний с более чем 700 млн пользователей. Qwen 72B+ имеет ограничения на коммерческое использование в некоторых сценариях.

Для российских компаний также важен вопрос происхождения модели. Если вы работаете с госконтрактами — использование китайских или американских моделей может вызвать вопросы. В таких случаях GigaChat или другие отечественные решения будут более предпочтительны.

Стоимость владения: облако vs on-premise

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

Расчёт TCO на 3 года

Возьмём типовой сценарий: компания с 200 активными пользователями, средняя интенсивность использования — 20 запросов на пользователя в день, средняя длина запроса и ответа — 1000 токенов.

Как видите, при умеренном использовании затраты примерно сопоставимы. Но есть важные нюансы, которые могут кардинально изменить картину.

Когда облако дешевле

Облачные решения выигрывают в нескольких сценариях. Во-первых, на старте проекта, когда объёмы небольшие и непредсказуемые. Вы платите только за фактическое использование, нет капитальных затрат. Во-вторых, для компаний без собственной IT-инфраструктуры — разворачивать Kubernetes с нуля только ради GPT нерационально. В-третьих, когда нужен доступ к самым современным моделям — GPT-4 Turbo, Claude 3.5 пока недоступны для on-premise.

Когда on-premise выгоднее

On-premise становится экономически оправданным при высокой интенсивности использования. Если ваши сотрудники отправляют сотни запросов в день, счета за API быстро станут неподъёмными. Также on-premise выигрывает в долгосрочной перспективе — через 2-3 года оборудование окупается, и остаётся только стоимость эксплуатации.

Ещё один неочевидный фактор — предсказуемость. CFO любят фиксированные расходы. С on-premise вы точно знаете, сколько потратите в следующем месяце. С облаком расходы могут скакать в разы в зависимости от активности пользователей.

Скрытые расходы, о которых забывают

При расчёте TCO on-premise часто упускают несколько статей. Обновление оборудования: GPU устаревают, через 3-4 года захочется апгрейд. Обучение команды: Kubernetes и ML-инфраструктура требуют специфических компетенций. Время на отладку: первые месяцы после запуска будут «сырыми», готовьтесь к доработкам. Резервирование: для критичных систем нужен второй комплект оборудования.

С облаком свои подводные камни: внезапные изменения тарифов (OpenAI уже несколько раз менял цены), лимиты на запросы (rate limits могут стать проблемой при масштабировании), зависимость от внешнего провайдера.

Безопасность и комплаенс

Главная причина, по которой компании выбирают закрытый контур — безопасность. Но просто развернуть модель на своих серверах недостаточно. Нужно правильно настроить контроль доступа, аудит, политики обработки данных.

RBAC и аудит запросов

Первое, что нужно настроить — это разграничение доступа. Не все сотрудники должны иметь одинаковые права. Стажёр из отдела маркетинга и финансовый директор — это разные уровни доступа к чувствительной информации.

Мы рекомендуем внедрять систему ролей (RBAC — Role-Based Access Control) с самого начала. Типовые роли: базовый пользователь (общие вопросы, без доступа к конфиденциальным данным), продвинутый пользователь (может работать с внутренними документами), администратор (настройка системы, просмотр логов). Для каждой роли определяются доступные функции, лимиты на запросы, категории данных.

Аудит — не менее важная часть. Все запросы и ответы должны логироваться. Это нужно не только для безопасности, но и для отладки, анализа использования, контроля качества. При этом важно продумать, как долго хранить логи (баланс между compliance и приватностью), кто имеет доступ к логам, как обеспечить неизменяемость логов (чтобы нельзя было «подчистить» следы).

Политики обработки персональных данных

Если система будет работать с персональными данными (а в большинстве корпоративных сценариев будет), нужно соблюдать требования 152-ФЗ. Ключевые моменты: данные должны храниться на территории России, необходимо получить согласие субъектов на обработку, нужно обеспечить возможность удаления данных по запросу, требуется назначить ответственного за обработку ПД.

Практический совет: внедрите механизм маскирования PII (персонально идентифицируемой информации) до отправки в модель. Замените реальные ФИО, телефоны, номера документов на плейсхолдеры, получите ответ, подставьте реальные данные обратно. Это добавляет сложности, но значительно снижает риски.

Сертификация

Для некоторых отраслей требуется формальная сертификация системы. Если вы работаете с государственными информационными системами — потребуется сертификат ФСТЭК. Для международных компаний или работы с европейскими клиентами — ISO 27001. Для банков — соответствие требованиям ЦБ по информационной безопасности.

Важно понимать: сертификация — это длительный и дорогой процесс. Если она действительно требуется, закладывайте на это отдельный бюджет и минимум 6-12 месяцев. Если требования менее строгие — возможно, достаточно внутреннего аудита и документирования политик безопасности.

Пошаговый план внедрения

За время работы в CrmAI мы выработали методологию внедрения, которая минимизирует риски и позволяет получить работающую систему в разумные сроки. Делюсь этим планом.

Этап 1: Аудит требований (2-4 недели)

Прежде чем что-то внедрять, нужно понять, что именно внедрять. На этом этапе мы проводим серию интервью с ключевыми стейкхолдерами: IT-директором, службой безопасности, представителями бизнес-подразделений. Выясняем:

• Какие задачи планируется решать с помощью AI?
• Какие данные будут обрабатываться? Есть ли среди них конфиденциальные?
• Сколько пользователей? Какая ожидаемая нагрузка?
• Какая инфраструктура уже есть? Есть ли Kubernetes, GPU-серверы?
• Какие интеграции нужны? CRM, 1С, внутренние системы?
• Какие регуляторные требования нужно соблюдать?

На выходе — документ с техническими требованиями, архитектурой решения, планом проекта и бюджетной оценкой.

Этап 2: Пилот на 10-20 пользователей (4-6 недель)

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

На этом этапе разворачиваем минимальную инфраструктуру: один GPU-сервер, базовый интерфейс, простейшую интеграцию. Главная цель — проверить гипотезы: подходит ли выбранная модель для задач компании? Какие сценарии использования реально востребованы? Какие проблемы возникают?

По итогам пилота корректируем план: возможно, нужна другая модель, дополнительные интеграции, иная архитектура. Лучше узнать это на маленькой группе, чем после rollout на всю компанию.

Этап 3: Масштабирование (8-12 недель)

После успешного пилота начинаем масштабирование. Этот этап включает: закупку и настройку продакшн-оборудования, настройку отказоустойчивости и бэкапов, интеграцию с корпоративными системами (SSO, CRM, 1С), разработку полноценного пользовательского интерфейса, настройку мониторинга и алертинга, обучение пользователей и администраторов, документирование процессов.

Масштабирование лучше делать постепенно: сначала один отдел, потом другой. Это позволяет отлавливать проблемы на ранних этапах и не парализовать всю компанию в случае сбоя.

Этап 4: Эксплуатация и развитие (постоянно)

Внедрение — это не финиш, а старт. После запуска начинается самое интересное: анализ использования, выявление новых сценариев, оптимизация производительности, обновление моделей на более новые версии.

Рекомендуем заложить ресурсы на постоянную поддержку: минимум один DevOps/MLOps инженер на part-time или договор на сопровождение с подрядчиком. Система будет требовать внимания — обновления безопасности, мониторинг производительности, реакция на инциденты.

5 типичных ошибок при внедрении

Набили шишек достаточно — и своих, и насмотрелись на чужие проекты. Вот пять ошибок, которые встречаются чаще всего.

Подводя итоги

Корпоративный GPT в закрытом контуре — это серьёзный проект, требующий инвестиций, компетенций и времени. Но для компаний с жёсткими требованиями к безопасности данных это единственный способ использовать возможности современных языковых моделей.

Коротко зафиксирую ключевые выводы:

• Закрытый контур нужен не всем — сначала убедитесь, что он действительно необходим
• Существуют промежуточные варианты (Azure OpenAI, private endpoints) — рассмотрите их
• Выбор модели зависит от задач, языка, бюджета — универсального ответа нет
• Экономика сильно зависит от интенсивности использования
• Безопасность — это не только изоляция, но и RBAC, аудит, политики обработки данных
• Начинайте с пилота, масштабируйтесь постепенно

Если вы рассматриваете внедрение корпоративного GPT в вашей компании — мы готовы помочь на любом этапе: от аудита требований до полного развёртывания и сопровождения.