Перейти к содержанию
Публикация AiManual

Спекулятивное декодирование Qwen3.8-27B на 16 ГБ: опыт запуска на RX 9070 XT с ~60 ток/с

Пользователь запустил Qwen3.8-27B на RX 9070 XT с 16 ГБ VRAM и получил около 60 ток/с. Разбираем связку с draft-моделью, KV-кэш k 8_0/v 4_0, контекст 128k и нюа

Коротко

Что будет в материале

  1. 01

    Как работает спекулятивное декодирование с отдельной draft-моделью

  2. 02

    Настройка KV-кэша и контекста 128k на 16 ГБ

  3. 03

    GTT, переполнение памяти и когда спекулятивное декодирование замедляет

  4. 04

    Насколько результат 60 ток/с воспроизводим: ограничения и другие тесты

Qwen3.8-27B укладывается в 16 ГБ видеопамяти Radeon RX 9070 XT, если взять агрессивный квант весов, сжать KV-кэш и добавить отдельную draft-модель для спекулятивного декодирования. Пользователь, поделившийся конфигурацией в обсуждении на Hugging Face, сообщает о средней скорости около 60 токенов в секунду при контексте 128k. Основная модель: ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF в варианте IQ3_XXS. Draft-модель: HermiHg/Qwen3.8-27B-DFlash2-Q2_K_S-MIX-GGUF.

Оговорка, без которой цифра 60 ток/с вводит в заблуждение: это опыт одного человека на одной системе, а не воспроизводимый бенчмарк. В конфигурации фигурируют DDR5 и PCIe 5, и автор отдельно подчёркивает, что спекулятивное декодирование чувствительно к переполнению GTT. На другой плате, с более медленной памятью или другим драйвером, итог может отличаться в разы. Точные параметры запуска, версии драйверов и ПО в описании не приведены.

Из чего собрана схема:

КомпонентТипРоль
ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF, IQ3_XXSОсновная модельГенерирует текст, занимает основную часть VRAM
HermiHg/Qwen3.8-27B-DFlash2-Q2_K_S-MIX-GGUFDraft-модельПредлагает токены-кандидаты, которые проверяет основная модель
KV-кэш k 8_0, v 4_0Кэш ключей и значенийПозволяет держать контекст 128k в остатке памяти
RX 9070 XT, 16 ГБGPUВсё перечисленное размещается в 16 ГБ

IQ3_XXS это квант примерно на 3 бита на вес с улучшенной калибровкой, то есть осознанный размен точности на размер. Именно такой размен открывает дорогу к 27B-модели на 16 ГБ: чем крупнее модель, тем заметнее выигрыш от агрессивного сжатия по сравнению с запуском модели меньшего размера в высоком кванте. Как соотносятся разные варианты квантования и где начинаются компромиссы, разобрано в материале про Qwen3.8-27B в true Q4_K_M на RTX 5080 с 16 ГБ.

Как работает спекулятивное декодирование с отдельной draft-моделью

Схема простая по идее. Маленькая быстрая модель предсказывает несколько токенов подряд, крупная проверяет всю пачку за один проход и оставляет те токены, с которыми согласна. Отклонённые отбрасываются, цикл повторяется. Когда draft-модель угадывает часто, основная модель реже прогоняет полный forward pass на каждый токен, и общая скорость растёт.

В разобранной конфигурации роль предсказателя играет HermiHg/Qwen3.8-27B-DFlash2-Q2_K_S-MIX-GGUF. Квант Q2_K_S означает сильное сжатие: draft-модель должна занимать мало VRAM, иначе смысл схемы теряется. Чем больше памяти она съест, тем меньше останется на KV-кэш основной модели, а при 16 ГБ каждый гигабайт на счету.

Главное ограничение метода: выигрыш зависит от доли принятых токенов. Если draft-модель часто ошибается, вы платите за её работу и не получаете ускорения. Если она плохо согласована с основной моделью по словарю и стилю, доля принятых кандидатов падает. Отсюда практический вывод: draft-модель имеет смысл брать из того же семейства, что и основную, как в этом кейсе.

Почему draft-модель, а не встроенный MTP

MTP (Multi-Token Prediction) встроен в саму модель: дополнительные головы предсказывают несколько токенов вперёд, и отдельный файл скачивать не нужно. Пользователь сравнивал оба варианта и отмечает, что встроенный MTP кратно увеличивает потребление VRAM, а скорость при этом ниже, чем со связкой основная модель плюс отдельная draft-модель. Причина понятна: MTP-головы живут внутри модели, и на 16 ГБ их вес и рабочие буферы отъедают память, которой и так не хватает.

Отдельная draft-модель даёт контроль над бюджетом. Её можно заменить на более лёгкую, убрать целиком и вернуться к обычному декодированию. Минус тоже есть: draft-модель требует собственного контекста и кэша, а это дополнительная нагрузка на память и лишние переключения между двумя моделями. На 16 ГБ такой размен обычно выгоден, на карте с 24-32 ГБ встроенный MTP может оказаться удобнее. Как связаны между собой батчи, MTP и квантование KV-кэша, с цифрами и таблицами показано в разборе настроек llama.cpp для Qwen 3.6 27B на RTX 5090.

Настройка KV-кэша и контекста 128k на 16 ГБ

Контекст 128k (131 072 токена) сам по себе стоит дорого. Кэш ключей и значений растёт линейно с длиной контекста, и в FP16 он один занял бы больше памяти, чем весит квантованная модель. Решение из этого кейса: квантовать KV-кэш раздельно, k в 8_0 и v в 4_0.

Логика такого сочетания: ключи чувствительнее к сжатию, их оставляют в 8 битах, а значения уходят в 4 бита. Перевод V-кэша с 8 на 4 бита примерно вдвое уменьшает его вклад в расход памяти. В сумме это освобождает несколько гигабайт, которых как раз хватает, чтобы держать 128k и одновременно разместить draft-модель.

В llama.cpp за типы кэша отвечают параметры --cache-type-k и --cache-type-v, длина контекста задаётся через -c. Точные значения остальных флагов автор не привёл, поэтому команду придётся собирать самостоятельно, ориентируясь на свою память и нужную длину контекста. Похожие конфигурации с готовыми командами и замерами разобраны в статье про запуск Qwen 3.8 27B на 24 ГБ VRAM.

Про качество: сжатие V до 4 бит заметно, но не катастрофично, и в этом кейсе автор с ним работал. Если ответы начнут деградировать, первым делом стоит вернуть V в 8_0 и посмотреть, сколько контекста после этого останется. Обмен всегда один и тот же: биты кэша против длины контекста и скорости генерации.

GTT, переполнение памяти и когда спекулятивное декодирование замедляет

GTT (Graphics Translation Table) на AMD это таблица трансляции, через которую GPU адресует системную память. Когда основная модель, KV-кэш и draft-модель перестают помещаться в 16 ГБ VRAM, часть данных уходит туда, и GPU читает их через PCIe вместо локальной памяти. Пропускная способность отличается на порядок, и именно здесь схема начинает разваливаться.

Наблюдение из кейса: спекулятивное декодирование делает систему чувствительнее к переполнению GTT. Причина в том, что работают две модели вместо одной, обе активно обращаются к своей памяти, и при выходе за пределы VRAM обмен по шине бьёт по обеим сразу. Практический вывод автора: если конфигурация упёрлась в лимит памяти, отключение спекулятивного декодирования может дать более высокую скорость, чем его использование. Оговорка, которую он сам делает: это верно по крайней мере для его системы с DDR5 и PCIe 5.

  • Следите за фактическим расходом VRAM и GTT, а не за ожидаемым по расчётам.
  • Проверяйте оба режима на одном промпте и при одной длине контекста.
  • Уменьшайте контекст или сильнее сжимайте KV-кэш, если заметили просадку.

Для карт AMD на Linux к этому добавляется зависимость от версии ROCm и выбранного бэкенда. Сопоставимый опыт на Radeon с разбором флагов и диагностикой памяти описан в материале про Qwen 3.6 35B A3B на Radeon RX 7600 с ROCm 7.

Насколько результат 60 ток/с воспроизводим: ограничения и другие тесты

60 токенов в секунду получено на конкретной сборке: RX 9070 XT, DDR5, PCIe 5, IQ3_XXS, контекст 128k, k 8_0 и v 4_0. Любой из этих пунктов может сдвинуть результат. У RX 9070 XT на разных системах отличается поведение драйвера, а от версии ROCm или бэкенда зависит, насколько эффективно загружаются вычислительные блоки.

В том же обсуждении на Hugging Face упоминается более обширное тестирование той же draft-модели на другой видеокарте. Конкретные цифры оттуда в исходном описании не приводятся, поэтому опираться на них как на ориентир нельзя. Это повод открыть обсуждение и посмотреть данные самостоятельно, уже понимая, какие параметры сравнивать.

Факторы, которые сдвигают скорость сильнее всего:

  • длина контекста: рост с 8k до 128k увеличивает время prefill и расход памяти;
  • доля принятых draft-токенов: от неё напрямую зависит выигрыш от спекулятивного декодирования;
  • пропускная способность памяти GPU: draft-модель упирается в неё постоянно;
  • драйвер, бэкенд и версия llama.cpp;
  • режим размещения: сколько слоёв ушло на GPU, сколько осталось на CPU.

Практические выводы: кому подходит схема и с чего начать

Схема подходит владельцам 16 ГБ GPU, готовым подбирать кванты и экспериментировать. Она не подходит тем, кому нужна предсказуемость: точные параметры запуска, версии драйверов и ПО в описанном кейсе не приведены, а скорость зависит от памяти и шины.

  1. Скачайте основную модель ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF в варианте IQ3_XXS.
  2. Скачайте draft-модель HermiHg/Qwen3.8-27B-DFlash2-Q2_K_S-MIX-GGUF.
  3. Задайте KV-кэш k 8_0 и v 4_0, длину контекста 128k.
  4. Замерьте скорость со спекулятивным декодированием и без него на одинаковых промптах.
  5. Следите за VRAM и GTT. При переполнении сначала отключайте draft-модель, потом уменьшайте контекст.

Если нужно поднять локальный стек целиком, а не разово запустить модель, полезен опыт сборки на Debian через llama.cpp и llama-swap: быстрый локальный стек для Qwen 3.8 27B. Там же разобраны диагностика проблем с VRAM и переключение между моделями, что для связки основная модель плюс draft-модель экономит время на ручных запусках.

Начинайте с одного замера на своём железе: контекст 8k, фиксированный промпт, сначала без draft-модели, потом с ней. Разница в токенах в секунду и в занятой памяти сразу покажет, есть ли смысл двигаться дальше к 128k и квантованию V-кэша до 4 бит.

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