Тест DeepSeek, Qwen, GLM и прочих LLM на продвинутом пользовательском железе

Еще чуть больше года назад ваш покорный слуга наконец решился обновить комп, приобретя ПК с RTX 5090 и 96Gb RAM, которые, как я тогда думал, окажутся ультимативным решением для запуска всего, что может когда‑либо хотеться запустить. Но с выходом DeepSeek V4 Flash в апреле понял, что оказался в своеобразном «лимбо» — суммарных 128Gb VRAM+RAM хватало либо на запуск модельки в кванте ^[1] Q2, либо на самом пределе возможного в Q3XSS. То есть был Qwen 3.6, а на всё, что больше — памяти ^[2] уже не хватало. А тут как раз вышла новая версия DSv4Flash 0731… Казалось бы, комп мощный, и для запуска продвинутой нейронки не хватает совсем чуть‑чуть, а в отличие от злосчастных обладателей DGX Spark, которым, наверно, брать разве что вторую такую же, я могу просто докупить еще один комплект 96Gb RAM, который мне тогда обошелся всего‑то в… 32000р?

…Я не хочу говорить, во сколько мне это обошлось сейчас. Тем не менее, 192Gb RAM на AM5 завелись в весьма достойных 6000Mhz в режиме 1:1 и после лишь небольшого шаманства с напряжениями успешно прошли все тесты на стабильность.

• DeepSeek V4 Flash (0731) — 31 июля 2026 года. (MoE‑модель на 284B параметров с 13B активных, ориентированная на ИИ‑агентов).

• Qwen 3.8 27B — 3 августа 2026 года. (Плотная (dense) локальная модель, умещающаяся на одной производительной видеокарте).

• GLM 5.3 Flash — 26 августа 2026 года. (Мультимодальная MoE‑модель на 320B параметров с 18B активных, ранее тестировавшаяся под стелс‑именем Ox Alpha).

• Qwen 3.8 Flash Next — 28 августа 2026 года. (Архитектурное превью линейки Qwen 4, MoE‑модель на ~125B обычных параметров с ~6B активных на токен, плюс около 51B параметров n‑gram‑эмбеддингов; суммарно — ~180B).

И еще несколько более мелких, но интересных релизов навроде Ornith 1.5 35B‑A3B и 397B. То есть за несколько недель у меня появился огромный набор моделей от «плотной» 27B до 300+B MoE, на котором можно было проверить, что сегодня вообще имеет смысл запускать дома — причем, в идеале, не просто запускать, а с приемлемой скоростью, большим контекстом и без убийственного квантования. Хочу попробовать все!

Формат тестов

Тесты проводились посредством создания cmd‑скрипта запуска модели, поднимавшего локальный LLM‑сервер по адресу http://127.0.0.1:5000/v1 ^[3], и обращения к нему через клиент Jan Desktop. Пример скрипта запуска (тут меня «вел за руку» ChatGPT):

@echo off
setlocal
chcp 65001 >nul

set "COMMON=%~dp0benchmark-common.ps1"

set "LLAMA_DIR=C:Users[User].unslothllama.cppbuildbinRelease"
set "SERVER=%LLAMA_DIR%llama-server.exe"
set "CUDA_LIBS=C:Users[User].unslothstudiounsloth_studioLibsite-packagestorchlib"
set "MODEL=D:LLMQwen3.8-Flash-NextQwen3.8-Flash-Next-UD-Q4_K_XLUD-Q4_K_XLQwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf"

set "CTX=262144"
set "THREADS=16"
set "FIT_TARGET=1024"

if not exist "%COMMON%" (
    echo ERROR: benchmark-common.ps1 not found:
    echo %COMMON%
    pause
    exit /b 1
)
if not exist "%SERVER%" (
    echo ERROR: llama-server.exe not found:
    echo %SERVER%
    pause
    exit /b 1
)
if not exist "%MODEL%" (
    echo ERROR: model not found:
    echo %MODEL%
    pause
    exit /b 1
)
if not exist "%CUDA_LIBS%" (
    echo ERROR: CUDA runtime directory not found:
    echo %CUDA_LIBS%
    pause
    exit /b 1
)

set "PATH=%CUDA_LIBS%;%PATH%"
set "NVIDIA_TF32_OVERRIDE=0"

