Axera AX650N: архитектура Edge ML SoC под CNN, LLM и VLM

Большинство задач современной робототехники так или иначе завязаны на нейронных сетях: детекция объектов, оценка глубины, локализация, планирование. Всё это ресурсоёмко, и вопрос выбора компактного вычислителя (достаточно часто алгоритмы должны работать локально) встает довольно остро. На практике выбор сводится к трём классам устройств: NVIDIA Jetson, внешний ускоритель (один из самых популярных — Hailo) и китайский (не всегда, конечно, но в современных реалиях обычно китайский) SoC с интегрированным NPU. В этой статье я рассмотрю представителя третьего класса — Axera AX650N, а NVIDIA Jetson будет использоваться для сравнения, так как это единственное массовое edge-решение с универсальными вычислительными ядрами (CUDA).

Это первая часть цикла. Здесь я разберу аппаратную архитектуру самого AX650N — CPU, NPU, DSP, ISP, память — и поделюсь результатами первых тестов: YOLO, Depth Anything, SuperPoint и мультимодальный Qwen3. Подробные бенчмарки и сравнения — во второй части.

Я тестировал AX650N в рамках готового устройства от Sipeed — Maix4 Hat. Он состоит из двух частей: SoM, на котором расположены SoC и 8 GB RAM (2×4 GB, так как у AX650N два отдельных DDR-контроллера), и baseboard от Sipeed с минимальным количеством интерфейсов. Скромность интерфейсов объясняется просто: baseboard — это HAT для Raspberry Pi 5, подключающийся по PCIe 2.0. В такой конфигурации AX650N работает как внешний ML-ускоритель, аналогично Hailo. В рамках этой и последующих статей я буду использовать Maix4 Hat как самостоятельный микрокомпьютер.

У Sipeed есть и полноценный baseboard для AX650N — M4N Dock. В нём уже выведен Ethernet, PCIe и 2 четырёх-лейновых MIPI CSI для камер. Но стоит он примерно вдвое дороже HAT-версии (45 тысяч рублей). В плане производительности разницы нет — SoM одинаковый.

Заявленные 18 TOPS@INT8 — маркетинговое число, которое включает производительность нескольких подсистем сразу. В даташите для самого NPU указано 10.8 TOPS@INT8. Далее в статье будет разобрано, откуда берётся разница и куда делись ещё 7 TOPS. В любом случае, даже 10 TOPS вполне достаточно для инференса свёрточных моделей (например, YOLO), но вот насколько этот чип справится с более тяжёлыми задачами — визуальными трансформерами и LLM/VLM — предстоит выяснить.

Что внутри: архитектура AX650N

Часть документации Sipeed выложили у себя. На основе доступных даташитов и тестов на реальном железе я далее описал общую архитектуру и особенности работы NPU.

AX650N объединяет восемь ядер Cortex-A55, собственный NPU Axera Neutron, AI-ISP с аппаратной нейросетевой обработкой, двойной DSP на ядрах Tensilica Vision Q7, аппаратные видеокодеки и целый набор дополнительных специализированных Vision-модулей. GPU нет вообще — и это принципиальный выбор архитектуры (или просто удешевление), к обсуждению которого я вернусь в конце статьи.

CPU

Восемь ядер Cortex-A55 организованы в единый кластер с трёхуровневым кэшем:

• L1: 32 KB I-Cache + 32 KB D-Cache на каждое ядро

• L2: 64 KB на каждое ядро

• L3: общий 512 KB на весь кластер

• Частота: до 1.7 GHz при напряжении 1.0 V; до 1.1 GHz при 0.8 V

• SIMD/FPU: поддержка NEON и интегрированный FPU

Cortex-A55 — не самые мощные ядра для 2026 года (например, у RK3588 4xA76 + 4xA55), но для Vision-пайплайнов этого обычно достаточно. CPU здесь занимается оркестрацией: настраивает DMA, конфигурирует ISP и NPU, запускает MIPI CSI — все ресурсоёмкие операции выполняются аппаратно. Единственное место, где процессор реально нагружается — постпроцессинг результатов моделей (NMS, confidence filtering). Поэтому необходимо максимальную часть постпроцессинга переносить на NPU или DSP, чтобы CPU не стал узким горлышком в итоговой скорости работы модели.

Подсистема памяти: двойной DDR-контроллер

AX650N оснащён двумя независимыми 32-битными контроллерами LPDDR4/LPDDR4x — DDR0 и DDR1. Каждый контроллер имеет собственную физическую шину данных (32 бита), собственный набор сигналов CA, CK, CS, DQS, а их адресные пространства в системной карте адресов разнесены: DDR0-система базируется по адресу 0x8000000, DDR1-система — по 0xC000000.

Два контроллера не образуют единую 64-битную шину (как в классическом “dual-channel ddr”), а работают параллельно с раздельными адресными пространствами. Это означает, что NPU, VDSP, ISP и CPU могут инициировать транзакции к разным контроллерам одновременно, не создавая конкуренции за одну шину. При скорости 4266 Mbps каждый контроллер обеспечивает ~17 GB/s, суммарно — до ~34 GB/s теоретической пропускной способности.

