ИИ офлайн на телефоне 2026: On-device AI

Телефон может запускать ИИ без сети, но не любой сценарий и не любую модель. В руководстве мы разбираем выбор задачи, Needle Tiny LLM, обработку текста, мультимодальные функции, интеграцию с iOS и Android, а также проверку памяти, температуры, батареи и разрешений на реальном устройстве.

Последнее обновление: 14 августа 2026 года. Технические сведения сверены с документацией Apple Core ML, Android On-device AI, Android storage и доступными материалами Needle.

По данным официальной документации Apple, Core ML использует CPU, GPU и Neural Engine устройства, а также поддерживает преобразование моделей из других ML-библиотек в собственный формат. Это означает главное: ИИ офлайн на телефоне в 2026 году реален, но начинать нужно не с размера модели, а с уменьшения задачи. Классификация, структурированный вывод, краткое резюме, извлечение данных и вызов ограниченного набора функций обычно подходят для первого релиза лучше, чем универсальный чат-бот. (документация Apple Core ML)

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

Эта статья предназначена для разработчиков, которые добавляют локальный ИИ в приложение для iOS или Android. Она также пригодится продуктовым командам, работающим с чувствительными данными, и техническим руководителям, выбирающим между чисто локальной и гибридной архитектурой.

Сначала определите сценарий, а не модель

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

Например, «умный помощник» — слишком широкая постановка. Рабочая версия выглядит иначе:

• распознать намерение пользователя из шести заранее известных классов;
• извлечь номер заказа, дату и сумму из короткого сообщения;
• вернуть JSON для одного из восьми разрешённых действий;
• сделать краткое резюме заметки;
• определить, требуется ли отправка запроса в облачный сервис;
• классифицировать изображение перед дальнейшей обработкой.

Такой подход снижает сразу несколько рисков.

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

Needle Tiny LLM особенно интересен для задач с ограниченным набором инструментов, структурированным выводом и управлением устройством. Однако компактность не делает модель безопасной автоматически. Перед реальным вызовом функции приложение должно проверить схему JSON, допустимость аргументов, наличие разрешения и необходимость подтверждения пользователя.

Инструменты и управление устройством

Для офлайн-вызова функций мы рекомендуем разделить цепочку на четыре уровня:

1. модель определяет намерение;
2. валидатор проверяет структуру ответа;
3. политический слой решает, разрешено ли действие;
4. исполнитель вызывает системный API или возвращает отказ.

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

Пример безопасной схемы:

{
  "action": "create_reminder",
  "title": "Позвонить клиенту",
  "date": "2026-08-15T10:00:00",
  "requires_confirmation": true
}

После генерации приложение обязано проверить:

• входит ли action в белый список;
• соответствует ли дата допустимому формату;
• не превышает ли длина текста установленный предел;
• есть ли у приложения нужное разрешение;
• требуется ли явное подтверждение пользователя;
• что произойдёт при неизвестном намерении.

Если модель не распознала запрос, безопасный ответ должен быть заранее заданным: «Команда не поддерживается» или «Уточните действие». Нельзя превращать ошибочный JSON в произвольный вызов системной функции.

Для таких задач компактная модель часто лучше большого чат-бота. Ей не нужно объяснять философию, писать длинный текст или поддерживать широкий круг тем. Её задача — выбрать маршрут и выдать проверяемую структуру.

Текст, документы и локальное резюме

Локальное резюме текста сложнее классификации, потому что модель должна удерживать смысл исходного материала. Здесь важны не только веса, но и:

• максимальная длина входа;
• поддерживаемые языки;
• стратегия разбиения длинного текста;
• формат исходного файла;
• память под промежуточные данные;
• требования к сохранению результата.

Если приложение работает с PDF, DOCX или HTML, сначала нужно реализовать надёжный слой извлечения текста. Нельзя считать, что передача файла напрямую в модель является частью AI-функции. Парсер может столкнуться с таблицами, сканами, нестандартной кодировкой, вложенными изображениями и повреждёнными документами.

Для длинного текста применяйте конвейер:

1. определить тип файла;
2. извлечь текст и метаданные;
3. удалить повторяющиеся колонтитулы;
4. разбить материал на фрагменты;
5. обработать каждый фрагмент;
6. объединить промежуточные резюме;
7. проверить длину и формат результата;
8. сохранить локально или передать в облако только с согласия пользователя.

