GLM-5.3-Flash VRAM-vereisten: hoeveel geheugen je nodig hebt om een 320B MoE te draaien.

GLM-5.3-Flash past op geen enkele consumenten-GPU. De kleinste bruikbare build, 2bit-lite, heeft ~102 GB aan gewichten en 112 GB RAM nodig. Een 128 GB Mac is het instapmodel; een enkele H200 past 2bit-lite met ~39 GB over; alle anderen zouden de gehoste API, z-ai/glm-5.3-flash, moeten gebruiken.

Dat is het hele antwoord in één adem, en het is de moeite waard om het hier ronduit te zeggen: er bestaat geen consumentenhardwareconfiguratie die dit model kan draaien. Het vision-language-mixture-of-experts-model van Z.ai met 320B parameters, uitgebracht op 26 augustus 2026, heeft in elke kwantisering serverklasse-geheugen nodig. Het cijfer "18B actief" beschrijft de rekenkracht per token, niet het residente geheugen — alle 320B-gewichten blijven geladen. De realistische lokale doelen zijn grote Macs met geünificeerd geheugen, multi-GPU-servers en een enkele H200 met 141 GB. Als je geen van die apparaten bezit, zijn de onderstaande cijfers geen boodschappenlijst; ze zijn de reden om het model in plaats daarvan via een API aan te roepen.

Een kanttekening vooraf bij de cijfers: de geheugencijfers in dit stuk zijn community-bevindingen, geen leveranciersrichtlijnen. Z.ai publiceert gewichten en API-specificaties; het publiceert geen geheugeneisen voor lokale inferentie. De tabel per quantisatie komt van de modelkaart orcarouter/GLM-5.3-Flash-MLX op Hugging Face, een MLX-quantisatie van de open gewichten die een communitygroep onderhoudt, en de implementatiecijfers komen van praktijkmensen die het model daadwerkelijk hebben geladen. Waar een cijfer door de leverancier is gerapporteerd — prijzen en de claims over de KV-cache-efficiëntie van de architectuur — vermelden we dat als zodanig.

Het korte antwoord: wat past op wat je bezit

Begin met wat je daadwerkelijk hebt, omdat de kwantiseringsladder alleen zin heeft ten opzichte van een doelmachine:

• Consumenten-GPU (RTX 4090, RTX 5090 en alles daaronder) — nee. Geen enkele consumentenkaart heeft genoeg VRAM: de kleinste build heeft alleen al ~102 GB aan gewichten, ongeveer vijf RTX 5090's waard. Systeem-RAM verandert dit niet, want de gewichten moeten op het apparaat aanwezig zijn.

• 128 GB Mac (M4 of M5 Max) — de 2bit-lite-build (~102 GB gewichten / 112 GB min RAM), en alleen na het verhogen van de wired-geheugenlimiet. Meer daarover hieronder. Dit is de enige machine in de consumentenklasse waar het model op past.

• 192 GB en 256 GB Mac Studio — 3-bit (~184 / 200 GB) en 2-bit (~145 / 160 GB) worden bereikbaar; 4-bit heeft ~224 GB nodig, wat alleen de 256 GB-categorie benadert.

• Eén H200 (141 GB VRAM) — 2bit-lite past met ongeveer 39 GB over voor de KV-cache, wat betekent dat alleen korte contexten mogelijk zijn.

• Multi-GPU-server — alles, inclusief 4-bit, 6-bit en de ~328 GB FP8-referentiebuild.

Iedereen anders — de gehoste API, z-ai/glm-5.3-flash. Dat is geen troostprijs; het is waar het model daadwerkelijk snel en goedkoop te gebruiken is, en dit wordt onderaan deze pagina behandeld.

Twee getallen, niet één: gewichten versus totaal geheugen

Elke kwantisatie op de modelkaart heeft twee kolommen — gewichtsgrootte en minimum-RAM — en de kloof ertussen is het deel dat de meeste artikelen overslaan. De gewichtencolumn betreft de modelbestanden: elke parameter, in die precisie, in het geheugen aanwezig. De minimum-RAM-kolom is wat de machine tijdens de uitvoering in het geheugen moet houden: de gewichten plus de KV-cache, de activaties en de buffers die met de contextlengte meegroeien.