Максимальный объём: до 16 GB на канал (до 32 GB суммарно). При этом часть памяти резервируется как CMM (Contiguous Media Memory) — непрерывный регион, доступный NPU, VPU, ISP и DSP напрямую, минуя MMU ядра Linux. Отношение CMM к Linux-памяти конфигурируется программно. По умолчанию на Maix4 HAT под систему выделяется 2 GB, а под CMM оставшиеся 6 GB.

NPU — Axera Neutron

Сразу хочу обратить внимание, что большинство ПО для NPU (низкоуровневые драйвера и SDK для подготовки моделей) является проприетарным, поэтому всё описанное дальше — логические выводы на основе доступной документации.

Заявленные 72 TOPS@INT4 / 18 TOPS@INT8 — это маркетинговая сумма по нескольким подсистемам сразу. В даташите отдельно для NPU указано: 43.2 TOPS@INT4 / 10.8 TOPS@INT8. Как именно были получены 18 TOPS@INT8 непонятно, но очевидно, что в них входит сумма NPU, DSP, MAU и других IP-блоков. При этом, например, двухъядерный DSP не участвует в инференсе моделей. Это было проверено при запущенной YOLO через дебаг информацию от драйвера DSP в sysfs (/proc/ax_proc/dspX/info).

NPU поддерживает широкий набор квантования (причём имеется поддержка смешанных типов между слоями): целочисленные INT4/INT8/INT16 и флоаты FP16/FP32. И это на самом деле очень важно, потому что если требуется детектировать объекты с высокой точностью границ, то в INT8 квантовании YOLO модели может не хватать.

Заявляется, что INT4 в 4 раза быстрее, чем INT8 (10.8 vs 43.2). Обычно INT4 даёт теоретический прирост не более чем в 2 раза по сравнению с INT8 (например, для RK3588). Из этого можно сделать вывод, что поддержка INT4 реализована аппаратно. Скорее всего два INT4 упаковываются в одну INT8 MAC дорожку, при этом в отличие от того же RK3588 считаются параллельно (два INT4 перемножения за один такт). Квантование в INT4 обычно не используется для свёрточных визуальных моделей, но вот веса LLM активно конвертируют в INT4.

По карте адресов можно частично восстановить топологию подсистемы NPU: 

Тринадцать EU разделены на три группы vNPU. Изначально я предположил распределение:

• Convolution Unit (3x) — выполняет все виды свёрток: standard, depthwise, grouped, dilated, transposed convolution

• Computer Vision Unit (3x) — нормализация изображений, ресайз, remap/warp

• Tensor Unit (3x) — функции активации, pooling, elementwise-операции, reduce

Затем в качестве эксперимента я экспортировал одну и ту же YOLO-модель через Pulsar 2 (инструмент подготовки моделей для Axera NPU) под три разных режима работы. Pulsar 2 может генерировать трейс модели, из которого видно в каком порядке что выполняется и на каких EU.

В режиме NPU1 (одно ядро из трёх) трейс демонстрирует минимальный набор активных треков: один teng, два conv, один sdma и отдельный cv.

В режиме NPU2 (Big-Little, два виртуальных ядра) количество активных треков удваивается симметрично: появляются teng4/teng5, conv0-3, sdma8/sdma9. Паттерн подтверждает, что второй vNPU добавляет аналогичный комплект EU, а не «достраивает» пул какого-то одного типа.

В режиме NPU3 (все три ядра объединены) трейс наиболее полный: teng6/teng7/teng8, conv0-5, sdma12-14. 

Из этого можно сделать вывод, что каждый vNPU содержит 2 Convolution EU + 1 Tensor EU + 1 SDMA, а всего Conv EU —  6, а не 3, как я предположил изначально. Также можно заметить, что все вычисления модели разделяются между NPU EU — задач для MAU или DSP нет. Это ещё раз подтверждает, что на инференс стандартными средствами выделяется максимум 10.8 TOPS.

Если посчитать количество EU для NPU3 режима, то их получится 12, хотя по карте адресов их должно быть 13. Сначала я предположил, что один оставшийся EU — это MAU (Matrix Operation Unit), отдельный блок для перемножения матриц. В трейсе его нет, потому что для YOLO он в целом и не нужен, всё ложится на Conv и Tensor EU. Даташит косвенно это подтверждает, потому что MAU описан в части, посвященной NPU:

Точного количества MAC-блоков в каждом EU не указано, но зная что общая пиковая производительность 10.8 TOPS можно найти количество MAC в каждом EU, если предположить, что оно одинаково для каждого. В таком случае получается:

Тогда производительность каждого EU немного больше 0.8 TOPS. Возможно в каждом EU более круглое значение MAC, а именно по 512 MAC, но они неравномерно распределены и в каких-то отдельных EU больше MAC. Либо частота NPU немного выше, чем 800 MHz (например, 810 MHz даёт практически 10.8 TOPS). Значение в 800 MHz я взял из дебага sysfs NPU драйвера (она всегда фиксированная и увеличить/уменьшить её нельзя):

cat /proc/ax_proc/npu/clk
800M