В Android чувствительные файлы разумно хранить в app-specific storage или внутреннем хранилище. Официальная документация Android отдельно отмечает, что внутреннее хранилище подходит для данных, которые не должны быть доступны другим приложениям. Для выбора документов пользователем можно использовать Storage Access Framework, поскольку такой путь не требует широкого разрешения на файловую систему. (документация Android о хранении данных)

На iOS необходимо заранее описать доступ к защищённым ресурсам. Если приложение использует камеру, микрофон, контакты или другие системные данные, в проекте должны быть корректные usage descriptions, а пользовательский отказ должен обрабатываться как нормальный сценарий, а не как исключение. (требования Apple к подготовке приложения)

Чат и персональный помощник

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

Мы обычно рассматриваем три архитектуры.

Чисто локальная. Ввод, инференс, память диалога и инструменты работают на устройстве. Такой вариант подходит для заметок, коротких подсказок, приватных данных и функций без подключения к сети. Недостаток — ограниченное качество и разный опыт на разных телефонах.

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

Гибридная. Телефон выполняет классификацию, фильтрацию и простую генерацию. Сложное рассуждение, большие документы или редкие запросы передаются в облако после явного согласия. Android прямо описывает выбор между локальными решениями, собственными моделями и облачными инструментами как архитектурное решение, зависящее от задачи и охвата устройств. (обзор Android On-device AI)

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

Мультимодальные функции

Изображения, речь и мультимодальные запросы нельзя оценивать только по размеру языковой модели. В реальном приложении появляются дополнительные компоненты:

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

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

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

Выбор платформы и формата

На iOS Core ML Tools позволяют конвертировать модели в формат Core ML и уменьшать точность весов. Apple указывает, что веса могут переходить от 32-битного представления к 16-битному или более низкой точности от 1 до 8 бит, но итоговая совместимость и качество должны проверяться на целевом устройстве. (документация Apple об уменьшении размера модели)

На Android выбор зависит от того, нужна ли готовая системная функция или собственная модель. ML Kit GenAI API работает поверх AICore и ориентирован на заранее определённые сценарии, тогда как LiteRT предназначен для интеграции пользовательских моделей. При этом доступность системных возможностей зависит от совместимого устройства, поэтому нельзя обещать одинаковый результат для всех телефонов. (обзор Android On-device AI)

Развёртывание и проверка на устройстве

Рабочий процесс лучше строить так:

1. Опишите контракт задачи. Запишите допустимые входы, выходы, лимит текста, разрешённые действия и вариант отказа.
2. Выберите модель под контракт. Для классификации и инструментов начните с Needle Tiny LLM или другой компактной модели, а не с универсального помощника.
3. Подготовьте данные. Уберите персональные сведения, нормализуйте форматы и соберите примеры ошибок, а не только успешных запросов.
4. Преобразуйте модель. Для iOS проверьте конвертацию в Core ML. Для Android выберите совместимый runtime и протестируйте операции, квантование и токенизацию.
5. Сделайте автономный экран диагностики. В нём должны отображаться версия модели, формат, состояние загрузки, размер контекста, ошибка выполнения и факт наличия сети.
6. Добавьте ограничения. Белый список функций, проверка схемы, тайм-аут, ограничение размера файла и безопасный fallback должны находиться вне модели.
7. Соберите приложение для реального устройства. Симулятор или эмулятор полезны для интерфейса, но не заменяют проверку памяти, нагрева и энергопотребления.
8. Проведите повторный тест после упаковки. Разница между моделью в рабочем каталоге и моделью внутри приложения может повлиять на загрузку, доступ к файлам и размер пакета.
9. Проверьте публикацию. Для iOS нужно сверить bundle ID, подпись, поддерживаемые устройства, разрешения, privacy manifest и процесс TestFlight или App Store. (подготовка приложения к распространению)
10. Зафиксируйте границы поддержки. Укажите минимальную версию ОС, список проверенных архитектур, допустимые форматы и условия, при которых включается облачный fallback.

Mac удобен для подготовки датасета, конвертации модели, сборки iOS-приложения и автоматизации тестов. Но Mac не показывает реальную картину на телефоне. Нельзя по результату на настольной системе делать вывод о температуре, фоновой работе, ограничениях памяти или расходе батареи на iPhone и Android.

Условия выбора архитектуры

Используйте следующие ветвления:

• Если задача имеет до нескольких фиксированных типов ответа и ошибка обратима, выбирайте локальную модель.
• Если функция работает с чувствительным текстом и не требует внешних знаний, оставляйте обработку на устройстве.
• Если требуется структурированный вызов ограниченного набора инструментов, начинайте с Needle Tiny LLM, но добавляйте независимую проверку полномочий.
• Если входом являются короткие сообщения или небольшие заметки, проверяйте локальную генерацию прежде, чем проектировать облако.
• Если нужны большие PDF, актуальные данные или сложное рассуждение, используйте гибридную схему.
• Если приложение должно поддерживать широкий парк недорогих телефонов, снижайте требования к модели и заранее определяйте облачный fallback.
• Если продукт не может безопасно обработать ошибочный ответ без сети, не делайте чисто локальную архитектуру единственным вариантом.
• Если обновление модели происходит часто, не зашивайте все веса в приложение без плана версионирования и отката.

FAQ для мобильных разработчиков

Какая конфигурация нужна телефону для работы ИИ без интернета?

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

Какие модели можно запускать локально на iPhone?

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

Как развернуть Tiny LLM на Android-приложении?

Сначала выберите модель и runtime, затем подготовьте формат, квантование и обработку токенов. Для готовых Android-сценариев можно использовать системные API On-device AI, а для собственной модели — совместимый edge-runtime. После интеграции проверьте загрузку модели, отсутствие сети, разрешения на файлы и камеру, поведение при нехватке памяти и корректный переход к безопасному ответу.

Когда для приложения лучше выбрать локальный ИИ, а когда облачный?

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

Как проверить память и расход батареи у локальной модели?

Тестируйте не только размер файла модели. Зафиксируйте холодный и повторный запуск, пиковое потребление памяти, время обработки, нагрев, разряд батареи, работу в фоне и поведение при отключённой сети. Повторите сценарии на минимальном поддерживаемом устройстве и на нескольких версиях ОС. Результаты оформляйте по задачам, а не одной средней цифрой.

Память, батарея и отказоустойчивость

Минимальный набор приёмочных проверок должен включать:

• холодный запуск после полной выгрузки приложения;
• повторный запуск уже загруженной модели;
• обработку короткого и максимального разрешённого ввода;
• отказ при повреждённом файле;
• работу при отключённой сети;
• отказ пользователя в доступе к камере, микрофону или файлам;
• переход приложения в фон;
• восстановление после нехватки памяти;
• повторную обработку после ошибки runtime;
• проверку удаления и обновления модели.

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

Энергопотребление также зависит от длительности операции, частоты вызовов, использования ускорителя, фоновой активности и температуры. Не стоит публиковать одно число вроде «модель расходует X процентов батареи», если оно не получено на конкретной модели телефона, версии ОС и одинаковом сценарии.

Для каждой поддерживаемой категории устройств полезно иметь три режима:

• полный локальный режим;
• облегчённый локальный режим с меньшим контекстом;
• облачный или ручной fallback.

Так приложение не превращает слабое устройство в источник постоянных сбоев.

Mac в процессе разработки

Mac особенно полезен, если команда одновременно ведёт iOS-сборку, преобразование моделей и автоматизированные тесты. На нём удобно:

• очищать и разбирать датасеты;
• конвертировать модель;
• проверять корректность токенизатора;
• собирать iOS-приложение;
• запускать статические проверки;
• готовить несколько вариантов квантования;
• автоматизировать установку тестовых сборок;
• сравнивать ответы модели на фиксированном наборе запросов.

Для iOS-проекта важно учитывать подпись, идентификатор приложения, разрешения и правила распространения через TestFlight или App Store. Apple рекомендует сначала тщательно проверить сборку в Xcode, затем создать архив и выбрать способ распространения для тестировщиков или магазина. (документация Apple о распространении приложения)

Если команде нужен временный Mac для сборки, конвертации или тестового конвейера, мы бы начинали с обзора облачной аренды Mac для мобильной разработки. Этот же рабочий ресурс можно использовать повторно для сборки, преобразования модели и автоматизированных проверок в разные этапы проекта; финальная проверка при этом должна проходить на физических телефонах, а не на удалённой рабочей станции.

Главное ограничение остаётся неизменным: удалённый Mac заменяет рабочую станцию, но не заменяет реальный телефон. Финальная проверка должна выполняться на физических iPhone, Android-устройствах и, если это предусмотрено продуктом, на носимых или периферийных устройствах.

Текущий подход и облачный Mac

Разработка только на локальном ноутбуке часто выглядит проще, но у неё есть реальные недостатки: одна рабочая конфигурация, ограниченный набор физических устройств, сложнее параллелить iOS-сборки и тесты, а при поломке или нехватке ресурсов команда теряет время. При этом покупка отдельного Mac не всегда оправдана для прототипа, сезонного проекта или короткой миграции модели.

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