Ключевые результаты: скорость Muse Glimmer 30B на AMD v620
Запуск 30-миллиардной модели на двух картах AMD v620 с 24 ГБ VRAM - задача, которая ещё недавно требовала либо серверных GPU, либо серьёзных компромиссов. Практические тесты показали: связка из двух v620 с тензорным сплитом и DFlash-спекулятивным декодированием выдает до 658 ток/с на обработке промпта и до 36 ток/с на генерации. Это уровень, достаточный для интерактивной работы и пакетной обработки.
Сводка по конфигурациям:
| Конфигурация | Обработка промпта (60k контекст) | Генерация | Уровень принятия DFlash |
|---|---|---|---|
| Одиночная v620, Q6 | ~210 ток/с | ~18 ток/с | — |
| Две v620, Tensor Split Q6/Q8 | ~380 ток/с | ~22 ток/с | — |
| Две v620, Tensor Split Q6/Q8 + DFlash | ~658 ток/с | ~36 ток/с | 55-74% |
Цифры получены на GGUF-квантованных версиях модели. DFlash дает прирост генерации в 1.6 раза при идентичном качестве вывода - это не эвристика, а строгий механизм проверки каждого токена целевой моделью. Уровень принятия 55-74% означает, что из каждых 100 предложенных черновиком токенов целевая модель подтверждает 55-74. Остальные отбрасываются, но параллельная генерация все равно дает чистое ускорение.
Архитектура Muse Glimmer 30B: почему модель влезает в 24 ГБ
Muse Glimmer 30B от Meta Superintelligence Labs - это dense-модель с 52 слоями, размерностью скрытого состояния 6656 и механизмом внимания GQA (32 query heads / 2 key-value heads). Полная BF16-версия занимает 29,78 млрд параметров и требует около 60 ГБ видеопамяти - очевидно, на v620 с 24 ГБ она не помещается.
Решение - квантование GGUF и архитектурные оптимизации. Sliding-window attention ограничивает окно контекста фиксированным размером, снижая квадратичный рост потребления памяти при увеличении длины промпта. GQA с соотношением 32:2 радикально уменьшает размер KV-кэша по сравнению с полным multi-head attention. Эти два механизма в комбинации с квантованием позволяют уместить 30B-модель в 24 ГБ без критической потери точности.
Квантование GGUF: что нужно знать перед запуском
Выбор между Q6 и Q8 - это компромисс между качеством и требованиями к VRAM. На практике:
- Q6_K: размер модели ~24 ГБ, помещается на одну v620. Потери качества относительно BF16 минимальны, большинство бенчмарков показывают разницу в пределах 1-2%.
- Q8_0: размер ~32 ГБ, требует тензорного сплита на две карты. Качество практически идентично BF16 для генеративных задач, разница обнаруживается только на специализированных тестах.
Для DFlash-спекулятивного декодирования используется отдельный ассистент BF16 на 2,56 млрд параметров. Это легковесная модель, которая работает в общем контексте с целевой и предлагает черновые токены. Её размер незначителен относительно основной модели, поэтому дополнительная нагрузка на VRAM минимальна.
Пошаговый запуск: llama-server с Tensor Split и DFlash
Все команды используют llama-server из актуальной сборки llama.cpp. Модель загружается в формате GGUF, доступном на Hugging Face. Перед запуском убедитесь, что ROCm-драйверы корректно определяют обе карты v620 и доступен порт 8080.
Конфигурация 1: одиночный GPU, Q6, без спекулятивного декодирования
Базовый сценарий для одной карты. Модель Q6_K загружается целиком в VRAM, контекст ограничен 16k токенов из-за размера KV-кэша.
llama-server \
-m muse-glimmer-30b-Q6_K.gguf \
-ngl 999 \
-fa on \
--jinja \
--host 0.0.0.0 \
--port 8080 \
-c 16384 \
--temp 1.0 \
--top-p 0.95 \
--top-k 64Скорость генерации - около 18 ток/с. Обработка промпта на 60k контексте - 210 ток/с. Этого достаточно для одиночных запросов и тестирования, но для продакшена с параллельными обращениями узким местом становится пропускная способность памяти одной карты.
Конфигурация 2: тензорный сплит Q6/Q8 на двух v620
Распределение модели между двумя GPU через параметр --tensor-split. Первая карта получает Q6-квантованные слои, вторая - Q8. Суммарно модель занимает больше VRAM, но качество выше, а контекст можно расширить до 32k.
llama-server \
-m muse-glimmer-30b-Q8_0.gguf \
-ngl 999 \
--tensor-split 12,12 \
-fa on \
--jinja \
--host 0.0.0.0 \
--port 8080 \
-c 32768 \
--temp 1.0 \
--top-p 0.95 \
--top-k 64Параметр --tensor-split 12,12 распределяет 24 ГБ на первую карту и 24 ГБ на вторую. Фактическое распределение слоев llama.cpp вычисляет автоматически, ориентируясь на эти лимиты. Скорость генерации вырастает до 22 ток/с, обработка промпта - до 380 ток/с. Прирост по промпту объясняется тем, что compute-bound операции распараллеливаются между двумя GPU.
Конфигурация 3: добавляем DFlash-спекулятивное декодирование
DFlash работает только в llama.cpp и использует общий контекст с целевой моделью. Ассистент-модель генерирует черновые токены, целевая модель проверяет их параллельно. Ключевые параметры:
llama-server \
-m muse-glimmer-30b-Q8_0.gguf \
-md muse-glimmer-30b-assistant-BF16.gguf \
-ngl 999 \
-ngld 999 \
--tensor-split 12,12 \
--spec-type draft-dflash \
--spec-draft-n-max 15 \
-fa on \
--jinja \
--host 0.0.0.0 \
--port 8080 \
-c 32768 \
--temp 1.0 \
--top-p 0.95 \
--top-k 64--spec-type draft-dflash активирует механизм DFlash. --spec-draft-n-max 15 задает максимальное число черновых токенов за шаг - эмпирически оптимальное значение для этой модели. -ngld 999 загружает все слои драфт-модели на GPU. Результат: 36 ток/с на генерации и 658 ток/с на обработке промпта. Ускорение генерации - 1.6x относительно конфигурации без DFlash, качество вывода идентично.
Бенчмарки: детальный разбор скорости и задержки
Производительность инференса на v620 зависит от трех факторов: длины контекста, распределения слоев между GPU и включения спекулятивного декодирования. Замеры проводились на синтетических промптах с контролируемой длиной, генерация - до 512 токенов.
Влияние длины контекста на скорость обработки промпта
Sliding-window attention ограничивает рост вычислительной сложности при увеличении контекста, но не устраняет его полностью. На конфигурации с тензорным сплитом и DFlash:
| Длина контекста | Скорость обработки промпта | Время до первого токена |
|---|---|---|
| 1k | ~1200 ток/с | ~0.8 с |
| 10k | ~890 ток/с | ~11.2 с |
| 30k | ~720 ток/с | ~41.7 с |
| 60k | ~658 ток/с | ~91.2 с |
Падение скорости от 1k до 60k составляет около 45%. Основная причина - рост KV-кэша и увеличение числа операций attention, даже с учетом sliding-window. Для задач с длинными документами (юридический анализ, суммаризация больших текстов) задержка первого токена в 91 секунду может быть приемлемой, если запросы идут в пакетном режиме.
DFlash: почему уровень принятия токенов не 100%, но это выгодно
Механизм DFlash устроен так: легковесная драфт-модель генерирует до 15 токенов за шаг, целевая модель проверяет всю последовательность параллельно. Если токен не совпадает с тем, что сгенерировала бы целевая модель, он отбрасывается вместе со всеми последующими. Поэтому уровень принятия 55-74% не означает, что 26-45% токенов неверны - это означает, что в среднем из 15 предложенных токенов принимаются 8-11, а остальные отбрасываются.
Почему это выгодно: проверка 15 токенов целевой моделью занимает примерно столько же времени, сколько генерация одного токена без спекуляции. При уровне принятия 55% чистая скорость = 1 / (1 - 0.55 + 0.55/15) ≈ 1.6x. Это совпадает с практическими замерами. На задачах с высокой предсказуемостью (код, переводы) уровень принятия ближе к 74%, на креативном письме - к 55%.
Сравнение с Qwen: когда Muse выигрывает за счет эффективности
На бенчмарке GLIMMER Muse Glimmer 30B уступает Qwen 3.6-35B в абсолютном качестве на 3-5%. Разница неравномерна по категориям: в генерации кода отставание 1-2%, в креативном письме 4%, в сложных рассуждениях до 7%. Но есть встречный фактор - эффективность по токенам. Первые тесты Muse на GLIMMER показали, что модель тратит на 45-55% меньше токенов на выполнение идентичных задач.
Экономика токенов: Muse vs Qwen на практике
Возьмем гипотетический сценарий: пакет из 1000 запросов на суммаризацию документов. Qwen генерирует в среднем 400 токенов на ответ, Muse - 220 токенов при сопоставимом качестве. На локальном железе с генерацией 36 ток/с Muse обработает пакет за 1000 × 220 / 36 ≈ 6111 секунд. Qwen на аналогичной конфигурации - за 1000 × 400 / 22 ≈ 18182 секунды (без учета спекулятивного декодирования, которое для Qwen может дать другой прирост). Разница - почти в 3 раза по времени выполнения.
Для API-сценариев с оплатой за токены экономия прямолинейна: 45-55% меньше токенов = 45-55% меньше затрат. При этом качество на задачах суммаризации и кода отличается незначительно. Muse - прагматичный выбор, когда бюджет важнее абсолютного максимума метрик.
Ограничения и подводные камни
Перед развертыванием учтите несколько моментов, выявленных в процессе тестирования:
- Максимальный контекст на одиночной v620 с Q6 - 16k токенов. При попытке установить 32k llama-server падает с ошибкой нехватки VRAM. Тензорный сплит на две карты снимает это ограничение, позволяя держать 32k без свопинга.
- Аблатерированная версия модели не показывает отказов на вредные запросы (0/450 в тестах). Это удобно для исследовательских задач, но создает риски безопасности при публичном развертывании. Если вы открываете API наружу, используйте стандартную версию с обученным отказом.
- DFlash работает только в llama.cpp и только с моделями, для которых есть совместимый ассистент. При миграции на vLLM или другой инференс-движок вы теряете спекулятивное декодирование. Опыт запуска DeepSeek-V4-Flash на B300 показал, что DSpark (аналог DFlash для DeepSeek) деградирует в насыщенном батче - для Muse аналогичная проблема вероятна при параллельных запросах.
- Цифры 658 ток/с и 36 ток/с получены на синтетических тестах с контролируемой нагрузкой. Реальная производительность зависит от паттерна использования: пиковые значения достигаются при пакетной обработке, интерактивные сценарии с одиночными запросами показывают цифры ближе к нижней границе диапазона.
Выводы: какую конфигурацию выбрать для ваших задач
Практические рекомендации на основе всех тестов:
- Одна v620, ограниченный бюджет: Q6 без DFlash. 18 ток/с достаточно для интерактивной работы, контекст 16k покрывает большинство задач. Команда из конфигурации 1 запускается за минуту.
- Две v620, нужна максимальная скорость: тензорный сплит Q6/Q8 + DFlash. 36 ток/с на генерации и 658 ток/с на промпте - это уровень, сопоставимый с серверными решениями. Контекст 32k позволяет работать с длинными документами. Полная команда в конфигурации 3.
- Две v620, критична минимальная задержка: тензорный сплит без DFlash. Спекулятивное декодирование добавляет 10-20 мс задержки на шаг из-за двойного прохода. Если вы делаете real-time приложение с жесткими требованиями по latency, конфигурация 2 предпочтительнее.
Muse Glimmer 30B оправдывает себя в сценариях, где экономия токенов важнее абсолютного качества: пакетная обработка, API с оплатой за использование, локальный инференс с ограниченным бюджетом времени. Для задач, требующих максимальной точности в сложных рассуждениях, Qwen остается более сильным выбором. Но разрыв сокращается, а эффективность Muse по токенам - аргумент, который сложно игнорировать при масштабировании.
Если вы экспериментируете с альтернативными движками инференса, обратите внимание на сравнение TensorSharp и llama.cpp - новый C# движок выигрывает до 27.9% на префилле в определенных сценариях, хотя для DFlash пока требуется именно llama.cpp. Для тех, кто работает с более компактными моделями на одной карте, оптимизация llama.cpp для Qwen 3.6 27B на RTX 5090 содержит детальный разбор параметров, применимый и к Muse.