Deep dives
Can Your iPhone Run AI Models? Apple Silicon, Explained
GPU, Neural Engine, unified memory: what the chip in your iPhone provides for running generative models locally.
By Mohit P · · Updated · 8 min read
Can your iPhone run generative AI models that make images on its own? Yes, and the reason is the chip. Apple silicon is several processors sharing a single pool of memory. That arrangement suits machine learning well enough that a picture-making model which once demanded a server GPU can now produce an image on a phone in seconds. (The technical name for that kind of model is a diffusion model.)
Saying “the chip is good at AI” skips the structure. This article covers which part of the chip runs the model, how GPU and Neural Engine execution differ, and how an iPhone is laid out differently from a gaming PC with a graphics card.
Three processors, three jobs
An Apple silicon chip carries three engines that matter for machine learning. Each one is strong at a different kind of work:
- The CPU is the all-rounder. It has a handful of powerful cores built for varied work full of decisions and branches. In an AI app it runs the show: loading models, scheduling work, handling the interface. But it is the wrong tool for the billions of repetitive multiplications an AI model needs.
- The GPU is the parallel workhorse. It has many simpler cores that all perform the same step across huge blocks of data at once. Running a trained model is almost entirely the multiplying of big grids of numbers (matrix multiplication), which is that shape of problem. The GPU is also fully programmable. It can run whatever new operations a fresh model design happens to need.
- The Neural Engine (ANE) is the specialist. It is fixed hardware built to run certain layers of a neural network extremely efficiently. For the workloads it fits, it delivers excellent performance per watt. The limit is in the word fits. It favors models prepared ahead of time, built only from the operations it supports, working on data of predictable size.
Unified memory
What the engines share matters more than the engines themselves. In a classic desktop PC, the graphics card is a separate island. It has its own memory, often 8–16 GB. Any data the GPU needs must be copied over from main RAM across a relatively slow connection. That card’s memory is a hard ceiling of its own. A model that does not fit in video memory is in trouble even on a machine with 64 GB of system RAM.
Apple silicon has no island. The CPU, GPU, and Neural Engine all read and write one physical pool of fast memory (unified memory). Two things follow. First, the GPU can use most of the device’s RAM instead of a small fixed slice. That is what makes model weights of several gigabytes possible on a phone at all. Second, nothing is ever copied from one processor to another. The CPU can fill a block of memory and the GPU can compute on that same block, at the same addresses. For work that bounces between coordination and heavy math, the skipped copies save time and battery.
The limit that remains is the size of the pool itself. Sharing memory means the model, the operating system, and every open app draw on one budget. iOS also enforces a strict ceiling on any single app, with no swap to fall back on. That subject has its own article on why RAM decides which models your iPhone can run.
Metal and MLX: how software reaches the silicon
Hardware needs a way in. Metal is Apple’s low-level programming interface (API) for the GPU. It plays the same role that CUDA plays on Nvidia hardware. Everything that runs on an Apple GPU goes through Metal in the end, from a game to a diffusion model.
Writing raw Metal by hand for machine learning is impractical, which is what MLX addresses. It is an open-source array framework from Apple’s machine learning research team, built specifically for Apple silicon. It looks like the NumPy-style libraries researchers already use. You describe math on arrays, and MLX compiles it and runs it on the GPU through Metal. It was designed around unified memory from the start, so it skips the copy-between-devices machinery that frameworks from the separate-card world assume. For an app running diffusion models on iPhone, MLX is the practical bridge between a model’s mathematics and the phone’s silicon.
GPU and Neural Engine routes
Both the GPU and the Neural Engine can participate in image generation. MLX gives developers a flexible GPU route. Core ML can execute supported prepared models across CPU, GPU, and Neural Engine, depending on their compute configuration and supported operations.
The Neural Engine is useful when the model has been converted into supported operations and shapes. That preparation can constrain model changes and memory strategy. GPU implementations allow different custom operations and scheduling choices. Neither route is universally faster.
The Neural Engine can run substantial diffusion work as well as smaller helper models. Onhand’s Core ML style packs request CPU and Neural Engine execution. Whether a particular operation uses a processor depends on the prepared model and runtime, so a route name is not a per-operation performance measurement.
What the chip does not solve
Apple silicon closed the speed gap enough to make local generation practical. A phone chip still delivers a fraction of the raw work per second of a data-center GPU. So a local model takes seconds per image where a server farm takes less. A phone also has no fan. Generate heavily for long enough and the device warms up, until the system lowers clock speeds to protect itself. And no chip feature squeezes a model into RAM it does not fit in. The largest frontier models remain out of reach on any phone today. What the chip provides is a floor that keeps rising: enough performance to make turbo-class diffusion models usable, on hardware you already carry.
How Onhand uses the silicon
Onhand uses more than one execution route. Turbo, Detailed Images, and Detailed Scenes use MLX on the GPU. Compact Turbo and the Core ML style packs request CPU and Neural Engine execution. A model’s packaging and supported operations determine the route; a device’s headline AI score does not establish its performance in the app.
Generation times depend on the selected model, quality, loading, and device temperature. Our Stable Diffusion on iPhone guide explains the memory techniques involved. For Core ML, Apple also publishes a Stable Diffusion implementation with CPU, GPU, and Neural Engine compute options.
The same memory and execution questions apply on a tablet; the AI image generator for iPad page covers what is the same and what to check before installing. For Apple’s own image generator, which in iOS 27 runs on Private Cloud Compute rather than on the device, see Onhand vs Image Playground.
Sources
Primary sources for the claims above, so you can check them rather than take our word for it.
- Apple, Metal documentation. The GPU compute API these models execute through.
- Apple, MLX documentation. Apple’s array framework built around unified memory.