Бенчмарк DGX Spark с LLM Qwen3: кому подойдет, почему 128 ГБ не серебряная пуля и о чем умолчал маркетинг NVIDIA / Хабр

Всем привет! Меня зовут Валерий Гречин, я руковожу компанией ML-интегратором для бизнеса и промышленности Palatine Vision, облачным API-провайдером речевых нейросетей Palatine Speech и несколькими стартапами.

У всех, кто работает с LLM-моделями случалось, что модель на 32B параметров не влезает в 24 ГБ VRAM вашей RTX 4090, offload на CPU убивает скорость, а облако — дорого и данные уходят на сторону. NVIDIA обещает нам решение: DGX Spark (он же GB10) с 128 ГБ unified memory за ~400-500 тысяч рублей. Было потрачено две недели на глубокие бенчмарки устройства и результаты оказались... неоднозначными.

Спойлер: иногда б/у RTX 3090 будут быстрее. Но есть сценарии, где DGX Spark это лучший выбор на рынке. Разбираемся, когда стоит переплачивать, а когда — точно нет.

Однако DGX Spark это не только про разработчиков и стартапы. 128 ГБ unified memory, 140W энергопотребления и полностью автономная работа без облака делают его кандидатом для промышленного Edge AI: предиктивное обслуживание оборудования, анализ технической документации по ГОСТ и ТУ, контроль качества в цеху и другие задачи. Для предприятий с закрытым контуром (как минимум производства, банки, медицина, ОПК, КИИ), где данные не должны покидать периметр, локальный инференс часто не просто опция, а требование. Я, как интегратор, вижу этот запрос все чаще, и DGX Spark одно из первых устройство своего класса, которое закрывает его без серверной стойки.

В статье будет много графиков, сравнение нескольких форматов квантизации, тесты разных объемов подаваемого контекста, сравнения с более привычными GPU и оценка финансовой эффективности такой покупки. Цель бенчмарка разобраться, в каких ситуациях DGX Spark показывает свои преимущества, а где его архитектурные ограничения становятся узким местом и предпочтительнее выбирать другие решения.

Оглавление

TL; DR — для тех, кто спешит

Железо и стек: что внутри GB10 и почему это важно

Как происходило тестирование: от синтетики к реальным сценариям

Четыре метрики, которые определяют все

Бенчмарк: где GB10 летает, а где буксует

0.6B: когда память еще не bottleneck

4B: рабочий вариант с неожиданными открытиями

14B: баланс качества и производительности

30B-A3B (MoE): знания 30B по цене 3B

32B: здесь начинается борьба с физикой

Квантизация: когда помогает, а когда бесполезна

Потолок на 50 запросах: почему больше не значит быстрее

Почему GPU простаивает: разбор узких мест

Итоги

Ожидания vs реальность

Применение в промышленности

Сравнение DGX Spark vs RTX сборок

Считаем ROI: когда DGX Spark окупается за год

Кому брать девайс, а кому – точно нет

Вердикт и итоговые рекомендации

Заключение

TL; DR — для тех, кто спешит

Прежде чем погружаться в детали, вот краткая выжимка результатов:

Сценарий	Результат	Вердикт
Чат-боты (короткий контекст)	400–4 500 tok/s (0.6B–32B)	✅ Отлично
RAG до 4k токенов	100–1 500 tok/s	✅ Хорошо
RAG 15k–73k токенов	50–300 tok/s, TTFT до 34 сек	⚠️ На грани
MoE 30B-A3B (GPTQ)	730 tok/s chat, 361 tok/s RAG	✅ Главная находка
High-throughput (100+ RPS)	Плато на ~50 запросах	❌ Не для этого

Когда брать DGX Spark:

Нужна простота развертывания (одно устройство, unified memory)
Работаете с моделями до 32B и не нужен extreme throughput
Критична энергоэффективность (140W vs 575-900W у альтернатив)
Конфиденциальность данных это безусловное требование
Планируете масштабирование через кластеризацию (2 устройства = 256 GB и поддержка моделей до 405B)

Когда лучше RTX 3090/4090/5090:

Нужен максимальный throughput (2-4× быстрее)
Планируете работать с LLM моделями 70B+ параметров
Готовы разбираться с multi-GPU настройкой
Важна цена за производительность

Железо и стек: что внутри GB10 и почему это важно

Основные характеристики DGX Spark

Параметр	Значение
Архитектура	Blackwell (5 nm)
Память	128 GB unified LPDDR5X-9400
Пропускная способность памяти	273.2 GB/s
Вычислительные ядра	6 144 CUDA cores
Tensor Cores	5-го поколения с поддержкой FP4
TDP	140W (SOC) + 100W (остальные компоненты)
Сеть	ConnectX-7 SmartNIC, 2× QSFP (200 Gbps)

Networking: ConnectX-7 и кластеризация

Отдельного внимания заслуживает сетевая подсистема. Компьютер оснащен NVIDIA ConnectX-7 SmartNIC, то есть тот же чип, что используется в серверных решениях. На борту:

2× QSFP порта с суммарной пропускной способностью до 200 Gbps
Поддержка InfiniBand и RDMA over Converged Ethernet (RoCE)
GPUDirect RDMA для прямой передачи данных между GPU и сетью