Но потом я нашёл референс мануал на IVE (Intelligent Video Engine — отдельная подсистема, документ 42, AX IVE API), в котором была описана производительность MAU:

25.6 GOPS — это примерно в 30 раз меньше, мощности одного EU (~800 GOPS). Получается, MAU — это не полноценный EU, а отдельный небольшой блок для матричных операций. Я пока не нашёл способа измерить нагрузку на каждый из EU по отдельности (драйвер даёт только оценку суммарной утилизации всех EU). Поэтому 13-й EU, скорее всего, либо является частью одного из Conv/teng-блоков, либо Pulsar 2 просто не задействовал его для YOLO. 

Теперь обсудим возможности EU блоков. Во-первых это не универсальные вычислительные блоки, подобно CUDA. Это специфичные блоки, реализующие набор конкретных операций. Список из даташита:

• Convolution: general NxM, Depthwise/Group Conv, Dilation, and ConvTranspose.

• MatMul with dynamic weights.

• Activations: ReLU/PReLU/Swish/Tanh/Sigmoid.

• Pooling: MaxPool/AvgPool/ROIAlign.

• Elementwise: Add/Sub/Mul/Div/Compare.

• Reduction: Sum/Mean/Max/ArgMax/Softmax.

• Normalization: BatchNorm/InstanceNorm/GroupNorm/LayerNorm.

• Tensor reshape: Reshape/Transpose/Concat/Slice/Reverse/Pad/Space2Depth/Depth2Space.

• CV: Resize/Remap/Warp.

Все модели под NPU конвертируются через предварительное представление в универсальном формате ONNX. Заявляется очень хорошая поддержка ONNX-версии 11. Таблица с уровнем поддержки отдельных опецаий есть в документации Pulsar 2. 

OCM и SDMA

On-Chip Memory объёмом ~11 MB — это буфер для весов и активаций текущего слоя модели в момент инференса. Для каждого слоя нейросети пайплайн выглядит следующим образом:

1. SDMA копирует веса слоя из CMM в OCM

2. EU исполняют операцию на данных (свёртку, нормализацию и т.д.) из OCM

3. SDMA копирует результат обратно в CMM для следующего слоя

Три параллельных SDMA позволяют организовать двойную буферизацию: пока EU выполняют текущий слой, SDMA уже загружают веса следующего. Для небольших моделей (с весами, умещающимися в OCM) SDMA-накладные расходы минимальны. Для крупных моделей типа LLM с весами в несколько гигабайт этот “bandwidth bottleneck” становится основным ограничителем производительности.

NPU можно сконфигурировать как единый монолитный NPU (с доступом ко всем EU) или как три независимых vNPU. В vNPU режиме есть возможность запускать модель на одном или двух ядрах. Режим vNPU используется, если есть необходимость параллельно инференсить несколько различных моделей. В случае, если вам нужно, чтобы полностью одинаковая модель обрабатывала изображения с трёх камер, vNPU не нужен. Для этого правильнее будет использовать batched inference. Но если нужна параллельная обработка различными моделями, то vNPU имеет смысл. Например: один vNPU может исполнять YOLO, второй — монокулярную оценку глубины (Depth Anything), а третий — детектор ключевых точек (SuperPoint), и всё это параллельно, без конкуренции за EU ресурсы. При этом в таком режиме проблемой может стать конкуренция за OCM (11 MB) и DMA (точнее пропускную способность DDR), которые будут делиться между тремя моделями.

AI-ISP: Axera Proton (AxeraVision)

AI ISP реализуется на основе классической ISP обработки, с добавлением нейронных сетей. Физически ISP поддерживает до 4 сенсоров одновременно, максимальное разрешение 8192×4320@30fps в режиме 2DOL HDR. Возможные конфигурации: 1×8-lane, 2×4-lane или 4×2-lane.

AI-модули, встроенные в ISP-пайплайн:

Кроме AI модулей, поддерживаются и все классические ISP алгоритмы: 3A (AF/AWB/AE), PDAF, YNR/CNR/3DNR, DRC, LSC, Gamma, CAC, Fish-eye коррекция, dehaze.

Подсистема DSP: Tensilica Vision Q7

AX650N содержит два независимых ядра Tensilica Vision Q7 VDSP, работающих на частоте до 800 MHz. Это IP от Cadence, специализированное именно для задач компьютерного зрения. Характеристики каждого ядра:

• L1: 32 KB I-Cache + 16 KB D-Cache

• TCM: 32 KB ITCM + 512 KB DTCM (Tightly Coupled Memory — сверхбыстрый локальный ОЗУ, сравнимо с OCM в NPU)

• MAC: 256 MAC@INT8, 64 MAC@INT16

• iDMA: 4 канала с поддержкой 3D-трансферов (для тензорных копирований)

• AXI: 128-bit AMBA AXI main master + 128-bit AXI iDMA master

• FBC/FBDC: интеграция со схемами сжатия буферов (снижение DDR bandwidth)

• Address remap: логика remapping для обращения к полному 64-bit адресному пространству DDR через 32-bit AXI-мастер

