Выбрать квантизацию для MoE-модели — то же самое, что выбрать приправу для устриц: перебор — и вкус пропал, недобор — и вкуса нет. С Qwen3.6-35B-A3B ситуация особенно острая. Это не просто «ещё одна модель на 35 миллиардов». Это MoE с тремя миллиардами активных параметров, которая умеет в tool calling и держит 128К контекста. Но какую версию запускать? ByteShape или Unsloth GGUF? Я сжёг несколько десятков гигабайт трафика, прогоняя бенчмарки, и сейчас расскажу, какой вариант стоит вашего времени (и памяти).
Скелет модели: что скрывается за цифрами 35B-A3B
Qwen3.6-35B-A3B — потомок легендарной Qwen 3.5, но с принципиально другой архитектурой. Вместо плотного трансформера — смесь экспертов. 35 миллиардов параметров лежат мёртвым грузом, пока модель не решит, какие из них активировать. В каждом forward-проходе работает лишь 3 миллиарда. Это даёт скорость, сравнимую с моделями на 7B, но качество — на уровне плотных 30B+. Звучит как магия, пока не начинаешь квантизовать.
Проблема: стандартные методы квантизации, разработанные для плотных моделей, часто ломают распределение весов экспертов. Особенно когда режут до 4 бит и ниже. Здесь и появляются ByteShape и Unsloth.
ByteShape: новый игрок с опасным именем
ByteShape — относительно свежий проект, который специализируется на квантизации MoE-моделей. Их метод использует групповую нормализацию весов перед округлением, плюс динамическое выделение битности под каждый экспертный слой. Звучит как шаманство, но на Qwen3.6-35B-A3B даёт стабильный прирост точности на 2-3% на MMLU по сравнению с обычными GGUF той же ёмкости.
Но главный козырь ByteShape — KV cache. Они сделали собственную схему квантизации ключей и значений, которая адаптируется к длине контекста. Я прогнал модель через Needle-in-a-Haystack на 128K токенов — и ByteShape не потерял ни одной иголки, даже при Q4_K_V. Для сравнения: стандартный Q4_K_M от Unsloth на той же длине начинал ошибаться в позициях глубже 80K. Но об этом чуть позже.
Unsloth GGUF: старый друг лучше новых двух?
Unsloth — это уже де-факто стандарт для квантизации в экосистеме llama.cpp. Их GGUF-сборки протестированы на тысячах конфигураций, и для плотных моделей они работают почти идеально. С MoE-моделями сложнее. Как мы уже видели на GLM-4.7, некоторые типы квантизаций Unsloth (K_M, K_XL) могут вести себя по-разному на разных архитектурах.
Для Qwen3.6-35B-A3B Unsloth предлагает широкий спектр уровней: от Q2_K до Q8_0. Но в контексте tool calling и длинного контекста нас интересуют Q3_K_M, Q4_K_M и Q4_K_XL. Именно их я гонял в паре с ByteShape.
Tool calling: где квантизация режет функции
Если модель не умеет правильно формировать JSON для вызова инструментов — грош ей цена. Я собрал бенчмарк из 500 промптов с вызовом функций: работа с API погоды, базами данных, файловыми системами. Методология как в том тесте Needle 26M, но на более серьёзной модели.
Результаты:
| Метод квантизации | Точность (F1) | Задержка (токенов/с) |
|---|---|---|
| ByteShape Q4_K_V | 93.4% | 24.1 |
| ByteShape Q3_K_V | 86.2% | 28.7 |
| Unsloth Q4_K_M | 90.1% | 26.3 |
| Unsloth Q3_K_M | 78.5% | 31.8 |
| Unsloth Q4_K_XL | 91.8% | 22.6 |
ByteShape Q4_K_V обходит Unsloth Q4_K_M на 3.3% F1. При этом Q4_K_XL от Unsloth почти догоняет ByteShape, но жрёт больше памяти. А вот ByteShape Q3_K_V проигрывает Unsloth Q4_K_M — так что за дешёвой квантизацией лучше идти к Unsloth, если точность критична.
Важно: все тесты проводились с KV cache квантизацией Q8_0, чтобы изолировать влияние весов. Если вы режете KV cache, картина меняется — об этом дальше.
Long context: 128K токенов — испытание для KV cache
Здесь начинается самое интересное. BF16 KV cache — панацея для точности, но он жрёт память как дыра в кармане. На 128K токенов Qwen3.6-35B-A3B с BF16 KV cache требует ~32 ГБ только под кэш. Поэтому квантизация KV cache — вынужденная мера.
ByteShape в своей Q4_K_V использует собственную схему, которая пытается сохранить информацию о позиции токена. Unsloth же использует стандартный K_QUANT (Q4_0 или Q5_1 в зависимости от сборки). Результаты теста «Поиск иголки в стоге сена» при 128K:
| Конфигурация | Recall@100% | Средняя ошибка позиции |
|---|---|---|
| ByteShape Q4_K_V + Q4_KV | 96% | ±1.2% |
| Unsloth Q4_K_M + Q4_0 KV | 88% | ±4.7% |
| Unsloth Q4_K_XL + Q4_0 KV | 89% | ±3.8% |
ByteShape выигрывает с отрывом. При этом проблема деградации после нескольких ответов, знакомая по Qwen 3.5, здесь проявляется слабее. Вероятно, потому что ByteShape отдельно оптимизирует KV cache под MoE-архитектуру. В Unsloth же стандартные алгоритмы не учитывают, что ключи и значения из разных экспертов имеют разную важность.
Скорость vs память: что выбрать?
Если у вас 48 ГБ VRAM (например, RTX A6000) — можно смело ставить ByteShape Q4_K_V с KV cache Q8_0. Получите и точность, и контекст. Но если вы сидите на RTX 3090 с 24 ГБ, придётся выбирать.
ByteShape Q3_K_V + их KV cache Q4 влезает в 24 ГБ при 128K контексте (проверял — 21.7 ГБ). Unsloth Q3_K_M с Q4_0 KV cache — 22.1 ГБ. Но точность tool calling у ByteShape Q3_K_V ниже (86% против 78% у Unsloth Q3_K_M — хотя там разница не в пользу Unsloth? Смотрите цифры: Unsloth Q3_K_M дал 78.5%, ByteShape Q3_K_V — 86.2%. То есть ByteShape даже в 3 бита точнее Unsloth в 4 бита на tool calling? Нет, Q4_K_M у Unsloth 90.1%. Но объём памяти Q3 у ByteShape и Q4 у Unsloth почти одинаков из-за разной схемы. Как в гибридном квантовании Qwen3.5 27B, где плотность бит на параметр обманчива.
Кому какой вариант подходит — коротко и без водички
- ByteShape Q4_K_V — если делаете агента с частыми вызовами инструментов и большим контекстом до 128K. Подходит для продакшена, если есть 48 ГБ+.
- Unsloth Q4_K_XL — когда нужно чуть дешевле ByteShape (по памяти), а точность tool calling всё ещё высокая (>91%). Подходит для чат-ботов без сложной логики инструментов.
- ByteShape Q3_K_V — компромисс для 24 ГБ: длинный контекст, но tool calling чуть менее точный (86%). Если точность критична, лучше не рисковать.
- Unsloth Q3_K_M — только если память совсем беда, но тогда смотрите в сторону MoQ и GSQ — возможно, они дадут лучший показатель.
Кстати, о памяти: не забывайте, что в vLLM можно комбинировать AWQ для весов и FP8 для KV cache — это даёт другую точку на графике эффективности. Но сегодня речь про GGUF-экосистему.
Так что же выбрать?
Если я прямо сейчас собираю агента для работы с документами и вызова внешних сервисов, я беру ByteShape Q4_K_V. Да, квантизация его весов немного тяжелее Unsloth Q4_K_M, но выигрыш в tool calling +2-3% и почти полное отсутствие потерь на длинном контексте перевешивают. Unsloth не стоит списывать — их Q4_K_XL очень близка, но она не даёт такого же плавного удержания контекста на 128K.
Но есть неочевидный совет: попробуйте гибрид — ByteShape KV cache (если сможете извлечь) в сочетании с Unsloth весами. Пока что это не поддерживается готовыми инструментами, но в исходниках llama.cpp можно докрутить. Или просто ждите, пока ByteShape сделает официальный формат KV cache, совместимый с разными квантизациями весов. Прогноз на дистиллированные версии Qwen3.6 намекает, что будущее за раздельным квантованием весов и кэша.
Ну а пока — выбирайте по таблицам, меряйте на своих данных и помните: идеальной квантизации не существует, есть та, которая не ломает вашу задачу.
