Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
TierKV позволяет мобильной LLM удерживать более длинный контекст в доступной памяти, не выбрасывая старые токены. В препринте University of Georgia, Peking University и Western Digital Research максимальная длина контекста при прежнем бюджете памяти выросла до 2,6 раза, хотя работа ещё не рецензирована и замеры провели сами авторы. Это делает локальный поиск по документам и обработку изображений реалистичнее на устройствах, где раньше контекст приходилось обрезать или переносить вычисления в облако.
Почему длинный контекст заполняет память смартфона
Во время генерации модель хранит KV-кэш: ключи и значения механизма внимания для всех уже обработанных токенов. Благодаря этому модель не пересчитывает прошлый контекст для каждого нового токена, но объём кэша растёт линейно вместе с историей диалога, документами и промежуточными рассуждениями.
На протестированном OnePlus 12 приложениям стабильно доступно около 6,8 ГБ оперативной памяти после резервов Android и системы. Контекст Llama-3.2-3B длиной 32 тысячи токенов занимает около 1,8 ГБ только под KV-кэш — без весов модели и рабочих буферов. Если приложение выходит за безопасный предел, Android может завершить его вместо постепенного замедления.
Обычные способы экономии переносят проблему в другое место. Удаление токенов необратимо стирает часть контекста, выгрузка всего кэша во флеш-память задерживает каждый шаг генерации, а равномерное низкоранговое сжатие добавляет вычисления и может резко ухудшить ответы на задачи, где важны ранние фрагменты запроса.
Как TierKV выбирает место для каждого фрагмента кэша
TierKV планирует размещение до начала генерации. Самые чувствительные токены система хранит без изменений в RAM, основную часть контекста держит там же в сокращённом виде, а длинный хвост переносит во флеш-память. Полный контекст остаётся доступен: система меняет форму и место хранения данных, но не удаляет их.
Сокращённый уровень использует сингулярное разложение — способ представить матрицу через её главные направления и отбросить менее значимые компоненты. Степень сжатия различается между слоями модели. Её заранее калибруют по структуре KV-кэша, не меняя веса и не переобучая модель.
Перед генерацией LLM сначала обрабатывает весь запрос на этапе предзаполнения. TierKV повторно использует уже рассчитанные скрытые состояния, оценивает неопределённость модели на разных токенах и сопоставляет запрос с локальной историей похожих обращений. Так система прогнозирует будущую длину последовательности без отдельной модели-предсказателя.
Затем решатель выбирает границы между точным, сжатым и выгруженным уровнями с учётом доступной памяти и допустимой потери качества. Это отличает TierKV от фиксированной настройки: простой запрос не получает лишний запас, а сложный не сжимается по тем же правилам только потому, что так настроено приложение.
Во время декодирования отдельные вычислительные пути обрабатывают разные части кэша. Восстановление сокращённых данных совмещается по времени с чтением из флеш-памяти, поэтому процессор не обязан сначала ждать ввод-вывод, а затем выполнять матричные операции. Полноразмерная промежуточная копия кэша также не создаётся.
Когда результат меняет планы мобильного продукта
TierKV проверили на 8 текстовых, визуальных и аудиомоделях и на 3 мобильных системах с GPU семейств Adreno и Mali. Предзаполнение работало до 1,6 раза быстрее llama.cpp и до 17,6 раза быстрее MNN-LLM, а KV-кэш в оперативной памяти сократился на 12,5–34%. В сравнение также входил MLC-LLM; качество ответов при выбранных системой настройках ухудшалось незначительно.
Границы этих результатов заданы мобильным сценарием: модели использовали разные схемы внимания, но исполнялись на смартфонных GPU, а не на серверных ускорителях. Работа измеряет скорость, память и качество; она не сравнивает совокупную стоимость локального исполнения с облачным API.
Для локального поиска по документам, мультимодального помощника или автономного приложения результат снимает один архитектурный запрет: нехватка RAM больше не обязательно требует обрезать контекст. Если продукт уже упирается именно в KV-кэш, имеет смысл проверить многоуровневое размещение до перехода на меньшую модель или обязательный серверный резерв.
Интеграция при этом не сводится к изменению параметра API. Понадобятся калибровка конкретной модели, контроль над форматом KV-кэша, специализированные ядра для мобильного GPU и планировщик чтения из флеш-памяти. Для коротких запросов или облачной архитектуры выигрыш может не оправдать этот системный слой, но для длительной локальной сессии TierKV меняет оценку технической реализуемости.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