Het cijfer van 18B actief is waar mensen worden misleid. GLM-5.3-Flash is een MoE met 320B totaal / 18B actief: per token rekenen slechts ongeveer 18B parameters mee. Dat is een besparing op rekenkracht, niet op geheugen. Alle 320B gewichten zitten in het geheugen, ongeacht welke experts actief zijn, omdat de router pas weet welke experts hij nodig heeft wanneer hij het token ziet. MoE levert snelheid op, geen geheugenvoetafdruk — een punt dat de eigen modelkaart illustreert, met de 320B totaal naast de 18B actief.

Dus wanneer een build zegt "~204 GB weights / 224 GB min RAM," is de extra ~20 GB runtime-overhead — KV-cache, activaties, contextbuffers. Verhoog de contextlengte en die delta groeit. De min-RAM-kolom, niet de weights-kolom, is de maatstaf om een machine op te dimensioneren.

Het model zelf — architectuur, licentie en de eigen framing van Z.ai — is gedocumenteerd op de officiële modelkaart van de leverancier, hierboven weergegeven. Lokaal geheugen wordt daar niet behandeld; daarom bestaat deze pagina. De cijfers hieronder komen van de community-MLX-port van de open gewichten.

De kwantiseringsladder

De tabel op de orcarouter/GLM-5.3-Flash-MLX-kaart is degene die beoefenaars vandaag daadwerkelijk laden. Deze vermeldt vijf gekwantiseerde builds plus de FP8-referentie, elk met gewichtsgrootte en minimaal RAM-geheugen:

• FP8-referentie — ~328 GB aan gewichten. Het niet-gekwantiseerde referentiepunt waarop de open gewichten worden uitgebracht.

• 6-bit — ~296 GB gewichten / 320 GB min. RAM. Bijna verliesvrij; de kwalitatief beste build.

• 4-bit — ~204 GB / 224 GB. De aanbevolen dagelijkse standaard.

• 3-bit — ~184 GB / 200 GB. Agressief maar bruikbaar.

• 2-bit — ~145 GB / 160 GB. Best-effort.

• 2bit-lite — ~102 GB / 112 GB. De kleinste build; de enige die op een 128 GB Mac of een enkele H200 past.

De kwaliteit neemt af naarmate het aantal bits daalt, en de card kwantificeert dit. Ten opzichte van de FP8-referentie verslechtert de perplexity met +0,24% bij 6-bit, +2,96% bij 4-bit, +9,96% bij 3-bit, +56,9% bij 2-bit en +141% bij 2bit-lite (perplexity-cijfers afkomstig van dezelfde modelcard). De richtlijnen in de card zelf: 6-bit voor bijna verliesvrij, 4-bit als standaard voor dagelijks gebruik, 3-bit en 2-bit bij geheugenbeperkingen, 2bit-lite alleen als er niets anders past — en lange codegeneratie is niet betrouwbaar met 2bit-lite. Die laatste waarschuwing is van belang voor een 320B-redeneermodel: 2bit-lite is wat je de 128 GB Mac oplevert, en je betaalt die kwaliteitsprijs precies daar waar codeerwerk het meest pijn doet.

Twee getallen in die ladder verdienen een nadere blik, omdat ze de hele hardwarekwestie bepalen.

Waarom 2bit-lite bestaat

2bit-lite is geen extra kwaliteitsniveau — het is een groottecategorie die om één reden is gecreëerd: reguliere 2-bit past niet. Met ~102 GB aan gewichten is het de enige build die onder de ~112 GB bruikbaar geheugen van een 128 GB Mac blijft, en de enige die in de 141 GB van een enkele H200 past met ruimte voor een KV-cache. De modelkaart zegt hetzelfde: reguliere 2-bit past niet op een 128 GB Mac; 2bit-lite wel, met een verhoogde limiet voor vastgezet geheugen. Op een H200 past het "met ~39 GB over voor de KV-cache" (de woorden van de kaart). Die 39 GB is het volledige werkbudget voor alles wat het model doet na het laden — en dat brengt ons bij context.

