Generated by Codex with GPT-5

What happened

Apple Machine Learning Research published Introducing the Third Generation of Apple’s Foundation Models, a June 8, 2026 research highlight describing the next foundation-model stack behind Apple Intelligence.

The post is interesting because it is not only a product-facing model update. It gives a compact view of how Apple is trying to make frontier-style capabilities fit an unusually constrained deployment model: some inference must happen on consumer devices, some can happen in Private Cloud Compute, and the privacy contract rules out training on private user interactions. That forces architecture, training, evaluation, hardware placement, and safety work to be treated as one system rather than as separate model-release details.

The new family has five models. AFM 3 Core is the next 3-billion-parameter dense on-device model. AFM 3 Core Advanced is a larger on-device multimodal model with a 20-billion-parameter sparse architecture that activates only about 1 to 4 billion parameters depending on the request. AFM 3 Cloud is the server-side general model. ADM 3 Cloud is the image creation and editing model. AFM 3 Cloud Pro is the highest-capability server model, aimed at harder reasoning and agentic tool-use workloads.

The broader engineering story is a placement strategy. Apple is not presenting a single giant model that serves every request. It is splitting work across dense local inference, sparse local inference, server-side multimodal reasoning, image generation, and a more capable cloud-pro model. Each tier is optimized for a different combination of latency, memory footprint, privacy boundary, silicon, and task difficulty.

The on-device architecture

The most technical part of the post is AFM 3 Core Advanced. A normal dense LLM has to keep all weights available during inference, and a conventional mixture-of-experts model still tends to require fast movement among many expert weights as tokens are generated. That is a poor fit for a phone or laptop, where DRAM is limited and flash storage is much slower than active memory.

Apple’s answer is to put the full model in NAND flash and make coarser routing decisions. The model uses Instruction-Following Pruning, an Apple research technique, so that a lightweight dense block selects a fixed set of experts during initial prompt processing. During generation, the system can periodically reselect experts, but it does not swap weights token by token. The selected routed experts are loaded into DRAM and combined with a large always-active shared-expert portion to form the active model for that request.

That design matters because it changes the memory limit from “the whole model must fit in DRAM” to “the active portion for this request must fit in DRAM.” Apple says the 20-billion-parameter model can run with roughly 1 to 4 billion active parameters. The model therefore behaves less like a static on-device model and more like an elastic local system whose effective size can change with task complexity.

There is an important tradeoff behind the design. Routing per prompt and periodically during generation is less flexible than token-level expert routing, but it avoids the bandwidth pattern that would make local sparse inference impractical. The point is not simply compression. It is an inference architecture shaped around the real memory hierarchy of consumer Apple silicon: fast DRAM, slower NAND, and tight latency expectations.

The server and image models

On the server side, Apple says AFM 3 Cloud builds on the Parallel-Track Mixture-of-Experts foundation it introduced in the previous generation. The post does not publish the full technical recipe, but it names two concrete goals of the upgrades: stabilizing training and improving the model’s ability to reason over and recall information inside the context window. That is a useful hint about where server-side scaling pressure has moved. For the cloud model, Apple is optimizing not just benchmark capability but long-context reliability for integrated operating-system features.

AFM 3 Cloud Pro is also strategically important because Apple says it worked with Google and NVIDIA to extend Private Cloud Compute to NVIDIA GPUs in Google Cloud. Apple is trying to preserve the privacy and attestation properties of Private Cloud Compute while still using hardware outside its own silicon stack for its most demanding server model. That is an infrastructure design problem as much as a model design problem: the serving environment has to expose enough accelerator capacity for high-end inference while keeping user data outside ordinary cloud-provider visibility and outside Apple’s own storage.

ADM 3 Cloud covers image creation, editing, and Genmoji-style generation. The implementation detail worth noticing is the split between a base image model and specialized adapters. The base model handles image creation and editing across aspect ratios and resolutions, while adapters support downstream product behaviors such as spatial reframing and touch-based edits. That is a familiar production pattern for foundation models: one general model carries broad generation ability, while narrow adapters encode feature-specific control without requiring a separate full model for every product surface.

