Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Длинный запрос научились обрабатывать быстрее без дообучения модели. В препринте, который не прошёл рецензирование и содержит замеры самих авторов, RidgeFill ускорил подготовку запроса в 1,25–1,60 раза в двух серверных реализациях. Метод можно добавить к уже выбранной модели, но выигрыш приходится обменивать на риск ошибок в отдельных задачах с длинным контекстом.
Как RidgeFill восстанавливает кэш поздних слоёв
Подготовка запроса (prefill) — это проход всех входных токенов через модель до генерации первого ответа. На длинном контексте этот этап определяет задержку: модель должна обработать каждый токен каждым слоем и записать в кэш ключи и значения, которые понадобятся при генерации.
RidgeFill полностью выполняет нижнюю часть модели до выбранного слоя. Затем для каждого позднего слоя отдельная линейная карта предсказывает его входное состояние непосредственно из состояния на границе раздела. Поздний слой применяет к прогнозу собственные проекции ключей и значений, но пропускает остальные вычисления, включая полносвязный блок.
Карты получают гребневой регрессией: исходную модель один раз запускают на калибровочном тексте, сохраняют состояния слоёв и решают систему уравнений в замкнутом виде. Итеративного обучения и изменения весов модели нет. В отличие от методов прореживания, RidgeFill не выбрасывает токены: для каждого остаётся запись в кэше.
Приближение применяют не ко всему запросу. Последние несколько тысяч токенов проходят модель полностью, как и каждый генерируемый токен. Дополнительные строки кэша можно считать точно, если нижние слои уделяют им много внимания или если они относятся к классам токенов, на которых ошибка особенно дорога.
У этого устройства есть прямой компромисс. Более ранняя граница раздела и короткий точный хвост экономят больше вычислений, но повышают риск потери качества. Метод также не уменьшает сам кэш, а карты занимают дополнительную память или загружаются из памяти центрального процессора.
Средняя ошибка не показывает, где сломается ответ
Авторы сначала измеряли среднюю потерю по всем токенам, но она скрывала проблему. Ошибка прогноза распределялась сравнительно ровно, тогда как ущерб концентрировался на малой части контекста — например, на числах, именах и идентификаторах, которые модель должна точно скопировать.
Поэтому RidgeFill проверяли задачами с поиском «иголки» внутри приближённой части контекста, потерей на токенах, зависящих от далёкого фрагмента, и тестами с подменой отдельных частей кэша точными значениями. Такая подмена показывает не только факт ухудшения, но и его источник.
На Llama-3.1-8B основную ошибку несли ключи внимания, причём заметная часть возникала из-за их масштаба. На Qwen3.5-9B важнее оказались значения и состояние рекуррентных слоёв. Для Qwen3-8B исправление только одной стороны не помогало: ключи и значения требовалось восстанавливать вместе.
Выбор точных строк по вниманию сработал, когда вопрос находился в конце запроса: нижние слои уже указывали на фрагменты, нужные для ответа. Если селектор не видел вопрос, качество снижалось. Это делает метод зависимым не только от архитектуры модели, но и от расположения инструкции и данных в реальном шаблоне запроса.
Границы проверки охватывают референсные Llama-3.1-8B, Qwen3-8B и Qwen3.5-9B, а также серверные запуски Qwen3.8-27B и Qwen3.8-Flash-Next. Результаты различались между архитектурами: настройки, которые помогали двум моделям, могли вредить третьей, а Llama хуже переносила ранний переход к приближению.
Когда метод меняет планы серверной части
На Qwen3.8-27B в форке llama.cpp с одной A100 точная обработка запроса длиной 120 тысяч токенов занимала 128 секунд. Когда карты лежали в памяти GPU, RidgeFill ускорял подготовку в 1,25–1,31 раза. Оценки RULER и LongBench v2 снижались примерно на 1,4 пункта; разница находилась в пределах погрешности, но замеры не исключают потери нескольких пунктов.
Верхнюю границу ускорения из лида получили на Qwen3.8-Flash-Next в форке vLLM. Это важно для интерпретации результата: RidgeFill пока показан как изменение двух конкретных серверных движков, а не как готовый переключатель в их основных версиях.
Для продукта с длинными документами работа меняет план эксперимента, но не выбор модели целиком. Если задержку создаёт именно подготовка запроса, можно сначала сохранить текущие веса, построить карты на собственном калибровочном корпусе и прогнать продуктовые задачи с теми же шаблонами инструкций. Оценивать только среднюю потерю или обычные короткие запросы недостаточно.
RidgeFill особенно уместен там, где допустима небольшая статистическая просадка ради более быстрого первого токена. Для точного извлечения реквизитов, кода и идентификаторов потребуется отдельный набор проверок и более консервативный точный хвост. Если же узкое место связано с памятью кэша или скоростью генерации после первого токена, эта работа архитектурный план не меняет.
Сравнение со SwiftKV показывает цену отказа от обучения: обученные проекции немного точнее при одинаковой схеме обработки, но выпущенная версия SwiftKV в тесте на длинных документах фактически сравнялась с RidgeFill. Практический выбор сводится к тому, оправдывает ли небольшой выигрыш обучение и поддержку отдельного варианта модели.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
