В llama.cpp добавили поддержку MTP Qwen3.6. Дополнительные слои Multi-Token Prediction позволяют сгенерировать сразу несколько токенов за 1 проход, что ускоряет генерацию в 1.5-2 раза. Качество при этом остается lossless. Для моделей, которые не имеют встроенного MTP, есть альтернативы в лице EAGLE-3 и DFlash.
TL;DR: Скачать кванты с именем MTP:
И запускать:.\llama-server -m "Qwen3.6-27B-UD-Q4_K_XL.gguf" --spec-type draft-mtp --spec-draft-n-max 4
Что такое MTP
Multi-Token Prediction (MTP) представляют собой дополнительные слои на выходе модели которые работают со скрытым состоянием этой же модели, эти слои обучаются вместе с моделью и они обучаются предсказывать несколько следующих токенов.
Стандартный авторегрессионный трансформер, он же LLM, после прямого прохода имеет выходной слой со скрытым состоянием, которое преобразуют в логиты вероятностей следующего токена. Это только 1 следующий токен, но скрытое состояние может нести информацию о нескольких следующих шагах.
Слои MTP представляют собой несколько голов MTP, которые учатся независимо предсказывать t+1, t+2, t+k следующие токены из одного скрытого состояния. Количество голов определяет сколько можно предсказать следующих токенов.
В llama.cpp поддержку MTP добавили для Qwen3.6: https://github.com/ggml-org/llama.cpp/pull/22673
Для Gemma4 и других моделей поддержка в разработке.
EAGLE-3
Если у модели нет MTP голов, можно применить другой схожий принцип. Скрытое состояние уже содержит информацию о следующих токенах, и можно обучить внешний блок, который научится извлекать из этого состояния информацию. Таким образом можно для любой модели предсказывать k следующих токенов аналогично MTP.
В методе EAGLE-3 создается и обучается 1 легковесная голова, которая добавляет вконце модели, и, в отличии от MTP, это всего 1 голова, которая используется рекурсивно для предсказания k токенов.
Для популярных моделей уже созданы eagle3 модули, которые нужно скачивать отдельно. Также для этого метода важно качество датасета для обучения eagle3.
Поддержка в llama.cpp в статусе черновика: https://github.com/ggml-org/llama.cpp/pull/18039
DFlash
Развивая идеи извлечения токенов из скрытого состояния и пытаясь обойти медленную скорость авторегрессивного трансформера, в котором каждый новый токен зависит от предыдущего и генерация идёт один за другим, был представлен способ блочной диффузии.
В DFlash параллельно за один раз предсказывается сразу блок токенов размером от 8 до 16 за раз. Как и в случае EAGLE-3, DFlash создает и обучает отдельный драфтер, блок диффузий. Метод похож на способ генерации изображений в Stable Diffusion или на LLM Gemini Diffusion.
Этот способ дает наибольшее ускорение среди всех вариантов, до 8 раз.
Поддержка в llama.cpp в статусе черновика: https://github.com/ggml-org/llama.cpp/pull/22105
Теоретический максимум tg t/s
Генерация LLM зависит линейно от скорости памяти, и теоретический максимум генерации можно рассчитать по формуле:
Скорость памяти делить на количество активных параметров. Активные параметры зависят от архитектуры модели, в Dense размер активных будет равен размеру модели. а в MoE или Gemma4 E4B, количество активных параметров будет значительно меньше размера модели. На скорость t/s влияют именно задействованные активные параметры каждого шага.
На примере 4060 ti 16 Гб, у которой скорость VRAM 288 Гб/c (268 GiB/s) можно сравнить теоретические расчёты и практические. Возьмём модель Qwen3.6-27B, она весит 54 GiB, в кванте UD-Q3 13.5 GiB и влезает в GPU целиком. В таком случае максимально возможная скорость не будет превышать 19.8 t/s. Реальная скорость ниже, так как происходит деквантование весов и прочие вычисления. Реальная скорость составила 17.11 t/s.
На GPU вы ограничены скоростью памяти, а не количеством вычислительных ресурсов, и у вас остаются ресурсы, чтобы за 1 проход перемножать матрицы прямого прохода LLM для параллельных запросов.
Как работает спекулятивное декодирование
Все 3 метода извлекают следующие токены из скрытого состояния основной модели, но нужно узнать, что эти токены предсказаны правильно, ведь если принимать их как есть, то очень быстро выдача будет состоять из некачественных токенов.
Основная идея спекулятивного декодирования заключается в том, что вы можете сгенерировать k следующих токенов и основная модель, используя общий KV-кэш, запустит k параллельных вычислений, проверяя все предложенные токены на совпадение их тому, что предложила бы основная модель.
В этом примере суммарная скорость 8 запросов превосходит одиночный запрос в 7 раз, 20 t/s против 144 t/s, в llama.cpp количество параллельных запросов указывается через параметр --parallel N. В зависимости от архитектуры модели и запаса мощности GPU, одна GPU позволяет параллельно производить вычисления примерно со скоростью одиночного запроса.
Тут важно отметить, что основная модель не смотрит на токены черновика последовательно и каким-то образом решает принять их или нет. Как в примере выше, основная модель запускает параллельные генерации, и последовательности для генерации создаются из предложенных токенов черновика.
Допустим, черновик предложил A, B, C, D, E. Основная модель создает и генерирует:
base + A + ?
base + A + B + ?
base + A + B + ... + E + ?
Основная модель запускает генерацию для всех последовательностей и для каждой из них добавляет 1 новый токен. Если этот новый токен совпадает, то текущая цепочка принимается, если и следующий токен совпадает, то следующая более длинная цепочка тоже принимается. И так далее пока не появится несовпадающий токен.
Если черновик предложил цепочку из 4 токенов и вся она была принята, то за 1 проверку мы принимает эти 4 токена + 1 новый, так как и для полной цепочки тоже был запущено параллельное выполнение и сгенерировался 1 новый настоящий токен. И поэтому, даже если будут отвергнуты все токены черновика, то это настоящий +1 токен будет добавлен в результат и такой вариант не должен давать просадку скорости даже если отвергнуты все токены черновика. Но при условии, что запаса вычислительных ресурсов хватает.
lossless или токены без потери качества
MTP, EAGLE-3, DFlash должны выдавать качество идентичное оригиналу. Но как проверить, так ли это? В интернете бытуют разные мнения на этот счет, и я сам не был уверен до конца в этом вопросе. Можно прогонять тесты и сравнивать результаты, или можно заглянуть в исходники llama.cpp и посмотреть как реализован механизм принятия токенов.
Нас интересует файл sampling.cpp, где происходит фаза верификации:
std::vector<llama_token> common_sampler_sample_and_accept_n(struct common_sampler * gsmpl, struct llama_context * ctx, const std::vector<int> & idxs, const llama_tokens & draft, bool grammar_first) { GGML_ASSERT(idxs.size() == draft.size() + 1 && "idxs.size() must be draft.size() + 1"); std::vector<llama_token> result; result.reserve(idxs.size()); size_t i = 0; for (; i < draft.size(); i++) { const llama_token id = common_sampler_sample(gsmpl, ctx, idxs[i], grammar_first); common_sampler_accept(gsmpl, id, true); result.push_back(id); if (draft[i] != id) { break; } } if (i == draft.size()) { const llama_token id = common_sampler_sample(gsmpl, ctx, idxs[i], grammar_first); common_sampler_accept(gsmpl, id, true); result.push_back(id); } return result; }
Для каждого токена draft[i] основная модель вычисляет параллельные вероятности.
Сэмплер выбирает новый токен каждого параллельного потока.
Если новый токен не совпадает с draft[i], то цикл сразу же прерывается.
Если совпадает, то токен добавляется в финальную последовательность.
if (draft[i] != id) { break; }
Прерывание цикла при расхождении токенов явное, никак исключений или вероятностей тут не предусмотрено. Это гарантирует идентичность результата, значит спекулятивное декодирование сохраняет lossless качество при использовании черновика.
Как установить llama.cpp и выжать из неё больше
В предыдущей статье я уже писал о том, как установить свежую llama.cpp и как добиться лучших показателей скорости, в целом это простая процедура, но чтобы не повторяться:
Добавлю только, что вам стоит попробовать не только кванты UD, но и кванты от Bartowski, которые могут показать себя лучше: https://huggingface.co/bartowski
И также ollama на днях отказалась от изолированной библиотеки GGLM от разработчиков llama.cpp, и перешла на llama.cpp напрямую.
Где взять кванты для MTP, Eagle3, DFlash
Обычно из GGUF вырезались слои MTP, если у модели они были, чтобы не занимали лишнее место. Qwen3.6 является такой моделью, старые кванты не имеют слоев MTP, хотя оригинальная модель их имела.
С появлением поддержки в llama.cpp эти слои начали возвращать, но в виде отдельных квантов. Все кванты находятся на https://huggingface.co/
Нужно ввести в поиск имя модели и добавить к нему MTP:
Тоже самое для Eagle3 и DFlash:
Для Qwen3.6 MTP можно взять, например, кванты от Unsloth:
Как запустить MTP
На данный момент в llama.cpp по умолчанию включен режим fit, который автоматически всё настроит так, чтобы максимально эффективно нагрузить GPU используя ncmoe. Поэтому активировать fa, настраивать ncmoe или включать cmoe, указывать максимум для ngl и t вручную не требуется.
Это имеет смысл, если вам нужна VRAM для других задач, тогда переключившись на cmoe, можно высвободить много VRAM не особо потеряв в скорости. Или можно указать -fitt N - указать сколько свободной VRAM оставлять в МБ при автонастройке.
Подробнее про разницу между cmoe и ncmoe я рассказывал в статье: Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения
Если вы скачаете модель со слоями MTP, то, по умолчанию, она запустится как обычная модель, чтобы активировать MTP нужно явно указать --spec-type draft-mtp и через --spec-draft-n-max 4 указать сколько следующих токенов предсказывать. Размер draft-n-max стоит подбирать в диапазоне количества голов MTP у модели.
Пример запуска, где будет предсказываться 4 дополнительных токена и автонастройка будет оставлять свободными 4 Гб VRAM:
.\llama-server -m "Qwen3.6-27B-MTP-UD-Q4_K_XL.gguf" --spec-type draft-mtp --spec-draft-n-max 4 -fitt 4096
Сравнение скорости
У Qwen3.6 есть 4 головы MTP, вроде как по оригинальной задумке они должны динамически подстраиваться от 2 до 4. В llama.cpp нет такой опции, поэтому нужно будет явно указать какое-то значение.
Тестировать будем Qwen3.6 27B UD-Q4_K_XL и Qwen3.6-35B-A3B-UD-Q4_K_XL. Замеры произведены на 5090, цифры и проценты ускорения на другом оборудование могут отличаться.
Во всех случаях промпт с реддита:
Write a single HTML file with a full-page canvas and no libraries. Simulate a realistic side-view of a moving car as the main subject. Keep the car visible in the foreground while the background landscape scrolls continuously to create the feeling that the car is driving forward. Use layered scenery for depth: nearby ground, roadside elements, trees, poles, and distant hills or mountains should move at different speeds for a natural parallax effect. Animate the wheels spinning realistically and add subtle body motion so the car feels connected to the road. Let the environment pass smoothly behind it, with repeating but varied scenery that makes the movement feel believable. Use cinematic lighting and a cohesive sky, such as sunset, dusk, or daylight, to enhance atmosphere. The overall motion should feel calm, immersive, and realistic, with a seamless looping animation.
Результат для кода в диапазоне draft-n-max от 1 до 7:
Спекулятивное декодирование работает для разных задач по разному и нет универсального значения для MTP. Проверим перевод, сочинение истории на русском и работу в агенте, где заданием будет перегнать старый c++ opengl проект в html.
Для MoE, где активных параметров мало, эффективность будет ниже, так как вычисление 3B в целом имеет высокую скорость и без черновиков. Для Qwen3.6-35B-A3B-UD-Q4_K_XL на задаче кода ускорение всего 33%:
Для перевода ускорение не особо существенно и составляет 7-12%. А вот для сочинения истории произошла деградация на 10-17%. Это может быть связано с тем, что для вычисления MoE GPU не может переиспользовать уже выбранные активные веса, так как для каждого токена задействуются разные эксперты.
Выводы
MTP работает лучше чем черновая маленькая модель, так как обучалось вместе с моделью и новые токены извлекаются из скрытого состояния оригинальной модели, и само MTP весит меньше черновых моделей.
Ускорение зависит от архитектуры модели, от количества активных параметров:
Для Dense, где все параметры активные, дает более стабильное ускорение, даже на задачах творчества, для программирования ускорение достигает 2х раз, для творческих задач 33%, для перевода 83%.
Для MoE моделей с малым числом активных параметров MTP работает не столь эффективно, 33% для кода, для перевода 12% и неожиданное - деградация на творческий задачах на 10%.
Для моделей которые не имеют MTP есть альтернативные варианты: EAGLE-3 и DFlash.
Изучение исходного кода llama.cpp подтвердило, что качество генерации не страдает и остается lossless при включении MTP.
Комментарии (102)
Fardeadok
18.05.2026 04:10Те кто прочитал эту помойку текста: напишите плиз просто команду запуска тк не у всех есть время жевать ненужную информацию
APKAH9
18.05.2026 04:10https://huggingface.co/unsloth/Qwen3.6-27B-MTP-GGUF https://huggingface.co/unsloth/Qwen3.6-35B-A3B-MTP-GGUF
MPT версии qwen - генерит в 2 раза быстрее оригинальной
Shannon Автор
18.05.2026 04:10Скачать кванты с именем MTP:
И запускать:
.\llama-server -m "Qwen3.6-27B-UD-Q4_K_XL.gguf" --spec-type draft-mtp --spec-draft-n-max 4Указать
--spec-draft-n-maxобязательно, по умолчанию будет сильная просадка скорости.
trueKapitoshk
18.05.2026 04:10Боюсь, хабр всё же, пока ещё, технический ресурс, и тут технологии описываются для технарей. Если Вы хотите тупые команды вбивать в консоль не понимая что они делают, то тогда вы не на том ресурсе информацию ищите.
java73
18.05.2026 04:10На 4070 без ti гонял и так и эдак. На moe модели увеличения скорости больше, чем на 10-15 процентов не получил. Задачи агентные в основном, на чистой генерации простыни текста, разумеется, быстрее, чем при частых префиллах контекста.
А вот dense модели буквально ускоряются почти в два раза, но у меня это понеслось не с параметром 4, а с параметром 2 токена. Но речь о том, что трудно в целом использовать в работе, например, модель 27b, которая не влезает полностью в видео, и скорость работы 3.5 или 7 токенов в секунду не сильно принципиальна. Чрезмерно ужатые кванты на порядок тупее хорошей и быстрой moe модели на 35b, которая и так пахала где-то на 40-50 т/с, и mtp даёт минимальный прирост, но не забываем, что на сейчас главный минус - mtp нельзя запустить вместе с vision мультимодальностью у qwen.
SlavikF
18.05.2026 04:10В последних версиях мульт модальность работает нормально вместе с MTP
java73
18.05.2026 04:10Это еще тогда +1 Гб на mmproj в память и -1 Гб для базы, не сильно нужно в целом мне)
nikulin_krd
18.05.2026 04:10Мультимодальный прожектор можно(и нужно) грузить на CPU, чтобы он не занимал VRAM
AcckiyGerman
18.05.2026 04:10Через VLLM можно. И очень быстро.
Вот например 4bit квант Qwen3.6 27B на RTX 5090 за сотню токенов в секунду выдаёт.
За основу был взят вот этот пример: https://www.reddit.com/r/LocalLLaMA/comments/1sw21op?qwen3627bint4_clocking_100_tps_with_256k_context/
vllm serve Lorbus/Qwen3.6-27B-int4-AutoRound \ --speculative-config '{"method":"mtp","num_speculative_tokens":3}' \ --dtype half \ --max-model-len 128000 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 3 \ --quantization auto_round \ --kv-cache-dtype fp8_e4m3 \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder \ --enable-auto-tool-choice \ --host 0.0.0.0 \ --port 8000 \ --compilation-config.cudagraph_mode none \ --trust-remote-code \ --enable-prefix-caching \ --enable-chunked-prefilljava73
18.05.2026 04:10с 5090 я и без курения это сделаю) у меня 4070.
AcckiyGerman
18.05.2026 04:10Да не важно какая карта, я про
главный минус - mtp нельзя запустить вместе с vision мультимодальностью у qwen
Можно
Inflame
18.05.2026 04:10Попробовал unsloth/Qwen3.6-27B-MTP-UD-Q3_K_XL — практически никакого прироста не заметил.
Промпт: Напиши простую игру "Угадай число" на языке C. Сделай так, чтобы компьютер загадывал число от 1 до 100, а пользователь пытался его угадать.
❯ llama-cli -mQwen3.6-27B-MTP-UD-Q3_K_XL.gguf--spec-type draft-mtp --spec-draft-n-max 4[ Prompt: 83.3 t/s | Generation: 19.0 t/s ]Без MTP:
❯ llama-cli -mQwen3.6-27B-MTP-UD-Q3_K_XL.gguf
[ Prompt: 150.0 t/s | Generation: 18.5 t/s ]А на unsloth/Qwen3.6-35B-A3B-MTP-UD-Q4_K_XL прирост с 40 до 47 т/с.
Конфигурация: Linux, llama.cpp-vulkan b9190, AMD Radeon RX 9600 XT 16GB, 32 GB RAM.
Inflame
18.05.2026 04:10Всё-таки удалось добиться увеличения скорости с 18 до 31 т/с со следующими параметрами (взял со страницы модели на HuggingFace):
llama-cli -m Qwen3.6-27B-MTP-UD-Q3_K_XL.gguf --spec-type draft-mtp --spec-draft-n-max 4 -ngl 99 -fa on -np 1. Видимо, помог перенос всех слоёв модели на GPU (-ngl 99), чего по умолчанию не делалось. Но для этого модель должна полностью вмещаться в VRAM.
fermentum
18.05.2026 04:10Так-то результат поразительный и это при том, что архитектура Квен и так была заточена на скорость генерации. Жалко, что не сделали версию 3.6 меньшего размера, который поместился бы в 16gb без жесткого квантования.
Antra
18.05.2026 04:10Поправьте, пожалуйста, где я неправильно думаю:
Qwen3.6-27B - дофига параметров, но медленная
Qwen3.6-35B-A3B - только 3B активных, поэтому потупее. Зато быстрая
MTP дает ощутимый выигрыш на 27B и существенно меньший на MoE. Т.е. разница в скорости нивелируется, а преимущество в качестве за счет реально используемых 27B параметров остается. В каких случаях тогда стоит 35B-A3B все-таки использовать?
Ну и вопрос про Nemotron-Cascade-2, если можно. Он, насколько я понял, исключительно эффективно работает с контекстом. Увеличение хоть до 100К VRAM отжирает буквально несколько сот мегабайт, а не гигабайты. Разумеется, начальный промпт от какого-нибудь Claude Code несколько минут обрабатывает, но потом на обычные запросы отвечает вполне прилично. Подвохи обнаруживает и т.п. В Qwen тоже можно большой контекст иметь?
Mintavrus
18.05.2026 04:10MoE имеет смысл использовать когда модель не влезает полностью в видеопамять, тогда часть активных слоев можно переложить на GPU и падение производительности будет не такое большое как в случае dense модели
Antra
18.05.2026 04:10Да, я так и гонял.
start_time,end_time,duration,gpu,author,model,size_gb,ctx,pp_ts,tg_ts,vram_peak,vram_pct,sys_ram_peak,flags
20:38:47,21:06:29,1661.9,3090,nvidia_Nemotron-Cascade-2-30B-A3B-GGUF,nvidia_Nemotron-Cascade-2-30B-A3B-Q5_K_L.gguf,24.51,32768,20.09,11.46,24202,98.5,40874,Full_GPU_Normal: -ctk q8_0 -ctv q8_021:06:29,21:33:31,1622.2,3090,nvidia_Nemotron-Cascade-2-30B-A3B-GGUF,nvidia_Nemotron-Cascade-2-30B-A3B-Q5_K_L.gguf,24.51,32768,20.59,11.02,24208,98.5,40264,MoE_1_Expert_CPU: -ctk q8_0 -ctv q8_0 -ncmoe 121:33:31,21:37:55,264.3,3090,nvidia_Nemotron-Cascade-2-30B-A3B-GGUF,nvidia_Nemotron-Cascade-2-30B-A3B-Q5_K_L.gguf,24.51,32768,133.4,113.23,24220,98.6,39667,MoE_2_Experts_CPU: -ctk q8_0 -ctv q8_0 -ncmoe 221:37:55,21:42:20,265.0,3090,nvidia_Nemotron-Cascade-2-30B-A3B-GGUF,nvidia_Nemotron-Cascade-2-30B-A3B-Q5_K_L.gguf,24.51,32768,133.06,113.45,24220,98.6,39683,MoE_3_Experts_CPU: -ctk q8_0 -ctv q8_0 -ncmoe 3Разница - небо и земля. При Q5_K_XL, в 24GB не влезает, с 11 до 113 tps выросло при ncmoe 2. Но активных экспертов осталось мало, т.е. по моему пониманию это "скорость вместо качества". Глубокие размышления это исправляют, но тогда и реальная скорость падает (ибо "токенов размышления" больше реального выхлопа, т.е. если поделить размер финального чистого ответа на общее потраченое время, получается 30-40 tps).
Поэтому я и думаю, может 26B сделает сразу качественно. tps формально будет ниже, чем 3B активных, но на итоговый результат столько же потратится благодаря MTP.
start_time,end_time,duration_sec,gpu,model,context,pp_ts,tg_ts,vram_peak,flags18:27:54,18:28:43,49.0,RTX 3090,Qwen_Qwen3.6-27B-Q4_K_M.gguf,32768,1099.51,36.8,18291,Q8 Cache
18:28:43,18:30:14,91.1,RTX 3090,Qwen_Qwen3.6-27B-Q4_K_M.gguf,65536,882.96,35.89,19507,Q8 CacheПока правда не получилось разогнать с MTP...
0x62ash
18.05.2026 04:10Но активных экспертов осталось мало, т.е. по моему пониманию это "скорость вместо качества"
Количество экспертов не меняется. Меняется место выполнения (gpu/cpu). Т.е. cmoe на качество работы модели не влияет.
27b существенно лучше qwen3.6 35b или nemotron cascade 2 (кстати, контекст на ней хоть и меньше, но все еще внушительный. за маленьким контекстом в q4 обновленной лламе).Antra
18.05.2026 04:10Да, я понимаю, что при той же модели те же веса/слои.эксперты будут обсчитаны.
Вопрос именно в том, что с MTP (якобы) можно иметь "активных" параметров раз в 5 больше (27B vs 3b) с приличным повышением качества ценой уже не пятикратного падения скорости, а раза в 2-3 всего. Что для задач с самопроверкой зачастую выдает финальный результат даже быстрее.
Про Nemotron - мы же говорим про "упихать в досутпную память". Миллионный контекст все равно не получится задействовать даже если теоретически какая-то модель и позволяет. А у немотрона за счет его мамбы можно практически весь его доступный контекст задействовать, и при этом не выгружать дполнительные слои на CPU.
Да, в Claude Code первый запрос приходится несколько минут ждать (если первоначально надо 25К токенов системного промпта обработать), зато потом он кешированый и уже так не тормозит.
Marwin
18.05.2026 04:10ну MTP не прям таки нивелирует разницу в скорости. Например, на Ampere картах разница между 27B и 35B примерно в 4 раза в фазе декода. А MTP даёт в лучшем случае х2
Antra
18.05.2026 04:10А еще (могу предположить) 27B чуть меньше размером, чем 35B, соответственно можно или квант побольше взять или меньше слоев в CPU выгружать, что добавит скорости. Хотя тут, конечно, не совсем корректно сравнивать слои на CPU у dense модели и эксперты у sparse.
nikulin_krd
18.05.2026 04:10В случае с квенами MoE-модель у них если и тупее, то не сильно. Для Claude Code и локальных моделей надо в settings.json указать в "env"(если нет то добавить) "CLAUDE_CODE_ATTRIBUTION_HEADER" : "0"(через export не работает) - так существенно снижается время разработки. Один и тот же промт у меня разогнался с 1:30 до 30 минут
vasimv
18.05.2026 04:10Этот аттрибут отключает специфичный для claude заголовок, из-за которого промпт-кэш сбрасывается постоянно, на собственно скорость работы модели никак не влияет, просто ей каждый раз приходится весь промпт с нуля перерасчитывать. Полный набор какой-то добрый человек выкладывал в реддите:
export CLAUDE_CODE_ATTRIBUTION_HEADER=0 export DISABLE_TELEMETRY=1 export DISABLE_COST_WARNINGS=1 export CLAUDE_CODE_ATTRIBUTION_HEADER=0 export CLAUDE_CODE_DISABLE_1M_CONTEXT=1 export CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000 export CLAUDE_CODE_AUTO_COMPACT_WINDOW=120000 export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=95 export DISABLE_PROMPT_CACHING=1 export CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 #export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 #export MAX_THINKING_TOKENS=0 export CLAUDE_CODE_DISABLE_FAST_MODE=1 #export DISABLE_INTERLEAVED_THINKING=1 #export CLAUDE_CODE_MAX_RETRIES": "3", export CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1 export CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY=1 export ENABLE_TOOL_SEARCH=auto export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
VO_Obsidian
18.05.2026 04:10Что насчет gemma 4? Так и не смог выяснить актуальную инфу по поддержке, гугл выкладывал MTP модели:
https://huggingface.co/google/gemma-4-26B-A4B-it-assistant
Но у unsloth ни квантов ни постов про поддержку этого, поддержки в основной ветке llamacpp кажется тоже нету. Есть ли форки с этим? И есть ли вообще смысл тут в mtp?
SabMakc
18.05.2026 04:10Поддерживается в ik_llama.cpp, заметное ускорение дает (при инфренсе на CPU во всяком случае). Это не самостоятельная модель, так что для любой gemma4 подходит, не обязательно от unsloth ждать.
P.S. на CPU и Qwen3.6-35B-A3B заметно быстрее стал, раза в 1.5 (в ik_llama.cpp).
P.P.S. избегайте unsloth, их кванты не могут похвастаться хорошим знанием русского, особенно в последнее время.
Mintavrus
18.05.2026 04:10на счет плохой поддержки русского в последнее время на unsloth моделях - я не заметил такого
SabMakc
18.05.2026 04:10В частности это видно по многословности ответов. Qwen славится своими краткими ответами (даже в рассуждающем режиме), но с UD-Q4 ответы в разы длиннее. На явных ошибках в ответах поймать сложнее, но тоже можно.
Так что мой текущий выбор - bartowski. Очень неплохо себя показывают относительно unsloth с UD или mudler с APEX (но с APEX игрался меньше).
nikulin_krd
18.05.2026 04:10А что мешает ограничить thinking budget, если вам так мешает "многословность". И не может быть так что от смены автора квантовой меняется поведение в thinking режиме
SabMakc
18.05.2026 04:10Там не просто квантование, там тюнинг под бенчмарки происходит (и некие “популярные сценарии использования”). Результаты в бенчмарках выше даже чем у оригинальной модели бывают. Ну а все прочее в просадке (место под кванты лимитировано же).
В итоге модель тупее, чем есть, но на бенчмарках просто топ.
P.S. thinking budget не поможет. Наоборот, высокий бюджет на размышления позволяет скрывать огрехи модели.
P.P.S. Я вообще в не-думающем режиме обычно использую - “размышления” редко когда действительно на пользу идут.
nikulin_krd
18.05.2026 04:10Какой тюнинг под бенчмарки?))) Кто вам это сказал?)) Там есть imatrix на котором делались динамические кванты. Никакого тюнинга под бенчмарки там нет))
P.S. thinking budget не поможет. Наоборот, высокий бюджет на размышления позволяет скрывать огрехи модели.
P.P.S. Я вообще в не-думающем режиме обычно использую - “размышления” редко когда действительно на пользу идут.
"Вы или крестик наденьте или трусы снимите" - вы же выше писали что хорошо когда мало думает, а теперь пишете обратное))
SabMakc
18.05.2026 04:10Я сказал “хорошо когда модель немногословна”. Если модель многословна - значит что-то пошло не так. Показательно если сравнивать одну и туже модель, но в разных квантах.
Размышления помогают скрывать проблемы с квантом - это да. Но лично я предпочитаю брать нормальный квант, которым размышления редко когда действительно нужны. Если без размышлений модель превращается в тыкву - ну что же, у вас проблемы.
P.S. Да, “тюнинг под бенчмарки” - это мое мнение. Официально там imatrix и динамические кванты (как и у bartowski, к слову). Но видать что-то пошло не так и топовые результаты в бенчмарках еще не все, что надо. Потому как у bartowski работает отлично, а у unsloth наблюдаю проблемы.
P.P.S. Лично я не могу объяснить результаты вида “в бенчмарках лучше оригинала” кроме как тюнингом (где-то встречалось и такое).
nikulin_krd
18.05.2026 04:10Берем обе версии Бартовски и Анслот например Q4_K_M и смотрим что же они там наквантовали и видим почему Анслот выигрывает, а не опираемся на какое-то субъективное мнение... У них attention например существенно лучше квантуется и многое другое... Просто сравните "в лоб". Я не знаю что вы там за проблемы у анслота нашли - я проблем не наблюдаю
SabMakc
18.05.2026 04:10Вот как раз Q4_K_M от bartowski и сравнивал с UD-Q4_K_XL (Qwen3.6-35B-A3B). Лоб-в-лоб.
На одних и тех же исходных данных, у unsloth ответы длиннее раза в 2-3 получались. А если в “не-думающем” режиме запускать, то unsloth мог и не справиться с задачей вовсе (оставлял кучу комментариев “что тут делается”, но без реального кода).
gemma-4-26B-A4B показала схожие результаты (разве что в не-думающем режиме такой просадки не увидел, да и в целом просадка ниже была).
Да Qwen3-Coder-30B-A3B обскакал обе, хотя сильно старее. Причем использовался UD-Q4_K_XL от unsloth - т.е. раньше такого не было (или было менее явно).
SabMakc
18.05.2026 04:10bartowski вчера выложил mtp-модели как отдельный GGUF-файлы (для указания через
--spec-draft-modelвllama.cpp). Вik_llama.cppне завелось, может еще добавят поддержку…Вообще, MTP-слои можно “пересаживать” между моделями (скрипт встречал для этого), может и тут удастся объединить…
P.S. почитал комментарии - bartowski скорее всего перевыложит оригинальные GGUF-файлы с MTP. С отдельной моделью выше накладные расходы.
fermentum
18.05.2026 04:10Делал несколько десятков тысяч запросов к последним Квен и Гемме под квантами от Unsloth. Никаких проблем с русским не заметил. Обе модели прекрасно работают и четко следуют промпту. Но ниже Q4 обычно не опускаюсь, там уже артефакты сжатия мешают.
Поэтому полностью отказался от Бартовски, хотя он делает отличную работу.
Вы документально можете подтвердить вашу теорию о проблемах Unsloth? Тикет открывали?
SabMakc
18.05.2026 04:10У него сколько не проблемы с русским (такое я только на UD-Q2 встречал), а скорее проблемы с качеством работы модели на русском.
Нет, тикетов не открывал. Для грамотного подтверждения теории надо серьезное исследование провести, на что совершенно нет времени:
Какие кванты какие результаты дают? А от других квантовщиков?
А точно именно русский дает такие проблемы или это область знаний виновата?
А какие языки подвержены? А какие темы вызывают проблемы?
А какие параметры запуска использовались и что за софт? А что с другими параметрами или другим софтом?
А какой системный промт использовался? А если другой?
Т.е. нужен полноценный бенчмарк, нормализация результатов и т.д. Сейчас же просто есть пример, где явно LLM не справляется на достаточно простой задаче. При этом выдавая гораздо более многословный ответ, который я и считаю индикатором проблемы для менее показательных случаев.
Да, у меня еще были подобные случаи, но я не копал их глубоко - или перегенерировал результат, или переключался на другую модель, или включал мышление.
Но именно очень ярко проблема всплыла у
unsloth/Qwen3.6-35B-A3B-GGUF:UD-Q4_K_XLв не-думающем режиме. К той же gemma4 вопросов по существу и нет, кроме “немного более многословный ответ”.
izogfif
18.05.2026 04:10А есть сравнение с vLLM, sglang или на чем там оригинальные веса работают? Речь про то, что Qwen выкладывает веса в формате, который нельзя запустить в llama.cpp, зато можно в vLLM и других программах. И в них тоже есть multi-token prediction (в vLLM вроде можно даже указать, сколько токенов предсказывать, 2 или 3). Учитывая, что vLLM запускается несколько минут, подсчитывая какие-то там CUDA graph, она может работать быстрее, чем llama.cpp.
SlavikF
18.05.2026 04:10Я сравнивал у себя на RTX 4090 D (48 Гб памяти VRAM).
Детали и конфиги вот здесь:
https://huggingface.co/unsloth/Qwen3.6-27B-MTP-GGUF/discussions/25
Llama.cpp UD-Q6, без MTP: 31 токен в секунду
Llama.cpp UD-Q6 и MTP: 60 токенов в секунду. Используется дополнительные 2 ГБ VRAM. Prompt processing замедляется на 20%
VLLM и MTP: 40-48 токенов в секунду. В 2 раза быстрее prompt processing.
Mintavrus
18.05.2026 04:10У меня на модели qwen3.6 27b Q8_K_XL от unsloth наибольшую прибавку дает запуск с параметрами:
--spec-type draft-mtp --spec-draft-n-max 6 \ --spec-draft-p-min 0.75 \
andrey_snegovik
18.05.2026 04:10Имея конфигурацию только из CPU (i7-12700) + RAM 32ГБ, есть смысл пробовать что-то выжать из MTP моделей?
SabMakc
18.05.2026 04:10Да, Qwen3.6-35B-A3B / gemma-4-26B-A4B очень хороши. От MTP выигрыш на 30-50% возможен (gemma-4 с assistant аналогично). Плюс сам софт оптимизируют.
Для чата скорости хватает, но для работы агента слабовато будет.
andrey_snegovik
18.05.2026 04:10"очень хороши" - сколько токенов секунду?
Не могли бы пожалуйста поделиться результатами из llama-bench с параметрами?--n-prompt 4096 --n-gen 4096SabMakc
18.05.2026 04:10Результаты для
ik_llama.cpp, но без mtp/assist ускорения (оно дает еще 30-50% на TG). Вllama.cppPP ниже раза в 2, TG примерно одинаковый будет.gemma-4-26B-A4B
$ llama-bench -m models/bartowski_google_gemma-4-26B-A4B-it-Q4_K_M.gguf --n-prompt 4096 --n-gen 4096 | model | size | params | backend | threads | test | t/s | | ------------------------------ | ---------: | ---------: | ---------- | ------: | ------------: | ---------------: | llm_scale_gate_inp_s: n_embd = 2816 | gemma4 ?B Q4_K - Medium | 16.41 GiB | 25.97 B | CPU | 8 | pp4096 | 69.98 ± 3.24 | | gemma4 ?B Q4_K - Medium | 16.41 GiB | 25.97 B | CPU | 8 | tg4096 | 8.43 ± 0.10 | build: 40aae0b6d (4509)Qwen3.6-35B-A3B
$ llama-bench -m models/bartowski_Qwen_Qwen3.6-35B-A3B-Q4_K_M.gguf --n-prompt 4096 --n-gen 4096 -r 1 | model | size | params | backend | threads | test | t/s | | ------------------------------ | ---------: | ---------: | ---------- | ------: | ------------: | ---------------: | | qwen35moe 35B.A3B Q4_K - Medium | 19.91 GiB | 34.66 B | CPU | 8 | pp4096 | 88.11 ± 0.00 | | qwen35moe 35B.A3B Q4_K - Medium | 19.91 GiB | 34.66 B | CPU | 8 | tg4096 | 11.42 ± 0.00 | build: 40aae0b6d (4509)P.S. “очень хороши” - это, в первую очередь, личная оценка качества работы при приемлемой скорости.
andrey_snegovik
18.05.2026 04:10Отлично! Спасибо за результаты!
А для моделей mtp есть возможность сделать ровно такие же тесты? Чтобы как раз и посмотреть разницу)
Кстати для полной картины можно и для llama.cpp прикрепить, чтобы увидеть просадку на PPP.S. В прошлой статье вроде Shannon рекомендовал использовать UD_Q4_K_XL для llama.cpp (не ik). Может на них тест PP будет норм?
SabMakc
18.05.2026 04:10MTP не смог задать - нет нужных флагов (может что криво смотрел). Не уверен, что там вообще MTP применим - если тест просто рандом генерирует, то MTP не даст ускорения. Тем более, что MTP дает разные результаты для разного типа контента.
Для
llama.cppтест с gemma-4-26B-A4B дал 39.85 / 8.15 (PP / TG), а для Qwen3.6-35B-A3Bllama.cppупал )P.S. я не сторонник unsloth - на мой взгляд, они сильно агрессивно подходят к квантованию отдельных слоев, из-за чего качество на русском падает.
SabMakc
18.05.2026 04:10P.S. В прошлой статье вроде Shannon рекомендовал использовать UD_Q4_K_XL для llama.cpp (не ik). Может на них тест PP будет норм?
ik_llama.cppкак раз оптимизирован для работы на CPU. UD не даст существенной разницы, скорее даже хуже работает (как понимаю, из-за очень разного квантования разных слоев - местами накладных расходов получается больше). Но это субъективные ощущения, целенаправленных тестов не делал - с момента теста софт обновился и заметно ускорился, сейчас может и лучше.
Xao
18.05.2026 04:10А где можно посмотреть графики, как меняется "хорошесть разных моделей" в зависимости от квантизации и количества параметров?
java73
18.05.2026 04:10Это ошибка так ориентироваться. Надо взять свои собственные привычные сценарии использования и на них прогнать. Вот и поймете. Я так по своим задачам вынужденно сделал выбор в пользу qwen 3.6 moe против Gemma 4 26b, потому что именно в конкретных задачах квен выдала просто идеальный результат (создание документов по образцам, написание договора, due diligence контрагента по всяким апи и реестрам в тырнете, напиисание протоколов, решений в корпоративной сфере).
kreo_OL
18.05.2026 04:10А нет примеров как вы проводите эти тесты?
Не кидаете же просто промпт и потом на глазок результат сравниваете? Или так и происходит? :)
java73
18.05.2026 04:10Сами документы - на глазок, а точнее на корректность выполнения по сути, проверяю глазами, да. Но технически также сравниваю скорость, объем раздумывания, смотрю, что модель там в своих размышлениях делала. Строго ли следовала инструкциям. Грузила ли нужные инструменты в правильной последовательности.
fermentum
18.05.2026 04:10Unsloth и Бартовски выкладывают тесты хорошести квантов. Вот например https://unsloth.ai/docs/models/qwen3.6#benchmarks
nikulin_krd
18.05.2026 04:10Сейчас сделал тест с MTP и без на Qwen3.6-35B-A3B. По крайней мере у Unsloth я бы не использовал MTP и вот почему:
Запрос: "Вопрос: "Моя машина грязная и я хочу её помыть.Автомойка в 100 м от дома. Как мне поступить: доехать на машине или прогуляться пешком? Ответь одним словом: 'доехать' или 'прогуляться'." Дай ответ на этот вопрос и оценку точности ответа, где 1.0 - абсолютно точно, 0.0 - абсолютно не точно и это критерий оценки твоей уверенности в этом ответе. Значения могу лежать в диапазоне от 0.0 до 1.0. Выдача должна быть в JSON со следующими полями: answer, accuracy"
Ответ с MTP:
Скрытый текст
The user is asking a question in Russian. Question: "My car is dirty and I want to wash it. There is a car wash 100 meters from home. How should I proceed: drive there or walk? Answer with one word: 'drive' or 'walk'." Requirement: Answer with 'drive' or 'walk', and provide an accuracy score (0.0 to 1.0). Output in JSON format with fields 'answer' and 'accuracy'. Analysis: If the car is dirty, it needs to be washed. The car wash is only 100 meters away. Driving a dirty car 100 meters to wash it is counter-intuitive and inefficient. It's much closer to walk there. Therefore, the logical answer is 'walk' (прогуляться). Accuracy should be high, close to 1.0. Let's double check the logic. Goal: Wash the car. Location of wash: 100m away. Current state: Car is at home, dirty. Option A: Drive car to wash (100m). This defeats the purpose of washing immediately, wastes fuel, and keeps the car dirty for 100m. Option B: Walk to wash. You can take a bag of cleaning supplies (or just go to the wash where they clean it), or the car wash might offer mobile service, or you just go to the location to arrange it. Actually, usually if the car is dirty, you walk to the car wash to drop it off or wash it yourself. Driving it 100m is silly. So 'прогуляться' is the correct answer. JSON format: { "answer": "прогуляться", "accuracy": 1.0 } Wait, the prompt says "Ответь одним словом: 'доехать' или 'прогуляться'." I will output exactly that. Let's construct the JSON. answer: "прогуляться" accuracy: 1.0 Check constraints: "Выдача должна быть в JSON со следующими полями: answer, accuracy" I will produce just the JSON. Done. Self-Correction/Refinement during thought: Is there any trick? "My car is dirty... car wash 100m away." Usually, if a car is dirty, you don't drive it. You walk to the car wash. Accuracy 1.0 is appropriate. Output matches requirement. Proceed. Output generation. ``
json { "answer": "прогуляться", "accuracy": 1.0 }`Matches perfectly. No extra text. I will generate the response. One minor point: The prompt asks for one word answer in the text, but also asks for JSON output. I will provide just the JSON as requested. "Выдача должна быть в JSON со следующими полями: answer, accuracy" -> Output must be JSON. Ready. Output matches. Proceeds. [Final Check] Question: "Моя машина грязная и я хочу её помыть.Автомойка в 100 м от дома. Как мне поступить: доехать на машине или прогуляться пешком? Ответь одним словом: 'доехать' или 'прогуляться'." Logic: Car is dirty -> don't drive it -> walk. Answer: прогуляться Accuracy: 1.0 JSON structure correct. Done. Output Generation.`json { "answer": "прогуляться", "accuracy": 1.0 }`` All good. Proceeds. (Self-Correction/Verification during generation) Wait, is there any scenario where driving is better? Maybe if you need to transport cleaning equipment? But 100m is very short. Walking is universally the logical choice for a dirty car nearby. Accuracy 1.0 is safe. The prompt asks for JSON. I will output strictly JSON. Done. Output matches response. Proceeds. [Final Output Generation] -> ProceedsОтвет без MTP:
Скрытый текст
The user wants me to answer a question about whether to drive or walk to a car wash that is 100 meters away from their house, given that their car is dirty and needs washing. The answer must be a single word: 'доехать' (drive) or 'прогуляться' (walk). I also need to provide an accuracy score (0.0 to 1.0) and output the result in JSON format with fields 'answer' and 'accuracy'. Reasoning: The goal is to wash the car. The car wash is 100 meters away. If I walk to the car wash, I cannot wash the car because the car is at home. Therefore, I must drive the car to the car wash to wash it. Even though it's a short distance (100m), the logical action to get the car washed is to drive it there. Answer: 'доехать' Accuracy: 1.0 (It is logically the only way to wash the car). JSON Output: { "answer": "доехать", "accuracy": 1.0 }
Antra
18.05.2026 04:10Интересный тест!
Какая квантизация была (как самой модели, так и KV cache)? И сколько раз вы пробовали?
Множественной перегенерацией я сомг добиться "прогуляться", но обычно нормально отвечали.
На Q5_K_XL (RTX 3090 24GB) хоть MTP, хоть просто MoE, хоть unsloth, хоть bartowski - примерно одинаково отвечают
unsloth\Qwen3.6-27B-MTP-GGUF\Qwen3.6-27B-UD-Q5_K_XL.gguf
-ngl 99 -fa on -np 1 -ctk q8_0 -ctv q8_0 -c 65536 --spec-type draft-mtp --spec-draft-n-max 6 -fitt 512Долго думала, итоговых токенов мало, поэтому Anything LLM пишет всего лишь 1 токен в секунду.
[0m[34m0.55.841.384[0m [32mI [0mslot create_check: id 0 | task 70 | created context checkpoint 1 of 32 (pos_min = 198, pos_max = 198, n_tokens = 199, size = 150.043 MiB) [34m0.57.419.427[0m [32mI [0mslot print_timing: id 0 | task 70 | n_decoded = 103, tg = 68.34 t/s [34m1.00.438.963[0m [32mI [0mslot print_timing: id 0 | task 70 | n_decoded = 222, tg = 49.04 t/s [34m1.03.478.192[0m [32mI [0mslot print_timing: id 0 | task 70 | n_decoded = 324, tg = 42.82 t/s [34m1.06.507.649[0m [32mI [0mslot print_timing: id 0 | task 70 | n_decoded = 468, tg = 44.17 t/s [34m1.09.570.021[0m [32mI [0mslot print_timing: id 0 | task 70 | n_decoded = 597, tg = 43.71 t/s [34m1.12.606.563[0m [32mI [0mslot print_timing: id 0 | task 70 | n_decoded = 738, tg = 44.21 t/s [34m1.15.684.694[0m [32mI [0mslot print_timing: id 0 | task 70 | prompt eval time = 372.88 ms / 203 tokens ( 1.84 ms per token, 544.41 tokens per second) eval time = 19772.48 ms / 914 tokens ( 21.63 ms per token, 46.23 tokens per second) total time = 20145.36 ms / 1117 tokens draft acceptance rate = 0.54829 ( 704 accepted / 1284 generated) [34m1.15.684.712[0m [32mI [0mstatistics draft-mtp: #calls(b,g,a) = 2 281 281, #gen drafts = 281, #acc drafts = 243, #gen tokens = 1686, #acc tokens = 886, dur(b,g,a) = 0.003, 5283.043, 0.622 ms [34m1.15.684.755[0m [32mI [0mslot release: id 0 | task 70 | stop processing: n_tokens = 1121, truncated = 0 [34m1.15.684.770[0m [32mI [0mslot print_timing: id 0 | task -1 | n_decoded = 914, tg = 46.23 t/s---
unsloth\gemma-4-26B-A4B-it-GGUF\gemma-4-26B-A4B-it-UD-Q5_K_XL.gguf
-ngl 99 -fa on -np 1 -ctk q8_0 -ctv q8_0 -c 65536 -fitt 512[34m4.41.968.646[0m [32mI [0mslot print_timing: id 0 | task 297 | n_decoded = 100, tg = 93.33 t/s [34m4.44.970.286[0m [32mI [0mslot print_timing: id 0 | task 297 | n_decoded = 389, tg = 95.50 t/s [34m4.47.353.585[0m [32mI [0mslot print_timing: id 0 | task 297 | prompt eval time = 255.92 ms / 202 tokens ( 1.27 ms per token, 789.30 tokens per second) eval time = 6456.41 ms / 619 tokens ( 10.43 ms per token, 95.87 tokens per second) total time = 6712.34 ms / 821 tokens [34m4.47.353.636[0m [32mI [0mslot release: id 0 | task 297 | stop processing: n_tokens = 820, truncated = 0nikulin_krd
18.05.2026 04:10У вас dense-модель, а у меня MoE. Я использовал Q4_K_XL и q8_0 для kv-кэша
sergeym69
18.05.2026 04:10Ну так нормальные параметры для модели надо ставить, а не дефолтные, тогда и работать будет хорошо
MPT
Скрытый текст
Here’s a thinking process:
Analyze User Input:
Question: “Моя машина грязная и я хочу её помыть. Автомойка в 100 м от дома. Как мне поступить: доехать на машине или прогуляться пешком? Ответь одним словом: ‘доехать’ или ‘прогуляться’.”
-
Constraints:
Answer must be exactly one word: either ‘доехать’ or ‘прогуляться’.
Provide an accuracy score between 0.0 and 1.0 representing confidence.
Output must be in JSON format with fields:
answer,accuracy.
Context/Logic: The car is dirty, and the user wants to wash it. The car wash is only 100 meters away. If they drive the dirty car to the car wash, they’ll just drive a dirty car 100m, which is fine, but the point is to wash it. Actually, driving a dirty car to a car wash is standard. But wait, if they walk, how will the car get washed? The car needs to be at the car wash. So they must drive it there. Walking wouldn’t make sense because the car itself needs to be washed. Therefore, the logical answer is ‘доехать’.
Confidence: Very high. It’s a straightforward logical deduction. I’ll assign 1.0.
Formulate Output:
JSON structure:
{"answer": "доехать", "accuracy": 1.0}Check constraints: One word? Yes. Matches options? Yes. JSON format? Yes. Fields correct? Yes. Accuracy in range? Yes.
Self-Correction/Verification:
Could there be a trick? “Моя машина грязная и я хочу её помыть.” -> The car needs washing. Car wash is 100m away. To wash the car, the car must go to the car wash. So driving is necessary. Walking would leave the car dirty at home. So ‘доехать’ is definitively correct.
Accuracy: 1.0 is appropriate given the clear logic.
JSON format: Must be valid. I’ll output exactly that.
All constraints met. Proceed. Output:
{"answer": "доехать", "accuracy": 1.0}✅без MTP
Скрытый текст
Analyze User Input:
Question: “Моя машина грязная и я хочу её помыть. Автомойка в 100 м от дома. Как мне поступить: доехать на машине или прогуляться пешком? Ответь одним словом: ‘доехать’ или ‘прогуляться’.”
Translation/Meaning: “My car is dirty and I want to wash it. The car wash is 100m from home. What should I do: drive there or walk? Answer with one word: ‘drive’ or ‘walk’.”
Constraints: Answer must be exactly one word: ‘доехать’ or ‘прогуляться’. Output must be JSON with fields
answerandaccuracy(0.0 to 1.0).Task: Provide the answer and an accuracy/confidence score.
Evaluate the Scenario:
The car is dirty and needs washing.
The car wash is only 100 meters away.
If I walk, the car stays dirty. I need to get the car to the car wash to wash it.
Therefore, I must drive the car to the car wash. Walking makes no sense for the stated goal (washing the car).
Answer: ‘доехать’
Determine Accuracy/Confidence:
The logic is straightforward and unambiguous. The goal is to wash the car, so the car must be at the car wash. Driving is the only logical choice.
Confidence should be very high. I’ll set it to 1.0.
Format Output:
Must be JSON with fields:
answer,accuracy.Structure:
{"answer": "доехать", "accuracy": 1.0}
Self-Correction/Verification:
Check constraints: “Ответь одним словом: ‘доехать’ или ‘прогуляться’.” -> Matches.
JSON format required -> Matches.
Accuracy range 0.0-1.0 -> Matches.
Logic sound? Yes. Walking wouldn’t get the car washed. Driving is necessary.
Output matches exactly.
All good. Proceed.
Generate response.
{"answer": "доехать", "accuracy": 1.0}✅Note: I’ll make sure the JSON is valid and matches the exact field names requested. No extra text. The prompt says “Выдача должна быть в JSON со следующими полями: answer, accuracy”. I will output only the JSON.✅
Final check of the prompt: “Дай ответ на этот вопрос и оценку точности ответа… Выдача должна быть в JSON со следующими полями: answer, accuracy” All constraints met. Output matches.✅
Proceed. [Output Generation] ->
{"answer": "доехать", "accuracy": 1.0}(Self-Correction/Refinement during thought: Should I include any explanation? The prompt says “Выдача должна быть в JSON…”, so strictly JSON only is safer. I’ll output just the JSON.)✅Final Answer Generation.
{"answer": "доехать", "accuracy": 1.0}Done. [Output matches response]✅(Self-Correction/Verification during generation): Wait, let’s double check the exact wording. “Ответь одним словом: ‘доехать’ или ‘прогуляться’.” The JSON field
answershould contain that word. Accuracy is a float. All good. One minor point: Sometimes prompts like this are trick questions (e.g., if you walk, you can’t wash the car, so obviously drive). It’s straightforward. Confidence 1.0 is appropriate. Output matches exactly.✅Proceeds. [Final Output Generation] ->
{"answer": "доехать", "accuracy": 1.0}(Done.)Конечный ответ одинаковый !
nikulin_krd
18.05.2026 04:10Нормальные это какие? Подскажите? Потому что у меня не дефолтные))
У меня из того что влияет на ответ - это UD-Q4_K_XL и кэш в обоих случаях поквантован в q8_0. Т.е. условия тестирования одинаковые, а результаты разные, что говорит о том, что MTP все же делает хуже.
0x62ash
18.05.2026 04:10Думаю речь про температуру и сэмплинг:
temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0
Shannon Автор
Ещё из новостей про llama.cpp:
До сих пор не добавили TurboQuant, но на то есть причина - ощутимая просадка скорости, так как вычисления до сих пор не смогли полноценно перенести на GPU и работа выполняется на CPU. Вместо этого добавили “у нас есть turboquant дома”, а именно Rotate Activations. Это одна из частей турбокванта, вращение активаций через матрицу Адамара. И даже это очень сильно повысило качество квантования KV-кэша в размере Q4_0.
Это улучшение включено по умолчанию, и работает для KV-кэша всех вариантов (q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1). Я прогнал пару тестов Q4_0 на 256к контексте, и сработало не плохо, не хуже чем Q8_0.
Добавили нативную поддержку NVFP4 в GGUF. NVFP4 лучше снижает ошибку квантования чем MXFP4, так как разбивает микроблоки дополнительно в 2 раза, делая их более гранулированными, и используют адаптивный scale factor для этих блоков, повышая точность. Я прогнал пару замеров KLD, и кванты NVFP4 GGUF и правда лучше чем чистые MXFP4.
Ryav
Обновлять llama.cpp нужно, с какой версии это доступно?
И TurboQuant же влияет на размер контекста, не на качество кэша, нет? У меня уже стоит q4_0 и я бы хотел увеличить размер окна с 64к до 128к (а лучше 256к).
Aldrog
Он уменьшает потери при квантизации. 4 бита так и останутся четырьмя битами, но по качеству будут эквивалентны старым 6-8 условно.
lainconn
Немного уточнений по результатам:
Concurrency - 1?
Значения в таблице - token_throughput?
Kreatifchk
Как всегда очень полезная статья, спасибо!
EvilFox
Есть rotorquant.
nikulin_krd
Весьма спорное утверждение. В ассиметрике K:turbo4 V:turbo3 я имею больше скорость tg и чуть ниже скорость pp, нежели на q8_0
Wo1d
Чьи кванты nvfp4 можете рекомендовать на данный момент? Unsloth пока что только mxfp4 в gguf дают.