Как решить проблему нехватки вычислительных ресурсов для ИИ внутри отдельного бизнеса

Нехватка ресурсов для ИИ часто связана не с дефицитом GPU, а с тем, как компании используют уже имеющиеся мощности. В материале «Российской газеты» эксперты Группы Rubytech объясняют, почему закупка оборудования под каждый новый проект тормозит рост бизнеса и как совместная ИИ-инфраструктура делает ресурсы управляемыми и предсказуемыми.

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

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

ПАК для ИИ - это связка аппаратного обеспечения, операционной системы, Kubernetes (открытое ПО для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями - Прим. ред.), ИИ-обеспечения, моделей и прочих ИТ-инструментов. Одна из его задач - обеспечить совместимость компонентов. Например, специалисты Группы Rubytech, специализирующейся на ПАК Скала^р, используют матрицу совместимости, в которой проверяют взаимодействие Kubernetes, серверов, GPU разных производителей, коммутаторов и других составляющих. После валидации компонент попадает в поддерживаемую конфигурацию, а так как управлять инфраструктурой можно через единый интерфейс, то при необходимости отдельные компоненты можно менять без ее полной пересборки, но новые все равно придется проверить на совместимость.

Что касается безопасности, в ИИ-инфраструктуре обычно выделяют 11 основных типов угроз. Для их закрытия используются разные средства, включая контейнеры, аппаратную инфраструктуру, исполнение моделей, промышленные firewall (система защиты компьютерной сети - Прим. ред.) и защиту от инъекций. Часто такой подход называют "пластилином безопасности": защитный контур можно собирать из разных средств на разных уровнях - в зависимости от того, какую угрозу нужно закрыть. При этом классификация самих угроз имеет общемировой характер, а способы защиты конкретной инфраструктуры требуют отдельной работы, и в том числе поэтому ИИ-инфраструктура может требовать в два-три раза большего бюджета, чем классическая. Также в расчет входят не только серверы и ускорители, но и энергопотребление, охлаждение, амортизация и сопровождение, поэтому важна не только совокупная стоимость владения (TCO), но и экономика конкретного ИИ-сценария.

В разговоре с "РГ" эксперты Группы Rubytech рассказали, что загрузку вычислительных ресурсов в среднем можно доводить до 70-85 процентов. Контекст можно размещать ближе к модели, которая его использует, а ее размер должен соответствовать задаче и требованиям SLA (соглашение об уровне обслуживания между поставщиком услуг и их заказчиком - Прим. ред.): не всегда нужна большая, иногда достаточно меньшей или дообученной. Разные задачи с разными требованиями к инструментам можно распределять по доступным ресурсам, как в тетрисе: раскладывать так, чтобы оставалось как можно меньше свободного пространства.

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

Если непонятно, какой эффект должен дать ИИ-проект, сложно определить требуемый объем инфраструктуры, поэтому важно создать эвристику или метрику оценки ИИ-проектов хотя бы на год и регулярно к ней возвращаться. В этом плане ПАК ИИ удобен еще и потому, что снимает с заказчика часть инфраструктурной сложности. Вместо самостоятельной сборки компонентов он получает заранее согласованный набор ресурсов и программного обеспечения: оборудование, драйверы, микрокод, модели, инструменты и другие составляющие.