Затраты и ROI ИИ на устройстве: Apple и Gemini

Apple Intelligence — это набор системных функций и фреймворков Apple для разработчиков, которые запускают компактную языковую модель локально на поддерживаемом оборудовании iPhone, iPad и Mac, при этом Private Cloud Compute используется для более тяжелых задач. Разработчики могут вызывать модель на устройстве через фреймворк Apple Foundation Models. Gemini Nano — это самая маленькая модель Gemini от Google, встроенная в Android через AICore на поддерживаемых устройствах и доступная веб-разработчикам через экспериментальные встроенные API ИИ в Chrome.

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

Команды, привыкшие к облачным API, часто предполагают, что на устройстве означает бесплатно. Это бесплатно за вызов, но проект — нет. Бюджет смещается в четыре места.

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

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

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

Проработанная концепция

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

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

Это дает точку безубыточности: месяц, в котором совокупная экономия облака превышает дополнительные усилия по сборке.

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

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

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

Выберите короткий список и отслеживайте его с момента запуска. Слишком много метрик скрывают сигнал.

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

Если принятие низкое, экономия затрат не имеет значения. Рассматривайте использование как первый порог, затем смотрите на деньги.

Некоторые ситуации говорят против этого. Ясность в отношении них является частью честного случая ROI.

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

В этих случаях хорошо выбранная облачная модель с кэшированием обычно дешевле в целом.