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 (49)

[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.

[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]

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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 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.

[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.

[Pietopdeheuvel]

Bij het gebruiken van een voorbeeld, gaat het niet om het voorbeeld an sich, maar om de essentie van het voorbeeld. Mijn gebruik van "Kolencentrales" is ter illustratie van de stijging. Kan ook 945 TWh ≈ ±6.000–7.000 km² zonnepanelen zeggen, of 945 TWh ≈ 50.000 – 80.000 windmolens. Had jij ook kunnen uitrekenen.

[Miglow]

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

[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

[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]

[bzuidgeest]

Al die mensen die geloofden dat Apple de prijzen niet verhoogde omdat ze voldoende voorraad hadden van geheugen zullen nu wel op hun neus kijken.

Apple heeft zijn winst marge herstelt naar 100% door gewoon stiekem minder geheugen in de machines to stoppen. Zo kan iedere Pipo wel claimen geen verhogingen door te voeren.

edit:
200 naar 100%, zelfs apple maakt het niet zo gek. tikfoutje.

[Reactie gewijzigd door bzuidgeest op 6 mei 2026 12:32]

[Pietopdeheuvel]

En, vertel, waar haal je die info vandaan?

[bzuidgeest]

Ik kan lezen? Ofwel het artikel....

[Pietopdeheuvel]

Staat niets van een 200% verbetering van marge of het verhogen van prijzen. Slechts dat bepaalde configuraties niet leverbaar zijn.

[bzuidgeest]

Nee? dan denk jij zeker dat ze een andere Apple bedoelen. Ik ben de rest niet ineens vergeten als ik een volgend artikel lees. Ik kan verschillende combineren. Ik neem aan dat je kan googlen. De 200 is overigens een tikfout die ik zal herstellen. moet 100 zijn.

[Pietopdeheuvel]

/ignore troll

[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.