«Без копирования петабайтов»: AWS и Qumulo показали обучение HyperPod на данных из другого региона

Развилка, из которой растёт задача

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

В посте от 25 сентября AWS описывает третий путь: связка Amazon SageMaker HyperPod с Cloud Native Qumulo (CNQ) и Qumulo Cloud Data Fabric (CDF) позволяет обучающим заданиям читать датасет из другого региона или из собственного дата-центра без копирования данных, без изменения кода и без потери пропускной способности.

Архитектура: хаб, spoke и VPC peering

Схема строится на единственном источнике правды: датасет хранится в одном регионе в CNQ, и он же называется хабом. Каждый кластер HyperPod монтирует локальный экземпляр CNQ по Network File System (NFS), а spoke-кластер забирает данные из хаба через Virtual Private Cloud (VPC) peering, поэтому полный датасет доступен вычислительным узлам без обращения между регионами.

В spoke-регионе задания отправляются через оркестратор Amazon Elastic Kubernetes Service (Amazon EKS) и выполняются на узлах HyperPod, которые монтируют локальный CNQ spoke по NFS. Ключевая деталь в том, что путь монтирования в обоих регионах одинаков: узлы читают данные по одному и тому же локальному пути, хотя физически копия одна и лежит в другом регионе.

Трафик VPC peering между регионами AWS шифруется при передаче, а группы безопасности на инстансах Qumulo и HyperPod по инструкции должны пропускать только NFS-порт TCP 2049.

NeuralCache: прогноз чтений вместо репликации

Поведение чтений определяет слой Qumulo Cloud Data Fabric. CDF держит единственную авторитетную копию датасета на хабе и проецирует её на spoke-кластеры как единое POSIX-пространство имён. Когда создаётся spoke, CDF реплицирует на него метаданные файловой системы, поэтому пространство имён становится доступным для просмотра за секунды — задолго до того, как переместились сами данные; при монтировании каждое чтение обслуживается из ближайшего валидного источника: локального NVMe-кэша при попадании и хаба при промахе.

Прогнозирующий слой NeuralCache наблюдает последовательные чтения блоками по 4 КБ, которые выдаёт загрузчик данных, и учится распознавать шаблон доступа. Вместо того чтобы ждать запроса, он размещает данные заранее: в первых 100–150 батчах модель учится предсказывать, какие блоки понадобятся следующими, и предзагружает их с хаба в локальный NVMe на spoke; после прогрева 94–96 % чтений обслуживаются из локального кэша с задержкой меньше 5 мс.

Отдельно описано управление перегрузкой: CDF выравнивает темп по измеренной пропускной способности узкого места и времени кругового распространения, а не отступает при потерях пакетов — именно это удерживает длинный канал заполненным там, где алгоритмы на основе потерь проседают. По утверждению AWS, CDF сохраняет почти линейную скорость на маршрутах с RTT до 900 мс.

Цифры проверочного прогона

Проверка построена на одном и том же задании: LLaMA v3 на 1,02 млрд параметров, по два инстанса ml.p5.48xlarge на каждый кластер SageMaker HyperPod, всего 16 GPU H100. Хаб работал в регионе US East (Огайо, us-east-2) рядом с данными и показывал 116–117 samples/sec, проходя 999 батчей за 18,5 минуты.

Spoke-кластер в регионе US West (Орегон, us-west-2) читал те же данные удалённо через CDF с сетевой задержкой 60 мс. С прогретым кэшем он показал 115–116 samples/sec и те же 18,5 минуты до 999 батчей. На холодном старте в худшем случае без предыдущих прогонов скорость составляла 95–105 samples/sec в первых 100–150 батчах и затем сходилась к уровню хаба — 116 samples/sec, а полное время до 999 батчей растягивалось примерно до 19–20 минут.

Масштаб разогрева авторы подчёркивают отдельно: батчи 0–150 идут на 15–20 % медленнее, пока NeuralCache прогревается, после чего производительность сходится к уровню хаба в пределах первой эпохи. Разовые издержки признаны пренебрежимыми в масштабе: меньше 1 % общего времени при 10 000+ батчах и меньше 0,1 % — при более чем 100 000. По утилизации GPU картина такая: 80–90 % в начальной фазе на 100–150 батчах и затем 98–100 %.

Хаб-конфигурация дала 1,0–1,3 ГБ/с устойчивого чтения с насыщением 10-гигабитного сетевого канала при максимальной задержке чтения 2–3 мс. AWS объясняет это тем, что облачная архитектура CNQ масштабирует производительность по размеру кластера, а не по размеру датасета, — поэтому кластер из четырёх узлов способен насытить канал, питающий GPU.

Что нужно, чтобы повторить

Предварительные условия описаны без обтекаемости: аккаунт AWS с включённым SageMaker HyperPod, развёрнутый Qumulo Cloud Native в основном регионе us-east-2, квота на инстансы ml.p5.48xlarge — по два на кластер, настроенный VPC peering между регионами хаба и spoke, а также базовое знакомство с PyTorch и концепциями распределённого обучения.

Развёртывание хаба идёт из AWS Marketplace: Qumulo Cloud Native ставится в us-east-2, шаблон AWS CloudFormation лежит в бакете Amazon S3 с файлами развёртывания по пути templates/cnq-standard.template.yaml, а стек создаётся на инстансах r5.8xlarge кластером из четырёх узлов в существующем VPC. Затем создаётся пиринговое соединение между VPC хаба и spoke, соединение принимается в парном регионе и таблицы маршрутов в обоих регионах направляют CIDR каждой VPC в peering — только после этого инстансы HyperPod в spoke-регионе получают доступ к данным хаба через свой локальный NFS-моунт.

Что это меняет

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

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

Общая рамка тоже обозначена: HyperPod позиционируется как управляемая инфраструктура для распределённого обучения с автоматическими проверками состояния, заменой узлов и восстановлением из чекпойнтов, а на собственном сайте AWS заявляет до 95 % training goodput на кластерах с тысячами ускорителей против типичных 60–80 % на самоуправляемых кластерах.

Границы проверки при этом стоит держать в голове: результаты получены на одном задании с 16 GPU H100 и задержке 60 мс, а утверждение о сохранении почти линейной скорости на маршрутах с RTT до 900 мс относится к описанию CDF и не проверялось в этом прогоне.