Это позволяет объединять два DGX Spark в кластер: 256 GB общей памяти и возможность запускать модели до 405B параметров в FP4. Сам ConnectX-7 NIC это компонент стоимостью ~130-195 тысяч рублей, так что часть цены DGX Spark оправдана серверным сетевым компонентом.

Важно: Для кластеризации потребуется один сертифицированный QSFP-кабель для данных и отдельное Ethernet/Wi-Fi соединение для управления.

Cсылка на официальную страницу устройства.

Почему bandwidth здесь главное ограничение

Ключевое ограничение этого девайса — 273 ГБ/с пропускной способности памяти. Для сравнения:

GPU	Memory Bandwidth, GB/s	Соотношение к DGX Spark
DGX Spark	273	1×
RTX 4090	1 008	3.7×
RTX 5090	1 792	6.6×
2× RTX 3090 (NVLink)	1 872	6.9×

Это не ошибка разработчиков, а архитектурный выбор: LPDDR5X дает огромный объем при низком энергопотреблении, но при этом жертвует скоростью передачи данных.

Главный вывод: DGX Spark — это про объем, а не скорость. Unified memory позволяет загрузить модель целиком, но пропускная способность памяти определяет потолок производительности.

Как происходило тестирование: от синтетики к реальным сценариям

Главная цель тестирования – получить прикладную информацию о том, как устройство и сама архитектура Grace Blackwell 10 ведет себя в реальных сценариях инференса LLM и где находятся ее практические ограничения. Для этого методология строится вокруг главных параметров: размера модели, подаваемых на вход данных и метода квантизации.

Программный стек

Ubuntu 24.04.3 LTS
NVIDIA Driver 580.95.05
CUDA 13.0
vLLM 25.11 (без prefix caching для чистоты бенчмарка)

Весь код бенчмарка доступен на GitHub: github.com/PalatineVision/dgx-spark-benchmark

Модели

Было выбрано семейство Qwen3 как современная и хорошо оптимизированная линейка моделей:

0.6B — baseline для оценки максимальной скорости чипа
4B — типичная модель для локальных задач
14B — баланс качества и производительности
30B-A3B MoE — Mixture of Experts: 30B параметров, ~3B активных
32B — стресс-тест для архитектуры

Модели тестировались в нескольких форматах квантизации:

BF16 (Brain Float 16) - "гибрид" между FP16 и FP32, он занимает столько же места, сколько FP16 (половина от стандартного FP32), но сохраняет динамический диапазон полной точности (FP32) за счет снижения точности дробной части
FP8 — 8-битная квантизация (нативная поддержка Tensor Cores 5-го поколения)
AWQ 4-bit — Activation-aware Weight Quantization для максимальной пропускной способности
GPTQ-Int4 — Group-wise Post-Training Quantization, особенно эффективна для MoE-моделей
GGUF Q4 — популярный формат с отличной поддержкой в llama.cpp и Ollama (спойлер: на vLLM сейчас он работает плохо)

Датасеты

Выбрано три сценария, максимально приближенных к реальным задачам:

Датасет	Токенов на вход	Сценарий
low_context_chat	~70	Чат-боты, короткие запросы
middle_context_rag	1 000–4 000	RAG-системы, поиск по документам
long_context_rag	15 000–73 000	Анализ больших документов

Параметры тестирования

Concurrency: от 1 до 100 параллельных запросов
Output length: 1024 токена на ответ
Количество промптов: 50 для каждой конфигурации

Важно: был отключен prefix caching (--no-enable-prefix-caching) для измерения реальной производительности чипа. В production среде с кэшированием throughput может быть на 20-40% выше при повторяющихся системных промптах.

Заметка о программном стеке: Из-за ARM-архитектуры GB10 не все Docker-образы работают из коробки. Например, vLLM запускается только из официального образа NVIDIA (nvcr.io/nvidia/vllm), стандартный vllm/vllm-openai выдаёт ошибки. Также было зафиксированы семплы из датасета neural-bridge/rag-dataset-12000, чтобы сравнение было корректным и воспроизводимым, так как встроенные бенчмарки часто рандомизируют промпты, что даёт разброс от 97 до 300 tok/s на одной и той же конфигурации.

Четыре метрики, которые определяют все

Прежде чем смотреть на цифры, важно понимать, что они означают и когда какая метрика критична:

TTFT (Time To First Token)

Что измеряет: Время от отправки запроса до получения первого токена ответа.

Почему важна: Определяет ощущение «отзывчивости» системы. Пользователь видит, что система «думает», пока ждет первый токен.

Когда критична:

Интерактивные чат-боты (пользователь не любит ждать)
Стриминг ответов в реальном времени
UX-критичные приложения

Пример: TTFT равный 2-м секундам означает, что пользователь будет смотреть на пустой экран 2 секунды перед стартом ответа от LLM. Для чат-бота это много, а для batch-обработки документов уже приемлемо.

TPOT (Time Per Output Token)

Что измеряет: Среднее время генерации одного токена после первого.

Почему важна: Определяет скорость «печати» ответа. При TPOT = 100 ms токены появляются ~10 раз в секунду — это ко��фортная скорость чтения.

Когда критична:

Длинные ответы (суммарное время = TTFT + TPOT × количество токенов)
Стриминг, где слишком медленный TPOT создает «заикание»
Batch-обработка большого количества запросов

