Оптимизация LLM на устройстве для телефонных AI-агентов

Почему качество phone agent начинается с задержки, памяти и батареи

Пользователь редко думает о модели, когда просит телефон: «Открой маршрут, подготовь сообщение и напомни перезвонить». Он чувствует только одно: телефон понял быстро или заставил ждать. Для телефонного AI-агента задержка — это не сухая цифра в тесте, а пауза между намерением и видимым Android-действием. Если каждая команда начинает с нескольких секунд ожидания, доверие к агенту падает даже при хорошем ответе.

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

Google описывает Gemini Nano через Android AICore как путь к on-device generative AI для поддерживаемых сценариев: низкая задержка, приватные задачи и опыт без сети там, где устройство и функция это поддерживают. Для phone agent это важный сигнал: часть понимания и подготовки ответа может происходить ближе к пользователю, а не каждый раз ждать удаленного запроса.

Но быстрый локальный ответ сам по себе еще не завершает задачу. Агенту нужно открыть приложение, понять состояние экрана, подготовить текст, показать результат и запросить подтверждение для действия, которое влияет на другого человека, данные или настройку. В FoneClaw мы строим опыт именно вокруг этой цепочки: скорость важна, потому что она поддерживает видимое Android-действие, а не заменяет его.

Бенчмарк может сказать, что модель быстрая. Пользователь оценивает другое: «Сообщение подготовлено? Карта открылась? Напоминание создано? Я вижу, что будет отправлено?» Поэтому качество телефонного агента — это задержка плюс память, батарея, доступность, восстановление после сбоя и понятный момент подтверждения.

Размер модели, квантование и малые маршруты для Android-задач

Большая модель умеет больше рассуждать, но телефон не всегда выигрывает от максимального размера. В Android-сценариях часто нужны короткие операции: классифицировать уведомление, выделить имя контакта, подготовить одно предложение, понять команду «поставь таймер», выбрать следующий экран. Для таких задач маленькая или облегченная модель может дать лучший пользовательский опыт, потому что быстрее запускается и меньше нагружает устройство.

Квантование можно объяснить без формул: модель хранит и считает числа в более компактном виде, чтобы занимать меньше памяти и работать быстрее. Это может немного менять качество, зато помогает поместить модель на телефон и уменьшить расход энергии. Для phone agent это компромисс не между «умная» и «глупая», а между «достаточно точная для этого шага» и «слишком тяжелая для текущего устройства».

Адаптеры и маленькие специализированные маршруты решают похожую задачу. Вместо того чтобы каждый запрос отправлять в одну огромную модель, система может использовать легкий локальный путь для понятных действий: распознать команду, подготовить короткий ответ, сгруппировать уведомления, открыть приложение. Более сложный reasoning включается только там, где действительно нужно сопоставить много контекста или сформировать длинный план.

Apple в материале о обновлениях foundation models описывает эффективность on-device моделей через техники вроде KV cache sharing, квантования, адаптеров и разделения между локальной и серверной моделью. Это не Android-реализация, но хорошо показывает общую индустриальную логику: мобильный AI строится вокруг экономного распределения задач, а не только вокруг размера модели.

В FoneClaw такая логика проявляется в продукте просто: для короткого Android-действия пользователь должен получать быстрый и видимый шаг. Если нужно открыть приложение, подготовить одно сообщение или создать напоминание, агенту нужна точность в действии. Если задача сложная, маршрут может включать более глубокое рассуждение, но результат все равно возвращается к экрану телефона и поддерживаемому действию.

AICore, Gemini Nano, ML Kit GenAI, LiteRT и LiteRT-LM на практике

Чтобы локальная модель стала частью приложения, одной модели мало. Нужен путь выполнения на телефоне: как проверить поддержку устройства, где хранится модель, как она загружается, какие лимиты применяются, как приложение получает ответ и что происходит при первой команде. Для Android это пространство быстро развивается: AICore, Gemini Nano, ML Kit GenAI, Google AI Edge, LiteRT и LiteRT-LM дают разные маршруты для локального или гибридного AI.

ML Kit GenAI Prompt API описывает практичные детали: проверку доступности функции, поддержку Android-устройств, загрузку Gemini Nano, прогрев для уменьшения задержки первого вызова, лимиты токенов и квоты на приложение. Эти детали важнее, чем звучат. Если модель еще не загружена или первый вызов холодный, пользователь чувствует паузу. Если есть квота, продукт должен вести себя предсказуемо.

Google AI Edge объединяет инструменты для on-device ML и AI, включая MediaPipe task APIs, LiteRT и LiteRT-LM. Для разработчика это набор путей, а для пользователя — шанс получить локальные функции, которые работают быстрее, экономят сеть и лучше вписываются в телефонный контекст. Но поддержка зависит от устройства, ОС, модели, приложения и выбранного сценария.

LiteRT-LM показывает, какие метрики важны для on-device LLM: prefill, decode, время до первого токена, CPU/GPU backends, память и локальное выполнение модели. Эти слова звучат технически, но в phone agent они превращаются в обычные ощущения: насколько быстро агент начинает отвечать, насколько плавно продолжает, сколько памяти держит и не выталкивает ли другие приложения.

Соседняя тема — устройство, ОС и агентная архитектура в целом. Если нужно шире увидеть фундамент, полезна статья про трехслойная основа OS-агента. Здесь же ключевой вопрос узкий: как локальная модель реально попадает в Android-продукт и помогает телефонному действию состояться.

