Скрытый счет ИИ за хранение данных: что оставляет после себя инференс
Попросите большинство руководителей представить себе стоимость ИИ, и, скорее всего, они увидят графические процессоры — стойки с ускорителями, потребляющие гигаватты энергии, — и очередь на поставку кремниевых компонентов. Но в этой картине кое-чего не хватает: затрат на хранение данных.
Что происходит с данными после того, как модель формирует ответ? Значительную часть генерируемых серверных данных — от миллиардов ежедневных запросов до изображений и видео — необходимо хранить. Однако затраты на хранение данных относятся к числу наиболее сложных для планирования инфраструктурных расходов, и ими часто пренебрегают при первоначальном планировании ИИ-инфраструктуры.
По мере масштабирования инференса растет и объем данных
Традиционно обсуждение ИИ-инфраструктуры было сосредоточено на ресурсоемком процессе обучения модели. Обучение ограничено во времени: запуск начинается, потребляет вычислительные ресурсы и завершается. Инференс же выполняется непрерывно — каждый раз, когда модель отвечает на запрос. Для планирования инфраструктуры это различие имеет значение: запуск обучения — это проект, бюджет которого можно спланировать и после завершения свернуть. Инференс не завершается: после каждого запроса остается какой-либо объем данных.
Рассмотрим генерацию видео с помощью ИИ. В рамках такой нагрузки затраты на серверную часть могут быть значительными. На основании внутренних измерений WD установила, что 8-секундный ролик (который пользователь получает в виде файла 720p размером 3,97 МБ) оставляет на серверной стороне более 500 МБ связанных данных, включая журналы, кэшированный контекст, промежуточные результаты рендеринга, резервные копии и записи, связанные с безопасностью. Это в 130 раз больше размера выходного файла, который видит пользователь. При масштабировании до уровня предприятия, генерирующего более длинные видео в более высоком разрешении, объем серверных данных вырастает до сотен гигабайт на один ролик.
И этот объем быстро растет. McKinsey прогнозирует, что спрос на инференс будет расти среднегодовыми темпами 35% до 2030 года по сравнению с 22% для обучения, и к концу десятилетия на него будет приходиться более 40% общего спроса на мощности дата-центров.
В недавнем глобальном исследовании IDC, проведенном при поддержке WD, в котором приняли участие 763 руководителя, принимающих решения в сфере ИТ и бизнеса, почти 95% респондентов сообщили об увеличении объема данных из-за генеративного ИИ за последние 12 месяцев, причем около 61% указали на рост на 25% и более.
«Можно считать увеличение объема хранилища оптимизацией, позволяющей поддерживать загрузку графических процессоров», — сказал старший менеджер по продукту поставщика гипермасштабируемых облачных сервисов, цитируемый в отчете. «Главная задача — не допустить простоя графических процессоров в ожидании данных: простой графического процессора на протяжении нескольких часов очень быстро становится чрезвычайно дорогим». Если выразить это в денежных терминах: если расходы на хранение растут на 25% в год, тогда как бюджет на вычислительные ресурсы увеличивается более предсказуемыми циклическими темпами, затраты на хранение в итоге опережают наиболее внимательно отслеживаемую бюджетную статью.
Адаптация хранения к жизненному циклу данных ИИ
Спрос на вычислительные ресурсы растет и снижается в зависимости от циклов обучения, запуска продуктов и обновления оборудования. Но объем сохраняемых данных не уменьшается вместе с ним, когда спрос на вычисления замедляется. Журналы моделей, синтетические результаты, результаты инференса и другие данные продолжают накапливаться, причем организации хранят все больше данных в течение все более длительного времени.
Это меняет роль сохраняемых данных. Информация, которая раньше перемещалась в архив и редко использовалась, теперь может стать источником данных для будущих ИИ-нагрузок. По мере того как все больше данных сохраняется, извлекается и используется повторно, системы хранения должны обеспечивать не только растущую емкость, но и все более динамичный доступ к данным. То же исследование WD и IDC показало, что 96% респондентов ожидают необходимости более быстрого извлечения данных из архивов для поддержки инференса или генерации с дополненным поиском (RAG).
ИИ-нагрузки требуют одновременно производительности и емкости, причем разные технологии подходят для разных этапов жизненного цикла данных. А для огромных объемов данных, которые необходимо хранить и к которым нужно возвращаться, жесткие диски обеспечивают экономичную основу высокой емкости, предлагая значительное преимущество по стоимости терабайта
Что это означает для планирования бюджета на ИИ
Для финансового или ИТ-директора это означает, что «расходы на ИИ-инфраструктуру» могут быть определены слишком узко — с акцентом на вычислительные ресурсы. Модель, простаивающая во время загрузки данных, обходится примерно так же дорого, как модель, простаивающая из-за отсутствия графического процессора. Но узкое место в системе хранения остается незаметным до тех пор, пока не превращается в проблему, проявляясь в операционных расходах и задержках при извлечении данных, а не в отдельной капитальной статье рядом с ускорителями.
Представьте себе розничную компанию, которая создает видеоролики о товарах с помощью ИИ для своего каталога, или страховую компанию, которая обрабатывает документы по страховым случаям через конвейер RAG для ускорения андеррайтинга. В обоих случаях стоимость вычислений известна и заложена в бюджет: это ставка за генерацию или запрос, которую финансовый отдел может спрогнозировать. Стоимость хранения устроена иначе: она накапливается с каждым созданным видео и каждым обработанным страховым случаем, поскольку ни один из этих серверных наборов данных не исчезает после завершения задачи.
Команда, планирующая бюджет на ИИ по принципу «вычисления плюс незначительная поправка на хранение», через 12–18 месяцев может обнаружить, что эта поправка превратилась в существенную долю общей стоимости программы — как раз в тот момент, когда руководство решает, стоит ли ее расширять.
Создание экономически масштабируемой емкости
Решение этой проблемы начинается с архитектуры. Стратегия хранения обычно разрабатывается с расчетом на дорогую производительность горячего уровня (для данных, к которым обращаются мгновенно и постоянно), тогда как основная часть ИИ-данных по объему накапливается на расположенных ниже уровнях — теплом, прохладном и холодном.
Предприятиям нужна экономически масштабируемая емкость: инфраструктура, рассчитанная на весь жизненный цикл данных ИИ и обеспечивающая баланс между производительностью, емкостью, энергопотреблением, надежностью и совокупной стоимостью владения по мере того, как данные сохраняются, накапливаются и все чаще используются повторно. Это означает, что архивы, которые раньше оставались нетронутыми, следует рассматривать как активы, используемые для RAG и инференса, а политики хранения — формировать с учетом растущей стратегической ценности данных, а не их первоначальной стоимости хранения. Это также означает признание того, что решения в отношении хранения реализуются на уровне всего парка оборудования, а не отдельных накопителей.
Такая инфраструктура требует уровней хранения, где индивидуальные показатели энергопотребления, надежности, плотности и операционной эффективности определяют, сохранит ли система экономическую устойчивость при масштабировании емкости.
О бюджете вашей организации на ИИ-инфраструктуру следует задать три вопроса:
- Какова наша политика хранения контента, созданного ИИ, и кто ее установил?
- Привязана ли закупка систем хранения к требованиям производительности на этапе обучения или к фактическому жизненному циклу создаваемых нами данных?
- Если в следующем году использование ИИ удвоится, удвоятся ли вместе с ним расходы на хранение — или вырастут еще сильнее?
Большинство организаций не может уверенно ответить на все три вопроса. Именно этот пробел стоит устранить до следующего бюджетного цикла, а не после него.
Этот материал подготовлен компанией WD. Он не был написан редакцией MIT Technology Review.
Переведено автоматически с английского. Оригинал статьи — по ссылке ниже.