Пример: При TPOT = 300 ms ответ на 100 токенов займет 30 секунд только на генерацию. Для 32B модели на BF16 это реальность.

Throughput (tok/s)

Что измеряет: Общее количество токенов, генерируемых системой в секунду при параллельной обработке запросов.

Почему важна: Главная метрика для production-систем. Показывает, сколько пользователей система может обслужить одновременно.

Когда критична:

Production deployment с множеством пользователей
Batch-обработка документов
Оценка стоимости инференса (токены/$ или токены/ватт)

Формула связи: Throughput ≈ Concurrency / (TTFT + TPOT × avg_output_length)

Latency P99

Что измеряет: 99-й перцентиль задержки — время, за которое завершаются 99% запросов.

Почему важна: Показывает «худший случай» для пользователя. Средние значения могут скрывать редкие, но болезненные задержки.

Когда критична:

SLA-критичные системы
Финтех/медицина, где задержка это потерянные деньги или дополнительные риски
Системы с жесткими требованиями к latency

Пример: Средний TTFT = 500 ms, но P99 = 5 000 ms означает, что 1 из 100 пользователей ждет в 10 раз дольше остальных.

Бенчмарк: где GB10 летает, а где буксует

0.6B: когда память еще не bottleneck

Маленькие модели это идеальный сценарий для GB10. Память еще не является узким местом и чип показывает свой потенциал.

Квантизация	Dataset	Max Throughput, tok/s	TTFT, ms	TPOT, ms
FP8	low_context_chat	4 492	70	10.9
BF16	low_context_chat	3 966	87	12.3
FP8	middle_context_rag	1 007	343	24.7
BF16	middle_context_rag	1 043	982	43.1
FP8	long_context_rag	788	529	29.2
BF16	long_context_rag	813	1 079	45.2

Выводы:

FP8 дает +13% на коротких промптах благодаря оптимизации Tensor Cores
На длинном контексте разница минимальна, память еще не становится bottleneck
Throughput падает в 5 раз при переходе от коротких к длинным промптам

Дополнительные графики для Qwen3-0.6B

4B: рабочий вариант с неожиданными открытиями

Достаточно типичный выбор для локального инференса это модели на 4B параметров. Здесь уже начинают проявляться эффекты квантизации на этом устройстве.

Квантизация	Dataset	Max Throughput, tok/s	TTFT, ms	TPOT, ms
AWQ 4-bit	low_context_chat	2 124	331	22.3
FP8	low_context_chat	1 636	209	29.8
BF16	low_context_chat	1 034	245	47.5
GGUF Q4	low_context_chat	409	2 786	111.9
AWQ 4-bit	middle_context_rag	528	4 643	75.2
FP8	middle_context_rag	530	3 411	79.0
GGUF Q4	middle_context_rag	105	44 660	298.6

Ключевые выводы:

AWQ дает 2× прирост над BF16 на коротких промптах (2 124 vs 1 034 tok/s)
FP8 прибавляет +58% над BF16, что является хорошим компромиссом качества и скорости
GGUF Q4 сейчас сильно проигрывает: в 2.5-5 раз медленнее AWQ

Почему GGUF показал такие плохие результаты?

Это было большим разочарованием для тех, кто надеялся использовать GGUF как универсальный формат и причина здесь в особенностях реализации формата актуальной версии vLLM, которая использовалась на момент проведения бенчмарка (v25.11).

Согласно официальной документации vLLM:

"GGUF support in vLLM is highly experimental and under-optimized at the moment, and it might be incompatible with other features. Currently, you can use GGUF as a way to reduce memory footprint."

Ключевые ограничения GGUF в vLLM:

Поддерживаются только single-file GGUF модели
Конвертация токенизатора нестабильна и занимает много времени
Многие архитектуры не поддерживаются (включая некоторые версии Qwen)
Требуется ручное скачивание файлов, нельзя просто указать HuggingFace path

Совет: GGUF имеет отличную поддержку и оптимизацию в llama.cpp и Ollama. Для vLLM используйте AWQ или FP8, так как они лучше оптимизированы под этот inference-движок.

Дополнительные графики для Qwen3-4B

Сравнение BF16 / FP8 / AWQ:

Сравнение с GGUF (наглядная демонстрация провала):

14B: баланс качества и производительности

14B модель помещается на GB10 с большим запасом (~7 GB в AWQ, ~14 GB в FP8), при этом она достаточно умная для production-задач. Здесь квантизация раскрывается в полную силу.

Квантизация	Dataset	Max Throughput, tok/s	TTFT, ms	TPOT, ms
AWQ 4-bit	low_context_chat	914	697	52.1
FP8	low_context_chat	599	637	81.3
BF16	low_context_chat	340	880	144.1
FP8	middle_context_rag	257	9 607	152.6
AWQ 4-bit	middle_context_rag	251	14 264	140.6
BF16	middle_context_rag	179	12 536	222.6
FP8	long_context_rag	203	10 226	157.3
AWQ 4-bit	long_context_rag	198	15 131	145.3
BF16	long_context_rag	143	13 365	226.8

14B это довольно подходящий размер модели для DGX Spark. Модель достаточно умная для production-задач, при этом в AWQ-квантизации выдаёт 914 tok/s на коротких промптах, что комфортно даже для 20-30 одновременных пользователей. Если думаете, с какой модели начать – начните с 14B с AWQ.

