Препринт HybridInfer предлагает учитывать нагрев смартфона не только как ограничение производительности, но и как входной сигнал для маршрутизатора языковых моделей. Система выбирает, где выполнять очередной запрос: на самом устройстве, на периферийном сервере или в облаке. По данным автора работы, такой подход на реальном Android-устройстве оказался быстрее и надёжнее постоянного локального инференса, сохранив при этом бонус за обработку данных на телефоне.
Работа опубликована на arXiv 28 сентября 2026 года. Это препринт, а не независимое сравнительное исследование: заявленные результаты относятся к эксперименту авторов на конкретной конфигурации оборудования и программного стека. Страница работы, PDF-версия и HTML-версия доступны на arXiv.
Локальный инференс столкнулся не только с троттлингом
В центре исследования — сценарий с последовательными запросами к небольшой языковой модели на смартфоне с флагманской платформой Snapdragon. Автор описывает проблему как более серьёзную, чем обычное снижение частоты GPU при нагреве: после нескольких подряд запросов локальный рантайм может аварийно завершиться или перейти в состояние, при котором генерация фактически останавливается.
Особенно проблемными названы длинные генерации и длинный этап предварительной обработки контекста — prefill. В работе сбои связываются с текущим программным стеком, включая компиляцию ядер OpenCL и выполнение prefill на мобильном GPU. При этом автор сообщает, что проблема воспроизводилась даже на остывшем устройстве. Следовательно, один только датчик температуры не объясняет все отказы: нестабильность может быть связана с особенностями реализации инференса и характером нагрузки.
Это важное уточнение для разработчиков локальных приложений. Низкая температура корпуса или отсутствие заметного системного предупреждения ещё не гарантируют, что длинная серия запросов будет обработана без сбоев. Однако препринт не позволяет распространить этот вывод на все смартфоны Snapdragon, версии драйверов или мобильные рантаймы: в описании приведён конкретный экспериментальный стенд, а не массовый тест устройств.
Три уровня для одного запроса
HybridInfer использует иерархию из трёх вариантов выполнения:
- on-device — Llama 3.2 3B работает непосредственно на смартфоне;
- edge — Llama 3.1 8B с механизмом поиска по внешним данным запускается на расположенном рядом сервере;
- cloud — запрос передаётся модели GPT-4o через облачное API.
Маршрутизатор получает два основных сигнала: оценку теплового запаса телефона и приблизительную сложность запроса. Затем политика выбирает один из трёх уровней. В отличие от простого правила вроде «при высокой температуре отправлять всё в облако», система должна балансировать несколько конфликтующих целей.
В функции награды учитываются качество ответа, задержка, стоимость и тепловая нагрузка. Отдельно добавлен бонус локальности — дополнительное поощрение за выполнение запроса на самом устройстве. Такой компонент нужен не только для конфиденциальности. Без него, как утверждает автор, оптимальная политика начинает отправлять все запросы на удалённые уровни: облако или edge проще использовать для получения качества и снижения нагрузки на телефон.
Это один из главных результатов работы. Тепловая осведомлённость сама по себе не означает «чаще использовать локальную модель». Если функция награды не оценивает локальность, агент выберет удалённые варианты почти во всех случаях. Поэтому поведение HybridInfer определяется не одним датчиком, а тем, как разработчик формулирует компромисс между качеством, задержкой, ценой и приватностью.
Q-learning обучается заранее
Для обучения использован offline Q-learning. Политика не должна самостоятельно исследовать варианты на пользовательских запросах: она обучается на заранее собранных данных, а затем применяется как механизм выбора тира. Такой дизайн потенциально удобнее для мобильных приложений, чем онлайн-обучение, при котором экспериментальные действия выполнялись бы непосредственно на устройстве.
Но у подхода есть практическое ограничение. Оценка сложности запроса и заранее заданная функция награды становятся критически важными. Ошибка в классификации может отправить простой запрос на дорогой облачный уровень или, наоборот, передать длинную задачу небольшой локальной модели, которая работает медленно и рискует столкнуться с нестабильностью рантайма.
В описанном эксперименте маршрутизатор сравнивался с двумя вручную настроенными эвристиками. Эти правила также могли выбирать между уровнями, но не использовали такой же обучаемой политики с тепловым состоянием в качестве части контекста.
Что показал тест на 210 промптах
Оценка проводилась на 210 промптах на реальном Android-устройстве. По данным препринта, HybridInfer продемонстрировал статистически значимое преимущество по качеству над двумя ручными эвристиками: для парного теста Уилкоксона автор приводит значение p < 0,02. При этом адаптивный маршрутизатор показал наименьшую стоимость среди проверенных адаптивных условий.
Абсолютные значения задержки, стоимости и качества в кратком описании работы не приводятся, поэтому результат нельзя интерпретировать как универсальный процентный выигрыш. Речь идёт о сравнении конкретных условий эксперимента и конкретного набора запросов.
Постоянный запуск Llama 3.2 3B на смартфоне сохранял сопоставимое качество на тех запросах, которые устройство вообще могло обслужить. Но такой режим, согласно автору, занимал в три-шесть раз больше времени и чаще не справлялся с длинными запросами. Преимущество HybridInfer поэтому заключается не в том, что локальная модель внезапно стала отвечать лучше. Выигрыш достигается за счёт покрытия большего числа запросов, снижения задержки и уменьшения числа отказов при серийной нагрузке.
Облачная модель, в свою очередь, не является бесплатной заменой локальному инференсу: она требует сетевого соединения, может увеличивать стоимость и меняет модель обработки пользовательских данных. Edge-уровень занимает промежуточное положение, но его эффективность зависит от доступности сервера, сетевой задержки и конкретной реализации поиска по данным.
Что это меняет для разработчиков
Главный практический вывод HybridInfer — мобильный LLM-рантайм стоит проектировать как систему с несколькими уровнями отказоустойчивости. Проверять нужно не только среднюю скорость одного запроса, но и поведение после серии генераций, на длинном контексте и при длительной работе GPU. Отдельный тест должен фиксировать, что происходит после сбоя: приложение корректно переключается на другой уровень, повторяет запрос или оставляет пользователя без результата.
При внедрении похожего роутера разработчику также потребуется заранее определить, какие запросы допустимо отправлять на сервер. Тепловой запас может подсказать, где выполнять инференс, но не решает вопросы приватности, сетевой доступности и согласия пользователя. Локальность в HybridInfer встроена в функцию награды, однако это не доказывает, что конкретное приложение будет обрабатывать данные на устройстве чаще или безопаснее без собственной настройки политики.
Наконец, результаты пока следует считать предварительными. В препринте заявлен тест на одном Android-бенчмарке, а независимая проверка на разных чипах, драйверах, моделях и версиях мобильных рантаймов в представленном материале не показана. Перед публикацией приложения разработчикам стоит отдельно проверить длинный prefill, серию последовательных запросов и корректность переключения между on-device, edge и cloud-сценариями — именно там HybridInfer обнаруживает наиболее заметную разницу с постоянным локальным запуском.
