Прекратите проектировать инфраструктуру ИИ вокруг GPU

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

Проведя всего пять минут на конференции по ИИ, вы легко можете уйти с убеждением, что каждый успешный запуск ИИ начинается с покупки большего количества GPU. Это легко понять. Оборудование доминирует в обсуждениях. Клиенты слышат о системах Blackwell, сетях InfiniBand, гипермасштабных облаках и всё более массивных кластерах ИИ. Поставщики естественно тяготеют к новейшим ускорителям и самым быстрым системам, потому что они захватывающие, актуальные и относительно легко продать на рынке.

Проблема не в том, что вычислительные ресурсы не важны. Они имеют огромное значение.

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

Первый вопрос не должен звучать «Какой GPU нам купить?»

«Какую рабочую нагрузку мы пытаемся поддержать?» должна стать в центре внимания.

Это, казалось бы, небольшое изменение влияет почти на каждое последующее решение об инфраструктуре.

Нет стандартной инфраструктуры ИИ

Одно из крупнейших заблуждений на рынке — это представление о существовании стандартного шаблона инфраструктуры ИИ. Такового нет.

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

Вы на самом деле не проектируете инфраструктуру для «ИИ». Вы проектируете инфраструктуру для бизнес‑приложения, которое использует ИИ. Это различие имеет значение. Каждая нагрузка предъявляет уникальные требования к поддерживающей её инфраструктуре. Одни требуют значительных вычислительных ресурсов. Другие сильно зависят от производительности хранилища, поскольку постоянно извлекают большие наборы данных. Некоторые ограничены пропускной способностью сети, тогда как другие могут погибнуть из‑за задержек, потому что каждая миллисекунда влияет на опыт клиента.

Есть и практическая реальность. Инфраструктура, для которой модель была спроектирована, не всегда доступна в момент развертывания. Доступность оборудования, длительные сроки поставки или дедлайны могут заставить организации использовать другие GPU, ускорители или конфигурации, чем планировалось. Это может потребовать переоптимизации модели или даже её перепроектирования под доступное оборудование.

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

Бизнес‑требования добавляют ещё один слой. Как быстро приложению понадобится масштабироваться? Какие эксплуатационные расходы являются устойчивыми? Какой уровень доступности требуется бизнесу? Сколько сложности организация может реально управлять? На каждый из этих вопросов каждый клиент даст свой ответ. Поэтому нет «универсальной» инфраструктуры ИИ.

Организации, начинающие с предпочтительного облака, аппаратной платформы или поставщика, не попадают в цель с инфраструктурой ИИ. Лидеры начинают с нагрузки и проектируют архитектуру вокруг бизнес‑цели.

Тренировка привлекает внимание. Инференс доставляет бизнес‑ценность.

Очарованность отрасли тренировкой — ещё одна причина, по которой разговоры об инфраструктуре ИИ могут идти в неверном направлении.

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

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

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

Клиенту всё равно, насколько мощный базовый GPU, если чат‑бот отвечает пять секунд. Звонящему всё равно, какие характеристики кластера ИИ, если голосовой помощник постоянно неправильно понимает запросы или задерживается в разговоре. Они просто знают, что приложение работает плохо.

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

Цель большинства клиентов MSP — не построить крупнейший в мире кластер GPU. Цель — быстро, надёжно, безопасно и экономично вывести ИИ‑приложения в продакшн.

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

Возможно, GPU не является вашим узким местом

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

«Сколько GPU нам нужно?» — не тот вопрос, который мы должны задавать; правильнее спросить «Что замедлит это приложение через шесть месяцев?»

Ответ может находиться в другом месте архитектуры.

Хранилище — хороший пример. ИИ‑нагрузки потребляют огромные объёмы данных, и эти наборы растут со временем. Даже чрезвычайно мощный GPU может терять ценное время, ожидая, если хранилище не может быстро предоставить информацию. Эти данные также необходимо защищать, резервировать, сохранять, обеспечивать их безопасность и управлять их жизненным циклом.

Не менее важна сеть. Пропускная способность, задержка, трафик «восток‑запад», а также взаимодействие между кластерами ИИ влияют на производительность приложения. Хорошо спроектированная вычислительная среда не сможет бесконечно компенсировать плохо спроектированную сеть.

Кроме того, безопасность должна быть частью архитектуры с самого начала. Вопросы, которые необходимо решить до продакшна, включают: где находятся конфиденциальные данные, как сегментированы сети, используют ли нагрузки частные или публичные соединения, и как учитываются требования к соответствию и суверенитету.

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

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

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

И существует гравитация данных. По мере роста наборов данных перемещение петабайт информации между локациями просто потому, что вычисления находятся где‑то ещё, становится всё менее эффективным. Во многих случаях перемещение вычислений ближе к данным может быть и практичнее, и дешевле.

Именно поэтому архитектура имеет значение.

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

Организации, получающие наибольшую ценность от ИИ, не обязательно будут теми, у кого самые большие кластеры GPU. Это будут те, кто понимает, как каждый слой инфраструктуры работает вместе.

Это разница между покупкой инфраструктуры и её проектированием.

Рамки планирования, ориентированные на рабочую нагрузку

У MSP есть возможность изменить разговор об инфраструктуре.

Вместо того чтобы начинать с:

• Какой GPU?
• Какое облако?
• Какой поставщик?

Начните с нагрузки:

• Какую бизнес‑проблему мы решаем?
• Является ли это нагрузкой обучения или инференса?
• Какую задержку может выдержать приложение?
• Где находятся данные и как быстро они будут расти?
• Какие требования к безопасности, соответствию и суверенитету применимы?
• Как будет масштабироваться нагрузка?
• Какой уровень доступности требуется бизнесу?
• Какой уровень операционного риска приемлем?
• Сколько будет стоить эксплуатация этой среды по мере роста нагрузки?

Ответы должны определять архитектуру. Не наоборот.

Возможность для MSP

Этот сдвиг меняет роль MSP.

Клиентам не нужен ещё один партнёр, способный продавать им инфраструктуру. Нужен партнёр, способный помочь им принимать более грамотные решения об инфраструктуре.

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

Таким образом, вы можете контролировать расходы, повышать производительность и выявлять операционные и безопасностные риски до того, как приложения попадут в продакшн.

Также появляется более выгодная бизнес‑модель для MSP.

MSP могут строить более ценные рекуррентные сервисы вокруг архитектуры, развертывания, оптимизации, безопасности, управления жизненным циклом, планирования ёмкости и непрерывного улучшения — вместо того чтобы конкурировать в основном за счёт сужения маржи оборудования.

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

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

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

Они станут теми людьми, которым клиенты доверяют при выборе реальной необходимой им инфраструктуры.