rem ============================================================
rem BENCHMARK METADATA
rem ============================================================
set "BENCH_SERVER=%SERVER%"
set "BENCH_MODEL_FILE=%MODEL%"
set "BENCH_MODEL=Qwen3.8-Flash-Next"
set "BENCH_PARAMS=~180B / ~6B active per token"
set "BENCH_QUANT=Unsloth UD-Q4_K_XL GGUF"
set "BENCH_RUNTIME=llama.cpp (Unsloth build)"
set "BENCH_DRAFTER=none; baseline (MTP disabled)"
set "BENCH_CONTEXT_KV=256K (262144) / Q8_0, Q8_0"
set "BENCH_VISION=No; mmproj not loaded"
set "BENCH_LAYERS=48 trunk layers; hybrid recurrent/attention architecture"
set "BENCH_EXPERTS=512 routed experts; 10 selected per MoE layer"
set "BENCH_EXPERT_PLACEMENT=TRUE AUTO FIT; mixed VRAM/RAM"
set "BENCH_GPU_EXPERT_CACHE=n/a; auto-fit tensor placement"
set "BENCH_CPU_MOE=automatic placement; no --n-cpu-moe override"

set "BENCH_RUN_ARGS=-m "%MODEL%" --alias benchmark --host 127.0.0.1 --port 5000 -c %CTX% -np 1 --cache-type-k q8_0 --cache-type-v q8_0 -fa on --fit on --lazy-mode off --fit-target %FIT_TARGET% --load-mode none -b 2048 -ub 128 -t %THREADS% --threads-batch %THREADS% --cache-ram 0 --jinja --reasoning-preserve"

title Qwen3.8-Flash-Next UD-Q4_K_XL - 256K baseline benchmark - port 5000

powershell.exe -NoLogo -NoProfile -ExecutionPolicy Bypass -File "%COMMON%"
set "RC=%ERRORLEVEL%"

echo.
echo llama-server exited with code %RC%.
pause
endlocal
exit /b %RC%

Каждой модели для каждого способа запуска давалось три «one‑shot» задачи:

1. Напиши подробное техническое объяснение того, почему упреждающее декодирование (speculative decoding) может ускорять локальную языковую модель (LLM), но иногда вместо этого замедляет её. Разбери долю принятых предсказаний (acceptance rate), стоимость вспомогательной модели (draft model), проверку предсказаний основной моделью (verification), пропускную способность памяти (memory bandwidth), влияние длины блока предсказаний (speculative block) и влияние длинного контекста. Не используй таблицы. Продолжай подробное объяснение до достижения лимита в 4096 токенов. Не завершай ответ досрочно.

2. Сделай SVG‑изображение: осёл едет на велосипеде, на заднем плане в лесу стоит медведь. Выдай только один законченный SVG‑код, без пояснений, Markdown и внешних ресурсов. SVG должен открываться как самостоятельный файл в браузере.

3. Сделай одним ответом законченную браузерную игру, аналог Battle City. Выдай один самодостаточный HTML‑файл без внешних библиотек и ресурсов. Управление WASD/стрелки, Space — выстрел. Должны быть игрок, противники, разрушаемые кирпичные стены, неразрушаемые стены, столкновения, снаряды, очки, жизни, поражение и перезапуск. Не объясняй код — выдай только готовый HTML.

Тестировались модели: Ornith-1.5–35B‑A3B, Qwen3.6–35B‑A3B, Qwen3.8–27B, Qwen3.5–122B‑A10B, Laguna‑S-2.1, Qwen3.8-Flash‑Next, DeepSeek‑V4-Flash-0731, Ornith-1.5–397B, GLM-5.3-Flash, Hy3, MiniMax‑M3. Под конец было решено попробовать хайпануть и запустить огромную модель Hy4-preview в STQ1_0 — потому что могу! Все остальные модели я пытался запускать на максимальном разумном качестве.

Инференсы

Довольно быстро я понял, что наилучший набор параметров для запуска не всегда очевиден, а для достижения наилучшей скорости нужно тестировать вообще разные способы запуска, а не только универсальный llama.cpp. Первым «звоночком» в этом плане стал Ninfer — наткнулся на упоминание о нём на Reddit, когда искал информацию по скорости запуска моделей. И первый же тест на Qwen3.8–27B поднял скорость с ~100 токенов в секунду до ~170ток/с. Вау!