Два VDSP работают полностью независимо и могут выполнять разные задачи параллельно. iDMA поддерживает трансферы TCM <-> TCM, TCM <-> DDR/OCM и DDR/OCM <-> DDR/OCM. Это означает, что DSP может предобработать данные (например, ORB-дескрипторы или облако точек с лидара) и отдать результат сразу в буфер NPU — без лишнего копирования и задействования CPU.

На сайте Tensilica есть отдельная страница для AX650N со списком библиотек:

Правда, просто так их не скачать, нужно запросить доступ. Но описание библиотек выглядит заманчиво: аппаратно ускоренный OpenCV, SLAM алгоритмы и CNN. В дальнейших тестах я обязательно проверю производительность DSP. Потенциально DSP должен решать задачи, которые плохо ложатся на CNN-ориентированный NPU (хотя и DSP может выполнять свёртки, но не такие большие и не так быстро), например классические CV алгоритмы (Optical Flow, ORB, FAST). Также, например, XPCL поможет эффективно обрабатывать данные с 3D лидара. 

IVE: Intelligent Video Engine

IVE (Intelligent Video Engine) — это единый API поверх всего vision-стека AX650N. Один хэндлер агрегирует 9 исполнительных движков: TDP, VPP, VGP, GDC, DSP, NPU, CPU, MAU и сам IVE-движок. CPU строит граф задач через этот API, не управляя аппаратными очередями напрямую.

Эта дополнительная абстракция с одной стороны удобна, но с другой не реализует потенциал каждой отдельной подсистемы полностью. Взять тот же Q7 DSP, через IVE он используется для небольшой части задач, при этом SDK от Tensilica может использовать его более гибко для гораздо более широкого спектра задач. 

Сам IVE-движок реализует классические алгоритмы:

• Арифметика: Add (с весовыми коэффициентами Q1.7), Sub (abs/shift), MSE (Mean Square Error)

• Булева логика: And, Or, Xor (над U8C1-масками)

• Пространственные фильтры: Filter 5×5 (произвольное ядро), Sobel-like 5×5 (градиент + угол), Canny (двухпроходный: CannHysEdge + CannyEdge)

• Морфология: Erode 5×5, Dilate 5×5 (с произвольной маской)

• Статистика: Hist (гистограмма), EqualizeHist, Integ (интегральное изображение, вывод U64C1)

• Фоновое моделирование: GMM и GMM2 (Gaussian Mixture Model — для детектора движения)

• Пороговые операции: Thresh (8 режимов: Binary, Binary-Inv, Trunc, ToZero и др.)

• Формат/геометрия: 16bit to 8bit конвертация, CropImage, CropResize, CropResize2, CSC (Color Space Conversion), CropResizeForSplitYUV

• Связные компоненты: CCL (Connected Component Labeling), до 2048 регионов, вывод blob-структур с bounding box

Все операции работают напрямую с физическими адресами CMM. Как было сказано выше IVE управляет различными другими Vision подсистемами, поэтому кратко опишу их:

• TDP (Two-Dimensional Processor) — 2D-операции над буферами: повороты, отражения/флипы, alpha blending, клиппинг маски. 

• VPP (Video Post Processor) и VGP (Video Graphics Processor) — Масштабирование и OSD

• GDC (Geometric Distortion Correction) — коррекция дисторсии линзы: Fisheye dewarping, LGC (Local Gain Compensation), поддерживаются сетки для кастомных типов дисторсии

• PyraLite — аппаратный генератор гауссовых пирамид для выделения фич. Пирамидальные признаки используются в детекторах фич SIFT, SURF, а также архитектура FPN (feature pyramid networks)

Видеокодек (VPU)

Имеется полноценный видеокодек H.264/H.265.

VENC:

• H.264 и H.265

• Максимум 7680×4320@30fps

• Многопоточное кодирование: 8K@30fps + 1080p@30fps одновременно

• Поддержка JPEG до 3840×2160@200fps

VDEC:

• До 32 потоков 1080p@30fps параллельно

• До 7680×4320@60fps в одном потоке

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

Пример vision пайплайна

• Сенсор выдаёт RAW-данные по MIPI

• Sensor System (CSI RX контроллеры) принимает пакеты и десериализует поток

• ISP (IFE -> ITP) выполняет полный пайплайн, включая AI-3DNR, AI-HDR, AI-Demosaic

• ISP выдаёт 3 YUV-выхода с разным разрешением; один — на VENC для записи/стриминга через RTSP, другой — в VPP/GDC

• GDC корректирует дисторсию линзы

• VPP масштабирует до нужного размера входного тензора NPU и записывает в CMM

• NPU (через SDMA) загружает веса из CMM в OCM, Convolution EU выполняют свёртки

• Результаты записываются в CMM

• CPU (или DSP) опционально выполняет постпроцессинг и принимает решение  

Это очень упрощённый пайплайн, который даёт базовое понимание, как всё функционирует: NPU специально упрощен, без учёта vNPU, предобработка входного кадра может не ограничиваться VPP+GDC. Вариаций много, vision подсистема AX650N может достаточно гибко масштабироваться.

Трансформеры: как vision — SoC запускает LLM

