On-device AI · geheugencheck

Draait zware on-device AI op jouw iPhone?

Een groot spraak- of taalmodel lokaal draaien is niet alleen een kwestie van opslag. De échte muur is geheugen: iOS killt een app (jetsam) zodra die boven een per-app-limiet komt — en die limiet ligt vaak vér onder het totale RAM. Het venijn zit in de allereerste keer: het model compileert dan naar de Neural Engine, en die compile piekt veel hoger dan het normale gebruik daarna. Kies je toestel en een model en zie of het past.

Checker

Welke iPhones halen dit model?

Per RAM-klasse, voor het hierboven gekozen model. De verdict kijkt naar de eerste-compile-piek tegen het geschatte jetsam-plafond van die klasse — dat is de bindende drempel, niet de schijfgrootte.

Waarom dit zo werkt

De eerste keer is het zwaarst — daarna gecached

CoreML compileert een model bij de eerste load naar een toestel-geoptimaliseerd formaat (.mlmodelc) en zet dat op schijf. Die eerste ANE-compile piekt fors: een ~600 MB Whisper-model dat in gebruik onder de 2 GB blijft, mat tijdens de eerste compile ~2,33 GB (eigen meting, iPhone 17 Pro Max). Volgende keren hergebruiken de gecachte binary — veel lichter en sneller (FluidAudio mat ~3,4 s koud vs ~0,16 s warm, ~20×).

Gevolg: een toestel dat het model in dágelijks gebruik prima zou trekken, kan op de eerste start alsnog jetsamen — en omdat de crash midden in de compile valt, wordt de cache nooit weggeschreven en start het model ook later niet. De compile-piek is dus de drempel die telt, niet de schijf- of inference-footprint.

De jetsam-limiet — vaak ~de helft van je RAM

Apple publiceert de per-app-geheugenlimiet niet. Empirisch ligt hij rond 45–60% van het totale RAM. Het hardste anker is de crash-string jetsam mem limit: ActiveHard 2098 MB (fatal) op 4 GB-toestellen (iPhone 12/12 mini). Daaronder schaalt het mee, maar niet strak lineair — sommige 6 GB-toestellen zijn in logs gemeten op ~2,1 GB, dichter bij 4 GB dan je zou denken. De Increased Memory Limit-entitlement (iOS 15+) tilt het plafond op, met een door Apple niet-gepubliceerd bedrag.

Live meten in je eigen app

Wil je het niet schatten maar weten: os_proc_available_memory() (C-API, iOS 13+) geeft terug hoeveel geheugen je app nog mag pakken vóór jetsam toeslaat. Dat is de betrouwbare runtime-check — beter dan de oude task_info/phys_footprint-trucs. Roep 'm vóór een zware model-load aan en val terug op een lichter model als de marge te klein is.

Eerlijk over de cijfers. RAM per toestel is hard. De jetsam-plafonds zijn best-beschikbare schattingen (geen officiële Apple-tabel); 2 GB op 4 GB-toestellen is het sterkst onderbouwd, 8 GB en 12 GB zijn extrapolatie. De compile-piek van Whisper-turbo (~2,33 GB) en Parakeet's footprint zijn eigen/afgeleide metingen, niet onafhankelijk herhaald. LLM-footprints zijn vuistregels (~0,5–0,75 GB per 1B bij 4-bit + KV-cache, groeit met contextlengte). Gebruik dit als richting, niet als garantie — meet de echte piek met os_proc_available_memory() op het doeltoestel.

Bronnen: WhisperKit-paper (arXiv 2507.10860) · WhisperKit-issue #112 · Apple coremltools FAQ (mlmodelc-caching) · Apple developer forums (2098 MB ActiveHard) · os_proc_available_memory · FluidAudio benchmarks. Gedestilleerd uit het bouwen van Versta (lokale NL-ondertiteling) en zijn engine-forks.