NInfer — специализированный движок инференса (запуска и вывода LLM), заточенный под небольшой набор конкретных моделей и современное NVIDIA‑железо; в отличие от универсального llama.cpp он сознательно жертвует широтой поддержки моделей и форматов ради скорости. На видеокартах архитектуры Blackwell NInfer использует преимущества 4-битного формата вычислений NVIDIA FP4 (NVFP4), имеющего аппаратную поддержку тензорными ядрами данной архитектуры. Это позволяет одновременно уменьшить объём читаемых из видеопамяти данных и ускорить сами матричные вычисления. Обратная сторона — необходимость заранее переквантовать веса модели из BF16 в NVFP4, а 4-битное представление уже может заметно влиять на качество, плюс используется собственный формат файлов *.ninfer. Раньше движок разрабатывался только под Linux и в Windows обычно запускался через WSL2, но сейчас появились и нативные реализации, например, natpate/ninfer‑windows ^[4].

Из альтернатив мне попались ещё ExLlamaV3, ориентированный на NVIDIA GPU и собственный формат EXL3, и FreeToken, рассчитанный на попытку оптимизации запуска MoE‑моделей с разгрузкой слоев в RAM.

Из более известных систем запуска стоит упомянуть vLLM и SGLang. В отличие от llama.cpp, который в первую очередь ценен широкой поддержкой моделей, форматов и самого разного железа, эти проекты сильнее ориентированы на серверное использование: одновременную обработку множества запросов, эффективную работу с уже посчитанным контекстом и распределение нагрузки между несколькими видеокартами. Поэтому они особенно популярны при развёртывании LLM как сервиса. В этом тесте я их пока не использовал: здесь основной сценарий — одна пользовательская машина и один активный запрос.

Из всего этого набора в дополнение к llama.cpp я тестировал NInfer, ExLlamaV3 и FreeToken там, где видел в этом возможность и смысл.

VRAM, RAM и MoE

Другим важным тестом стал тест Q6 vs Q8 на моделях Qwen3.8–27B и Ornith-1.5–35B‑A3B. Попытка перехода с Q6 на Q8 для первой из них потребовала всего лишь выгрузить пару слоев из VRAM в RAM… и скорость со 100ток/с улетела до 10. В 10 раз, Карл! Для Ornith-1.5–35B‑A3B выгрузка пары слоев в RAM прошла заметно менее болезненно — если Q6_K GGUF с контекстом 192K с квантованием kv‑кеша в Q8, полностью помещавшаяся в видеопамять, давала ~235ток/с, то увеличение контекста с частичной выгрузкой до 256K дало уже ~185ток/с, а переход вместе с тем на Q8 — ~95ток/с.

