Что вообще произошло: короткий ответ на главный вопрос
Пользователь под ником JurBank сравнил три квантизации Qwen 3.8 27B на видеокарте R9700 и опубликовал результаты в r/LocalLLaMA. В тесте участвовали Qwen3.8-27B-UD-Q6_K_L.gguf, Swift-Qwen3.8-27B-Q6_K.gguf и Swift-1.5-Qwen3.8-27B-MXFP4-A-outQ6_K.gguf. Математику проверяли через gsm8k, генерацию кода через humaneval, а настройку обоих тестов выполнил агент Pi внутри одного Docker-контейнера. Исходный пост с результатами.
Автор заранее выстроил три ожидания. UD-Q6_K_L должен был взять точность и оказаться самым медленным, Swift-Q6_K - встать посередине по точности и скорости, а MXFP4 - проиграть в точности и выиграть в скорости. Ни одно из трёх предположений не подтвердилось в полном виде.
Фактический расклад вышел таким: MXFP4 занял первое место в математике и последнее в коде, UD-Q6_K_L показал худший результат в математике, а Swift-Q6_K оказался самым медленным. Автор не скрывает удивления и прямо спрашивает сообщество, как одна квантизация может быть первой в математике и последней в коде.
Сразу оговорка по формату статьи: ниже разбор чужого теста с его условиями и ограничениями. Мы не запускали эти квантизации и не измеряли их. Всё, что есть в тексте, опирается на опубликованные данные автора, а там нет ни полных наборов задач, ни многократных прогонов, ни замеров скорости в токенах в секунду.
Сетап теста: модели, серверы, железо и бенчмарки
Три файла и три разных способа запуска:
- Qwen3.8-27B-UD-Q6_K_L.gguf - через Llama.cpp;
- Swift-Qwen3.8-27B-Q6_K.gguf - через Llama.cpp;
- Swift-1.5-Qwen3.8-27B-MXFP4-A-outQ6_K.gguf - через сервер whirl.
Железо одно: видеокарта R9700. Тесты gsm8k и humaneval запускались в Docker, настройкой занимался агент Pi. Автор не приводит объём VRAM, версии драйверов, длину контекста, параметры сэмплинга и число прогонов на задачу. Без этих деталей воспроизвести тест один в один не получится, можно только повторить общую схему.
Почему разные серверы (Llama.cpp и whirl) - это важно
Llama.cpp и whirl - два разных движка инференса. Один и тот же GGUF-файл они могут обрабатывать по-разному: иначе раскладывать слои, иначе работать с KV-кэшем, батчингом и сэмплированием. Для двух Q6-вариантов использовался Llama.cpp, для MXFP4 - whirl. Значит, часть разницы в результатах может объясняться и форматом квантизации, и сервером под ней.
Это не отменяет тест целиком. Если бы разница между MXFP4 и Q6_K была крошечной, версия "дело в сервере" звучала бы правдоподобно. Здесь же разброс по местам (первый в математике, последний в коде) слишком заметный, чтобы списать его на один фактор. Держать в голове эту деталь стоит, категорично обвинять whirl или Llama.cpp - нет.
Что измеряют gsm8k и humaneval
gsm8k - набор школьных математических задач. Модель должна построить цепочку рассуждений и выдать конкретное число. Проверка идёт по финальному ответу, а не по красоте рассуждения.
humaneval устроен жёстче. Модель генерирует короткую функцию по текстовому описанию, и результат прогоняется через тесты. Ошибка в имени переменной, пропущенная скобка или необработанный краевой случай - задача провалена полностью.
Два бенчмарка нагружают модель по-разному: длинные цепочки размышлений в первом случае и компактная генерация с точным синтаксисом во втором. Расхождение между математикой и кодом из-за этого перестаёт выглядеть как ошибка теста и становится нормальным поводом для разбора.
Результаты против гипотез: где ожидания сломались
| Гипотеза автора | Что показал тест |
|---|---|
| UD-Q6_K_L - лучший по точности и самый медленный | Худший результат в математике |
| Swift-Q6_K - второй по точности и скорости, компромисс | Самый медленный |
| MXFP4 - худший по точности и самый быстрый | Первый в математике и последний в коде |
Сломалось всё три пункта. Гипотеза "больше бит - выше точность" не сработала: UD-Q6_K_L, который по идее должен был дать лучший результат, оказался аутсайдером в математике. Гипотеза "меньше бит - быстрее" тоже не сработала: самым медленным стал Swift-Q6_K, а не 4-битный MXFP4.
В посте нет полных таблиц точности по каждой задаче и нет нескольких прогонов. Есть итоговый расклад по местам. Поэтому корректная формулировка звучит так: это сигнал, что привычная логика выбора квантизации не работает автоматически, а не доказательство превосходства одного формата над другим.
Схожие истории уже случались в тестах Qwen 3.8 27B на другом железе. На RTX 3060 12 ГБ сравнение GSQ-RCO-IQ3-XXS и ByteShape IQ3-XXS дало разный расход токенов при похожем результате, а на 16 ГБ VRAM Qwen3.8 27B IQ3_XXS против Bonsai Ternary PQ2 обе модели прошли проверки, но разошлись в скорости в три раза.
Почему MXFP4 выиграл в математике, но провалился в коде
Чем MXFP4 отличается от Q6_K на уровне формата
Q6_K - 6-битная схема квантизации из семейства K-quants, которое используется в GGUF и Llama.cpp. Каждый вес хранится с 6 битами плюс служебные масштабы, которые считаются по блокам весов.
MXFP4 - 4-битный формат с блочным масштабированием (microscaling). Битов на вес меньше, но общий масштаб на блок позволяет сохранять относительные различия внутри группы весов. За счёт этого 4-битный формат иногда удерживает нужную информацию на тех слоях, где 6-битная схема с другим распределением ошибки её теряет.
Вывод из этого простой: "меньше бит" не равно "хуже точность" автоматически. Схема распределения ошибки по слоям значит не меньше, чем среднее число битов на вес. В файле Swift-1.5-Qwen3.8-27B-MXFP4-A-outQ6_K выходной слой оставлен в Q6_K, то есть финальное распределение токенов считает более точный формат. Для задач с одним правильным числовым ответом это может давать заметный эффект.
Почему код прощает меньше, чем математика
humaneval проверяет функцию на исполнение, а не на сходство с эталоном. Даже при сохранённом "смысле" решения одна деталь синтаксиса или пропущенный краевой случай ломает весь ответ. Квантизация, которая теряет именно мелкие детали, здесь наказывается сразу.
В gsm8k ситуация мягче. Модель ведёт рассуждение, а проверка смотрит на финальное число. Небольшие отклонения в формулировках по пути часто не мешают дойти до правильного ответа. Поэтому формат, который сохраняет общую логику, но теряет мелкую точность, может выигрывать в математике и проигрывать в коде.
Отсюда список гипотез, которые объясняют расхождение. Все они гипотезы, ни одна не доказана:
- MXFP4 по-разному влияет на длинные цепочки рассуждений и на задачи с точным синтаксисом и API.
- Выходной слой Q6_K в MXFP4-варианте частично компенсирует потери на финальном распределении токенов, что помогает там, где нужен один правильный ответ.
- Разные серверы (whirl для MXFP4, Llama.cpp для Q6) могли разойтись в сэмплинге и обработке контекста.
- humaneval чувствителен к строгому соответствию сигнатур и краевым случаям, и квантизация ломает именно такие детали.
- Малая выборка и один прогон могли дать случайный выброс в любую сторону.
Почему UD-Q6_K_L проиграл в математике, а Swift-Q6_K оказался самым медленным
Больше бит не гарантирует лучшую точность на конкретном бенчмарке. Разные схемы квантизации распределяют ошибку по слоям неодинаково, и UD-Q6_K_L мог потерять именно на тех слоях, которые важны для пошаговых рассуждений. Приставка UD означает доработанную схему квантизации от Unsloth, но и она не застрахована от такого перекоса.
Со скоростью та же логика. Swift-Q6_K оказался самым медленным, хотя по размеру не должен был проигрывать MXFP4. Причины могут лежать в том, как Llama.cpp обрабатывает слои, в эффективности загрузки весов на R9700, в настройках сервера или в длине генерируемых цепочек рассуждений. Автор не приводит замеров в токенах в секунду, поэтому вывод о скорости - его наблюдение по времени прогона, а не измеренная метрика.
Полезный вывод из этого блока: и "больше бит - точнее", и "меньше бит - быстрее" в этом тесте не сработали. Обе мантры требуют проверки на своём железе и своих задачах, а не веры на слово.
Насколько можно доверять этим результатам
Ограничения честно перечислены самим автором, и их стоит держать в голове:
- неполные наборы тестов, а не полные gsm8k и humaneval;
- однократные прогоны без повторов;
- разные серверы для разных квантизаций (Llama.cpp и whirl);
- одно железо (R9700) и неизвестные настройки сэмплинга;
- нет замеров скорости в цифрах и нет статистики по разбросу;
- нет распределения ошибок по типам задач.
Автор прямо пишет, что для точных выводов пришлось бы гонять полные наборы и делать несколько прогонов, но на его оборудовании это заняло бы слишком много времени. В исходном посте он и не заявляет окончательных выводов, а просит сообщество помочь с объяснением.
Практический смысл из этого такой: результаты полезны как сигнал и повод копать дальше, но строить на них выбор квантизации для продакшена рано. Разброс мест по одной задаче может перевернуться на другом прогоне.
Минимальный чек-лист корректного теста квантизаций
Если хотите проверить квантизации сами, соберите схему так:
- один и тот же сервер для всех квантизаций, иначе сравнение нечистое;
- полные наборы gsm8k и humaneval, а не выборка из нескольких задач;
- минимум три прогона на модель, чтобы увидеть разброс;
- фиксированные seed и температура, одинаковый контекст и батчинг;
- логирование токенов в секунду, времени и точности по каждой задаче;
- общий Docker-контейнер и агент для запуска тестов, так проще повторить сетап.
Docker и агент вроде Pi упрощают воспроизводимость, но они не заменяют контроль переменных. Разные серверы, разные параметры сэмплинга и разный контекст сведут сравнение к случайным числам.
Что это значит на практике: какую квантизацию Qwen 3.8 27B выбрать
Под математику и рассуждения
В тесте JurBank MXFP4 показал лучший результат в gsm8k. Универсально лучшим его это не делает. Если ваша задача - рассуждения с точным финальным ответом, формат стоит попробовать на своих примерах. Сравните с Q6-вариантом на одном сервере и посмотрите, повторяется ли перевес. Похожий эффект от режимов размышлений уже разбирался на тесте Qwen 3.8 на 16 ГБ VRAM с thinking effort, где рост усилий почти не добавлял решённых задач.
Под генерацию кода
В humaneval MXFP4 оказался последним, а Q6-варианты выступили лучше. Кто именно из двух Q6-файлов сильнее, тест не показывает: данных для такого вывода мало. Если пишете код, ориентируйтесь на Q6 и проверяйте на своём стеке. Отдельно стоит смотреть на модели, заточенные под экономию токенов: Swift-1.5-Qwen3.8-Flash-Next в тесте на Aider прошёл чуть выше базовой модели, потратив около 40% токенов и времени.
Под ограниченную VRAM и скорость
MXFP4 как 4-битный формат компактнее Q6_K, и при нехватке видеопамяти это плюс. Утверждать, что MXFP4 быстрее, тест JurBank не даёт: замеров в токенах в секунду нет. Swift-Q6_K в этом прогоне оказался самым медленным, так что полагаться на общие ожидания по скорости не стоит. Если ресурсы ограничены, полезно посмотреть на другие практические сравнения, например на запуск Qwen3.5 0.8B на CPU с кастомным движком, где разница в prefill достигала 2,9x.
Общая рамка выбора без категоричных советов: под математику и рассуждения попробуйте MXFP4, под код держите Q6-варианты, при нехватке VRAM компактный 4-битный формат логичен, а по скорости нужен собственный замер. Единственный надёжный способ - прогнать свой сценарий через пару кандидатов на одном сервере и сравнить результат.
Открытый вопрос: что сообщество может проверить дальше
Невыясненным остаётся главное: почему MXFP4 первый в математике и последний в коде. Дополнительные вопросы касаются вклада выходного слоя Q6_K, влияния разных серверов и поведения форматов квантизации на разных типах задач.
Проверяемые шаги выглядят так. Прогнать MXFP4 и Q6_K через один и тот же сервер и сравнить результат. Взять полные наборы gsm8k и humaneval вместо выборки. Сделать по три прогона на модель с фиксированным seed. Посмотреть не только на итоговую точность, но и на то, какие именно задачи и как часто проваливаются. Так можно отделить эффект формата от эффекта сервера, настроек сэмплинга и случайности.
Пока таких данных нет, вопрос JurBank остаётся открытым, а его тест - полезным сигналом, что привычные правила выбора квантизации работают не всегда.