Валерий Гречин, руководитель Palatine Vision

Ключевые выводы:

AWQ даёт +169% над BF16 на коротких промптах (914 vs 340 tok/s)
FP8 лучше на RAG-задачах: на middle_context FP8 обходит AWQ (257 vs 251 tok/s), TTFT на 33% быстрее (9 607 vs 14 264 ms)
TTFT парадокс: AWQ kernel медленнее на prefill из-за дополнительных dequant операций – 14 264 ms vs 9 607 ms у FP8
14B наиболее оптимальна для GB10: помещается с запасом и достаточно умная для production
Рекомендация: AWQ для chatbot, FP8 для RAG

Дополнительные графики для Qwen3-14B

Критичные для понимания графики:

30B-A3B (MoE): знания 30B по цене 3B

MoE (Mixture of Experts) это архитектура, которая хранит все 30B параметров в памяти, но активирует только ~3B. Что это означает на практике: качество на уровне 30B модели, а стоимость инференса как у 3B модели. На GB10 эта архитектура показала себя лучше всех.

Квантизация	Dataset	Max Throughput, tok/s	TTFT, ms	TPOT, ms
GPTQ-Int4	low_context_chat	730	415	67.1
FP8	low_context_chat	493	369	100.4
BF16	low_context_chat	265	632	186.8
GPTQ-Int4	middle_context_rag	361	6 224	111.8
FP8	middle_context_rag	311	4 962	137.2
BF16	middle_context_rag	185	8 019	231.5
GPTQ-Int4	long_context_rag	291	6 675	112.3
FP8	long_context_rag	241	5 384	145.0
BF16	long_context_rag	145	8 728	241.7

MoE-модели это, пожалуй, главная находка бенчмарков. Qwen3-30B-A3B по сути даёт вам «мозги» 30-миллиардной модели, а обходится по вычислениям как 3-миллиардная. На DGX Spark это работает идеально: 730 tok/s в GPTQ быстрее, чем dense 32B в AWQ, при том же объёме памяти. Если вам нужен максимум качества при приемлемой скорости, то MoE в GPTQ-Int4 ваш выбор.

Валерий Гречин, руководитель Palatine Vision

Ключевые выводы:

GPTQ-Int4 критичен: +175% на low_context, +95% на middle, +101% на long vs BF16
MoE 30B-A3B GPTQ (730 tok/s) на 64% быстрее Dense 32B AWQ (444 tok/s) на коротких промптах
На middle_context: 361 vs 116 tok/s это 3× преимущество над Dense 32B!
TTFT значительно ниже: 415 ms vs 2212 ms у Dense 32B (GPTQ vs AWQ) благодаря ~3B активных параметров
MoE — оптимальная архитектура для GB10

Сравнение MoE vs Dense:

Метрика	MoE 30B-A3B GPTQ	Dense 32B AWQ	Dense 14B AWQ
low_context	730 tok/s	444 tok/s	914 tok/s
middle_context	361 tok/s	116 tok/s	251 tok/s
long_context	291 tok/s	91 tok/s	198 tok/s
Memory	~15 GB	~16 GB	~7 GB
TTFT (low)	415 ms	2 212 ms	697 ms

Дополнительные графики для Qwen3-30B-A3B MoE

Критичные для понимания графики:

32B: здесь начинается борьба с физикой

Модели на 32B параметров это стресс-тест для системы. Здесь GB10 показывает свои ограничения.

Квантизация	Dataset	Max Throughput, tok/s	TTFT, ms	TPOT, ms
AWQ 4-bit	low_context_chat	444	2 212	104.5
FP8	low_context_chat	278	1 397	174.9
BF16	low_context_chat	152	2 004	322.5
AWQ 4-bit	middle_context_rag	116	34 490	290.8
FP8	middle_context_rag	124	21 097	310.8
BF16	middle_context_rag	83	28 783	476.7

Когда впервые увидел TTFT в 34 секунды на длинном контексте, то настройки были перепроверены трижды. Казалось, что-то сломалось. Все-таки нет, все верно: это не ошибка, а архитектурный потолок LPDDR5X. Unified memory дает объем, но забирает bandwidth.

Валерий Гречин, руководитель Palatine Vision

Ключевые выводы:

AWQ критичен: 3× разница с BF16 (444 vs 152 tok/s)
Парадокс FP8: на среднем контексте FP8 быстрее AWQ (+7%)
- Причина: FP8 лучше обрабатывается тензорными ядрами при большом KV-cache
BF16 на 32B можно использовать только для исследовательских задач, применение в продуктовой среде же нецелесообразно

Дополнительные графики для Qwen3-32B

Критичные для понимания графики:

Квантизация: когда помогает, а когда бесполезна

Общие закономерности

Размер модели	Эффект квантизации	Рекомендация
0.6B	Минимален (±13%)	Не обязательна
4B	FP8 +58%, AWQ +106%	AWQ для chatbot, FP8 для RAG
14B	FP8 +76%, AWQ +169%	AWQ для chatbot, FP8 для RAG
30B-A3B MoE	FP8 +86%, GPTQ +175%	GPTQ-Int4 для всех задач
32B	AWQ +192% vs BF16	Обязательна

