Даже 70% загрузки GPU в панели мониторинга не означают, что кластер работает на пределе. В спонсорском материале The Register о платформе Hammerspace разбирают неприятный для инфраструктурных команд факт: ускорители по цене около $40 тыс. могут простаивать не из-за нехватки вычислений, а потому, что нужный файл лежит в старом NAS в нескольких сетевых переходах. Для российского рынка вывод приземленный: купить GPU мало, если данные по-прежнему разбросаны по файловым шарам, объектным хранилищам и локальным дискам.
Главная мысль текста проста: узкое место в ИИ-инфраструктуре сместилось с объема хранения на размещение данных и маршруты доступа к ним. Вопрос уже не в том, сколько терабайт закуплено, а в том, где лежат наборы данных, как они попадают к ускорителям и сколько лишних копирований происходит по дороге.
Проблема в разрозненных данных, а не в емкости
The Register со ссылкой на Hammerspace пишет, что корпоративные наборы данных редко бывают готовыми к обучению моделей. Обычно их приходится собирать из разных подразделений, площадок и облаков, затем переносить между системами и дополнительно подготавливать. Такая работа плохо видна по привычным метрикам хранения, зато быстро бьет по скорости обучения и по реальной загрузке дорогих GPU.
В тексте приводят и внешнюю оценку: по данным Gartner, 57% организаций считают свои данные неготовыми для сценариев ИИ. Для компаний из России и СНГ это знакомая история: пилот модели запускают быстро, а затем выясняется, что данные живут в нескольких контурах, права доступа собраны вручную, а между командами уже вырос собственный зоопарк NAS, S3-совместимых систем и локальных архивов.
Отсюда и неприятный вывод для CIO, CTO и MLOps-команд. Идея «выкинуть старое хранилище и купить новый стек под ИИ» выглядит красиво только на слайде. На практике самые ценные данные часто остаются именно в старых системах, которые нельзя просто отключить без риска для бизнеса.
Локальные NVMe в GPU-серверах стали отдельным ресурсом
Отдельный акцент в материале сделан на NVMe-накопителях внутри самих GPU-серверов. По оценке Hammerspace, современный сервер класса HGX или DGX обычно получает от 8 до 16 NVMe-накопителей, каждый подключен по четырем линиям PCIe. Чаще всего эту емкость используют как локальный временный слой для одного узла, хотя по факту речь уже идет о сотнях терабайт на сервер, а в планах рынка фигурируют и конфигурации до 2 ПБ.
Логика Hammerspace в том, чтобы превратить эту «застрявшую» емкость в общий быстрый уровень хранения. Аргумент не только в скорости, но и в экономике: накопители уже входят в состав GPU-сервера, сеть уже куплена, а значит новый слой можно собрать без отдельного цикла закупки под массив all-flash. Для компаний, которые считают полную стоимость ИИ-кластера, это, пожалуй, самый практичный тезис во всем материале.
Hammerspace предлагает единое пространство имен поверх разных систем
Технически компания описывает свой подход как слой между вычислительными узлами и уже существующими хранилищами: NAS, объектными системами и локальными NVMe. Данные получают единое глобальное пространство имен, а доступ к ним идет по стандартным протоколам NFS, SMB и S3. Идея в том, чтобы не переписывать приложения и не гонять байты между системами без необходимости.
Сценарий внедрения Hammerspace называет assimilation: система сканирует существующий NAS, импортирует дерево каталогов в глобальное пространство имен и перенаправляет точки монтирования. По версии компании, сами данные при этом не переезжают, а источником истины остаются исходные массивы, например NetApp, Qumulo или VAST. Если архивный файл внезапно становится «горячим» для обучения, политика может поднять его копию на быстрый уровень автоматически, а после завершения задания убрать ее, чтобы не забивать быстрый слой.
Здесь стоит сделать редакторскую оговорку. Почти все сильные цифры в тексте исходят либо от самой Hammerspace, либо из материалов с ее участием. Компания ссылается на попадание в топ-10 бенчмарка IO500 10-Node Production в ноябре 2025 года и на собственные результаты в MLPerf Storage v2.0: масштабирование до 420,8 ГБ/с на 140 GPU в пяти узлах при загрузке GPU выше 96%. Это звучит убедительно, но рынку все равно нужны независимые сравнения с Weka, VAST, NetApp и другими игроками в разнородных клиентских средах.
Значение для рынка
Для российских и СНГ-команд смысл новости простой: следующая проблема после закупки GPU почти наверняка окажется не в самих ускорителях, а в данных. Если компания строит внутренние сервисы RAG, контуры вывода или обучение на корпоративных наборах, ей придется решать вопрос единого доступа, политики размещения и автоматического перемещения данных между уровнями хранения. Иначе кластер за миллионы рублей будет отлично считать только паузы между чтением файлов.
Дальше рынок, вероятно, сместит разговор с «сколько GPU докупить» к более скучной, но куда более полезной теме: как сократить лишние копирования и дать ускорителям доступ к данным без ручной сборки маршрутов. Оригинал материала — .