Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Один и тот же LLM лучше обслуживает запрос, если обработка промпта и генерация ответа используют разные представления весов. В нерецензированном препринте, где все числа получили сами авторы, отдельный модуль обработки промпта поднял точность 1-битной Qwen3.8-27B на MMLU-Pro на 32,5 процентного пункта, не меняя декодер. Для команд это открывает промежуточный путь между заменой готовой сжатой модели и полной загрузкой более точной версии в память ускорителя.
Две фазы упираются в разные части оборудования
Во время обработки промпта модель одновременно прогоняет много токенов и строит кэш ключей и значений, который затем использует при ответе. Вычислительные блоки многократно обращаются к одним весам, поэтому скорость сильнее зависит от того, насколько эффективно ускоритель выполняет матричные операции.
Во время генерации модель выпускает токены последовательно. Для каждого нового токена ей снова приходится читать веса, поэтому ограничением чаще становится пропускная способность памяти, а не скорость арифметики.
Обычная квантизация, то есть снижение точности весов и промежуточных значений, выбирает один компромисс для обеих фаз. Аппаратно поддерживаемый формат вроде NVFP4 ускоряет обработку промпта, но квантизация промежуточных значений может повредить качеству ответа. Сложная упаковка весов в несколько бит экономит память при генерации, однако перед матричными операциями значения приходится восстанавливать или преобразовывать.
Авторы разделили эти решения на три уровня. В простейшем варианте веса остаются общими, но промежуточные значения при генерации не квантизуются. В полном варианте обработка промпта получает собственные веса NVFP4, а генерация — отдельный компактный набор. Оба пути обучаются совместно, чтобы созданный первым кэш подходил второму.
Отдельный модуль помогает самым сжатым декодерам
Разделение форматов почти не меняет размещение модели: обработка промпта использует быстрые операции NVFP4, а генерация читает компактные веса без квантизации промежуточных значений. На Qwen 3 и Gemma 3 это улучшило результаты прежде всего в задачах с длинным ответом, сохранив расход памяти и стоимость обработки промпта.
Отдельные веса дают больший эффект, когда декодер сильно сжат. Для готового Qwen3.8-27B в формате GGUF авторы заморозили декодер и обучили только модуль обработки промпта. На MMMU-Pro точность 1-битной версии выросла на 35,3 процентного пункта. Для 3-битного декодера тот же подход уже слегка ухудшил результат: дополнительная модель нужна не при любой степени сжатия.
Хранить второй набор весов в памяти ускорителя необязательно. В варианте ODP веса поступают с SSD по слоям: пока один слой обрабатывает промпт, следующий загружается в освободившийся буфер. На контексте 8K время до первого токена улучшилось в 1,78 раза относительно запуска только с компактными весами.
Такой конвейер окупается, когда вычисление каждого слоя длится достаточно долго, чтобы скрыть чтение с SSD. На коротких промптах загрузка задерживает запрос. Авторы считают ODP прежде всего способом локально запускать плотные модели; для моделей с разреженными экспертами чтение весов оказывается слишком дорогим относительно объёма вычислений.
Архитектуру сервинга стоит менять только под длинный контекст
Если обработка промпта и генерация уже работают на разных ускорителях, работа предлагает сравнительно прямое изменение: каждой фазе можно назначить собственный формат. Передавать между ними нужно прежний кэш, поэтому менять устройство внимания или формат запросов к модели не требуется.
Для локального сервинга вывод уже уже: отдельный модуль имеет смысл при длинных промптах, дефиците памяти ускорителя и готовом низкобитном декодере, который нежелательно переобучать. Тогда его можно оставить замороженным, обучить совместимый модуль обработки промпта и держать этот модуль на SSD между запросами. При коротком контексте или умеренной квантизации сложность дополнительного конвейера может не окупиться.
Основные эксперименты охватывают Qwen 3 и Gemma 3, задачи с длинной генерацией и RULER с длинным промптом и коротким ответом. Скорость измеряли для одного запроса на DGX Spark: генерацию — в vLLM, загрузку с SSD и время до первого токена — в модифицированном llama.cpp. Отдельно отключение квантизации промежуточных значений при генерации проверили после обучения на моделях размером до 2,8 трлн параметров.
Эти условия не покрывают высокую пакетную нагрузку, многоходовые диалоги и агентов. В многоходовом сценарии часть кэша создаёт декодер, а при повторной обработке истории те же токены может пересчитать другой набор весов. Поэтому работа меняет планы прежде всего для однопользовательского или разнесённого сервинга с длинным контекстом, но пока не обосновывает замену конвейера в нагруженном диалоговом продукте.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