Что работает, а что нет

✅ AWQ 4-bit — лучший выбор для vLLM на коротких контекстах
✅ GPTQ-Int4 — оптимален для MoE-моделей, +175% на chatbot-задачах
✅ FP8 — отличный компромисс, особенно на средних контекстах
❌ GGUF — экспериментальная и неоптимизированная поддержка в vLLM, используйте только для llama.cpp или Ollama

Тут важно помнить: квантизация ускоряет не за счет меньшего количества вычислений, а за счет меньшего объема данных, которые нужно прогнать через память. А DGX Spark как раз работает в memory-bound режиме 90% времени.

Потолок на 50 запросах: почему больше не значит быстрее

Одна из самых интересных находок бенчмарка — эффект плато.

При увеличении concurrency от 1 до 50 throughput растет почти линейно. Но после 50 параллельных запросов происходит полная остановка роста, вариация при этом менее 1%.

Concurrency	Throughput 32B AWQ, tok/s	Изменение
5	59	—
20	180	+205%
50	443	+146%
70	443	0%
100	443	0%

Когда это было обнаружено, снова возникли мысли «наверное, что-то не так с настройками vLLM». Покрутил параметры, перезапустил с разными конфигами. Результат тот же. Это не софт, а та же физика: 273 ГБ/с пропускной способности памяти определяют жесткий потолок, который не обойти кодом.

Валерий Гречин, руководитель Palatine Vision

Причина: Пропускная способность памяти перегружена и все запросы стоят в очереди на доступ к памяти.

Практический вывод: Масштабировать нагрузку выше 50 параллельных запросов на одном DGX Spark бессмысленно. Для обработки большей нагрузки необходимо использовать кластеризацию через ConnectX-7.

Почему GPU простаивает: разбор узких мест

Простое объяснение: память vs вычисления

Представьте конвейер на заводе. Есть два этапа:

Подвоз материалов (загрузка данных из памяти)
Сборка (вычисления на GPU)

Если сборщики работают быстрее, чем им подвозят материалы, то конвейер простаивает. Это называется memory-bound (ограничение по памяти).

Инференс LLM это именно такой случай.

При генерации каждого токена GPU должен:

Загрузить все веса модели из памяти (~64 ГБ для 32B модели в BF16)
Выполнить относительно простые вычисления (умножение матрицы на вектор)

Тут и возникает проблема: на каждые 2 байта загруженных данных GPU выполняет всего ~2 операции. А мог бы выполнить ~300 операций за то же время, пока данные едут из памяти.

Считаем на пальцах

Для DGX Spark:

Memory bandwidth: 273 ГБ/с (скорость «подвоза материалов»)
Compute: ~80 TFLOPS (скорость «сборки»)

Сколько операций GPU может сделать, пока ждет 1 байт из памяти?

# 80 000 млрд операций/с ÷ 273 млрд байт/с ≈ 293 операции на байт

Сколько операций реально нужно при генерации токена?

При умножении матрицы весов на вектор (основная операция при decode):

На каждый элемент весов (2 байта в BF16) делается 2 операции
Итого: ~1 операция на байт

Вывод: GPU мог бы делать 293 операции пока ждет данные, а нужно всего одну. Вычислительная мощность используется на 0.3%. Остальное время GPU ждет данные из памяти.

Именно поэтому квантизация так эффективна на этом устройстве: AWQ 4-bit уменьшает размер модели в 4 раза → в 4 раза меньше данных нужно гонять через память → в ~3 раза выше throughput.

Теория vs практика: откуда 35× разница

Для Qwen3-32B BF16:

Размер модели: 64 ГБ
Наивный расчет: 273 ГБ/с ÷ 64 ГБ = 4.3 токенов в секунду
Реальный результат: 152 токена в секунду
Разница: 35×

Откуда возникает такой выигрыш?

Батчинг: веса загружаются один раз, но обрабатываются сразу 50 запросов
Pipelining: vLLM загружает следующий слой, пока GPU считает текущий
KV-cache: не перечитываем весь промпт на каждом токене

Но есть потолок: при concurrency > 50 выигрыш от батчинга исчерпывается и мы упираемся в физику памяти.

Итоги

Ожидания vs реальность

Что обещают	Что в реальности	Комментарий
128 ГБ unified memory — запускай любые модели	70B+ работают, но ~20 tok/s	Объем есть, а bandwidth нет
Blackwell — новейшая архитектура	FP8/FP4 быстрее только на коротких контекстах	На long context выигрыш теряется
Компактный форм-фактор для офиса	✅ Верно: тихий, 140W	Исказить реальность было бы сложно)
ConnectX-7 для кластеризации	✅ Два устройства = 256 GB, до 405B моделей	Серверный networking из коробки
Альтернатива дата-центру	Скорее альтернатива рабочей станции с 2×RTX	Для настоящего уровня ДЦ нужны H100/H200
Unified memory = нет проблем с VRAM	Нет проблем с объемом, но есть с bandwidth	Маркетинг умалчивает про 273 ГБ/с vs 1.8+ ТБ/с

Что совпало с маркетингом:

✅ Простота развертывания — одно устройство и один процесс vLLM
✅ Энергоэффективность — реально 140W под нагрузкой
✅ Модели до 32B — комфортная работа в квантизации
✅ Серверный networking — ConnectX-7 с InfiniBand/RDMA

