# Когда продукту нужен ИИ на устройстве?

> Практическое руководство по ИИ на устройстве: выбор моделей, память, нагрев, среды выполнения, тестирование и выпуск продукта.

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

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

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

## Локальный инференс должен давать продуктовое преимущество

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

Проверку обычно выдерживают четыре преимущества:

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

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

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

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

## Бюджет определяет самое слабое поддерживаемое устройство

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

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

Модель на миллиард параметров хорошо показывает, почему размер весов дает лишь начальную оценку. При четырех битах на параметр исходные веса занимают около 0,5 ГБ. Среде выполнения также могут понадобиться метаданные квантования, данные токенизатора, временные тензоры, преобразованные буферы и растущий кеш внимания. Некоторые среды копируют или перепаковывают веса при загрузке. Поэтому приложению нужно заметно больше 0,5 ГБ доступной памяти, причем за нее конкурируют все остальные функции.

Храните проверяемый файл с ограничениями, который вместе обсуждают менеджер продукта, мобильные разработчики и инженеры машинного обучения:

```yaml
on_device_feature: compose_suggestion
supported_tier: mid_range_2022_and_newer
model_download_mb_max: 180
peak_rss_mb_max: 650
cold_start_ms_p95: 900
first_result_ms_p95: 250
sustained_run_minutes: 10
offline_required: true
fallback: server_or_manual_input
```

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

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

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

## Сначала выберите семейство, а не известную модель

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

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

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

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

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

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

## Среда выполнения определяет доступное железо

В телефоне могут быть CPU, GPU и нейронный ускоритель, но модель использует лишь те блоки, на которые среда выполнения умеет направить поддерживаемые операторы. Рекламные характеристики чипа не гарантируют ускорение вашего вычислительного графа. Один неподдерживаемый оператор может отправить часть графа обратно на CPU, добавить копирование между форматами памяти и уничтожить ожидаемый выигрыш.

На платформах Apple для большинства продуктовых команд первым выбором будет Core ML. В документации Core ML сказано, что среда может выбирать ресурсы CPU, GPU и Neural Engine, а `MLComputeUnits` позволяет приложению ограничить допустимые блоки. Полезна именно возможность управления, а не обещание, что все блоки всегда работают быстрее. Фоновая задача может намеренно использовать CPU, тогда как интерактивной задаче на переднем плане можно разрешить все блоки. Преобразуйте модель как можно раньше и проверьте ее на каждой поддерживаемой версии операционной системы и каждом классе чипов.

На Android среда LiteRT дает компактное исполнение на CPU и аппаратные делегаты. Делегаты нельзя считать взаимозаменяемыми переключателями. Покрытие операторов, драйверы устройства, формат модели и реализация производителя определяют, что попадет на GPU или NPU. Документация Google по NPU для LiteRT прямо описывает эту зависимость: производители чипов поставляют делегаты для своего железа. Из-за такой фрагментации план для Android должен включать проверенную матрицу совместимости и надежный путь через CPU.

ONNX Runtime Mobile разумно выбрать, если команда ценит единое представление модели на разных платформах или уже экспортирует через ONNX. Архитектура с поставщиками выполнения позволяет работать с разными ускорителями, но правило покрытия остается тем же. Сборка среды только с операторами конкретной модели помогает контролировать размер бинарного файла. За это придется платить еще одним слоем совместимости, в котором нужно искать причины расхождений между экспортированными графами, поставщиками и версиями платформ.

ExecuTorch подходит командам, чей процесс обучения и экспорта уже строится вокруг PyTorch. В его документации описаны предварительный экспорт, понижение представления и планирование памяти, специализированные бэкенды и переносимый резервный путь через CPU. Там также рекомендуют отдельные программные файлы для каждого бэкенда, потому что поддержка железа различается. Это честная инженерная формулировка: «кроссплатформенность» означает общий процесс и контракт среды, а не один бинарный файл с одинаковой скоростью повсюду.

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

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

## Квантование меняет продукт, а не только пакет

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

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

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

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

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

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

## Лучшие продуктовые сценарии скрывают границу модели

Локальный инференс лучше всего работает, когда продукт сразу использует ограниченный результат и понятно восстанавливается при неуверенности модели. Пользователь должен видеть отзывчивую функцию, а не управлять миниатюрным сервером моделей. Интерфейсы, которые перекладывают на человека задержку генерации, загрузку моделей, пределы контекста и необъясненные оценки уверенности, передают клиенту инженерные проблемы.

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

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

Для уверенности нужна продуктовая политика. Вероятности модели не получают правильную калибровку автоматически, и оценка 0,9 не означает, что в вашем приложении прогноз верен девять раз из десяти. Выбирайте пороги по отложенным данным продукта. Дайте системе резервный путь без модели, например ручной ввод, обычный поиск или запрос к серверу. При низкой уверенности продукт должен защищать пользователя, а не просто показывать меньшее число.

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

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

## Гибридная система должна выдерживать два вида отказа

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

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

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

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

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

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

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

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

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

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

## Производственные тесты начинаются после бенчмарка

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

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

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

```json
{
  "feature": "compose_suggestion",
  "model_version": "2026-08-rc3",
  "device_tier": "mid",
  "route": "local",
  "load_ms": 412,
  "inference_ms": 138,
  "fallback_reason": null,
  "result_status": "accepted"
}
```

Смотрите на распределения, а не радуйтесь медиане. Медленный хвост определяет впечатление, а частота отказов может скрыться на графиках задержки, из которых исключили тайм-ауты. Разделяйте результаты по версии модели, версии приложения, операционной системе, классу устройства, бэкенду среды, температурному состоянию, если оно доступно, и маршруту. Используйте укрупненные классы устройств, если точные идентификаторы железа создают проблемы с конфиденциальностью или слишком много рядов данных.

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

Ответственность должна быть явной. Инженер машинного обучения отвечает за оценку и происхождение артефакта; платформенные разработчики - за интеграцию и потребление ресурсов; менеджер продукта - за обещание пользователю и резервный путь; эксплуатация - за видимость выпуска и откат. В небольшой компании один человек может совмещать несколько ролей, но сами обязанности никуда не исчезают. Team & AI Audit помогает обнаружить расхождение обязанностей и затрат до того, как локальная модель станет еще одной постоянной подсистемой.

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