Apple verlaagt stilletjes de maximale geheugenopties voor Mac mini en Mac Studio

Apple biedt kopers van de Mac mini en Mac Studio niet langer enkele keuzes voor geheugenconfiguraties van die kleine computers. De Mac mini is niet meer te koop met 32 of 64GB geheugen en de Studio met M3 Ultra is niet meer te koop met 256GB geheugen.

De Mac mini heeft nu maximaal 48GB geheugen, wat geldt voor de uitvoering met M4 Pro-processor. Voor de Mac mini met reguliere M4-soc ligt de maximale hoeveelheid geheugen nu op 24GB. Beide modellen verliezen dus hun topconfiguratie qua geheugen.

Verder heeft de M3 Ultra Mac Studio nu maximaal 96GB geheugen. De website van Apple lijkt kopers van de Mac Studio met M4 Max-processor nog wel de keuze te bieden van 96GB geheugen, maar dat blijkt niet echt zo te zijn. Selectie van meer geheugen geeft de melding dat een duurdere configuratie met andere processor vereist is.

Langere levertijden

Zowel het Studio-model met de M3 Ultra als die met de M4 Max hebben een levertijd van negen tot tien weken, meldt MacRumors. Een steekproef door Tweakers op de Nederlandse en Belgische websites van Apple bevestigt dit.

Het wegvallen van deze geheugenopties voor configuratie bij aankoop gebeurt nu de tekorten voor geheugenchips verder oplopen. Daardoor stijgen de prijzen en moeten hardwareleveranciers maatregelen nemen. Apple-ceo Tim Cook waarschuwde een week geleden al dat de stijgende geheugenprijzen steeds meer impact zullen hebben. Hij zei dat die impact vooral na juni voelbaar wordt, wat strookt met de nu zichtbare langere levertijden.

Mac mini. Bron: Apple

Reacties (68)

[ApexAlpha]

Een logisch gevolg van:
1) enorme populariteit van Macs door hun unified geheugen: werkt enorm goed voor lokale AI. Dit zal de vraag enorm doen toenemen voor hogere geheugenconfiguraties. Ik denk niet dat een 256gb optie ooit zo populair was als nu.

2) Zelfs Apple kan niet om te geheugencrunch heen. Ze zullen opties op geheugen hebben, maar waarschijnlijk simpelweg niet genoeg om de extra vraag te kunnen bijbenen.

Het is ook bizar, maar ik kijk zelf als naar 128gb Apple apparaten... Puur voor lokale AI. Het werkt zo ongelooflijk goed, dat ik daar best wat voor wil neertellen.

De M5 studio / mini zullen als warme broodjes over de toonbank gaan.

[Neus]

Bij mij blijft het traag. Ollama, LM Studio, etc.

Tips om een goede LLM te draaien op een 32GB Mac Studio M2 Max ?

[ApexAlpha]

1) kies een model dat volledig in je (v)ram past. Bij grotere modellen kun je een quant van 4 gebruiken.

2) een MoE model is vele malen sneller dan een 'dense' model. Kies bijvoorbeeld Gemma4 of Qwen3.6 MoE modellen.

3) Zorg dat je goed up to date bent, er zijn bijna dagelijks nieuwe updates van modellen en lmstudio/llama.cpp.

4) Hou het nieuws in de gaten! Gisteren kwam Google met een aankondiging van MTP: een 100% snelheidsverbetering zonder kwaliteitsverlies: https://blog.google/innov...token-prediction-gemma-4/

Coming to a dank GPU near you! (Waarschijnlijk binnen paar dagen!)

5) Je kan splitsen! Ik gebruik zelf mijn lokale model als back-end voor OpenClaw / Home Assistant. Maar als ik iets zwaarder werk wil doen zoals het schrijven van nieuwe script of skills dan wissel ik tijdelijk naar een cloud model zoals GPT5.5. Zolang er geen prive gegevens heengaan is dat de betere optie.

[kvaruni]

Het antwoord van @ApexAlpha is heel goed. Ik wil er nog een aantal dingen bij aanvullen.

Blijf weg van Ollama. Slechte performance, slechte modellen, slechte ethiek. Je kan ook beter doen dan LM Studio. De betere keuze is llama.cpp en uit diezelfde stal komt LlamaBarn . Makkelijker wordt het niet: installeren, model selecteren, open de WebUI, en gaan. Het voordeel is dat je direct een vrij recente llama.cpp hebt met een vrij goede standaard keuze van modellen en vrij goede instellingen. Je kan in de WebUI ook makkelijk een MCP server toevoegen, zoals https://mcp.exa.ai/mcp om online zoeken mogelijk te maken.

