ИИ-ускоритель¶

Введение¶

ИИ-ускоритель, обозначаемый в SDK как NNACC, берёт на себя поддерживаемые операции нейронных сетей в некоторых устройствах SF32. Он позволяет выполнять ИИ на периферии (edge AI) локально, без зависимости от облачного сервиса. Снижение задержки, загрузки CPU или энергопотребления зависит от модели, размещения данных в памяти, программной реализации и нагрузки всего изделия.

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

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

Сведения о приведённых ниже операциях CMSIS-NN и количестве ресурсов NNACC для каждого устройства основаны на документации SiFli-SDK v2.5.1. В руководстве NNACC этой версии указаны ресурсы для SF32LB55x/56x/58x, но не установлено, есть ли NNACC в SF32LB52x или SF32LB57x; отсутствие сведений не доказывает отсутствие ускорителя. Проверки границ адресных окон, поведение ожидания и настройка GC032A — это наблюдения по HAL или драйверу данной версии, а не универсальные гарантии для всех ревизий микросхем и версий SDK. Упомянутые руководство и примеры NNACC не подтверждают наличие полного преобразователя моделей или среды выполнения графов, автоматического перехода на CPU либо поддержку захвата с камеры для каждой микросхемы и платы. До фиксации проекта проверьте точную версию и конфигурацию SDK, ревизию микросхемы, среду выполнения и плату.

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

Зачем выполнять ИИ на устройстве¶

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

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

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

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

Место ускорителя в системе SF32¶

Упрощённый конвейер периферийного ИИ на SF32 выглядит так:

Sensors / Audio / Camera
        │
        ▼
Pre-processing
  - filtering
  - framing
  - normalization
  - feature extraction
        │
        ▼
Firmware / Inference Runtime
  - model graph orchestration
  - supported operations on NNACC
  - other operations on CPU, if implemented
        │
        ▼
Post-processing
  - thresholding
  - smoothing
  - event detection
  - application decisions
        │
        ▼
Application, UI, Bluetooth, or Storage

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

Что делает ИИ-ускоритель¶

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

Это примеры вычислений в нейронных сетях, а не перечень операций, поддерживаемых NNACC в SF32. В руководстве по NNACC для SiFli SDK v2.5.1 описано ускорение NNACC для трёх функций свёртки q7 из CMSIS-NN, включая свёртку отдельно по каждому каналу (depthwise convolution); там же указано, что реализация CMSIS-NN с ускорением NNACC в 8 раз быстрее ARM DSP-реализации CMSIS-NN. Условия сравнения в руководстве не приведены: воспринимайте это как сравнение, заявленное производителем, а не как гарантию снижения задержки или энергопотребления всей модели. Проверьте совместимость каждого оператора модели и его числового формата с выбранной реализацией. Нельзя считать, что умножение матриц, функции активации и пулинг имеют отдельное аппаратное ускорение. SDK также предоставляет HAL API для прямого управления ускорителем, но не следует считать, что какой-либо из этих интерфейсов включает полный конвертер моделей или среду выполнения графа. Прошивка или отдельная среда инференса должна управлять слоями и буферами; для выполнения неподдерживаемых операций на CPU нужна соответствующая реализация.

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

К распространённым задачам относятся:

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

Роли CPU, ускорителя и памяти¶

Удобная модель для проектирования: CPU управляет процессом, а ускоритель выполняет выбранные вычислительно сложные операции.

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

Позиционирование семейств устройств¶

Выбирайте устройство по операторам, бюджету памяти и нагрузке всего изделия, а не по общей рейтинговой оценке семейств. Руководство SDK v2.5.1 описывает по одному NNACC в подсистеме HCPU каждого из устройств SF32LB55x и SF32LB56x, а также по одному в подсистемах HCPU и LCPU у SF32LB58x. Эти ресурсы помогают при выборе, но не гарантируют ускорения всей модели или снижения энергозатрат. Проверьте наличие ресурсов, доступную память и программную поддержку для конкретного номера микросхемы и конфигурации.

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

