Что такое Hot Expert Reload и почему о нём заговорили в llama.cpp
Hot Expert Reload - это предложение добавить в llama.cpp динамическую подкачку активных экспертов MoE-модели в видеопамять. Смысл в том, чтобы эксперт, которого роутер выбрал на текущем шаге, попадал в VRAM на лету, а редко используемый освобождал место. Сейчас llama.cpp так не умеет: раскладка слоёв и экспертов по устройствам задаётся до старта генерации и остаётся неизменной, пока работает модель.
На момент публикации это запрос и обсуждение в сообществе, а не выпущенная функция. Автор обращения связывает её с ускорением декодирования MoE-моделей, у которых много общих параметров и умеренное число активных, и приводит в пример Qwen3.8-Flash-Next, Deepseek V4/V4.1 Flash и GLM 5.3 Flash. Ожидания такие: заметный прирост даже на одной RTX 3090, а на двух картах скорость подбирается к той, что даёт полное размещение модели в VRAM. Перепроверяемых замеров Hot Expert Reload в открытых материалах нет, поэтому все оценки прироста дальше читаются как ожидания автора запроса, а не как измеренный факт.
Практический смысл затеи простой. Если подкачка окажется быстрее чтения эксперта из оперативной памяти или с диска, MoE-модель на карте с 24 ГБ сможет генерировать токены со скоростью, близкой к полному размещению весов на GPU. Если не окажется - выигрыша не будет, потому что узким местом станет шина.
Коротко: что предлагается и для кого
Держать в VRAM пул экспертов, к которым модель обращается чаще всего, и подгружать остальные по мере того, как роутер их выбирает. Вытеснение - по давности использования. Целевое железо из обращения: одна или две RTX 3090, то есть 24 или 48 ГБ VRAM. Целевые модели: разреженные MoE с большим общим числом параметров и небольшим числом активных. Если у вас четыре карты или 80 ГБ VRAM, проблема, которую решает функция, у вас просто не возникает.
Почему это обсуждают именно сейчас
Линейка моделей сместилась в сторону разреженных архитектур: общее число параметров растёт, активных на токен остаётся немного. Для качества это выгодно, для локального запуска - нет. Весить модель стала заметно больше, а считать по-прежнему нужно лишь часть весов.
llama.cpp в этой ситуации умеет две вещи: оставлять на GPU часть слоёв через --n-gpu-layers и держать экспертов MoE в оперативной памяти. Обе настройки статичны. Динамического кэша, который во время генерации подтягивает в VRAM именно тех экспертов, кого выбрал роутер, в проекте нет. Отсюда и запрос: роутинг по своей природе динамический, а раскладка весов по устройствам - статичная. Даты, версии и номера патчей в источниках не указаны, поэтому статус темы описывается обобщённо.
Как MoE-модели работают с экспертами и почему это бьёт по скорости
MoE-слой собирается из нескольких независимых FFN-блоков, которые называют экспертами, и небольшой сети-роутера (gate). Роутер смотрит на вектор токена и решает, каким экспертам этот токен отдать. Работают только выбранные, обычно от одного до восьми. Остальные веса в вычислении не участвуют, но место в памяти занимают.
Отсюда главная особенность разреженных моделей: общее число параметров может быть большим, а активных на один токен - умеренным. Модель хранит все веса целиком, а считает лишь часть. Для локального запуска это означает простую вещь: VRAM упирается в хранение, а не в арифметику.
Роутинг экспертов: что происходит на каждом токене
Набор активных экспертов меняется от токена к токену. При генерации по одному токену за шаг каждый шаг даёт свой узкий набор. В prefill картина другая: батч большой, объединение выбранных экспертов широкое, потому что разные последовательности попадают в разные блоки. Кэш экспертов на GPU вынужден работать в двух режимах одновременно, и это одна из причин, почему задача нетривиальная.
Вторая причина проще: раскладку нельзя посчитать заранее. Она зависит от текста, который модель ещё не прочитала. Статичная карта оффлоада строится один раз и не знает, какие эксперты понадобятся через сто токенов.
Почему декодирование упирается в память, а не в вычисления
Авторегрессивное декодирование обрабатывает один токен за шаг, и каждый шаг требует прочитать веса активных экспертов из памяти, а затем умножить их на вектор активаций. Переиспользовать прочитанные веса, как в prefill, не получается: следующего токена ещё нет. Скорость упирается в пропускную способность памяти, а не в вычислительные блоки карты.
Порядок величин для 3090: пропускная способность VRAM по спецификации около 936 ГБ/с, реальные копирования по PCIe 4.0 x16 дают порядка 25 ГБ/с. Если эксперт лежит в оперативной памяти, каждый токен, которому он нужен, платит за пересылку по шине. Если эксперт уже в VRAM, платить не нужно. В этом вся идея Hot Expert Reload: превратить частые пересылки в редкие попадания. Справочные значения приведены как ориентир, на конкретной плате и в конкретной сборке они отличаются.
Что именно предлагается изменить в llama.cpp
Обсуждаемая схема выглядит так: в VRAM живёт пул горячих экспертов, остальные остаются в оперативной памяти или на диске. На каждом шаге роутер выбирает набор экспертов, отсутствующие копируются на GPU, давно не использовавшиеся вытесняются. Чтобы это не съедало скорость, копирование перекрывается с вычислениями: пока GPU считает текущий слой, следующий набор уже едет по шине.
Технически нужны четыре части: менеджер памяти под эксперты в VRAM, планировщик асинхронных копирований, политика вытеснения и метаданные о том, где в файле модели лежит каждый эксперт, чтобы читать его без распаковки всей модели. Отдельный вопрос - интеграция с батчингом: чем шире батч, тем шире набор нужных экспертов и тем хуже работает кэш.
| Критерий | Оффлоад слоёв | Hot Expert Reload (предложение) |
|---|---|---|
| Гранулярность | целый слой | отдельный эксперт внутри MoE-слоя |
| Когда принимается решение | один раз при запуске | на каждом шаге генерации |
| Что лежит в VRAM | фиксированный набор слоёв | пул горячих экспертов |
| Смена набора экспертов | ничего не меняется, веса читаются из RAM | недостающие эксперты копируются на GPU |
| Статус | работает в llama.cpp | обсуждается, в коде нет |
Чем это отличается от обычного оффлоада слоёв
--n-gpu-layers задаёт, сколько слоёв модели живёт на GPU, и это решение принимается один раз. Эксперты внутри MoE-слоя при таком подходе остаются там же, где оказался слой: либо целиком в VRAM, либо целиком в RAM. Гранулярность - слой, менять её во время генерации нельзя.
Hot Expert Reload предлагает гранулярность «отдельный эксперт» и динамику: раскладка меняется прямо во время генерации. Оффлоад слоёв отвечает на вопрос «сколько влезет», подкачка экспертов отвечает на вопрос «что нужно именно сейчас». Это разные уровни одной задачи.
Что уже есть в llama.cpp для работы с MoE
Проект давно поддерживает MoE-архитектуры, умеет оффлоадить слои, размещать экспертов на CPU, располагает CUDA-бэкендом и фильтрами, которые позволяют выбирать, каких экспертов оставлять на GPU. В наших материалах показано, как запустить MoE-модель весом 204 ГБ на одной видеокарте: комбинация unified memory, regex-фильтров для экспертов и управления батчем даёт до 340 токенов/с на префилле и 9.6 t/s при генерации на DGX Spark, с отдельными замерами на связке RTX 3090 и DDR4. Там же разобраны ограничения такого подхода.
Чего нет, так это динамического кэша экспертов в VRAM. Раскладка вычисляется на старте и живёт до конца сессии. Hot Expert Reload - ровно про отказ от этого ограничения. Конкретного патча в открытых источниках нет, поэтому формулировка «предлагается» здесь не осторожность ради осторожности, а точное описание статуса.
Насколько реально ускорение на одной и двух RTX 3090
Аргумент автора обращения: на одной RTX 3090 прирост будет ощутимым, на двух картах скорость приблизится к полному размещению модели в VRAM. Проверить это пока нечем, публичных замеров именно Hot Expert Reload нет. Зато понятно, от чего результат зависит.
- Объём VRAM: 24 ГБ на карту. Всё, что не влезло, едет по шине.
- Размер одного эксперта и число активных экспертов на токен.
- Локальность роутинга: как часто повторяются одни и те же эксперты.
- Длина контекста и размер батча: чем шире набор активных экспертов, тем хуже работает кэш.
- Шина: PCIe 4.0 x16 и NVLink-мост.
Отношение скоростей задаёт потолок. VRAM на 3090 по спецификации читается примерно на порядок быстрее, чем идёт копирование по PCIe. Значит, подкачка выигрывает только тогда, когда объём данных, которые нужно перетащить, заметно меньше объёма весов, которые GPU всё равно читает из VRAM. Чем чаще меняется набор экспертов, тем хуже соотношение.
Одна RTX 3090: где предел 24 ГБ VRAM
На одной карте пул экспертов делит 24 ГБ с весами остальных частей модели, KV-кэшем и буферами. Чем длиннее контекст, тем меньше места остаётся под кэш экспертов, и тем чаще происходят подкачки. Прирост будет заметен, если роутер часто возвращается к небольшому набору экспертов. Если набор меняется на каждом токене, каждая подкачка добавляет лишний обмен по шине на токен, и скорость может упасть ниже той, что даёт обычный оффлоад экспертов на CPU.
Две RTX 3090: когда скорость приближается к полному VRAM-размещению
48 ГБ суммарно позволяют держать более широкий пул экспертов и KV-кэш. У 3090 есть NVLink-мост, который даёт больше пропускной способности, чем PCIe, но обмен между картами остаётся копированием со своей задержкой. Ожидание «скорость как при полном размещении в VRAM» корректно читать как верхнюю границу, к которой можно приблизиться при удачном паттерне роутинга, а не как гарантию.
Полезно держать в голове масштаб. В отчёте о сборочной проблеме llama-server на Windows зафиксирован замер декодирования на RTX 3090: 18.5 tok/s против 17.9 tok/s на сборке до изменения. Разница меньше четырёх процентов. Функция подкачки экспертов должна отыгрывать десятки процентов, иначе смысла в ней нет.
Узкое место бывает и не в шине. Разбор запуска DeepSeek-V4-Flash на одном B300 показывает, как скорость съедают отказ MoE-ядра без expert parallel и насыщенный батч: 770 токенов/с вместо ожидаемых тысяч. Подкачка экспертов не поможет там, где ядро и без неё работает неэффективно.
Ограничения и подводные камни подхода
Идея выглядит логично, но упирается в несколько физических и архитектурных ограничений. Разберём их честно, потому что обещать «SOTA на домашнем ПК» здесь нечего.
Латентность и пропускная способность шины
Каждая подкачка - это обмен по PCIe. У копирования есть задержка запуска, и на небольших передачах она ощутима. Если набор экспертов меняется каждый токен, GPU большую часть времени ждёт данные, а не считает. В таком режиме выигрыш нулевой или отрицательный.
В разборе LayerStoRm про 186 ГБ весов на 96 ГБ VRAM и стриминг экспертов видно, как PCIe и NUMA определяют реальную скорость при подгрузке экспертов из системной памяти. Там же приведён чек-лист стенда и правила чтения TTFT, чтобы не переносить чужие результаты на своё железо.
Эффективность кэша экспертов
Кэш работает только при локальности роутинга. Если модель раз за разом обращается к одному и тому же подмножеству экспертов, пул в VRAM быстро окупается. Если распределение близко к равномерному, попаданий почти не будет, и каждый токен потянет за собой копирование. Вытеснение добавляет свои накладные расходы: политика по давности использования не знает, что вытесненный эксперт понадобится через один шаг. Точных процентов попаданий для конкретных моделей в открытых материалах нет, поэтому оценивать их нужно на своей нагрузке.
Отдельный пласт - инфраструктура сборки, от неё зависит, как быстро функция доберётся до пользователей. Сборка llama-server под Windows/MSVC падает на этапе линковки с ошибкой LNK2001 из-за известной несовместимости двух возможностей CMake: WINDOWS_EXPORT_ALL_SYMBOLS и precompiled headers. Обход - отключить PCH флагом -DCMAKE_DISABLE_PRECOMPILE_HEADERS=ON; бинарник после этого ведёт себя так же, теряется только выигрыш по времени сборки. Это не блокер для подкачки экспертов, но напоминание: до конечного пользователя доходит не только алгоритм, но и сборочная обвязка.
Что это значит для локального запуска почти-SOTA моделей
Модели, которые приводит автор обращения, объединяет одна черта: много общих параметров и умеренное число активных. Qwen3.8-Flash-Next, Deepseek V4/V4.1 Flash, GLM 5.3 Flash именно поэтому выглядят кандидатами на схему с подкачкой экспертов: целиком в 24 ГБ они не помещаются, но вычислительно не требуют всей своей массы одновременно. Без работающей функции и замеров это остаётся гипотезой о поведении, а не подтверждённым сценарием.
Кому это даст больше всего
Владельцам одной или двух карт с 24 ГБ, которые уже запускают MoE-модели и упираются в объём VRAM. Им функция вернула бы часть скорости, потерянной на оффлоаде экспертов в RAM и загрузке процессора. Тем, у кого 80 ГБ VRAM или четыре карты, подкачка почти не нужна: модель и так помещается, а лишний обмен только добавит задержек. На одно-GPU конфигурациях без запаса по VRAM выигрыш будет скромнее, потому что конкуренцию за память никто не отменял.
Что делать сейчас, пока функции нет
- Замерить текущую скорость декодирования на своих моделях и записать конфигурацию: модель, квант, флаги, длину контекста. Без базовой точки отсчёта сравнивать будет не с чем.
- Поэкспериментировать с уже доступными механизмами: оффлоад экспертов на CPU, regex-фильтры для выбора экспертов, unified memory. Это даёт реальный прирост сегодня.
- Посмотреть, как выглядят альтернативные подходы к той же проблеме: экспериментальная ветка llama.cpp с expert expansion для MoE-моделей и стриминг-инференс для MoE-моделей через TensorRT-LLM и DeepSpeed. Оба варианта решают задачу «модель не влезает», но с разной ценой по скорости и сложности.
- Не менять железо под функцию, которой пока нет. Апгрейд стоит планировать под задачи, а не под ожидания от обсуждения.
Итог: чего не хватает llama.cpp и когда ждать изменений
Короткий ответ на главный вопрос
llama.cpp умеет оффлоадить слои и держать экспертов MoE на CPU, но не умеет динамически подгружать их в VRAM по выбору роутера. Hot Expert Reload - это запрос на такую возможность, а не готовая функция. Потенциальный выигрыш реален для разреженных моделей с локальным роутингом и умеренным числом активных параметров, однако подтверждённых замеров нет, и сроков появления назвать нельзя. Если у вас одна-две RTX 3090, следить за темой стоит, строить на ней планы - рано.
Как следить за развитием темы
Смотреть на обсуждения и issue в репозитории llama.cpp, на релизные заметки проекта и на тематические сообщества локального инференса. Ориентир простой: как только появятся флаги для управления кэшем экспертов и хоть один замер tok/s на двух картах с воспроизводимой конфигурацией, тему можно будет обсуждать предметно. До этого честный вывод звучит так: инфраструктура готова, идея сформулирована, кода нет.