Wat nog ontbreekt is de keuze van GGUF (of MLX model). De quant bepaalt de compressie. Een kleinere quant werkt sneller, maar met mindere kwaliteit. Maar als je bijvoorbeeld llama.cpp rechtstreeks gebruikt kan je heel gericht een beste GGUF zoeken. Zo heeft unsloth bijvoorbeeld UD (Unsloth Dynamic) en XL varianten. Waar dit op neerkomt is dat je niet de volledige GGUF comprimeert, maar elk deel van de GGUF afzonderlijk behandelt. Zo noemt @ApexAlpha al dat een MoE vele malen sneller is. Maar een belangrijk onderdeel van een MoE is de laag die schakelt tussen experten, en die wil je liever niet comprimeren. Probeer bijvoorbeeld eens een UD-Q4_K_XL variant van een Gemma 4 of Qwen3.6 model. Voor llama-server mag je wel --spec-default niet vergeten, die een standaard speculative decoding inschakelt (een lichte versie van MTP, waarbij pure MTP in de toekomst nog eens +25% aan prestaties kan bieden). Gebruik je Gemma, schakel dan ook -np 1 in want Gemma 4 reserveert (te) veel geheugen in parallel gebruik.

Nu blijft 32GB wat beperkt. Je kan de K/V cache (de context) verder beperken door deze te comprimeren, maar dit gaat ten koste van snelheid. Maar als je geheugen op is gaat alles zoooo traag, dus probeer het eens: -ctk q8_0 -ctv q4_0.

Kortom: experimenteer door de juiste tool te gebruiken, én het juiste model (quant én MoE). Houd je geheugen in de gaten: van zodra de geheugendruk te groot wordt storten te prestaties in.

[mouse86]

Is een dx spark met 128 GB nou wel of niet sneller dan een Mac?

[kvaruni]

Mwa, is lastig. De GPU op de DX Spark heeft CUDA, wat veel (snelheids)voordelen biedt als je puur met AI bezig bent. Ondersteuning is over het algemeen veel slechter dus reken erop dat je veel zelf moet puzzelen en compileren. Zo heb je betere ondersteuning voor INT4 in CUDA, maar dat zit dan ook weer maar half in de Spark.

Is het enkel om LLM te doen dan is het toch een heel ander verhaal. Je kan meerdere Spark koppelen om grotere modellen te draaien, dat is zeker een plus. Je hebt meer compute, waardoor prefill (het lezen van je verzoek, zeker belangrijk bij agentic werk) sneller is. Maar token generatie, de uitkomst, hangt enkel af van bandbreedte en dan is een M5 Max meer dan dubbel zo snel. Maar dan ondersteunt de Spark de data types zoals INT4 en INT8 beter, dus die wordt weer sneller. De M5 Max heeft een neural accelerator op elke GPU core die nog niet goed benut wordt in tools zoals llama.cpp, dus er zit nog meer winst in die prefill in de toekomst. Maar de Spark heeft nu meer compute over, dus een techniek zoals MTP biedt op een Spark 50-125% meer snelheid tegenover de huidige 25% op de M-series chips (en direct weer een kanttekening: de huidige MTP implementatie halveert de prefill snelheid, dus dan heb je dat weer). Puur in benchmarks zal prefill 1.5x tot 2x zo snel zijn op de DX Spark, en genereren van tekst zal ongeveer hetzelfde zijn (maar vermoedelijk wat sneller op M5 Max).

Puur AI modellen trainen, grote modellen: (meerdere) DX Spark, want CUDA.

Algemeen gebruik of enkel LLM: MacBook M5 Max, want kan veel meer, is gewoon een goede laptop, verbruikt veel minder.

[dvdmeer]

Helaas, het zal traag blijven. De memory bandbreedte is te beperkt in de Macs om goed een local LLM te draaien. Ik heb een Macbook M4 Max met 128GB RAM, dus ik kan best wel grote modellen draaien met ook een flinke context maar over het algemeen is het bijna niet te doen. Een simpele vraag stellen in LM Studio voor een willekeurig model gaat op zich best snel en ook heel snel al een antwoord, maar koppel ik bijvoorbeeld Claude Code aan een locale LLM dan is die echt 5 minuten bezig voodat die met een eerste prompt komt en de vragen daarna duren ook zo lang. Dit komt omdat Claude Code een heleboel standaard al in de context gooit waardoor die in het begin al mega groot is. Dat wordt bij iedere prompt meegestuurd dus dat maakt het extreem traag.
En daarnaast is mijn Macbook altijd extreem stil en de fans gaan nooit aan. Tenzij ik met LLMs werk en dan maakt het ding overuren. Ben op zich altijd wat huiverig om voor lange tijd LLM modellen te draaien omdat ik ook heb gehoord dat de componenten sneller slijten en uiteindelijk misschien mijn laptop de geest kan geven omdat de warmte niet voldoende afgevoerd kan worden. Dus een hoge load voor lange tijd zou een probleem kunnen zijn.
Mijn Mac is mijn daily driver dus als die stuk gaat, wordt ik heel ongelukkig.

