DeepSeek DSpark на двух DGX Spark: порт, баг и бенчмарки
DeepSeek DSpark запустили на двух DGX Spark. Разбираем порт V4 Flash, sampling-slot bug, NVFP4-KV, бенчмарки и границы применимости цифр.
Факты проверены 5 июля 2026 года. DeepSeek DSpark на двух DGX Spark - практический тест слоя спекулятивного декодирования для DeepSeek V4 Flash на малом железе. Главный вопрос здесь не в самом запуске модели, а в том, где ускорение держится, где ломается когерентность и какие цифры нельзя переносить в заголовок без оговорок.
Базовый разбор DSpark у нас уже есть: как DeepSeek ускоряет инференс без новой модели. Новый материал закрывает другой интент - конкретный порт на 2x DGX Spark/GB10, sampling-slot bug, fp8/NVFP4-KV и бенчмарки конфигурации сообщества. Для фона по самой линейке V4 можно отдельно открыть разбор DeepSeek V4 Pro и Flash; здесь не повторяем весь обзор модели.
Что изменилось после базового DSpark-разбора
На Habr 5 июля вышел технический отчёт о запуске DeepSeek-V4-Flash-DSpark на двух DGX Spark. Авторы описывают путь от нерабочего публичного vLLM-режима для GB10/SM121 в окне 27-30 июня до собственного порта, патча sampling-логики и повторных замеров. Официальным бенчмарком DeepSeek он не считается, зато хорошо показывает, как DSpark ведёт себя не в дата-центровом профиле, а на двух компактных узлах с ограниченной памятью и межнодовой связью.
Официальная карточка Hugging Face задаёт главное ограничение: DeepSeek-V4-Flash-DSpark - тот же checkpoint с добавленным модулем спекулятивного декодирования, а не новая базовая модель. Поэтому корректный заголовок говорит о порте и бенчмарках, а не о «новом DeepSeek».
| Что проверено | Что нельзя обобщать |
|---|---|
| DeepSeek-V4-Flash-DSpark работает на 2x DGX Spark/GB10 в конкретных fp8 и NVFP4-KV конфигурациях. | Что любой владелец DGX Spark получит те же tok/s без того же образа, патчей и профиля нагрузки. |
| Исправление sampling-slot bug заметно подняло acceptance и throughput в тестовом порте. | Что вся разница между fp8 и NVFP4 объясняется одной строкой кода. |
| NVFP4-KV рецепт дал заметный выигрыш в single-stream и aggregate-режимах. | Что 1M или 1.5M context стабильно полезны для любого длинного агентного сценария. |
| На большой глубине контекста скорость выходит на полку, а когерентность иногда становится главным риском. | Что acceptance rate сам по себе гарантирует качество ответа. |
Почему порт на DGX Spark потребовал патчей
DSpark относится к стеку DeepSpec: draft-модуль предлагает несколько токенов вперёд, target-модель проверяет их пачкой, а выигрыш зависит от того, сколько предложенных токенов принято. В официальном DeepSpec-репозитории это описано как полный стек для обучения и оценки draft-моделей спекулятивного декодирования; код открыт под MIT-лицензией.
В отчёте Habr проблема была не в идее DSpark, а в посадке на GB10/SM121 и vLLM. Авторы пишут, что в доступном им публичном пути method=dspark не проходил конфигурационную валидацию, поэтому порт делали поверх форка сообщества. Потом пришлось чинить слой hidden states, нормализацию, non-causal видимость внутри блока и устойчивость sparse-MLA metadata под конкурентной нагрузкой.
Это важная деталь для читателя, который разворачивает LLM сам. Статья не заменяет гайд по vLLM-серверу: здесь нет пошагового рецепта запуска. Но она хорошо показывает типичный инженерный риск: модельная карточка может выглядеть готовой, а реальное обслуживание запросов на новой архитектуре упирается в enum, kernel path, KV-cache и профиль батча.
Sampling-slot bug: что исказило измерения
Самая показательная часть Habr-отчёта - не график, а баг на один индекс. По описанию авторов, унаследованный kernel сэмплил draft-токены не из нужного bonus-слота, а из noise-слота. После сдвига индекса acceptance первой позиции поднялся с 0.41 до 0.74, средняя принятая длина - с 1.75 до 2.5, throughput в debug-прогоне - с 26 до 36 tok/s.
Эта история полезнее громкой цифры «ускорилось». Она показывает, почему бенчмарки спекулятивного декодирования хрупкие: маленькая ошибка в том, какие токены draft предлагает target-модели, превращает весь режим в шум. А если мерить только итоговые tok/s, можно долго спорить о fp8, KV-cache и железе, не заметив, что драфт смотрит не туда.
Бенчмарки 2x DGX Spark: как читать tok/s
В single-stream fp8-профиле Habr получил 26.7 tok/s без спекуляции и 32.4 tok/s с DSpark, то есть около +21-24%. Это выглядит скромнее, чем заголовочные цифры DeepSeek 60-85%, но сравнение некорректно без контекста: у DeepSeek другая точка отсчёта, другое железо и метрика скорости на пользователя при сопоставимой общей пропускной способности. В тесте на DGX Spark авторы измеряли свой порт и свой профиль обслуживания запросов.
Главный выигрыш на малом железе проявился в конкурентности. В fp8-замерах DSpark дал около 99 tok/s aggregate на 8 потоках и 141-146 tok/s на 12 потоках. Рецепт NVFP4-KV от tonyd2wild сообщает ещё более сильный режим: max_model_len=1500000, max_num_seqs=12, KV pool 3 225 280 токенов, single-stream выше 50 tok/s и C16-static 315.1 tok/s aggregate на 200K. Habr пишет, что воспроизвёл C16-static примерно на 324 tok/s с разбросом 282-330.
| Замер | Цифра | Как читать |
|---|---|---|
| fp8 no-spec single-stream | 26.7 tok/s | Контроль без спекулятивного декодирования. |
| fp8 DSpark single-stream | 32.4 tok/s | +21-24% в конкретном порте, не универсальная оценка DSpark. |
| fp8 DSpark, 12 потоков | 141-146 tok/s aggregate | Выигрыш заметнее в multi-user режиме. |
| NVFP4-KV C16-static | 315.1 tok/s в рецепте, около 324 tok/s при воспроизведении | Конфигурация сообщества на 200K context; не официальный бенчмарк DeepSeek. |
| NVFP4-KV глубина 1.03M | 17.2 tok/s single-stream | После 512K скорость выходит на полку, но качество ответа остаётся отдельным риском. |
Где нельзя обобщать 1M и 1.5M context
Самая опасная ошибка - превратить max_model_len=1500000 в обещание «полтора миллиона токенов работают». В GitHub-рецепте это параметр конкретной конфигурации с NVFP4-KV, TP=2 и заданным max_num_seqs. В Habr-графике скорость на глубине падает с 42.7 tok/s при 16K до 17.6 tok/s при 512K и 17.2 tok/s при 1.03M. После 512K нет резкого обвала, но есть другой риск: на глубине от 256K авторы видели петли когерентности, а acceptance в такой ситуации может выглядеть лучше, чем реальное качество.
Отсюда практический вывод для команд, которые строят агентные системы. DSpark и NVFP4-KV помогают выжать больше throughput из пары DGX Spark, особенно при нескольких параллельных сессиях. Но длинный контекст не заменяет проверку качества на собственных задачах. Если модель быстрее повторяет мусор, график tok/s не спасает продукт.
Вывод
Материал про DSpark на двух DGX Spark интересен не рекордом, а инженерной честностью. В нём есть успешный порт, баг, который меняет всю картину, воспроизведение чужого рецепта, негативные результаты и аккуратная граница применимости. Для маленького железа это хороший сигнал: слой обслуживания запросов всё ещё даёт ощутимый выигрыш, но каждый процент скорости нужно привязывать к конфигурации, профилю нагрузки и качеству ответа.
Если коротко: отдельный материал оправдан именно как техническое продолжение про железо. Базовый ответ на вопрос «что такое DSpark и почему это не новая модель» остаётся в предыдущем разборе. Здесь главный урок другой: на 2x DGX Spark ускорение рождается не из одного флага, а из цепочки мелких решений - KV-cache, draft acceptance, потолка батча, sampling и проверки длинного контекста.