Кэш, прогрев и контекст: почему повторные действия ощущаются быстрее

В phone agent многие задачи повторяются. Пользователь утром просит сводку уведомлений, в дороге готовит ETA, вечером открывает список покупок. Если каждый раз модель заново обрабатывает весь контекст, телефон тратит время и батарею. Поэтому важны кэш, прогрев и разумная работа с контекстом.

Prefill — это этап, когда модель обрабатывает входной контекст перед генерацией. Decode — этап, когда она выдает ответ по токенам. Time to first token показывает, как быстро пользователь видит начало ответа. KV cache хранит промежуточные вычисления, чтобы при продолжении или похожем запросе не пересчитывать все с нуля. В интерфейсе это превращается в ощущение: агент быстрее продолжает знакомую задачу.

Warmup, или прогрев, нужен, чтобы первый вызов не был самым медленным. ML Kit GenAI Prompt API прямо документирует возможность warmup для уменьшения first-call latency. Для телефонного агента это важно перед сценариями, где пауза особенно заметна: голосовая команда, быстрый ответ, проверка уведомлений, подготовка сообщения. Пользователь ожидает, что телефон реагирует сейчас, а не «после подготовки».

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

В FoneClaw мы думаем о таких вещах через пользовательский маршрут. Агенту важно помнить достаточно, чтобы продолжить поддерживаемое Android-действие: какой экран открыт, что пользователь попросил, какой черновик подготовлен, где требуется подтверждение. Оптимизация кэша и прогрева ценна тогда, когда она делает эти повторяемые маршруты быстрее и понятнее.

Когда достаточно локального AI, а когда нужен облачный reasoning

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

Зрелый phone agent должен выбирать путь по задаче, а не по лозунгу. Если локальный маршрут дает быстрый и достаточный результат, он удобен. Если требуется глубокое рассуждение, облако может дать более сильный ответ. Если сеть слабая, локальный fallback сохраняет часть полезности. Если действие чувствительное, экран и подтверждение остаются центральными, независимо от того, где происходило рассуждение.

Apple Foundation Models framework показывает параллельное направление на другой платформе: on-device language model для задач Apple Intelligence, структурированный вывод и tool calling внутри приложений. Общая тенденция понятна: мобильные экосистемы хотят дать приложениям локальные языковые возможности и при этом сохранять маршрут к более мощным моделям там, где нужно.

Для FoneClaw гибридная логика выражается в видимом Android-действии. Пользователь просит: «Подготовь ответ», «Открой приложение», «Сделай сводку», «Напомни позже». Мы строим опыт так, чтобы результат появлялся на экране: черновик, открытое приложение, созданное напоминание, выбранный следующий шаг. Локальная скорость помогает, облачное рассуждение может поддержать сложную часть, а подтверждение связывает все с контролем пользователя.

Если хочется глубже сравнить локальный и облачный подход на уровне доверия и приватности, используйте отдельную страницу локальный и облачный AI-агент. Здесь фокус уже на оптимизации LLM на устройстве для телефонных AI-агентов: как сделать локальную часть достаточно быстрой, экономной и полезной для конкретного Android-действия.

Чек-лист оценки on-device LLM на телефоне

Когда производитель или приложение обещает on-device LLM, задайте не один вопрос «насколько модель умная?», а серию практических вопросов. Телефонный агент должен быть полезен в реальном использовании: быстро стартовать, беречь батарею, понятно вести себя без сети, показывать результат и восстанавливаться после ограничений.

• Поддержка устройства: работает ли функция на конкретной модели Android, версии ОС и регионе.
• Загрузка модели: нужно ли скачать Gemini Nano или другой локальный компонент, сколько это занимает и где видно состояние.
• Первый запуск: есть ли прогрев, заметна ли задержка первой команды.
• Память и батарея: не мешает ли локальная модель обычным приложениям и длительному использованию.
• Квоты и лимиты: есть ли per-app quota, лимиты токенов или ограничения на частоту вызовов.
• Сеть: какие задачи работают без подключения, а какие переходят к облачному маршруту.
• Экран: видит ли пользователь результат: черновик, действие, открытое приложение, ошибку или запасной шаг.
• Подтверждение: сообщения, настройки, платежи, доступ к данным и другие важные действия должны показывать, что именно будет сделано.

Для FoneClaw этот чек-лист сводится к опыту пользователя. Мы хотим, чтобы Android phone agent быстро понимал намерение, показывал следующий шаг и помогал завершить поддерживаемое действие. Если локальная модель ускоряет черновик, сводку или классификацию — отлично. Если требуется более сильное рассуждение, маршрут должен аккуратно перейти к подходящему пути и вернуться к видимому действию.

Связь с управление телефоном через AI-агента здесь прямая: LLM сама по себе не закрывает задачу. Пользователь оценивает завершенность: приложение открыто, сообщение подготовлено, напоминание создано, действие подтверждено, fallback понятен. Оптимизация на устройстве ценна ровно потому, что делает этот путь быстрее и надежнее.

Главная мысль: локальный AI — это не отдельная галочка в характеристиках. Это часть телефонного опыта, где модель, кэш, прогрев, квоты, батарея, сеть, Android-интерфейс и FoneClaw-supported actions складываются в действие, которое пользователь видит и контролирует.