Процесс разработки модели¶

Типичный процесс разработки встроенной ИИ-системы включает несколько этапов:

1. Обучите модель или выберите готовую на рабочей станции, используя репрезентативные данные.
2. Уменьшите модель до размера, допустимого для встроенной системы: выберите подходящую архитектуру, примените прунинг (pruning) или квантование либо измените модель.
3. Выберите или реализуйте среду инференса и представление модели; затем проверьте охват операторов и числовую совместимость с выбранными вычислительными ядрами SDK. Не считайте, что HAL NNACC включает конвертер полных моделей.
4. Проверьте точность численных результатов после преобразования и квантования.
5. Встройте предварительную обработку, инференс и постобработку в прошивку.
6. На реальном устройстве измерьте задержку, расход памяти и энергии, а также точность.
7. Испытайте реальные параллельные нагрузки Bluetooth, дисплея, аудио и датчиков, включая переходы в запланированные энергосберегающие состояния и выход из них.

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

Квантование и размер модели¶

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

Модель с разрядностью 8 бит не обязательно совместима с NNACC. В конфигурации HAL SDK v2.5.1 используются буферы int8_t и поля bias_shift / out_shift. Это не подтверждает поддержку произвольных нулевых точек, поканальных масштабных коэффициентов или всех современных операторов int8. Проверьте размещение элементов тензоров, обработку знака, сдвиги и представление bias (смещения) в конкретной реализации вычислительного ядра. Затем сравните выходные данные с программной эталонной реализацией на характерных входах и граничных значениях.

При квантовании нужно учитывать компромиссы:

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

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

Память и пропускная способность¶

Даже небольшая на вид модель может требовать много памяти. Системе могут понадобиться области памяти для:

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

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

Сначала проверьте, что выбранный NNACC имеет доступ к каждому буферу. Размещение данных во внешней флеш-памяти или PSRAM само по себе не означает, что NNACC может использовать эти данные без промежуточного копирования в рабочие буферы. Включите в бюджет время копирования, рабочую RAM и энергию. Реализация HAL SDK v2.5.1 округляет проверяемые размеры буферов до 4 байт и отклоняет буфер, если его начало и проверяемый конец попадают в разные адресные окна размером 1 MiB (1,048,576 байт). Входной буфер и буфер bias также должны находиться в одном окне. Конец точно на границе следующего окна тоже не проходит проверку. Планируйте выделение памяти по этим фактическим условиям и обрабатывайте ошибки до запуска следующей операции.

Если CPU использует общие буферы с DMA или NNACC, на время каждой передачи или операции назначайте одного владельца доступа. Перед чтением аппаратурой входов, записанных CPU, запишите данные из кэша в память. До аппаратной записи подготовьте строки кэша выходного буфера по правилам SDK, чтобы грязные строки CPU позднее не перезаписали результат. После подтверждённого завершения аппаратной операции инвалидируйте устаревшие копии CPU и только затем читайте выходные данные. Обслуживание кэша должно охватывать полные строки; не размещайте в тех же строках посторонние данные, которые ещё используются. Запись старой выходной копии из кэша после аппаратной записи может уничтожить результат. Очистка с записью в память и инвалидация не взаимозаменяемы.

Конвейеры аудио, датчиков и камеры¶

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

Аудио и голос¶

Обнаружение голоса или звуковых событий может включать микрофонный вход, DMA-буферы, разбиение на кадры, фильтрацию, выделение признаков, инференс и сглаживание результатов. NNACC выполняет поддерживаемые нейросетевые операции; прошивка или выбранная среда обрабатывает остальной граф, а CPU или аудиоподсистема управляет отсчётами и признаками. Модель и проверенная программная реализация по-прежнему необходимы.

Типичные задачи:

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