Из предыдущего описания аппаратных блоков может сложиться справедливое мнение, что AX650N — это Vision SoC с CNN ориентированным NPU. Это действительно так, тем не менее Axera заявляет о “native support for Transformer intelligent processing platform” и в их Model Zoo на Hugging Face можно найти очень много готовых LLM и VLM моделей.

Основная стратегия развёртывания LLM на AX650N — W8A16 (Weights 8-bit, Activations 16-bit) квантование. Это означает:

• Веса представляются в INT8

• Активации представляются FP16 (сохраняет точность динамического диапазона)

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

Свёрточные блоки внутри NPU фактически выполняют GEMM операции:

GEMM C = A * B

Матрицу активаций A (размерность [batch, seq_len, d_model]) можно рассматривать как изображение с пространственными размерами [seq_len, 1] и d_model каналами. А матрицу весов B — как ядра свёртки [1×1 с d_model входными и d_out выходными каналами]. 

Таким образом Conv EU в NPU могут выполнять линейные проекции трансформера, представляя их в виде 1×1 свёрток. Но Conv EU адаптированы под работу с матрицами статичного размера, а в случае с LLM, длина последовательности токенов (seq_len) обычно переменная, поэтому Pulsar 2 может генерировать разные модели для разной длины начального контекста (prefill_len).

При инференсе ax-llm делает следующее:

• Prefill: промпт нарезается чанками по prefill_len токенов, каждый чанк прогоняется через p128_l{N} axmodel’и. KV-кэш накапливается в CMM.

• Decode: каждый новый токен прогоняется через decode-версию тех же слоёв (сконвертированную под seq_len=1). KV-кэш читается из CMM.

Такой подход оправдан для текущей архитектуры ускорителя, но главная проблема заключается в том, что реализация памяти (CMM <-> OCM) не оптимизирована под такую высокую нагрузку. Более детальный анализ будет далее.

Токенизатор исполняется на CPU и работает примерно за O(N), поэтому особого смысла в его переносе на NPU нет. A55 справляется достаточно быстро.

Vision Encoder в VLM

VLM по сути состоит из двух независимых пайплайнов — Vision Encoder и LLM. Vision часть модели собирается в отдельную axera модель с фиксированным размером входа (разрешением изображения). Инференс ViT состоит из следующих этапов:

• Patch Embedding — 2D-свёртка с ядром размера patch_size x patch_size. Обрабатывается на Conv EU

• Positional Embedding — Tensor EU

• Блоки трансформеров, так же как и LLM: 

  • LayerNorm -> QKV-проекции (Conv EU) -> Attention (Conv EU + Tensor EU) -> FFN (Conv EU)

Теперь перейдём к тесту производительности некоторых моделей.

Первые тесты

График называется “Model Performance Comparison (FPS)”, FPS откладывается по вертикали. При этом на самом деле это график производительности только инференса моделей. Не для всех моделей инференс даёт сразу готовый для использования результат. Часто требуется выполнить на CPU некоторый постпроцессинг, который тоже занимает время. Примеры кода для инференса есть в репозитории от Axera, а Model Zoo на Hugging Face.

Все модели тестировались в INT8 весах. Реализация YOLO от Axera для модели YOLO11s занимает 3.2 мс на инференс и 4.45 мс на построцессинг (при 7 детекциях, чем больше детекций — тем дольше постпроцессинг). В итоге, можно рассчитывать на латентность 7.65 мс (130.7 FPS) от получения кадра до готовых результатов детекции. Латентность инференса YOLO11n — 1.675 мс + те же 4.45 мс постпроцессинга дают латентность не сильно меньше — 6.125 мс (163.2 FPS). Тут можно сразу сделать вывод, что bottleneck возникает не в скорости NPU, а в CPU, который слишком долго производит постпроцессинг результатов выходных слоёв модели. При этом, если говорить про realtime детекцию с камеры, то при частоте кадров в 60 FPS, задержка между чтением кадров составит 16, в которые текущая задержка работы YOLO укладывается, т.е. кадры пропускаться не будут. Для камер с большей частотой, например, IMX477, которая может выдать 240 FPS, возможно, самый простой вариант оптимизации будет использование double buffering подхода (NPU сразу после инференса первого кадра начинает работу со следующим кадром, пока CPU занимается постпроцессингом предыдущих результатов). Также решением может быть перенос постпроцессинга на NPU/DSP или использование архитектур с более простым постпроцессингом, например, YOLOv10, с обучаемым (learnable) NMS-фильтром, который не выносится за пределы модели и будет сразу выполняться на NPU. 

YOLO: 

• Квантование в INT8 

• Разрешение 640×640

• Инференс в режиме NPU3 (максимальная утилизация NPU)

Конфигурация экспорта через Pulsar 2:

{  "model_type": "ONNX",  "npu_mode": "NPU3",  "quant": {    "input_configs": [      {        "tensor_name": "images",        "calibration_dataset": "./dataset/coco_1000.tar",        "calibration_size": 32,        "calibration_mean": [0, 0, 0],        "calibration_std": [255.0, 255.0, 255.0]      }    ],    "calibration_method": "MinMax",    "precision_analysis": true,    "precision_analysis_method":"EndToEnd"  },  "input_processors": [    {      "tensor_name": "images",      "tensor_format": "BGR",      "src_format": "BGR",      "src_dtype": "U8",      "src_layout": "NHWC"    }  ],  "output_processors": [    {      "tensor_name": "/model.23/Concat_output_0",      "dst_perm": [0, 2, 3, 1]    },    {      "tensor_name": "/model.23/Concat_1_output_0",      "dst_perm": [0, 2, 3, 1]    },    {      "tensor_name": "/model.23/Concat_2_output_0",      "dst_perm": [0, 2, 3, 1]    }  ],  "compiler": {    "check": 2  }}

