# Почему опубликованные скорости DeepSeek на DGX Spark расходятся между собой > Одна и та же модель на тех же двух узлах GB10 публикуется со скоростями от конца пятидесятых до начала семидесятых токенов в секунду. Каждая из этих цифр может быть верной — вот конфигурация за каждой и какую цитировать под какой вопрос. - Published: 2026-08-13 - Evidence level: lab_single_run - Funding: Собственное финансирование, внутреннее исследование - Canonical: https://agmind.ai/ru/reports/dspark-speed-numbers-disagree/ Спросите ассистента, с какой скоростью DeepSeek-V4-Flash работает на паре DGX Spark, — получите число. Спросите завтра — можете получить другое. Скорее всего, оба ответа цитируют что-то реальное: опубликованные цифры для ровно этой модели на ровно этом железе тянутся примерно от конца пятидесятых до начала семидесятых токенов в секунду, и разброс — не шум: это четыре разных вопроса, на которые отвечают одной единицей. Эта страница сопоставляет каждую цифру с конфигурацией, которая её даёт. Все числа здесь цитируются из нашего же публичного репозитория прогонов и воспроизводятся по лежащему в нём рецепту; ничего на этой странице не приходит из реестра клеймов, потому что линия DGX стоит вне методологии v1 (см. ограничения в конце). ## Четыре вопроса, спрятанные за «токенами в секунду» **1. Какой MoE-бэкенд активен?** В образе runtime есть MoE-ядро, собранное под нативных MXFP4-экспертов DeepSeek-V4 на GB10, — и оно намеренно исключено из выбора `auto`. На карточкоподобном контрольном профиле `auto` даёт среднюю клиентскую скорость декода 59.7 tok/s , а `flashinfer_b12x` — 67.6 tok/s . Те же веса, те же узлы, те же промпты: флаг, который по умолчанию никто не ставит, стоит около 13% . Если опубликованная цифра лежит в конце пятидесятых, первое, что стоит проверить, — запускал ли автор вообще `docker logs … | grep "Mxfp4 MoE backend"`: с `auto` вы получаете `DEEPGEMM_MXFP4`, а не `B12X_MXFP4`. **2. Какой был промпт?** Разброс по ворклоаду больше, чем у большинства изменений конфигурации. В серии на 500 токенов профиль кода даёт 65.5 tok/s при конкурентности 1, а русский технический контекст на ~4K токенов («heavy») — 43.7 tok/s : та же машина, тот же бэкенд, тот же день. Цифра, процитированная без профиля промпта, нефальсифицируема. **3. Мерили на клиенте или в движке?** Наш собственный первый проход считал токены по моменту прихода SSE и отчитался о приросте частоты шагов от MoE-ядра в 16–18% . Более поздний перезамер, берущий цифры из собственных счётчиков движка, дал тот же прирост как 9–12% . Клиентский метод смещён вверх: задержка до прихода первого чанка вычитается из окна декода, а его токены при этом продолжают считаться. В репозитории мы пометили ранний раздел как перекрытый, а не удалили его: направление устояло, величина — нет. **4. Конкурентность 1 или агрегат?** На c=12 тот же профиль кода агрегирует 260.4 tok/s . Это верное число и бесполезный ответ на вопрос «насколько быстро это ощущается», который относится к c=1. Агрегатная пропускная способность и одиночный декод различаются здесь примерно в 4× . ## Так какую цифру цитировать? - **«Насколько быстро это ощущается одному человеку?»** — клиентская цифра декода на c=1 для профиля, похожего на вашу работу: 67.6 tok/s для карточкоподобного короткого вывода с включённым MoE-ядром, 43.7 tok/s для тяжёлого контекста на 4K токенов. - **«Важен ли флаг?»** — со стороны движка, 9–12% по частоте шагов верификации. Не клиентские 16–18%. - **«Сколько коробка обслужит суммарно?»** — агрегат на вашей целевой конкурентности, названный вместе с конкурентностью, никогда в одиночку. ## Честные погрешности На карточкоподобном контроле `auto` разошёлся между прогонами в 59.0–60.1 (около 2%), а плечо с MoE-ядром — в 62.6–71.0 (около 12%). Агрегаты на 500 токенов отличались между идентичными прогонами на 18–24% . Направление каждого сравнения здесь устойчиво; точная величина при таком числе повторов не разрешима. Кто цитирует с этого класса железа цифру с двумя знаками после запятой, цитирует точность, которой у измерения нет. ## Ограничения - **Это не результат методологии v1.** Линия DGX — это bring-up: прогоны за ней одиночные, с прогревами, а не трёхкратная дисциплина замороженного ворклоада, стоящая за нашим [реестром клеймов](https://agmind.ai/ru/claims/). Метка `lab_single_run` стоит ровно поэтому. - **Одна модель, один чекпойнт, один образ runtime.** Находка про MoE-ядро специфична для MXFP4-экспертов DeepSeek-V4 на GB10 — она ничего не говорит про другие MoE-модели или другое железо. - **В игре спекулятивный декодинг.** Учёт токенов идёт по `usage.completion_tokens` и никогда по числу SSE-событий: под спекулятивным декодингом одно событие может нести несколько принятых токенов, и подсчёт событий молча завышает пропускную способность. Нашли цифру, которая расходится с любой из этих? [Пришлите расходящееся число](https://github.com/botAGI/agmind-lab/issues/new?template=conflicting-number.md) — конфигурационная дельта за расхождением обычно информативнее любой из цифр по отдельности. ## Как воспроизвести Рецепт сервинга, скрипты запуска, run-манифест с digest образа и ревизией модели, сырые выводы — всё открыто: [botAGI/dspark-0731-gb10](https://github.com/botAGI/dspark-0731-gb10). Лонгрид, стоящий за этой страницей, — на [Хабре](https://habr.com/ru/articles/1066164/). Связанное: [кривая глубины до 1M контекста на том же кластере](https://agmind.ai/ru/reports/dspark-speculative-1m-dgx-spark/) и [отчёт про MoE-бэкенд](https://agmind.ai/ru/reports/dsv4-flash-moe-backend-dgx-spark/). --- Machine-readable claim registry: https://agmind.ai/claims.json · llms.txt: https://agmind.ai/llms.txt