Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Большая LLM может принять контекст от меньшей модели и не обрабатывать весь запрос заново. Во внерецензированном препринте, где все числа получили сами авторы, команда USC, UC Irvine и Intel Labs сохранила 95–99% качества целевой модели, пересчитав 30% позиций. Схема рассчитана на каскады моделей, программных агентов и переключение модели внутри уже начатой сессии.
Почему нельзя просто передать кеш большой модели
Во время первичной обработки запроса модель сохраняет для каждого токена кеш ключей и значений (KV-кеш). Благодаря ему при генерации следующего токена не приходится повторно обрабатывать весь контекст.
Но кеш зависит от архитектуры и параметров модели. Если агент сначала работал на небольшой Qwen3, а затем передал сложный запрос крупной Qwen3, новая модель обычно заново обрабатывает историю диалога. На длинном контексте этот этап увеличивает время до первого токена и занимает GPU до начала генерации.
RaReCache сначала переводит кеш исходной модели в пространство целевой с помощью линейного преобразования. Его заранее рассчитывают отдельно для слоёв, ключей и значений на калибровочных данных. Метод работает внутри семейства моделей, где используется общий токенизатор: каждой позиции исходного запроса соответствует та же позиция у целевой модели.
Одного преобразования недостаточно. Чем сильнее модели различаются по размеру, тем больше важной информации отсутствует в представлениях меньшей модели. В опыте с Qwen3 разрыв по числу параметров достигал 23×, поэтому обычный перенос кеша заметно уступал полной обработке контекста целевой моделью.
Как ранговое расхождение находит важные позиции
Ошибки переноса распределяются по запросу неравномерно. Повторяющиеся элементы — шаблон чата, заголовки и инструкции — линейное преобразование восстанавливает достаточно хорошо. Уникальные числа, сущности и связи из самого задания чаще требуют обработки большой моделью.
RaReCache оценивает каждую позицию по ранговому расхождению. Полное преобразование сравнивают с его сокращённой версией, которая оставляет только направления, хорошо представленные в калибровочных данных. Если результаты сильно расходятся, токен опирается на плохо изученную часть пространства и попадает в очередь на пересчёт.
Оценка не требует предварительно прогонять весь запрос через целевую модель. Система сортирует позиции, запускает большую модель только для верхней доли списка, а затем объединяет пересчитанные записи с перенесённым кешем.
Обычное внимание модели для такого отбора оказалось плохим ориентиром. В разобранном запросе из GSM8K целевая модель направила 72% внимания на начальный служебный токен, 24% — на остальной шаблон и инструкцию и лишь 4% — на условие задачи. Поэтому отбор по вниманию тратил вычисления на позиции, которые преобразование уже воспроизводило.
Не помогла и величина ошибки между перенесённым и настоящим кешем: крупное отклонение не всегда влияло на ответ. Ранговое расхождение ищет не самую большую ошибку, а непривычное для калибровочных данных представление.
Ускорение зависит от нагрузки и устройства сервиса
Метод проверяли на семействах Qwen3 и Llama 3, а качество — на задачах по математике, общим знаниям, рассуждению и ответам по длинному контексту. В набор вошли GSM8K, MMLU-Redux, ARC-Challenge, ARC-Easy и LongBench-E QA. Для каждой задачи преобразование калибровали отдельно на её обучающей части, которая не пересекалась с проверочными примерами.
На серверных замерах выигрыш оказался меньше, чем сокращение числа пересчитанных позиций. Целевой модели всё равно нужно загрузить веса и позволить выбранным токенам обратиться ко всем ключам запроса. При пакетной обработке RaReCache ускорил первичную обработку до 2,36× при бюджете, который сохранял близкое к исходному качество.
Под высокой нагрузкой сокращение вычислений дополнительно уменьшало очередь запросов. На границе пропускной способности обычной обработки медианное время до первого токена снизилось в 5 раз. При слабой нагрузке базовый вариант мог отвечать быстрее: накладные расходы на преобразование, отбор и запуск нескольких небольших вычислительных операций ещё не компенсировались очередью.
Для команды, которая использует одну модель для всех запросов, работа не меняет архитектурный выбор: переносить кеш между моделями там не требуется. Практический кандидат — сервис, где малая модель уже обрабатывает контекст, а большая подключается только к сложным шагам или продолжает длинную сессию.
Перед внедрением придётся проверить схему на собственных запросах и профиле нагрузки. В работе преобразования настраивали под конкретные модельные пары и задачи, а измерения проводили внутри двух семейств с общим токенизатором. Поэтому результат пока служит основанием для прототипа, а не универсальной заменой полной обработки контекста.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
