Обновить

DeepSeek 0731 на DGX Spark: разгоняю до 68 tok/s и разбираюсь, почему у автора карточки 57

Уровень сложностиСредний
Время на прочтение14 мин
Охват и читатели7.5K
Всего голосов 4: ↑4 и ↓0+6
Комментарии12

Комментарии 12

Не хабр а ранбук Клода: Протокол работы над проектом, выложенный в общий доступ.

Да ладно, будет хоть на чём обучать Opus-6 :)

А по теме: этот А.Петерсон какую-то неудачную лоботомию с Дипсиком провёл - качесто ответа сильно просело. Эта сборка лучше будет: drowzeys/keys-DeepSeekV4-Flash-GA-0731-Dspark-Abliterated-32-32

У меня оригинальная модель на этом образе: aidendle94/sparkrun-vllm-ds4-gb10:production-hybrid-1.4 - ну 40-50 токенов даёт.

Но я не очень понимаю, зачем автор за 20% перформанса гонится: для персонального пользования, ну, приятно конечно, но большой погоды не делает. А для небольшой команды, мне кажется, так себе удовольствие - даже если 120 т/с на несколько юзеров выдавать будет, то для каждого отдельного - это будет 10-20 т/с - не комфортно.

Число из “ранбука клода” выше: 260 tok/s - это может какой-то сферический промпт в вакууме, в реальной жизни - более-менее бесполезен.

П.С. А! Не настоящие юзеры, агенты же! Ну, ладно, если для толпы агентов, то за 20% можно и побороться )

П.П.С. влился в ряды борцов:

Thinking…

🎉 Его образ поднялся на нашей модели в TP2 (worker rank1 + head rank0 через self-ssh, готов за ~510с, отдаёт deepseek-v4-flash на :8070). Его rejection_sample_method:block + moe-backend flashinfer_b12x + spec=5 + gmu 0.86 + 1M контекст — всё как у него.

Бенчмаркаю тем же протоколом (greedy t=0, 2 прохода + его t=0.5), с acceptance …

П.П.П.С:

Клод быстро справился
 Результат — решающий. Его образ + наша модель, то же железо, тот же бенч:

 ┌─────────────────────────────────────┬───────────────────┬──────────┐
 │ образ / конфиг                          │ greedy tg t/s     │ acceptance │
 ├─────────────────────────────────────┼───────────────────┼──────────┤
 │ наш образ, spec=4 (дефолт)              │ ~50.8 (50.3/51.4) │ 48%        │
 ├─────────────────────────────────────┼───────────────────┼──────────┤
 │ наш образ, spec=5                       │ ~40.3 (41.6/39.1) │ 36%        │
 ├─────────────────────────────────────┼───────────────────┼──────────┤
 │ его образ (spec=5+block, все его флаги) │ ~38.6 (35.9/41.3) │ 28.5%      │
 ├─────────────────────────────────────┼───────────────────┼──────────┤
 │ его образ, t=0.5                        │ 30.7              │ —          │
 └─────────────────────────────────────┴───────────────────┴──────────┘

Его образ на нашей модели МЕДЛЕННЕЕ нашего (~39 vs ~51), на идентичном железе.
Никакой магии в его образе нет.
Его 68 — это его модель (apetersson abliterated) + его контент, а не образ.

 Восстанавливаю прод (гашу его контейнеры, поднимаю наш spec=4):

И еще один важный момент: у меня частота ГПУ ограничена 2100 Мгц, потому как если без, то Спарк с большой вероятностью догревается до 90 градусов и отрубается. На этой максимальной частоте просадка по производительности всего несколько процентов, но зато температура больше 75 не поднимается, и потребление не превышает 35 ватт.

О, вы реально прогнали, респект. Но там засада: aidendle94 включает B12X сам, у него VLLM_USE_B12X_MOE=1 прямо в образе. Я на нём раньше сидел, переменная до сих пор в моём старом лаунчере валяется. То есть вы сравнили B12X с B12X, понятно, что разницы нет. Моё утверждение вообще про anemll, где auto его молча не берёт.

