Трехслойный планировщик приоритетов сокращает задержку локальной языковой модели с более чем одной секунды до менее чем двух десятых секунды, поддерживая отзывчивость чат-приложений даже тогда, когда телефон занят фоновыми задачами. Разработанный для чипа Tensor G3, работающего с моделью на 3 миллиарда параметров, он снижает задержку с 1420 мс до 161 мс, не прерывая фоновые процессы.
Почему локальные LLM работают с трудом
Запуск большой языковой модели на мобильном процессоре создает дефицит ресурсов. На Tensor G3 модель объемом 3 млрд параметров уже потребляет около 85 % возможностей нейронного процессора (NPU). Когда низкоприоритетная задача — например, офлайн-индексатор — выполняется одновременно с открытием пользователем окна чата, воспринимаемое время отклика возрастает примерно со 140 мс до 1400 мс — это десятикратное замедление, которое пользователи замечают мгновенно.
Проблема не только в скорости. Мобильные устройства должны балансировать между плавностью интерфейса, временем автономной работы и множеством приложений, запрашивающих вычислительные мощности. Наивная очередь, обрабатывающая задачи по порядку, заставляет поток пользовательского интерфейса ждать завершения фоновых работ, превращая разговорного ассистента в медлительный инструмент.
Как работает трехслойный планировщик
Новый планировщик встраивает в конвейер вывода (inference pipeline) три скоординированных компонента:
- Priority Queue (Очередь приоритетов) — min-heap (минимальная куча), которая упорядочивает входящие задачи по статическому уровню важности.
- Preemption Controller (Контроллер вытеснения) — при поступлении запроса с более высоким приоритетом он приостанавливает низкоприоритетные задачи вместо их отмены.
- Token Budget Governor (Регулятор бюджета токенов) — ограничивает количество токенов, которые может сгенерировать задача, в зависимости от состояния жизненного цикла приложения.
Вместе они позволяют запросу чата на переднем плане мгновенно переместиться в начало очереди, в то время как фоновые задачи остаются в режиме ожидания, готовые возобновиться, когда освободятся ресурсы.
Уровни приоритета и вытеснение
Четыре уровня определяют, что может быть прервано:
| Уровень | Описание |
|---|---|
| Чат на переднем плане | Критическое взаимодействие с интерфейсом |
| Встроенные подсказки | Подсказки в стиле автодополнения |
| Фоновое резюме | Периодическое обобщение контента |
| Офлайн-индексация | Массовая обработка данных |
Планировщик никогда не прерывает низкоприоритетную задачу. Вместо этого он делает снимок (snapshot) кэша пар «ключ-значение» (KV cache) модели — структуры, хранящей промежуточные результаты механизма внимания (attention), — и ставит задачу на паузу. Когда высокоприоритетный запрос завершается, контроллер восстанавливает снимок и позволяет фоновой задаче продолжить работу с того места, где она остановилась. Такой подход «пауза-возобновление» позволяет избежать дорогостоящих повторных вычислений, которые потребовались бы при перезапуске задачи с нуля.
Частичное вытеснение (eviction) KV-кэша дополнительно сокращает потери. Статический системный промпт остается в кэше, в то время как вытесняются только динамические реплики диалога. В результате затраты на повторное заполнение (re-prefilling) модели после паузы снижаются на 40–60 %.
Управление бюджетом токенов без таймеров
Многие реализации полагаются на таймеры, чтобы угадать, когда задача должна уступить время процессора или NPU. Таймеры — инструмент грубый: они могут либо лишить ресурсов интерфейс, либо привести к недоиспользованию чипа. Планировщик заменяет таймеры на Android-компонент ProcessLifecycleOwner, который генерирует события жизненного цикла, надежно указывающие, находится ли приложение на переднем или заднем плане.
- ON_RESUME — приложение восстанавливает полный вычислительный бюджет, позволяя ожидающим задачам на переднем плане выполняться беспрепятственно.
- ON_STOP — приложение ограничивает фоновые задачи примерно до 25 % от их обычного бюджета токенов, сохраняя запас мощности для любого внезапного запроса интерфейса.
Привязывая распределение ресурсов к событиям жизненного цикла, система реагирует на реальное поведение пользователя, а не на произвольные временные интервалы.
Прирост производительности и компромиссы
При использовании наивной очереди по принципу «первым пришел — первым обслужен» фоновая задача увеличивает задержку чата на переднем плане примерно до 1420 мс. С активным планировщиком приоритетов тот же запрос чата выполняется примерно за 161 мс — десятикратное улучшение, возвращающее плавность взаимодействия с пользователем.
Возобновление приостановленной задачи увеличивает общее время её выполнения примерно на 22 %. Поскольку фоновая работа не является критически важной, такой компромисс остается приемлемым, особенно если интерфейс остается быстрым.