Сравнение YOLOv8 и YOLO11 в N и S размерах:

Depth Anything V2

Depth Anything — это визуальный трансформер для точной монокулярной оценки глубины. Его можно использовать для навигации/SLAM, планирования пути и так далее. Так же результаты модели можно взаимодополнять лидарными и стерео данными.

При входном разрешении 518×518 латентность инференса около 33-34 мс, а время постпроцессинга 10-13 мс. Эффективный FPS получается около 20-23 FPS. Модель работает в режиме NPU3. Часть последних слоёв, экспортированы в float16.

Super Point Mono VO

SuperPoint — это полностью свёрточная нейронная сеть, которая детектирует ключевые точки и их дескрипторы на изображении за один проход. В отличие от классических методов (SIFT, ORB), модель работает на изображении полного размера и способна находить более широкий набор повторяемых точек интереса. Поиск ключевых точек на изображении разрешения 640×480 занимает около 28 мс (35 FPS). Входные и выходные слои не квантованы, т.е. результирующие дескрипторы ключевых точек возвращаются в float32.

Далее, если добавить матчинг точек (например, через BFMatcher), то можно сопоставлять ключевые точки между двумя последовательными кадрами и затем восстанавливать физическое перемещение камеры между ними (но без привязки к реальным координатам). Так можно сделать простую визуальную одометрию с потенциальным расширением до полноценного vSLAM. Благодаря небольшому квантованию, которое применяется в основном к свёрточным слоям внутри модели, качество поиска ключевых точек падает незначительно. Но матчинг через BFMatcher производится на CPU и занимает 25 мс, что слишком много для работы в реалтайме. Поэтому для матчинга можно использовать LightGlue, перенесённый на NPU. Это увеличит и качество матчинга, и производительность. Или как простой вариант, можно использовать L2-норму.

Ниже приведён пример вычисленной одометрии на основе детекции ключевых точек через SuperPoint + BFMatcher + recoverPose на датасете KITTI. Дальнейшей оптимизацией может быть перенос матчера на NPU и findEssentialMat + recoverPose на DSP. Так как в реальности такой пайплайн работает не в реальных размерах, то для сопоставления с ground truth результат одометрии скейлится на основе ground truth. В реальности scale можно восстанавливать на основе, например, IMU данных. 

Qwen LLM

Для теста я запустил мультимодальную Qwen3-VL-2B-Instruct в w8a16 квантовании. В только текстовом режиме при входной длине в 31 токен (системный промпт + пользовательский запрос), ttft (time to first token — время, через которое модель начнёт декодировать токены) составляет 157.91 мс. Скорость генерации ~12.3 токена в секунду. Ответы выглядят адекватно (в системном промпте было указано: “you are helpful assistant specialized in computer science and robotics”):

prompt >> Hello! What is NPU?media >>16:29:54.103 INF SetKVCache:1437 | decode_grpid:0 prefill_grpid:1 history_cap:0 total_cap:128 symbolic_cap:1 precompute_len:0 input_num_token:31 prefer_symbolic_group:016:29:54.103 INF SetKVCache:1458 | current prefill_max_token_num:128016:29:54.221 INF SetKVCache:1462 | first run16:29:54.268 INF Run:1553 | input token num : 31, prefill_split_num : 116:29:54.268 INF Run:1640 | prefill chunk p=0 history_len=0 grpid=1 kv_cache_num=0 input_tokens=3116:29:54.269 INF Run:1665 | prefill indices shape: p=0 idx_elems=384 idx_rows=3 pos_rows=016:29:54.426 INF Run:1837 | ttft: 157.91 msHello! NPU stands for **Neural Processing Unit**. It is a specialized hardware component designed to accelerate the processing of artificial intelligence (AI) and machine learning (ML) workloads, particularly those involving matrix operations and neural network computations.In the context of **AI and robotics**, NPU is commonly used in **edge computing** devices (like smartphones, IoT devices, or robotics systems) to perform real-time AI tasks more efficiently than traditional CPUs or GPUs.### Key Features of NPU:- **Specialized for AI workloads**: NPU is optimized for matrix multiplications, which are common in deep learning models.- **Lower power consumption**: Designed to run AI models efficiently on low-power devices.- **Faster for neural network operations**: Enables faster inference (prediction) of machine learning models.### Example Use Case:In robotics, an NPU can be used to process real-time video data from a camera, run object recognition algorithms, or enable autonomous decision-making in robotic systems.### In Summary:> **NPU (Neural Processing Unit)** is a hardware chip designed to accelerate AI and machine learning computations, especially for tasks like image recognition, speech recognition, and real-time pattern recognition in robotics and AI systems.Let me know if you'd like to know more about how NPU compares to GPUs or CPUs!16:30:16.181 NTC Run:2102 | hit eos,decode avg 12.37 token/s16:30:16.181 INF GetKVCache:1408 | precompute_len:301, remaining:979