Training and evaluation

Apple describes a shared training pipeline before model specialization. The models start from a common foundation, then branch into their architectures and use cases, adding multimodal capabilities such as audio, image understanding, long-context reasoning, and visual generation. Post-training combines supervised fine-tuning with multi-stage reinforcement learning. The final compression and deployment optimization is hardware-specific: Apple-silicon models are optimized for local execution, while AFM 3 Cloud Pro is optimized for NVIDIA GPUs.

The data statement is also part of the system design. Apple says it trains on a mix of public information, licensed or purchased data, open-source data, data from dedicated studies, and synthetic data. It also says it does not use users’ private personal data or user interactions to train these foundation models, and that it respects publisher opt-outs. That choice increases pressure on curation, synthetic-data generation, and post-training because the company is not relying on private product telemetry as a model-improvement shortcut.

The evaluation section is useful because it separates model-level and feature-level checks. Model responses are judged by in-house human graders on instruction following, truthfulness, presentation, and image understanding. Apple reports that AFM 3 Core is preferred over the 2025 on-device baseline on 45.6 percent of general text prompts versus 23.3 percent for the baseline. For image understanding, users preferred the new on-device model over the previous generation more than 61 percent of the time when one response was preferred.

The server-side reported gains are larger. AFM 3 Cloud is preferred over the 2025 server model on 64.7 percent of general text prompts versus 8.7 percent for the prior model, and Apple reports relative improvements in response satisfaction and instruction following. AFM 3 Cloud Pro then improves further over AFM 3 Cloud, especially in math and image-understanding slices.

The feature-level results are more operationally grounded. For expressive voice, AFM 3 Core Advanced runs at a 1-billion-parameter activation size and beats Apple’s current text-to-speech baseline on mean opinion score. For dictation, it is preferred over the existing production dictation system across dimensions such as punctuation, casing, layout, disfluency handling, meaning capture, and style. That distinction matters: a model can be better in abstract chat evals and still fail a product surface. Apple is measuring the system at the level where users experience it.

Why it matters

The post shows how different the engineering problem becomes when a foundation model is not only an API endpoint. Apple is integrating models into operating systems, so the system has to respond quickly, preserve battery and memory, run locally when privacy or latency demands it, escalate to private cloud when capability requires it, and support multimodal features that are not framed as chat.

The AFM 3 Core Advanced architecture is the clearest example. The sparse model is not being used only to reduce serving cost in a data center. It is being used to make a much larger model usable on local hardware by aligning expert activation with the device memory hierarchy. That is a useful direction for on-device AI generally: instead of forcing small dense models to carry every local workload, a system can keep a larger sparse model on storage and load the right active subset for a given request.

The Private Cloud Compute extension is another important pattern. If advanced assistants need occasional large-model reasoning, then purely on-device AI will not be enough. But ordinary cloud inference weakens the privacy story. Apple’s approach is to treat the cloud accelerator environment as part of the trusted computing boundary, using private infrastructure guarantees while still expanding to NVIDIA GPUs in Google Cloud for the highest-capability model. The engineering takeaway is that privacy-preserving AI at scale depends on infrastructure design, not only model training policy.

There are still open questions. Apple does not publish enough detail to evaluate the full training recipe, the sparse-routing failure modes, the cost of expert reselection, the exact privacy implementation for the Google Cloud and NVIDIA path, or how the models compare on public benchmarks. The post says a more detailed technical report will come later. Until then, the vendor-reported evaluation results should be treated as directionally useful rather than independently verified.

Takeaway

Apple’s AFM 3 post is a useful snapshot of model engineering under product and privacy constraints. The core move is not one model getting bigger. It is a tiered architecture: small dense local inference, elastic sparse local inference, private cloud models, a specialized image model, and a higher-capability cloud-pro model for difficult tasks.

The broader lesson is that production AI systems are increasingly shaped by placement. The important questions are where each request runs, which weights are active, what memory tier holds the inactive weights, which accelerator executes the model, what data can cross the boundary, and how quality is measured in the actual feature. Apple’s third-generation foundation-model stack is a clear example of that shift from model release to full deployment architecture.