Компании массово заявляют об ИИ-стратегиях, но спрос на ИИ-инфраструктуру растёт быстрее, чем складываются ориентиры, как её строить. Генеральный директор mt cloud Тимур Чубарин рассказывает, с какими запросами приходят клиенты, как отличить зрелого провайдера от того, кто просто поставил видеокарты в стойку, и почему за разросшимся счётом за GPU-кластер чаще стоит не инфраструктура, а неправильно посчитанная задача.
Чего на самом деле хотят клиенты
Заказчики, которые приходят за GPU-мощностями, в действительности приходят не за кластером. У каждого свой прикладной запрос, наложенный на возможности ИИ: кто-то решает проблему в бизнес-процессе, кто-то делает свой сервис умнее за счёт накопленных данных, кто-то автоматизирует рутину, кто-то выводит на рынок собственный продукт. Но по тому, как клиент заходит в технологию, все они делятся на два типа: те, кто пробует и проверяет гипотезу, и те, кто после успешного пилота выходят в промышленную эксплуатацию.
Первым нужно «пощупать» технологию. Они берут карты на короткий срок и небольшие объёмы, часто на волне интереса к ИИ в отрасли, когда конкуренты заявляют о преимуществах внедрения. GPU-серверы стоят дорого, а уверенности, что технология сработает в их задаче, пока нет: нагрузка скачет, профиль меняется, бизнес-эффект не доказан, решение об инвестициях не принято, а значит, капзатраты на этой стадии иррациональны. Поэтому таким клиентам важна разумная точка входа — проверить гипотезу на чужом железе, с минимальными издержками, и понять, нужно это бизнесу или нет. Технически это почасовая аренда, недорогие карты, простой self-service.
За экспериментом почти всегда стоит конкретная проблема в существующем процессе. В отделе продаж обзванивают лиды, но конверсия низкая — нужно понять, на каком шаге теряется клиент. В техподдержке копятся плохие отзывы — нужно найти, где ломается клиентский опыт. Справочную службу хотят разгрузить ассистентом, который сам ищет ответы по внутренней базе знаний. Голосовому помощнику нужно слышать раздражение в голосе, чтобы вовремя передать разговор оператору. Общее у этих задач в желании улучшить то, что уже работает.
Вторые уже прошли пилот: технология подтвердилась, и теперь нужны стабильные мощности под нагрузку: зарезервированные карты, SLA, предсказуемая стоимость, поддержка, иногда выделенные хосты и кастомные конфигурации. У них решение уже принято, поэтому им важна не проба, а надежность и предсказуемость на длинной дистанции.
Типичный путь выглядит так. Гипотезу клиент проверяет на чужом железе, покупать сервер ради теста, конечно, дорого и рискованно. Если гипотеза подтвердилась и эффект есть, часть заказчиков задумывается о собственном контуре. Логика понятная: при стабильной и высокой загрузке владеть железом на длинной дистанции дешевле, чем арендовать.
При этом, так как провайдеры сегодня не просто сдают серверы, а добавляют поверх то, что клиенту трудно или невыгодно повторить у себя, аренда с сервисами сегодня востребована. Это удобный выбор моделей через интерфейс. Это учёт расходов, привязанный к реальному потреблению, — по токенам для инференса или по GPU-часам для аренды карт: нагрузка скакнула вверх — заплатил больше, упала — меньше, без риска переплатить за простой. Принцип клиентам уже привычен по зарубежным API. Наконец, это снятая головная боль bare metal: собственное железо требует редких профильных команд и развития непрофильных компетенций. И в том числе когда инвестиции в свою инфраструктуру не оправданы, а работу с ИИ нужно налаживать уже сейчас, аренда с сервисами поверх остаётся рациональным выбором.
Что отличает зрелого провайдера от того, кто просто поставил видеокарты в стойку
Сама по себе аренда GPU в облаке, даже в базовом пакете, уже снимает с клиента обслуживание железа. Это базовая ценность облачной аренды, и её даёт практически любой игрок на рынке.
А дальше начинается развилка. Провайдеры расходятся по зрелости и набору возможностей. Одни ограничиваются тем, что ставят сервер и сдают его в аренду. Это арендодатели железа. Другие добавляют сервис: настройку, сопровождение, интеграцию, и работают уже как инфраструктурный партнёр. Оба варианта оправданы: аренда голого железа не плоха сама по себе, но требует от заказчика высокой собственной экспертизы, подходит компаниям, которые уже хорошо продвинулись в ИИ, им не нужен дополнительный сервис, им нужны дешевые ресурсы. А компаниям, которые только начинают путь в ИИ или сознательно решают не вкладываться в капитальные затраты и не растить непрофильные компетенции, нужен зрелый провайдер. И здесь стоит разобраться, что это вообще значит.
Первый признак, инженерная инфраструктура. Выдать клиенту GPU это 10% работы. Остальные 90% это инженерная обвязка вокруг карт. На уровне железа клиенту может выделяться целая карта, её часть или несколько карт, объединенных в один контур и работающих совместно. Поверх лежит технологический слой: драйверы и их совместимость с моделями, виртуализация для нарезки ресурса, оркестрация для масштабирования и автоскейлинга, мониторинг загрузки, серверы инференса. На этот слой стоит внимательно смотреть, оценивая провайдера.
Второй признак, уровень сопровождения. Любая бизнес-задача с ИИ — это интеграция: у клиента есть своя система, CRM, ERP, биллинг, сайт, мобильное приложение, и в один из её процессов нужно встроить нейросеть через API. Чтобы это заработало, нужно проделать большой объём работы: настроить авторизацию, разобрать ошибки интеграции, объяснить лимиты и тайм-ауты, оптимизировать запросы. Обычно эту работу выполняет заказчик. Но если заказчику нужна помощь, зрелый провайдер может дать надёжных партнёров, которые эту задачу закроют.
Третий признак, безопасность и работа с регуляторикой. Для финансов, госсектора, здравоохранения критично, чтобы данные не выходили за периметр. Зрелый провайдер умеет это обеспечить: изоляция арендаторов при использовани карт, размещение в аттестованных ЦОДах, соответствие отраслевым требованиям.
Понять, насколько провайдер это все умеет, до подписания договора вполне возможно.
Инженерную обвязку выдаёт структура тарификации. Проверять стоит не цену, а то, как устроен счёт: сам факт наличия прайса не говорит ни о чём, он есть у всех, а вот умение биллить по реальному потреблению — по токенам для инференса, по GPU-часам для аренды, с шерингом по времени — это сигнал, что под капотом есть та самая виртуализация, учёт и оркестрация из «90%». Плоский тариф «карта в месяц» чаще выдаёт арендодателя железа. О том же говорит наличие собственной платформы для работы с моделями: она превращает разрозненный доступ к картам в управляемый сервис.
Сопровождение и компетенции проверяются через людей и опыт. Самое базовое — референс-кейсы именно в GPU и ИИ-инфраструктуре. Также стоит узнать, кто со стороны провайдера отвечает за ИИ-направление, и вложить время в общение с командой, самое результативное в формате технического интервью. Это быстро показывает реальный уровень и заодно насколько удобно с ними будет работать. Если уже здесь что-то не складывается, дальше будет только сложнее.
Безопасность проверяются предметно: по аттестациям ЦОДов и отраслевым сертификатам.
Как не дать кластеру съесть бюджет
В ИИ-проектах деньги чаще всего теряются не там, где ищут потери. Кажется, что виновата инфраструктура: разросся счёт, значит, что-то не так с кластером. На деле кластер съедает бюджет в трёх типичных ситуациях, и самый дорогой просчёт случается ещё до закупки.
Первая ситуация, покупка кластера под задачу, которая того не стоит. Прежде чем вкладываться в оборудование, а сервер для GPU-кластера может стоить до
Вторая ситуация, дать кластеру простаивать. GPU-кластер не работает бесплатно, когда нет задач: счёт приходит каждый месяц независимо от загрузки. Защита от этого — модель оплаты по факту: по токенам или по времени, пользуешься — платишь, простаивает — нет. Тогда счёт следует за реальным потреблением, а не за самим фактом владения железом.
Третья, не понять заранее, как изменится потребление. Это сложность уже не техническая, а управленческая. Типичная история обратна ожидаемой: заказчик приходит за небольшим объёмом, начинает работать — и дальше нужно всё больше. Причём рост этот часто закономерный, а не стихийный. Например, когда разработчики переходят на ИИ-ассистированную разработку, узкое место смещается. Раньше DevOps несколько дней настраивал окружение, а потом разработчики месяцами писали код. Теперь первый рабочий вариант собирается несравнимо быстрее — но за ним идёт длинный хвост: ревью, отладка сгенерированного, проверка на безопасность. Нагрузка на мощности не схлопывается в короткий спринт, а наоборот становится плотной и постоянной. Каждый отдельный прогон теперь быстрый и недорогой, поэтому их запускают часто, итераций становится больше, и суммарное потребление только растёт. Поэтому, внедряя подобные изменения, потребление нужно считать наперёд, оно вырастет не разово, а вдолгую.
Получается, разросшийся счёт почти всегда можно предвидеть заранее, ещё на этапе проработки перед закупкой.
Когда провайдер должен сам предложить расширение
Жёсткого норматива одной пороговой цифры по загрузке нет. Карта может показывать 90% и при этом простаивать по сути: упираться в память, голодая по вычислениям. Разовый ночной тренировочный прогон тоже даст красивый пик, который завтра не повторится. Строить решение о закупке железа правильнее, ориентируясь на тренд: если базовая линия загрузки из недели в неделю ползёт вверх, клиент действительно перерастает выделенную ёмкость. Это уже структурный спрос, который железом придётся закрывать. Условно, практический порог для разговора — устойчивые
На практике, впрочем, инициатива чаще исходит от самой команды клиента. Если ресурсы распределены по токенам и инженеры выбирают весь лимит уже к середине рабочего дня, команда приходит за расширением сама, раньше, чем тему успеет поднять кто-либо ещё.
Но как только решение расширяться принято, неважно, провайдер его инициировал или клиент, начинается более тонкая часть. Реакция по умолчанию — просто добавить карт. Однако нужно учитывать, что масштабирование нелинейно, и удвоенное железо — не гарантия удвоенной отдачи. Этот вопрос нужно прорабатывать внимательно.
Отдача определяется не числом карт, а тем, насколько карта соответствует задаче. Одна задача упирается в объём видеопамяти — модель просто не помещается. Другая — в скорость вычислений. Третья — в то, как быстро данные движутся внутри карты. Если долить карт с упором на память, а узкое место было в скорости, прирост окажется нулевым: вы расширили не то измерение. Поэтому правильный первый вопрос при расширении — не «сколько добавить», а «во что именно мы упёрлись».
Отдельный вопрос — топология, то есть как эти карты соединить. Если задач много и они независимы, например, поток отдельных запросов на инференс, карты выгоднее разнести: каждая работает сама по себе, общаться им не нужно. Если же задача одна, но большая, и модель не влезает в одну карту, их собирают в кластер: тогда карты работают как единое целое и постоянно обмениваются данными. Можно идеально подобрать тип карты, но ошибиться именно здесь — собрать в кластер то, что стоило разнести, и получить лишние издержки на связь между картами, или наоборот.
Сюда же относится выбор модели: одинаково хорошей для всех задач не существует, и если команда упёрлась в неподходящую модель, никакое железо этого не лечит, мощность здесь не та переменная.
И надо понимать, что расширение нередко оказывается не разовым, а постоянным процессом. Когда дообученную модель внедряют в продукт и пользуются ею шире, включается петля: лучше результат, больше пользователей, больше запросов, выше нагрузка, и снова нужно железо. Рост качества сам разгоняет рост потребления. Но так бывает не всегда: если нагрузка стабильна, если это внутренний инструмент с постоянным кругом пользователей и относительно фиксированным потоком задач, расширение вполне может остаться разовым. Петлю запускает именно рост использования. Поэтому, как только продукт начинает набирать аудиторию, к этому росту нагрузки стоит быть готовым заранее, закладывать расширение как часть плана.
Кто формирует спрос на GPU в России
Запросы на ИИ-инфраструктуру сейчас приходят из всех отраслей, но самый заметный спрос идет от компаний из ИТ-сферы, разработчиков программного обеспечения, финтеха, промышленности, e-com и крупных федеральных сетей с большими ИТ-штатами.
Логика для всех этих отраслей одна. У таких компаний значительный масштаб бизнеса и, как следствие, большие массивы данных, собственный ИТ-штат с командами по работе с данными и машинному обучению, а главное, поток прикладных задач, под которые нужны GPU. У ритейла и e-com это прогноз спроса, рекомендательные системы и оптимизация логистики, у финтеха — скоринг, антифрод и обработка обращений, у ИТ-компаний и разработчиков ПО — обучение и встраивание ИИ в собственные продукты, у промышленности — компьютерное зрение и анализ данных с производства.
Везде это задачи, встроенные в бизнес-процессы, с сильным потенциальным эффектом: оптимизация, рост качества решений и выручки, а также новые возможности, которых без ИИ не было. Поэтому спрос таких игроков и большой, и растущий.
За счёт облачной модели, которая своей доступностью стирает границы входа, спрос подхватывает и средний бизнес.
Что будет с рынком через 2-3 года
Вокруг GPU-инфраструктуры сейчас классический всплеск интереса, и на фоне высокого спроса цены растут, во многом из-за дефицита компонентов, прежде всего памяти, которую производители перенаправляют в чипы для ИИ-дата-центров. В какой-то момент ажиотаж схлынет, и цена нащупает более понятный, устойчивый уровень. Свою границу найдут и сами компании: во многих задачах, особенно там, где труд людей стоит недорого, обнаружится черта, за которой нанимать сотрудников выгоднее, чем автоматизировать процесс.
Крупный бизнес и государственные структуры продолжат активно внедрять ИИ там, где нужно обрабатывать большие массивы данных и множество переменных. Эти игроки получат наибольшую выгоду, потому что у них есть для этого ресурсы и масштаб. Облако снижает порог входа и для компаний поменьше: типовые задачи через готовые API сегодня доступны почти всем. Но там, где нужно обучать модель под себя на собственных данных, преимущество остаётся за крупными: у них есть и данные, и команды, чтобы это вытянуть.
Источник: Тимур Чубарин, генеральный директор mt cloud
