Mennyi memóriát hagyjon az AI-segédnek 1080p-s streamelésnél

Először számolja ki, mi van már foglalva

Az AI-segéd nem vákuumban működik: osztozik a hardveren a játékkal, a kódolóval és magával a streammel. Mielőtt memóriát osztana ki, számolja ki, mennyit fogyasztanak már a többi résztvevők. 1080p-nél a fő terhelés a kódolóra hárul – hardveres a videokártyán vagy szoftveres a processzoron –, plusz magára a játékra és a képernyőrögzítésre.

Gyakorlati iránymutatás: ha a játék és a kódoló együtt a videomemória jelentős részét foglalja, a szabad maradék a modellre megy, nem a gyorsítótárra – és akkor nem a memóriahiány miatt kap akadozást, hanem annak állandó újraelosztása miatt. Ezért ne azt számolja, hogy „mennyit adjak”, hanem azt, hogy „mennyi maradt a játék és a kódoló után”.

Helyi modell vagy felhő

Ez a fő elágazás, és minden ettől függ.

A felhős segéd szinte nem fogyaszt helyi memóriát: a kérések a hálózaton mennek, a gépén csak a kliens marad. A kérdés ilyenkor nem a gigabájtokban van, hanem a csatorna stabilitásában és a késleltetésben – aktív streamelésnél az upload már foglalt, és a segéd osztozik rajta a videóval. Ha a csatorna szűk, a segéd szünetekkel válaszol, vagy verseng a streammel a sávszélességért.

A helyi modell a súlyokat folyamatosan a videomemóriában vagy az operatív memóriában tartja. Itt a memória közvetlen kiadás, amelyet előre félre kell tenni. Cserébe nincs hálózati késleltetés, és az upload szabad.

Mennyi videomemóriát igényel egy helyi modell

A pontos számok a modelltől és a kvantálástól függenek, de a képlet alapján számolhat: a paraméterek számát szorozza meg a tárolási bitszámmal. 4 bites kvantálásnál minden milliárd paraméter valamivel több mint fél gigabájtot foglal – plusz a kiszolgáló pufferek és a kontextus-gyorsítótár többletköltsége. Innen a VRAM-ra vonatkozó gyakorlati iránymutatások:

• 3–4 milliárd paraméteres modell 4 biten – körülbelül 2–3 GB;
• 7–8 milliárd paraméter 4 biten – nagyjából 4,5–5,5 GB;
• 13–14 milliárd paraméter 4 biten – mintegy 8–9 GB;
• 30–34 milliárd paraméter 4 biten – körülbelül 18–20 GB.

Ezekhez a számokhoz adja hozzá a kontextus-gyorsítótárat: ez a párbeszéd hosszával együtt nő, és hosszú levelezésnél több gigabájttal is megnövelheti a fogyasztást. A teljes pontosság a kvantálás helyett 3–4-szeresére növeli a súlyok méretét, és 1080p-s streamelésnél ez szinte mindig azt jelenti, hogy nem marad videomemória a játékra.

Melyik 7–8 milliárdos modellt válasszuk streameléshez

A 7–8B osztály 4 bites kvantálásban a munkaközép a 12–16 GB VRAM-os konfigurációkhoz. A streamer chat-segédjeként az olyan családok instruct-verzióit szokás nézni, mint a Qwen, Llama, Mistral, Gemma: ezek kiszámíthatóan számolhatók a fenti képlettel, és beleférnek a megadott méretekbe. A köztük lévő különbség az orosz nyelvű válaszok minőségében és a generálás tempójában van, nem a memóriaigényben – a paraméterek száma nagyjából ugyanannyi.

Egy olyan segédhez, amely a chatet olvassa és rövid replikákkal súg reakciókat, elég a 7–8B mérsékelt kontextussal. A 3–4B-s modellek észrevehetően gyengébbek az összefüggő szövegben, de 2–3 GB-ot felszabadítanak a játéknak. A teljes, nem kvantált súlyok 7–8B-nél a többszörösét foglalják, és 1080p-s streamelésnél nem férnek bele a keretbe.

VRAM-hiány és offload: hogyan változtatja meg a számítást

Ha a súlyoknak nem jutott elég videomemória, a rétegek egy része offloaddal a rendszermemóriába kerül – és a modell tovább működik. Ennek az ára a sebesség: az adatcsere a buszon keresztül megy, az inferencia lelassul, és egyszerre fogy a RAM és a VRAM is. Az offload nem szünteti meg a számítást – átviszi a kiadást a VRAM-ból a RAM-ba, és csökkenti a válaszok tempóját.