Очевидно, разница этих моделей — в архитектуре последней — Mixture of Experts (MoE, смесь экспертов). Если в классической LLM, так называемой «плотной» модели, для каждого следующего слоя активируются все параметры, то в MoE каждый слой разделен на набор «экспертов» (набор параметров), и присутствует роутер, который для каждого следующего слоя выбирает, какой набор параметров будет задействован (подробнее — https://newsletter.maartengrootendorst.com/p/a‑visual‑guide‑to‑mixture‑of‑experts ^[5]).

При этом, сама модель — это не только слои. И даже в MoE помимо экспертов (Routed Experts) в модели остаётся общая, постоянно вычисляемая часть — attention, нормализации и прочее, в зависимости от архитектуры, а также общие эксперты (Shared Experts), которые задействуются для каждого токена. Всё это лучше оставлять в VRAM. Но помимо слоев есть еще и кэш памяти (KV cache) модели, а также опционально драфтер (предиктор, ускоритель модели, о нём позже) и слои Vision — их, кстати, если не предполагается постоянная работа нейросети с картинками, как раз часто можно отправить в RAM.

KV cache — это рабочая память модели для уже обработанного текста: истории чата, загруженного документа, программного кода и вообще всего, что сейчас находится в её контекстном окне. Контекстное окно — это тот объём информации, который модель ещё «видит»; всё, что осталось за его пределами, она уже не учитывает. Для токенов внутри этого окна модель хранит в KV cache промежуточные результаты вычислений, чтобы не пересчитывать их заново при каждом следующем токене.

Чем больше контекстное окно, тем больше KV cache. На длинных контекстах он может занимать гигабайты и даже десятки гигабайт видеопамяти, а поскольку кэш постоянно используется при генерации, его крайне желательно держать в дорогой для нас VRAM. Но расход памяти, можно и уменьшить.

Технически, KV cache (Key‑Value Cache) — это буфер в памяти GPU/CPU, в котором хранятся промежуточные тензоры Key и Value, вычисленные механизмом самовнимания (self‑attention) для каждого обработанного токена. В трансформере на каждом слое внимания ^[6] каждый токен формирует три вектора: Query (Q), Key (K) и Value (V). При генерации нового токена его Query должен быть сопоставлен с Keys всех предыдущих токенов, чтобы определить, на какие части контекста обратить внимание, и затем агрегировать соответствующие Values. Без кэша эти K и V пришлось бы пересчитывать заново на каждом шаге генерации, что привело бы к квадратичной сложности по времени. KV‑кэш сохраняет их один раз, превращая каждый последующий шаг decode из O(N²) в O(N) по вычислениям (https://sponsr.ru/evil_about_tech/159835/IIshnica_Upravlenie_KVkeshem_v_vLLM_i_llamacpp_Arhitekturnye_razlichiya_i_ih_posledstviya/ ^[7]).

Важно то, что и K, и V мы также можем квантовать, разменивая память на точность ответа. То есть вместо 128K контекста с 16-битным KV cache можно получить 256K Q8, Q8 почти без потерь, или даже 512K Q4, Q4. Последнее я пока не пробовал, ибо чем больше контекст, тем сложнее модели не терять важные детали среди большого объёма контекста и так, а квантование не только позволяет вместить больший объем контекста, но и не добавляет вычислениям точности.

Как итог, крайне желательно, чтобы в VRAM видеокарты помещались все слои «плотной» LLM или вся общая часть и Shared Experts для MoE, драфтер (если есть), KV cache, и оставался хотя бы гигабайт видеопамяти под рабочие буферы и саму систему. Квантованием слоев модели (вернее, чаще выбором и скачиванием более подходящего кванта), квантованием K, V и управлением размером контекстного окна мы можем этого добиться. Конечно, чем большая часть экспертных слоев также окажется в видеопамяти, тем быстрее заработает MoE‑модель. Если видеокарт несколько, слои можно распределить между ними (но это разделение тоже не бесплатно). Нужно больше видеокарт!

Наибольшее разочарование — драфтеры

Наибольшее — после цен на видеокарты и оперативку, конечно. Но да, впервые узнав про MTP (Multi‑Token Prediction) и DFlashDSpark, я прямо был в предвкушении. MTP — встроенный в модель предиктор нескольких следующих токенов. DSpark у DeepSeek решает ту же задачу более хитрым способом, используя отдельный специально обученный модуль.

Идея на бумаге красивая. Вместо того чтобы основная модель по одному генерировала каждый следующий токен, ей в помощь дают небольшой предиктор, который пытается угадать сразу несколько следующих токенов. Основная модель затем проверяет этот кусок целиком: удачные предсказания принимаются, на первом ошибочном токене цепочка обрывается. Если предиктор достаточно дешёвый и угадывает достаточно хорошо, за один дорогой проход основной модели можно получить сразу несколько токенов.

И это работает! На той же Qwen3.8–27B в Q6 включение MTP подняло среднюю скорость генерации в моих трёх тестах примерно с 56 до 106 ток/с — почти в два раза! Но наилучшим образом драфтеры должны повести себя там, где они наиболее нужны — в ускорении больших и медленных MoE моделей! Верно?

Первой под раздачу попала Qwen3.8-Flash‑Next. Без MTP она у меня давала около 34,3 ток/с. Включаю штатный MTP — и получаю:

• n_max=1 — 20,5 ток/с;

• n_max=2 — 21,2 ток/с;

• n_max=3 — 20,3 ток/с;

• n_max=4 — 20,9 ток/с.

Где n_max — макс. количество предсказываемых драфтером токенов.

То есть вместо ускорения — стабильные минус 38–41%. Причём изменение длины speculative‑блока почти ни на что не влияет: сама по себе работа MTP уже стоит настолько дорого, что отбить её дополнительными принятыми токенами не получается. Попытка добавить сверху ещё ngram‑mod тоже ничего не спасла — 20,7 ток/с.

Неудачный конкретный режим? Казалось бы, да. Но дальше стало интереснее.

На GLM-5.3 Flash обычный decode дал 9,22 ток/с. MTP с n=2 поднял скорость до 9,49 ток/с, то есть аж на 2,9%. С n=3 скорость уже упала до 8,19 ток/с.

Иными словами, здесь драфтер примерно вышел в ноль. Второй предсказанный токен ещё кое‑как окупает затраты на предиктор и проверку, третий — уже нет.

А вот DeepSeek V4 Flash внезапно показал обратную картину: с его DSpark ускорение у меня оказалось с 13.5ток/с до 17ток/с — примерно на 25%!

То есть на одном и том же компьютере, среди трёх больших современных MoE я получил буквально все возможные варианты:

• Qwen Flash‑Next — драфтер сильно мешает.

• GLM-5.3 Flash — почти ничего не меняет.

• DeepSeek V4 Flash — заметно ускоряет.

После этого выражение «speculative decoding ускоряет генерацию» мне стало нравиться заметно меньше.

Причина, судя по всему, довольно приземлённая: драфтер тоже не бесплатен. Нужно вычислить его собственные предсказания, подготовить несколько кандидатов, проверить их основной моделью, отбросить неудачные. Всё это имеет смысл только в том случае, если стоимость этой дополнительной работы меньше, чем стоимость тех обычных последовательных проходов, которые удалось пропустить.

И здесь архитектура модели решает очень многое.

У Qwen3.8-Flash‑Next основная модель и без того чрезвычайно разреженная — около 6 млрд активных параметров на токен. Обычный проход получается относительно дешёвым, и мы пытаемся ускорить уже быстрый механизм, добавляя к нему вполне реальную дополнительную работу. Результат — минус 40%.

У GLM-5.3 Flash основная активная часть тяжелее, поэтому экономить уже есть что, но её обычный MTP, похоже, просто не угадывает достаточно длинные куски достаточно дёшево. Получается почти точка безубыточности.

А у DeepSeek V4 Flash используется уже более специализированный механизм DSpark, и он оказался достаточно эффективным, чтобы действительно окупать собственные расходы.

Есть ещё один неприятный момент именно для MoE с экспертами в RAM. Проверка сразу нескольких токенов не означает, что можно один раз загрузить экспертные веса и получить несколько токенов почти бесплатно. Разные позиции могут отправляться роутером к разным экспертам, и тогда при проверке блока приходится тащить из памяти гораздо больше разных весов. Если маршруты токенов хорошо пересекаются — отлично, если нет — преимущество совместной проверки быстро уменьшается.

На плотной Qwen3.8–27B, которая у меня помещается в VRAM целиком, ситуация заметно приятнее. Там для нескольких проверяемых токенов используются одни и те же матрицы весов, лежащие в быстрой GDDR7, и драфтер действительно может дать пользу. То есть проблема не в самой идее speculative decoding — просто для разных архитектур и способов размещения модели её экономика радикально различается.

Практический вывод у меня получился довольно грустный: драфтер нельзя просто включить и считать, что стало быстрее. Его нужно тестировать отдельно на каждой модели и на конкретном железе. Причём иногда оптимальной настройкой оказывается n=2, иногда n=3, а иногда — кнопка «выключить».

Результаты тестов

Но хватит уже душнить, пытаясь своими словами написать то, что большинству здесь наверняка очевидно. Вот результаты тестов:

В целом, глядя на получившиеся скорости и результаты тестов, я бы заключил, что:

• Первое — поколение модели сейчас может оказаться важнее её номинального размера. Qwen3.8–27B, Qwen3.8-Flash‑Next, DeepSeek V4 Flash и GLM-5.3 Flash в практических тестах выглядят заметно сильнее многих более крупных моделей предыдущего поколения. К ним же с некоторой оговоркой можно отнести Ornith-1.5–35B‑A3B как своеобразный «топ за свои деньги». Понадеемся, что Qwen3.8–35B‑A3B все‑таки тоже выйдет. При этом Ornith-397B, Hy3, MiniMax M3 и прочие справились хуже, несмотря на гораздо больший размер. Hy4, вероятно, проиграл из‑за абсурдно низкого кванта.

  Кстати, ещё один неожиданный результат — новые модели иногда пытаются вызывать инструменты, которых им никто не давал. В обычном чате это оказывается галлюцинацией, и, похоже, становится характерной ошибкой ^[8] современных агентно‑обученных моделей.

• Второе — размещение модели в памяти критично. Если у плотной Qwen3.8–27B часть постоянно используемых весов вылетает из VRAM в RAM, скорость может рухнуть почти на порядок. У MoE‑моделей выгрузка экспертных слоёв обычно переносится мягче, но тоже напрямую бьёт по скорости. Поэтому размер контекста, квант KV cache и выбор кванта весов оказываются не вспомогательными настройками, а частью настройки производительности.

• Третье — NInfer действительно выделяется среди альтернатив llama.cpp, показывая реальный значительный прирост скорости. FreeToken тоже вначале показался мне более быстрым по скорости, но после приведения настроек reasoning к сопоставимому виду оказался примерно на уровне llama.cpp. ExLlamaV3 чаще оказывался медленнее, но видимо, при определенных условиях и удачных квантах, как получилось с GLM-5.3-Flash EXL3 4.05 bpw, может внезапно оказаться оптимальным вариантом.

• Четвертое — драфтеры работают далеко не всегда. На Qwen3.8-Flash‑Next MTP дал почти минус 40%, на GLM-5.3 Flash — около нуля, а на DeepSeek V4 Flash специализированный dFlash/DSpark дал примерно плюс 25%. То есть включать speculative decoding “потому что он есть” точно не стоит, всегда требуются тесты.

• Пятое — скорость в токенах в секунду сама по себе недостаточно точно описывает удобство модели. Qwen3.8-Flash‑Next генерирует быстрее DeepSeek V4 Flash, но в тестовых задачах часто пишет существенно больше токенов. Поэтому по полному времени выполнения конкретной задачи преимущество может оказаться ниже ожидаемого или вообще исчезнуть. GLM-5.3 Flash в этом отношении показала себя ещё тяжелее: она не только примерно вдвое медленнее DeepSeek по скорости генерации, но в тестах ещё и тратила больше токенов, так что компенсировать низкую скорость краткостью ответа не получилось. Хотя, заметим, в качестве ответов ей не откажешь.

• Шестое — даже на Q4-Q6-Q8 видно, что квантование модели оказывается далеко не бесплатным по качеству. Ниже Q3 как правило уходить вообще бессмысленно, оставаться на Q3 можно только от безысходности, но даже Q4, особенно на малых моделях, оказывается не всегда приемлемым компромиссом.

  Кстати, для Qwen3.8-Flash‑Next возможно размещение n‑gram‑эмбеддингов на SSD без драматичного замедления работы модели, но конкретно для моей текущей конфигурации это неактуально.

Краткие выводы

1. Для локального запуска поколение модели сейчас может оказаться важнее её номинального размера.

2. Главное ограничение — не просто объём VRAM, а то, помещается ли в неё «hot working set». KV cache и постоянно активную часть модели — лучше не трогать, а вот Vision часто можно вынести в RAM.

3. Для MoE быстрая RAM действительно позволяет запускать огромные модели с приемлемой скоростью. Хотя 10–30ток/с на пользовательской двухканальной DDR5 — все‑таки маловато.

4. NInfer на поддерживаемых моделях — реальный способ получить новый класс производительности. FreeToken и ExLlamaV3 могут оказаться полезными ситуативно.

5. Драфтеры не всегда дают ускорение — нужно тестировать отдельно для каждой модели и конфигурации оборудования.

6. Скорость модели лучше оценивать с учетом затрат токенов на получение результата.

7. Q4 уже нельзя считать полностью бесплатным по качеству, особенно на небольших моделях.

Топ локальных моделей на текущий момент, полагаю, выглядит так:

P. S.: