ainews
DFlash превратил 118B-модель на двух RTX 5090 в тормоз: как вернуть скорость или забить на спекуляцию
Энтузиаст запустил огромную MoE-модель Laguna S 2.1 (118B параметров, 71 ГБ) на двух RTX 5090 с технологией DFlash speculative decoding — и она замедлила генерацию в 2,5 раза вместо ускорения. Причина: дефолтные настройки llama.cpp заставляли драфтер генерировать слишком много токенов без уверенности, а верификация каждого токена обходилась дорого из-за оффлоада экспертов в CPU RAM. После тюнинга (ограничение длины драфта, порог уверенности 0.6, квантизация драфтера в Q8) скорость выросла с 23 до 64 tok/s — но это всё равно примерно как без драфта (62 tok/s), так что вывод: на такой конфигурации спекулятивная генерация бесполезна.
Первое детальное исследование того, почему speculative decoding может провалиться на больших MoE-моделях с частичным оффлоадом. Важно для всех, кто пытается выжать максимум из llama.cpp на потребительском железе с ограниченной VRAM — показывает, что дефолтные настройки могут сделать только хуже, и объясняет почему.
Эксперимент с дорогим железом и неожиданным провалом
Пользователь Reddit под ником luke_pacman запустил массивную MoE-модель Laguna S 2.1 (118 миллиардов параметров, 71 ГБ в квантизации Q4) на связке из двух RTX 5090 (по 32 ГБ каждая) с использованием технологии DFlash speculative decoding в llama.cpp. Идея спекулятивной генерации проста: маленькая «драфтер»-модель (2,1 ГБ) предсказывает несколько токенов наперёд, большая модель проверяет их за один проход — если угадали, выигрываем время.
Но на практике скорость упала с 58 до 23 tok/s — в 2,5 раза медленнее. Причина: модель не влезает в 64 ГБ видеопамяти, часть экспертов (модель использует 256 экспертов, активируется топ-10 на каждый токен) живёт в оперативке CPU. Каждый дополнительный токен в батче верификации — это потенциально 160 разных экспертов на слой, которые надо подгружать из RAM. Измеренная стоимость: ~6,8 мс на каждый токен верификации. «Верификация почти бесплатна» — миф на такой архитектуре.
Три ошибки дефолтных настроек
--spec-draft-p-minпо умолчанию = 0.00. Драфтер отправлял все 15 токенов каждый раз, даже когда не уверен. Acceptance rate: жалкие 10,5%.- Fine-grained MoE наказывает большие батчи верификации: каждый токен активирует свой набор экспертов, CPU-оффлоад превращает это в узкое горлышко.
- BF16-драфтер жрал лишние ~3 ГБ VRAM, которые могли держать больше экспертов на GPU.
Починка: три простых твика
- Ограничить длину драфта (
--spec-draft-n-max 7) и включить порог уверенности (--spec-draft-p-min 0.6). Acceptance взлетел до 73%. - Квантизовать драфтер из BF16 в Q8_0 — освободил 1 ГБ, acceptance не пострадал.
- Итог на двух GPU: 64 tok/s против 62 без драфта — формально быстрее, но на практике в пределах погрешности.
На одной RTX 5090 (40 ГБ экспертов в RAM) с ещё более строгим порогом (0.75) результат: 33 tok/s против 30. Тут спекуляция уже реально работает, потому что базовый шаг медленнее — относительная польза от драфтера выше.
Бенчмарк на Spec-Bench: категории имеют значение
Автор прогнал всё на Spec-Bench (стандартный датасет для speculative decoding: разговоры, перевод, суммаризация, QA, математика, RAG). Результаты:
- Математика и перевод: +20-25% — драфтер обожает формульный текст.
- Диалоги: +5-9%.
- RAG/QA/суммаризация: от паритета до −9%. Копируемый текст ≠ предсказуемый. Драфтер не умеет просто копировать как n-gram-методы, ему нужна структура.
Вывод: на этой конфигурации драфт бесполезен
DFlash обычно даёт 2×+ ускорение — но только когда всё влезает в VRAM. Здесь CPU-оффлоад экспертов убивает экономику: каждый токен верификации стоит дорого, спекулятивная генерация окупается только на идеальных категориях.
Бонус: на одной RTX 5090 32 ГБ можно вполне комфортно работать с такой моделью на ~30 tok/s для агентских задач. Но вопрос качества Q4-квантизации для реальной работы автор пока не проверял.
Ключевые выводы
- DFlash speculative decoding на MoE-моделях с частичным CPU-оффлоадом не даёт ускорения: верификация перестаёт быть дешёвой, каждый токен в батче активирует новые эксперты в RAM
- Дефолтный --spec-draft-p-min=0.00 в llama.cpp — ловушка: драфтер генерирует все токены без разбора, acceptance rate проваливается до 10%
- Квантизация драфтера (BF16 → Q8_0) освобождает ~1 ГБ VRAM без потери точности — бесплатная оптимизация
- Спекулятивная генерация выигрывает на формульном тексте (математика, переводы), но проигрывает на копируемом контенте (RAG, суммаризация) — learned drafter ≠ n-gram lookup
- На одной RTX 5090 (32 ГБ) можно реально работать с 118B MoE-моделью на ~30 tok/s — достаточно для агентских задач
Автор: Никита Громов · Источник: reddit.com
Это тот редкий случай, когда пост на Reddit ценнее дюжины корпоративных блогов. Автор не просто пожаловался на тормоза — он методично разобрал три слоя проблемы (дефолты llama.cpp, архитектуру MoE, экономику CPU-оффлоада), показал цифры на каждом этапе и честно признал: после всех танцев с бубном speedup нулевой. Это антитеза хайпу вокруг speculative decoding.
Важная деталь: DFlash работает отлично *на правильных задачах и железе*. Но на fine-grained MoE с частичным оффлоадом вся математика ломается — верификация становится дорогой, а категории текста начинают иметь значение. Перевод и математика выигрывают +20%, суммаризация проигрывает — learned drafter не умеет просто копировать текст, ему нужна предсказуемая структура. Мораль: бенчмарки на чужих датасетах не скажут вам ничего про вашу задачу, тестируйте сами. И читайте документацию llama.cpp, там есть флаги, которые никто не трогает — а зря.
Комментарии