Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Большую языковую модель можно ускорить, не выделяя отдельный KV-кэш для черновой модели. Работа команд Harvard University, Capital One, Red Hat, ISTA и NVIDIA, которая не прошла рецензирование и приводит числа из собственных замеров авторов, показывает: H-Spec превосходит лучший сравниваемый вариант по средней принятой длине на 5,0–13,3%, а по ускорению времени ожидания следующего токена — на 5,3–12,6%. Для сервиса под нагрузкой это означает меньше памяти на каждый запрос и больше места для одновременных генераций.
Отдельный кэш начинает мешать под нагрузкой
При спекулятивном декодировании небольшая черновая модель предлагает сразу несколько будущих токенов. Основная модель проверяет их за один проход и принимает только те, которые соответствуют её собственному распределению вероятностей. Поэтому система сокращает число дорогих проходов основной модели, не меняя результат генерации.
Современные параллельные черновые модели предсказывают весь блок токенов одновременно. Чтобы учитывать исходный запрос, они преобразуют скрытые состояния основной модели в собственное хранилище ключей и значений внимания — KV-кэш. Оно живёт до конца запроса, занимает GPU-память и требует записывать новые элементы по мере генерации.
Эти расходы растут вместе с числом активных запросов. В опыте с Qwen3-8B время на запись KV для черновой модели выросло в 4,7 раза при переходе от 4 до 128 одновременных запросов. Такой кэш может не мешать одиночной генерации, но сокращает доступный пакет и пропускную способность сервера.
Просто подключить черновую модель к KV-кэшу основной модели недостаточно. Ключи и значения сохраняют сведения об отдельных позициях, но не дают готового краткого представления всего префикса. В эксперименте такой вариант почти не уступал обычной схеме в начале чернового блока, но чаще ошибался на поздних позициях.
Как H-Spec сохраняет контекст без второго кэша
H-Spec получает контекст из двух источников. Модули внимания напрямую читают уже существующий KV-кэш основной модели и извлекают сведения о конкретных позициях. Отдельная копия этих данных не создаётся.
Второй источник — скрытое состояние основной модели для последнего входного токена. При причинном внимании оно уже учитывает весь предшествующий текст, поэтому служит компактной сводкой запроса. Его объём не растёт вместе с длиной входа, в отличие от полного набора ключей и значений.
Этой сводкой H-Spec инициализирует состояние модулей Mamba-2. Они последовательно связывают позиции на уровне архитектуры, но вычисляют черновой блок параллельным сканированием. Модули внимания дополняют это состояние точными сведениями из KV-кэша основной модели.
После гибридной части работает лёгкая причинная коррекция из DSpark: прогноз на очередной позиции уточняется с учётом предыдущего прогноза. Это компенсирует слабое место полностью параллельных черновиков, которым труднее учитывать зависимости между соседними токенами. Основная модель при этом не меняется, поэтому H-Spec можно подключать на уровне системы вывода.
Когда H-Spec меняет план сервинга
Работу проверяли с Llama3.1-8B-IT, Qwen3-4B и Qwen3-8B на восьми типах задач: от математики и кода до диалогов, поиска с дополнением контекста и вызова инструментов. H-Spec сравнивали с P-Eagle, DFlash и DSpark, обученными заново по единой схеме. Нагрузочные испытания проводили в vLLM.
При одновременном обслуживании запросов H-Spec во всех проверенных режимах давал более высокую пропускную способность и занимал меньшую долю KV-кэша, чем сравниваемые параллельные черновые модели. Это делает схему интересной для систем, где предел задаёт память GPU: чат-сервисов, программных агентов и генерации длинных ответов с общим пулом ускорителей.
Для малой нагрузки преимущество не гарантировано. В отдельном синтетическом опыте гибридная архитектура работала медленнее при конкуренции ниже 32 запросов из-за более глубокого графа вычислений. По мере роста входа соотношение менялось: после примерно 512 токенов она становилась быстрее блочной диффузионной модели, поскольку содержит меньше модулей внимания и не записывает отдельный KV-кэш.
Есть и архитектурное условие: размеры ключей и значений в H-Spec должны совпадать с основной моделью, иначе повторно использовать её кэш без преобразования не получится. Это не универсальная замена любой черновой модели, а целевая схема, которую придётся обучать и собирать под конкретное семейство основной модели.
Для сервиса с короткими запросами и небольшим числом одновременных генераций работа сама по себе не требует менять стек. Если же команда уже упирается в KV-кэш или уменьшает пакет из-за памяти, H-Spec предлагает проверяемое направление: отказаться от второго кэша, передать сводку префикса через состояние Mamba и оценивать выигрыш именно под рабочей конкуренцией, а не только на одиночном запросе.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