Можно предположить использование модели для высокоуровневого управления в робототехнике (планирование и перестроение миссии на основе непредсказуемых сценариев), в том числе внутри LLM агента, то если результат модели уместить в 80 токенов (примерно 40-50 английских слов, стандартный токенизатор Qwen без адаптации под задачу) решение получится генерировать за ~6.6 секунды (0.15 Hz). При этом, если уменьшать требование к объёму выходных токенов, например в 2 раза (40 токенов), то время на генерацию составит 3.4 секунды + TTFT 157 мс. Продолжая уменьшать количество токенов TTFT начинает давать всё большую задержку (при 80 токенах он занимает 2% времени, при 40 уже 4.6%). При дальнейшем сокращении токенов TTFT станет доминирующим ограничением, и снижение количества токенов перестанет давать линейный прирост частоты. Качество ответов модели я планирую проверить через различные открытые бенчмарки.

Теперь можно попробовать мультимодальность. Vision энкодер у модели работает с изображения разрешения 384×384. Со следующим системным промптом модель будет работать как детектор объектов:

You are a helpful assistant for object detection in images. When detecting objects, return a valid minified JSON array. Each entry must contain just only 2 entries: — label: the object name (string) — bbox_2d: [x_min, y_min, x_max, y_max] in normalized 0-1000 coordinates Return ONLY a minified JSON array, no explanation text.

Модель нативно оперирует нормализованными координатами от 0 до 1000, поэтому 

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

Также стоит обратить внимание, что json не самый токенно-эффективный формат для представления результатов, но зато любая модель очень хорошо его знает и чётко придерживается формата. Более эффективный формат может требовать полного или низкорангового (LoRA) дообучения. 

Пример результата работы:

[{"label": "car", "bbox_2d": [200, 370, 371, 734]},{"label": "car", "bbox_2d": [500, 488, 998, 998]},{"label": "car", "bbox_2d": [744, 770, 1000, 1000]}]

Время работы визуального энкодера при разрешении 384×384 примерно 200 мс, на разрешении 640×640 — 1015 мс.

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

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

Системный промпт:

You are a high-level planner for a robotic grasping arm. You receive an image of fruits or vegetables on a surface. Your job is to analyze the scene and output a structured grasp plan. Generate grasp strategy with object specific methods.

Входное изображение:

Результат работы модели:

### Grasp Strategy for the Image**Objective**: Safely and efficiently grasp a variety of strawberries and other fruits from a hanging basket.---### **Step-by-Step Grasp Plan**#### **1. Scene Analysis**- **Object Identification**: The image shows a hanging basket of strawberries, some green and some red, along with other fruits like grapes and possibly some green vegetables.- **Spatial Layout**: The fruits are arranged in a vertical, hanging basket. The basket is suspended by a metal frame, and the fruits are arranged in a way that allows for a vertical grasp.- **Constraints**: The basket is suspended, so the grasp must be stable and avoid falling. The fruits are not on a flat surface, so the grasp must be stable and secure.---### **Grasp Strategy**#### **Step 1: Identify the Target Object**- **Target Object**: The primary target is the strawberries in the basket.- **Object Characteristics**: The strawberries are hanging from the basket, and they are not on a flat surface. They are suspended and may be slightly tilted.#### **Step 2: Choose the Grasp Method**- **Grasp Method**: Use a **vertical grasp**.- **Why Vertical Grasp?**: The vertical grasp is ideal for hanging objects. It allows the robotic arm to grasp the object from the side, which is more stable and secure than a horizontal grasp.#### **Step 3: Position the Grasp**- **Grasp Point**: The grasp should be placed on the **side of the fruit** that is closest to the basket.- **Grasp Point Location**: The grasp should be placed on the **side of the fruit** that is closest to the basket. This ensures that the grasp is stable and secure.#### **Step 4: Apply the Grasp**- **Grasp Action**: Use the robotic arm to grasp the fruit from the side.- **Grasp Force**: Apply a moderate force to ensure the fruit is securely held without slipping.---### **Final Grasp Plan**- **Grasp Method**: Vertical grasp- **Grasp Point**: Side of the fruit, closest to the basket- **Grasp Action**: Use the robotic arm to grasp the fruit from the side- **Grasp Force**: Moderate---### **Final Answer**The robotic arm should use a vertical grasp on the side of the fruit, closest to the basket, to securely hold the fruit. The grasp should be applied with a moderate force to ensure stability and safety.

Ответ содержит избыточный текст и повторения, но семантика сцены распознана корректно.

Архитектурная философия AX650N: гетерогенный конвейер

AX650N можно сравнивать с другими китайскими SoC (RK3588, Kendryte K230, Sophgo BM1688), но наиболее показательно сравнение с лидером Edge ML — NVIDIA Jetson. Jetson Orin и AX650N решают одну задачу — Edge ML для Vision — принципиально разными способами.

