Gyakorlati tapasztalatok

8, 12, 16 vagy 24 GB grafikus memória: melyik GPU elég egy helyi LLM-hez?

A modellsúlyokat, a kontextust és a futási tartalékot együtt tervezze: VRAM-osztályok áttekinthető 4 bites számítással és konkrét GGUF-fájlméretekkel.

Infrastruktúra
DAXS-logó négy memóriaszimbólum felett, 8, 12, 16 és 24 GB jelöléssel.

8, 12, 16 vagy 24 GB grafikus memória segít az előzetes választásban. Egy helyi nyelvi modell napi használhatóságát a modellverzió, a kontextus és az egyidejű használat is meghatározza. Egy rövid memória-összevetés megelőzheti a rossz vásárlást.

Mi foglalja ténylegesen a grafikus memóriát?

A tervezés három területet fed le: a betöltött modellsúlyokat, a kontextusmemóriát a KV-gyorsítótárral együtt és a futási puffereket a használt háttérrendszerben. Ezen felül hely kell más GPU-alkalmazásoknak és az üzemi tartaléknak. Egy szokásos különálló grafikus kártyánál a rendszermemória és a grafikus memória külön erőforrás.

A keret a modellsúlyokat, a kontextust és KV-tárat, a puffereket és a tartalékot foglalja magában. Összegét a ténylegesen szabad grafikus memóriával kell összevetni.
Közös keret: a súlyok, a kontextus és a futás memóriát foglalnak. Az ábra összefüggéseket, nem arányos méreteket vagy méréseket mutat.

Az osztott memóriájú rendszerek kerete más: az operációs rendszer, az alkalmazások és a modell ugyanazt a készletet használják. A pilotnak itt is a ténylegesen rendelkezésre álló memóriát és a valós feladatot kell mérnie. A névleges kapacitás egyik kialakításnál sem elegendő.

4 bit: hasznos számítás világos korlátokkal

A 7B vagy 70B jelölésben a „B” milliárd paramétert jelent. Egységes 4 bites tárolásnál a súlyok közelítő számítása: paraméterszám × 4 ÷ 8 = bájt. A kvantálás kisebb pontossággal tárolja a súlyokat. A válaszminőségre gyakorolt hatást feladatonként ellenőrizni kell.

A súlyok tisztán elméleti alsó korlátja. A decimális GB és bináris GiB külön szerepel; kontextus, metaadatok és pufferek nélkül.
Modellosztály Elméletileg 4 biten Következmény
7–8B 3,5–4,0 GB ≈ 3,26–3,73 GiB Kompakt kiindulópont az első teszthez; a konkrét fájl és a kontextus még hozzáadódik.
14B 7,0 GB ≈ 6,52 GiB A számítás önmagában nem igazolja a teljes futást egy 8 GB-os kártyán.
32B 16,0 GB ≈ 14,90 GiB A névlegesen megfelelő súlykeret sem hagy helyet a működés többi részének.
70B 35,0 GB ≈ 32,60 GiB Ebben az egyszerűsített számításban már a súlyok is meghaladják egyetlen 24 GB-os kártya kapacitását.

Egy konkrét GGUF nagyobb vagy más összetételű a számításnál. A Q4_K_M és hasonló módszerek nem egyszerűen négy biten tárolnak minden összetevőt paraméterenként. Ezért a tervben szerepeljen a pontos modellfájl és kvantálási változat , amelyet használni kívánnak.

Ellenőrizhető példa a hivatalos Qwen-fájllistákból: a Q4_K_M fájlrészek összege a Qwen2.5-Instruct modellnél 7B esetén körülbelül 4,68 GB / 4,36 GiB, 14B esetén 8,99 GB / 8,37 GiB és 32B esetén 19,85 GB / 18,49 GiB. Ezek fájlméretek, nem mért VRAM-fogyasztások. Mutatják azonban, miért nem megalapozott ígéret ennél a verziónál, hogy „32B 4 biten elfér 16 GB-on”.

A 8, 12, 16 és 24 GB értékelése

Támpont kvantált szövegmodellekkel és különálló GPU-val végzett pilothoz. Nem általános kompatibilitási vagy sebességgarancia.
Kapacitásosztály Hasznos tesztterület Fontos szempontok
8 GB Kompakt 7–8B változat és korlátozott kontextus kiindulásként. Más GPU-használat és hosszabb bemenetek gyorsan csökkenthetik a keretet.
12 GB Több hely kompakt modelleknek; konkrét 14B-kvantálást kell célzottan tesztelni. A súlyoknak, a KV-tárnak és a puffereknek együtt kell elférniük a szabad memóriában.
16 GB További tartalék megfelelő kisebb és közepes modellváltozatokhoz. Az említett Qwen2.5-32B-Q4_K_M már teljes fájlként sem fér ebbe az osztályba.
24 GB Egy megfelelő 32B-kvantálás bekerülhet a szűkebb választékba. A hosszú kontextust és a párhuzamos kéréseket külön is tesztelni kell. Ebből nem következik a 70B támogatása.

Ellenőrizze a mérőeszköz egységét és a szabad memóriát. Két azonos kapacitású kártya jelentősen eltérhet sávszélességben, számítási teljesítményben, illesztőprogram-támogatásban és fogyasztásban. A több GB tehát nem modelljóváhagyás és nem benchmark.

A kontextust és az egyidejű kéréseket is tesztelni kell

A KV-gyorsítótár a feldolgozáshoz szükséges köztes értékeket őrzi. Igénye függ többek között a modell architektúrájától, a kontextus hosszától és a tárolási formátumtól. Hosszú dokumentumok, beszélgetési előzmények és tudáskivonatok további helyet igényelnek. A modell hirdetett maximális kontextusablaka ezért nem költségmentesen használható memória.

Egy sikeres egyedi teszt keveset mond az egyidejű kérésekről. Az Ollama párhuzamos kontextusfeldolgozása növeli a memóriaigényt; rögzítse a pontos beállítást. Rövid kérés mellett hosszabb valós kontextust és várható egyidejűséget is teszteljen. A minőséget, az első tokenig eltelt időt, a teljes időt, a hibákat és a csúcsmemóriát együtt értékelje.

Kisebb vagy kvantált KV-formátum a futtatókörnyezettől és backendtől függően memóriát takaríthat meg. A pontosságot és a viselkedést is befolyásolhatja. A modellsúlyok és a KV kvantálása külön beállítás; mindkettőt ugyanazokkal a szakmai tesztesetekkel hasonlítsa össze.

Tehermentesítés CPU-val és RAM-mal: lehetséges, eltérő működéssel

A llama.cpp és hasonló környezetek támogatják a CPU és GPU közötti megosztást. Így használhatóvá válhat a grafikus memóriánál nagyobb teljes memóriaigényű modell. Ehhez elegendő RAM és megfelelő adatút kell. Az SSD nem alakítja a hiányzó VRAM-ot ugyanolyan gyors grafikus memóriává.

A kiszervezés megváltoztatja a végrehajtási utat és gyakran a válaszidőt; hatása mérés nélkül nem számszerűsíthető felelősen. Az Ollamában az ollama pssegít ellenőrizni az aktuális CPU/GPU-megosztást. Több GPU sem jelent automatikusan egyetlen nagy eszközt: a támogatás, az elosztás és a kártyák közötti átvitel az architektúra ellenőrzésének része.

Vásárlás előtt: konkrét konfiguráció jóváhagyása

  1. A modell meghatározása: pontos verzió, kvantálás, licenc és elvárt válaszminőség.
  2. A terhelés meghatározása: kontextuskeret, bemeneti/kimeneti hossz és egyidejű kérések.
  3. A környezet ellenőrzése: konkrét GPU, backend, illesztőprogramok, rendszer, RAM, hűtés és tápegység.
  4. Mérés: szabad kapacitás, csúcsfogyasztás, válaszidők és szakmai hibák reprezentatív pilotban.
  5. Döntés: meglévő hardver újrahasználata, célzott bővítése vagy helyi, külső, illetve hibrid szolgáltatás választása.

A DAXS a modell- és hardverválasztást a meglévő IT-hez és az egyeztetett üzemeltetéshez igazítja. A keretet a Helyi LLM-ek és infrastruktúraszakoldal írja le. A helyi AI terhelési pilotjáról szóló cikk valós feladatokkal mutatja be az értékelést; a Költségek és modellválasztás a gazdasági szempontokat vizsgálja.

Modell- és hardverválasztás megbeszélése

Források: Ollama: kontextushossz (külső hivatkozás) · Ollama: memória, egyidejűség és offloading (külső hivatkozás) · llama.cpp: végrehajtási utak (külső hivatkozás) · Hugging Face: GGUF (külső hivatkozás) · hivatalos Qwen-fájllisták 7B (külső hivatkozás), 14B (külső hivatkozás), 32B (külső hivatkozás). Tájékoztatás inferenciához; nem tanítási teszt, hardverajánlat vagy állított ügyfélmérés.