Эра локального искусственного интеллекта переживает фундаментальный сдвиг. Еще недавно запуск больших языковых моделей (LLM) был прерогативой дата-центров с тысячами GPU, требующих колоссальных затрат на электроэнергию и охлаждение. Однако появление NVIDIA DGX Spark изменило правила игры, перенеся мощь серверных вычислений на уровень настольных рабочих станций. Теперь, по словам NVIDIA, разработчики могут не просто запускать отдельные модели, но и оркестрировать сложные многоагентные системы, объединяя несколько устройств в единый кластер. На конференции GTC Berlin NVIDIA представила официальную поддержку кластеров из восьми узлов DGX Spark, что открывает двери к запуску моделей уровня Frontier (передового класса) прямо у вас на столе.
Ключевым достижением этой архитектуры является объединение унифицированной памяти до 1 ТБ. Эта емкость позволяет локально исполнять такие гиганты, как полная версия модели GLM 5.3 (753B) от Z.ai, которая ранее требовала распределенных кластеров. Но память — это только половина дела. Вторая половина — это скорость коммуникации между узлами. NVIDIA представила оптимизированный бэкенд коллективных операций RoCEnante, который радикально снижает задержки при тензорной параллельной декодировке, обеспечивая ускорение в 4,43 раза на восьми узлах по сравнению с базовыми конфигурациями. В этой статье мы подробно разберем, как работает эта система, какие бенчмарки она показывает и что это значит для разработчиков ИИ в России и мире.
01Масштабирование памяти: Доступ к моделям уровня Frontier
Главное преимущество кластера из восьми узлов DGX Spark заключается в объеме памяти. Каждый узел DGX Spark оснащен 128 ГБ унифицированной памяти. Когда вы объединяете четыре узла, вы получаете 512 ГБ, а восемь узлов дают вам доступ к 1 ТБ памяти. Эта емкость открывает доступ к классу моделей, которые физически не могли бы запуститься на четырехузловой системе. Ярким примером является полная модель GLM 5.3 (753B) от компании Z.ai.
Важно отметить, что кластер спроектирован не просто для того, чтобы «вместить» эти модели, но и для их интерактивного обслуживания. В качестве раннего примера разработчики NVIDIA запустили GLM 5.3 Flash на восьмиузловом кластере и измерили скорость генерации примерно в 80 токенов в секунду (TPS). Этот показатель делает модель пригодной для интерактивной локальной разработки, позволяя исследователям работать с передовыми архитектурами типа MoE (Mixture of Experts) без задержек, характерных для облачных API.
Ниже приведены данные о производительности полной модели GLM 5.3 (nvidia/GLM-5.3-NVFP4) на восьмиузловом кластере. Модель занимает около 470 ГБ в квантованном формате NVFP4. Измерения проводились с использованием MTP3 при конкурентности от 1 до 8 пользователей. Длина входной последовательности (ISL) для измерения префилла составляла 8K токенов.
| Конкурентность | Префилл, всего (TPS) | Префилл, на пользователя (TPS) | Декодирование, всего (TPS) | Декодирование, на пользователя (TPS) |
|---|---|---|---|---|
| 1 | 1,600 | 1,600 | 31 | 31 |
| 4 | 1,600 | 750 | 51 | 21 |
| 8 | 1,600 | 473 | 67 | 18 |
Как видно из таблицы, даже при увеличении числа пользователей до восьми, общая пропускная способность префилла остается стабильной, а скорость декодирования на пользователя снижается предсказуемо, что является нормой для распределенных систем. Это подтверждает, что кластер способен обслуживать несколько пользователей одновременно, работая с моделью огромного размера.
02RoCEnante: Оптимизация коллективных операций
При тензорно-параллельном выводе значительная часть времени тратится на коллективные операции, такие как all-reduce. В кластерах, соединенных через коммутатор (switch), NVIDIA оценивает новый оптимизированный бэкенд под названием RoCEnante. Эта технология снижает задержки коллективных операций для паттернов с малыми сообщениями, низкой конкурентностью и умеренным количеством рангов, которые типичны для локального аппаратного обеспечения ИИ.
RoCEnante реализует обмен типа all-to-all, за которым следует локальное суммирование. Каждый ранг (вычислительный узел) делит свой ввод со всеми остальными рангами, а затем складывает вводы локально. Один GPU-ядра координирует этот обмен и суммирование. Главное преимущество — меньшее количество шагов коммуникации. Традиционный ring all-reduce передает данные между соседними рангами в несколько раундов. Подход RoCEnante обменивается данными напрямую со всеми пирами, избегая этой цепочки пересылки. Для малых сообщений и умеренного числа рангов это значительно снижает задержку.
Однако есть и компромисс: больший объем перемещаемых данных. Каждый ранг отправляет свой полный ввод каждому пиру и сам выполняет суммирование всех вводов. По мере роста размера сообщений или количества рангов (узлов) этот дополнительный трафик становится более дорогим, что делает ring all-reduce более привлекательным с точки зрения эффективности пропускной способности. Если вам нужна высокая конкурентность, большие кластеры или кольцевые топологии, библиотека NVIDIA Collective Communications Library (NCCL) будет работать лучше.
На практике мы наблюдаем примерно на 5% более высокий префилл и на 21% более высокую пропускную способность декодирования на четырех узлах (NVFP4), а также примерно на 18% более высокую пропускную способность декодирования на восьми узлах для неквантованной модели. Это согласуется с компромиссом между задержкой и пропускной способностью. На восьми узлах RoCEnante обеспечивает ускорение в 4,43 раза по сравнению с 3,05 раза без него — улучшение эффективности масштабирования на 45%.
03Топологии связи: Кольцо против Коммутатора
Низколатентные сетевые карты NVIDIA ConnectX-7 и протокол RDMA over Converged Ethernet (RoCE) позволяют узлам DGX Spark эффективно обмениваться тензорами. Чтобы изолировать поведение масштабирования кластера и исключить зависимость от контекста, разработчики протестировали плотную модель Qwen3.8-27B (NVFP4) без спекулятивного декодирования на конфигурациях от одного до восьми узлов.
Результаты показывают два ключевых вывода. Во-первых, пропускная способность декодирования сильно масштабируется с количеством узлов: от примерно 12 TPS на одном узле до 52 TPS на восьми узлах. Во-вторых, лучшая топология зависит от рабочей нагрузки.
| Кол-во узлов | Топология | Префилл (TPS) | Масштабирование префилла | Декодирование (TPS) | Масштабирование декодирования |
|---|---|---|---|---|---|
| 1 | — | 2,635 | 1.00x | 11.86 | 1.00x |
| 2 | Прямое соединение | 3,285 | 1.25x | 21.71 | 1.838x |
| 4 | Физическое кольцо | 4,446 | 1.69x | 32.82 | 2.77x |
| 4 | Коммутатор (RoCEnante) | 4,556 | 1.73x | 36.34 | 3.06x |
| 8 | Физическое кольцо | 4,962 | 1.88x | 40.11 | 3.38x |
| 8 | Коммутатор (RoCEnante) | 5,105 | 1.94x | 52.58 | 4.43x |
Физическое кольцо обеспечивает отличную пропускную способность декодирования для одной модели, распределенной по всем узлам, и является более дешевым решением. Однако коммутатор необходим, если вы хотите разделить кластер на независимые группы или запустить рабочие нагрузки, требующие прямой связи «любой-с-любым» между узлами. Например, если вы хотите разделить кластер из восьми узлов на две группы по четыре узла, кольцо не может выразить эту топологию — вам нужен коммутатор.
04Оркестрация нескольких моделей с NeMo Switchyard
Не каждый запрос требует использования вашей самой большой модели. На общем восьмиузловом кластере можно получить значительно более высокую агрегированную пропускную способность, маршрутизируя простые запросы на маленькую, быструю модель и резервируя большую модель для сложных задач. NVIDIA NeMo Switchyard делает это практичным: легкий классификатор проверяет каждый запрос (или сессию) и направляет его в соответствующий пул моделей, а балансировщик нагрузки распределяет трафик между репликами.
В прототипе использовалась модель OpenBMB’s MiniCPM5 2B в качестве классификатора и модели выполнения для простых задач, а Qwen3.8 Flash Next — для сложных. На стандартном и сложном бенчмарке использования инструментов (tool-use) маршрутизируемый агент показал качество, сопоставимое с конфигурацией только на Qwen, но при этом освободил ресурсы кластера.
На бенчмарке из 92 случаев использования инструментов маршрутизируемый агент набрал 91/100, что совпадает с результатом конфигурации только на Qwen. Поскольку MiniCPM обслуживает примерно в десять раз больше запросов в секунду, чем Qwen на одну реплику, перенос части трафика на меньшую модель повышает потолок пропускной способности всего кластера. При распределении трех реплик Qwen (по два узла DGX Spark каждая) и двух реплик MiniCPM (по одному узлу DGX Spark каждая) мы получаем:
- ~1.5x агрегированной пропускной способности по сравнению с базовой конфигурацией только на Qwen, когда половина запросов маршрутизируется на Qwen.
- ~3.0x агрегированной пропускной способности, когда четверть запросов маршрутизируется на Qwen, а остальные — на MiniCPM.
Политика маршрутизации — это простой YAML-файл, и NVIDIA предоставляет образец политики в качестве отправной точки. Разработчики могут настраивать разделение и классификатор под свою рабочую нагрузку. Это особенно актуально для локальных развертываний, где ресурсы ограничены, а требования к разнообразию задач высоки.
05Предобучение с нуля: почти линейное масштабирование
Обучение ведет себя иначе, чем вывод. Когда каждый узел содержит полную копию модели, единственная коммуникация между узлами — это синхронизация градиентов один раз за шаг, поэтому кластеризация масштабируется почти линейно. Для демонстрации разработчики предобучили модель nanochat с нуля (около 896,5 млн параметров, 20 слоев трансформера, скрытое измерение 1280 и последовательности длиной 2048 токенов) и измерили пропускную способность обучения по мере добавления узлов.
| Узлы | TPS | Ускорение | Эффективность масштабирования |
|---|---|---|---|
| 1 | 8,741 | 1.00x | 100.0% |
| 2 | 17,202 | 1.97x | 98.4% |
| 4 | 33,640 | 3.85x | 96.2% |
| 8 | 68,079 | 7.79x | 97.4% |
Восемь узлов обеспечивают ускорение в 7,79 раза при эффективности 97,4%. Это тип почти линейного масштабирования, который делает восьмиузловой кластер Spark достоверной платформой для обучения небольших моделей с нуля, а не только для их обслуживания. Это также естественный рабочий процесс: прототипирование и предобучение локально, затем масштабирование по мере роста модели. Полный код для воспроизведения эксперимента доступен на GitHub.
06Что это значит на практике
Для разработчиков ИИ в России и других регионах, где доступ к облачным GPU может быть ограничен или дорог, возможность локального развертывания кластера из восьми DGX Spark представляет собой стратегическое преимущество. Вы получаете:
- Доступ к SOTA-моделям: Запуск GLM 5.3 (753B) и других моделей уровня Frontier локально, без зависимости от внешних API.
- Гибкость оркестрации: Использование NeMo Switchyard для эффективного распределения нагрузки между большими и малыми моделями, что экономит ресурсы и повышает общую скорость ответа системы.
- Эффективное обучение: Возможность предобучать и дообучать модели с нуля с почти линейным масштабированием, что ранее требовало дорогостоящих серверных решений.
- Простота развертывания: Поддержка как кольцевых топологий (для экономии средств на малых кластерах), так и топологий с коммутаторами (для максимальной производительности и гибкости).
Технология NVIDIA Sync упрощает настройку кластера, а поддержка восьми узлов в Sync появится к концу года. Разработчикам рекомендуется начать с изучения руководства по настройке сети, чтобы подключить несколько машин DGX Spark для распределенных рабочих нагрузок, а также использовать vLLM для обслуживания LLM в распределенном режиме. Это открывает новую эру локального ИИ, где мощь дата-центров доступна на рабочем столе.
Для получения дополнительной информации посетите ресурсы NVIDIA по настройке кластеров DGX Spark, изучите руководство по совместимости моделей и материалы по оркестрации Switchyard. Начните строить свои решения на NVIDIA DGX Spark уже сегодня.
Источник: NVIDIA Developer ↗