Jetson Orin — это вертикально однородная архитектура. CUDA-ядра умеют всё: свёртки, attention, resize, морфологию, softmax и так далее. При разработке реализуется один CUDA-граф, который исполняется на одном пуле вычислительных ресурсов. Система предсказуема и гибка — любая операция выражается через CUDA-примитивы.

AX650N — это горизонтально гетерогенная архитектура. Каждый класс операций имеет собственный аппаратный IP-блок. На самом деле, большинство китайских AI-capable SoC строятся именно по такому принципу. Небольшое сравнение:

На Jetson Orin, если нужно одновременно запустить детектор объектов и интеллектуальное ISP-шумоподавление, оба занимают SM. Конкуренция за один пул вычислительных ресурсов неизбежна — планировщик CUDA вынужден мультиплексировать через CUDA streams.

На AX650N ISP с GDC и инференс NPU выполняются на физически отдельных аппаратных IP-блоках на одном кристалле SoC. Conv EU и GDC работают параллельно без конкуренции за вычислительные ресурсы — это аппаратный параллелизм с нулевыми накладными расходами планировщика. Но всё не так просто. 

Главная проблема AX650N: CMM и конкуренция за DDR-bandwidth

Оборотная сторона гетерогенности — все IP-блоки используют одну физическую RAM. Это не уникальная особенность AX650N — на Jetson Orin также реализована UMA (unified memory architecture), где CUDA-ядра, CPU, NVENC и ISP делят единую LPDDR5. Проблема конкуренции за DDR-bandwidth существует на обеих платформах. Разница — в том, насколько остро она проявляется.

Суммарная теоретическая пропускная способность AX650N — около 34 GB/s (два 32-bit LPDDR4x @ 4266 Mbps). Для сравнения, Jetson Orin NX имеет 128-bit LPDDR5 с пропускной способностью около 102 GB/s — разница в три раза. Но это не архитектурная особенность, разница в скорости памяти не играет ключевую роль.

Почему на AX650N конкуренция острее

На Jetson CUDA-ядра обращаются к RAM через иерархию кэшей (L1 -> L2 -> DRAM). L2-кэш на Orin составляет до 4 MB на кластер CUDA SM и способен удерживать горячие данные между вызовами одного слоя для разных элементов батча, снижая фактическую DDR-нагрузку. Компилятор CUDA умеет в coalescing — объединение транзакций 32 потоков warp’а в одну широкую burst-операцию с высоким КПД шины.

На AX650N каждый IP-блок — это конечный автомат с фиксированным паттерном доступа: SDMA делает burst определённого размера, ISP пишет построчно, MAU читает матрицу целиком. Нет универсального кэша второго уровня, который сглаживал бы транзакции между разными мастерами. AXI-арбитр просто решает, кто из мастеров получает доступ к шине в данный такт — и если одновременно активны SDMA (NPU), ISP, VENC и MAU, арбитр сериализует часть запросов, создавая stall’ы.

Конкретные bottleneck-сценарии

1. LLM-инференс как bandwidth-bound задача

При decode-фазе LLM SDMA каждый шаг перезагружает веса всех слоёв из CMM в OCM. Для Qwen3-2B-VL (~2.5 GB весов, 28 слоёв) при 10 токенах в секунду это ~25 GB/s только на загрузку весов NPU — 73% от всего доступного bandwidth. Именно поэтому реальная скорость Qwen3-2B-VL на AX650N составляет около 10-12 токенах в секунду: ограничивает не MAC-производительность EU блоков, а пропускная способность SDMA <-> DDR. Если в этот момент ISP пишет в CMM кадры с четырёх камер (ещё ~3 GB/s), конкуренция за DDR становится критической.

2. Маленький OCM как мультипликатор DDR-нагрузки

11 MB OCM достаточно для небольших CNN-моделей. Для LLM 11 MB OCM — это буквально ничто: один FFN-слой Qwen3-2B (hidden=2560, ffn=6912) — это 2560x6912x1 байт ≈ 17 MB. OCM при LLM инференсе используется лишь как staging-буфер для одного тайла за раз, что означает нагрузку на SDMA и по-факту OCM перестаёт использоваться по назначению.

Итоги

AX650N — это мощный Vision-конвейер. Каждый класс задач получает свой аппаратный блок: свёртки — Conv EU, геометрические преобразования — GDC, видео препроцессинг — VPU. Это даёт реальный параллелизм без конкуренции за вычислительные ресурсы, но не лишает от проблем с пропускной способностью памяти.

Из первых тестов можно сделать вывод, что чип хорошо справляется с Vision задачами, под которые и был адаптирован. YOLO работает в 125–140 FPS, Depth Anything — около 20–23 FPS, SuperPoint — 35 FPS. Qwen3-VL-2B генерирует ~12 токенов в секунду, что уже достаточно для задач высокоуровневого планирования в робототехнике, пусть и не в реальном времени. С точки зрения работы LLM и VLM главным ограничением на мой взгляд является не самая эффективная реализация оперативной памяти. В следующей статье я продемонстрирую результаты бенчмарков (как скорости работы, так и качества) для различных свёрточных моделей, визуальных трансформеров и LLM/VLM.

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