På WWDC26 udfordrede Apple den hidtidige tommelfingerregel i on-device AI: at hele modellen skal ligge i RAM. Med tredje generation af Apple Foundation Models, AFM 3, flytter Apple vægtsættet for en 20-milliarder-parameters model til flash og laster kun de nødvendige eksperter i RAM per prompt. Det er et arkitekturskifte, ikke en finpudsning.
I praksis har enterprise-arkitekter måttet vælge mellem kraftige, skybaserede modeller med værktøjsbrug og reasoning – eller små on-device modeller med lav latenstid og bedre privatliv, men lavere kapacitet. Apples budskab er: loftet på enheden kan hæves uden at sprænge RAM-budgettet.
DRAM som mur
On-device modeller er historisk blevet presset ned i størrelser, der kan være i enhedens DRAM. VentureBeat beskriver problemet klart: når hele vægtsættet skal ligge i RAM, når man hurtigt grænsen, længe før serverklassens modeller. Det matcher vores erfaringer: 3–7B parametre i praksis, ofte kvantiseret, fordi større sæt koster på batteri, termik og opstartstid.
RAM er hurtig; flash er langsom – og meget større. Den afvejning har holdt on-device småt. Det er præcis den knude, Apple forsøger at løsne.
Hvad Apple gør
AFM 3 er en familie på fem modeller, ifølge Apple og VentureBeat: to på enheden og tre på servere i Apples Private Cloud Compute. Den mest markante er AFM 3 Core Advanced, en 20B-parameter model, hvor vægtene ligger i flash frem for DRAM. Apple kalder tilgangen Instruction-Following Pruning (IFP). Flash er lageret; DRAM er arbejdsfladen.
Modellen ruter ikke som en klassisk Mixture of Experts, der skifter eksperter for hvert token – det ville kræve konstant vægt-swap mellem flash og RAM i inferenshastighed. I stedet vælges eksperter én gang per prompt, de indlæses, og derefter genereres alle tokens med den konfiguration. VentureBeat citerer Awni Hannun for netop den forskel.
Sådan virker det i praksis
En lille router-model vurderer prompten og udpeger et sæt eksperter til opgaven. De hentes fra flash til DRAM sammen med fælleslag, hvorefter generationen kører. Den aktive parameter-mængde ligger typisk omkring 1–4 milliarder afhængigt af opgaven; resten bliver i flash.
Eksperter skiftes ikke løbende, fordi NAND→DRAM-båndbredde og latenser ikke kan følge token-for-token. Derfor prompt-baseret routing. Konsekvensen: første token kan være dyrere ved cold load, mens efterfølgende tokens går hurtigere, hvis de samme eksperter genbruges. Cache-hit-raten i RAM bliver derfor central – også for batteriet.
Server når det er svært
Apple holder samtidig en skyvej åben. De tre servermodeller kører i Private Cloud Compute – på Nvidia-GPU’er i Google Cloud, ifølge Apple og VentureBeat. Privatlivsdiskursen er tydelig, men de tunge workloads afvikles i Googles datacentre under Apples kontrolflade.
For enterprise betyder det adgang til stærkere reasoning og værktøjsbrug i skyen, uden at data forlader PCC-kapslen. Til gengæld følger leverandørkæde, aftaler og dokumentationskrav – især i det offentlige, hvor man skal kunne vise, hvor inferens kørte, og hvem der havde fysisk adgang til hvad.
Hvad det betyder for arkitekter
For danske arkitekter er dette en ny justerskrue. On-device kan bære større opgaver: lokal dokumentsammenfatning, semantisk søgning i offline kundedata, billetassistent i field-apps – og enkle agent-trin med lokale værktøjer. Ikke alt, men mere end før.
Latenstid først: forvent hurtige svar, når de rigtige eksperter allerede er varme i RAM. Cold loads koster. Planlæg derfor warm-up, forudindlæsning af ekspertsæt til de hyppigste opgaver, eller små forprompter, der guider routeren. Vi har set effekten i en feltapp hos en dansk kunde, hvor offline var afgørende: en lille bootstrap-procedure gjorde forskellen. Det er en workaround – men den virker.
Privatliv og governance
On-device beskytter data, medmindre man bevidst offloader. Kobles servermodeller på via Private Cloud Compute, starter governance-arbejdet: hvad logges hvor, hvordan revideres det, og kan routing-beslutninger dokumenteres per forespørgsel. Her er et hul: dokumentationen beskriver ikke tydeligt, hvornår enhedsforespørgsler skifter til sky, eller hvordan det eksponeres til udviklere.
For offentlige og regulerede organisationer kræver det synlige kontroller: en “no-offload”-tilstand i kritiske flows, eller revisionslog, der bekræfter lokal inferens og viser, hvad der eventuelt blev overført. Test det under realistisk belastning – ikke kun i demoer.
Omkostninger og TCO
Mindre cloud-trafik kan sænke driftsudgifter, men kompleksitet flytter til klienten: flere kodeveje, RAM-budgettering, I\/O-optimering, OTA-strategi for modelopdateringer samt test af varm\/kold-mønstre. Det koster tid – og måske hardware, hvis ældre enheder er begrænsede på flash-hastighed.
Lav en TCO over 12–36 måneder. Hvor ofte opdateres vægte? Hvor meget skrives til flash? Slid på NAND er en reel faktor, og Apple deler ikke konkrete write-endurance-tal i denne kontekst. Læg et konservativt budget og mål i pilot.
Hardware og OS-krav
Det er ikke plug-and-play. Prompt-routing kræver hurtig og stabil I\/O fra flash til RAM, hvilket forudsætter OS-integration og ofte driveroptimering til Apples silicon. Her har Apple en fordel. Spørgsmålet er, hvor meget tredjepartsapps kan bruge direkte, og hvad der kræver Apple-godkendelse eller specifikke SDK-rammer.
Dokumentationen beskriver arkitekturen, men ikke adgangslag, latency-SLA’er eller termiske budgetter i lange sessioner. Marco Abis peger også på manglende metrikker for energi, båndbredde og varme – netop de nøgletal, der afgør produktionsegnethed på device. Det er stadig åbent.
Drift i hverdagen
Når vægtene bor i flash, opstår nye driftsvalg: hvilke ekspertsæt caches i RAM, hvor længe, og hvornår de tømmes. Hurtige kontekstskift mellem opgaver med meget forskellige eksperter kan give UI-hak, hvis styringen er forkert.
I en dansk feltapp betød offline-krav, at batteri pludselig blev en produktbeslutning. Vi brugte kvantisering og distillation for at holde mest muligt lokalt, men savnede en klog prompt-router. Med AFM 3-tilgangen giver det mening at genbesøge designet – uden at love mirakler.
Migration og hybrid
Start smalt, hvis I vil prøve arkitekturen: én use case som dokumentklassificering eller en fokuseret chatassistent med kort kontekst. Mål latenstid ved cold og hot loads, og mål batteri over 24 timer. Log cache-hit-rater for eksperter, hvis Apple eksponerer det – ellers afled tal via latenstid og energiforbrug.
Næste trin er hybrid: lad en controller på enheden afgøre lokalt vs. sky efter tre parametre – datafølsomhed, latenstid, kompleksitet. En regel kan være: “Fagtermer og tabeludtræk køres lokalt; flertrins-reasoning med tool calls sendes til AFM 3 Cloud Pro.” Læg en økonomitærskel på serverkald, så månedsslutten ikke overrasker.
Modelops på kanten
Edge kræver disciplin. 4-bit kvantisering af udvalgte eksperter kan være forskellen mellem hot cache og konstant udskiftning. Distillation hjælper med at holde størrelsen nede til standardopgaver. Overvej en lokal LRU-cache af ekspertsæt baseret på teamets hyppigste prompts i arbejdstiden. Sæt telemetry på – ikke indhold, men timings for load, generate, evict.
OTA-strategi er nødvendig. Segmentér vægte, så hyppige opdateringer ikke skriver hele pakken. Planlæg vedligeholdsvinduer, især på ældre enheder. Test wear-leveling. Apple oplyser ikke den praktiske skriveomkostning ved hyppige ekspertopdateringer – mål det i pilot.
Begrænsninger og huller
Der mangler feltdata på NAND→DRAM-latenser i realistiske apps, og der er ingen klar metode til at forudsige eller inspicere routerens valg og eventuel offload til sky i logs. Vi mangler også indsigt i, hvor deterministisk ekspertvalget er under belastning for identiske prompts.
Det efterlader åbne spørgsmål efter en stor annoncering. Apple lover flere tekniske rapporter; indtil da bør enterprise-arkitekter validere i egne miljøer – med målinger, ikke slides.
Konkurrence og marked
Google har presset på on-device via NNAPI og Gemini Nano. NVIDIAs kant-stack står stærkt i industri og robotik, men telefoner er Apples hjemmebane. Hvis AFM 3 virker i praksis, rykker det forventningen til, hvad en telefon kan alene.
For danske indkøbere giver det en ny forhandlingsmulighed: mindre afhængighed af dyre server-SKU’er til standardopgaver – men også tættere binding til én OS-leverandørs metode. Notér, at servermodellerne kører på Nvidia-GPU’er i Google Cloud: fleksibel skalering, men flere led i leverandørkæden, der skal vurderes i risikomodellen.
Hvad man gør nu
Tre skridt i morgen: 1) Vælg en lille use case med høj dataværdi og klar offline-gevinst. 2) Byg en pilot, der logger cold\/hot expert loads, måler energi og tid, og tester en enkel warm-up. 3) Kør en 24-måneders TCO, der inkluderer kundesupport og OTA-vedligehold – ikke kun GPU-minutter.
En note fra et kundemøde i Odense, hvor kaffemaskinen lød som en traktor, står stadig: man forstår først forskellen, når man har det i hånden. AFM 3 ændrer rammebetingelserne for modellen. Resten er drift, målinger og stædighed.
Kildegrundlag og usikkerheder
De centrale tekniske påstande om DRAM-flaskehals, flash-lagring af vægte, prompt-routing og IFP stammer fra VentureBeat og bekræftes i Apples research-oversigt om AFM 3. Oplysninger om modelportefølje, samarbejde med Google og Private Cloud Compute stammer samme steder. Hvor tal mangler – write-endurance, præcise latenser under pres og synlighed af offload-beslutninger – markerer vi det som åbne spørgsmål, indtil Apple eller uafhængige tests leverer data.
Skulle kilderne senere divergere, opdaterer vi. Lige nu er billedet konsistent, men ufuldstændigt – hvilket er fint. Det tvinger til målinger i virkeligheden frem for gæt i præsentationer.