Движение и объединение данных датчиков¶

В носимых устройствах данные могут поступать от акселерометров, гироскопов, датчиков сердечного ритма, датчиков SpO2, аналоговых входных каскадов ЭКГ и другой периферии. Алгоритмы ИИ могут классифицировать состояния движения, жесты, виды активности и признаки, связанные со здоровьем.

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

Камера и изображения¶

Ввод данных камеры зависит от конкретной микросхемы, корпуса, платы и драйвера захвата. Драйвер датчика GC032A в SDK v2.5.1 настраивает 8-битный выход DVP или двухбитный SPI. Это не доказывает работоспособность обоих путей захвата на всех устройствах SF32. До выбора камеры проверьте выводы, поддержку захвата периферией или PTM, временные параметры датчика и драйвер. Изображения часто требуют более крупных буферов и большей пропускной способности, чем аудио или движение, но сравните реальные разрешения и частоты.

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

Планирование задач и управление питанием¶

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

Рекомендуемые подходы:

• Выбирайте периодический инференс или запуск по событию с учётом требуемой полноты обнаружения, риска пропуска событий и допустимой задержки.
• Избегайте циклов опроса, если работу можно запускать по прерыванию или событию.
• Объединяйте отсчёты датчиков, если это допускает требуемое время отклика.
• Ограничивайте задержку от входных данных до решения, сохраняя окно, нужное для надёжного обнаружения.
• Согласуйте выполнение ИИ-задач с активностью дисплея и Bluetooth.
• Переводите CPU и ускоритель в допустимые энергосберегающие состояния после подтверждения завершения, передачи буферов и снятия необходимых блокировок управления питанием; нужный сбор данных и другие незавершённые задачи должны продолжаться.

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

В SDK v2.5.1 блокирующий запуск HAL опрашивает завершение без собственного явного тайм-аута. Режиму прерываний нужны рабочий обработчик IRQ и уведомление о завершении. Проверяйте ошибки запуска, ограничивайте ожидание в приложении и определите порядок восстановления до повторного использования буферов или снятия блокировок управления питанием.

Компромисс между точностью, задержкой и энергопотреблением¶

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

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

Практические рекомендации¶

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

• Какое решение устройство должно принимать локально?
• Какие датчики предоставляют исходные данные?
• Как часто нужно выполнять инференс?
• Какая задержка допустима?
• Каков максимальный объём памяти для весов модели и тензоров?
• Можно ли квантовать модель без существенной потери точности?
• Какие операции ускоряются выбранной микросхемой и SDK?
• Как ведёт себя система, когда одновременно работают Bluetooth, дисплей, аудио и инференс?
• Как проверять точность модели на реальных данных изделия?
• Как при необходимости обновлять или заменять модель после выпуска устройства?

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

Типовые сценарии применения¶

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

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

Главное¶

• NNACC может брать на себя поддерживаемые операции и снижать занятость CPU; выигрыш по задержке и энергии проверяйте для всей функции.
• Ускоритель входит в состав полного конвейера, включающего датчики, аудио или камеру, предварительную обработку, перемещение данных в памяти, постобработку и логику приложения.
• SDK v2.5.1 описывает ресурсы NNACC для SF32LB55x, SF32LB56x и SF32LB58x, но не устанавливает наличие NNACC в SF32LB52x или SF32LB57x. Проверяйте конкретную микросхему и нагрузку, не делая выводов о наличии или отсутствии ускорителя только по названию семейства.
• Реальная производительность зависит от размера модели, квантования, поддерживаемых операций, размещения данных в памяти, работы с кэшем, DMA и поддержки среды инференса в SDK.
• Локальный инференс полезен, если он отвечает целям изделия по быстродействию, работе без сети, конфиденциальности или беспроводному трафику. Одна лишь аппаратура ускорителя не гарантирует этих преимуществ.

Последнее обновление: 2026-10-19