Ловушка вывода: как поставщики облачных услуг съедают вашу маржу ИИ

Эта статья является частью специального выпуска VentureBeat «Реальная стоимость ИИ: производительность, эффективность и окупаемость инвестиций в масштабе». Подробнее читайте в этом специальном выпуске.

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

Однако по мере того, как эти проекты переходят из стадии пилота в стадию производства, команды сталкиваются с препятствием, которое они не планировали: расходы на облако подрывают их маржу. Шок от ценника настолько силен, что то, что когда-то казалось самым быстрым путем к инновациям и конкурентному преимуществу, становится неустойчивой бюджетной черной дырой — и это происходит в мгновение ока.

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

Но вот факт: хотя облако может поднять расходы до невыносимых уровней, оно не злодей. Вам просто нужно понять, какой тип транспортного средства (инфраструктура ИИ) выбрать, чтобы пойти по какой дороге (рабочая нагрузка).

История облака — и где это работает

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

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

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

«Вы создаете учетную запись, нажимаете несколько кнопок и получаете доступ к серверам. Если вам нужен другой размер графического процессора, вы выключаете и перезапускаете экземпляр с новыми характеристиками, что занимает несколько минут. Если вы хотите запустить два эксперимента одновременно, вы инициализируете два отдельных экземпляра. На ранних этапах основное внимание уделяется быстрой проверке идей. Использование встроенных фреймворков масштабирования и экспериментирования, предоставляемых большинством облачных платформ, помогает сократить время между этапами», — рассказал VentureBeat Рохан Сарин, который руководит голосовым продуктом AI в Speechmatics .

Хотя облако имеет смысл для использования на ранней стадии, математика инфраструктуры становится мрачной, когда проект переходит от тестирования и проверки к реальным объемам. Масштаб рабочих нагрузок делает счета жестокими — настолько, что расходы могут вырасти более чем на 1000% за одну ночь.

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

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

Кристиан Хури, генеральный директор платформы EasyAudit AI для проверки соответствия требованиям ИИ, назвал логические выводы новым «облачным налогом» и рассказал VentureBeat, что видел, как компании за одну ночь увеличивали свои доходы с 5 до 50 тыс. долларов в месяц только за счет трафика логических выводов.

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

Обучение этих моделей, со своей стороны, происходит «взрывным» (происходит в кластерах), что оставляет некоторое пространство для планирования мощности. Однако даже в этих случаях, особенно с учетом того, что растущая конкуренция заставляет часто переобучаться, предприятия могут иметь огромные счета за время простоя GPU, вытекающие из избыточного выделения ресурсов.

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

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

«Это не просто стоимость вычислений. Вы получаете… непредсказуемое автомасштабирование и безумные сборы за выход, если вы перемещаете данные между регионами или поставщиками. Одна команда платила больше за перемещение данных, чем за обучение своих моделей», — подчеркнул Сарин.

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

Это не просто теория — это растущее движение среди руководителей инженерных компаний, пытающихся внедрить ИИ в производство, не прожигая время.

«Мы помогли командам перейти на размещение для вывода с использованием выделенных серверов GPU, которые они контролируют. Это не круто, но это сокращает ежемесячные расходы на инфраструктуру на 60–80%», — добавил Хури. «Гибрид не просто дешевле — он умнее».

В одном случае, сказал он, компания SaaS сократила свой ежемесячный счет за инфраструктуру ИИ с примерно $42 000 до всего $9 000, переместив рабочие нагрузки вывода из облака. Переход окупился менее чем за две недели.

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

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

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

Другой большой бонус — предсказуемость.

С помощью стеков on-prem или colocation команды также имеют полный контроль над количеством ресурсов, которые они хотят предоставить или добавить для ожидаемого базового уровня рабочих нагрузок вывода. Это обеспечивает предсказуемость расходов на инфраструктуру — и устраняет неожиданные счета. Это также снижает агрессивные инженерные усилия по настройке масштабирования и удерживает расходы на облачную инфраструктуру в разумных пределах.

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

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

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

«Наши расчеты показывают, что локальный сервер GPU стоит примерно столько же, сколько шесть-девять месяцев аренды эквивалентного экземпляра из AWS, Azure или Google Cloud, даже с годовой зарезервированной ставкой. Поскольку оборудование обычно служит не менее трех лет, а часто и более пяти, это становится положительным по затратам в течение первых девяти месяцев. Некоторые поставщики оборудования также предлагают операционные модели ценообразования для капитальной инфраструктуры, поэтому вы можете избежать авансового платежа, если вас беспокоит денежный поток», — пояснил Сарин.

Для любой компании, будь то стартап или предприятие, ключ к успеху при проектировании (или перепроектировании) инфраструктуры ИИ заключается в работе в соответствии с конкретными текущими рабочими нагрузками.

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

При этом помните, что речь идет не о полном отказе от облака, а об оптимизации его использования для максимального повышения эффективности.

«Облако по-прежнему отлично подходит для экспериментов и интенсивного обучения. Но если вывод — ваша основная рабочая нагрузка, откажитесь от арендной беговой дорожки. Гибрид не просто дешевле... Он умнее», — добавил Хури. «Относитесь к облаку как к прототипу, а не как к постоянному дому. Ведите расчеты. Поговорите со своими инженерами. Облако никогда не скажет вам, когда оно не подходит. Но ваш счет за AWS скажет».