Обзор¶

Обзор¶

Здесь объясняется, как развернуть ИИ на устройстве SF32: выбрать устройство, подготовить модель с учётом выбранного способа выполнения, спланировать память и запускать инференс в пределах бюджета энергопотребления изделия. Материал опирается на аппаратные сведения из статьи «ИИ-ускоритель». Сначала прочитайте её, если хотите узнать о роли и ограничениях ускорителя.

SDK предоставляет ускоряемые операции через HAL NNACC (ускоритель нейронных сетей). Есть отдельные примеры для HAL и драйвера RT-Thread. Они проверяют отдельную операцию свёртки depthwise (по каналам), а не полное развёртывание обученной модели. Сначала используйте их для проверки отдельной операции; среду выполнения модели, средства преобразования и реализацию каждого слоя выбирайте и проверяйте отдельно.

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

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

Определите, какие решения устройство должно принимать самостоятельно¶

Начните с задачи изделия, а не с выбора модели:

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

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

Выберите подходящее устройство SF32¶

Возможности устройств SF32 для ИИ-нагрузок различаются:

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

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

Практический путь переноса модели на SF32 в целом одинаков для разных задач:

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

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

Зафиксируйте требования к среде выполнения¶

До преобразования модели запишите точные требования, которым должна соответствовать прошивка во время её выполнения:

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

Проверьте операторы и переходы на CPU¶

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

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

Квантование и планирование памяти¶

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

Квантование может сократить затраты памяти и вычислений, но после преобразования снова проверьте точность на репрезентативных данных датчиков. Руководство SDK v2.5.1 описывает ускорение arm_convolve_1x1_HWC_q7_fast_nonsquare, arm_convolve_HWC_q7_basic_nonsquare и arm_depthwise_separable_conv_HWC_q7_nonsquare. В конфигурации HAL используются 8-разрядные буферы и поля для сдвигов смещения и выходного значения. Это не доказывает прямую совместимость с нулевыми точками и поканальными масштабами произвольной современной int8-модели. Проверьте численную эквивалентность и для каждого неподдерживаемого слоя определите реализацию на CPU, преобразование либо отказ от развёртывания.

Размещение буферов и иерархия памяти¶

Пропускная способность памяти может ограничивать ИИ даже при доступной вычислительной мощности. На SF32 с SRAM, Flash, PSRAM и кэшами инструкций/данных STAR-MC1 проверьте доступность памяти и затраты, связанные с размещением буферов:

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

Реализация HAL v2.5.1 проверяет, что буферы не пересекают границы адресных окон размером 1 MiB (1 048 576 байт), а входной буфер и буфер bias находятся в одном окне. Проверяйте фактически выделенные адреса, а не только общий объём свободной памяти. Блокирующий запуск ожидает завершения опросом; режим прерываний требует корректной обработки IRQ и уведомления о завершении. Проверяйте возвращаемые значения и предусмотрите восстановление после ошибок и ограниченное ожидание в приложении, не предполагая наличия тайм-аута в среде модели.

См. STAR-MC1 — там описаны кэш и иерархия памяти при таком смешанном доступе.

Таблица расчёта объёма памяти¶

До интеграции прошивки заполните таблицу объёма памяти, используя наихудшие, а не средние оценки:

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

Соберите полный конвейер¶

Ускоритель — один этап конвейера от датчика до решения. Ниже описаны три типичных сценария поступления входных данных.

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

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

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

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

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

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

Планируйте инференс с учётом энергопотребления¶

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

• Где это уместно, запускайте инференс по новым полезным данным, например по срабатыванию порога датчика или получению полного аудиокадра. Сохраняйте периодическую обработку, если она нужна, и после изменения условия запуска проверяйте пропуски событий и наихудшее время отклика.
• Если требования к задержке позволяют, обрабатывайте данные пакетами вместо множества небольших запусков инференса.
• Если устройство и SDK это поддерживают, перенесите малозатратную постоянно активную обработку данных датчиков на маломощный процессор, чтобы не будить основной процессор приложения при каждой выборке.
• Измеряйте энергию на один инференс, интегрируя измеренную мощность питания (напряжение питания × ток) за явно заданный интервал. В бюджет функции включайте захват, пред- и постобработку, переходы между активностью и сном. Ускорение может сократить энергию активной работы или позволить раньше заснуть, но выигрыш зависит от тока, обмена с памятью и остальной системы.

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

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

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

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

Обновляйте модель и проверяйте её в эксплуатации¶

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

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

Отлаживайте производительность и точность ИИ¶

Типичные ошибки¶

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

Контрольный список первоначального запуска¶

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

Главное¶

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

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