Overigens zou je ook eens vMLX kunnen proberen. Maar daar kun je dan volgens mij weer geen GGUF modellen mee draaien. Maar er zijn zat MLX versies overal van te vinden en die zijn ook meer geoptimalizeerd voor de Mac dus dat is sowieso beter om te draaien.

Edit: en voordat ik het vergeet. Waarschijnlijk doe je dat al, maar een Mac heeft de mogelijkheid om de hoeveelheid Unified Memory aan te passen naar wat je nodig hebt. Volgens mij default wordt 80% gealloceerd voor VRAM en de rest voor het systeem (pin me er niet op vast), maar dit is aan te passen. Zodoende kan ik in mijn geval 10GB alloceren voor het MacOS en mijn dev tools en de rest als VRAM gebruiken waar ik het model en de context in kan gooien. Zoek maar eens naar het commando: sudo sysctl iogpu.wired_limit_mb=xxxxx, waarbij xxxxx de hoeveelheid geheugen is die je wil alloceren aan VRAM (in Mb)

[Reactie gewijzigd door dvdmeer op 6 mei 2026 11:25]

[HummerHealey]

Kijk eens op het Youtube kanaal van Alex Ziskind. De modellen op de Mac's performen daar juist heel goed.

https://www.youtube.com/@AZisk

[dvdmeer]

Dankjewel voor de link. Ik heb al enkele videos van hem gezien. Goede entertainment en ook wel nuttige dingen, maar mijn ervaring met m'n mac is toch wel anders. Misschien moet ik lichtere modellen gebruiken en/of mijn context verlagen, maar ik merk vooral dat het toch traag gaat.

[aeon_flux]

Ja precies, daarom zie je nu ook zoveel interesse in de M3 Ultra Mac Studio’s voor local LLM-workloads. Niet alleen vanwege de hoeveelheid unified memory, maar vooral door de geheugenbandbreedte.

Een M4 Pro zit op 273 GB/s,
een M4 Max op 546 GB/s en
de M3 Ultra op 819 GB/s!!!

Bij LLM-inference, zeker met grote modellen en lange context, is memory bandwidth vaak minstens zo belangrijk als pure compute. Dat merk je vooral bij coding agents, omdat die bij elke stap enorme context meesturen. Een losse simpele prompt voelt dan nog prima, maar zodra je een agent-workflow aan een lokale LLM hangt, wordt de context meteen gigantisch en zakt de snelheid hard in.

Sinds macOS Tahoe 26.2 en RDMA over Thunderbolt wordt het bovendien veel interessanter om meerdere Mac Studio’s te clusteren. Vaak zie je dat in combinatie met Exo, waarmee je met veel lagere latency dan via ethernet distributed inference kunt draaien en effectief richting 1 TB (of meer) unified memory kan gaan, met meerdere M3 Ultra’s.

Als grote unified-memory machine voor modellen die anders niet lekker in VRAM passen zijn die cluster echt een uitkomts.

Voor een MacBook als daily driver zou ik ook niet langdurige LLM-loads laten draaien en zo’n laptop continu op z’n tenen laten lopen.

Hier nog een video "oude" video met 2TB unified ram: YouTube: Ethernet is DEAD?? Mac Studio is 100x FASTER!!

[IKON]

Misschien een out of the blue vraag, maar als iemand wilt beginnen met lokaal AI draaien en de mogelijkheden wilt ontdekken, waar zou je dan nu aanraden om te beginnen?

[ApexAlpha]

Je kan nu al beginnen! Er zijn zeer kleine modellen beschikbaar van bijvoorbeeld Google: https://ai.google.dev/gemma/docs/core

De 2B en 4B varianten draaien waarschijnlijk nu al op je PC.

Voor het iets serieuzere werk is Qwen 3.6 nu de gouden standaard voor lokale AI, gevolgd door Gemma 4.

Hiervoor heb je al wat meer (v)ram nodig. Met een GPU met 16GB ram kom je al een heel eind.

Makkelijk begin: https://lmstudio.ai
Via dat programma kun je modellen downloaden en het laadt je meteen zien of ze gedraaid kunnen worden.