Что маркетинг умолчал:

❌ Bandwidth LPDDR5X создает жесткий потолок
❌ Long context (>15K токенов) — TTFT до 34 секунд
❌ Не подходит для обучения моделей

Применение в промышленности

Промышленность и производство

Интеграторы, работающие с промышленными предприятиями регулярно видят один и тот же запрос: «нужен ИИ, но данные не должны покидать периметр, ставить серверную стойку негде или протянуть кабели не сможем, а облако нельзя по регламентам». DGX Spark вполне закрывает часть таких запросов лучше любого другого устройства на рынке, особенно там, где не справляются устройства от Raspberry Pi до NVIDIA Jetson.

Автономная работа в закрытом контуре

На производстве часто нет стабильного интернета или облако прямо запрещено регламентами (как минимум ОПК, критическая инфраструктура, предприятия с гостайной). DGX Spark же работает полностью автономно, а 128 GB unified memory вмещают модель, векторную базу и ОС в одном устройстве. Это принципиально отличает его от решений на consumer GPU, которые требуют серверной инфраструктуры: блока питания на 1 200W+, охлаждения и стойки.

Для объектов атомной энергетики вопрос автономности критичен. Любое решение, требующее постоянного доступа в интернет или передачи данных за пределы периметра, практически невозможно внедрить из-за регламентов. Формат, когда модель работает локально и дает результат прямо на площадке, существенно упрощает внедрение ИИ в процессы диагностики и эксплуатации оборудования.

Сергей Гречин, заместитель начальника отдела технической диагностики Курской АЭС-2

Визуальный контроль качества

Edge AI прямо в цеху это всего 140W, компактный форм-фактор, не требующий серверной комнаты и промышленного кондиционера. Модели 4B-14B могут справляться с классификацией определенных дефектов: 4B AWQ выдаёт 2 124 tok/s, что с запасом покрывает часть сценариев. При этом устройство стабильно работает часами – за время многочасовых тестовых сессий температура GPU не превышала 80°C и троттлинг не наблюдался.

Когда камеры находятся далеко от вычислительного узла, длинные кабельные трассы начинают создавать дополнительные точки отказа: от помех до потери качества изображения. Локальная обработка прямо в цеху значительно упрощает архитектуру системы и повышает надежность контроля.

Павел Кривенчук, технический руководитель проектов по автоматизации и механизации на производстве медицинских пробирок и игл

Анализ технической документации

RAG по ГОСТ, ТУ, паспортам оборудования, регламентам ТО – подходящая задача для MoE 30B-A3B. На middle_context_rag эта модель выдаёт 361 tok/s в GPTQ-Int4 с хорошим качеством 30B модели для работы со сложными нормативными документами без обращения к облаку. Инженер на площадке может задать вопрос по регламенту и получить ответ за секунды, а не искать нужный раздел в 500-страничном PDF.

Цифровой помощник оператора

На производственных линиях, где оператор работает с десятками параметров процесса, LLM-агент на DGX Spark может выступать интеллектуальным ассистентом для интерпретации показаний приборов, выдаче подсказок по настройке в соответствии с инструкциями и анализ отклонений от нормы (хотя здесь чаще эффективнее использовать другой класс ML моделей). MoE 30B-A3B в GPTQ-Int4 (730 tok/s chat, TTFT 415 ms) обеспечивает мгновенный отклик и оператор может задавать вопрос голосом, получая ответ в считанные секунду.

Масштабирование на производстве

Начать можно с одного DGX Spark в пилотном цеху. Когда задача подтвердит ROI, далее масштабировать через ConnectX-7, где два устройства дадут 256 GB unified memory, позволяя вмещать модели до 405B в FP4. Серверный networking (InfiniBand, RDMA) здесь уже встроен и не нужно докупать сетевое оборудование серверного класса.

Производственники часто приходят с запросом «хотим ИИ на площадке, но данные ни в коем случае не должны покидать периметр». Раньше часто как решение предлагались серверные стойки с A100 или аналогичными GPU. Это дорого, еще сильнее зашумляет зону и нередко требует отдельного помещения с квалифицированным обслуживанием. DGX Spark это устройство, которое можно поставить в шкаф рядом с ПЛК или, если позволяют условия, даже закрепить на самой конвейерной линии и получить инференс 30B-класса моделей. Для цифровизации производства это качественный сдвиг.

Валерий Гречин, руководитель Palatine Vision

Проведение пресейлов и демо

На этапе пресейла часто возникает задача показать работу моделей прямо на данных заказчика до подписания договора. Обычно это означает логистику тяжелого оборудования: полноценной рабочей станции или серверного решения, где только доставка может стоить десятки тысяч и заметно увеличивать стоимость пресейла.

DGX Spark меняет эту ситуацию. Устройство можно привезти как обычное компактное оборудование, быстро развернуть на площадке и запустить инференс прямо в цеху, без подготовки серверной инфраструктуры и сложного монтажа. Это позволяет в тот же день проверить реальные данные клиента, провести демо в рабочих условиях и мгновенно подтвердить техническую реализуемость решения.

Для интеграторов это снижает стоимость пресейлов, сокращает цикл сделки и дает возможность быстрее переходить от демонстрации к пилоту.