А вот что у вас реально любопытно, это acceptance 28.5%. У меня на коде 71-73, на русской прозе 36-38. Ваши 28.5 явно ближе к прозе. Мои 67.6 это код, на прозе у меня 43.7.

Про «зачем 20%». У меня не синтетика ради синтетики. Я гоняю агентные сценарии через OpenClaw, по Grafana там 40-45 tok/s. Где-то посередине между моими 67 на коротком коде и 43 на длинной прозе. Когда агент долбит пачками, эти проценты вполне заметны по времени ответа.

Про 2100 МГц, вот это ценно, спасибо. У меня клок не зажат, 3003 максималка.

spec=4 у вас работает, у меня 3 и 7 валидатор отбивал, а в карточке 0731 вообще 7 стоит. Три образа, три разных набора. Про качество apetersson не спорю, я мерил только скорость. 260 это 12 параллельных суммарно, для одного юзера бессмысленно, для агентов норм.

Если захотите ткнуть именно в моё утверждение, это один рестарт: ваш же образ, =0 против =1.

ПС: частоты не лочил, потому что у меня на кластере кастомное охлаждение.

Ваши 28.5 явно ближе к прозе.

Эта проза называется: tool-eval-bench :)

А на счёт образов - озадачил агента посмотреть, можно ли уже поднакопившийся зоопарк перевести на eugr/spark-vllm-docker. Посмотрим завтра.

Расскажете, что вышло? Интересно, что там с acceptance на вашем tool-бенче))

Стоковый eugr vllm-node (main) НЕ тянет DeepSeek+DSpark — краш num_tokens=5 в ядре flashinfer sparse-MLA SM120. Нужен именно b12x. На b12x всё поднялось.

Перф (temp = 0, single-stream, thinking off)

 ┌───────────────┬───────┬───────────┐
 │ конфиг          │ tok/s │ acceptance │
 ├───────────────┼───────┼───────────┤
 │ aidendle spec=4 │ ~50.8 │ 48%        │
 ├───────────────┼───────┼───────────┤
 │ aidendle spec=5 │ ~40.3 │ 36%        │
 ├───────────────┼───────┼───────────┤
 │ eugr b12x spec=5│ ~41.3 │ 38.7%      │
 └───────────────┴───────┴───────────┘

b12x надо spec≥5 (block=5; spec=4 у него «некорректен»). Поэтому лучший b12x (~41) ниже aidendle spec=4 (~51).

tool-eval-bench Hardmode + thinking

  • b12x: 77 / 77 (2 прогона, воспроизводимо) против ~89 (aidendle). Заметно ниже.

Вердикт:

  • Скорость + hardmode сегодня → остаёмся на aidendle spec=4.

  • Корректность + поддержка NVIDIA + свежие ядра + TP=3 (3 Spark’а) → переходим на b12x, но сперва добить 4 оговорки: проверить, что reasoning_effort=max реально применяется (77 мог быть на «high»). Reasoning efforts режимы у Дипсипа - детский сад: в темплейте зашито: high - “думай хорошо”, max - “думай так хорошо, как можешь, и ещё лучше”.

  • Консолидация оркестрации (DeepSeek → eugr run-recipe.sh --no-ray) безопасна независимо от выбора образа — рецепт написан.

«Ранбук» - это комплимент, спасибо. Именно так и должен выглядеть бенчмарк: протокол, который можно повторить, сырые логи и репозиторий, где меня можно поймать на ошибке. Альтернатива - «я померил, у меня 68», и проверить это никак.

Кстати, в статье я исправляю три собственные ошибки, найденные при перепроверке. Для этого пришлось перемерять. Одну строку в комментариях перемерять не нужно.

А что плохого-то? Обычно как раз наоборот: человек кидает «у меня 68 tok/s» и всё, ни профиля, ни версии образа, ни как считал. Проверить невозможно. Тут хотя бы видно, что и почему померено, и репо есть с логами. Мне такое полезнее очередного «поставил и работает».

DeepSeek-v4-flash конечно быстро работает, но говорят что у него высокий уровень галлюцинаций, что делает практически непригодным для агентского использования. А самый низкий уровень галлюцинаций у MiniMax-M3

