В последние годы локальные LLM (on-device LLM) стали заметной альтернативой облачным ИИ-системам в мобильных приложениях.
Если говорить просто, локальная LLM — это языковая модель, которая работает непосредственно на устройстве пользователя (смартфоне или планшете), не отправляя запросы на удалённый сервер.
Такой подход даёт ощутимые преимущества: защита конфиденциальности, работа в офлайн-режиме, низкая задержка и меньшая зависимость от облачных API.
Вместе с тем он сопряжён с существенными ограничениями: ограниченный размер модели, потребление памяти, производительность устройства, расход батареи, сложность обновлений и — в ряде случаев — более низкое качество ответов по сравнению с крупными облачными моделями.
Эта статья — не руководство по написанию кода, а практический гид для бизнеса, который хочет разобраться в особенностях разработки on-device LLM и принять взвешенное решение о целесообразности её внедрения.
Что такое локальная LLM в мобильном приложении?
Локальная LLM — это языковая модель на базе ИИ, которая работает полностью на устройстве пользователя, а не в облаке. Этот процесс называется on-device inference («локальный инференс»): модель обрабатывает входные данные и генерирует ответы непосредственно на устройстве, без обращения к сети.
В отличие от облачных LLM — например, типичных чат-систем на основе API — локальные модели не отправляют пользовательские запросы на удалённые серверы: вся обработка происходит локально.
Локальный инференс становится всё более востребованным в мобильной разработке: современные смартфоны оснащены мощными процессорами CPU, GPU и NPU, способными эффективно запускать высокопроизводительные ИИ-модели.
| Подход | Где работает модель | Лучше всего подходит для | Основные ограничения |
| Облачная LLM | Удалённый сервер / API | Сложных задач рассуждения, крупных моделей | Передача данных, задержка, стоимость API |
| Локальная LLM | Устройство пользователя | Защиты конфиденциальности, офлайн-режима, быстрых простых задач | Аппаратные ограничения |
| Гибридная LLM | Устройство + облако | Сбалансированной производительности | Более сложная архитектура |
Ключевые различия между типами LLM: простое сравнение
Когда имеет смысл использовать on-device LLM?
Для компаний локальные LLM — это не обязательно замена облачным ИИ-системам. Они наиболее эффективны в продуктах, где конфиденциальность, офлайн-функциональность, низкая задержка, контроль затрат или соответствие регуляторным требованиям играют ключевую роль.
Типичные сценарии использования: офлайн-ИИ-ассистенты для мобильных пользователей, приватные чат-боты в банковских, медицинских и юридических приложениях, локальное суммаризирование документов, интеллектуальный поиск по данным внутри приложения, инструменты личной продуктивности, приложения для выездного обслуживания без стабильного доступа к интернету, а также корпоративные приложения, работающие с конфиденциальными внутренними данными.
Вместе с тем было бы ошибкой считать локально развёрнутую модель оптимальным выбором во всех перечисленных случаях. Облачные модели нередко демонстрируют более высокий уровень рассуждений, обладают более обширными знаниями и проще масштабируются — поэтому всё определяется конкретной ситуацией.
Выбор модели для интеграции LLM в мобильное приложение
Выбор модели — одно из ключевых решений при интеграции LLM в мобильное приложение.
От него зависят производительность приложения, качество ответов, потребление памяти, расход батареи, совместимость с мобильными фреймворками и долгосрочные затраты на сопровождение.
Универсально «лучшей» модели для любого проекта не существует: оптимальный выбор определяется бизнес-задачей, целевыми устройствами, требованиями к офлайн-работе и ожиданиями в части конфиденциальности.
Для мобильных приложений компании, как правило, рассматривают семейства моделей, обеспечивающих баланс между качеством и эффективностью, — а не самые крупные из доступных. На практике компактные и квантизованные модели чаще оказываются реалистичным выбором для смартфонов и планшетов: они снижают потребление оперативной памяти и ускоряют инференс.
Модели Mistral нередко рассматриваются компаниями, которым нужна сбалансированная универсальная производительность для мобильных ассистентов или функций суммаризации. Компактные варианты Mistral могут обеспечить приемлемый компромисс между качеством и потреблением ресурсов — особенно в сочетании с техниками квантизации.
Семейство Phi традиционно привлекает внимание в сценариях с лёгкими мобильными нагрузками, где эффективность важнее сложного рассуждения. Эти модели часто рассматриваются для классификации, структурированных выводов и простых диалоговых задач, требующих быстрого локального инференса на устройствах среднего класса.
Модели Gemma представляют интерес для проектов в области мобильного и периферийного ИИ — во многом благодаря широкой экосистеме Google в этих сегментах. Компаниям, рассматривающим внедрение нативных ИИ-функций на Android, стоит обратить внимание на Gemma в тех случаях, когда важна совместимость с инструментами, ориентированными на эту платформу.
Модели на базе Llama сохраняют популярность благодаря обширной экосистеме, гибким вариантам развёртывания и широкой доступности квантизованных версий. Они широко применяются в прототипах, кастомных ассистентах и RAG-приложениях.
При этом компаниям не стоит принимать решения, опираясь исключительно на результаты бенчмарков или теоретические заявления о производительности. Реальная производительность на мобильных устройствах во многом определяется стратегией квантизации, длиной контекста, совместимостью с фреймворком, целевым железом, тепловым троттлингом и требованиями к качеству конечного продукта.
Если необходимы конкретные метрики — скорость генерации токенов, требования к оперативной памяти, энергопотребление или размер модели — их следует проверять силами инженерной команды либо на основе актуальных источников с бенчмарками и тестирования на реальных устройствах.
| Семейство моделей | Сильные стороны | Возможные сценарии использования на мобильных устройствах | Что проверить перед интеграцией |
| Mistral | Высокая универсальная производительность, эффективные компактные модели | Ассистенты, суммаризация, вопросы и ответы | Лицензия, квантизованные версии, потребление памяти |
| Phi | Компактные модели, оптимизированные для лёгких задач | Простые ассистенты, классификация, структурированные ответы | Качество на целевых задачах, совместимость с устройствами |
| Gemma | Семейство открытых моделей Google, ориентированных на граничные сценарии | Нативные мобильные ИИ-функции, офлайн-ассистенты | Поддерживаемые среды выполнения, размер модели, бенчмарки |
| Llama | Обширная экосистема, множество квантизованных вариантов | Кастомные ассистенты, RAG-системы, корпоративные прототипы | Лицензия, совместимость с GGUF / Core ML / MLC |
Сравнение моделей для интеграции LLM в мобильные приложения
Фреймворки для запуска LLM на iOS и Android
Для развёртывания LLM на мобильных устройствах разработчики, как правило, используют специализированные фреймворки для инференса, оптимизирующие производительность и потребление памяти.
Выбор фреймворка влияет на сложность интеграции, совместимость с моделями, кроссплатформенную поддержку, оптимизацию производительности и долгосрочную поддерживаемость решения.
llama.cpp широко применяется для локального инференса LLM в различных аппаратных средах. Фреймворк пользуется популярностью при запуске квантизованных GGUF-моделей и создании кастомных прототипов благодаря гибкости и широкой поддержке моделей.
Компании нередко рассматривают llama.cpp, когда им нужен более полный контроль над развёртыванием и оптимизацией. Однако успешная интеграция в продакшн, как правило, требует значительной настройки: потребления памяти, многопоточности, теплового режима и стабильности UX на мобильных устройствах.
MLC-LLM ориентирован на кроссплатформенное развёртывание и оптимизированный нативный инференс для различных типов устройств. Он наиболее актуален для компаний, стремящихся к единой стратегии развёртывания на iOS и Android без платформенной фрагментации.
Для команд, планирующих долгосрочную мультиплатформенную поддержку ИИ, MLC-LLM способен упростить часть процессов развёртывания.
Core ML — фреймворк машинного обучения Apple для запуска ИИ-моделей на устройствах компании. Он хорошо подходит для iOS-ориентированных продуктов благодаря тесной интеграции с аппаратным ускорением Apple и системными оптимизациями.
Компании, разрабатывающие приложения преимущественно для экосистемы Apple, могут выбрать Core ML для повышения производительности, снижения энергопотребления и обеспечения совместимости с нативными функциями iOS.
Google AI Edge — инструменты такие как MediaPipe и LiteRT-LM — становятся всё более востребованными для запуска ИИ непосредственно на устройствах. Они разработаны для выполнения ИИ-задач на мобильном оборудовании, однако уровень поддержки и готовность к продакшну следует оценивать отдельно — с учётом конкретных требований проекта и целевых устройств.
Эти технологии предназначены для обработки ИИ-задач на мобильном оборудовании, однако компаниям всё равно следует проверять поддержку фреймворка, совместимость и готовность к продакшну применительно к конкретному проекту и целевым устройствам.
На практике выбор фреймворка редко определяется одним фактором. Как правило, компании оценивают следующие критерии:
- Целевые платформы и охват устройств
- Поддерживаемые форматы моделей
- Производительность инференса
- Сложность интеграции
- Долгосрочная поддерживаемость
- Совместимость со стратегиями квантизации
- Наличие инженерной экспертизы
Как организовать RAG на устройстве
Многим мобильным ИИ-приложениям недостаточно одной языковой модели. Если приложение должно отвечать на вопросы на основе корпоративных документов, внутренних баз знаний, пользовательских файлов или другого структурированного контента, как правило, требуется архитектура RAG (Retrieval-Augmented Generation — генерация с дополнением извлечением).
RAG позволяет модели извлекать релевантную информацию из подключённых источников данных перед формированием ответа. Вместо того чтобы опираться исключительно на внутренние знания модели, приложение может работать с реальными бизнес-данными, документами или контентом, специфичным для конкретного пользователя.
В мобильных приложениях on-device RAG может включать хранилище документов на устройстве, эмбеддинги, сгенерированные локально или предварительно вычисленные, облегчённый векторный поиск, управление доступом и синхронизацию с серверными системами.
Вместе с тем не все данные обязательно должны оставаться на устройстве. Многие компании используют гибридный подход к RAG: чувствительные или часто используемые данные хранятся локально, тогда как более объёмные базы знаний остаются в облаке.
On-device RAG особенно полезен в корпоративных приложениях с офлайн-доступом к инструкциям, медицинских или юридических приложениях с конфиденциальными документами, программном обеспечении для выездного обслуживания в удалённых средах, а также в корпоративных ассистентах, подключённых к внутренним базам знаний.
В этих сценариях локальное извлечение данных помогает защитить конфиденциальность, снизить зависимость от интернет-соединения и уменьшить задержку.
Однако компаниям следует учитывать и ограничения локальных RAG-систем. Документы, эмбеддинги и векторные индексы могут существенно увеличивать требования к хранилищу и негативно влиять на расход батареи и производительность устройства. Синхронизация данных также может усложняться при частом обновлении информации.
Когда on-device RAG оправдан:
- Корпоративные приложения с офлайн-доступом к руководствам и регламентам
- Медицинские или юридические приложения с конфиденциальными документами
- Инструменты для выездного обслуживания в удалённых средах
- Корпоративные ассистенты с доступом к внутренним базам знаний
Ограничения on-device RAG:
- Ограниченный объём хранилища
- Накладные расходы на индексирование и генерацию эмбеддингов
- Повышенное энергопотребление
- Сложность синхронизации данных
- Ограничения контекстного окна
- Необходимость продуманного UX при низкой уверенности модели в ответе
Аппаратные требования для запуска локальных LLM на мобильных устройствах
Возможность запуска больших языковых моделей на мобильных устройствах во многом определяется аппаратными характеристиками: пользовательский опыт напрямую зависит от объёма памяти, вычислительной мощности и энергоэффективности.
Начинайте проектирование с памяти (RAM). Убедитесь, что модель и среда выполнения без проблем помещаются в доступную память на наименее производительных из целевых устройств. Если это условие не выполнено, приложение будет работать нестабильно или окажется неработоспособным — вне зависимости от качества модели.
Уделяйте особое внимание вычислительной мощности. CPU, GPU и особенно специализированные ИИ-ускорители (NPU) напрямую влияют на скорость ответа и энергоэффективность.
На практике это означает, что на устройствах среднего класса и старых моделях следует всегда закладывать более низкую производительность — даже если на флагманских устройствах всё работает корректно.
Тщательно контролируйте энергопотребление. Непрерывный инференс быстро разряжает батарею, и пользователи замечают это сразу. Если сценарий предполагает длительные сессии, заранее планируйте агрессивную оптимизацию или ограничьте частоту обращений к модели.
Не недооценивайте влияние на хранилище. Локальные модели увеличивают размер приложения, что может снижать конверсию при установке и создавать трудности при загрузке или обновлении.
Учитывайте тепловое поведение устройства. При перегреве мобильные устройства снижают производительность: приложение, которое работает быстро в начале, может замедляться при длительном использовании. Это необходимо учитывать при проектировании UX и формировании ожиданий по производительности.
Принимайте во внимание различия на уровне операционных систем, поскольку доступные API и возможности аппаратного ускорения варьируются в зависимости от версии ОС и производителя устройства.
| Фактор | Почему это важно для бизнеса |
| RAM / доступная память | Определяет, сможет ли модель работать без сбоев |
| CPU / GPU / NPU | Влияет на скорость ответа и энергопотребление |
| Энергопотребление батареи | Влияет на пользовательский опыт и удержание аудитории |
| Возраст устройства | На старых устройствах может потребоваться переход на более компактные модели или облачный фолбэк |
| Хранилище | Локальные модели существенно увеличивают размер приложения |
| Тепловые ограничения | При длительных сессиях производительность может деградировать |
| Версия ОС | Влияет на доступные API и поддержку фреймворков |
Аппаратные требования для локальных LLM: сводная таблица
Ключевые сложности разработки, к которым нужно быть готовым
Интеграция локальных LLM в мобильные приложения сопряжена с рядом стратегических и технических сложностей: приложение перестаёт опираться на централизованную и масштабируемую облачную инфраструктуру.
- Ограничения по размеру модели и приложения — например, приложение-чат-бот может стать тяжелее на сотни мегабайт после добавления квантизованной модели.
- Компромиссы при оптимизации производительности и квантизации — например, уменьшение размера модели для запуска на Android-устройствах среднего класса может несколько снизить качество ответов.
- Фрагментация устройств на iOS и Android — например, ИИ-функция может отлично работать на новом iPhone, но медленно — на старых Android-устройствах.
- Платформенные различия в реализации — использование Core ML на iOS при одновременном применении других сред выполнения (llama.cpp или MediaPipe) на Android.
- Частые обновления моделей и управление версиями — например, выпуск новой версии модели, требующей повторной загрузки десятков или сотен мегабайт.
- Конфиденциальность локальных данных и требования к защищённому хранилищу — например, шифрование кэшированных документов в медицинском приложении.
- UX-проектирование для медленных или неуверенных ответов — например, отображение потоковых токенов или индикатора «обдумывания» в случаях, когда генерация занимает несколько секунд.
- Бенчмаркинг и тестирование производительности — например, измерение задержки и влияния на батарею на нескольких реальных устройствах, а не только в симуляторах.
- Логика фолбэка на облачный ИИ — например, переключение на облачную LLM при сбое локальной модели или недостаточной мощности устройства.
- Регуляторные требования и соответствие стандартам — например, обеспечение соответствия GDPR или HIPAA при локальной обработке чувствительных данных.
Пошаговый план интеграции локальной LLM в мобильное приложение
Интеграция локальной LLM в мобильное приложение требует прежде всего тщательного планирования на уровне продукта, инженерии и инфраструктуры. Представленный ниже план описывает практический, ориентированный на бизнес подход — от концепции до продакшна.
Определение бизнес-задачи
Процесс необходимо начать с чёткого понимания того, какую функцию должна выполнять ИИ-возможность и почему она должна работать локально. Грамотно сформулированная задача помогает избежать излишней сложности и подтвердить, что выбранная модель действительно создаёт ценность для продукта.
Выбор между локальной, облачной или гибридной архитектурой
Следующий шаг — определить оптимальную стратегию развёртывания. Во многих случаях гибридная архитектура обеспечивает наилучший баланс. Если выбор неочевиден или бизнес-контекст имеет специфические особенности, рекомендуется проконсультироваться со специалистами.
Определение целевых устройств и требований к производительности
На этом этапе важно установить, какие устройства должно поддерживать приложение и какой уровень производительности является приемлемым. Поскольку аппаратные характеристики мобильных устройств существенно различаются — особенно среди Android-устройств — этот шаг критически важен для формирования реалистичных ожиданий в отношении скорости, потребления памяти и размера модели.
Выбор семейства моделей и стратегии квантизации
Следующий шаг — выбор подходящего семейства моделей и определение подхода к их адаптации для запуска на мобильных устройствах. Как правило, предпочтение отдаётся компактным или квантизованным моделям: они снижают требования к памяти и ускоряют инференс.
Выбор фреймворка для инференса
Далее необходимо выбрать среду выполнения для запуска модели на мобильных устройствах — например, llama.cpp, MLC-LLM или Core ML. Это решение зависит от требований платформы, потребностей в оптимизации и необходимого уровня кроссплатформенной совместимости.
Разработка прототипа
Прототип необходим для проверки того, корректно ли выбранная модель работает на реальных устройствах. Как правило, он предполагает тестирование осуществимости — базовой функциональности, генерации ответов и первичных бенчмарков производительности — а не полноценную готовность к продакшну.
Тестирование производительности на реальных устройствах
Как только прототип достигает стабильного состояния, процесс переходит к комплексному тестированию на широком спектре реальных устройств. Это включает измерение задержки, потребления памяти, влияния на батарею и качества ответов.
Проектирование логики фолбэка
Поскольку не все устройства стабильно поддерживают локальный инференс, в системах нередко предусматриваются механизмы фолбэка, перенаправляющие запросы к облачному ИИ при необходимости. Такой подход обеспечивает предсказуемый пользовательский опыт на устройствах различных классов и в разных условиях использования.
Внедрение средств защиты и контроля конфиденциальности
На этом этапе команда разработки реализует меры безопасности для защиты чувствительных данных, обрабатываемых на устройстве. Они могут включать шифрование, защищённое локальное хранилище и механизмы управления доступом.
Подготовка к продакшн-развёртыванию и обновлениям
На финальном этапе решение готовится к выпуску в продакшн: настраиваются версионирование моделей, пайплайны обновлений, мониторинг и долгосрочные стратегии оптимизации. На практике после запуска компании продолжают корректировать баланс между локальным и облачным выполнением — на основе реальных паттернов использования и данных о производительности.
Сколько стоит разработка мобильного приложения с локальной LLM?
Стоимость разработки мобильного приложения с ИИ — в частности, с локальной LLM — во многом определяется конкретными условиями и желаемым результатом. На итоговую сумму влияет совокупность факторов:
- Количество платформ (iOS, Android или обе)
- Сложность и размер модели (компактная квантизованная модель или продвинутый ассистент)
- Необходимость офлайн-функциональности
- Наличие RAG
- Сложность UI/UX для ИИ-взаимодействий
- Тестирование производительности на реальных устройствах
- Требования к безопасности и соответствию стандартам
- Гибридная серверная инфраструктура
В зависимости от комбинации этих факторов можно ориентироваться на следующие средние значения:
- Простой MVP (локальная модель + базовый интерфейс, одна платформа, без RAG): ~$30 000–$80 000
Как правило, включает лёгкую модель, базовый чат-интерфейс и ограниченную поддержку устройств.
- Продукт среднего уровня (iOS + Android, оптимизированная модель, базовый фолбэк на облако): ~$80 000–$200 000
Обычно включает работу по квантизации, настройку производительности и кроссплатформенную интеграцию.
- Продвинутое решение (RAG, гибридная архитектура, корпоративный уровень безопасности): ~$200 000–$500 000+
Включает системы извлечения документов, оркестрацию локального и облачного выполнения, масштабное тестирование на устройствах и выполнение требований соответствия.
Скрытые затраты
В ряде случаев расходы могут неожиданно возрасти — если в процессе разработки выявляется потребность в дополнительной оптимизации под реальные устройства или обнаруживается скрытая сложность системы. Например:
- Поддержка старых Android-устройств может потребовать перехода на более компактные модели или реализации логики фолбэка на облако
- Добавление RAG увеличивает инженерные затраты на работу с эмбеддингами, хранилищем и синхронизацией
- Жёсткие требования к конфиденциальности (например, в здравоохранении или финансах) добавляют уровни шифрования и соответствия стандартам
- Гибридные архитектуры требуют дополнительной серверной инфраструктуры и систем мониторинга
Лучшие практики разработки on-device LLM
Разработка on-device LLM требует иного подхода, чем традиционная интеграция облачного ИИ.
Начинайте с чётко ограниченной задачи
Важнейшая рекомендация — не пытаться создать на устройстве «универсальный ИИ-ассистент». Мобильное железо не способно в полной мере поддерживать широкие, открытые сценарии использования на уровне качества облачных моделей.
Значительно эффективнее сосредоточиться на узкой задаче: например, офлайн-поддержке на основе FAQ, суммаризации документов или структурированных ответах в рамках конкретной предметной области.
Чёткая постановка задачи позволяет сохранить модель компактной, улучшить качество ответов и снизить риски производительности.
Используйте компактные и квантизованные модели
Размер модели напрямую влияет на все аспекты мобильного LLM-приложения: скорость, потребление памяти, расход батареи и размер приложения. Именно поэтому для продакшна, как правило, необходимы компактные и квантизованные модели — например, в формате 4-bit или 8-bit.
Такая оптимизация позволяет запускать модели на более широком спектре устройств с приемлемой производительностью — даже если это сопряжено с некоторым снижением глубины рассуждений.
Тестируйте на реальных целевых устройствах
Производительность мобильных ИИ-приложений существенно варьируется в зависимости от устройства — особенно между флагманскими и среднеклассовыми Android-смартфонами.
Модель, корректно работающая в симуляторе, может давать сбои в реальных условиях из-за ограничений памяти или теплового троттлинга. Именно поэтому тестирование на реальных устройствах необходимо для измерения задержки, стабильности и влияния на батарею.
Этот этап нередко выявляет ограничения, незаметные на ранних стадиях разработки, и помогает предотвратить неудовлетворительный пользовательский опыт в продакшне.
Почему стоит выбрать СКЭНД для разработки мобильного приложения с локальной LLM
Для компаний, рассматривающих или внедряющих on-device ИИ, сотрудничество с опытным инженерным партнёром способно существенно снизить технические риски, сократить время выхода на рынок и помочь избежать дорогостоящих архитектурных ошибок.
СКЭНД обеспечивает полный цикл поддержки мобильных и ИИ-решений, помогая компаниям пройти путь от концепции до готового продакшн-решения.
Направления нашей работы:
- ИИ-стратегия и консалтинг: выбор оптимального подхода — локального, облачного или гибридного
- Разработка ИИ-решений
- Разработка мобильных приложений для iOS и Android
- Интеграция генеративного ИИ в существующие или новые мобильные продукты
- Разработка on-device ИИ-прототипов для ранней проверки осуществимости
- Выбор и оптимизация моделей, включая квантизацию и настройку производительности
- Проектирование RAG-архитектуры для приложений, работающих с документами и данными
- Кроссплатформенная разработка с использованием современных мобильных ИИ-фреймворков
- Тестирование качества и производительности на реальных устройствах и в различных средах
- Долгосрочное сопровождение, масштабирование и стратегии обновления моделей
На практике такая поддержка полного цикла особенно ценна, когда компании не уверены, справятся ли локальные LLM с требованиями к производительности и пользовательскому опыту, — или когда необходимо совместить мобильную разработку с проектированием ИИ-систем.