Локальный запуск моделей (on-device)

Локальный запуск моделей (on-device) — это выполнение модели машинного обучения прямо на конечном устройстве: телефоне, ноутбуке, камере, терминале или встроенном контроллере, без обращения к удаленному серверу на каждый запрос. Подход полезен там, где важны приватность, работа без сети и предсказуемая задержка. Он плохо подходит для очень больших моделей, длинного контекста, тяжелого поиска по внешним данным, слабого железа и сценариев, где критичны централизованный контроль, единая телеметрия и быстрые обновления логики.

Простыми словами

Если серверный запуск означает: устройство отправило данные → сервер посчитал ответ → вернул результат, то on-device означает: устройство получило данные → само выполнило модель → показало результат. На практике это почти всегда означает локальный инференс, а не обучение. Обучать модели на устройстве можно лишь в узких случаях, но в продакшене это редкость из-за нагрузки на память, процессор и аккумулятор.

Типичные устройства для on-device: смартфоны, ноутбуки, браузеры, POS-терминалы, промышленные планшеты, камеры, автомобили и IoT-устройства. Типичные задачи: распознавание речи, классификация изображений, OCR, фильтрация текста, биометрия, автодополнение, локальные LLM-помощники.

Коротко: on-device — это не «любой AI вне облака», а именно запуск на конечном пользовательском устройстве. Локальный сервер в офисе или шлюз в цехе — это уже ближе к edge, но не обязательно on-device.

Как это работает

Технически локальный запуск состоит из нескольких шагов.

1. Выбирают задачу и бюджет ресурсов. Сначала определяют допустимую задержку, объем памяти, энергопотребление, необходимость офлайн-режима и требования к качеству. Для мобильного приложения и для промышленной камеры это будут разные бюджеты.
2. Берут компактную модель или уменьшают существующую. Если исходная модель слишком велика, применяют дистилляцию, квантование, иногда обрезку архитектуры или уменьшение контекста.
3. Конвертируют модель под конкретный рантайм. На практике используют форматы и среды вроде Core ML, LiteRT, ONNX Runtime или ExecuTorch. Это нужно, чтобы модель могла исполняться на CPU, GPU или NPU конкретного устройства.
4. Пакуют модель в приложение или скачивают один раз после установки. Первый вариант упрощает контроль версий, второй уменьшает размер приложения и позволяет обновлять модель отдельно.
5. Настраивают выполнение на железе. Один и тот же граф может работать на CPU, мобильном GPU или нейроускорителе. На реальных устройствах это влияет не только на скорость, но и на нагрев, разряд батареи и стабильность.
6. Управляют памятью и входными данными. Для генеративных моделей это особенно важно: токенизация, кэш внимания, длина контекста и буферы часто становятся главным ограничением раньше, чем «чистая» вычислительная мощность.
7. Делают обновления и откат. Локальная модель должна иметь версионирование, проверку совместимости, подпись артефактов и безопасный fallback, если конкретное устройство не тянет новый релиз.

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

Зачем нужно

• Офлайн-работа. Если сеть нестабильна или ее нет, локальный запуск позволяет не ломать пользовательский сценарий.
• Меньше передачи чувствительных данных. Аудио, изображения документов, биометрия и черновики текста можно не отправлять на сервер для каждого запроса.
• Предсказуемая задержка. Нет сетевого round trip на каждый вызов, а значит меньше случайных провалов из-за канала и перегрузки бэкенда.
• Снижение нагрузки на инфраструктуру. Часть вычислений переносится на клиентское устройство, что особенно заметно в массовых потребительских сценариях.
• Устойчивость к разрывам связи. Приложение может продолжать выполнять базовые функции при проблемах с облаком.

Сценарий	Подходит ли on-device	Почему
Оффлайн-камера, мобильное приложение, полевой планшет	Да	Нужна работа без сети и малая задержка
Обработка персональных данных на устройстве	Часто да	Можно сократить передачу исходных данных на сервер
Корпоративный чат с большой LLM и длинным контекстом	Скорее нет	Высокие требования к памяти, вычислениям и контролю версии
Система, где логика меняется ежедневно	Скорее нет	Сложнее быстро и одинаково обновлять парк устройств

