Обновить

DGX Spark на 256K контексте: тестирую конфигурации vLLM, реальные замеры и почему NVFP4 в mainline сломан

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

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

Очень тяжело читается. Как обрывки мыслей.

пофиг как читается - чел запорочился - скормлю клоде - сделат удобоваримым. Ценность в экспериментах а не в гладкости текста

спасибо за проделанную гигантскую работу!
сам думаю что купить помощнее.
сейчас комп на ryzen ai 9 370, dd5-8ггц, 64гб. на Qwen3.6-35B-A3B-FP4 выдаёт порядка 20ток/cек. подсистема памяти вдвое медленнее, чем у спарка - вот и результат.

Имея живой опыт работы на GB10, я бы всё‑таки рекомендовал смотреть на решения на базе Strix Halo. По скорости в типичных LLM/ML‑нагрузках разница не драматическая, зато классический x86 даёт предсказуемое поведение, нормальную совместимость с экосистемой и сильно меньше возни с портированием

Хорошее решение для запуска БЯМ, но не для обучения, так как без куды.

RTX PRO 4000 Blackwell 24 GB VRAM, именно эта модель именно в этих квантах выдает 120 decode и prefill 4500 на пустом контексте, при 90k забитого контекста около 77 tps decode. Могу померять еще если надо. Backend llama.cpp

я на ddr4 + 3060 12gb на Qwen3.6-35B-A3B q4km, q16c, 32k контекста получал 30+ т/с, правда скорость декодирования медленная.
если вам домой - то полноценный ryzen 395 + 3090 внешняя в/к
а вообще какой-нибудь codex за ваши токены может вполне сам погонять тесты и подобрать разные настройки и сделать конфиги, оч удобно, и не очень дорого.

Почему только vllm? llama.cpp гораздо шустрее будет работать на таком железе.

llama.cpp хорош для одиночного инференса, а мне здесь нужен именно продакшн‑сервер под несколько клиентов. Для этого vLLM с его шедулером, KV‑кэшем и API даёт больше профита, чем голая скорость одного потока. Спасибо за идею с llama.cpp — в одной из следующих статей как раз попробую сравнить оба подхода на таком железе.

есть кстати форки llama.cpp с турбоквантом, на rtx 3090 24gb qwen 3.6 35b q4km при контексте 256к выдаёт в начале 90-95 ток/с но я кручу чаще qwen 3.6 27b q4km так же при контексте 256к выдаёт 30ток/с
лично я пользуюсь этим форком AmesianX/TurboQuant
а так же для себя собирал бинарник vllm.rs-windows.exe но мне не зашло ибо сжирает всю память быстрее даже на мелких моделях, была бы версия с турбоквантом, возможно было бы лучше,
а так же могу порекомендовать исправление чат темплейта, пока ещё не совсем распробовал но вроде как лучше hf Qwen-Fixed-Chat-Templates

А с Gemma 4 будет работать? А на TurboQuant-ах + вспомогательных моделях 4 версии? https://habr.com/ru/news/1031968/

будет, но gemma 4 отстаёт от qwen 3.6

Может не по адресу, но как обычно сравниваете (интересует image detection), какие бенчмарки смотрите. Или это на ваших задачах?

на моих задачах, но и бенчмарки +- то же и показывают, насчёт распознавания изображений не вкурсе

Удивило, что всё не квантованное. Берите gguf, квантуйте кеш, это хорошо

Так оно квантовано — пять из шести конфигов. Gemma BF16 одна осталась стоковой как baseline, и даже у неё KV cache в FP8 (без этого 252K не поднялся бы в 128 GB).

Остальные: Qwen3.6-FP8, NVFP4 на 4 битах, AEON-7 тоже NVFP4. KV cache везде FP8. Дальше квантовать в Q3 — уже бьёт по качеству, на 35B-MoE особенно.

Про GGUF — vLLM формат читает, но сами разработчики в доке пишут "highly experimental and under-optimized, may not be compatible with other features". Для одиночного юзера локально llama.cpp с GGUF — вполне рабочий путь (форумные замеры на Qwen3-30B-A3B Q4_K_M порядка 80-90 tok/s single-stream). У нас серверная нагрузка с Dify и concurrency, там vLLM с paged attention и continuous batching в разы выгоднее.

А чем можно заменить Spark для дома? Что бы тянул большие модели типа Gemma 4 на полной скорости?

я жду Beelink GTR9 Pro AI Max+ 395 , спарк отлично подходит под дообучение - под инференс это танцы с бубном)

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

Публикации