The STM32 model zoo is reference models that fit in a microcontroller

The models are selected for the hardware, not for the leaderboard

The STM32 AI model zoo is a collection of reference machine learning models that are optimized to run on STM32 microcontrollers, available on GitHub as a resource for anyone looking to add AI capabilities to STM32-based projects.

The word optimized here carries the whole design constraint. A model that scores well on a server is not a model that fits into a microcontroller's memory, and the zoo's premise is that the interesting engineering is the fitting, not the training.

The collection is application-oriented rather than architecture-oriented. There is a large collection of application-oriented models ready for re-training, and pre-trained models on reference datasets available across several frameworks.

Each use case directory in the repository follows the same pattern. image_classification/, object_detection/, face_detection/, pose_estimation/, semantic_segmentation/, instance_segmentation/, re_identification/, audio_event_detection/, arc_fault_detection/, depth_estimation/, hand_posture/, human_activity_recognition/, neural_style_transfer/ and speech_enhancement/.

So the organisation is by task, which is the axis an application developer starts from, and each directory has a README that defines the task and lists the suitable deployment targets.

The model zoo was developed internally at STMicroelectronics and open-sourced for the community, and the 3.0 release notes record that the Model Zoo is hosted on Hugging Face as well, which is where you would go for the weights.

Each use case names the boards it has been checked against

The use case table is the most useful part of the documentation for an adopter, because it maps each task to specific hardware.

Image Classification is described as classifying the content of an image within a predefined set of classes, with suitable targets including the STM32H747I-DISCO, the NUCLEO-H743ZI2, the STM32MP257F-EV1 and the STM32N6570-DK. Object Detection detects, locates and estimates the occurrences probability of predefined objects from input images, with the same family of targets.

Face Detection detects, locates and estimates the occurrences probability of predefined faces and keypoints from input images, listed for the STM32H747I-DISCO and the STM32N6570-DK. Pose Estimation detects key points on specific objects such as people, hand and face, with the STM32MP257F-EV1 and the STM32N6570-DK listed as suitable targets.

Semantic Segmentation associates a label to every pixel in an image to recognise a collection of pixels that form distinct categories.

The pattern across the table is that the H7 series, the MP2 Linux-capable MPU and the N6 discovery kit cover the range from a microcontroller with an accelerator, through an application processor running Linux, to the newest edge AI hardware.

What the table also gives you, indirectly, is the deployment code locations. Each entry links into the stm32ai-modelzoo-services repository under application_code, with a directory per family such as STM32H7 and STM32MP-LINUX/STM32MP2, which is where the generated application code for that target lives.

PyTorch joined TensorFlow and ONNX in 4.0

The most significant change in the project's history is the arrival of PyTorch, and the announcement puts it plainly: the STM32 AI model zoo now includes comprehensive PyTorch support, joining TensorFlow and ONNX, with a vast library of PyTorch models integrated into the end-to-end workflows. Whether you want to train, evaluate, quantize, benchmark or deploy, everything is there, plus the flexibility to choose between PyTorch, TensorFlow and ONNX.

The 4.0 release notes describe how much work that was. There is major PyTorch support for Image Classification and Object Detection, new training and evaluation scripts for PyTorch models, a unified workflow for TensorFlow and PyTorch, a Python software architecture rework, expanded model selection and improved documentation, and performance and usability improvements.

The framework version support in 4.0 was Keras 3.8.0, TensorFlow 2.18.0, PyTorch 2.7.1 and ONNX 1.16.1. Pinning those versions tells you how old that release is and what it expects, and it is worth checking them against your own environment before you start.

The 4.0 release also added new use cases in Face Detection, Arc Fault Detection and Re-Identification, and new mixed precision models with weights at 4 bits and activations at 8 bits for the Image Classification and Object Detection use cases. Mixed precision with 4-bit weights is how you get a model into the memory of a part that would not take 8-bit weights, and having it shipped as a standard variant rather than a hobby is the useful part.

Version 4.1, published in April 2026, is a smaller release: support for STEdgeAI Core v4.0.0, Audio Event Detection updated to support deployment on STM32U3, the YOLO26 model added, and multiple bug fixes and quality improvements.

The workflow tools live in a separate repository

The zoo is models, and the tooling around them is elsewhere, which is a division worth understanding before you clone anything.

