ExecuTorch 1.4 Expands Android and Qualcomm On-Device AI Support
ExecuTorch 1.4, released on 7 August 2026, expands Android Kotlin APIs, Qualcomm QNN quantisation and profiling, Arm model export, and embedded support. These changes give developers more ways to prepare PyTorch models for local execution. They do not establish a universal speed gain, because performance still depends on the model, backend, phone, quantisation, and application configuration.
On this page
Android and Qualcomm support moved forward
PyTorch released ExecuTorch 1.4 on 7 August 2026. ExecuTorch is a runtime and deployment toolchain for moving PyTorch models onto phones, computers, microcontrollers, and other edge devices.
The Android work continues a migration from Java to Kotlin. Version 1.4 moves the Module, TrainingModule, SGD, and language-model extension APIs to Kotlin, adds Kotlin examples, and expands Android end-to-end model tests. This is developer infrastructure rather than a new consumer feature, but it can reduce the amount of custom glue needed when an Android app embeds an ExecuTorch model.
Qualcomm's QNN backend gained 2-bit weight quantisation, multi-batch language-model quantisation, more operators, and tools for partitioning, tensor inspection, profiling, and heap analysis. The release notes describe the new format as 16a2w, with 16-bit activations and 2-bit weights. Smaller weights can reduce storage and memory traffic, although heavier compression can affect model quality and is not suitable for every model.
Arm, Vulkan, and embedded targets also changed
ExecuTorch 1.4 broadens Arm export and backend coverage for data types, dynamic shapes, profiling, and TOSA lowering. It adds export and evaluation coverage for SmolLM2 and Qwen3-VL, two model families that exercise text and vision-language workflows.
The Cortex-M work targets much smaller embedded processors. It covers additional CPU variants, scratch-buffer planning, CMSIS-NN integration, and an example runner for Espressif ESP32. These targets are relevant to narrow tasks with compact models, not evidence that a general chat model will fit a microcontroller.
Vulkan support now includes Linux and Windows desktop GPUs with opt-in Python wheel builds and a backend availability check. That desktop change does not automatically extend Android GPU coverage. ExecuTorch selects among portable kernels and hardware-specific backends, so the same model may take a different path on a Snapdragon phone, an Arm microcontroller, or a Windows GPU.
A runtime release is not a phone benchmark
The release notes list features and fixes, but they do not provide one comparable before-and-after Android benchmark. There is no single useful claim that ExecuTorch 1.4 makes local models a fixed percentage faster.
Actual results depend on whether a model can be partitioned onto an accelerator, which operators fall back to the CPU, how its weights were quantised, and how much memory the app reserves for prompts and generated tokens. Phone temperature, current memory pressure, and vendor software also affect repeated runs. Support for a format means that a deployment path exists. It does not prove acceptable latency, stability, or output quality on a particular device.
The 2-bit Qualcomm path needs especially careful evaluation. A smaller artifact may load with more headroom, yet aggressive quantisation can change answers. Developers should compare output quality against a less compressed reference, then measure cold loading, prompt processing, generation speed, peak memory, heat, and cancellation on the exact phones they intend to support.
App developers still own qualification
For Android teams already using PyTorch, version 1.4 is a practical reason to reassess Kotlin integration and Qualcomm deployment. The separated calibration, quantisation, compilation, and evaluation stages should make it easier to identify where a language or vision-language model fails instead of treating export as one opaque step.
Applications should expose only model and backend combinations they have tested. A model manager should verify the complete artifact, preserve the selected model, report loading and generation as separate states, and recover cleanly when the user stops a response. Download size and parameter count are not substitutes for this evidence.
For users, the release is an upstream improvement rather than an immediate upgrade to every local AI app. Its value appears when developers adopt the new APIs, select a compatible backend, and publish real-device results. Until then, the safest buying or download decision still comes from testing the exact app, model, and phone together.