Wat de KV-cache kost bij lange context

GLM-5.3-Flash heeft een contextvenster van 1M tokens, en lange context is waar lokale geheugenplannen sterven. De hybride sparse-plus-lineaire aandacht van het model — NoPE-MLA met een index-poolmechanisme — is werkelijk efficiënt: Z.ai meldt dat het de rekenkracht voor aandacht met 3.01× en de KV-cachegrootte met 4.44× vermindert ten opzichte van zijn eigen GLM-5.3 (door de leverancier gerapporteerde cijfers). Maar "4.44× kleiner dan GLM-5.3" laat nog steeds een cache achter die in tientallen GiB wordt gemeten wanneer je naar een volledige 1M-context streeft.

Het beste publieke getal dat we hebben komt van een community-implementatie die het model over vier DGX Spark-nodes draaide: 16 GiB aan KV-cache per rank — ongeveer 64 GiB in totaal over de vier — om een volledige context van 1M tokens vast te houden, groot genoeg om een paar gelijktijdige verzoeken met volledige context te ondersteunen. Dat is meer dan het volledige geheugenbudget van de meeste enkele machines, nog vóór één enkel gewicht. Op een enkele H200 is de berekening het punt van deze pagina: 2bit-lite laat ~39 GB over voor alles na de gewichten — comfortabel voor een kort gesprek, binnen enkele minuten opgebruikt naarmate de context naar 100K tokens klimt.

De praktische vuistregel: de min-RAM-kolom gaat uit van een redelijke context. Als je workload lange documenten, agentloops of code op repositoryschaal draait, reserveer dan extra KV-cachegeheugen — en voor alles in de buurt van 1M tokens kun je beter stoppen met rekenen en de API gebruiken. Deze observaties over dimensionering zijn bevindingen uit de community; er bestaat geen richtlijn van leveranciers voor KV-budgettering.

De limiet van het wired-geheugen van macOS: waarom een Mac met 128 GB nog steeds niet kan laden

De meest voorkomende fout die door gebruikers wordt gerapporteerd is niet "niet genoeg RAM." Het is een 128 GB Mac met een ~102 GB model dat weigert te laden. De oorzaak is de wired-geheugenlimiet van macOS. Op Apple Silicon kan de GPU niet al het unified memory adresseren: Metal stelt een "aanbevolen maximale werkset" bloot van ongeveer twee derde van het fysieke RAM, en toewijzingen daarboven mislukken zelfs wanneer de machine vrij geheugen heeft.

Een standaard Metal-budget van een Mac met 128 GB ligt ergens in de range van 80–90 GB — onder wat de 2bit-lite-build nodig heeft (~112 GB min RAM met een ~102 GB resident model). Het laden mislukt op het Metal-budget, niet op de RAM-capaciteit. De oplossing in elk praktijkrapport dat we vonden is hetzelfde: verhoog de wired-limiet met sudo sysctl iogpu.wired_limit_mb=…, stel een waarde in boven de totale voetafdruk van het model in MB, en verwacht dat deze bij een herstart wordt gereset. Sommige communitygidsen stellen de wired-limiet ook in vanuit Python via mlx.metal.set_wired_limit() zodat de gewichten van het model worden vastgezet en macOS stopt met het comprimeren van inactieve Metal-pagina's.

Nog een complicatie: runtimes gedragen zich verschillend. MLX handhaaft het Metal-budget en faalt hard zodra het wordt overschreden, terwijl op llama.cpp gebaseerde runtimes (het GGUF-pad) dit over het algemeen niet afdwingen en macOS in plaats daarvan laten swappen. Daarom kan hetzelfde model in de ene runtime weigeren te laden en in de andere 'laden' — en daarom kan een geswapt model zo traag zijn dat het onbruikbaar wordt. Dit zijn bevindingen van de community over het gedrag van macOS, geen richtlijnen van Apple.

Het gehoste alternatief: z-ai/glm-5.3-flash

