Журнал · Rit.work

EncBank сохраняет обработанные документы между запросами к LLM

EncBank сохраняет состояния документов в четырёхбитном виде: постоянное хранилище сокращается, но выгода зависит от повторных запросов, длины ответа и допустимой потери качества.

Rit.work
Студия разработки
8 октября 2026 г.3 мин чтения

Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.

Один и тот же документ можно не прогонять через всю LLM заново при каждом запросе. Хотя работу не рецензировали и все числа в ней получили сами авторы, в опыте Tsinghua University постоянное хранилище EncBank занимало 28,1% объёма варианта с исходной точностью. Такой подход может сократить расходы на коллекции документов, но не гарантирует столь же заметного ускорения ответа.

Как EncBank превращает нижние слои модели в энкодер

Обычная система с поиском сначала выбирает подходящие фрагменты, а затем при каждом запросе снова проводит их через все слои модели. Полный кеш ключей и значений сохраняет больше вычислений, но требует хранить состояния внимания для каждого слоя и каждого токена.

EncBank проводит документ только через нижнюю часть модели и сохраняет одно остаточное состояние на токен. Когда приходит запрос, поиск BM25 выбирает подходящие фрагменты, система восстанавливает их состояния и передаёт в верхние слои вместе с запросом. В опытах документ делили на фрагменты длиной до 512 токенов, а на чтение выбирали не более 12 фрагментов.

Верхние слои нельзя использовать без подготовки. Независимая обработка фрагментов меняет состояния по сравнению с непрерывным чтением документа, поэтому авторы обучили для верхней части модели адаптер LoRA. Нижние слои и основные веса оставались замороженными, а один адаптер работал со всеми вариантами точности хранения.

Глубина разделения и точность решают разные задачи. Чем больше нижних слоёв выполняют работу заранее, тем меньше вычислений остаётся на запрос, но тем сильнее может измениться ответ. Снижение точности уменьшает постоянное хранилище, однако не сокращает веса модели, временные буферы и кеш текущего запроса.

Экономия памяти не переносится на задержку один к одному

На основной модели Qwen3-8B четырёхбитное хранение осталось в пределах одного балла от исходной точности во всех пяти наборах испытаний. Это сводные результаты: на отдельных длинах контекста и отдельных задачах разница была больше, поэтому близкие средние оценки не означают одинаковых ответов.

Повторное использование состояний ускорило предварительный проход (prefill) в 1,40 раза по сравнению с повторным чтением тех же фрагментов тем же адаптером. За это модель потеряла 3,12 балла на RULER. Замер скорости не включал запись документа, поиск, загрузку состояний и генерацию ответа; с учётом генерации преимущество сокращалось.

Четырёхбитный формат также не дал пропорционального снижения памяти во время запроса. Постоянные состояния стали компактнее, но в памяти по-прежнему находились веса, восстановленные фрагменты и рабочий кеш генерации. В тёплом сценарии обычная обработка полного контекста отвечала быстрее, хотя требовала больше постоянного места.

Работу проверяли на трёх базовых моделях Qwen и задачах на поиск, длинный контекст, ответы по документам, память диалога и работу агента в терминале. Основные контролируемые сравнения сосредоточены на одной модели; для гибридных архитектур связь между контрольными точками, оценщиками и вариантами точности описана менее полно. Глубину повторного использования и точность хранения авторы изучали раздельно, поэтому их выигрыши нельзя складывать.

Планы меняются для стабильных и часто используемых коллекций

EncBank имеет смысл закладывать в архитектуру, если документы меняются редко, а к одним и тем же материалам обращаются многократно. Подготовка состояний оплачивается заранее, поэтому единичный запрос скорее проиграет обычному чтению текста. В одном из сценариев для документа на 32 тыс. токенов подготовка окупалась после 9–11 коротких запросов, но этот расчёт относится к хранению с исходной точностью, а не к четырёхбитному варианту.

Метод хуже подходит задачам, где ответ требует просмотреть всю коллекцию или собрать сведения из большого числа частей. Онлайн-расходы ограничивает поиск: верхние слои видят только выбранные фрагменты. Это удерживает рабочую память под контролем, но превращает полноту поиска в предел качества всей системы.

Для команды практический следующий шаг — не заменять текущий конвейер целиком, а измерить повторное использование на собственном трафике. Нужны три раздельных бюджета: подготовка документа, постоянное хранилище и стоимость запроса с генерацией. Если документы быстро устаревают, ответы длинные или запросы редко повторяются, компактные состояния могут не успеть окупить запись и адаптацию верхних слоёв.

EncBank показывает рабочую промежуточную точку между хранением исходного текста и полным кешем всех слоёв. Она сокращает объём постоянных состояний и часть повторных вычислений, но переносит архитектурный риск в адаптер, поиск фрагментов и частоту повторного использования.

Источники

Пауза в чтении

Похоже на вашу задачу?

Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.

Rit.work

Студия разработки

Собираем мобильные приложения и помогаем командам получать от AI реальную пользу. Основатель и команда, работаем удалённо — с клиентами в России и за рубежом.

← Ко всем материалам
Понравилось? Обсудим вашу задачу