Сколько вы закладываете на обвязку, когда бюджетируете покупку шестнадцати флагманских чипов от NVIDIA? Если ваш ответ крутится вокруг идеи купить карты, воткнуть их в серверы и связать стандартной десятигигабитной корпоративной сетью, вы только что превратили инвестиции в очень дорогой кремниевый обогреватель. Покупать сырые терафлопсы без продуманной инфраструктуры доставки данных — это классическая ошибка, на которой ломается почти каждый свежеиспеченный ИИ-отдел. Иллюзия проста: железо куплено, значит, модели сейчас полетят. Но на практике попытка собрать GPU-кластер с нуля: сеть, хранилище и планировщик, без которых дорогие карты простаивают, обычно игнорируется ради красивой цифры закупленных ускорителей.
В изолированном сервере всё отлично: там правит бал NVLink, обеспечивая колоссальную пропускную способность между чипами. Но современные модели не учатся на одном узле. Распределенное обучение требует синхронизации градиентов между десятками серверов. И вот здесь ваша система выезжает на магистраль и намертво встает в пробку, потому что дешевый интерконнект убивает весь потенциал железа.
GPU-кластер с нуля: сеть, хранилище и планировщик, без которых дорогие карты простаивают
Поговорим про сеть. В распределенном обучении ключевой метрикой является не просто пропускная способность, а latency при операции All-Reduce. Когда узлы обмениваются обновлениями весов, ни один из них не может продолжить работу, пока не получит данные от всех остальных. Ваш кластер работает со скоростью самого медленного сетевого пакета. Традиционный Ethernet с его стеком TCP/IP генерирует чудовищные накладные расходы на уровне ядра операционной системы.
Даже если вы поставите коммутаторы на 100GbE, задержки протокола задушат утилизацию карт. Вам нужен RDMA — прямой доступ к памяти удаленных машин в обход CPU. Здесь у вас два пути: InfiniBand или RoCE. InfiniBand дорог, требует специализированных коммутаторов, кабелей и менеджеров подсетей. Но он работает из коробки с минимальной задержкой. RoCEv2, работающий поверх конвергентного Ethernet, обходится дешевле и использует знакомое сетевое оборудование. Но попытка заставить RoCE стабильно работать под пиковой нагрузкой без потерь пакетов, настраивая Priority Flow Control и ECN — это отдельный вид инженерного мазохизма. Да, Ethernet дешевле на этапе закупки. Но он беспощадно душит multi-node обучение, заставляя H100 простаивать в ожидании данных. Платить за InfiniBand больно один раз, платить за простаивающие чипы вы будете каждую минуту.
Голодный зверь: почему стандартный NAS убьет обучение
Сеть — это трубы, но по ним нужно что-то качать. Следующее ребро, о которое разбиваются амбиции дата-саентистов — это подсистема хранения. Представьте: вы запускаете эпоху обучения на датасете из десятков миллионов мелких изображений. Dataloader в PyTorch начинает порождать тысячи параллельных потоков на чтение. Классическое сетевое хранилище, собранное на жестких дисках с протоколами NFS или Ceph, мгновенно упирается в потолок IOPS. Как только хранилище захлебывается, графические процессоры останавливаются.
Утилизация чипов падает до двадцати процентов. Карты просто висят в памяти и ждут, пока медленные шпиндели найдут нужные блоки данных. В индустриальном ИИ это недопустимо. Чтобы загрузить современные PCIe шины, нужна параллельная файловая система вроде Lustre или WekaFS, способная выдавать десятки гигабайт в секунду на случайном чтении. В Morana Labs наш подход к инфраструктуре данных строится на жестком тиринге. Мы не храним холодные датасеты на дорогом флеше. Но активный датасет, на котором прямо сейчас идет обучение, переносится в агрессивный NVMe-кэш, подключенный максимально близко к вычислительным узлам. Более того, мы используем технологии вроде GPUDirect Storage, позволяющие гнать данные с NVMe накопителей напрямую в память видеокарт, минуя системную память и процессоры. Если ваши данные совершают лишние прыжки по архитектуре сервера, вы сжигаете процессорное время впустую.
Оркестрация хаоса: Slurm против Kubernetes
Допустим, вы обеспечили карты данными. Теперь к вам приходит команда исследователей, и начинается битва за ресурсы. Управлять распределением видеокарт в электронных таблицах или бронировать узлы в корпоративном чате — это каменный век. Вам нужен планировщик, который будет жестко контролировать квоты и обеспечивать шеринг ресурсов.
Рынок по умолчанию тащит в кластеры Kubernetes, потому что DevOps-инженеры привыкли запускать в нем микросервисы. Но Kubernetes из коробки отвратительно справляется с gang-scheduling — одновременным запуском всех воркеров для распределенной задачи. Если для обучения требуется 32 карты на 4 узлах, задача не должна стартовать, пока не будут доступны абсолютно все ресурсы, иначе часть запущенных подов зависнет в ожидании остальных, удерживая драгоценные чипы. В классическом HPC для таких задач уже двадцать лет существует Slurm. Он умеет честно ставить тяжелые batch-задачи в очередь, вытеснять низкоприоритетные интерактивные сессии и запускать процессы с гарантированным выделением топологии сети. Наш подход в Morana Labs зависит от профиля: для чистых кластеров обучения мы ставим бескомпромиссный Slurm, а для гибридных сред, где инференс перемешан с обучением, мы глубоко переписываем логику Kubernetes с помощью кастомных планировщиков уровня Volcano, внедряя жесткие device-plugins и тайм-слайсинг. Без автоматического прерывания задач ваши карты будут заняты сутками, пока кто-то забыл закрыть свой Jupyter Notebook.
Киловатты и телеметрия: цена холостого хода
Наконец, мы подходим к физике. Серверная стойка, набитая вычислителями, с легкостью потребляет 40 киловатт. Требования к охлаждению таких стоек исключают использование обычных кондиционеров — мы говорим о внутрирядных системах или прямом жидкостном охлаждении чипов. И здесь кроется самая жестокая правда: даже в простое современный ускоритель потребляет 50-70 ватт.
Если ваша архитектура несбалансирована, кластер работает в режиме прерывистой нагрузки. Вы платите за электричество, которое не трансформируется в полезные вычисления, а просто генерирует тепло, на отвод которого вы тратите еще больше энергии. Вы не можете управлять тем, чего не видите, поэтому внедрение глубокой телеметрии обязательно. Собирать базовые метрики операционной системы недостаточно. Необходимо разворачивать DCGM и собирать данные с периодичностью в секунду. Вас должен интересовать не объем занятой видеопамяти — фреймворки часто аллоцируют её всю про запас, обманывая мониторинг. Истинной метрикой является утилизация тензорных ядер и потоковых мультипроцессоров. Если задача заблокировала 80 гигабайт VRAM, но потоковые процессоры нагружены на пять процентов — это мусорный код или узкое место в чтении диска. Такие задачи должны выявляться автоматически и убиваться планировщиком с отправкой алерта автору. Инженерия кластера заканчивается не тогда, когда серверы монтируются в стойку, а когда каждая миллисекунда машинного времени отрабатывает вложенный бюджет на ста процентах утилизации кремния.