Voor iedereen die door de bovenstaande cijfers wordt uitgesloten — en dat zijn de meesten — serveert Z.ai het model zelf als z-ai/glm-5.3-flash, en dit is waar de "Flash" in de naam daadwerkelijk naar voren komt. Z.ai's catalogusprijs is $0,15 per miljoen invoertokens, $0,03 per miljoen gecachte invoertokens en $0,50 per miljoen uitvoertokens; een introductieactie loopt tot 9 september 2026 tegen $0,075 / $0,015 / $0,25 (door de leverancier gerapporteerde prijzen, actueel op het moment van schrijven). Gecachte invoer tegen een vijfde van verse invoer is de grootste kostenfactor: elke workload met een herbruikbaar prefix — systeemprompts, tooldefinities, lange gedeelde documenten — zou gebruik moeten maken van cache-read-prijzen.

De geheugenberekening moet meegenomen worden in de beslissing. Een 320B-model zelf draaien betekent dat je er 112–320 GB geheugen aan moet toewijzen, of het nu inactief of verzadigd is. Het gehoste endpoint haalt dat alles van je machines af, en tegen introductieprijzen kost het model minder per token dan veel modellen die tien keer zo klein zijn — en dat is precies het hele punt van een 18B-actieve MoE.

Dit is ook de natuurlijke plek voor het routeringspunt. Via OrcaRouter is z-ai/glm-5.3-flash een van de 200+ modellen achter een enkele API, geprijsd tegen de lijstprijs van de provider met 0% opslag — dus de lanceerpromotie en elke toekomstige prijsverlaging zijn live op dezelfde dag dat ze worden aangekondigd. Automatische failover betekent dat een drie dagen oud model met een wankel servingpad geen gok is op je productiestack: als de provider fouten geeft of verzadigd raakt, wordt het verzoek doorgeschakeld naar een gezonde provider in plaats van te falen. Een onbewezen model veilig uitproberen is precies waar een router voor is.

Veelgestelde vragen

Kan ik GLM-5.3-Flash draaien op een RTX 5090?

Nee. De kleinste build heeft alleen al ~102 GB aan gewichten, en een RTX 5090 heeft 32 GB VRAM. Geen enkele consumenten-GPU komt in de buurt; het model vereist Macs met unified memory, een enkele H200, of een server met meerdere GPU's.

Betekent 18B actief dat GLM-5.3-Flash op consumentenhardware draait?

Nee. Het actieve cijfer van 18B betreft rekenkracht per token. Alle 320B parameters blijven in het geheugen aanwezig, omdat de router niet kan weten welke experts een token nodig heeft voordat hij het token ziet. MoE bespaart rekenkracht, niet geheugen.

Wat is de goedkoopste manier om GLM-5.3-Flash uit te proberen?

De gehoste API, z-ai/glm-5.3-flash. Tegen de lanceerpromotieprijs kost het $0,075 per miljoen invoertokens, en gecachende invoertokens kosten $0,015. Het zelf hosten van de kleinste build betekent dat je er ~112 GB RAM aan moet toewijden, wat alleen zin heeft als je de hardware al bezit.

De eerlijke samenvatting: GLM-5.3-Flash is in elke build een serverklasse-model. De Mac met 128 GB krijgt de enige build die past: 2bit-lite, met een verhoogde wired-memory-limiet, korte contexten en een gedocumenteerde kwaliteitsheffing op lange code. Een enkele H200 krijgt dezelfde build met ~39 GB KV-headroom. Serverhardware krijgt de echte ladder, van 4-bit als standaard tot bijna verliesvrije 6-bit. En voor alle anderen — de meeste lezers — is het gehoste z-ai/glm-5.3-flash-endpoint het juiste antwoord; de bovenstaande cijfers zijn de reden, geen boodschappenlijst. Voor de stapsgewijze installatie op een MacBook Pro behandelt onze MacBook-installatiehandleiding de hele flow van begin tot eind; voor hoe de kwantiseringsbuilds zich qua kwaliteit verhouden en wanneer je welke kiest, geeft de MLX-buildgids de details; en de releaseverslaggeving bevat de lanceercontext en benchmarkclaims.