Architecture-specific kernels
Optimized code paths target instruction sets such as ARM NEON, x86 SIMD extensions, and WebAssembly SIMD.
HIGH-EFFICIENCY CPU INFERENCE
XNNPACK turns neural network operators into fast CPU execution paths
Download the XNNPACK source archive and understand how its optimized kernels accelerate inference across ARM, x86, WebAssembly, RISC-V, and supported mobile, desktop, server, and web environments.
Targets ARM · x86 · WASM · RISC-V
License BSD-style
Build baseline C11 · C++17 · Python 3
INPUT
Tensor
NHWC layout
OPERATOR GRAPH
Conv · Pool · Activation
subgraph scheduling
CPU DISPATCH
SIMD micro-kernels
runtime architecture selection
What XNNPACK is
A low-level performance layer beneath modern inference frameworks
XNNPACK is not a desktop app with its own interface. It is a highly optimized neural network inference library designed to provide fast operator implementations for CPU execution. Frameworks can use these primitives for convolutions, pooling, fully connected layers, activations, tensor transforms, and other common inference work.
Instead of using one generic implementation everywhere, XNNPACK selects architecture-appropriate kernels and execution paths so a model can better use SIMD instructions, available CPU threads, and platform-specific capabilities.
Typical role: a backend or delegate inside a larger machine learning runtime rather than a tool used directly by end users.
Operator coverage
representative groups
Spatial operatorsConvolution, depthwise convolution, pooling, resize, depth-to-space
Elementwise mathAdd, subtract, multiply, divide, min, max, squared difference
Activation functionsClamp, ReLU variants, sigmoid, tanh, ELU, HardSwish, PReLU
Tensor transformsConvert, copy, transpose, channel shuffle, quantize and dequantize paths
Core capabilities
Six practical reasons frameworks use XNNPACK
Each capability addresses a real CPU inference challenge without relying on decorative or invented performance claims.
Runtime dispatch
The library can select an appropriate micro-kernel path based on the target architecture and available CPU features.
Broad operator coverage
Common convolutional, pooling, fully connected, activation, elementwise, and tensor transformation operators are included.
Multi-threaded execution
Work can be distributed through a thread pool so supported workloads can use multiple CPU cores effectively.
Framework integration
XNNPACK is used through higher-level runtimes and backend integrations instead of requiring every app to call low-level operators directly.
Portable source integration
The source can be built for mobile, desktop, server, embedded, and web targets with an appropriate toolchain.
How it works
From model runtime to optimized CPU kernel
XNNPACK usually sits below the model-facing API. The framework prepares an execution plan, hands supported work to the backend, and the backend dispatches optimized kernels for the current CPU.
01
Framework receives the modelTensorFlow Lite, ExecuTorch, ONNX Runtime, or another supported integration loads the graph.
02
Supported operators are delegatedCompatible graph nodes are prepared for XNNPACK execution.
03
Architecture path is selectedThe runtime uses kernels appropriate for the target CPU and instruction set.
04
Inference output returnsResults flow back through the framework to the application.
model graph→framework delegate→XNNPACK subgraph→CPU micro-kernel→output tensor
SOURCE ARCHIVE
Download XNNPACK from the project source repository
The main button below uses the direct ZIP archive for the current master branch. XNNPACK is source code, so the archive must be extracted and built or integrated through a supported framework workflow.
Minimum language standardsC11 and C++17
Required scripting runtimePython 3
Package typeSource ZIP archive
XNNPACK-master.zip
Official source branch archive
Download Source ZIP
No installer or executable is included. Extract the archive before building.
Compatibility
Architecture and platform coverage
Support varies by architecture, operating system, and available instruction set. These groups reflect the official project’s listed targets.
Primary CPU familiesproduction targets
ARM
ARM64, ARMv7, ARMv6
ARM64 spans Android, iOS, macOS, Linux, and Windows. ARMv7 uses NEON on Android; ARMv6 uses VFPv2 on Linux.
x86
x86 and x86-64
Supported up to AVX512 across Windows, Linux, macOS, Android, and the iOS simulator.
WEB
WebAssemblyMVP, SIMD, and experimental Relaxed SIMD
RV
RISC-VRV32GC and RV64GC targets
HX
HexagonHVX-enabled target support
Build reminderArchitecture support does not guarantee that every operator, precision mode, or framework integration behaves identically on every platform.
Build overview
A clean path from ZIP file to compiled library
Use the project’s build documentation for platform-specific flags. The simplified workflow below helps you understand what happens after the source archive is downloaded.
Read the complete download guide1
Extract the archiveUnpack the ZIP into a short, writable project path.
2
Install prerequisitesPrepare Python 3, a C11/C++17-capable compiler, and the build tools required for your target.
3
Configure the targetSelect the intended operating system, architecture, instruction set, and library options.
4
Compile and integrateBuild the library, run relevant tests, and link it through your application or framework workflow.
Where it fits
Practical XNNPACK deployment scenarios
These are infrastructure-level use cases rather than standalone-app features.
On-device inference inside Android and iOS applications
Use a framework integration that delegates supported operators to optimized CPU kernels when a GPU or dedicated accelerator is unavailable, unsuitable, or unnecessary.
ARM64low-level backendframework-managed
Browser inference with WebAssembly SIMD
Support CPU-based inference paths in web runtimes that can take advantage of modern WebAssembly capabilities.
Embedded and edge CPU targets
Build for supported ARM, RISC-V, or other listed architectures when a compact native inference backend is needed.
Native CPU inference in desktop and service runtimes
Use supported x86, x86-64, or ARM64 targets where a native runtime needs optimized operator execution without requiring a dedicated accelerator.
Framework backend development
Integrate XNNPACK beneath a higher-level model API to handle supported operator execution and architecture-specific kernel dispatch.
Before you build
Know when XNNPACK is the right layer
A good fit when
- You are integrating or configuring a machine learning runtime.
- Your workload must run efficiently on supported CPU architectures.
- You need optimized implementations of common neural network operators.
- Your project can build native source code or use an existing framework backend.
Not the right starting point when
- You expect a click-to-install desktop application with a graphical interface.
- You only need to train models rather than run inference.
- Your target depends entirely on unsupported operators or hardware-specific acceleration.
- You do not control the runtime, build system, or backend configuration.
Setup guides
Continue with a focused XNNPACK guide
Download
How to download XNNPACK the right way
Understand source archives, repository branches, extraction, and the next build step.
Read guide →
Windows
Building XNNPACK on Windows
Prepare a Windows toolchain and avoid common path, compiler, and configuration problems.
Read guide →
Troubleshooting
XNNPACK not building? Try this
Work through dependency, compiler, generator, architecture, and cache issues in a sensible order.
Read guide →FAQ
Common questions about XNNPACK
Clear answers for developers deciding whether to download, build, or use XNNPACK through a framework.
XNNPACK provides optimized low-level neural network operators for fast CPU inference. Higher-level runtimes and frameworks can send supported parts of a model graph to XNNPACK so those operations run through architecture-specific kernels.
No. XNNPACK is a source-code library and inference backend, not a graphical desktop program. Developers build it directly or access it through a framework integration such as a delegate or execution provider.
The official project supports major CPU targets including ARM64, ARMv7, ARMv6, x86, x86-64, WebAssembly, RISC-V, and Hexagon. Exact instruction-set and platform support depends on the selected target and build configuration.
The project lists C11, C++17, and Python 3 as minimum requirements. You also need a compatible compiler, build system, and target-specific toolchain for the operating system and architecture you plan to use.
Yes. XNNPACK can be used through supported framework backends and execution providers, including integrations in TensorFlow Lite and ONNX Runtime. Setup steps and supported operators vary by framework version and platform.
No. The direct download is a source archive rather than a ready-to-run application. Extract it, install the required toolchain, and build it, or use a framework that already integrates XNNPACK.
XNNPACK is distributed under a permissive BSD-style license. Commercial use is generally possible, but you should review the license file included with the source and follow your organization’s compliance requirements.
Extract the archive, read the included build documentation, install the required compiler and tools, choose your target architecture, and follow the platform-specific configuration steps before building or integrating the library.
Yes. XNNPACK is commonly used for CPU inference on Android, particularly on ARM-based devices. It is often accessed through a supported mobile framework rather than integrated as a standalone application.
Yes. XNNPACK can target Apple mobile hardware when it is built with a compatible toolchain and used through a supported integration. Actual performance depends on the model, operators, threading, and device CPU.
Yes. WebAssembly is one of the supported targets. Browser performance depends on the available WebAssembly features, SIMD support, runtime configuration, model structure, and the browser and device being used.
XNNPACK is designed primarily for optimized CPU execution. It does not function as a general GPU backend. A framework may combine XNNPACK CPU execution with other delegates or providers for unsupported graph sections.
XNNPACK contains optimized implementations for many common neural network operators. Exact coverage changes over time, so review the current project documentation and your framework’s delegation report for the model you are deploying.
It uses architecture-aware kernels, vector instructions, cache-conscious data access, operator fusion opportunities, and efficient threading. The gain varies with tensor shapes, operator coverage, CPU features, and runtime configuration.
Yes. Supported integrations can use thread pools or runtime threading options. More threads do not always produce better results, so benchmark realistic workloads and consider device thermals, contention, and model size.
A framework delegates only operators and tensor configurations that its XNNPACK integration supports. Unsupported nodes remain on another execution path, which is normal for models with mixed operator coverage.
Enable the framework’s diagnostic or verbose logging and inspect delegation or execution-provider messages. You can also compare benchmark results with XNNPACK enabled and disabled using the same model, inputs, and thread settings.
It can be useful for CPU-based server workloads, especially when low latency, portability, or efficient operator execution matters. Benchmark it against other backends using your actual model, batch size, and hardware.
Check the compiler version, Python version, submodules or dependencies, selected generator, target architecture, and cached build files. Recreate a clean build directory after correcting configuration problems.
Use representative models, realistic input sizes, warm-up runs, repeated measurements, fixed thread settings, and the same power conditions. Compare median latency and throughput rather than relying on a single run.