Qwen3.6 35B A3B на RX 6600 XT: реальные 300 t/s prefill и разгром официальных бенчмарков

Реальные цифры: что показал тест на RX 6600 XT + Ryzen 7 5700X

Пользователь Reddit запустил Qwen3.6 35B A3B в квантизации Q4_K_XL на связке RX 6600 XT + Ryzen 7 5700X и получил 270-300 t/s на prefill и ~30 t/s на decode. Это в 10 раз выше цифр, которые публикуют официальные бенчмарк-сайты. Результат ставит под сомнение общепринятые методики тестирования и открывает модель для комфортной локальной работы на среднебюджетном железе.

Prefill - это этап обработки входного промпта. Модель за один проход проглатывает весь контекст и заполняет KV-кэш. Высокий prefill критичен для сценариев с длинными системными промптами, RAG-поиском и обработкой документов. 300 t/s означает, что промпт на 3000 токенов обработается за 10 секунд.

Decode - это этап генерации ответа. Модель предсказывает по одному токену за шаг, и здесь важна каждая миллисекунда. 30 t/s decode даёт скорость чтения, сопоставимую с быстрым скроллингом текста. Для чат-бота или ассистента этого хватает с запасом. Для голосового взаимодействия с целевыми 1000+ t/s - нет.

Сравним с другими тестами на схожем железе. На RTX 3090 с тернарной квантизацией Qwen3.6 27B выдаёт 60 токенов в секунду. На Strix Halo под 32 параллельными запросами та же 35B A3B модель показывает 14.2 токен/с. RX 6600 XT с 30 t/s decode на одном потоке выглядит достойно, учитывая её ценовую категорию.

Почему официальные бенчмарки врут: разбор методик и ошибок

Расхождение в 10 раз между реальной производительностью и данными бенчмарк-сайтов объясняется тремя факторами: настройками по умолчанию, отсутствием оптимизаций под конкретное железо и некорректным распределением слоёв на AMD GPU. Стандартный бенчмарк запускается с флагами, которые не учитывают особенности ROCm-экосистемы. Результат - цифры, вводящие пользователей в заблуждение и заставляющие отказываться от работоспособных конфигураций.

Квантизация Q4_K_XL добавляет ещё один слой непонимания. Это компромиссный формат: 4-битное квантование весов с расширенным набором параметров, дающее качество, близкое к Q5_K_M, при меньшем размере модели. Модель Qwen3.6 35B A3B в Q4_K_XL занимает около 20 ГБ - это влезает в 24 ГБ VRAM на RX 6600 XT с запасом под KV-кэш. Бенчмарк-сайты часто тестируют на Q4_0 или Q8_0, где результаты ожидаемо хуже из-за неоптимального использования пропускной способности памяти.

Ловушка ручного распределения слоёв на ROCm

Главный технический нюанс успешного запуска - отказ от ручного указания числа слоёв через --n-gpu-layers. Пользователи, привыкшие к CUDA-экосистеме, часто вручную выставляют этот параметр, пытаясь контролировать размещение модели между GPU и CPU. На ROCm это ломает внутренние оптимизации llama.cpp.

При автоматическом распределении llama.cpp анализирует доступную VRAM, размер модели и пропускную способность шины PCIe. Для MoE-моделей с разделяемыми и экспертными слоями алгоритм учитывает паттерны доступа к памяти и минимизирует пересылки данных между GPU и CPU. Ручное вмешательство отключает эту логику. Результат - падение prefill в 3-5 раз и decode до 5-8 t/s.

Пример рабочего конфига:

./llama-cli \
  -m Qwen3.6-35B-A3B-Q4_K_XL.gguf \
  -ngl 99 \
  -c 8192 \
  -fa 1 \
  -ctk q8_0 \
  -ctv q8_0

Параметр -ngl 99 указывает llama.cpp загрузить на GPU столько слоёв, сколько влезет, но не вмешиваться в логику распределения. Flash Attention (-fa 1) снижает использование памяти KV-кэшем и ускоряет prefill на длинных контекстах. Квантование кэша в q8_0 экономит VRAM без заметной потери качества.

Как повторить результат: пошаговая настройка llama.cpp под ROCm

Для воспроизведения теста на RX 6600 XT + Ryzen 7 5700X потребуется три компонента: ROCm 6.1 или новее, llama.cpp с поддержкой HIP и модель Qwen3.6 35B A3B в квантизации Q4_K_XL. Порядок действий:

1. Установите ROCm по официальной инструкции AMD для вашего дистрибутива. Проверьте установку командой rocminfo.
2. Соберите llama.cpp с поддержкой HIP: make GGML_HIPBLAS=1 -j$(nproc). Альтернативный вариант - cmake -B build -DGGML_HIPBLAS=ON.
3. Скачайте модель Qwen3.6 35B A3B в формате GGUF с квантизацией Q4_K_XL. Размер файла - около 20 ГБ.
4. Запустите инференс с параметрами выше, не указывая --n-gpu-layers вручную.

Ключевой момент: не пытайтесь форсировать размещение модели. Автоматический режим в llama.cpp на ROCm с 24 ГБ VRAM корректно размещает все активные блоки Qwen3.6 35B A3B на GPU. Модель использует около 3B параметров на токен благодаря архитектуре Mixture of Experts, и полный набор экспертов умещается в VRAM RX 6600 XT.

Выбор квантизации: почему Q4_K_XL - золотая середина

Q4_K_XL занимает промежуточное положение между Q4_K_M и Q5_K_M по качеству, но ближе к Q4_K_M по размеру. На RX 6600 XT с пропускной способностью памяти 256 ГБ/с выбор квантизации напрямую влияет на decode-скорость: чем меньше модель, тем быстрее чтение весов из VRAM.

