У меня есть хорошие новости и плохие новости. Хорошая новость: у меня есть кластер из четырех работающих устройств NVIDIA DGX Spark, объединенных в единую систему. Плохая новость: это действительно адски жарко. Воздух выдувается с такой силой, что если направить его неправильно, можно отключить камеры. Но зачем вообще нужно объединять эти устройства? Каждая единица DGX Spark оснащена 128 ГБ памяти, доступной для обучения и инференса больших языковых моделей (LLM). Объединяя их, я получаю 512 ГБ (а в расширенной версии — до 1 ТБ) общей памяти, что позволяет запускать модели, которые физически не помещаются в один чип.
Но это не просто «больше памяти». Это использование интерфейса NVIDIA ConnectX-7, который стоит сам по себе от 1000 до 1500 долларов. Без этого интерфейса у нас не было бы безумно быстрого соединения, необходимого для тензорного параллелизма. Тензорный параллелизм — это техника, при которой веса модели распределяются между несколькими GPU. В обычных сетях (например, Ethernet) добавление новых машин замедляет систему из-за задержек. Но с поддержкой RDMA (Remote Direct Memory Access) масштабирование работает иначе: чем больше машин, тем быстрее система обрабатывает запросы, так как данные передаются напрямую между памятью серверов, минуя процессоры.
01Начало пути: Ошибки, кабели и первые тесты
Первая проблема, с которой я столкнулся, была банальной, но дорогой. Я купил кучу кабелей QSFP, не понимая разницы между стандартами. QSFP28 и QSFP56 имеют одинаковые разъемы, но скорость у них разная. QSFP56 обеспечивает двойную скорость. Кроме того, существуют коннекторы двойной плотности (double density), которые мне и требовались для соединения четырех устройств. Я купил неправильные кабели и несколько месяцев использовал QSFP28, хотя цель была в QSFP56.
Для соединения устройств нужен был коммутатор. Я купил MicroTik CRS812, самый дорогой свитч, который у меня когда-либо был, за 1300 долларов. Он имеет два порта 400 GbE. Используя разветвляющий кабель (breakout cable), я подключил один порт к четырем Spark-ам, создав mesh-сеть. Теперь устройства могут пинговать и подключаться по SSH друг к другу без паролей, что критично для кластера.
Однако, когда я запустил утилиту ethtool для проверки скорости соединения между узлами, результат оказался шокирующим: 50 Гбит/с. Это была не 100 Гбит/с, как ожидалось, и не 200 Гбит/с, как заявлено для интерфейса. Оказалось, что я использовал кабель QSFP28, который физически ограничивает скорость. Я заказал новый кабель QSFP56 на Amazon, который стоил всего 185 долларов (что считается дешевизной в этом сегменте), и заменил его.
ethtool илиiperf, а не верить описанию товара.02Настройка сети: Роковой баг коммутатора
Даже после замены кабеля на правильный QSFP56 скорость оставалась на уровне 50 Гбит/с. Я перезагружал устройства, проверял кабели, но результат был прежним. Здесь на помощь пришел AI-ассистент (Claude), который помог проанализировать ситуацию. Оказалось, что проблема не в кабелях, а в настройках самого коммутатора MicroTik.
MicroTik CRS812 — это управляемый коммутатор (managed switch). Через веб-интерфейс или SSH можно зайти в его настройки. Оказалось, что порт, к которому я подключил кабель, был жестко зафиксирован на скорости 50 Гбит/с. Это не баг, а особенность конфигурации по умолчанию или предыдущих настроек. Я изменил конфигурацию порта на 100 Гбит/с, переподключил кабель, и скорость выросла до 100 Гбит/с. Затем я подключил остальные узлы, и каждый порт теперь работал на 100 Гбит/с. Учитывая, что у каждого Spark есть два физических порта, каждый из которых поддерживает 200 Гбит/с, но виртуально разделен на два интерфейса по 100 Гбит/с, мы получили суммарную пропускную способность 200 Гбит/с на узел.
NCCL_DEBUG=INFO или специальные утилиты для проверки задержки.03Бенчмарки: Llama-Benchy и реальность
Для тестирования я использовал утилиту llama-benchy, которая более реалистична, чем llama-bench, так как взаимодействует с сервером через сеть. Первым тестом стала модель Qwen3 34B (полная версия BF16, не квантованная). На одном узле скорость генерации составляла 51 токен/с. При подключении всех четырех узлов скорость обработки промпта (prompt processing, PP) взлетела до 6367 токенов/с (при контексте 2048), а генерация токенов показала прирост.
Однако, после настройки сети на 100 Гбит/с результаты оказались парадоксальными. Скорость генерации токенов выросла всего на 7% (что находится в пределах погрешности), а вот скорость обработки промпта упала на 19%. Почему? Оказалось, что на скорости 50 Гбит/с задержки были выше, но алгоритмы распределения нагрузки могли работать эффективнее в определенных условиях. На скорости 100 Гбит/с задержка снизилась, но это не дало ожидаемого скачка в производительности для этой конкретной модели и конфигурации.
Для сравнения: - 1 узел: 23 токена/с (генерация) - 2 узла: 35 токенов/с (генерация) - 4 узла: ~40-45 токенов/с (генерация, с учетом 100 Гбит/с сети)
Обработка промпта (pre-fill) на 4 узлах показала почти 8000 токенов/с, что является огромным преимуществом кластера. Это означает, что вы можете загрузить очень длинный контекст (например, всю книгу) за доли секунды.
04Масштабирование: От Qwen3 32B к Qwen3.5 397B
Самый интересный вопрос: зачем все это нужно, если прирост скорости генерации не всегда огромен? Ответ — размер модели. Некоторые модели просто не помещаются в память одного устройства. Я начал с Qwen3 VL 32B (66 ГБ на диске). На одном узле скорость была 3.58 токена/с. На двух узлах — 6.14 токена/с. На четырех узлах — 11.36 токена/с. Масштабирование здесь линейное и предсказуемое. Память на каждом узле заполняется почти полностью (63 ГБ из 128 ГБ), так как модель делится, но также требуется память для KV-кэша и операционных систем.
Затем я расширил кластер до 8 узлов, добавив еще один коммутатор MicroTik CRS804 (с 4 портами 400 GbE) и новые кабели. Настройка заняла много времени: пришлось настраивать SSH-меш (64 соединения между 8 машинами), копировать модели через rsync, настраивать jumbo frames (MTU 9000) для оптимизации пакетов. В итоге я получил кластер из 8 DGX Spark.
Тест на Qwen3 4B (8 ГБ на диске) показал, что для маленьких моделей кластер из 8 узлов избыточен. Скорость генерации выросла с 61 до 64 токенов/с — прирост всего 10%. Модель слишком мала, чтобы распределить нагрузку эффективно, и накладные расходы на коммуникацию нивелируют выгоду.
Но настоящий триумф случился с моделью Qwen3.5 397B (Active 17B). Эта модель весит 800 ГБ на диске. Ее невозможно запустить даже на Mac Studio с 512 ГБ памяти. Но мой кластер из 8 Spark-ов (общая память 1 ТБ) справился с задачей. Модель была разрезана (sharded) на все 8 узлов. Загрузка памяти на каждом узле составила 112 ГБ из 128 ГБ. Скорость генерации составила 24 токена/с. Для модели такого уровня (SOTA, mixture of experts) это приемлемый результат. Это позволило запустить модель, которая иначе была бы недоступна.
05Технические детали и подводные камни
В процессе работы я столкнулся с рядом технических нюансов, которые стоит учитывать энтузиастам:
- Тепловыделение: Кластер из 8 устройств генерирует огромное количество тепла. Мне пришлось открыть окно, так как выдуваемый горячий воздух быстро нагревал помещение. Шум от вентиляторов коммутаторов также заметен, хотя они тише серверных.
- Стоимость: Помимо самих Spark-ов (185$ за штуку), затраты на сеть огромны. Коммутаторы MicroTik, кабели QSFP56, разветвляющие кабели — все это складывается в серьезную сумму. Только сеть обошлась в несколько тысяч долларов.
- Программное обеспечение: Для работы кластера используется Docker-контейнер с vLLM. Также активно используется репозиторий пользователя Yuger, который упростил настройку кластеризации без необходимости глубокого погружения в Docker-сети. Важно использовать
NCCLдля коммуникации между GPU. - Операционная система: Все узлы работают под управлением Linux (вероятно, Ubuntu или специализированной сборки NVIDIA). Настройка SSH без паролей и синхронизация времени критичны для стабильной работы.
06Выводы: Кому что подойдёт
Эксперимент с кластером из 8 NVIDIA DGX Spark показал, что технически возможно объединить эти мини-серверы в мощную систему для инференса LLM. Однако это не «plug-and-play» решение. Оно требует глубоких знаний в настройке сетей, коммутаторов и распределенных вычислений.
Кому это подходит: - Энтузиастам и исследователям, которые хотят запустить модели размером 30B+ параметров на домашнем или офисном оборудовании. - Тем, кому нужен огромный контекст (pre-fill) для обработки больших документов. - Тем, кто готов потратить время на настройку сети и решение проблем с задержками.
Кому это НЕ подходит: - Обычным пользователям, которым нужна просто быстрая генерация текста. Один Spark или даже два справятся лучше, чем 8 узлов с низкой скоростью генерации на токен. - Тем, кто не готов разбираться в сетях, RoCE, NCCL и настройке коммутаторов.
Главный вывод: масштабирование по памяти работает отлично, позволяя запускать модели, которые иначе невозможно запустить. Масштабирование по скорости генерации (token generation) имеет пределы и зависит от архитектуры модели и эффективности сети. Для моделей типа Mixture of Experts (MoE), таких как Qwen3.5 397B, кластеризация — это единственный способ их запуска. Для других задач лучше рассмотреть более простые решения, такие как использование нескольких GPU в одном корпусе или облачные сервисы.
Этот проект стал уроком терпения и внимательности к деталям. От неправильных кабелей до настроек коммутатора — каждый шаг требовал проверки. Но результат — работающая система, способная запустить 800-гигабайтную модель — того стоил. Если вы решитесь на такой путь, будьте готовы к тому, что ваш дом станет жарким, а счета за электричество вырастут, но вы получите доступ к миру больших моделей, который раньше был доступен только корпорациям.
Источник: видео-разбор (YouTube) ↗