Готовых бенчмарков, которые сравнивают Qwen3.8-27B в квантовании IQ3_XXS и Qwen3.6-35B-A3B в Q4_K_M, в открытых источниках нет. Пользователь, запустивший обсуждение на r/LocalLLaMA, искал такие тесты довольно долго и не нашёл ни одного (ветка с вопросом).
Поэтому честный ответ звучит так: однозначного победителя в этой паре нет. Выбор определяет то, какая из трёх переменных упрётся первой - объём VRAM, требования к точности формата или нужная скорость генерации. Ниже разбираем каждую переменную и собираем из них практические сценарии.
Коротко для тех, кто читает по диагонали. При 8-12 ГБ VRAM из этой пары реалистично запускается только IQ3_XXS на 27B, и брать её стоит с оговорками по tool use. При 24 ГБ и больше Q4_K_M на MoE-модели даёт более высокое качество квантования и обычно более быструю генерацию, но все 35B придётся держать в памяти.
Почему готового сравнения этих моделей нет
Стандартные лидерборды оценивают модели в исходных весах и на железе с большим запасом памяти. Конкретные GGUF-сборки туда почти не попадают: результат зависел бы от битности, версии бэкенда и настроек сэмплинга, а не от самой модели.
Вторая причина в постановке задачи. Здесь смешаны две переменные сразу: битность квантования (примерно 3 бита против 4) и архитектура (плотная сеть против MoE). Когда в эксперименте меняются два фактора, вывод «модель A лучше» ничего не объясняет.
Третья причина прозаична. Такие тесты собирают энтузиасты на своём железе, и живут они недолго: выходят новые сборки, обновляется llama.cpp, меняются квантизации. Единого реестра, где сравниваются все комбинации «модель плюс квант плюс железо», не существует.
Что делать вместо поиска готовых цифр? Мерить на своих задачах. Методика честного замера - отдельная тема: полезно разделять prefill (обработку промпта) и decode (генерацию), фиксировать длину контекста и не сравнивать разные настройки сэмплинга. Пример такого подхода на Qwen 3.8 27B разобран в материале про запуск модели на одной RTX 5090.
Чем отличаются IQ3_XXS и Q4_K_M: квантование без магии
Обе схемы пришли из llama.cpp и записываются прямо в имени GGUF-файла. Буквы и цифры там значат конкретные вещи: цифра указывает на целевое число бит на вес, суффикс - на вариант смешивания точности внутри одного файла.
Что такое IQ3_XXS и когда он оправдан
IQ - семейство i-quants (importance quantization). Это схема со сверхнизкой битностью, введённая в llama.cpp в 2024 году и нацеленная на среднюю точность порядка 2-3 бита на вес и ниже (например, IQ1_S - около 1,56 бита на вес). Веса сжимаются не в простую равномерную сетку, а в наборы кодбуков, подобранных с учётом важности отдельных весов.
В практических рекомендациях IQ3_XXS позиционируется как вариант для очень малого объёма VRAM (4-6 ГБ) и как минимально адекватное качество для крупных моделей: при том же размере он даёт заметно лучшее качество, чем Q2_K. Точных замеров потерь именно для Qwen3.8-27B в IQ3_XXS в доступных источниках нет, поэтому здесь уместна осторожность, а не красивые проценты.
Отсюда два следствия. Файл весов заметно меньше, чем у 4-битных вариантов, а ошибка квантования выше. Оправдан IQ3_XXS в одном случае: когда модель иначе не влезает в доступную память. Второй сценарий - черновая работа, где важен общий смысл и скорость: суммаризация, черновики, разбор логов, первичная классификация.
Для задач со строгим форматом на выходе экономия памяти оборачивается дополнительными ретраями.
Q4_K_M: золотая середина или нет
Q4_K_M - это k-квантование со смешанной точностью. Буква K означает k-quants, M - смешанный (medium) набор: разные подмодули Transformer-блока получают разную битность. В типовой раскладке проекции Q/K/V идут в Q6_K (около 6,56 бита на вес), а O-проекция и FFN Gate/Up/Down - в Q4_K (около 4,5 бита на вес), что даёт среднюю точность примерно 4,84 бита на вес.
Качество здесь обычно предсказуемее, чем у трёхбитных схем: по оценкам, perplexity Q4_K_M держится в пределах примерно 0,1-0,15 от FP16 и заметно лучше наивного Q4_0, который может терять 0,5+ пункта perplexity. Платить приходится размером. Для MoE-модели это особенно чувствительно: у Qwen3.6-35B-A3B в памяти должны лежать все эксперты, хотя на каждый токен срабатывает лишь их часть. 35B в четырёх битах - крупный файл, и малое число активных параметров объём весов не уменьшает.
Полезно держать в голове весь спектр компромиссов. В каталоге YouRunAI для Qwen3.8-27B рядом стоят варианты Q4 (ниже память), Q8 (выше качество) и FP16 (исходные веса) (каталог моделей). Это иллюстрация логики «больше бит - больше памяти», а не сравнение с IQ3_XXS.
Практический вывод по разделу: IQ3_XXS покупает память за счёт точности, Q4_K_M покупает точность за счёт памяти. В коде и tool use цена ошибки выше, чем в обычном чате: промах в одном символе ломает вызов функции целиком. Пограничные случаи между низким квантованием и более высоким разобраны в отдельном сравнении IQ1_S против Q4.
Плотная 27B против MoE 35B-A3B: архитектура решает
Qwen3.8-27B - плотная модель. Каждый токен проходит через все 27B параметров, никакой маршрутизации нет. Qwen3.6-35B-A3B построена как разреженная смесь экспертов (sparse Mixture-of-Experts): по официальной карточке модели - 35B параметров всего и 3B активируемых на токен. Роутер выбирает нескольких экспертов под конкретный токен, остальные простаивают.
Почему MoE с 3B активных параметров может быть быстрее
Скорость генерации на локальном железе упирается в пропускную способность памяти. На каждый токен нужно прочитать веса, участвующие в вычислении. Активные параметры влияют на вычисления, но не уменьшают занимаемую память: полные веса FP16/BF16 всё равно занимают около 70 ГБ на диске. Оценка трафика на токен для плотной 27B в IQ3_XXS и для MoE с 3B активных в Q4_K_M в доступных источниках не приводится, поэтому конкретные цифры здесь не называем - корректнее говорить о порядке: MoE читает из памяти существенно меньше байт на токен, чем плотная модель, и decode у неё обычно быстрее.
Prefill тоже дешевле: обработка промпта считает только активные параметры. Для длинного контекста в десятки тысяч токенов это заметно.
Обратная сторона медали: все эксперты должны быть доступны. Экономия на вычислениях не уменьшает объём файла, поэтому по VRAM MoE-модель на 35B тяжелее, чем плотная на 27B в трёхбитном квантовании, несмотря на скромные 3B активных.
Когда плотная модель выигрывает в качестве
Плотная сеть тратит на каждый токен все параметры, поэтому её поведение меньше зависит от того, как сработал роутер. На длинных многошаговых задачах (сборка кода с зависимостями, цепочка вызовов инструментов) это даёт более предсказуемый результат.
У MoE маршрутизация добавляет вариативность: разные токены одного ответа могут обрабатываться разными экспертами. Ошибки квантования накладываются на это, и жёсткий формат страдает первым.
Подчеркну: это рассуждение об архитектуре, а не результат теста. Прямых замеров, которые подтверждали бы или опровергали его для этой пары моделей, в доступных источниках нет.
Сколько VRAM нужно: считаем без иллюзий
Первую прикидку по весам можно сделать в уме. Размер файла примерно равен числу параметров, умноженному на биты на вес и поделённому на 8.
| Модель и квант | Целевые биты на вес | Оценка размера весов |
|---|---|---|
| Qwen3.8-27B IQ3_XXS | ~3,4 | оценка не подтверждена |
| Qwen3.6-35B-A3B Q4_K_M | ~4,8 | оценка не подтверждена |
Важная оговорка: точные размеры файлов этих сборок в доступных источниках не подтверждены. В карточке Qwen3.8-27B-UD-IQ3_XXS.gguf на Hugging Face значение размера не указано, а для Qwen3.6-35B-A3B в одном из разборов упоминается порядка 24 ГБ для Ollama-тега, что не совпадает с ходовыми прикидками в 19-22 ГиБ. Поэтому таблица выше - только порядок величины, а не размер конкретного файла: служебные тензоры, метаданные и версия схемы двигают цифру на несколько процентов. Реальный размер стоит смотреть в карточке GGUF перед скачиванием. KV-кэш в этих оценках не учтён.
KV-кэш и длина контекста: скрытый пожиратель VRAM
KV-кэш хранит состояния внимания по всем предыдущим токенам, поэтому растёт линейно с длиной контекста. Формула для оценки: KV cache (bytes) = batch_size × context_length × 2 × num_layers × num_kv_heads × head_dim × bytes_per_param. При батче в один запрос множитель batch_size равен единице, и формула сводится к привычному виду «2 × число слоёв × число kv-голов × размер головы × длина контекста × байт на элемент».
Оговорка: формула предполагает обычное полное внимание и одинаковую структуру слоёв. Для гибридных архитектур с чередованием типов внимания (к ним относится и Qwen 3.6) она даёт лишь грубую верхнюю оценку.
Для веб-скрапинга и многошаговых агентов кэш часто съедает больше памяти, чем разница между Q4_K_M и IQ3_XXS. Спасает квантование самого кэша: переход с FP16 (2 байта на значение) на 8-битный формат q8_0 вдвое уменьшает размер кэша при минимальной потере качества. В llama.cpp это задаётся флагами --cache-type-k и --cache-type-v, например: llama-server -m model.gguf -ngl --cache-type-k q8_0 --cache-type-v q8_0. Плюс трезвая оценка нужной длины: 32k вместо 128k - это вчетверо меньше памяти под кэш. Как считать общий бюджет «веса плюс кэш плюс запас на фрагментацию», разобрано на примере Qwen3.8-27B в true Q4_K_M на 16 ГБ.
CPU offload: когда он спасает, а когда убивает скорость
Если веса не влезают, часть слоёв можно выгрузить в оперативную память. Модель запустится, но decode резко замедлится: пропускная способность DDR5 в разы ниже, чем у видеопамяти. Для интерактивного кодинга и tool use это обычно неприемлемо, для пакетного скрапинга ночью - нормально.
Проверить свои шансы заранее помогают калькуляторы и каталоги. YouRunAI персонализирует оценки моделей под конкретную машину (GPU и объём памяти) и отдельно учитывает загрузку CPU при offload (страница моделей).
Что критично для веб-скрапинга, кода и tool use
Автор исходного вопроса назвал эти три задачи одинаково важными: веб-скрапинг, программирование и работу с инструментами (ветка с вопросом). Требования у них разные, и одна модель может выигрывать в одной задаче и проигрывать в другой.
Веб-скрапинг: контекст и структурированный вывод
Типичная задача выглядит так: скормить модели выгрузку HTML или текст и получить JSON по схеме. Критичны три вещи: длина контекста, если страниц или документов несколько, стабильность следования инструкциям и способность не терять схему к концу ответа.
Что снижает риски независимо от модели: резать страницы на фрагменты, требовать минимальный JSON и валидировать его кодом, а не глазами. Длинный контекст нужен реже, чем кажется, и это экономит память под KV-кэш.
Программирование: длина контекста и точность
Для кода важна способность удерживать зависимости: файл, соседние модули, сигнатуры функций. Здесь длина контекста работает на результат напрямую. Вторая переменная - точность синтаксиса и API: ошибка в имени метода стоит дороже, чем шероховатый текст в чате.
Низкобитное квантование бьёт по обоим пунктам: модель чаще путает редкие токены (имена, сигнатуры) и теряет нить в длинном файле. Если код - основная задача, разумнее взять модель меньшего размера в более высоком квантовании, чем большую в трёх битах. Сравнение двух восьмибитных сборок для локального кодинга (DeepSeek-V4-Flash-Vision Q8 против Qwen3.8-Flash-Next Q8) показывает, что tokens/s сам по себе не предсказывает время до рабочего патча.
Tool use: вызов функций и стабильность формата
Самый требовательный сценарий. Модель должна выдавать вызов функции в точном формате (JSON или XML по схеме инструмента), не добавлять пояснений перед ним и корректно продолжать после получения результата. Одна лишняя кавычка - и цепочка рвётся на середине.
Что помогает на практике: низкая температура, явная схема инструментов в системном промпте, валидация аргументов перед вызовом и ограниченное число шагов. Квантование здесь играет плохую шутку: чем ниже битность, тем выше шанс, что модель «поплывёт» именно в синтаксисе. Для многошаговых агентов плотная модель в умеренном квантовании обычно надёжнее агрессивно сжатой, а MoE с 3B активных параметров добавляет к этому вариативность роутинга. Это архитектурное предположение, и подтверждённых тестов под него в источниках нет.
Как выбрать под своё железо и задачу: практические критерии
Сценарий 1: ограниченная VRAM (8-12 ГБ)
Из этих двух вариантов влезает только Qwen3.8-27B IQ3_XXS, и то при умеренном контексте и квантованном KV-кэше. Готовьтесь к возможным сбоям формата в tool use и держите ретраи с валидацией аргументов.
Альтернатива, которую стоит проверить: модель меньшего размера в более высоком квантовании. 9B-модель в Q8 или Q6 часто выдаёт более стабильный JSON, чем 27B в трёх битах, хотя знаний у неё меньше. Обмен понятный: меньше параметров, выше точность представления весов.
Сценарий 2: 24 ГБ VRAM и больше
Q4_K_M на 35B-A3B помещается в память с запасом на KV-кэш и работает быстрее на генерации за счёт малого числа активных параметров. Если же задача - жёсткий формат вызовов инструментов, имеет смысл сравнить MoE с плотной моделью в Q4 или Q5: плотная даёт меньше вариативности, пусть и ценой скорости.
Сценарий 3: приоритет скорости
MoE с ~3B активных параметров на каждом токене читает из памяти меньше байт, чем плотная 27B, поэтому decode обычно быстрее. Оговорка: если веса MoE лежат частично в RAM, а не в VRAM, преимущество исчезает.
Это ориентиры, а не догма. У обеих моделей качество зависит от версии бэкенда, типа KV-кэша и настроек сэмплинга, поэтому проверять стоит на своих задачах: 10-20 реальных кейсов на модель дают больше, чем чужие сводки.
Что делать, если ни одна не подходит: альтернативы
Зацикливаться на двух сборках не стоит. В каталоге YouRunAI есть, например, MiMo V2.6 Distill Qwen 9B: 9B-модель от Xiaomi MiMo, полученная дообучением Qwen3.5-9B на сгенерированных данных и нацеленная на кодинг, агентные задачи и кибербезопасность (каталог моделей). Там же отдельно отмечены задачи «Build a local tool-calling assistant» и «Extract structured data with a local model». На 12 ГБ VRAM такой вариант может оказаться практичнее, чем 27B в трёх битах.
Второй вопрос: хватит ли модели меньшего размера в принципе. Где малые модели упираются в число параметров, а где в VRAM, разбирается в отдельном материале про пределы возможностей малых моделей.
Итог: какую модель выбрать
Единого победителя нет, потому что нет бенчмарков, а условия у всех разные. Рабочее правило выглядит так:
- 8-12 ГБ VRAM: Qwen3.8-27B IQ3_XXS, с оговорками по формату вызовов инструментов.
- 24 ГБ и больше, приоритет скорости и общих знаний: Qwen3.6-35B-A3B Q4_K_M.
- Tool use и код с жёсткими требованиями: плотная модель в Q4, Q5 или Q8, даже если параметров у неё меньше.
- Длинный контекст: сначала посчитайте KV-кэш, потом выбирайте квант.
Дальше остаётся замер. Соберите 10-20 своих кейсов (страница для парсинга, функция в реальном проекте, вызов инструмента), прогоните их на обеих сборках с одинаковыми настройками и посчитайте не только скорость, но и долю успешных вызовов без правок. Такой прогон на своём железе полезнее любых чужих цифр: у вашей задачи свой профиль контекста, формата и допустимой задержки.