Verwacht geen cloud performance.

[drdelta]

Je kunt in principe met iedere PC beginnen, zolang je maar voldoende (V)RAM hebt.

Heb je een beetje recente videokaart met 10-12GB VRAM, dan kun je een model zoals Llama 3.1 8B of Deepseek R1 7B/8B met prima snelheid lokaal draaien. Prima om mee te beginnen, en er zijn tal van andere kleine modellen beschikbaar.

Maar in principe kun je ook alles in RAM draaien, je hebt dan alleen wel geduld nodig.

Als je hardware gaat kopen dan blijft de Mac Mini een hele aantrekkelijke optie vanwege het snelle gedeelde geheugen, waardoor je voor ~2200 euro 48GB GDDR7 (V)RAM hebt. Ga je naar een videokaart gebaseerde oplossing kijken dan begint het bij ~3500 euro voor "slechts" 32GB GDDR7, en dan heb je daar nog een hele PC bij nodig, aanzienlijk minder aantrekkelijk dus.

[HummerHealey]

Ik draai Gemma 4 e4b op m'n standaard Mini M4 16/256Gb. En dat gaat prima. Je hebt in principe dan 12 Gb voor het model. Met een hack is dit nog te vergroten, maar dat laat ik aan me voorbij gaan.

[jappelkiste]

Is lokaal AI een beetje te vergelijken met de cloud diensten? Ik gebruik nu Claude modellen om te programmeren maar als ik dit ook maar een beetje intensief gebruik, zit ik rap over mijn limiet heen.

Ik heb het in de vergelijking nog niet eens zo zeer over de snelheid van output, maar meer de kwaliteit van de output. Zijn er lokale AI modellen die qua output te vergelijken of zelfs beter zijn dan modellen zoals Sonnet? Gekeken naar zowel vragen beantwoorden als programmeren?

[ApexAlpha]

Nee, een Claude is altijd sneller en beter. Zo een Claude model zal tegen de biljoen parameters zitten. Qwen3.6 heeft er ~30 miljard.

Maar de lokale modellen worden wel steeds beter. Een Qwen3.6 of Gemma4 zit met dit lagere aantal parameters nu al aan de kwaliteit van een cloud model van 6 maanden geleden zoals GPT4 of Claude 4.5.

En je betaalt geen tokens, en je informatie blijft prive.

Voor complexe, diepe redeneringen zal de cloud altijd winnen maar voor het normale werk is een model al snel goed genoeg.

[sapphire]

Dus de Studio moest de Mac Pro gaan vervangen maar mist nu de bak geheugen die pro mensen nodig hebben

[OruBLMsFrl]

Ja, en veel wilden in recente jaren voor AI natuurlijk ook al graag zulke sloten geheugen op hoge snelheid en daar is Apple een van de marktleiders op rond dat prijspunt. Jammergenoeg missen geheugensloten dan weer bij Apple zodat je het ook niet zelf kunt vervangen of uitbreiden.

[ApexAlpha]

Inference (draaien van AI modellen) leunt vooral, eigenlijk praktisch enkel, op de bandbreedte van je werkgeheugen.

Als je zelf je geheugen kon uitbreiden had je meer, maar was het veel langzamer want een so-dimm slot heeft nu eenmaal een max bandbreedte en dat kan echt niet tippen aan bijvoorbeeld gddr7 gesoldeerd.

[drdelta]

Als je zelf je geheugen kon uitbreiden had je meer, maar was het veel langzamer want een so-dimm slot heeft nu eenmaal een max bandbreedte en dat kan echt niet tippen aan bijvoorbeeld gddr7 gesoldeerd.

Daar heb je helaas alleen iets aan als je model volledig in je VRAM geheugen past, anders wordt je alsnog gebottlenecked door je langzamere RAM bandbreedte.

[SG]

Heb je meer mem nodig dan vervang je apple. Weet je niet wat je als 300000 $ werknemer in near future gaat gebruiken heb je ook Apple lease concepten

Zelf sinds 80386S dozijn aan cpu generaties intel en AMD zelf bouw . ram nog nooit vervangen. Altijd voldoende voor de next windows en apps.

Zal niet anders zijn met mijn 64GB Mac Studio. Die kan 5 a 10 jaar mee net als W11 7800x3D 32GB build

Al is voor mij hobby

[eettjjuuhh]

Wat ik me afvraag: gaan programmeurs door ram schaarste efficiënter coderen? Had het idee dat efficiëntie steeds verder ging ontbreken omdat er toch genoeg ram was?

[jpsch]

