Комментарии 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/
Еще рекомендую попробовать запуск gguf моделей на vllm - огромный прирост производительности на слабом железе https://docs.vllm.ai/en/stable/features/quantization/gguf/ .
Удивило, что всё не квантованное. Берите 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 на полной скорости?

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