Сравнение для Qwen3.6 35B A3B:

Q4_K_XL даёт падение скорости всего на 5-10% относительно Q4_0 при заметном выигрыше в качестве. Q5_K_M уже не влезает в 24 ГБ с комфортным KV-кэшем на 8192 токена - начинается свопинг на CPU, и decode падает до 5-8 t/s. Для практического использования Q4_K_XL - оптимальный выбор.

Целевые 1000+ t/s для голосового взаимодействия: где мы сейчас и что делать

Голосовое взаимодействие требует decode-скорости выше 1000 t/s. Причина - задержка. Человек воспринимает паузу более 200-300 мс как неестественную. Генерация ответа из 200 токенов на 30 t/s занимает 6.7 секунды - это режим «печатной машинки», неприемлемый для голосового ассистента. На 1000 t/s тот же ответ генерируется за 0.2 секунды - задержка незаметна.

Текущие 30 t/s decode на RX 6600 XT закрывают сценарии текстовых чат-ботов, локальных ассистентов и автономной генерации кода. Для RAG-систем с поиском по документам скорость достаточна: prefill в 300 t/s обрабатывает контекст за секунды, а decode на 30 t/s выдаёт ответ быстрее, чем пользователь читает.

Разрыв между 30 t/s и 1000 t/s - это разница в пропускной способности памяти. RX 6600 XT имеет 256 ГБ/с. Для 1000 t/s decode на MoE-модели с 3B активных параметров в 4-битном квантовании требуется около 1.5 ТБ/с. Это уровень RTX 4090 (1 ТБ/с) или multi-GPU конфигураций.

Минимальный апгрейд для voice-режима: что покупать и какой прирост ждать

Переход на GPU с большей пропускной способностью памяти даёт линейный прирост decode-скорости для MoE-моделей, ограниченных bandwidth. Расчёт для Qwen3.6 35B A3B Q4_K_XL (3B активных параметров, ~1.5 ГБ данных на токен):

Даже RTX 4090 не дотягивает до целевых 1000+ t/s на одной карте. Для голосового взаимодействия потребуется либо модель с меньшим числом активных параметров (например, 1B вместо 3B), либо тензорный параллелизм на 4-8 GPU. Опыт запуска крупных MoE-моделей показывает, что multi-GPU конфигурации на AMD требуют тщательного тюнинга ROCm и не всегда дают линейный прирост.

Qwen3.6 35B A3B: архитектура MoE и почему она летает на слабом железе

Qwen3.6 35B A3B построена на архитектуре Mixture of Experts. Полный набор параметров - 35 миллиардов, но на каждом токене активируется только подмножество экспертов общим объёмом 3 миллиарда параметров. Маршрутизатор выбирает 2-4 эксперта из пула, и только их веса загружаются для вычислений.

Сравнение с dense-моделями: Llama 3 8B требует загрузки всех 8 миллиардов параметров на каждый токен. При 4-битном квантовании это 4 ГБ данных, которые нужно прочитать из VRAM. Qwen3.6 35B A3B читает только 1.5 ГБ - в 2.7 раза меньше. Отсюда и преимущество в скорости на железе с ограниченной пропускной способностью памяти.

Плата за эффективность - общий объём модели. 35B параметров требуют 20 ГБ VRAM даже в Q4_K_XL, хотя активны только 3B. Это ограничивает применение на GPU с 16 ГБ и менее. RX 6600 XT с 24 ГБ проходит по границе: модель помещается, но запас под KV-кэш составляет всего 4 ГБ - хватает на контекст в 8192 токенов с квантованным кэшем.

Архитектура MoE также накладывает ограничения на батчинг. При параллельных запросах активируются разные эксперты, и эффективная пропускная способность памяти делится между запросами. Тесты на Strix Halo с 32 одновременными запросами показали падение decode до 14.2 t/s на поток - суммарная производительность остаётся высокой, но индивидуальная скорость страдает. Для одного пользователя это не проблема. Для серверных сценариев - критично.

Выводы: стоит ли связываться с Qwen3.6 35B A3B на AMD

Qwen3.6 35B A3B на RX 6600 XT даёт 30 t/s decode - комфортную скорость для текстовых чат-ботов, локальных ассистентов и генерации кода. Официальные бенчмарки, показывающие 3-5 t/s, стоит игнорировать: они получены на неоптимальных настройках и не отражают реальной производительности.

Для голосового взаимодействия с целевыми 1000+ t/s текущая конфигурация не подходит. Требуется либо переход на multi-GPU сборку, либо ожидание моделей с 1B активных параметров. Опыт оптимизации инференса на CPU показывает, что даже на слабом железе грамотный тюнинг параметров запуска даёт кратный прирост скорости.

Модель отлично подходит для экспериментов и локального использования благодаря архитектуре MoE. 35B общих параметров обеспечивают качество ответов на уровне моделей класса 30B+, а 3B активных параметров позволяют запускать инференс на среднебюджетных GPU. Выбор бэкенда для инференса также влияет на итоговую производительность, но для одиночных запросов llama.cpp на ROCm показывает результаты, близкие к предельным для данного железа.

Практическая рекомендация: если у вас уже есть RX 6600 XT или аналогичная карта с 24 ГБ VRAM, Qwen3.6 35B A3B в Q4_K_XL - один из лучших вариантов для локального инференса. Настройка занимает 15 минут: установка ROCm, сборка llama.cpp с HIP, загрузка модели и запуск без ручного распределения слоёв. Результат - производительный локальный ассистент без облачных подписок и задержек сети.

Подписаться на канал