Efficiënter coderen verwacht ik niet met al die vibe coding.

[jvwou123]

en opdracht bij vibe coding: ik zie dat er veel geheugen gebruikt wordt, kun je dat verminderen?
En klaar ;-)

Ik heb een DNS server gemaakt, daarna met Github Copilot, gevraagd: kun je hem sneller maken, en dat is factor 2-4x sneller geworden. Zo snel dat de testtool het niet meer aan kan ;-). Kan natuurlijk komen omdat ik geen goede programmeur ben, maar toch vond ik het best indrukwekkend wat ie verbeterde.

[bzzzt]

En ben je zelf nog in staat over die code te redeneren? Misschien is jouw 'verbeterde' versie nog steeds hopeloos inefficient en zijn hooguit de ergste problemen eruit gehaald.
Vraag Copilot eens om een benchmark tegenover een gangbare productie DNS server.

[jvwou123]

Van dat project wel. Alle code die daar door copilot geschreven is heb ik eerst gecontroleerd voor dat ik het accepteerde. Ik wil bij dat project wel echt weten wat er gebeurd.

Bij andere projecten, waar veel minder klant impact is, eigen tooltjes, controleer ik niet altijd even strak wat ie maakt. Ik ben nu met een projectje bezig, waar alleen ik (nu) mee bezig ben, en daarvan heb ik geen letter zelf in de code getypt, en ook geen idee wat ie precies doet. Zodra het breder gebruikt gaat worden ga ik eerst de hele code base door om te kijken wat er gebeurd. Ik wil wel weten wat er gebeurd. En of er geen rare bug in gemaakt zijn. Pas nog in een prive projectje, en daar had ie heel mooi een OWASP #6 ingebouwd. Of te wel: path traversal, je kon zonder problemen /etc/password van de server lezen.

