Москва, ул. Пришвина, д.8, корп.2
С корпоративным AI сейчас происходит примерно то же, что когда-то происходило с облаками. Сначала это любопытный инструмент, который пробуют отдельные сотрудники. Потом находится задача, где он действительно экономит время. Следом появляется идея подключить к нему внутренние документы, базу знаний, CRM или техническую документацию. И вчерашний эксперимент довольно быстро становится частью рабочей IT-системы.
На этом этапе меняются и вопросы. Какую модель выбрать, конечно, по-прежнему интересно. Но рядом появляются менее эффектные и куда более практичные вещи: где будут храниться данные, где запустится сама модель, кто получит к ней доступ, хватит ли ресурсов при росте нагрузки и насколько легко инфраструктуру можно будет расширить, если пилот окажется успешным.
Вот здесь и начинается разговор об отдельном контуре для корпоративного AI.
У этой истории есть и более широкий фон. Мы уже рассказывали, как развитие AI влияет на доступность мощностей дата-центров, увеличивает потребление электроэнергии, меняет рынок памяти и серверных комплектующих и в целом влияет на стоимость IT-инфраструктуры. Теперь посмотрим на ситуацию с другой стороны: что происходит, когда AI приходит внутрь самой компании.
Где заканчивается удобство публичного AI
Для эксперимента публичный сервис почти идеален. Не надо покупать сервер, поднимать окружение, думать об охлаждении стойки и выяснять, почему в пятницу вечером внезапно закончилось место на диске. Зарегистрировались, получили доступ к модели, проверили идею. Для части задач этого более чем достаточно.
Но представим другой сценарий. Компания хочет сделать ассистента для технической поддержки, который знает документацию по продуктам, историю обращений, внутренние инструкции и базу типовых решений. Юридическому отделу нужен поиск по договорам и архиву. Инженеры хотят задавать вопросы по техническим регламентам и проектной документации.
Тогда AI приходится давать доступ к информации, которую компания обычно не отправляет во внешние сервисы без дополнительных вопросов. Где физически находятся данные? Кто их обрабатывает? Какие сотрудники имеют доступ? Что пишется в журналы? Где лежат резервные копии? Может ли система обращаться к внешним API?
Причины для отдельного контура бывают разными. Где-то действуют внутренние требования информационной безопасности, где-то отраслевые или договорные ограничения. Иногда всё проще: компании важно самой понимать, на каких ресурсах находятся её данные и кто имеет к ним доступ.
При этом «свой контур» совсем не означает обязательную серверную в соседней комнате. Инфраструктура может работать на собственном оборудовании компании или на выделенных ресурсах провайдера. Главное, что вычисления, данные и связанные с ними сервисы находятся в контролируемой среде с понятными границами доступа.
AI-инфраструктура это не один сервер с очень дорогой видеокартой
GPU получает больше всего внимания, и это неудивительно. Ускорители дороги, их характеристики постоянно обсуждают, а объём видеопамяти порой выглядит главным показателем готовности компании к AI.
На практике всё интереснее.
Возьмём корпоративного ассистента с RAG. RAG позволяет модели отвечать с учётом документов компании: система ищет подходящие фрагменты в базе знаний и передаёт их модели вместе с запросом пользователя.
Для такой схемы нужна сама модель, но вокруг неё довольно быстро собирается компания. Документы надо где-то хранить и индексировать. Появляется векторная база, прикладная логика, API, авторизация, интеграции с внутренними системами. Всё это нужно обновлять, мониторить и резервировать.
Нагрузка тоже распределяется по-разному. Модель может требовать GPU, базы и API работают на CPU, для индексов и активно используемых данных важна скорость дисковой подсистемы. При больших объёмах данных могут понадобиться NVMe, а если компонентов становится несколько, всё заметнее роль сети между узлами.
Поэтому начинать проект с вопроса «какую видеокарту брать?» примерно то же самое, что выбирать двигатель, ещё не решив, проектируем мы городской автомобиль, грузовик или гоночную машину.
Сначала нужно понять саму задачу. Какая модель будет использоваться, сколько ожидается одновременных запросов, какой объём данных придётся обрабатывать, нужна ли работа с изображениями или видео, планируется обучение модели или только инференс.
После этого уже становится понятно, нужен ли GPU вообще, какой объём видеопамяти потребуется и какие ресурсы должны работать рядом с ним.
Когда одного сервера хватает, а когда появляется кластер
Для пилотного проекта один сервер часто оказывается вполне разумным началом. На нём можно проверить модель, собрать первую версию сервиса, подключить данные и увидеть реальную нагрузку. Покупать инфраструктуру на три года вперёд только потому, что «AI наверняка будет расти», особого смысла нет.
Самое интересное начинается, когда пилот действительно работает.
Сначала ассистентом пользуются пять человек, потом двадцать. Ещё через некоторое время доступ получает новый отдел, подключается дополнительная база документов, появляется вторая модель, растёт число запросов. Сервер, который месяц назад большую часть дня откровенно скучал, уже не выглядит таким мощным.
Тогда архитектуру можно разделять по ролям. На одном узле работает модель, на другом хранятся и обрабатываются данные, отдельные серверы обслуживают базы, API и интеграции. Если вычислительной мощности становится мало, добавляются GPU-узлы.
Так постепенно появляется кластер. Его преимущество как раз в том, что инфраструктуру можно развивать частями, а не покупать всё сразу. Следующий узел появляется тогда, когда для него уже есть реальная нагрузка.
В ESTT для таких проектов есть отдельный вариант защищённого кластера, когда несколько серверов объединяются в единый контур с общей сетевой инфраструктурой. Для AI-систем такой подход удобен ещё и тем, что вычислительные узлы, базы, хранилища и сервисы можно разделить по ролям, сохранив возможность дальнейшего расширения.
Это особенно полезно для проектов, где нагрузку до запуска иногда приходится оценивать с точностью примерно «ну, должно хватить».
Какие корпоративные задачи требуют своей инфраструктуры
Один из самых понятных сценариев это внутренний AI-ассистент. Он может искать информацию в регламентах, инструкциях, технической документации, базе знаний или истории обращений и формировать ответы на основе данных компании.
Близкая задача связана с локальными LLM и RAG-системами. Здесь особенно хорошо видно, что инфраструктура нужна не только модели. Документы приходится хранить и обновлять, данные индексировать, нужные фрагменты быстро находить и передавать в контекст запроса.
Другой большой пласт это обработка документов и данных: классификация, извлечение информации, поиск по архивам, анализ обращений, подготовка сводок. Если через систему проходят внутренние или клиентские документы, требования к размещению и доступу становятся частью проекта с самого начала.
Есть задачи компьютерного зрения, генерации изображений и видео, обработки медиаданных. Здесь нагрузка может серьёзно смещаться в сторону GPU. А командам, которые разрабатывают собственные AI-продукты, нужна отдельная среда для тестирования моделей, интеграций, разных конфигураций и нагрузки.
На словах всё это называется AI. С точки зрения инфраструктуры это совершенно разные проекты. Поэтому универсального «AI-сервера» не существует: конфигурация для внутреннего поиска по документам и система для тяжёлой модели с большим потоком запросов могут отличаться почти во всём.
А что с безопасностью
Сам по себе выделенный сервер ещё не делает систему защищённой. Можно поставить дорогое оборудование за закрытой дверью и оставить пароль admin123. Формально контур свой, а спокойнее от этого почему-то не становится.
Безопасность AI-инфраструктуры начинается с вполне знакомых вещей: разграничения прав, сетевой сегментации, контроля доступа, журналирования, обновлений, резервного копирования и мониторинга.
У AI-систем добавляется ещё один важный вопрос: куда уходят данные во время обработки. Например, документы могут храниться внутри собственного контура, но отдельный компонент приложения обращается к внешнему API. Тогда нужно понимать, какие данные передаются за пределы инфраструктуры и соответствует ли это требованиям компании.
Если нужен полностью закрытый контур, такое ограничение влияет и на архитектуру, и на выбор модели, и на интеграции. AI здесь не отменяет старые правила информационной безопасности. Он просто добавляет новые места, где о них легко забыть.
Покупать оборудование или арендовать
Если нагрузка известна, система рассчитана на долгую эксплуатацию, а у компании есть специалисты и подходящая площадка, покупка собственного оборудования может быть вполне рациональной.
С новым AI-проектом определённости обычно меньше. После тестов может выясниться, что выбранной модели нужно больше видеопамяти. Через несколько месяцев команда решит использовать другую модель. Число пользователей вырастет, появятся новые компоненты, потребуется отдельное хранилище.
Бывает и обратная ситуация: купленный с запасом GPU большую часть дня работает с загрузкой, которая заставляет финансового директора задумчиво смотреть на счёт за оборудование.
К стоимости самого сервера при этом добавляются размещение, питание, охлаждение, сеть, обслуживание и резервирование.
Поэтому на этапе пилота аренда выделенной инфраструктуры часто даёт больше свободы. Можно собрать конфигурацию под текущую задачу, проверить её в реальной работе и расширять ресурсы по мере появления нагрузки.
Но аренда не универсальный ответ. Для большой, стабильной и хорошо прогнозируемой нагрузки экономику собственного оборудования имеет смысл считать отдельно. Здесь нет правильного решения для всех, есть конкретный проект и его цифры.
С чего начинать проект
Для первого расчёта инфраструктуры совсем не обязательно знать точную модель сервера, количество ядер и объём видеопамяти.
Гораздо полезнее описать, что должна делать система, с какими данными она будет работать, сколько пользователей или запросов ожидается на старте и насколько быстро проект может вырасти.
Например: «Нужен внутренний ассистент для ста сотрудников. Он должен искать по корпоративной базе знаний и технической документации. Документы сейчас хранятся здесь, часть системы должна быть закрыта от внешних сервисов».
Для начала этого уже достаточно. Дальше можно разбираться с моделью, GPU, CPU, оперативной памятью, дисками, сетью и схемой масштабирования.
Так вероятность собрать красивую и дорогую конфигурацию, которая решает не ту задачу, становится заметно меньше.
Инфраструктура для корпоративного AI в ESTT
В ESTT AI-проект можно начать с одного сервера или GPU-VPS, а по мере роста перейти к выделенным GPU-серверам, отдельным узлам для приложений и баз данных, быстрому NVMe или S3-хранилищу и кластерной архитектуре.
Конфигурация зависит от проекта. Для одного сервиса основная нагрузка придётся на GPU, для другого важнее окажутся RAM, быстрые диски или объём хранилища. В сложной системе роли можно распределить между несколькими серверами и развивать контур по мере роста нагрузки.
При этом ESTT отвечает именно за инфраструктурную часть. Мы не разрабатываем нейросеть вместо команды клиента и не создаём AI-продукт под ключ. Наша задача это серверная площадка, вычислительные ресурсы, хранение, сеть и возможность масштабировать инфраструктуру вместе с проектом.
Подробнее о вариантах построения такого контура мы рассказали на странице «Инфраструктура для корпоративного AI».
Есть задача, но пока нет готового ТЗ?
Это вполне нормальная точка старта. Расскажите, что должна делать система, с какими данными работать и какая ожидается нагрузка. Поможем определить, нужен ли GPU, какие серверы и диски подойдут и как собрать инфраструктуру с возможностью дальнейшего роста.