Короткий ответ: двух DGX Spark хватит не всегда
Два DGX Spark дают около 256 ГБ unified memory: по 128 ГБ на устройство по опубликованным спецификациям. Этого достаточно, чтобы поднять крупную MoE-модель семейства DeepSeek в 4-битной квантизации, и недостаточно, чтобы держать тот же чекпоинт в FP16.
Короткий ответ зависит от формата и контекста. Под 4-битные веса и умеренное окно на 32-64K токенов двух узлов хватает. Под нативный FP8 или FP16 с контекстом 128K и выше надёжнее планировать три-четыре узла, а часто такой запуск вообще выходит за рамки этого класса железа. Официально NVIDIA описывает связку двух DGX Spark; конфигурации на три и больше устройств пока остаются территорией сообщества и экспериментов.
Выбор упирается в три числа: объём весов, объём KV-кэша и пропускную способность связи между узлами. Первые два отвечают на вопрос, влезет ли модель. Третье решает, будет ли она выдавать приемлемую скорость. Суммарная память кластера не равна доступной: на активации, буферы коллективных операций и саму ОС уходит заметная доля. В разборах serving-стека на 2× DGX Spark из 256 с лишним гигабайт под систему оставалось 5-7 ГБ.
Что именно определяет минимальное число узлов
- Размер модели в параметрах. Память под веса считается по полному числу параметров, даже если модель MoE и на токен срабатывает лишь часть экспертов. 300B в 4 битах - это ~150 ГБ только под веса, 300B в FP16 - ~600 ГБ.
- Формат квантизации. FP16 - 2 байта на параметр, INT8 - 1 байт, INT4 - 0.5 байта, агрессивные GGUF Q2-Q3 спускаются к 2.5-3 битам и ниже.
- Длина контекста и параллелизм запросов. KV-кэш растёт линейно с числом токенов, которые нужно удерживать в памяти. Пять параллельных сессий по 32K токенов съедают столько же, сколько одна на 160K.
- Тип параллелизма. Tensor parallelism требует обмена между узлами на каждом слое, pipeline parallelism режет трафик, но оставляет простои.
- Скорость interconnect. Чем медленнее связь, тем больше узлов нужно, чтобы просто уместить модель, и тем меньше смысла добавлять третье устройство ради скорости.
- Накладные расходы стека. Служебные буферы, CUDA graphs, резервы ОС и запас на фрагментацию съедают 10-20% сверху.
Практический вывод из списка: считать нужно не по «влезет ли модель в 256 ГБ», а по «влезет ли модель плюс KV-кэш плюс 15% запаса».
Как распределяются веса модели и контекст по узлам
Кластер работает не как один большой компьютер, а как несколько устройств, которые постоянно обмениваются промежуточными результатами. Модель режется на части, и от схемы нарезки зависят и память, и скорость.
Tensor parallelism vs pipeline parallelism
Tensor parallelism (TP) делит каждый слой между узлами: матрицы внимания и MLP разрезаются по столбцам или строкам, а после каждого блока считается all-reduce, чтобы собрать результат. Все узлы заняты одновременно, память под веса распределяется равномерно. Плата за это - обмен данными на каждом слое, и весь трафик уходит в interconnect. Для модели на 80 слоёв это 80 синхронизаций на каждый сгенерированный токен.
Pipeline parallelism (PP) делит слои блоками: первый узел держит слои 1-40, второй 41-80, данные идут по конвейеру. Обменов намного меньше, но узел, ожидающий вход от соседа, простаивает. На двух-четырёх узлах это заметно бьёт по загрузке, поэтому в малых кластерах чаще берут TP, а PP добавляют сверху при переходе на большее число устройств.
Третий вариант, который недооценивают, - экспертный параллелизм для MoE-моделей. Эксперты раскидываются по узлам, и на каждом токене работает только та часть, что выбрана роутером. Память при этом всё равно распределяется по полному набору экспертов.
KV-кэш и длина контекста: скрытый потребитель памяти
KV-кэш хранит ключи и значения внимания для всех уже обработанных токенов. Формула на один токен выглядит так:
2 (K и V) x слои x KV-головы x head_dim x байт на элемент
Возьмём модель на 80 слоёв с GQA на 8 KV-голов и head_dim 128 в FP16: 2 x 8 x 128 x 2 байта = 4 КБ на токен на слой, то есть около 320 КБ на токен по всей модели. Контекст 128K токенов - это уже ~40 ГБ, и это для одной сессии. При TP эти гигабайты делятся между узлами вместе с головами, но лимит по суммарному контексту остаётся жёстким.
На практике KV-кэш становится ограничителем раньше весов: модель занимает 60% памяти, а остаток съедает контекст. Именно поэтому в разборах serving-стека на 2× DGX Spark на KV-кэш уходило около 11 GiB при коротком окне, и любое увеличение max-model-len упиралось в отсутствие свободной памяти.
Сколько VRAM нужно для DeepSeek и как квантизация меняет расклад
Ориентир считается в одну строку: параметры x битность / 8. Дальше добавляются KV-кэш и накладные расходы. В таблице ниже только веса, без кэша и запаса.
| Модель (полные параметры) | FP16 | INT8 | INT4 |
|---|---|---|---|
| 70B dense | ~140 ГБ | ~70 ГБ | ~35 ГБ |
| 120B MoE | ~240 ГБ | ~120 ГБ | ~60 ГБ |
| 200B MoE | ~400 ГБ | ~200 ГБ | ~100 ГБ |
| 300B+ MoE | ~600 ГБ и больше | ~300 ГБ | ~150 ГБ |
Кластер из двух DGX Spark с суммарными ~256 ГБ попадает в таблицу так: 300B в INT4 ещё можно попробовать, 300B в INT8 требует минимум трёх узлов (384 ГБ), а FP16-версия такого чекпоинта не помещается и в четыре устройства (512 ГБ против 600 ГБ только на веса). Прибавьте KV-кэш, активации и резерв, и картина станет ещё жёстче.
FP16, INT8, INT4: компромисс между памятью и качеством
FP16 даёт эталонное качество и вдвое больший объём. INT8 экономит половину памяти, деградация на большинстве задач невелика, и этот формат часто становится разумным компромиссом для длинных контекстов. INT4 сжимает сильнее всего, но требует аккуратной калибровки: на простых задачах разницы почти нет, на многошаговых агентных сценариях она начинает проявляться.
Отдельная история - агрессивные GGUF и смешанные чекпоинты с разной точностью для разных слоёв. Разбор сравнения на MacBook и 2× DGX Spark показал, что 2.45-битная квантизация и нативный FP8/FP4 чекпоинт дали близкие результаты в агентном бенчмарке (54% против 52%, p ≈ 0.82), то есть статистически значимой разницы между ними не нашлось. Разница проявилась в другом: в скорости и доступной длине контекста. Если выбираете модель под конкретное железо, посмотрите практическое сравнение DeepSeek V4, Laguna 2.1 и Inkling-Small на DGX Spark: там сведены замеры по памяти и скорости для разных квантизаций.
Форматы для локального запуска делятся на три группы: GGUF с гибкой квантизацией, AWQ и GPTQ на 4 бита, оптимизированные под GPU-инференс, и нативные FP8/FP4 чекпоинты вроде тех, что публикует DeepSeek. Запуск MoE в 2-3 битах часто единственный способ уместить большую модель в два узла, и он рабочий, но качество стоит проверять на своих задачах, а не полагаться на средние бенчмарки. Подробнее о том, когда агрессивной квантизации достаточно, разобрано в материале про DeepSeek-V4-Flash на MacBook против 2× DGX Spark.
Практический расчёт: сколько узлов нужно для модели N
- Возьмите полное число параметров, а не активное. Для MoE память считается по всем экспертам.
- Умножьте на байты на параметр: 2 для FP16, 1 для INT8, 0.5 для INT4, 0.4-0.5 для 3-битных GGUF.
- Посчитайте KV-кэш по формуле выше под свой контекст и число параллельных сессий.
- Добавьте 10-20% на активации, буферы и ОС.
- Разделите на полезную память одного узла. Для DGX Spark реально доступно меньше 128 ГБ: часть занята системой.
- Округлите вверх и проверьте, хватает ли interconnect на выбранную схему параллелизма.
Пример: 120B MoE в INT4 даёт ~60 ГБ весов, KV-кэш на 64K токенов и две сессии - порядка 20-25 ГБ, накладные 15% - итого около 100 ГБ. Двух узлов хватает с запасом. Тот же расчёт для 300B в INT4: ~150 ГБ весов плюс 30-40 ГБ кэша и резерв, выходит 200-220 ГБ. Два узла на грани, и результат зависит от формата и длины окна.
Пропускная способность и задержки: где проходит практический предел
Скорость генерации на локальном железе упирается в пропускную способность памяти, а не в вычислительные блоки. Каждый токен требует прочитать активные веса модели из памяти. Оценка сверху выглядит так:
токены/с ≈ суммарная пропускная способность памяти / размер активных весов в байтах
У одного DGX Spark заявлено порядка 273 ГБ/с на LPDDR5X. Два узла дают около 546 ГБ/с. Если активные веса в 4 битах занимают ~10 ГБ (типичная картина для MoE с небольшим числом активных экспертов), теоретический потолок выходит около 50-55 токенов/с на одиночном стриме. Такой порядок цифр и фигурирует в разборах DeepSeek-V4-Flash на двух DGX Spark, около 58 ток/с. Считаются активные параметры, а не полные, поэтому 300B MoE может отвечать быстрее, чем 70B dense.
Дальше в игру вступает interconnect. Tensor parallelism на каждой генерации токена прогоняет коллективные операции между узлами. Связь у DGX Spark идёт через ConnectX-7, а это сотни гигабит в секунду, на порядок меньше, чем NVLink у серверных GPU. При TP=2 обмен успевает спрятаться за вычислениями, при TP=4 и больше он начинает доминировать. Если RDMA не поднялся и NCCL молча ушёл в TCP, скорость падает в разы без единой ошибки в логах: сеть формально работает, инференс еле ползёт.
Почему 4 узла не всегда быстрее 2
Масштабирование упирается в закон, знакомый любому, кто собирал распределённые вычисления: полезная работа растёт линейно, а накладные расходы на синхронизацию - быстрее. Если модель уже помещается в два узла, третье устройство не добавляет скорости к одиночному запросу, а иногда и снижает её: больше точек синхронизации, больше задержек, больше шансов на нестабильность. Выигрыш появляется там, где важна суммарная пропускная способность под параллельные сессии, а не задержка одной генерации.
На 8× GB10 картина обратная: в разборе GLM-5.2 и Int4/Int8 на 8× GB10 prefill достигал ~1200 токенов/с, а decode держался в районе 33-54 ток/с, при этом освободившаяся память позволила поднять вторую модель рядом. Расширение имеет смысл, когда вы продаёте не минимальную задержку, а количество параллельных задач на одном стенде.
Когда кластер DGX Spark оправдан, а когда нет
Кластер имеет смысл, если сходятся три условия. Модель не помещается в одну систему. Данные нельзя отдавать наружу. Вы готовы разбираться с NCCL, параметрами vLLM, лимитами контекста и следить за температурой и питанием.
Кластер не нужен, если рабочая модель спокойно живёт на одной карте с 48-80 ГБ, если важна предсказуемость и минимум обслуживания, или если нагрузка эпизодическая. Три-четыре устройства добавляют не только память: это больше блоков питания, больше тепла, больше точек отказа, отдельная сеть и более сложная отладка, когда что-то не стартует.
Стоимость владения: кластер, одна система, облако
Сравнивать стоит не цену железа, а стоимость на час полезной работы. Кластер из нескольких устройств дороже в закупке, но при круглосуточной нагрузке его стоимость на час падает с каждым месяцем работы. Одна мощная рабочая станция дешевле в настройке и обслуживании, зато упирается в потолок по памяти. Облачные GPU не требуют капитальных затрат, но при постоянной работе счёт легко перекрывает покупку, а данные уходят на чужую сторону.
Про энергопотребление и шум стоит помнить отдельно: два устройства в режиме инференса потребляют сотни ватт и требуют активного охлаждения. Для домашнего кабинета это ощутимо, для отдельной стойки или серверной - уже нет.
Альтернативы: одна мощная система или облачные GPU
Одна мощная GPU: проще, но дороже
Одна карта с 48-80 ГБ памяти (RTX 6000 Ada, H100) закрывает модели до ~70B в INT4 с хорошим контекстом и до 120B в 4 битах с оговорками. Никаких inter-node обменов, нет проблем с NCCL, запуск сводится к одному процессу. Цена за карту высокая, а потолок по памяти жёсткий: наращивать его потом нечем. Если нужна система уровня дата-центра на столе, посмотрите разбор NVIDIA DGX Station 2026: там про многопользовательский инференс и про то, какие расходы считать до покупки.
Облачные GPU: гибкость за почасовую плату
Аренда GPU даёт доступ к A100, H100 и H200 на часы. Это разумный вариант для экспериментов, разовых прогонов и пиков, когда локальное железо простаивало бы. Ограничения прямые: стоимость при постоянной загрузке, приватность данных и зависимость от провайдера. Гибридная схема встречается чаще всего: локальный стенд под повседневные задачи и небольшие модели, облако под редкие тяжёлые прогоны.
Если задача скромнее и речь о моделях с 10-20 ГБ VRAM, кластер вообще не нужен: смотрите компактные альтернативы DGX Spark с разбором eGPU, mini-ITX и CPU-only вариантов.
Практические выводы: как выбрать конфигурацию под свою задачу
Порядок действий, который экономит деньги и нервы:
- Определите модель, которая реально нужна под задачу, а не самую большую из доступных.
- Зафиксируйте требуемый контекст и число параллельных сессий. Это часто важнее числа параметров.
- Выберите минимально допустимую квантизацию и проверьте качество на своих задачах.
- Посчитайте память: веса плюс KV-кэш плюс 10-20%. Разделите на полезную память узла.
- Проверьте interconnect: при TP=3-4 обмен между узлами становится узким местом.
- Сравните с альтернативами: одна карта с большим объёмом памяти, облако на часы, гибрид.
Если расчёт показывает, что модели нужно 200 ГБ и больше, а бюджет ограничен, честный ответ часто звучит так: взять модель поменьше с более щедрой квантизацией, чем собирать кластер под чекпоинт, который в него еле помещается. Работающая конфигурация с запасом по памяти полезнее, чем запуск на грани, где любое увеличение контекста роняет сервер.