Ezért a „tegyünk nagyobb modellt és kapcsoljunk be offloadot” aktív streamelésnél határesetű kompromisszum: a segéd tovább gondolkodik, a rendszer pedig a játék csúcsainál elkezd swappelni. Jobb kisebb modellt venni, és teljes egészében a szabad maradékba illeszteni.

Operatív memória

Ha a modell a CPU-n fut, a fogyasztás átkerül a RAM-ba: ugyanaz a fél gigabájt milliárd paraméterenként 4 biten, plusz a pufferek. A 7–8B-s modell a processzoron körülbelül 5–6 GB RAM-ot foglal a rendszer, a játék és a kódoló igényein felül, a CPU-s inferencia pedig észrevehetően lassabb – a segéd érzékelhető szünettel válaszol. Az 1080p-s szoftveres kódolás önmagában is terheli a processzort, és ezzel együtt ugyanazon a CPU-n inferenciát futtatni – biztos út a dropokhoz.

Miért nem adhatjuk oda az összes szabad memóriát

A kísértés egyszerű: ennyi szabad – mindet odaadom a modellnek. Ez hiba. A memória pufferként kell a csúcsokhoz: az asszetek betöltése a játékban, a bitráta-ingadozások a kódolónál, a rendszer háttérmunkája. Ha a modell elfoglalta a maradékot, a rendszer elkezd swappelni – és olyan fagyásokat kap, amelyek forrását nem találja azonnal. A stream csúcsai a legkellemetlenebb pillanatokban jönnek – dinamikus jeleneteknél és helyszínváltáskor.

Mivel mérjük a foglalt memóriát csúcsidőben

A Feladatkezelő átlagértékei megtévesztenek: a harc közbeni csúcsra van szüksége, nem a nyugodt képernyőre.

• az nvidia-smi ciklikus frissítéssel mutatja a foglalt VRAM-ot és a folyamatonkénti összlimitet;
• az MSI Afterburner RivaTuner overley-jel közvetlenül a játék fölé írja a foglalt VRAM-ot és a GPU-terhelést – kényelmes a csúcs szemmel követése;
• a beépített statisztika vagy az illesztőprogram overley-je ugyanezeket az értékeket adja külső programok nélkül;
• a Feladatkezelő és az Erőforrás-figyelő a RAM-hoz és a swaphoz kell – ott látszik, amikor a rendszer elkezdte kiírni az oldalakat.

Ne az átlagot nézze, hanem a munkamenet maximumát: ez határozza meg, mi marad a modellnek.

Hogyan válasszuk meg a méretet a saját konfigurációhoz

1. Indítsa el a játékot és a kódolót éles 1080p-s módban, mérje meg a csúcsot nvidia-smi-vel vagy az Afterburner overley-jével.
2. Vonja ki a csúcsot az elérhető mennyiségből – megkapja a modell felső határát, tartalékkal a csúcsokra.
3. Indítsa el a segédet, figyelje a képkockákat, a swapot és a válaszidőt.
4. Ha fagyások jelentek meg – először rövidítse a kontextust, aztán csökkentse a modell osztályát vagy kapcsoljon agresszívebb kvantálást, és ismételje, amíg el nem tűnnek a dropok és a swap.

A módszer ismételt méréseket igényel: a csúcsok játékonként és jelenetenként változnak.

Mi takarít meg valójában memóriát

Ha szűkében van a memória, több kar van, és mindegyiknek megvan az ára:

• a rövidebb kontextus és az előzmények törlése csökkenti a gyorsítótár fogyasztását, de elveszíti a párbeszéd fonalát;
• a kisebb modell vagy agresszívebb kvantálás gigabájtokat takarít meg, de romlik a válaszok minősége;
• a felhős segéd teljesen felszabadítja a helyi memóriát, cserébe késleltetést és hálózati függőséget ad;
• az 1080p hardveres kódolóra váltása leveszi a terhelést a processzorról, és gyakran többet ad, mint a gigabájtok hangolása;
• a válaszhossz és az előzmények méretének korlátozása a kliens beállításaiban kiszámíthatóan tartja a gyorsítótár fogyasztását.

Kezdje a kódolóval és a kontextussal: ezek a minőség szempontjából a legolcsóbb intézkedések. A kvantáláshoz és a modell csökkentéséhez akkor nyúljon, amikor ezek a lépések nem voltak elegendők.