Egy nagyjából 2000-3000 dolláros unified memory miniPC be tud tölteni néhány erősen kvantált 235B osztályú modellt, amely nem fér el egy egyetlen H100-osztályú GPU-n.
Ez visszásnak hangzik, ezért pontosítsuk az összehasonlítást. A drága kártya sokkal gyorsabb, de a helyi GPU-memóriája kisebb. A kis doboz az asztalon rendelkezhet nagyobb megosztott memóriapoollal, így a modell betölthető, még ha a generálás lassú is.
Az egyszavas válasz a hogyanra: "unified memory". Ez sok új AI-miniPC és Mac adatlapján kiemelt számként szerepel ("128 GB unified memory"), és szinte senki sem magyarázza el, mit is csinál valójában. Ezért ez itt a feladat. A cikk végére tudni fogod, mi az unified memory, miért teszi lehetővé, hogy egy kis gép futtatás olyan modellt futtatni, amelyhez korábban egy szerverrack kellett, és a bökkenőt, amit senki sem ír a főcímbe: lassan futtatja azt a modellt.
Röviden
- Az unified memory egyetlen fizikai memóriapool, amelyet egy lapkakészlet CPU-ja és integrált GPU-ja oszt meg egymással, ahelyett, hogy egy különálló grafikus kártya kicsi, elkülönített VRAM-ja ülne a különálló rendszer RAM mellett.
- Ez a megosztott memóriapool nagy méretű, és a GPU jellemzően sokkal több memóriához fér hozzá, mint egy különálló kártya rögzített VRAM-korlátja, bár a pontosan felhasználható mennyiség a platformtól, a firmware-beállításoktól, az operációs rendszertől és a futtatókörnyezettől függ. Így az első kérdés az lesz: ez a kvantált build belefér-e a felhasználható memóriába? Egy 128GB-os pool olyan modelleket is elférhet, amelyeket egy 24GB-os vagy 32GB-os grafikus kártya soha nem tudna befogadni.
- A bökkenő a sebesség, nem a méret. Az unified memory sokkal lassabban mozgatja az adatokat, mint egy különálló kártya VRAM-ja. A nagy modell fut. Csak lassan generál tokeneket. Az unified memory lehetővé teszi, hogy futtasd a nagy modellt, nem azt, hogy gyorsan futtasd.
- Az "unified" nem egyetlen dolgot jelent. Az Apple verziója nagyrészt láthatatlan a felhasználó számára; az AMD verziója több beállítási lehetőséget kínál, mivel a firmware- és illesztőprogram-beállítások befolyásolhatják, mennyi memóriát tartanak fenn a GPU számára, vagy mennyi az, amit a GPU ténylegesen felhasználhat. És a több memória nem jelent gyorsabbat.
Mi az az unified memory?
Képzelj el két elrendezést. Egy különálló grafikus kártyának saját memóriája (VRAM) van közvetlenül a processzora mellé szerelve, gyors, de kicsi. A rendszer RAM egy második, különálló pool, amelyet a CPU használ. Ahhoz, hogy egy modell fusson a GPU-n, az adatokat először a rendszer RAM-ból a PCIe-buszon keresztül a VRAM-ba kell másolni. Két pool, egy másolási lépés.
Az unified memory eldobja ezt a szétválasztást. Ez egyetlen fizikai memóriapool, amelyet a lapkakészlet CPU-ja és integrált GPU-ja is megoszt, így a GPU a megosztott poolból dolgozhat ahelyett, hogy egy kicsi, különálló VRAM-tárolóra hagyatkozna. Az Apple Silicon-hoz hasonló platformokon ez egyúttal elkerüli a régi, PCIe-n keresztüli másolási lépést is. Az Apple saját architektúráról szóló előadása úgy írja le, hogy a CPU és a GPU "ugyanazon a memórián dolgozik", anélkül hogy adatot kellene másolni egy PCIe-buszon keresztül. Egy pool. Nulla másolás.
A megosztott pool általában a csomagra forrasztott LPDDR5X memória, ez teszi lehetővé, hogy egyszerre legyen nagy méretű és közel a processzorhoz. A jelenlegi kiemelt példák az Apple Silicon Macek, az AMD Strix Halo rendszerei, amelyek olyan lapkákra épülnek, mint a Ryzen AI Max+ 395, valamint az Nvidia DGX Spark. Az AMD Ryzen AI Halo fejlesztői platformja 128GB LPDDR5x memóriát sorol fel 256GB/s sebességgel, míg az Nvidia DGX Spark 128GB LPDDR5x unified rendszermemóriát sorol fel 273GB/s sebességgel.
A megosztott memória a CPU és az integrált GPU között nem újdonság. A laptopok évek óta így működnek, és ez általában kompromisszumot jelentett: lassú memória, nem is sok belőle. Ami megváltozott, az a kapacitás a felhasználható sávszélesség mellett. Amint egy megosztott pool elég nagy lett, nagyjából a 128GB-os osztályban, miközben elég gyors is maradt ahhoz, hogy érdemes legyen használni, átlépte azt a határt, ahol nagyon nagy, nyílt súlyú modellek is elférhettek helyben. Ez a teljes történet. Az architektúra régi; a méret az új.
Egy megjegyzés a "vs VRAM" kapcsán: az emberek gyakran megkérdezik, hogy az unified memory ugyanaz-e, mint a VRAM. Nem egészen. A VRAM egy különálló kártyán található dedikált grafikus memória, gyors és elkülönített. Az unified memory egyetlen megosztott pool, amely egyszerre látja el a VRAM és a rendszer RAM feladatát. Cserébe a különálló kártya nyers sebességéért méretet és a másolási lépés elhagyásának lehetőségét kapod.
Miért kell egy modellnek elférnie a memóriában?
A szokásos, memórián belüli következtetéshez a modell súlyainak olyan memóriában kell lenniük, amelyet a processzor el tud érni. Ha a felhasználható memória túl kicsi, a modell nem tölthető be tisztán az adott eszközön. Egyes eszközök képesek a modell egyes részeit CPU-memóriába vagy tárolóra kiszervezni, de ez erősen megváltoztatja a teljesítményprofilt, és nem ugyanaz, mintha a modell kényelmesen elférne a GPU által elérhető memóriában. A kapacitás egy kemény kapu, amely megelőz minden sebességgel kapcsolatos kérdést.
Ez az a kar, amelyet az unified memory megmozgat. Sok fogyasztói grafikus kártyának 24GB VRAM-ja van vagy kevesebb, és még a csúcskategóriás egykártyás fogyasztói modellek is csak nagyjából 32GB körül mozognak. Egy 70 milliárd vagy 235 milliárd paraméteres modell messze túl nagy ehhez. A nyers 4-bites aritmetika 235B paraméterhez nagyjából 118GB-nál kezdődik, még a formátum-overhead, a futtatókörnyezet pufferei és a kontextusmemória nélkül. A gyakorlatban a ténylegesen letölthető buildek sokat változnak: például az Ollama Qwen3-235B-A22B Q4_K_M buildje 142GB-osként szerepel, míg az agresszívabb, alacsonyabb bitszámú kvantálások közelebb kerülhetnek ahhoz a tartományhoz, amelyet egy 128GB-os unified memory gép kezelni tud. Így a feladatra tervezett kártyából elfogy a hely, mielőtt egyáltalán elkezdhetné. (Hogy hogyan számítják ki ezeket a memóriaértékeket, paraméterek szorozva a súlyonkénti bájtszámmal, plusz az az overhead, amelyet a fájlméret elrejt, az egy külön téma, és a a kvantálási matematikáról szóló testvércikk elvégzi ezt a számítást.)
Egy 128GB-os unified pool egyetlen kérdésre változtatja meg a választ: elfér-e ez a konkrét kvantált build azután, hogy az operációs rendszer, a futtatókörnyezet, a KV cache és a GPU-allokációs korlátok elveszik a maguk részét? Néhány agresszív 235B osztályú kvantálás esetén igen. Ezért tud néha egy kompakt unified memory doboz olyan modellt betölteni, amelyet egy kisebb VRAM-mal rendelkező GPU nem. Nem arról van szó, hogy erősebb lenne. Csak nagyobb helye van, ahová a modellt teheti.
Ez az első dolog, amit a főcímek helyesen mondanak, de magyarázat nélkül hagynak. A pool mérete, nem a nyers teljesítmény dönti el, hogy a modell egyáltalán elindul-e.
Miért lassabb az unified memory, mint egy grafikus kártya?
A szöveg egyenkénti, tokenenkénti generálását a memória korlátozza sávszélesség, nem attól, milyen gyorsan tud a processzor számolni. Minden egyes előállított token azt igényli, hogy a modell aktív súlyai átfolyjanak a processzoron, így a sebességkorlátot az szabja meg, milyen gyorsan tudja a memória táplálni a lapkát. Ez a jól dokumentált "memóriakorlátos" jellege az egyszálú dekódolásnak, a lapka idejének nagy részét memóriára várakozással tölti, nem számítással.
És a sávszélesség pontosan az a terület, ahol az unified memory teret veszít. Az AMD Strix Halo poolja papíron 256GB/s sebességgel fut, és a llm-tracker.info független tesztje szerint a gyakorlatban körülbelül 212GB/s-ot mér. A DGX Spark 273GB/s-on áll. Egy csúcskategóriás, különálló grafikus kártya ezzel szemben többszörösen gyorsabban mozgatja az adatokat, hiszen dedikált VRAM-ja pontosan erre lett tervezve. Így amikor egy modell elfér mindkettő egy unified dobozban is és egy különálló kártyán is, a különálló kártya érzékelhetően gyorsabban generál tokeneket. Ugyanaz a modell, ugyanaz az eredmény, nagyon eltérő sebesség.
Sűrű (dense) modellek esetén hasznos ökölszabály:
tokens/másodperc ≈ memória-sávszélesség ÷ a modell mérete a memóriában.
Ez inkább irányadó, nem egy benchmark, de megmagyarázza az átváltást: a kisebb rezidens súlyok vagy a nagyobb sávszélesség általában gyorsabb dekódolást jelent. MoE modellek esetén ne alkalmazd a szabályt közvetlenül a teljes paraméterszámra. A kapacitás továbbra is a teljes tárolt súlytól függ, de a tokenenkénti sebesség inkább az aktivált útvonaltól, a routing-overheadtől, a cache viselkedésétől és az implementációtól függ.
Egy árnyalatnyi kiegészítés, aztán békén hagyom: egy kérésnek két fázisa van. A prompt beolvasása (prefill) inkább a számítási teljesítményre támaszkodik. A válasz generálása (decode) inkább a sávszélességre. A lassú rész, amit érzékelsz, a szavak egyesével történő megjelenése, az a sávszélesség-korlátos rész.
Íme tehát a tanulság, amit az adatlap kihagy: az unified memory lehetővé teszi, hogy futtasd a nagy modellt, nem azt, hogy gyorsan futtasd. Megnyeri a kapacitás körüli vitát, és elveszíti a sávszélességét. Hogy ez a csere megéri-e, teljesen attól függ, mit csinálsz, és ez egy tisztességes csere, amit tudatosan kell megkötni, nem egy meglepetés, amit vásárlás után fedezel fel.
Minden unified memory ugyanaz?
Nem. Az "unified" egy kategóriát ír le, nem egyetlen konkrét megvalósítást, és a verziók olyan módokon térnek el, amelyek számítanak. Az Apple verziója nagyrészt láthatatlan a felhasználó számára: a memória alapértelmezetten megosztott. Az AMD Strix Halo inkább kézi beavatkozást igényel: firmware- és illesztőprogram-beállítások befolyásolhatják, mennyi memóriát tartanak fenn a GPU számára, vagy mennyi az, amit a GPU ténylegesen felhasználhat. Mindkettő unified memory. De nem ugyanaz az élmény.
Hadd nevezzem meg azt a téves elképzelést, amelyet ez az egész téma szül, mert ez a leggyakoribb: a több memória nem jelent gyorsabb inferenciát. Azt jelenti, hogy egy nagyobb modell tud futni. Valaki megvesz egy 128GB-os dobozt sebességet remélve, betölt egy olyan modellt, amely egy 24GB-os különálló kártyán is elférne, és csalódik, hogy lassabban fut, mint a kisebb kártyán futott volna. Mindkét állítás egyszerre igaz: a nagy pool több mindent befogad, a kicsi, gyors kártya pedig gyorsabban futtatja azt, ami közös bennük. A méret és a sebesség két különböző tengely. Az unified memory az elsőt vásárolja meg neked.
Egy gyakorlati bökkenő az AMD oldalon: hogy a poolból ténylegesen mennyi használható fel egy modellhez, az a firmware-beállítástól és az operációs rendszertől függ. Az AMD Variable Graphics Memory GYIK-je leírja, hogyan működik ez az allokáció; a rövid verzió az, hogy egy 128GB-os doboz nem adja át mind a 128GB-ot a GPU-nak, és a felhasználható mennyiség a VGM-beállítástól, a fenntartott rendszermemóriától, az operációs rendszertől és a futtatókörnyezettől függ. A tervezésnél a felhasználható memóriával számolj, ne a matricán szereplő számmal.
Profi tipp: amikor egy gépet méretezel helyi modellekhez, két számként olvasd az adatlapot, ne egyként. A kapacitás megmondja, mely modellek férnek el. A sávszélesség megmondja, milyen gyorsan futnak majd, ha már elférnek. Egy hatalmas poollal, de szerény sávszélességgel rendelkező doboz olyan doboz, amely lassan futtatja a nagy modelleket, ami pontosan az lehet, amit szeretnél, feltéve, hogy ezt már előre tudtad.
Van még egy eset, amelyet érdemes kiemelni, mert ez az, ami az embereket megzavarja ezeken a nagy poolú gépeken: a Mixture-of-Experts modellek. Egy olyan modell, mint a Qwen3-235B-A22B összesen 235 milliárd paraméterrel rendelkezik, de ezekből tokenenként csak nagyjából 22 milliárdot aktivál. Csábító azt feltételezni, hogy ez azt jelenti, csak az aktív részhez szükséges memória kell. A szokásos, memórián belüli következtetéshez azonban nem ez a helyzet. Mind a 235 milliárd súlynak jelen kell lennie valahol, amit a futtatókörnyezet elérhet, mert bármelyik token bármelyik szakértőhöz irányítható: csak a tokenenkénti számítási igény csökken, a kapacitásigény nem. Pontosan ez az a különbség, ahol az unified memory nagy poolja megmutatja az értékét, és a a kvantálási matematikáról szóló testvércikk végigszámolja, mire jönnek ki ezek a számok.
Gyakran ismételt kérdések
Az unified memory ugyanaz, mint a VRAM?
Nem. A VRAM egy különálló grafikus kártyába épített, dedikált, nagysebességű memória, elkülönítve a rendszer RAM-tól. Az unified memory egyetlen megosztott pool, amelyet a CPU és a GPU is használ, és egyszerre látja el a VRAM és a rendszer RAM feladatát. Az unified memory általában nagyobb, de lassabb, mint egy különálló kártya VRAM-ja, és kihagyja az adatok két pool közötti másolásának lépését.
Miért lassú a helyi modellem, ha egyszer elfér a memóriában?
Mert az elférés és a gyors futás két különböző dolog. Hogy egy modell betöltődik-e, az a memóriakapacitástól függ; hogy milyen gyorsan generál szöveget, az a memória sávszélességétől. Az unified memory bőséges kapacitással rendelkezik, de sokkal alacsonyabb sávszélességgel, mint egy különálló grafikus kártya, így egy kényelmesen elférő modell mégis lassan generálhat tokeneket. Sűrű (dense) modellek esetén a durva összefüggés: tokens/másodperc ≈ sávszélesség ÷ modellméret. MoE modellek esetén a kapacitás továbbra is a teljes tárolt súlyoktól függ, de a sebesség inkább az aktivált útvonaltól és a futtatókörnyezet implementációjától függ.
Szükséged van még GPU-ra, ha van unified memoryd?
Az integrált GPU már eleve része egy unified memory lapkakészletnek, ez az, ami futtatja a modellt. Az igazi kérdés az, hogy szeretnél-e emellé egy különálló GPU-t is. Sok különálló kártya sokkal nagyobb sávszélességet ad, ami gyorsabb generálást jelent, de kevesebb helyi memóriát, mint egy nagy unified memory rendszer, így önmagukban esetleg nem tudják befogadni a legnagyobb modelleket. Az unified memory egy nagy poolt ad, amely befogadja a nagy modelleket, alacsonyabb sebesség mellett. Hogy melyiket akarod, az a modellméret és a sebesség közötti mérlegeléstől függ.
Miért tud egy miniPC futtatni egy olyan modellt, amelyhez adatközponti GPU kell?
Mert a modellbetöltés szűk keresztmetszete a memóriakapacitás, és egy nagy unified pool-lal rendelkező miniPC-nek több felhasználható modellmemóriája lehet, mint sok egy-GPU-s elrendezésnek. Egy fogyasztói GPU-nak 24-32GB VRAM-ja lehet, egyetlen H100-osztályú adatközponti GPU-nak pedig 80-94GB-ja van, míg néhány unified memory rendszer 128GB-os megosztott poolt hirdet. A modell súlyainak mind el kell férniük valahol, amit a processzor elér; a nagy megosztott pool befogadja őket, a kicsi, gyors VRAM nem. A miniPC nem erősebb. Egyszerűen csak több helye van.
Az elférés a nyereség: a következő kérdés az, mennyire van szükség
Az unified memory hozzájárulása egyetlen tiszta dolog: egy nagy, megosztott, címezhető pool, amely lehetővé teszi, hogy egy kis gép elférni olyan modelleket, amelyekhez korábban szerver kellett. Ez a kapacitásbeli győzelem. A sávszélesség bökkenője az ára, és most már úgy tudsz olvasni egy adatlapot, hogy tudod, melyik szám melyik viselkedést irányítja.
A természetes következő kérdés az, amit ez a cikk végig továbbadott: mennyi memóriára van ténylegesen szüksége egy adott modellnek? Ez matematika: paraméterek, súlyonkénti bájtszám, a választott tömörítési szint, és a kontextus-adó, amelyet a fájlméret elrejt. GGUF, GPTQ, AWQ és EXL2 kvantálásról szóló testvércikk pontosan ezt a matematikát vezeti végig, és érdemes elvégezni, mielőtt méretezel egy gépet vagy kiválasztasz egy modellt.
