DGX Spark + Mac Studio: Эксперимент с разделением Pre-fill и Decode

Представьте себе сценарий, где вы можете взять лучшее от двух совершенно разных архитектур и объединить их в единую систему инференса. С одной стороны — NVIDIA DGX Spark, машина, которая молниеносно обрабатывает промпты (prefill), но страдает при генерации токенов. С другой — Mac Mini или Mac Studio на Apple Silicon, которые медленнее обрабатывают входные данные, но выдают ответ с невероятной скоростью благодаря пропускной способности памяти. Звучит как идеальная формула? Автор видео решил проверить эту гипотезу на практике, и результаты оказались не только технически интересными, но и откровенно провокационными для индустрии локального ИИ.

Этот эксперимент — не просто сравнение «кто быстрее», а глубокое погружение в архитектуру распределенного инференса. Мы поговорим о том, как разделить задачи Pre-fill (предварительная обработка) и Decode (генерация), почему сеть стала главным узким местом, и почему в итоге покупка двух дорогих машин может быть менее выгодной, чем одна мощная рабочая станция. Разберем все цифры, ошибки конфигурации и реальные показатели токен/с.

01Архитектура эксперимента: Два гиганта на одном столе

Для начала определим, с чем именно мы имеем дело. В первой фазе эксперимента использовались две машины, представляющие два полюса современного потребительского/профессионального железа для ИИ.

Сторона NVIDIA (Pre-fill): MSI Edge Expert (по сути, клон DGX Spark от другого вендора). Это устройство построено на архитектуре Blackwell. Ключевые характеристики:

• GPU: NVIDIA Blackwell (архитектура SM 121).
• Память: 128 ГБ унифицированной памяти (HBM).
• ОС: Linux (ARM64).
• Стек: vLLM, BF16 (полная точность для вычислений).

Сторона Apple (Decode): Mac Mini M4 Pro.

• Чип: Apple M4 Pro.
• Память: 64 ГБ унифицированной памяти.
• ОС: macOS.
• Стек: MLX, 4-bit квантование (для оптимизации под Apple Silicon).

Цель была проста: использовать GPU NVIDIA для тяжелой вычислительной работы по обработке промпта (Prefill), а затем передать результат (KV Cache) на Mac для быстрой посимвольной генерации (Decode). Это классическая схема Disaggregated Pre-fill and Decode (раздельная обработка).

02Первые шаги: Борьба с сетью и протоколами

Теория звучала просто, но реализация превратилась в ад для разработчика. Автор, будучи веб-разработчиком, а не системным программистом на Rust, столкнулся с серьезными барьерами при настройке фреймворка Exo — проекта, предназначенного для распределенного инференса на потребительском железе.

Первая проблема возникла на этапе обнаружения пиров (peer discovery). Exo использует протокол mDNS для поиска устройств в сети. Однако на macOS этот механизм оказался сломанным в контексте взаимодействия с Linux-машиной через прямое соединение. Автор потратил часы на эксперименты с прямыми Ethernet-кабелями, USB-адаптерами и даже Thunderbolt-кабелями.

Решение пришло через анализ трафика с помощью tcpdump. Оказалось, что библиотека libp2p, используемая в Exo, имеет баг в реализации mDNS на macOS. Обходной путь оказался простым, но нетривиальным: пришлось принудительно указать Mac Mini (MSI Edge Expert) на необходимость «навязывать» соединение с Mac, а не ждать, пока Mac сам его обнаружит. Это потребовало установки переменных окружения и ручной настройки сетевых интерфейсов.

После успешного соединения началась компиляция. На стороне Linux пришлось собирать vLLM из исходников для ARM Linux, а на Mac — компилировать MLX с учетом всех шейдеров Metal. Это заняло несколько дней, что подчеркивает высокую порог входа для таких экспериментов.

03Тест 1: Qwen 2.5 32B и проблема сети

Первой моделью для теста стала Qwen 2.5 32B. Это модель среднего размера, которая хорошо подходит для демонстрации принципов. На стороне NVIDIA она запускалась в полной точности BF16 (так как 128 ГБ памяти позволяют это сделать без квантования), а на Mac Mini — в 4-bit квантовании через MLX.

Результаты первого запуска были шокирующими, но логичными с точки зрения физики:

• Prefill (NVIDIA): 546–937 токенов/с. Отличный результат, GPU справлялся с вычислениями мгновенно.
• Decode (Mac Mini): 66 токенов/с. Быстро для Mac Mini, но это не рекорд.
• Общая задержка (TTFT): Катастрофическая.

При длине промпта в 25 000 токенов GPU NVIDIA вычислял KV Cache менее чем за секунду. Однако передача этого KV Cache по 2.5 Gbps Ethernet-адаптеру занимала 25 секунд. То есть 96% общего времени ушло на пересылку данных по сети. GPU NVIDIA простаивал, ожидая подтверждения от Mac Mini. Это наглядно показало, что стандартные сетевые интерфейсы не подходят для такого рода задач.

