Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
KV-кэш циклических трансформеров научились сжимать ниже одного бита на элемент без резкого падения качества модели. В препринте, который не прошёл рецензирование, все числа получили сами авторы: LoopVQ почти вдвое сократил задержку генерации при длинном контексте и позволил обслуживать больше параллельных запросов. Метод может изменить расчёт инфраструктуры для циклических моделей, но не переносится напрямую на обычные трансформеры.
Общие веса не сокращают память контекста
Циклический трансформер несколько раз применяет один и тот же набор слоёв. Так модель увеличивает глубину вычислений, не сохраняя отдельные веса для каждого прохода. Ouro-1.4B благодаря этому сопоставим с некоторыми обычными моделями большего размера.
Экономия заканчивается на KV-кэше — памяти с ключами и значениями уже обработанных токенов. Каждый шаг цикла записывает собственные ключи и значения, поэтому объём кэша растёт вместе с числом повторных проходов. У Ouro-1.4B на один токен приходится в шесть раз больше KV-кэша, чем у Llama-3.1-8B, хотя весов у Ouro меньше.
При длинном контексте кэш занимает больше памяти, чем веса. Он ограничивает длину запроса и размер пакета, а во время генерации GPU приходится постоянно читать его из памяти. Поэтому уменьшение весов само по себе не решает задачу дешёвого обслуживания циклической модели.
LoopVQ использует то, что повторные проходы создаёт один блок слоёв. Один и тот же канал ключа между соседними шагами коррелирует в среднем на 0,85, тогда как разные каналы внутри одного шага — на 0,16. Обычные методы квантизации, то есть хранения чисел с меньшей разрядностью, эту связь между шагами не используют.
Один код описывает несколько шагов цикла
При векторной квантизации несколько чисел заменяют индексом записи в таблице эталонных векторов. Стандартные методы объединяют соседние каналы одного шага и создают независимые таблицы для разных шагов. При разрядности ниже одного бита такая схема теряет слишком много информации.
LoopVQ собирает в один вектор каналы нескольких последовательных шагов. В кэше остаётся один индекс, а каждый шаг читает из выбранной записи свою часть. Метод не выбрасывает старые токены и не сокращает контекст: он меняет представление ключей и значений.
Шаги при этом по-разному чувствительны к ошибкам. Искажение раннего кэша проходит через последующие циклы, тогда как ошибка последнего шага влияет только на финальный проход. Поэтому обычная настройка таблиц по точности восстановления исходных чисел распределяет доступную разрядность не там, где она сильнее влияет на ответ.
После начальной настройки LoopVQ дообучает таблицы так, чтобы выходное распределение сжатой модели совпадало с исходной моделью. Веса самой модели остаются замороженными, а соответствие векторов записям таблицы пересчитывается во время настройки. Это учитывает и разную чувствительность шагов, и накопление ошибок между ними.
При 0,5 бита на элемент сочетание TaSQ и LoopVQ дало Ouro-2.6B среднюю оценку 80,30 против 81,46 у BF16. На задачах с длинной цепочкой рассуждений LoopVQ также сохранил близкую к BF16 длину ответа, тогда как базовые методы квантизации часто доходили до предельного бюджета токенов и тратили вычисления без завершения рассуждения.
Когда LoopVQ меняет план развёртывания
Авторы встроили метод в SGLang. Первые и самые свежие токены остаются в BF16, а более старые страницы кэша переводятся в индексы. Во время внимания отдельное ядро GPU восстанавливает ключи и значения из таблиц, после чего объединяет результат с несжатой частью кэша.
При контексте 32K токенов задержка генерации сократилась примерно вдвое. Пиковая пропускная способность выросла до 4,3 раза на Ouro-1.4B и до 6,1 раза на Ouro-2.6B. Выигрыш растёт вместе с контекстом: чтение KV-кэша становится узким местом, а сжатое представление передаёт из памяти меньше данных.
Обработка входного контекста, напротив, стала немного медленнее из-за кодирования кэша. Для коротких запросов это может съесть часть выигрыша. Метод полезнее там, где модель долго генерирует ответ, держит большой контекст или обслуживает много запросов одновременно.
Качество проверяли на Ouro-1.4B, Ouro-2.6B и Huginn-3.5B: на общих задачах, программировании, математике, длинных рассуждениях и поиске информации в большом контексте. Системные замеры проводили для Ouro на A100 и RTX 6000 Ada. По скорости LoopVQ сравнивали только с обслуживанием BF16, поэтому эти результаты не показывают, как он соотносится с другими методами при одинаково оптимизированных ядрах GPU.
Для команды, которая уже выбрала циклическую архитектуру, работа добавляет практический путь к длинному контексту без пропорционального роста памяти: понадобятся калибровка таблиц и специализированное ядро внимания. Если продукт строится на обычном трансформере, план менять рано — преимущество LoopVQ возникает именно из повторного применения общих слоёв и сходства кэша между шагами.
Источники
Иллюстрация: рисунок из статьи «LoopVQ: Sub 1-bit KV Cache Quantization for Looped Transformers», Minsoo Cheong, Sungjoo Yoo, CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