Иными словами, on-device — это не «замена облака вообще», а способ отдать на устройство ту часть вычислений, которая действительно выигрывает от близости к данным и автономности.

Пример

Практический сценарий: сервисная команда делает Android-приложение для инспекции оборудования в цехе, где сеть нестабильна. Техник фотографирует узел, а приложение должно сразу показать один из трех статусов: норма, подозрение на дефект, нужна ручная проверка.

1. Модель обучают централизованно на сервере, потому что для обучения нужны датасеты и контроль качества.
2. Для мобильного запуска выбирают более компактную версию и квантование, чтобы уложиться в память планшета.
3. Модель конвертируют в мобильный формат и встраивают в приложение либо догружают при первом запуске.
4. Инференс выполняется локально: фото не нужно отправлять в облако ради первичной оценки.
5. Если связь есть, приложение отправляет только итоговый статус, служебные метаданные и, при необходимости, снимок для аудита.
6. Если устройство перегрето или памяти не хватает, приложение должно уметь отключить локальную модель и перейти в деградированный режим: просто сохранить снимок и отложить анализ.

Почему здесь on-device оправдан: технику нужен ответ сразу, сеть может пропадать, а передавать каждый кадр в облако неудобно и не всегда допустимо. Почему здесь все равно нужен сервер: для обучения, контроля качества модели, журналирования инцидентов и обновления версии.

Заблуждения и ограничения

• «Локально» не значит «автоматически безопасно». Если приложение пишет сырые данные в логи, кэширует их без шифрования или хранит модель с секретами, приватность все равно нарушается.
• On-device не всегда быстрее. Загрузка модели, cold start, токенизация, разогрев графа и троттлинг из-за температуры могут сделать локальный запуск медленнее ожидаемого.
• Один билд не работает одинаково везде. Разные чипы, объем RAM, версии ОС и драйверы нейроускорителей сильно усложняют тестирование и поддержку.
• Большие генеративные модели остаются проблемой. Даже если модель формально запускается, длина контекста, скорость генерации, расход памяти и батареи могут сделать продукт непригодным.
• Локальный запуск не отменяет бэкенд. Обычно все равно нужны раздача моделей, телеметрия, мониторинг ошибок, A/B-проверки, откат версий и политика обновлений.
• Не каждая задача выигрывает от on-device. Если данные уже живут на сервере, а задержка сети не критична, вынос модели на устройство может только усложнить систему.

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

Частые вопросы

Можно ли запускать большие языковые модели локально на телефоне?

Можно, но обычно только небольшие или сильно оптимизированные версии и с заметными компромиссами: меньше контекст, ниже скорость, выше расход памяти и батареи. Для крупных LLM on-device часто выступает как вспомогательный режим, а не как полная замена сервера.

Чем on-device отличается от edge computing?

On-device — это выполнение на конечном устройстве пользователя или оператора. Edge — более широкое понятие: вычисления могут идти на ближайшем шлюзе, локальном сервере, промышленном ПК или базовой станции. Всякий on-device — это edge-сценарий, но не всякий edge — on-device.

Нужен ли интернет для локального запуска?

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

Можно ли обновлять модель без релиза всего приложения?

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

Связанные понятия

• Инференс — выполнение уже обученной модели на новых данных.
• Квантование — уменьшение точности весов и активаций ради экономии памяти и ускорения выполнения.
• Дистилляция — перенос поведения большой модели в более компактную.
• Edge computing — вычисления ближе к источнику данных, не обязательно на самом пользовательском устройстве.
• NPU — специализированный нейроускоритель в мобильных и встроенных чипах.
• RAG — схема, где модель опирается на внешний поиск по данным; для чистого on-device она часто тяжела из-за индекса, памяти и обновлений базы.

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