вместо cpu-moe использовал n-cpu-moe - раскидал сколько смог слоев в видеокарту. n-cpu-moe на обычной llama.cpp дал 50 т/с, на ik_llama.cpp получил 60 т/с
Для qwen3.6 на днях добавили поддержку MTP, можно получить еще больше скорости без потери качества. Для Qwen3.6-35B-A3B ускорение не такое большое, как для Qwen3.6 27B, но оно тоже есть.
Интересная идея и реализация, а есть какой-то результат для примера?
Неделю назад обучал 0.25B LLM с нуля исключительно на статьях с хабра, датасет IlyaGusev/habr, просто посмотреть, что из этого получится. SFT датасет автоматически построен из датасета хабра, чтобы не было примесей из других источников. Токенизатор обучен тоже только на хабре.
Идея была попробовать обучить 1B, но времени было мало, поэтому на коленке обучил только 0.25B за 3 часа. Первый шаг, это pre-train, который умеет только продолжать то, что ему задать как промпт:
Правильное понимание, где римские цифры, а где буквенное перечисление
Что-то похожее на связный текст
Обучение pre-train было всего на 1 эпохе, поэтому знания плохо усвоены, но что-то аппроксимировано. Модель сама выявила паттерны русского языка, родов, склонений и прочего, хотя логика и знания хромают, общее написание фраз вполне корректное.
Для примера как выглядело начало обучения:
10% от 1 эпохи
Дальше идет обучение SFT, где pre-train учится шаблону чата и умению отвечать на вопросы и уметь разделять где assistant, а где user. Качество общения зависит от качества SFT датасета, его я сделал автоматически и всего на 1к записей, как старт сойдет, но о проработке речи не идет:
Первое, что ответила модель после SFT обучения, все совпадения случайны
Выставил температуру минимально, результаты должны быть максимально близки. Есть шанс заруинить. Допустим взяли черновую очень маленькую 0.6B
Отвечаю сам себе и уточняю для тех, кто сюда забредёт. Это информация устарела, она больше не актуальна. Проблем с черновыми моделями нет.
Спекулятивное декодирование дает идентичный результат без искажений, я специально проверил исходники llama.cpp, чтобы убедиться, что это действительно так. Особенно это актуально для новых методов MTP, Eagle-3, DFlash, которые дают сильно большее ускорение, чем старый метод через маленькие черновые модели.
Так не получится сравнить, сделав несколько прогонов, вы оцениваете сэмплинг, а не модель MTP. Модель детерминирована, а сэмплинг стохастичен и сэмплинг это внешняя от модели сущность. Для сравнения надо либо отключить сэмплинг, либо собрать статистику на большом количестве замеров.
Прогнал 100 замеров без MTP и 100 с MTP на вашем задании. Температура 0.8, top_p 0.85.
Вариант с MTP выдал 64% правильных ответов, а без MTP - 57%. Но не стоит цепляться за сами проценты, в следующем прогоне будет наоборот, серия “доехать” может составлять 10 подряд, а потом 5 подряд будет “прогуляться”, один “доехать” и снова 5 “прогуляться”. Главное тут то, что температура 0.8 добавляет слишком много случайности, а top_p 0.85 креативности (значение по умолчанию в 0.95 добавляет ещё больше креативности).
Температура 0.3, процент правильных ответов стремится к 75%:
Температура 0, процент правильных ответов 100%:
Сэмплинг в данном случае вносит слишком много хаоса, модель хоть и может найти правильный ответ на задачу, но внешняя случайность от сэмплинга уводит модель в сторону. MTP тут не при чём, в статье я как раз смотрел исходники llama.cpp чтобы убедиться, что MTP не добавляет от себя ничего и никак не искажает генерацию.
До сих пор не добавили 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.
В llama.cpp завезли поддержку Qwen3.6 MTP. Новые кванты уже создали со слоями MTP. Написал статью что такое MTP, как запустить и какое ускорение получилось. Также проверил исходники llama.cpp, чтобы проверить, качество оригинала сохраняется или искажается:
Еще можно какие-нибудь Q2_K_L от bartowski попробовать - с гарантированно равномерным квантованием экспертов.
Это хороший аргумент, но есть несколько нюансов:
bartowski статические кванты квантует с использованием imatrix, поэтому равномерного квантования там не может быть, неравномерность задается на уровне суперблоков через imatrix.
У него калибровачный датасет 400к токенов, из них только 4к на русском, 1%. И этот 1% не отборных текстов, а каких-то разорванных кусков.
calibration_datav5.txt от Bartowski, отсортирован только русский текст
bartowski тоже не квантует равномерно, часть слоев выше, часть ниже.
Bartowski, qwen3.6-35B-A3B, Q4_K_M и Q2_K_L
Поэтому его кванты не чистые статические классические Q4_K_M, а являются динамическими. Хотя тут, смотря что вы имели ввиду под "гарантированно равномерным".
Вообще, мне нравятся кванты от ubergarm, они весят меньше, что важно когда мало VRAM, используют новые алгоритмы квантования, которые сохраняют больше точности, квантование тоже равномерное, без сильных экспериментов, imatrix содержит уже 2% русского текста.
Но кванты ubergarm сложно рекомендовать, так как требуют понимая ik_llama.cpp, которая не имеет автонастроек fit, не дружит с AMD и тому подобное.
Ещё из интересного для квантов, недавно завезли NVFP4 GGUF в llama.cpp. NVFP4 имеет в 2 раза меньший размер микроблоков, что повышает точность суперблоков, и имеет более детальный scale factor чем у MXFP4, когда внутри в рецептах начнут использовать nvfp4 вместо Q4_K, то это, возможно, не плохо повысит качество.
Чистые NVFP4 тоже работают не плохо, уже в GGUF виде можно запускать.
Это хорошо, что он откатил свой рецепт, я перестал качать его кванты когда он начал, пытаясь выиграть в размере, часть ffn квантовать в Q3_K, что ударяло по качеству Q4_K_M. Если он ещё увеличит процент русского текста в своем imatrix с 1% хотя бы до 5%, то его кванты будут совсем хороши.
Скажите пожалуйста, а точно ли надо скачивать библиотеки cudart-llama и помещать в довесок к основным файлам запуска? Всегда работало без них. Сейчас попробовал их тоже закинуть - разницы абсолютно никакой и по логам что-то не видно, что он хоть как то с ними взаимодействует…
У вас скорее всего CUDA toolkit стоит. У большинства его нет, поэтому нужно.
как минимум с этим надо быть осторожным и перепроверить на конкретной задаче и модели, не попадаете ли вы в эту деградацию 10%.
Перепроверять это правильно, но вы не перепроверили в статье, а используете как пруф цифры, которые уже не актуальны и вводят в заблуждение.
Вы ссылаетесь на старый пост со старыми квантами. Там деградация была, но это была аноримальная деградация из-за использования mxfp4 для ffn-тензоров вместо K-квантов, аномалию почти сразу заметили и исправили. Было проведено большое исследование с квантами, в итоге кванты переделали, способ квантования UD изменили.
График от комментатора выше, где видно преимущество UD квантов Qwen3.6 - это как раз тесты после исправления. По комплексной метрике KLD, которая точнее чем PPL, исправленные UD обходят остальные кванты, включая Bartowski.
Проблема новых моделей и квантов в том, что их исправляют несколько раз после выхода, и не стоит использовать посты 3 месячной как источник для статьи, не уточнив были ли исправления. Например, для Gemma4 было 5 исправлений, включая исправления в самой llama.cpp, и каждый раз надо было перекачивать кванты. Вначале Gemma4 была не пригодна во многих задачах, включая вызовы инструментов и агентов, сейчас это всё исправили, но если ссылаться на первые посты про Gemma4, то “выяснится”, что она “не пригодна” полностью.
Это просто скриншоты агенту, в qwen code в новых версиях можно копи-пастить изображения, либо обычным @bug7.png добавлять в диалог.
Кстати, по поводу качества. Пока видел мало обсуждений свежего Qwopus, это Qwen3.5 и 3.6 дообученные на выдаче больших моделей. Есть в разных размерах, включая Qwopus3.5-4B. Сейчас пробую Qwopus3.6-27B-v1-preview, в целом впечатления положительные, как будто бы лучше чем простой Qwen3.6 27B, но нужно больше экспериментов.
Формат от автора bartowski, на которого я рекомендую обратить внимание.
Q4_K_M отклоняется от эталона на 2,1%. UD-Q4_K_XL - на 9,7%
Q4_K_M - это не формат от Bartowski, у него не классические статические Q4_K_M кванты, хоть он и называет их так.
Bartowski для всех своих квантов применяет кастомные динамические рецепты, например, ffn он квантует как Q3, хотя должен как Q4, и для всех статических квантов, кроме Q8_0, он применяет свой imatrix, который не должен применяться для классического Q4_K_M.
Другая проблема в том, что в imatrix Bartowski нет или мало русского языка в датасете, и она включает в себя wiki text, поэтому показатели PPL завышены, но на практике квант оказывается сломан и не работает как надо, что трудно понять.
Новее ≠ лучше: перплексия не врет
Но метрики перплексии (PPL) на WikiText-2 рисуют другую картину:
Итог простой: не гонитесь за «новым» и «продвинутым» форматом. Проверяйте метрики конкретно под свою модель. Иногда старое доброе работает лучше.
Перплексия постоянно врёт. К PPL нужно относиться с осторожностью, её не стоит сравнивать в лоб, это не мера качества модели, это первичная оценка деградации квантов в рамках одного создающего, чтобы заметить аномальное отклонение. Для оценки качества кванта вместо PPL используют KLD, эта метрика показывает более объективную деградацию кванта.
Недавно показывал как делается KLD замер, и в качестве сравнения как раз брал классику Q4_K_M, которая выступила на уровне UD-Q3_K_XL.
Чем ниже значение, тем лучше
Unsloth-кванты исторически проседают именно на MoE-архитектурах со сложной маршрутизацией экспертов
Спорное утверждение. В недавней статье я показывал на что способен квант Qwen3.6-35B-A3B UD-Q2_K_XL, этот квант хуже чем UD-Q4_K_XL, но даже в таком низком значении он не сломан и выполняет работу.
UD-Q2_K_XL сделала реплику Win11 с рабочими окнами, пуском и анимациями:
Qwen3.6-35B-A3B-UD-Q2_K_XL, 4060 16гб, 60 t/s
И в агентном режиме создала проект “Minecraft в браузере”, включая правки через Vision:
Qwen3.6-35B-A3B-UD-Q2_K_XL
Gemma4 только в размере Dense 31B смогла что-то подобное повторить, MoE 26B-A4B не справилась и в программировании она сильно хуже себя показывала.
Для Gemma4 в очередной раз что-то починили, и надо перекачать gguf файлы. Конкретнее исправили вызовы инструментов в шаблоне чата, из-за чего в агентах эти модели работали плохо. Чтобы не перекачивать gguf, можно скачать исправленный шаблон чата и указывать его при запуске.
MTP - это отдельный модуль, который обучается вместе с моделью, и позволяет предсказывать 2-3 токена вперед с высокой долей принятия токена. Для MTP и EAGLE3 (альтернатива от nvidia) обычно используется точная верификация, поэтому результат идентичен (в отличии от варианта через draft-модели).
Слои MTP и у Gemma4 и Qwen3.6 встроены в модель, но в стандартных gguf они вырезались, так как не было поддержки. Их можно было использовать в vLLM, что ускоряло в 2-3 раза. Для Gemma4 их дополнительно выложили отдельно.
Тут как-то до сих пор нет консенсуса. Если это Dense - то однозначно работает, если MoE за счет дополнительных GPU целиком влезает, то работает, но ncmoe компенсирует разницу.
А вот если MoE не влезает целиком, то добавление второй GPU пока не ясно - дает эффект или нет. Зависит от разных факторов. В моем случае результат усредняется. И нужно учитывать, что 2 GPU это не VRAM1 + VRAM2, общий расход памяти на контекст будет выше, чем на одной карте.
В последнее время не было больших Dense, поэтому старая Llama-3.3-70B-Instruct-UD-Q3_K_XL 34.9 Гб, просто из расчёта чтобы влезло на 2 GPU:
5090 -ngl 81: 10 t/s
4060 -ngl 32: 2.4 t/s
5090 + 4060 auto: 17 t/s
5090 + 4060 -ts 5,1: 23 t/s
Qwen3.5-122B-A10B-UD-Q4_K_XL 74 Гб:
5090: 23 t/s
4060: 12 t/s
5090 + 4060: 18 t/s
Qwen3.5-122B-A10B-UD-IQ2_XXS 35 Гб:
5090: 67 t/s
4060: 19 t/s
5090 + 4060 auto: 64 t/s.
5090 + 4060 -ts 5,1: 79 t/s
Везде 4k контекст и Win10. У меня 4060 подключена через pcie x1, через nvtop можно посмотреть интенсивность обмена, она довольно низкая для MoE:
ncmoe
Для Dense еще менее интенсивна:
dense
Вообще, ширина канала нужна для Tensor Parallelism, который дает ~2х ускорение на двух GPU, где происходит интенсивный обмен тензорами. В llama.cpp используется Pipeline Parallelism - сначала работает первая GPU, потом вторая GPU, между ними обмен только конечных слоев, которые на конкретной GPU, что не особо интенсивно, но и ускорение только за счет дополнительной быстрой памяти, а не одновременной работы двух GPU.
Хорошая поддержка TP в vllm и sglang. В ik_llama есть режим -sm graph, который делает почти тоже что TP. В llama.cpp есть -sm tensor, но он работает пока не очень, хуже чем sm graph.
Кстати, кто-нибудь пользовался deepseek coder? Какие впечатления?
Сильно устарел. Сейчас для кода нужна поддержка агентного режима и вызова инструментов - то есть нужно что-то, что выходило в последние пол года, или даже пару месяцев.
2 недели назад вышла Gemma4, в размере 31B годная, в размере 26B-A4B слабая, но знает много анекдотов. Но модель 31B что это Dense модель, то есть должна целиком влезать в VRAM для нормальной скорости, в то время как MoE модель можно распределить между VRAM и RAM в cmoe режиме (не обычная выгрузка слоев ngl, cmoe работает по другому) и получить хорошую скоростью, этот режим по умолчанию включен в llama.cpp, но его нет в ollama.
Вчера вышла Qwen3.6-35B-A3B, и это хороший уровень для такого размера. Даже квантованная Qwen3.6-35B-A3B-UD-Q2_K_XL работая с opencode или qwen code не теряет контекст на 128к, но лучше, конечно, UD-Q4_K_XL.
Для пример попросил UD-Q2_K_XL сделать реплику Win11, 1 запрос, результат 40к токенов. На 4060 16гб скорость 60 t/s. Всё двигается, шевелится, плавное, анимированное:
DeepSeek-R1-Distill-Qwen-32B - это был экспериментальный файнтюн Qwen2.5-32B, с плохим качеством. Если нужно отключить мышление, то проще взять именно Qwen2.5-32B, где и качество выше и размышление нормально отключается. Но вообще, с тех пор уже вышло 4 поколения новых Qwen моделей, которые и лучше и легче. И удобнее перейти на gguf, там есть и квантование, и размышление отключается 1 строчкой --reasoning off (и ещё несколькими способами).
Если сравнивать именно с Distill-Qwen-32B, то можно посмотреть даже на мелкие Gemma4 E4B или Qwen3.5 4B, которые очень хороши для своего размера.
Вчера вышла качественная Qwen3.6-35B-A3B сделанная на MoE архитектуре, активных параметров всего 3B, модель очень быстрая, а для запуска хватит 4Гб VRAM. Или свежие MoE Gemma4-26B-A4B и Dense Gemma4 31B, которые вышли 2 недели назад.
В актуальных версиях llama.cpp, по умолчанию включен режим fit, чего нет в ollama и lm studio, fit сам определяет оптимальные параметры загрузки модели, и для MoE он включает режим ncmoe, чтобы максимально использовать GPU для ускорения, остальное крутится в RAM. В статье про это тоже есть.
Для qwen3.6 на днях добавили поддержку MTP, можно получить еще больше скорости без потери качества. Для Qwen3.6-35B-A3B ускорение не такое большое, как для Qwen3.6 27B, но оно тоже есть.
Вот тут подробнее: Qwen3.6 27B MTP весит на +0.3 Гб больше, а даёт ускорение в ~2 раза. С 60 t/s до 130 t/s без потерь. Что такое MTP
Если согласны потерять сколько-то в качестве, то можно ускориться раза в 1.5. Попробуйте кванты, которые хорошо работают на CPU, это Q4_0 и Q4_1.
Интересная идея и реализация, а есть какой-то результат для примера?
Неделю назад обучал 0.25B LLM с нуля исключительно на статьях с хабра, датасет IlyaGusev/habr, просто посмотреть, что из этого получится. SFT датасет автоматически построен из датасета хабра, чтобы не было примесей из других источников. Токенизатор обучен тоже только на хабре.
Идея была попробовать обучить 1B, но времени было мало, поэтому на коленке обучил только 0.25B за 3 часа. Первый шаг, это pre-train, который умеет только продолжать то, что ему задать как промпт:
Обучение pre-train было всего на 1 эпохе, поэтому знания плохо усвоены, но что-то аппроксимировано. Модель сама выявила паттерны русского языка, родов, склонений и прочего, хотя логика и знания хромают, общее написание фраз вполне корректное.
Для примера как выглядело начало обучения:
Дальше идет обучение SFT, где pre-train учится шаблону чата и умению отвечать на вопросы и уметь разделять где assistant, а где user. Качество общения зависит от качества SFT датасета, его я сделал автоматически и всего на 1к записей, как старт сойдет, но о проработке речи не идет:
Отвечаю сам себе и уточняю для тех, кто сюда забредёт. Это информация устарела, она больше не актуальна. Проблем с черновыми моделями нет.
Спекулятивное декодирование дает идентичный результат без искажений, я специально проверил исходники llama.cpp, чтобы убедиться, что это действительно так. Особенно это актуально для новых методов MTP, Eagle-3, DFlash, которые дают сильно большее ускорение, чем старый метод через маленькие черновые модели.
Подробнее я расписал в статье: Qwen3.6 27B MTP весит на +0.3 Гб больше, а даёт ускорение в ~2 раза. С 60 t/s до 130 t/s без потерь. Что такое MTP
Так не получится сравнить, сделав несколько прогонов, вы оцениваете сэмплинг, а не модель MTP. Модель детерминирована, а сэмплинг стохастичен и сэмплинг это внешняя от модели сущность. Для сравнения надо либо отключить сэмплинг, либо собрать статистику на большом количестве замеров.
Прогнал 100 замеров без MTP и 100 с MTP на вашем задании. Температура 0.8, top_p 0.85.
Вариант с MTP выдал 64% правильных ответов, а без MTP - 57%. Но не стоит цепляться за сами проценты, в следующем прогоне будет наоборот, серия “доехать” может составлять 10 подряд, а потом 5 подряд будет “прогуляться”, один “доехать” и снова 5 “прогуляться”. Главное тут то, что температура 0.8 добавляет слишком много случайности, а top_p 0.85 креативности (значение по умолчанию в 0.95 добавляет ещё больше креативности).
Температура 0.3, процент правильных ответов стремится к 75%:
Температура 0, процент правильных ответов 100%:
Сэмплинг в данном случае вносит слишком много хаоса, модель хоть и может найти правильный ответ на задачу, но внешняя случайность от сэмплинга уводит модель в сторону. MTP тут не при чём, в статье я как раз смотрел исходники llama.cpp чтобы убедиться, что MTP не добавляет от себя ничего и никак не искажает генерацию.
Код скрипта, для тех кто хочет повторить
Скачать кванты с именем MTP:
unsloth/Qwen3.6-27B-MTP-GGUF
unsloth/Qwen3.6-35B-A3B-MTP-GGUF
И запускать:
.\llama-server -m "Qwen3.6-27B-UD-Q4_K_XL.gguf" --spec-type draft-mtp --spec-draft-n-max 4Указать
--spec-draft-n-maxобязательно, по умолчанию будет сильная просадка скорости.Ещё из новостей про 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.
В llama.cpp завезли поддержку Qwen3.6 MTP. Новые кванты уже создали со слоями MTP. Написал статью что такое MTP, как запустить и какое ускорение получилось. Также проверил исходники llama.cpp, чтобы проверить, качество оригинала сохраняется или искажается:
Qwen3.6 27B MTP весит на +0.3 Гб больше, а даёт ускорение в ~2 раза. С 60 t/s до 130 t/s без потерь. Что такое MTP
Это хороший аргумент, но есть несколько нюансов:
bartowski статические кванты квантует с использованием imatrix, поэтому равномерного квантования там не может быть, неравномерность задается на уровне суперблоков через imatrix.
У него калибровачный датасет 400к токенов, из них только 4к на русском, 1%. И этот 1% не отборных текстов, а каких-то разорванных кусков.
bartowski тоже не квантует равномерно, часть слоев выше, часть ниже.
Поэтому его кванты не чистые статические классические Q4_K_M, а являются динамическими. Хотя тут, смотря что вы имели ввиду под "гарантированно равномерным".
Вообще, мне нравятся кванты от ubergarm, они весят меньше, что важно когда мало VRAM, используют новые алгоритмы квантования, которые сохраняют больше точности, квантование тоже равномерное, без сильных экспериментов, imatrix содержит уже 2% русского текста.
Но кванты ubergarm сложно рекомендовать, так как требуют понимая ik_llama.cpp, которая не имеет автонастроек fit, не дружит с AMD и тому подобное.
Ещё из интересного для квантов, недавно завезли NVFP4 GGUF в llama.cpp. NVFP4 имеет в 2 раза меньший размер микроблоков, что повышает точность суперблоков, и имеет более детальный scale factor чем у MXFP4, когда внутри в рецептах начнут использовать nvfp4 вместо Q4_K, то это, возможно, не плохо повысит качество.
Чистые NVFP4 тоже работают не плохо, уже в GGUF виде можно запускать.
Это хорошо, что он откатил свой рецепт, я перестал качать его кванты когда он начал, пытаясь выиграть в размере, часть ffn квантовать в Q3_K, что ударяло по качеству Q4_K_M. Если он ещё увеличит процент русского текста в своем imatrix с 1% хотя бы до 5%, то его кванты будут совсем хороши.
У вас скорее всего CUDA toolkit стоит. У большинства его нет, поэтому нужно.
Перепроверять это правильно, но вы не перепроверили в статье, а используете как пруф цифры, которые уже не актуальны и вводят в заблуждение.
Вы ссылаетесь на старый пост со старыми квантами. Там деградация была, но это была аноримальная деградация из-за использования mxfp4 для ffn-тензоров вместо K-квантов, аномалию почти сразу заметили и исправили. Было проведено большое исследование с квантами, в итоге кванты переделали, способ квантования UD изменили.
График от комментатора выше, где видно преимущество UD квантов Qwen3.6 - это как раз тесты после исправления. По комплексной метрике KLD, которая точнее чем PPL, исправленные UD обходят остальные кванты, включая Bartowski.
https://www.reddit.com/r/LocalLLaMA/comments/1rlkptk/final_qwen35_unsloth_gguf_update/
Проблема новых моделей и квантов в том, что их исправляют несколько раз после выхода, и не стоит использовать посты 3 месячной как источник для статьи, не уточнив были ли исправления. Например, для Gemma4 было 5 исправлений, включая исправления в самой llama.cpp, и каждый раз надо было перекачивать кванты. Вначале Gemma4 была не пригодна во многих задачах, включая вызовы инструментов и агентов, сейчас это всё исправили, но если ссылаться на первые посты про Gemma4, то “выяснится”, что она “не пригодна” полностью.
Это просто скриншоты агенту, в qwen code в новых версиях можно копи-пастить изображения, либо обычным
@bug7.pngдобавлять в диалог.Кстати, по поводу качества. Пока видел мало обсуждений свежего Qwopus, это Qwen3.5 и 3.6 дообученные на выдаче больших моделей. Есть в разных размерах, включая Qwopus3.5-4B. Сейчас пробую Qwopus3.6-27B-v1-preview, в целом впечатления положительные, как будто бы лучше чем простой Qwen3.6 27B, но нужно больше экспериментов.
Q4_K_M - это не формат от Bartowski, у него не классические статические Q4_K_M кванты, хоть он и называет их так.
Bartowski для всех своих квантов применяет кастомные динамические рецепты, например, ffn он квантует как Q3, хотя должен как Q4, и для всех статических квантов, кроме Q8_0, он применяет свой imatrix, который не должен применяться для классического Q4_K_M.
Другая проблема в том, что в imatrix Bartowski нет или мало русского языка в датасете, и она включает в себя wiki text, поэтому показатели PPL завышены, но на практике квант оказывается сломан и не работает как надо, что трудно понять.
Перплексия постоянно врёт. К PPL нужно относиться с осторожностью, её не стоит сравнивать в лоб, это не мера качества модели, это первичная оценка деградации квантов в рамках одного создающего, чтобы заметить аномальное отклонение. Для оценки качества кванта вместо PPL используют KLD, эта метрика показывает более объективную деградацию кванта.
Недавно показывал как делается KLD замер, и в качестве сравнения как раз брал классику Q4_K_M, которая выступила на уровне UD-Q3_K_XL.
Спорное утверждение. В недавней статье я показывал на что способен квант Qwen3.6-35B-A3B UD-Q2_K_XL, этот квант хуже чем UD-Q4_K_XL, но даже в таком низком значении он не сломан и выполняет работу.
UD-Q2_K_XL сделала реплику Win11 с рабочими окнами, пуском и анимациями:
И в агентном режиме создала проект “Minecraft в браузере”, включая правки через Vision:
Gemma4 только в размере Dense 31B смогла что-то подобное повторить, MoE 26B-A4B не справилась и в программировании она сильно хуже себя показывала.
Подробнее: Выжать больше из локальных LLM. Ollama медленнее llama.cpp в 3 раза. UD_Q4_K_XL лучше чем Q4_K_M, а вес тот же и т.д
Для Gemma4 в очередной раз что-то починили, и надо перекачать gguf файлы. Конкретнее исправили вызовы инструментов в шаблоне чата, из-за чего в агентах эти модели работали плохо. Чтобы не перекачивать gguf, можно скачать исправленный шаблон чата и указывать его при запуске.
--chat-template-file "T:\models\chat_template.jinja"Для Gemma4 и Qwen3.6 есть новости про поддержку MTP, в llama.cpp в статусе черновика уже можно попробовать: https://github.com/ggml-org/llama.cpp/pull/22673
MTP - это отдельный модуль, который обучается вместе с моделью, и позволяет предсказывать 2-3 токена вперед с высокой долей принятия токена. Для MTP и EAGLE3 (альтернатива от nvidia) обычно используется точная верификация, поэтому результат идентичен (в отличии от варианта через draft-модели).
Слои MTP и у Gemma4 и Qwen3.6 встроены в модель, но в стандартных gguf они вырезались, так как не было поддержки. Их можно было использовать в vLLM, что ускоряло в 2-3 раза. Для Gemma4 их дополнительно выложили отдельно.
https://blog.google/innovation-and-ai/technology/developers-tools/multi-token-prediction-gemma-4/
И вышли новые Dense модели:
Mistral-Medium-3.5-128B
granite-4.1 (3B, 8B, 30B, vision-4b)
Тут как-то до сих пор нет консенсуса. Если это Dense - то однозначно работает, если MoE за счет дополнительных GPU целиком влезает, то работает, но ncmoe компенсирует разницу.
А вот если MoE не влезает целиком, то добавление второй GPU пока не ясно - дает эффект или нет. Зависит от разных факторов. В моем случае результат усредняется. И нужно учитывать, что 2 GPU это не VRAM1 + VRAM2, общий расход памяти на контекст будет выше, чем на одной карте.
В последнее время не было больших Dense, поэтому старая Llama-3.3-70B-Instruct-UD-Q3_K_XL 34.9 Гб, просто из расчёта чтобы влезло на 2 GPU:
5090 -ngl 81: 10 t/s
4060 -ngl 32: 2.4 t/s
5090 + 4060 auto: 17 t/s
5090 + 4060 -ts 5,1: 23 t/s
Qwen3.5-122B-A10B-UD-Q4_K_XL 74 Гб:
5090: 23 t/s
4060: 12 t/s
5090 + 4060: 18 t/s
Qwen3.5-122B-A10B-UD-IQ2_XXS 35 Гб:
5090: 67 t/s
4060: 19 t/s
5090 + 4060 auto: 64 t/s.
5090 + 4060 -ts 5,1: 79 t/s
Везде 4k контекст и Win10. У меня 4060 подключена через pcie x1, через nvtop можно посмотреть интенсивность обмена, она довольно низкая для MoE:
Для Dense еще менее интенсивна:
Вообще, ширина канала нужна для Tensor Parallelism, который дает ~2х ускорение на двух GPU, где происходит интенсивный обмен тензорами. В llama.cpp используется Pipeline Parallelism - сначала работает первая GPU, потом вторая GPU, между ними обмен только конечных слоев, которые на конкретной GPU, что не особо интенсивно, но и ускорение только за счет дополнительной быстрой памяти, а не одновременной работы двух GPU.
Хорошая поддержка TP в vllm и sglang. В ik_llama есть режим -sm graph, который делает почти тоже что TP. В llama.cpp есть -sm tensor, но он работает пока не очень, хуже чем sm graph.
Выжать больше из локальных LLM. Ollama медленнее llama.cpp в 3 раза. UD_Q4_K_XL лучше чем Q4_K_M, а вес тот же и т.д
Сильно устарел. Сейчас для кода нужна поддержка агентного режима и вызова инструментов - то есть нужно что-то, что выходило в последние пол года, или даже пару месяцев.
2 недели назад вышла Gemma4, в размере 31B годная, в размере 26B-A4B слабая, но знает много анекдотов. Но модель 31B что это Dense модель, то есть должна целиком влезать в VRAM для нормальной скорости, в то время как MoE модель можно распределить между VRAM и RAM в cmoe режиме (не обычная выгрузка слоев ngl, cmoe работает по другому) и получить хорошую скоростью, этот режим по умолчанию включен в llama.cpp, но его нет в ollama.
Вчера вышла Qwen3.6-35B-A3B, и это хороший уровень для такого размера. Даже квантованная Qwen3.6-35B-A3B-UD-Q2_K_XL работая с opencode или qwen code не теряет контекст на 128к, но лучше, конечно, UD-Q4_K_XL.
Для пример попросил UD-Q2_K_XL сделать реплику Win11, 1 запрос, результат 40к токенов. На 4060 16гб скорость 60 t/s. Всё двигается, шевелится, плавное, анимированное:
DeepSeek-R1-Distill-Qwen-32B - это был экспериментальный файнтюн Qwen2.5-32B, с плохим качеством. Если нужно отключить мышление, то проще взять именно Qwen2.5-32B, где и качество выше и размышление нормально отключается. Но вообще, с тех пор уже вышло 4 поколения новых Qwen моделей, которые и лучше и легче. И удобнее перейти на gguf, там есть и квантование, и размышление отключается 1 строчкой
--reasoning off(и ещё несколькими способами).Если сравнивать именно с Distill-Qwen-32B, то можно посмотреть даже на мелкие Gemma4 E4B или Qwen3.5 4B, которые очень хороши для своего размера.
Вчера вышла качественная Qwen3.6-35B-A3B сделанная на MoE архитектуре, активных параметров всего 3B, модель очень быстрая, а для запуска хватит 4Гб VRAM. Или свежие MoE Gemma4-26B-A4B и Dense Gemma4 31B, которые вышли 2 недели назад.
Подробнее: Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
Нужен режим работы cmoe (не просто выгрузка слоев ngl). Вот тут подробнее: Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
В актуальных версиях llama.cpp, по умолчанию включен режим fit, чего нет в ollama и lm studio, fit сам определяет оптимальные параметры загрузки модели, и для MoE он включает режим ncmoe, чтобы максимально использовать GPU для ускорения, остальное крутится в RAM. В статье про это тоже есть.