Применение для малого и среднего бизнеса

Локальные RAG-системы

128 GB unified memory это модель + векторная база + ОС. MoE 30B-A3B в GPTQ-Int4 на RAG-задачах выдаёт 361 tok/s, что вполне достаточно для корпоративной базы знаний с десятками пользователей.

Чат-боты техподдержки

14B AWQ выдает 914 tok/s на коротких запросах с TPOT 52 ms, выдавая комфортный стриминг для 20-30 одновременных пользователей.

Автоматизация отчетности и документооборота

Анализ договоров, генерация отчетов, извлечение данных из неструктурированных документов. 32B AWQ (444 tok/s) обеспечивает максимальное качество для сложных задач с пониманием контекста.

Конфиденциальность

Данные клиентов не уходят в облако, что критично для соответствия GDPR и 152-ФЗ. Все обрабатывается локально, аудит и контроль полностью на стороне предприятия.

Разработчики и стартапы

AI-разработчики: локальная разработка и тестирование без облачных API. Модели до 32B в квантизации работают комфортно, а итерация промптов мгновенная.

Исследователи: fine-tuning моделей до 7B, QLoRA на 14-32B. 128 GB unified memory снимает ограничение по VRAM, которое мешает на consumer GPU.

Стартапы: прототипирование AI-продуктов без дата-центра. От идеи до MVP на одном устройстве, без аренды облачных GPU и риска утечки интеллектуальной собственности.

Сравнение DGX Spark vs RTX сборок

Технические характеристики GPU

Параметр	DGX Spark (GB10)	RTX 3090	RTX 4090	RTX 5090
Архитектура	Blackwell	Ampere	Ada Lovelace	Blackwell
CUDA Cores	6 144	10 496	16 384	21 760
Tensor Cores	5th gen	328 (3rd gen)	512 (4th gen)	680 (5th gen)
VRAM	128 GB LPDDR5X	24 GB GDDR6X	24 GB GDDR6X	32 GB GDDR7
Memory BW	273 GB/s	936 GB/s	1 008 GB/s	1 792 GB/s
TDP	140W	350W	450W	575W
NVLink	Нет (есть ConnectX-7)	Да (600 GB/s)	Нет	Нет
Цена	~400-500k ₽	~50-80k ₽ (б/у)	~280-330k ₽	~350-600k ₽

Сравнение конфигураций

Параметр	DGX Spark	2× RTX 3090	2× RTX 4090	2× RTX 5090
Суммарный VRAM	128 GB unified	48 GB (раздельно)	48 GB (раздельно)	64 GB (раздельно)
Memory bandwidth	273 GB/s	1 872 GB/s (NVLink)	2 016 GB/s	3 584 GB/s
TDP	140W	700W	900W	1 150W
Цена	~400-500k ₽	~100-140k ₽	~560-660k ₽	~400k ₽
Multi-GPU	ConnectX-7 (кластер)	NVLink (tensor parallel)	PCIe only	PCIe only

Оценка производительности инференса LLM

Модель	DGX Spark, AWQ (tok/s)	2× RTX 3090, FP16 (tok/s)	2× RTX 4090, FP16 (tok/s)	2× RTX 5090, FP16 (tok/s)
7B	~2 000	~3 500	~3 000	~5 000
14B	~914 (AWQ)	~2 500	~2 200	~3 500
30B-A3B MoE	~730 (GPTQ)	~1 800	~1 500	~2 500
32B	~444	~1 200	~1 000	~1 800
70B	~50	~600	~500	~900

Оценка для RTX 5090 на основе bandwidth ratio. RTX 4090 без NVLink страдает от PCIe overhead.

Если бы мне год назад сказали, что я буду рекомендовать б/у видеокарты как конкурента новому железу от NVIDIA – не поверил бы. Но цифры есть цифры и в чистом throughput две 3090 с NVLink выигрывают, а стоят в 3-5 раз дешевле. Другой вопрос — сколько времени вы потратите на настройку тензорного параллелизма и охлаждение 700-ваттного+ монстра.

Валерий Гречин, руководитель Palatine Vision

Считаем ROI: когда DGX Spark окупается за год

Энергоэффективность

При работе 24/7 и тарифе 8 ₽/кВт·ч:

Конфигурация	Потребление, Вт	Стоимость/год, ₽
DGX Spark	140	~10 000
2× RTX 3090	700	~49 000
2× RTX 4090	900	~63 000
2× RTX 5090	1 150	~81 000

Экономия: 40-70k ₽/год на электричестве по сравнению с RTX-сборками.

Дополнительные расходы RTX-сборок

Блок питания 1 200-1 600W: 20-40k ₽
Охлаждение/кондиционирование: от 50k ₽
Корпус/стойка с хорошей вентиляцией: 15-30k ₽
Время на настройку тензорного параллелизма: бесценно

Кому брать девайс, а кому – точно нет

✅ Идеален для:

1. Разработчиков AI-приложений

Локальная разработка и отладка LLM-агентов
Быстрая итерация промптов без облачных API
Комфортная работа с моделями до 32B в подходящей квантизации

2. Малый бизнес с локальными RAG-системами

Вычисления на локальной машине обеспечивают полную конфиденциальность данных
Если 10-50 пользователей и 400-2 000 tok/s будет достаточно
128 GB памяти для модели + векторной базы + ОС

3. Edge AI в корпоративных средах

140W TDP это стандартная офисная стойка
Тихая работа vs ревущие RTX 4090

4. Кластерные решения на 2 устройства

256 GB unified memory через ConnectX-7
Модели до 405B в FP4
InfiniBand/RDMA для низкой задержки между нодами

140 ватт это не просто цифра в спецификации. Это возможность поставить DGX Spark в обычный офис без промышленного кондиционера. После визитов в дата-центры с серверами на несколько 4090 или А100, где один GPU потребляет как микроволновка и издает звуки реактивного двигателя, это ощущается совершенно иначе.

❌ Не подходит для:

1. High-throughput production (>100 req/s)

Плато на 50 запросах из-за архитектурных ограничений
Для нагруженных сервисов нужны A100/H100

2. Обучение моделей

Memory bandwidth недостаточен для эффективного обучения

3. Длинный контекст (>100K токенов)

TTFT до 34 секунд — почти всегда неприемлемо для UX

4. Модели 70B+ на одном устройстве

Технически запустится, но ~50 tok/s это очень медленно
Для 70B+ нужен кластер из 2 DGX Spark или RTX-сборка

Вердикт и итоговые рекомендации

Сценарий	DGX Spark	2× RTX 3090	2× RTX 4090	2× RTX 5090
Разработка AI-агентов	Отлично	Хорошо	Средне	Хорошо
Малый бизнес с RAG	Отлично	Хорошо	Средне	Хорошо
Production (>100 req/s)	Плохо	Отлично	Хорошо	Отлично
Модели 70B+	Плохо	Отлично	Хорошо	Отлично
Энергоэффективность	Отлично	Плохо	Плохо	Плохо
Цена/производительность	Средне	Отлично	Плохо	Хорошо
Простота настройки	Отлично	Средне	Средне	Средне

Выбирайте DGX Spark если:

Нужна простота — одно устройство, unified memory, никакого multi-GPU
Работаете с моделями до 32B
Критична энергоэффективность и тишина
Конфиденциальность данных это приоритет
Планируете масштабирование через кластеризацию (ConnectX-7)

Выбирайте 2× RTX 3090 если:

Бюджет ограничен (в 3-5 раз дешевле)
Нужен максимальный throughput
Планируете работать с 70B+ моделями
Готовы потратить время на настройку и охлаждение
Важен NVLink для эффективного тензорного параллелизма

Выбирайте 2× RTX 4090 если:

Нужна максимальная производительность и не критична цена
Планируете использовать для gaming/rendering задач помимо AI
Не критичен NVLink (его нет на 4090)

Выбирайте 2× RTX 5090 если:

Нужен баланс цены и производительности
Хотите Blackwell на consumer GPU
Готовы к 1150W энергопотребления
Не критичен NVLink (его нет на 5090)

Заключение

NVIDIA DGX Spark это специализированное решение, а не универсальная рабочая лошадка. Его архитектурные компромиссы (низкий bandwidth, большой объем объединенной памяти, низкое энергопотреблен��е) делают его идеальным для:

Edge AI и IoT
Конфиденциальных вычислений с чувствительными данными
Разработки на малых и средних моделях (до 14B) и MoE-моделях (30B-A3B)
Кластеризации через ConnectX-7 для больших моделей

MoE-модели — главная находка бенчмарков: Qwen3-30B-A3B в GPTQ-Int4 на 64% быстрее Dense 32B AWQ на chatbot-задачах и в 3× на RAG при сопоставимом memory footprint. Если вам нужен максимум качества от GB10, то MoE в GPTQ-Int4 ваш выбор.

Эффект плато на 50 запросах это фундаментальное ограничение пропускной способности LPDDR5X. А квантизация (FP8/AWQ) единственный путь к масштабированию производительности в этих условиях.

Для промышленных предприятий DGX Spark открывает путь к Edge AI без компромиссов: аналитика прямо на производственной площадке, анализ технической документации без облака, контроль качества с ML-моделями и все это в форм-факторе настольного компьютера с энергопотреблением 140W. А возможность кластеризации через ConnectX-7 позволяет масштабировать решение по мере роста масштаба задач.

Стоит ли переплачивать? Зависит от ваших приоритетов:

Если важны простота, тишина и энергоэффективность — да, DGX Spark оправдывает свою цену
Если нужен максимальный throughput за минимальные деньги — б/у RTX 3090 будут лучшим выбором
Если хотите современную архитектуру с максимальной производительностью — присмотритесь к RTX 5090

Бенчмарки проведены на NVIDIA DGX Spark (GB10) с 128 GB LPDDR5X, 273.2 GB/s bandwidth. Использовался vLLM без prefix caching, модели Qwen3 0.6B-32B (включая MoE 30B-A3B) в форматах BF16/FP8/AWQ/GPTQ/GGUF. В production среде с включенным кэшированием показатели throughput могут быть на 20-40% выше.

Репозиторий с кодом бенчмарка: github.com/PalatineVision/dgx-spark-benchmark

Буду рад замечаниям по бенчмарку и другим комментариям.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

40%110

28%07

32%Нужно крепко подумать…8

Проголосовали 25 пользователей. Воздержались 2 пользователя.