Тут важный нюанс: 0731 это не просто «дипсик», её как раз переучили под агентов и работу с инструментами. По официальным бенчам DeepSWE прыгнул с 7.3 до 54.4, Terminal Bench с 61.8 до 82.7. То есть ровно то, за что V4-flash ругали, в этом релизе и чинили.

Другое дело, что сам я качество не мерил, у меня в статье только скорость и я это специально оговариваю. Так что если у вас есть замеры по галлюцинациям на MiniMax-M3 против 0731 именно, а не против дефолтной, было бы интересно посмотреть.

результаты могут быть бесполезны, ведь 4К контекст из 1М. покажите скорость при полном контексте плиз с чудо-находкой-ключом и без него

Померил.

Гонял один и тот же промпт на четырёх глубинах, до настоящего миллиона токенов (1 042 600, это уже под потолок max-model-len). Один поток, ответ 128 токенов, температура 0, пять прогонов на точку. Все цифры сняты со счётчиков движка, а не с клиента, про это ниже отдельно.

Медианы, tok/s:

глубина    с ключом    без ключа
4K           45.9        41.2
64K          45.4        39.0
256K         40.1        32.9
1M           28.0        28.0

Прямой ответ на ваш вопрос: на полном контексте ключ не даёт ничего. По частоте шагов верификации разрыв +9.3% на 4K, +9.8% на 64K, +11.7% на 256K и 0.8% на миллионе. Перепроверил на двух разных типах текста, чтобы не показалось: везде в пределах пары процентов, то есть разницы нет.

Механизм понятный. B12X ускоряет счёт MoE-экспертов, а это фиксированная цена на токен, от длины контекста не зависящая. На коротком контексте она занимает заметную долю шага верификации, отсюда и десять процентов. На миллионе шаг почти целиком уходит во внимание над гигантским KV, доля MoE схлопывается, ускорять становится нечего. Так что флаг имеет смысл для обычной работы и не имеет, если у вас только сверхдлинные контексты.

Заодно ваш вопрос вскрыл в моей методике четыре бага, и все четыре завышали результат.

Самый обидный: клиентские тайминги. Я считал скорость по времени прихода SSE-чанков. На коротком контексте это врёт на процент, а на миллионе сервер начинает паковать несколько шагов верификации в один чанк, и врёт уже на 78%. Один прогон отрапортовал 84 tok/s, то есть быстрее, чем та же машина на 4K. Поймал по физике: 7.94 токена на шаг при потолке 6 (пять черновых плюс свой). Переделал всё на движковые счётчики.

Самый поучительный: филлер. Длинный контекст я строил из одного абзаца, повторённого двести тысяч раз. На такой длине драфтер начинает его щёлкать: приёмка на миллионе подскочила до 56% против ровных 45% на всех остальных глубинах, и миллион показывал 35 tok/s. Сделал несжимаемый текст, приёмка встала на 39%, скорость упала до 28.

И самое интересное, что из этого вышло. Частота шагов на миллионе: 8.54 на повторяющемся тексте и 8.58 на случайном. Одно и то же число. Скорость шага верификации от содержимого не зависит вообще, это чистая цена глубины. А расходятся результаты целиком по приёмке драфтера. То есть с длиной контекста дорожает шаг, а драфтер деградирует не от длины, а от непредсказуемости текста. Два разных механизма, которые обычно меряют одной цифрой.

Про prefill, раз уж речь о полном контексте. Холодный миллион это 1894 секунды, тридцать две минуты до первого токена, 550 tok/s против 1400 на мелкой глубине. Но дописать тысячу токенов в конец уже набранного миллионного диалога стоит около двух секунд, префикс-кэш держит. То есть агент, наращивающий контекст постепенно, не блокируется никогда, а вот «свалить миллион разом и ждать» действительно стоит получаса.

Сырые логи, включая забракованные прогоны и разбор всех четырёх багов, плюс сам гарнесс: github.com/botAGI/dspark-0731-gb10

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации