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

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

1. Предпосылки

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

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

Однако успешное развертывание механизма глубокого обучения на мобильных устройствах — непростая задача. Скорость работы, размер пакета, занимаемая память, охват модели и даже энергопотребление — все это препятствия, которые необходимо преодолеть. Мобильный движок глубокого обучения xNN от Alipay является лидером в этом отношении.В этой статье будут рассмотрены методы и технологии оптимизации мобильного DL xNN.

2. Скорость бега

Большинство мобильных процессоров основаны на архитектуре ARM. Мобильный терминал выполняет задачу глубокого вывода нейронной сети. Решение на основе ЦП является самым простым и надежным; решение на основе графического процессора имеет слишком высокую совместимость/синхронизацию данных/накладные расходы/ Интерфейс не решает проблемы; решение DSP также будет иметь проблемы с совместимостью; в последнее время многие производители чипов для мобильных телефонов начали создавать сопроцессоры ИИ (различные TPU/APU/NPU), но пройдет определенное время, прежде чем применение. Ниже мы сосредоточимся на технологии оптимизации на платформе ARM. Оптимизация состоит из трех шагов:

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

Шаг 2: Подтвердите вычислительную точку доступа. Это неотделимо от некоторых инструментов профиля синхронизации, таких как инструмент XCODE, GPROF, ATRACE, DS-5 и т. д. Умелое использование инструментов может сделать больше с меньшими затратами.

Часть 3: Рукопашный бой. Ниже приведены некоторые преимущества.

2.1 Базовая оптимизация на C/C++

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

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

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

2.2. Кэширование

Большая часть работы по оптимизации, основанной на подсистеме памяти ЦП, заключается в том, чтобы подумать о том, как эффективно использовать кеш (кэш), особенно в сцене обработки изображений и видео такого большого объема обмена данными. Десятилетия назад наши предшественники изобрели оперативную память, многоуровневый кэш, регистры для компенсации разницы в производительности между памятью и вычислительным блоком, и эта проблема до сих пор не решена (может быть, никогда не будет решена, память и вычислительный блок). идеи разные, а стоимость скоростного тарана однозначно высокая). Уровень хранения показан на рисунке ниже.Принцип очень прост.Хочешь бегать быстро,можешь только меньше читать.Если хочешь бегать быстро и собирать больше,то придется платить больше,чтобы купить машину.

После работы подсистемы ЦП-память, если регистры пересчитаны, берем из кэша L1 через инструкцию, L1 вне счета (Cachemiss), берем из L2, а в кеше нет данных, берем из основная память, возьмем ее из основной памяти , она тоже делится на время и место.Эффективность доступа к разным местам в основной памяти (драм/DDR) в разное время разная. Вот несколько рекомендаций, которыми можно поделиться:Используйте меньше памяти

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

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

Наименьшей единицей обмена данными между основной памятью и кешем является строка кеша, поэтому лучше обращаться к адресу памяти в соответствии с размером строки кеша, что может обеспечить наиболее эффективный доступ к данным. Например, машина с размером строки кэша 64 байта обращается к области памяти размером 128 байт и помещает свой начальный адрес в положение, не выровненное по 64 байтам, например, 0x80000020, тогда для доступа к этим 128 байтам требуется 3 доступа к строке кэша, если он размещен в 0x80000040, то требуется только 2 строки кэша, как правило, применяя немного больше памяти, чтобы избежать этого смещения, например, используя функцию posix_mem_align(); кроме того, чтобы выровнять доступ, иногда необходимо сделать некоторые отступы на границе изображения, например 224x224 , мы можем сохранить его по адресу памяти 256x224, который гарантированно будет выровнен при случайном доступе к строке. как:

комбинированный доступ

Если вы многократно читаете и записываете часть памяти для выполнения операций, эффективность определенно не так эффективна, как «одно чтение — несколько операций — одна запись». Например, в модели DL за уровнем CONV обычно следуют уровни RELU и BIAS.На основе принципа экономии доступа к памяти путем предварительного анализа структуры сети уровень CONV и смещение могут быть объединены, и даже CONV+BIAS+RELU можно комбинировать Совместное выполнение операций может дать хороший выигрыш. Например:

После слияния изначальные три чтения и три записи в память стали тремя чтениями и одной записью, и скорость отличная.

Явно выровненные загрузки данных

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

Среди них ":128" должен сообщить ЦП, что адрес, сохраненный R1, является 128-битным выровненным адресом. В это время ЦП может посылать более эффективный сигнал при отправке запроса данных в память. Если R1 не выровнен по 128 битам, выполнение такой инструкции приведет к исключению адреса, что является распространенной ошибкой шины в LINUX. Как обеспечить, чтобы R1 был выровнен по 128 битам?Программист должен знать структуру данных, соответствующую R1, и должен заранее спроектировать смещение адреса, чтобы гарантировать правильное выполнение инструкции. Не все случаи могут соответствовать этому требованию.предварительная выборка кеша

Представьте себе, если ЦП вовсю делает вычисления, то мы в фоновом режиме скрытно перемещаем некоторые данные, которые будут использоваться позже, в кеш, и ЦП не нужно ждать данные в следующий раз. выше? да. Предварительная выборка кэша может сделать это, например: предварительная загрузка [R1, #256], которая позволяет ЦП продолжать выполнение последующих инструкций и начать загрузку данных в $R1+256 байт в кэш в фоновом режиме.

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

2.3 Многопоточность

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

поток накладных расходов

OPENMP автоматически выделяет потоки для циклов, но не все циклы подходят для оптимизации многопоточности.Если каждый цикл выполняет очень мало действий, то использование многопоточности может быть полезным. Создание и переключение потоков будет потреблять определенное количество системных ресурсов.В планировании потоков существуют определенные правила.При отсутствии высокоприоритетных событий (прерываний, исключений, семафоров), инициируемых операционной системой, цикл планирования находится на уровень миллисекунды.Если время выполнения не достигает определенного значения, эффект многопоточности будет значительно снижен. На практике вы можете использовать оператор #pragma omp parallel for if (cond), чтобы определить, следует ли включать многопоточность в процессе выполнения.

Динамическое планирование

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

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

2.4. Редкий

Глубокая нейронная сеть — это суперчерный ящик, люди узнают вес синапса, чтобы вся сеть могла выполнить определенную задачу, но не знают, что делает каждый синапс. На самом деле его решающую роль, скорее всего, будут именно эти «несколько сухожилий». То же самое верно и для наших экспериментальных результатов, большое количество весовых данных может быть равно 0, а общая точность вывода почти одинакова. Когда обнаруживается, что 50% или даже 80% данных в сети равны 0, тогда очень важна свертка и оптимизация матрицы для разреженности.

Разреженная оптимизация направлена на разработку соответствующей схемы индекса и метода хранения данных, как показано на следующем рисунке.

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

2.5 Фиксированная точка

Большинству механизмов логического вывода глубоких нейронных сетей необходимо использовать точность с плавающей запятой для получения более точных результатов, чтобы данные на бумаге выглядели хорошо. Но на самом деле некоторые приложения ГО не требуют такой высокой точности, даже с плавающей запятой одинарной точности, все равно есть большие избыточные операции. Взяв в качестве примера свертку Tensor 1x1, на самом деле это процесс умножения-накопления.Если для хранения данных используются данные с плавающей запятой одинарной точности, каждый элемент требует 4 байта, а если данные квантуются до 8 бит, только 1 byte, экономя 3/4 доступа к памяти, а это означает, что улучшение производительности будет более очевидным в условиях узкой полосы пропускания. На следующем рисунке показаны преимущества повышения производительности (множественные) фиксированной точки в различных сценариях.

2.6.НЕОН и сборка

NEON — это 64/128-битная гибридная SIMD-технология для передовых приложений обработки мультимедиа и сигналов, а также встроенных процессоров. Он реализован как часть ядра ARM, но имеет собственный конвейер выполнения и набор регистров, который отличается от набора регистров ядра ARM. NEON поддерживает SIMD-операции с целыми числами, с фиксированной запятой и с плавающей запятой одинарной точности. Хорошо спроектированный код NEON теоретически может быть в 2-8 раз быстрее, чем обычная версия на языке C.

Набор инструкций NEON разделен на версию ARMV7 и версию ARMV8, а количество и формат регистров немного отличаются. Есть два способа написания инструкций NEON: один — NEON Intrinsic, другой — NEON Inline Assembly.

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

https://community.arm.com/Android-community/not/Android/posts/arm-neon-programming-quick-reference

2.6.1.НЕОН внутренний против Неон встроенная сборка

В большинстве случаев достаточно использовать программирование NEON Intrinsic.Преимущества NEON Intrinsic также весьма очевидны.Во-первых, он может работать как на платформах armv7, так и на armv8.Во-вторых,код лаконичен и прост для понимания и поддержки.Платформа делает перестановку кода; но встроенный NEON также имеет некоторые недостатки, такие как отсутствие инструкций предварительной выборки, очень хлопотно декомпозировать регистры Neon, распределение регистров может быть неэффективным, и загрузка явного выравнивания не может быть выполнена, и компилятор может ввести некоторые странные инструкции , что приводит к снижению производительности.

Если требования к производительности определенного модуля очень высоки и вывод компилятора не соответствует требованиям, требуется встроенная сборка.Для операции свертки основного модуля в xNN она реализуется через встроенную сборку, и ее производительность лучше, чем у NEON. Внутренний потенциал увеличился примерно на 10%. Ниже приведен официальный пример ARM:

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

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

2.6.2 Очень важно уметь писать НЕОН/ассемблер, и еще важнее придумать хороший план реализации

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

Например, практическая реализация умножения матриц одинарной точности с плавающей запятой C = A * B + Bias в sgemm для простоты предполагает, что размеры матрицы являются степенями двойки. Например, Dims(C) = 512x512, Dims(B) = 512x512, Dims(B) = 512x512, Dims(Bias) = 512x512;

Код 1: язык C записывается как:

Время работы: 1654689 мкс (Xiaomi 5 Snapdragon 820, то же самое ниже).

Чтобы построить SIMD, мы выводим 4 элемента C одновременно, например:

Это приводит к коду 2, который является начальной записью NEON:

Время работы: 633551us

Учитывая повторную загрузку данных, вы можете взять еще четыре строки и вывести блок 4x4 за раз, что может сэкономить почти 3/4 чтения данных, например

Это приводит к коду 3:

Время работы: 367165us

Кроме того, мы обнаружили, что число матрицы B не является непрерывным, каждый раз берется только 4 числа с плавающей запятой, что намного меньше строки кэша (64 байта), что эквивалентно 3/4 промаха кэша, может быть оптимизировано, есть много отходов, поэтому данные B транспонируются, и процесс транспонирования может быть объединен с фактическим кодом, чтобы уменьшить дополнительное копирование памяти; в то же время мы используем Bias в качестве значения инициализации суммы, чтобы уменьшить одну операцию записи. Итак, получите код 4:

Время работы: 60060us

Наконец, постройте цикл в соответствии с блоком 4x4, а затем используйте OPENMP для многопоточности и получите код 5:

Время работы 25178us

Прирост скорости работы четырех вышеуказанных методов записи NEON:

Код 5, безусловно, не конец оптимизации, за счет перераспределения данных часть транспонирования 4x4 можно опустить, оптимизация кеша может быть более детальной, оптимален ли блок 4x4, еще предстоит продемонстрировать, наконец, сборка также может быть принесены в жертву Большой убийца, производительность может перейти на другой уровень.

Оптимизированная версия sgemm также может ссылаться на библиотеки с открытым исходным кодом, такие как nnpack/eigen. В реальном коде необходимо обрабатывать различные измерения, и код намного сложнее, чем приведенный выше.

3. Размер упаковки

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

3.1 Оптимизация компиляции

Компилятор имеет параметры компиляции, зависящие от размера, такие как GCC -Os, что эквивалентно одновременному включению эффекта оптимизации -O2 при уменьшении размера сгенерированного объектного файла.После создания объектного кода при компоновке в динамическую библиотеку можно передать команду strip., чтобы удалить избыточный код отладки. Это самые основные оптимизации. Для IOS следующие методы могут быть использованы для упрощения XCODE:

BuildSettings-> Уровень оптимизации, для XCODE по умолчанию установлено значение «Самый быстрый, самый маленький», оставьте значение по умолчанию
Для параметра Build Settings->Linking->Dead Code Stripping установлено значение YES.
Для постобработки развертывания установлено значение YES.
Для продукта Strip Linked установлено значение YES
Для параметров проекта Включить исключения C++ и Включить исключения Objective-C установлено значение НЕТ.
Параметр Символы, скрытые по умолчанию, установлен на ДА.
Все библиотеки lib, которые не используют динамические функции C++ (в проекте поиска не используется ключевое слово dynamic_cast) Параметр Enable C++ Runtime Types имеет значение NO.

Для приведенной выше конфигурации, когда IOS устанавливает цель вывода для выпуска, XCODE автоматически откроет для вас часть конфигурации. Точно так же скомпилируйте в Android NDK, настройте OPTIMIZE=release в Application.mk, NDK поможет вам выполнить большую часть работы по оптимизации.

Для встраиваемых устройств с ограниченными ресурсами ARM предоставляет сокращенный набор инструкций thumb/thumb2, который эквивалентен той же инструкции, с двумя наборами 16-битных и 32-битных инструкций одновременно.Использование параметра -MThumb позволяет компилятору преимущественно компилировать 16-битные Во время выполнения встроенный декодер преобразует инструкцию в 32-битную инструкцию, что позволяет не только упростить код, но и сохранить производительность исходной 32-битной инструкции.

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

Это нормально, это действительно дешево!

3.2 Упрощение кода

Выше приведены некоторые традиционные методы уменьшения размера библиотеки.На самом деле, в соответствии с характеристиками модели DL размер библиотеки может быть дополнительно уменьшен, например:

Упрощение зависимостей библиотек — большинство движков с открытым исходным кодом полагаются на библиотеки C++ STL, такие как Caffe/Tensorflow.Если вы хотите добиться предельного упрощения, вам необходимо удалить сложные атрибуты C++, чтобы вы могли полагаться на более компактные библиотеки stl даже без stl. .
Адаптация функций — удаление нестандартных слоев, удаление нестандартных ветвей кода или компонентизация слоев, требующая времени для загрузки, может уменьшить размер базовой библиотеки;

3.3 Сжатие модели

Размер модели глубокого обучения может быть от нескольких мегабайт до сотен мегабайт, без сжатия это просто невообразимо. Большая часть данных в модели — это синаптические веса нейронной сети, и существует огромное пространство для сжатия. Например, инструмент xqueeze, предоставленный командой Alipay xNN, может сжать модель глубокого обучения в десятки и даже в сто раз. Методы сжатия включают обрезку нейронов, обрезку синапсов, квантование, преобразование сети, адаптивный алгоритм Хаффмана и многое другое. Конкретная реализация может относиться к некоторому основному документу.

4. Сокращение памяти

Использование памяти также нуждается в рационализации.Младшие модели могут иметь только 1 ГБ или даже 512 МБ памяти.В сложных сценариях приложений этого часто недостаточно. Уменьшение памяти может в определенной степени смягчить воспоминания, вызванные недостатком памяти, с другой стороны, использование меньшего объема памяти также способствует повышению скорости логического вывода;

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

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

Alipay xNN разработала механизм управления памятью под названием MPool.В сочетании с процессом логического вывода глубокого обучения, MPool анализирует структуру сети и вычисляет минимальное использование памяти на основе достаточного повторного использования памяти и применяется заранее перед началом логического вывода.Достаточно памяти.

MPool имеет следующие преимущества:

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

Механизм DL со структурой MPool используется для запуска основных моделей, а использование памяти сокращается более чем на 75%.

5. Совместимость и надежность

Коммерческое программное обеспечение, совместимость и надежность являются важными показателями. Например, уровень покрытия модели Alipay xNN достиг более 98% во время Весеннего фестиваля, посвященного пяти благословениям.По сути, если это мобильный телефон на базе ARM, он может поддерживать его без взрыва батареи. Однако улучшение совместимости и надежности не намного более гладко, чем процесс разработки, и необходимо решить множество инженерных проблем.

Приведу несколько примеров:

Чтобы развернуть xNN в приложении Alipay, он должен быть совместим с версией stl в приложении;

Для совместимости со старыми версиями Android необходимо использовать более старые версии NDK и API, иначе возникнут проблемы с совместимостью математических библиотек;

Чтобы убедиться, что память не утекает при нескольких последовательных запусках, необходимо провести тесты на усталость на разных версиях android/ios;

Для многозадачного параллелизма требуется взаимное исключение;

Чтобы быть совместимым с поврежденными файлами модели, необходимо выполнить многоуровневую совместимость контрольной суммы модели.

...

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

6. Еще

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

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

Одна техническая статья в день,

Не можешь посмотреть?

обрати внимание на"Машинный интеллект Алибаба",

Узнайте больше о сухих товарах с искусственным интеллектом.

↑ Ждем вашего внимания

Вам также может понравиться

Нажмите на изображение ниже, чтобы прочитать

Как быстро разработать Даббо применение?

Скучное «машинное обучение» тоже можно выучить таким образом

Модель распознавания речи с открытым исходным кодом собственной разработки Alibaba DFSMN

обрати внимание на «Али Технологии»

Уловите пульс передовых технологий