En unified-memory mini-pc til omkring $2.000-$3.000 kan indlæse nogle kraftigt kvantiserede 235B-klasse-modeller, som ikke passer på en enkelt H100-klasse GPU.
Det lyder bagvendt, så lad os præcisere sammenligningen. Det dyre kort er meget hurtigere, men dets lokale GPU-hukommelse er mindre. Den lille boks på skrivebordet kan have en større delt pulje, så modellen kan indlæses, selv om genereringen er langsom.
Svaret på hvordan i ét ord er "unified memory." Det er trykt på datablade for mange nye AI-mini-pc'er og Mac'er som et fremtrædende tal ("128 GB unified memory"), og næsten ingen forklarer, hvad det egentlig gør. Det er opgaven her. Ved slutningen ved du, hvad unified memory er, hvorfor det giver en lille maskine mulighed for at køre en model, der plejede at kræve et serverrack, og fangsten, som ingen sætter i overskriften: den kører den model langsomt.
Kort sagt
- Unified memory er én fysisk hukommelsespulje, som en chips CPU og integrerede GPU deler, i stedet for et diskret grafikkorts lille, separate VRAM, der sidder ved siden af dit separate system-RAM.
- Den delte pulje er stor, og GPU'en kan normalt tilgå langt mere hukommelse end et diskret korts faste VRAM-grænse, selvom den præcise brugbare mængde afhænger af platformen, firmwareindstillingerne, OS'et og runtime. Så det første spørgsmål bliver: passer denne kvantiserede build ind i den brugbare hukommelse? En 128GB pulje kan rumme modeller, som et 24GB eller 32GB grafikkort aldrig kunne.
- Fangsten er hastighed, ikke størrelse. Unified memory flytter data langt langsommere end et diskret korts VRAM. Den store model kører. Den genererer bare tokens langsomt. Unified memory lader dig køre den store model, ikke køre den hurtigt.
- "Unified" er ikke én ting. Apples version er stort set usynlig for brugeren; AMD's version blotlægger flere justeringsmuligheder, fordi firmware- og driverindstillinger kan påvirke, hvor meget hukommelse der reserveres til, eller reelt kan bruges af, GPU'en. Og mere hukommelse betyder ikke hurtigere.
Hvad er unified memory?
Forestil dig to opsætninger. Et diskret grafikkort har sin egen hukommelse (VRAM) fastmonteret lige ved siden af sin processor, hurtig men lille. Dit system-RAM er en anden, separat pulje, som CPU'en bruger. For at køre en model på GPU'en skal data først kopieres fra system-RAM over PCIe-bussen ind i VRAM. To puljer, ét kopieringstrin.
Unified memory smider den opdeling ud. Det er én fysisk hukommelsespulje, som chippens CPU og integrerede GPU begge deler, hvilket lader GPU'en arbejde ud fra den delte pulje i stedet for at være afhængig af en lille separat VRAM-boks. På platforme som Apple Silicon undgår dette også det gamle kopieringstrin over PCIe. Apples eget arkitekturforedrag beskriver det som, at CPU og GPU "arbejder over den samme hukommelse" uden behov for at kopiere data over en PCIe-bus. Én pulje. Nul kopiering.
Den delte pulje er som regel LPDDR5X-hukommelse loddet fast på pakken, hvilket er det, der gør den både stor og tæt på processoren. De fremtrædende eksempler lige nu er Apple Silicon Mac'er, AMD's Strix Halo-systemer bygget omkring chips som Ryzen AI Max+ 395, og Nvidias DGX Spark. AMD's Ryzen AI Halo-udviklerplatform opgiver 128GB LPDDR5x-hukommelse ved 256GB/s, mens Nvidias DGX Spark opgiver 128GB LPDDR5x unified systemhukommelse ved 273GB/s.
Delt hukommelse mellem en CPU og en integreret GPU er ikke nyt. Bærbare computere har gjort det i årevis, og det var som regel et kompromis: langsom hukommelse, og ikke ret meget af den. Det, der har ændret sig, er kapacitet ved brugbar båndbredde. Da en delt pulje blev stor nok, omkring 128GB-klassen, mens den forblev hurtig nok til at være værd at bruge, krydsede den grænsen for, hvornår meget store open-weight-modeller kunne indlæses lokalt. Det er hele historien. Arkitekturen er gammel; størrelsen er ny.
En bemærkning om "vs. VRAM": Folk spørger, om unified memory er det samme som VRAM. Ikke helt. VRAM er dedikeret grafikhukommelse på et diskret kort, hurtig og separat. Unified memory er én delt pulje, der udfører jobbet for både VRAM og system-RAM. Den bytter det diskrete korts rå hastighed for størrelse og muligheden for at springe kopieringstrinnet over.
Hvorfor skal en model kunne være i hukommelsen?
Ved normal in-memory-inferens skal modellens vægte ligge i hukommelse, som processoren kan adressere. Hvis den brugbare hukommelse er for lille, vil modellen ikke indlæses rent på den enhed. Nogle værktøjer kan aflaste dele af en model til CPU-hukommelse eller lager, men det ændrer performance-profilen markant og er ikke det samme som, at modellen passer komfortabelt ind i GPU-adresserbar hukommelse. Kapacitet er en hård spærre, der kommer før ethvert spørgsmål om hastighed.
Det er den håndtag, unified memory trækker i. Mange forbrugergrafikkort har 24GB VRAM eller mindre, og selv topmodeller blandt enkelte forbrugerkort ligger på omkring 32GB. En model med 70 milliarder eller 235 milliarder parametre er alt for stor til det. Rå 4-bit-aritmetik for 235B parametre starter omkring 118GB, før format-overhead, runtime-buffere og context-hukommelse. I praksis varierer de faktiske downloadbare builds meget: for eksempel Ollamas Qwen3-235B-A22B Q4_K_M build opgives til 142GB, mens mere aggressive lav-bit-kvantiseringer kan komme tættere på det interval, en 128GB unified-memory-maskine kan håndtere. Så kortet, der er bygget til opgaven, løber tør for plads, før det overhovedet kan begynde. (Hvordan de hukommelsestal beregnes, parametre gange bytes per vægt plus det overhead, filstørrelsen skjuler, er sit eget emne, og søsterartiklen om kvantiseringsmatematik gennemgår regnestykket.)
En 128GB unified pulje ændrer svaret på ét spørgsmål: passer denne bestemte kvantiserede build ind, efter OS, runtime, KV cache og GPU-allokeringsgrænser har taget deres andel? For nogle aggressive 235B-klasse-kvantiseringer, ja. Det er derfor en kompakt unified-memory-boks nogle gange kan indlæse en model, som en GPU med mindre VRAM ikke kan. Den er ikke mere kraftfuld. Den har bare et større rum at placere modellen i.
Det er den første ting, overskrifterne får ret i og lader stå uforklaret. Puljestørrelse, ikke rå kraft, er det, der afgør, om modellen overhovedet kører.
Hvorfor er unified memory langsommere end et grafikkort?
At generere tekst ét token ad gangen begrænses af hukommelse båndbredde, ikke af, hvor hurtigt processoren kan regne. Hvert token, du producerer, kræver at strømme modellens aktive vægte gennem processoren, så hastighedsloftet er, hvor hurtigt hukommelsen kan fodre chippen. Dette er den velbeskrevne "hukommelsesbundne" natur ved single-stream decoding, chippen bruger det meste af sin tid på at vente på hukommelsen, ikke på at beregne.
Og båndbredde er præcis der, hvor unified memory må vige. AMD's Strix Halo-pulje kører på papiret ved 256GB/s, og uafhængig test hos llm-tracker.info måler den til omkring 212GB/s i praksis. DGX Spark ligger på 273GB/s. Et high-end diskret grafikkort flytter til sammenligning data flere gange hurtigere, dets dedikerede VRAM er bygget til netop det. Så når en model passer ind i begge både en unified-boks og et diskret kort, genererer det diskrete kort tokens markant hurtigere. Samme model, samme resultat, meget forskellig hastighed.
For dense modeller er en nyttig tommelfingerregel:
tokens pr. sekund ≈ hukommelsesbåndbredde ÷ modelstørrelse i hukommelsen.
Det er retningsgivende, ikke et benchmark, men det forklarer afvejningen: mindre residente vægte eller højere båndbredde betyder som regel hurtigere decoding. For MoE-modeller skal reglen ikke anvendes direkte på det samlede antal parametre. Kapacitet afhænger stadig af de samlede lagrede vægte, men hastigheden pr. token afhænger mere af den aktiverede sti, routing-overhead, cache-adfærd og implementering.
Én nuance, så lader jeg det ligge: en forespørgsel har to faser. At læse din prompt (prefill) læner sig op ad beregning. At generere svaret (decode) læner sig op ad båndbredde. Den langsomme del, du mærker, ord der dukker op ét ad gangen, er den båndbreddebundne del.
Så her er konklusionen, databladet springer over: unified memory lader dig køre den store model, ikke køre den hurtigt. Den vinder kapacitetsargumentet og taber båndbreddeargumentet. Om den byttehandel er værd, afhænger helt af, hvad du laver, og det er en fair byttehandel at indgå bevidst, ikke en overraskelse at opdage efter købet.
Er al unified memory ens?
Nej. "Unified" beskriver en kategori, ikke én bestemt implementering, og versionerne adskiller sig på måder, der betyder noget. Apples version er stort set usynlig for brugeren: hukommelsen deles som standard. AMD's Strix Halo kræver mere håndsætning: firmware- og driverindstillinger kan påvirke, hvor meget hukommelse der reserveres til, eller reelt kan bruges af, GPU'en. Begge er unified memory. Det er ikke den samme oplevelse.
Lad mig nævne den misforståelse, hele dette emne skaber, for det er den mest almindelige: mere hukommelse betyder ikke hurtigere inferens. Det betyder, at en større modeller kan køre. Nogen køber en 128GB-boks i forventning om hastighed, indlæser en model, der også passer på et 24GB diskret kort, og bliver skuffet over, at den kører langsommere end det mindre kort gjorde. Begge udsagn er sande på samme tid: den store pulje rummer mere, og det lille hurtige kort kører hurtigere på det, de har til fælles. Størrelse og hastighed er forskellige akser. Unified memory køber dig den første.
En praktisk detalje på AMD-siden: hvor meget af puljen, der faktisk er brugbar til en model, afhænger af firmwareindstillingen og styresystemet. AMD's Variable Graphics Memory FAQ gennemgår, hvordan den allokering fungerer; den korte version er, at en 128GB-boks ikke giver alle 128GB til GPU'en, og den brugbare mængde afhænger af VGM-indstillingen, reserveret systemhukommelse, styresystemet og runtime. Planlæg ud fra brugbar hukommelse, ikke det tal, der står på mærkatet.
Godt råd: Når du dimensionerer en maskine til lokale modeller, skal du læse databladet som to tal, ikke ét. Kapacitet fortæller dig, hvilke modeller der passer. Båndbredde fortæller dig, hvor hurtigt de vil køre, når de først gør. En boks med en enorm pulje og beskeden båndbredde er en boks, der kører store modeller langsomt, hvilket måske er præcis, hvad du vil have, så længe du vidste det på forhånd.
Der er endnu et tilfælde, det er værd at fremhæve, fordi det snubler folk på disse maskiner med store puljer: Mixture-of-Experts-modeller. En model som Qwen3-235B-A22B har 235 milliarder parametre i alt, men aktiverer kun omkring 22 milliarder af dem pr. token. Det er fristende at antage, at det så kun kræver hukommelse til det aktive udsnit. Ved normal in-memory-inferens gør det ikke det. Alle 235 milliarder vægte skal stadig ligge et sted, runtime kan bruge, fordi ethvert token potentielt kan sendes til enhver ekspert: kun beregningen pr. token reduceres, ikke kapacitetskravet. Det er præcis der, unified memorys store pulje betaler sig, og søsterartiklen om kvantiseringsmatematik gennemgår, hvad de tal ender med at være.
Ofte stillede spørgsmål
Er unified memory det samme som VRAM?
Nej. VRAM er dedikeret højhastighedshukommelse indbygget i et diskret grafikkort, holdt adskilt fra dit system-RAM. Unified memory er én delt pulje, som både CPU og GPU bruger, og som udfører jobbet for både VRAM og system-RAM på én gang. Unified memory er som regel større, men langsommere end et diskret korts VRAM, og det springer trinnet med at kopiere data mellem to puljer over.
Hvorfor er min lokale model langsom, selv om den passer i hukommelsen?
Fordi at passe ind og at køre hurtigt er to forskellige ting. Om en model kan indlæses, afhænger af hukommelseskapacitet; hvor hurtigt den genererer tekst, afhænger af hukommelsesbåndbredde. Unified memory har rigelig kapacitet, men langt lavere båndbredde end et diskret grafikkort, så en model, der passer komfortabelt, kan stadig generere tokens langsomt. For dense modeller er den omtrentlige sammenhæng tokens pr. sekund ≈ båndbredde ÷ modelstørrelse. For MoE-modeller afhænger kapaciteten stadig af de samlede lagrede vægte, men hastigheden afhænger mere af den aktiverede sti og runtime-implementeringen.
Har du stadig brug for en GPU, hvis du har unified memory?
Den integrerede GPU er allerede en del af en unified-memory-chip, det er den, der kører modellen. Det egentlige spørgsmål er, om du også vil have et diskret GPU. Mange diskrete kort giver dig langt højere båndbredde, hvilket betyder hurtigere generering, men mindre lokal hukommelse end et stort unified-memory-system, så de kan muligvis ikke rumme de allerstørste modeller alene. Unified memory giver dig en stor pulje, der rummer store modeller ved lavere hastighed. Hvad du vil have, afhænger af modelstørrelse versus hastighed.
Hvorfor kan en mini-pc køre en model, der kræver en datacenter-GPU?
Fordi flaskehalsen ved indlæsning af en model er hukommelseskapacitet, og en mini-pc med en stor unified pulje kan have mere brugbar modelhukommelse end mange single-GPU-opsætninger. En forbruger-GPU kan have 24-32GB VRAM, og en enkelt H100-klasse datacenter-GPU har 80-94GB, mens nogle unified-memory-systemer reklamerer med 128GB delte puljer. Modellens vægte skal alle passe et sted, processoren kan nå; den store delte pulje rummer dem, den lille hurtige VRAM gør ikke. Mini-pc'en er ikke mere kraftfuld. Den har bare plads.
At passe ind er gevinsten: Hvor meget det kræver, er det næste spørgsmål
Unified memorys bidrag er én ren ting: en stor, delt, adresserbar pulje, der lader en lille maskine rumme modeller, der plejede at kræve en server. Det er kapacitetsgevinsten. Båndbreddefangsten er prisen, og nu kan du læse et datablad og vide, hvilket tal der styrer hvilken adfærd.
Det naturlige næste spørgsmål er det, denne artikel hele tiden har givet videre: hvor meget hukommelse har en given model egentlig brug for? Det er regnestykke: parametre, bytes pr. vægt, det kompressionsniveau du vælger, og den context-skat, filstørrelsen skjuler. søsterartiklen om GGUF-, GPTQ-, AWQ- og EXL2-kvantisering gennemgår præcis det regnestykke, og det er værd at gøre, før du dimensionerer en boks eller vælger en model.