Scripts to easily retrain, quantize, evaluate or benchmark any model from user datasets, as well as application code examples automatically generated from a user AI model, are in the stm32ai-modelzoo-services GitHub repository. The model zoo repository itself is the model collection, with a README per use case and the weights.

So the intended workflow has two repositories. You pick a use case and a model from the zoo, and you use the services repository to retrain, quantize, evaluate or benchmark it on your own data, and to generate the application code for your target.

The zoo also says that these models can be useful for quick deployment if you are interested in the categories they were trained, and that training scripts are provided to do transfer learning or to train your own model from scratch on a custom dataset. That is a useful framing of the two modes of use: take a pre-trained model as is if your problem matches its categories, or retrain it if it does not.

Performance metrics are provided on reference STM32 MCU, NPU and MPU targets, for both float and quantized models. That distinction between float and quantized metrics is the one to read carefully, because the quantized number is the one your deployed model will produce, and the two are not the same measurement.

STEdgeAI Core and the deployment toolchain are the version constraint

Every recent release ties itself to a version of STEdgeAI Core, and that is the dependency that will bite you.

Release 4.1 supports STEdgeAI Core v4.0.0, and release 4.0 also lists support of STEdgeAI Core v4.0.0. Release 3.2 supported STEdgeAI Core v2.2.0, which the notes describe as STM32Cube.AI v10.2.0, and added support of X-Linux-AI v6.1.0 for MPU targets.

So the model zoo, the model conversion tool and the runtime are released together and are expected to match. The 3.2 release also brought new use cases in StyleTransfer and FastDepth, new models with Face Detection in the Object Detection use case and Face Landmarks in the Pose Estimation use case, and an architecture and code base clean-up.

The 3.0 release was the one that changed the shape of the project. It added models compatible with the STM32N6570-DK board, expanded models in all use cases, expanded use case support to include Instance Segmentation and Speech Enhancement, added PyTorch support through the speech enhancement use case, and hosted the Model Zoo on Hugging Face.

Two other releases show the porting work. The 2.1 release added models compatible with the STM32MP257F-EV1 board and expanded use case support to include Pose Estimation and Semantic Segmentation. The 2.0 release was about an aligned and uniform architecture for all the use cases, which is the release where the current directory-per-use-case layout came from.

The licence field reads Other, a custom licence GitHub cannot classify, with a LICENSE.md file in the repository, and there is a SECURITY.md and a CODE_OF_CONDUCT.md alongside a CONTRIBUTING.md. The primary language is listed as unknown, which is what you would expect from a repository of models and per-model documentation rather than one codebase.

Where this fits against training your own model from scratch

The realistic comparison is with the two other ways to get a model onto an STM32, and each has a different cost.

Training from scratch is what the zoo's transfer learning scripts are there to avoid. A microcontroller target constrains the architecture, the input resolution and the memory footprint of the model, and a model that was designed for a server usually violates all three. The zoo's value is that the models were already chosen with those constraints in mind, and the metrics on reference hardware tell you whether your particular part can keep up.

Using a general-purpose model and converting it yourself is the middle path. This is where the framework flexibility pays off, since the zoo now offers the same use cases in PyTorch, TensorFlow and ONNX, and the ONNX route is the one most people would take for a deployment pipeline they already have. The risk is that the model you pick was not validated for the part, and you find out about the latency after the conversion work is done.

The third comparison is a vendor-specific NPU toolchain from a different supplier, which will often have its own model zoo with models tuned for its own accelerator. If you are committed to that hardware, that zoo is the relevant one, and this one becomes useful mainly for the training scripts and the application code generation.

What the STM32 zoo does well is the breadth of the use case list for one family of parts, and the fact that the deployment targets are named per use case rather than left to you. The application code in the services repository is generated from your model, which removes the part of an edge deployment that usually eats the most time and is the least interesting.

Editorial conclusion

Adopt the STM32 model zoo if you are putting machine learning on an STM32 and want a starting point that has already been chosen to fit the hardware, since the models come with performance metrics on reference MCUs, NPUs and MPUs for both float and quantized versions. Skip it if you need a production model for your own data, because the zoo is reference models plus training scripts for transfer learning, not a model library you can pick from by accuracy alone. Verify first which board you are targeting and check the use case table for it, that the STEdgeAI Core version in your toolchain matches the one the release you want expects, and that you understand the trained categories, since a model is only useful for the classes it was trained on.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. STMicroelectronics/stm32ai-modelzoo on GitHub