ps: qua benchmark (met https://github.com/Tantalor93/dnspyre): ik haal op de server in productie meer requests/sec in de benchmark, en sneller dan vanaf de zelfde pc/verbinding naar b.v. google dns, of cloudflare dns. Overigens ook sneller dan een caching DNS in het zelfde netwerk. Dus ik heb niet het idee dat ie traag is... De pihole heeft een eigen DNS die heet FTL (Faster Than Light). de laatste keer dat ik op zelfde hardware getest heb, kon mijn DNS 10x meer requests per seconde afhandelen dan FTL. Waarom die vergelijking: ze hebben allebij een lijst met domeinen die gefilterd moeten worden, en ik heb een beetje grote lijst, met veel categorieën. Die lijst ook in FTL geladen, en daar kon ie niet goed mee overweg.

[kaas-schaaf]

Raar dat je het met Pi-hole's FTL gaat vergelijken. Die hebben stability-before-features als uitgangspunt en vibe coding voor snelheid is de antithesis daarvan.

[Argantonis]

Het zou me niet verbazen idd, zeker bij grotere desktop-producten waar mensen in dat bedrijf wel echt bezig zijn met wat minimale performance moet zijn op een ondergrens aan gemiddelde consumer-pc. Het helpt niet mee dat de gemiddelde dev-bak wel aardig wat geheugen moet hebben door alle benodigde vm's/docker containers om lokaal een beetje te kunnen ontwikkelen. Ik moest zelf jaren geleden al naar 32 GB geheugen om lokaal lekker te kunnen blijven werken. Dus ik zou het persoonlijk niet zo snel merken als iets te krap is. Nou werk ik alleen aan backend software in de cloud dus daar huur je gewoon het geheugen wat je nodig hebt, het is voor mij wat minder relevant dan bij consumer-software dat op een pc draait.

[drdelta]

Waarschijnlijk niet.

Efficiënt programmeren kost doorgaans meer tijd en moeite, en het heeft vaak weinig financieel voordeel, waardoor er minder aandacht voor is.

De voornaamste reden waarom we steeds meer geheugen zijn gaan gebruiken komt door frameworks zoals Electron, React Native, etc. die het mogelijk maken om sneller (multiplatform) applicaties te ontwikkelen. De "kosten" zijn meer geheugen gebruik, maar dat is een "probleem" voor de eindgebruiker.

[satya]

Binnen bijvoorbeeld GitHub werkt dat anders.

Default werk je vanuit markdown om je vraag op te zetten en copilot aan te sturen, maar dat lijkt vervangen te worden door Toon, een notatie die wat strikter is , betere code opleverd en Ai gebruik ook efficiënter maakt.

[Hercolubus]

Jammer dat ook Apple dit doet, ze leken zich zo aan hun eerdere beloften te houden

[Scribe]

Ben bang dat ze weinig keuze hebben. Zelfs voor reuzen als Apple is het moeilijk om nog geheugen bij elkaar te krijgen op dit moment.

[WillySis]

Op dit moment is Apple voor de geheugen producenten geen grote klant meer. Ze bestelden wel een vaste hoeveelheid geheugen per maand, maar zo'n maandelijkse opdracht van een datacentrum is vele malen groter dan wat een computer fabrikant kan. Bovendien gaat het bij Apple om een langer contract waarbij de prijzen vaak vast staan of binnen een bandbreedte moeten blijven. De prijzen die men voor de datacentra rekent is nu echt wat de gek ervoor geeft. Zeker nieuw te bouwen datacentra bieden enorme bedragen om maar zoveel mogelijk voorrang te krijgen. Zelfs een klant als Apple moet daarvoor wijken.

Ook andere computermerken zullen last gaan krijgen van de langere levertijden van het geheugen en de levertijden van systemen zal toenemen, zeker als de klant daar veel geheugen in wil hebben.

[Rainboww]

"Op dit moment is Apple voor de geheugen producenten geen grote klant meer."
Apple is en zal altijd een van de grootste klanten blijven.

"Ze bestelden wel een vaste hoeveelheid geheugen per maand"
Een Apple besteld niet per maand, die kopen in bulk in voor maanden vooruit, als het niet langer is. De fabrieken mogen niet stil komen te vallen.
Bovendien doen ze ook ook leveringscontracten voor langere termijnen afsluiten.
nieuws: 'Apple koopt geheugenvoorraden op en zet Chinese Android-fabrikanten onder druk'

[WillySis]

Apple heeft lange termijn contracten voor bepaalde hoeveelheden geheugen per maand. Elke levering is inderdaad een aantal maanden voor het vermoedelijke gebruik gepland. Zo'n maandelijkse levering is nu een relatief kleine order. De producenten verdienen nu zoveel dat ze de boete voor het niet leveren gemakkelijk kunnen betalen, of de prijzen zijn gestegen boven de maximale prijs die in de contracten staat.

Natuurlijk probeert Apple overal voorraden en capaciteit in te kopen, maar dat doen meerdere computer merken. Zelfs Samsung heeft het moeilijk om aan geheugen te komen omdat de geheugen divisie zelfstandig werkt en niet automatisch voorrang verleent aan andere divisies van Samsung.

[DLeijen]

Tsja, als zelfs Apple niet in staat is aan geheugen te komen valt er niet zo veel aan te doen.

[drdelta]

Waarschijnlijk wil Apple dat mensen duurdere hardware kopen wanneer ze meer (V)RAM nodig hebben.

Voor ~2200 euro heb je een Mac Mini met 48GB geheugen, wil je meer dan moet je naar de Mac Studio waar je voor ~4850 euro 96GB geheugen kunt krijgen.

[SG]

Altijd het slechte denken.

Er is schaarste dan hak je de hoge ram updates. Inkoop duurder geworden is verdwijnt de marge snel.

De lage basis modellen zijn volume producten

Hoge gb vervallen heb je meer over voor de hoge volume modellen.

Bij SSD vervalt soms de instap SSD. of de kleinere chip NAND schuift maar grotere chips. Of Omdat bij ultra lage basis modellen de marges al klein waren vervalt de instap ssd. Tier hoger blijkbaar dekt meer prijs de marge.

De reden zal mix zijn incluis slechte

[Donstil]

Jammer dat ook Apple dit doet, ze leken zich zo aan hun eerdere beloften te houden

Welke beloften doel je dan op?

Want Tim zei tijdens de laatste kwartaalcijfers juist dat ook Apple de schaarste ervaart en de impact voelbaar zal worden.

[S1NN3D]

Enkele dagen geleden kwam ook deze al voorbij.

nieuws: Apple zet stilletjes verkoop van M4-Mac mini met 256GB opslag stop

In aanloop naar WWDC waar opvolgers op basis van M5 verwacht worden, zal men het aantal modellen en voorraden terug willen brengen. Daar past dit nieuws ook bij.

[Xfade]

ze willen voornamelijk geen tekorten hebben, dus snoepen ze geheugen om deze in die modellen te plaatsen. Tim had dit al aangegeven.

[outlandos]

Dit denk ik ook. Mac Mini M5 incoming met 512gb als minimum opslag.

[dnat]

Exact waarom die dingen nu zo goed verkopen: om AI modellen te laden gaan ze deze beetje kortwieken

[Pietopdeheuvel]

Lijkt mij duidelijk dat door de AI on Prem vraag de varianten met meer en veel geheugen uitverkocht zijn, en men geen nieuwe van de M3 en M4 versies laat bouwen, wanneer men nu de M5 variaties aan het produceren is die binnenkort op de markt komen. Verwacht die begin van de zomer. #MetooaGurman

Met andere woorden, Apple verlaagd niet de opties, de hogere opties zijn gewoon uitverkocht. IMHO

[Reactie gewijzigd door Pietopdeheuvel op 6 mei 2026 09:58]

[torp]

"Apple verlaagt stilletjes de maximale geheugenopties voor Mac mini en Mac Studio"
"Apple zet stilletjes verkoop van M4-Mac mini met 256GB opslag stop"
Het gebruik van het suggestieve "stilletjes" neemt op Tweakers snel toe als het over Apple gaat.

[Pietopdeheuvel]

Ja, Apple in de headline, en de mogelijkheid voor iets om over te klagen, dat brengt clicks, de redactie van Heise.de doet hetzelfde.

[chrome moral]

Al die lokale AI modellen doen me denken aan een oud collega met zijn gaming pc. Die was de hele dag geheugentimings aan het testen en overclocks aan het proberen en hij had het over pifast en 3d Mark en was echt trots op zijn instellingen of resultaten. Hij speelde echter nooit spellen.

Mensen met al die AI zaken in mijn omgeving die hebben het over Obama en over query zus of query zo, maar als je dan vraagt wat ze er daadwerkelijk mee gedaan hebben dan komen ze niet veel verder als welk model ze ingeladen hebben of hoelang ze over token zus of zo deden.

Het is dus zonde als dat soort figuren een schaarste creëren van apparaten die door professionals gebruikt worden voor foto of video bewerking waarmee er dus daadwerkelijk een nuttige output is.

ik denk dat Apple dit ook inziet en daarom liever 2 professionals blij maakt met een 128GB Mac, dan 1 AI hobbyist die het apparaat niet echt nuttig zal gebruiken.

[Pietopdeheuvel]

Sowieso de hele AI Bubble is een gigantische verspilling van resources, er is heel grote rekencapaciteit voor en slikt gigantische hoeveelheden stroom. Schattingen die ik gezien heb waren dat 50-80% van nde compute gebruikt worden voor beelden, video, muziek, chat en andere entertainment. Zakelijke toepassingen (coding, automatisering, AI support) 20-40% en wetenschappelijk, medisch fundamenteel onderzoek 10-20%

Kortom, het genereren van al die grappige plaatjes en video's slikt het gros van de resources.

Bij een groot bedrijf in de automotive branche waar ik recent aan het werk was, hadden we iedereen toegang gegeven tot AI, maar we stelden vast dat vrijwel alle capaciteit opging aan het genereren van grappige plaatjes,recepten zoeken, etc etc. Hebben dat na een jaar aanzien terug gedraaid en men krijgt alleen nog toegang (zakelijk) wanneer men een duidelijke use case heeft. Het bespaarde kapitalen.

[Reactie gewijzigd door Pietopdeheuvel op 6 mei 2026 10:25]

[bzzzt]

Ik vraag me af waar je die 'schattingen' vandaan haalt, want de bron kan natuurlijk ook gekleurd zijn om een bepaald narratief te ondersteunen. Jaren terug heb ik ook een 'schatting' gezien dat 60% van de internet capaciteit gebruikt zou worden voor het transport van pornografisch materiaal. Doe met zo'n schatting wat je wil, maar zonder bron en onderbouwing zou ik het niet zonder meer voor waarheid aannemen.

Wat voor de een 'grappige plaatjes' zijn is voor de ander op te leveren presentatie- of marketingmateriaal en gewoon werk wat eerder met veel meer moeite gemaakt moest worden. Uiteraard is het voor veel mensen nieuw en 'magisch' en zal er een hoop onzin worden opgevraagd. Maar is dat anders dan bij computers in het algemeen? Wie kocht in de jaren 80-90 z'n PC niet om 'mee te tekstverwerken' waarna het ding 90% van de tijd spellen draaide. Als je problemen hebt met AI heb je dan ook problemen met gamers die elkaar opjutten om vooral zo zwaar mogelijke 1000W standkachels aan te schaffen die eigenlijk geen enkel nuttig doel hebben behalve laten zien dat je de grootste hebt?

[beeldbuijs]

Het is niet anders dan met computers in het algemeen en sterker nog, zoals met zoveel consumptie-artikelen, maar dat doet er niets aan af dat het vaak wel waar is.

Auto’s wogen in de jaren zeventig 700 - 800 kg. Nu het dubbele, 15.500 moet uiteraard zijn: 1.500 kg en dan tel ik de vanwege accu’s relatief zware ev’s nog niet mee. Tegelijkertijd zijn gezinnen juist kleiner en het aantal alleenstaanden groter dan ooit. Natuurlijk dragen airbags etc hier ook aan bij, maar het meeste zit hem in de veel grotere afmetingen en meer luxe.

[Reactie gewijzigd door beeldbuijs op 6 mei 2026 19:11]

[Miglow]

15.500 kg? Damn, mijn 4-assige truck met haakarm systeem weegt nog minder (14.200)

[bzzzt]

Auto’s wogen in de jaren zeventig 700 - 800 kg. Nu het dubbele, 15.500 kg en dan tel ik de vanwege accu’s relatief zware ev’s nog niet mee.

Ik ga er vanuit dat je 1550kg bedoelt, maar zelfs dat is overdreven (oftewel: je bent op zoek naar bevestiging voor je narratief). Een gemiddelde gezinsauto op benzine begint rond de 1200kg. En zelfs dat is niet zo gemiddeld meer omdat ook kleine auto's een stuk duurder zijn geworden. In ieder geval zijn die ondertussen even groot als die waar we het in de jaren 70 mee moesten stellen.

Tegelijkertijd zijn gezinnen juist kleiner en het aantal alleenstaanden groter dan ooit. Natuurlijk dragen airbags etc hier ook aan bij, maar het meeste zit hem in de veel grotere afmetingen en meer luxe.

Veiligheid is juist een enorme factor in gewichtstoename. Niet alleen airbags en andere toevoegingen, maar ook eisen aan de structurele stevigheid van auto's (de 'kooi'). Dat tikt aan, maar lijkt wel geleid te hebben tot een neergaande hoeveelheid verkeersdoden.

Als ik je zo lees lijkt het wel alsof je denkt dat half Nederland in een SUV rijdt. Nou ligt het er een beetje aan waar je woont, maar als je gaat bijhouden wat er allemaal door een gemiddelde straat rijdt (of er in staat) denk ik dat je zal zien dat er maar een kleine groep mensen is die gruwelijk oversized auto's wil en kan betalen.

[beeldbuijs]

Het heeft weinig te maken met wat ik denk, maar met de feiten. Het zijn niet eens de suv’s, al had je die 50 jaar geleden ook niet. Alle auto’s bij elkaar zijn gemiddeld groter, zwaarder, langer, breder geworden, ook de ‘kleine’ modellen. De laatste 20 jaar zijn auto’s gemiddeld elk jaar een cm breder geworden.

[bzzzt]

Dat ontken ik ook niet, maar het gaat ook volgens dat artikel om batterijen, veiligheid en pas in de laatste plaats luxe...

[Pietopdeheuvel]

Nu ja, wereldwijde vraag naar stroom, wordt verwacht flink te stijgen, tot 2030 het stroomverbruik van DC's zal verdubbelen.

Global data center power demand to double by 2030 on AI surge: IEA | S&P Global

945 TWh ≈ 140–160 grote kolencentrales, en dat is alleen de stroom, hebben we het nog niet over het geheugen en de GPU schaarste

[bzuidgeest]

Data centrums zijn meer dan AI en kolen is niet de enige optie.

Ze hebben in Amerika meer dan genoeg ruimte voor wind en zon en de batterijen om de wisselingen in beschikbaarheid op te vangen en die batterijen kunnen van minder energiedichter maar goedkope, ruim beschikbare makkelijk te recyclen materialen worden gemaakt.

Kolen is verre van de enige optie. Het totale energie gebruik is niet relevant. HOE die energie verkregen word is relevant. En dan hebben we het nog niet eens over kernenergie. Japan kan een centrale zetten in vijf jaar. Bij ons duurt het langer over vergunningen en rechtszaken. Maar het kan veel vlugger.

[bzuidgeest]

Zelfs als dat waar is, dan is er dus niets veranderd aan hoe het internet voor AI werd gebruikt.

Entertainment is met bijna alles het grootste gebruik. En het gebruikt al jaren gigantische resources.

Tja, dat het bedrijf in de automotive branch waar je het over hebt zulke slechte mensen had dat die niets nuttigs met de AI konden doen.... Misschien zegt dat meer over professionalisme en leiderschap daar dan over AI

[ymmv]

Er worden in juni op WWDC26 hoogstwaarschijnlijk nieuwe Mac Minis en Mac Studios met M5-chips aangekondigd. Dan is het logisch dat Apple bestaande voorraden van de huidige Mac Studio niet meer aanvult.