04Апгрейд инфраструктуры: 50 Gbps и Thunderbolt

Поняв, что сеть — узкое место, автор решил радикально улучшить канал связи. Был приобретен Thunderbolt 5 enclosure (внешний корпус с PCIe слотом) и сетевая карта Mellanox ConnectX-4 (QSFP+, 50 Gbps). На стороне Linux был подключен коммутатор Microtech CSR-812.

Почему именно ConnectX-4? Автор отметил, что более мощная карта Intel 800 (100 Gbps) не заработала на macOS из-за отсутствия драйверов. Mellanox ConnectX-4 же поддерживается Apple «из коробки» с 2019 года. Это позволило создать высокоскоростной канал с минимальными задержками.

Также для корректного тестирования была выбрана модель Llama 3.1 8B. Почему 8B? Потому что это «не думающая» модель. В предыдущих тестах с Qwen (моделью с цепочкой рассуждений, Chain-of-Thought) скрытые токены рассуждения генерировались со скоростью Decode, что маскировало преимущества GPU в Prefill. Llama 3.1 8B выдает ответ сразу, что позволяет четко измерить время до первого токена (Time to First Token, TTFT).

05Тест 2: Llama 3.1 8B — Первые успехи

С новым сетевым стеком и моделью Llama 3.1 8B результаты изменились кардинально. Использовался бенчмарк LlamaBenchy для точного измерения через HTTP API.

Результаты для промпта длиной 4096 токенов:

• MSI Edge Expert (только): Prefill ~1800 токенов/с. TTFT ~2.3 сек.
• Mac Mini M4 Pro (только): Prefill значительно медленнее, но Decode ~52 токенов/с.
• Disaggregated (Связка): Prefill ~1585 токенов/с (почти как у Spark), Decode ~34 токенов/с.
• TTFT (Связка): 2.4 секунды.

Здесь мы видим интересный парадокс. Связка показала TTFT, сопоставимый с чистым Spark (2.3 vs 2.4 сек). Однако скорость Decode в связке (34 токена/с) оказалась медленнее, чем у Mac Mini в одиночку (52 токена/с). Почему? Из-за накладных расходов на инъекцию удаленного KV Cache. Сеть добавила около 18 миллисекунд задержки, но главное — процессор Mac Mini тратил время на прием и обработку данных из сети, а не только на генерацию.

Тем не менее, связка выиграла в общем времени ответа за счет того, что Spark обработал длинный промпт так же быстро, как и сам бы, а Mac Mini продолжил генерацию. Но главное открытие было сделано позже: Mac Mini M4 Pro — не предел.

06Тест 3: Mac Studio M3 Ultra — Проверка гипотезы

Автор заменил Mac Mini на Mac Studio M3 Ultra. Этот монстр имеет 512 ГБ унифицированной памяти и пропускную способность 819 ГБ/с (в 3 раза больше, чем у M4 Pro). Ожидания были высокими: если Decode лимитирован памятью, то M3 Ultra должен ускорить генерацию втрое.

Настройка снова потребовала усилий: процесс-раннер на Mac Studio не мог найти Spark, потребовалось перенастройка сетевых сервисов и перезагрузка. Но в итоге кластер заработал.

Результаты для Llama 3.1 8B на Mac Studio M3 Ultra:

• Decode (Mac Studio): 106 токенов/с (против 52 у Mac Mini). Ускорение почти в 2 раза, что близко к теоретическому пределу при батче 1.
• Disaggregated Decode: 84 токена/с. Опять же, потеря ~20% скорости из-за накладных расходов сети.
• TTFT (Disaggregated): 2.6 секунды. Spark показал 1585 токенов/с, Mac Studio — 1420. Связка дала 1584, то есть полностью сохранила преимущество Spark в Prefill.

Здесь связка начала выглядеть привлекательно. Decode в 84 токена/с все еще медленнее, чем чистый Mac Studio (106), но в 6 раз быстрее, чем Spark (14 токенов/с). Для 8B модели гипотеза о том, что «чем больше памяти, тем быстрее Decode», подтвердилась.

07Тест 4: Тяжеловесы — Qwen 2.5 32B и Gemma 2 27B

Самый интересный этап — переход к большим моделям. Автор попытался запустить Llama 3.1 70B, но столкнулся с ограничениями NVIDIA Spark. Модель в полной точности весит значительно больше, чем доступно памяти у Spark. Попытки использовать квантованные версии провалились из-за отсутствия соответствующих ядер (kernels) в сборке vLLM для архитектуры Blackwell. Пришлось пересобирать vLLM с нуля, что автор отложил.

Вместо этого были взяты модели 27B и 32B класса. Результаты для Qwen 2.5 32B и Gemma 2 27B показали интересную динамику:

Для Qwen 2.5 32B:

• Prefill (Spark): 875 токенов/с.
• Prefill (Mac Studio): 356 токенов/с.
• Disaggregated Prefill: 792 токена/с. (Связка почти равна Spark, что в 2.2 раза быстрее Mac Studio).
• Decode (Mac Studio): 29 токенов/с.
• Decode (Spark): 23 токена/с.
• Disaggregated Decode: 24 токена/с (потеря ~20% из-за сети, но все равно сопоставимо с Spark).

Для Gemma 2 27B картина была схожей: Prefill в связке повторял показатели Spark, а Decode был близок к показателям Mac Studio с небольшой потерей на сеть.

Ключевой вывод: с ростом размера модели разрыв в скорости Decode между Mac Studio и Spark сужается. Если для меньшей модели Mac Studio был заметно быстрее, то для более крупной разрыв составляет всего несколько десятых процента. Это связано с тем, что на больших моделях Decode становится менее зависимым исключительно от пропускной способности памяти (из-за sliding window attention в Gemma и оптимизаций ядра в Qwen), и вычислительная часть становится более значимой. Spark, имея мощный GPU, начинает конкурировать с Apple Silicon в Decode, тогда как в Prefill он остается вне конкуренции.

08Сетевые накладные расходы: Цена распределенности

Один из самых важных выводов эксперимента — это цена, которую приходится платить за распределенную архитектуру. В каждом случае, когда использовалась связка, скорость Decode падала примерно на 20% по сравнению с работой Mac Studio в одиночку. Это плата за:

1. Передачу KV Cache по сети (даже при 50 Gbps).
2. Синхронизацию состояний между узлами.
3. Накладные расходы на инъекцию данных в память Mac Studio.

При этом время до первого токена (TTFT) в связке практически всегда совпадало с показателями чистого Spark. Это означает, что Spark берет на себя всю «тяжесть» инициализации, а Mac Studio просто продолжает поток. Но если Spark не быстрее Mac Studio в Prefill (как это было с некоторыми конфигурациями или при меньших промптах), то связка проигрывает по всем фронтам.

09Альтернатива: RTX Pro 6000 vs. Связка Spark + Mac

Автор задает главный вопрос: «Стоит ли оно того?». И дает честный ответ: скорее нет, если вы собираете систему с нуля.

Один мощный GPU, такой как NVIDIA RTX Pro 6000 (Blackwell), обладает:

• В 6 раз большей пропускной способностью памяти, чем DGX Spark.
• В 3.5 раза большей вычислительной мощностью.

Такая карта способна «раздавить» всю связку Spark + Mac Studio как в Prefill, так и в Decode. Она не требует сложной сетевой настройки, не имеет задержек на передачу KV Cache и работает в едином адресном пространстве памяти. Если бюджет позволяет купить DGX Spark и Mac Studio M3 Ultra, то гораздо разумнее купить RTX Pro 6000 и собрать вокруг нее рабочую станцию.

Однако, если у вас уже есть оба этих устройства, то эксперимент показывает, что их можно использовать вместе для получения marginal gain (небольшого прироста) в скорости генерации за счет использования избыточных мощностей Mac Studio для Decode, пока Spark обрабатывает следующий промпт или просто простаивает.

10Выводы: Кому что подойдёт

Эксперимент с объединением DGX Spark и Mac Studio (Mini/Ultra) — это блестящий proof-of-concept для технологии Disaggregated Inference, но суровое напоминание о сложностях её внедрения на потребительском уровне.

• Для энтузиастов и исследователей: Это отличный проект для изучения сетей, Rust, vLLM и MLX. Вы научитесь настраивать сложные кластеры и поймете внутреннюю кухню инференса.
• Для тех, у кого уже есть железо: Если у вас есть DGX Spark и Mac Studio M3 Ultra, связка через 50 Gbps сеть даст вам быстрый Prefill от NVIDIA и приличный Decode от Apple. Но ожидайте потерь ~20% в скорости Decode из-за сети.
• Для тех, кто строит систему с нуля: Не делайте этого. Купите одну мощную карту NVIDIA (RTX 4090, RTX Pro 6000 или будущие модели). Простота, надежность и отсутствие сетевых задержек перевешивают все теоретические преимущества гетерогенных систем.
• Будущее: Технологии вроде Exo и разделения Pre-fill/Decode будут развиваться. С появлением более быстрых сетей (100+ Gbps) и оптимизированных драйверов для macOS, такие связки могут стать более жизнеспособными, особенно в сценариях, где нужно масштабировать Prefill и Decode независимо.

ИИ-инференс становится все более сложным, и хотя «просто соединить два компьютера» пока не работает идеально, направление верное. Мы движемся к облачным гибридным архитектурам, где разные части задачи выполняются на оптимальном для этого оборудовании.

Источник: видео-разбор (YouTube) ↗