AFM 3 Core Advanced: How Apple Fits a 20B Model On Device

Direct answer: Apple AFM 3 Core Advanced is a 20-billion-parameter sparse on-device model that activates roughly 1 to 4 billion parameters for a request. Instead of holding every expert weight in active memory, Apple stores the full expert set in flash and selects a fixed subset for the prompt. A lightweight dense block makes the initial routing decision, and the system periodically reselects experts during generation. Apple calls the underlying approach Instruction-Following Pruning. The design reduces active memory compared with a dense 20B model, but it does not make storage bandwidth, prompt latency, battery use, or device eligibility disappear.

Quick decision table

Why ordinary mixture-of-experts routing is hard on a phone or Mac

A conventional sparse mixture-of-experts model may choose different expert weights token by token. That works when all weights remain in fast accelerator memory, but consumer devices cannot keep very large expert sets in DRAM without displacing the operating system and other applications. Moving a new expert from NAND for every token would make generation wait on storage. Apple's research reframes the routing interval: select a useful subnetwork for the instruction, load it, and keep it stable long enough to generate efficiently.

The published AFM 3 description says a lightweight dense block selects experts during initial prompt processing. Those experts are patched with shared static weights to create a dense model in DRAM. The router can periodically update the selected set during generation. That makes the memory requirement closer to the active subnetwork than the total 20B capacity, while still allowing different requests to use different knowledge and abilities.

Instruction-Following Pruning in plain language

Instruction-Following Pruning asks which parts of a large trained model are most useful for the instruction in front of it. Think of a reference library that keeps every book in storage but brings only the relevant shelf to the desk. The selection is not free. The system must interpret the prompt, load the chosen experts, and know when a different subset is required. The benefit is that the active working set can be much smaller than the total library.

This also explains why total parameter counts become a poor buying metric. A 20B sparse model with 1B to 4B active parameters has different storage, memory, and latency behavior from a dense 20B model. It may also behave differently across short edits, image prompts, dictation, and long conversations. Developers should quote total and active counts together and avoid turning either number into a quality guarantee.

What it may unlock for voice and creative apps

Apple describes AFM 3 Core Advanced as natively multimodal and connects it to expressive voices and higher-accuracy dictation. A creative app could use stronger local understanding to clean transcripts, preserve speaker intent, extract scene structure, or turn natural-language direction into typed production parameters. The model should not silently rewrite a script that must be spoken exactly. Use structured output and show the proposed changes before local TTS runs.

Murmur already separates language preparation from speech generation through its CLI and MCP workflow. That boundary remains useful even when the language model is more capable. A local LLM can prepare sections, names, and pronunciation notes; a TTS engine then produces and validates audio. The missing-word troubleshooting guide explains why exact script completion needs its own check.

The limits hidden by the phrase on device

On-device execution still has eligibility rules. Apple says Core Advanced targets its most capable systems. Storage space must hold the model, memory must hold the active subnet and caches, and flash reads consume time and energy. The operating system can update the underlying model, changing prompt behavior. A feature therefore needs capability checks, versioned evaluations, and a fallback that does not erase a user's work.

Do not assume the architecture is an open checkpoint that third-party apps can download or fine-tune freely. Developers interact through Apple frameworks and policies. For an app that requires a specific open model or deterministic deployment, compare Core AI and MLX. The AFM architecture is evidence of where local systems are going, not a universal replacement for app-owned models.

Evidence to collect before publication

Use Apple's architecture figure as a linked source rather than redrawing it without permission. Create an original explanatory diagram with three labeled stages: prompt routing, selected experts loaded from flash, and periodic reselection. Keep total and active parameter counts on the same visual. Add a small glossary for NAND, DRAM, sparse activation, and expert weights. Cross-link the purchasing implications to the existing local-model guide instead of guessing which unreleased or unsupported device tier will run Core Advanced.

• Official 20B total and 1B to 4B active figures
• Original prompt-level routing diagram
• No unsupported device-compatibility claim
• Clear separation of storage and active memory
• Model-version caveat for app evaluations

Reader worksheet

Create a one-page worksheet before acting on this Apple AFM 3 Core Advanced guide. Write the job, current baseline, minimum supported Mac, privacy requirement, model and runtime revision, acceptable failure rate, and the one result that would change your decision. Add measured values only after the test, and keep upstream claims in a separate column. Save links to raw output and licenses beside the row they support. Review the worksheet after seven days of real use, not only after a successful demo. Browse the Murmur research library for the related memory, privacy, model, and production checks that belong in the same decision.

Practical checklist

1. State total and active parameter counts together.
2. Separate storage size, active memory, KV cache, and working buffers.
3. Measure first response after an expert set is loaded and warm follow-up latency.
4. Test each supported OS model version with a fixed evaluation set.
5. Check device eligibility before exposing a feature or importing user data.
6. Keep an understandable non-AI fallback for critical editing tasks.

Frequently asked questions