Cele mai bune setări Low-VRAM pentru rularea locală a Llama 3 pe laptopuri de gamă medie

Rularea modelului original Meta Llama 3 8B pe un laptop de gamă medie nu se rezumă atât la găsirea unei setări magice, cât la protejarea unui spațiu de memorie suficient pentru ca modelul să rămână stabil, păstrând în același timp o calitate utilă a ieșirii. Pentru majoritatea laptopurilor cu 4 până la 8 GB de VRAM dedicat, cel mai puternic punct de plecare este o cuantizare GGUF pe 4 biți, o fereastră contextuală de la 2K la 4K, o generație activă pe rând și o descărcare GPU cât mai mare pe câtă poate suporta mașina fără a epuiza VRAM-ul.

Acest articol vizează în mod specific versiunea originală Llama 3 8B lansată în aprilie 2024. Indexul actual al modelului Meta îl distinge în continuare de Llama 3.1, 3.2 și versiunile ulterioare. Modelele originale Llama 3 8B și 70B au fost antrenate cu o lungime de context de 8K, în timp ce Llama 3.1 și membrii familiei ulterioare utilizează limite diferite. Depozitul original Llama 3 GitHub al Meta a fost arhivat în martie 2026 și acum direcționează dezvoltatorii către depozitul consolidat Meta llama-models . Specificațiile originale sunt, de asemenea, documentate în fișa oficială de instrucțiuni a modelului Meta Llama 3 8B .

Cele mai bune setări de bază pentru 4–8 GB VRAM

Dacă doriți o singură linie de bază practică înainte de reglajele fine, începeți cu instrucțiunea Llama 3 8B în Q4_K_M GGUF , setați contextul la 4.096 de jetoane, mențineți cererile paralele la unul, activați sau lăsați Flash Attention pe automat și lăsați runtime-ul să aleagă descărcarea maximă a GPU-ului care lasă în continuare spațiu pentru VRAM. Pe un GPU de 4 GB, reduceți contextul la 2.048 de jetoane și așteptați-vă la o descărcare parțială a CPU-ului.

Acestea sunt puncte de plecare, nu garanții. GPU-urile laptopurilor rezervă adesea o parte din VRAM pentru afișaj, iar răcirea, backend-ul driverelor, memoria RAM a sistemului și configurația exactă a GGUF afectează cantitatea de memorie disponibilă. O configurație care se potrivește pe un GPU de 8 GB poate eșua totuși pe un alt laptop de 8 GB dacă stiva grafică sau sarcina de lucru a desktopului consumă mai multă memorie.

De ce Q4_K_M este de obicei cel mai bun punct de plecare cu VRAM redus

Cuantizarea înseamnă stocarea ponderilor modelului la o precizie mai mică, astfel încât modelul să ocupe mai puțină memorie. Aceasta reduce amprenta ponderilor, dar cuantizarea agresivă poate reduce și calitatea răspunsurilor. Datele de referință actuale ale cuantizatorului llama.cpp pentru Llama-3-8B oferă o comparație direcțională utilă: Q3_K_M este listat la aproximativ 3,74G cu o creștere mai mare a perplexității, Q4_K_M la aproximativ 4,58G cu o creștere mai mică și Q5_K_M la aproximativ 5,33G cu o creștere din nou mai mică. Puteți inspecta aceste valori direct în sursa cuantizatorului llama.cpp .

Perplexitatea nu este același lucru cu calitatea percepută de utilizator, așa că nu tratați aceste numere ca pe un clasament universal pentru fiecare sarcină. Sunt cele mai utile pentru alegerea unei ordini rezonabile de experimentare. Dacă Q4_K_M răspunde bine solicitărilor dvs., trecerea la Q3 doar pentru a face modelul să se încadreze complet în VRAM s-ar putea să nu fie o schimbare care să merite. Descărcarea parțială a GPU-ului poate păstra ponderile modelului Q4, mutând în același timp o parte din lucru către memoria RAM a sistemului.

Documentația actuală a LM Studio explică în mod similar că variantele pe 4 biți sunt o implicită rezonabilă atunci când mașina le poate suporta. Consultați ghidul oficial de descărcare a modelului LM Studio . Biblioteca oficială Llama 3 a Ollama listează în prezent pachetul original 8B la aproximativ 4,7 GB cu o fereastră contextuală de 8K, ceea ce este o altă reamintire a faptului că fișierul modelului singur depășește deja un buget VRAM de 4 GB. Consultați pagina oficială a bibliotecii Ollama Llama 3 .

Lungimea contextului: reduceți-o înainte de a sacrifica calitatea modelului

Lungimea contextului reprezintă numărul de token-uri pe care modelul le poate lua în considerare în promptul său activ și în istoricul conversațiilor. Un context mai mare necesită mai multă memorie cache KV. Pentru laptopurile cu VRAM redus, contextul este una dintre cele mai sigure setări de redus, deoarece nu modifică ponderile stocate ale modelului.

Începeți de la 2.048 de jetoane pe 4 GB de memorie VRAM și 4.096 de jetoane pe 6–8 GB de memorie VRAM. Treceți la 8.192 doar după ce confirmați că configurația 4K este stabilă. Placa de model originală Llama 3 își limitează contextul antrenat la 8K, așa că utilizarea unui număr mult mai mare nu transformă Llama 3 original într-un model cu context lung. Dacă aveți nevoie de zeci de mii de jetoane, utilizați un model care a fost efectiv antrenat pentru acel context, cum ar fi o versiune ulterioară a familiei Llama.

Documentația actuală a contextului a Ollama menționează explicit că creșterea contextului crește cerințele de memorie. Începând cu 2026, Ollama setează implicit sistemele cu mai puțin de 24 GiB VRAM la un context de 4K. Acest lucru face ca 4K să fie un plafon general rezonabil de testat înainte de a crește nivelul pe un laptop. Consultați documentația oficială a Ollama privind lungimea contextului .

Descărcarea GPU-ului: maximizați-o, dar lăsați spațiu liber

Descărcarea GPU controlează câte straturi ale modelului sunt stocate și calculate pe GPU în loc de CPU. Mai multe straturi rezidente pe GPU îmbunătățesc de obicei viteza de generare, dar umplerea VRAM până la ultimii câțiva megaocteți este fragilă, deoarece timpul de execuție necesită și memorie cache KV, buffere de calcul și alocări backend.

Cu fișierul actual llama.cpp, linia de comandă acceptă --n-gpu-layers auto, deci selecția automată este o primă încercare bună. Dacă încărcarea eșuează, reduceți mai întâi contextul. Dacă încă eșuează, permiteți mai puține straturi pe GPU, în loc să treceți imediat la o cuantizare mult mai mică. Opțiunile actuale din linia de comandă sunt documentate în referința oficială CLI llama.cpp .

O lansare conservatoare a rachetei Llama 3 8B Q4_K_M arată astfel:

llama-cli -m Meta-Llama-3-8B-Instruct-Q4_K_M.gguf   -c 4096   -b 256   -ub 128   -ngl auto   -fa auto

Numele exact al fișierului GGUF va varia. Pe un GPU de 4 GB, încercați -c 2048 -b 128 -ub 64mai întâi. Scopul nu este de a maximiza fiecare număr; ci de a stabili o bază stabilă, apoi de a adăuga context sau de a descărca treptat.

Dimensiunea lotului: reduceți-l atunci când încărcarea promptă provoacă vârfuri de încărcare

Dimensiunea lotului logic controlează câte jetoane de prompt pot fi procesate împreună. Un lot mai mare poate accelera ingerarea prompturilor, dar poate crește și cererea temporară de memorie. Micro-lotul este blocul fizic utilizat pentru execuție. Fișierul llama.cpp actual le expune ca --batch-sizeși --ubatch-size.

Dacă modelul se încarcă cu succes, dar se blochează când lipiți o solicitare lungă, reduceți numărul de loturi înainte de a modifica cuantizarea. Un loturi logic de 256 cu un micro-loturi de 128 este o soluție intermediară rezonabilă pentru 6 GB de VRAM. Pe 4 GB, 128/64 este mai conservator. Pe 8 GB, 512/256 merită testat. Loturile mai mici pot încetini procesarea solicitărilor, dar de obicei au un efect mai mic asupra fazei constante de generare token cu token.

Flash Attention și KV Cache: utile, dar testați backend-ul

Flash Attention este o cale de atenție optimizată care poate reduce utilizarea memoriei și îmbunătăți viteza pe backend-urile acceptate. Fișierul llama.cpp actual expune un mod automat, iar API-ul de încărcare curent al LM Studio documentează Flash Attention ca o opțiune care poate reduce utilizarea memoriei și îmbunătăți viteza de generare pentru motorul său bazat pe llama.cpp. Consultați documentația API-ului de încărcare a modelelor LM Studio .

Pentru un laptop de gamă medie, lăsați mai întâi Flash Attention setat automat. Dacă întâmpinați o eroare specifică backend-ului sau o instabilitate a driverului vizual, testați aceeași solicitare cu aceasta dezactivată înainte de a modifica mai multe alte setări simultan. Acest lucru facilitează identificarea cauzei reale.

llama.cpp acceptă și tipuri de memorie cache KV cuantizată, cum ar fi Q8_0. Cuantificarea memoriei cache KV poate reduce utilizarea memoriei, dar este un pas avansat de reglare. Modificați mai întâi lungimea contextului și dimensiunea lotului, deoarece aceste ajustări sunt mai ușor de raționat și nu modifică precizia KV. Dacă ulterior aveți nevoie de spațiu suplimentar pentru contextul 8K, testați o memorie cache Q8 KV în funcție de propriul set de prompturi înainte de a o adopta permanent.

Utilizați o solicitare paralelă pe un laptop

Concurența este ușor de trecut cu vederea. Generațiile multiple paralele necesită o capacitate separată a contextului activ și pot împinge o configurație altfel stabilă peste limita de memorie. Pentru un laptop cu un singur utilizator, mențineți paralelismul la unu în timpul ajustării. Întrebările frecvente oficiale ale Ollama menționează că memoria necesară se scalează în funcție de solicitările paralele și dimensiunea contextului și ollama psarată dacă un model este pe GPU, CPU sau împărțit în ambele. Consultați Întrebările frecvente oficiale ale Ollama .

Cum să evaluezi dacă setările sunt într-adevăr bune

O configurație este utilă doar dacă oferă răspunsuri acceptabile în mod constant, nu doar dacă modelul se încarcă. Folosește același set mic de evaluare de fiecare dată când modifici o setare. Cinci până la zece solicitări sunt suficiente pentru un test practic pe laptop: o explicație factuală, o sarcină de rezumat, o sarcină de extragere structurată, o sarcină de codare și o conversație cu mai multe rânduri care se apropie de lungimea contextului tău normal.

• Stabilitatea memoriei: modelul ar trebui să se încarce în mod repetat fără o eroare de memorie insuficientă, iar desktopul ar trebui să rămână receptiv în timpul solicitărilor lungi.
• Viteză de generare: se măsoară numărul de token-uri pe secundă după procesarea prompturilor. Se compară același prompt, nu conversații diferite.
• Viteză de procesare promptă: dacă intrările lungi necesită prea mult timp pentru a fi asimilate, încercați să măriți dimensiunea lotului numai dacă există spațiu liber pentru VRAM.
• Urmărirea instrucțiunilor: verificați dacă modelul respectă în continuare formatele solicitate, constrângerile și instrucțiunile în mai mulți pași după modificarea cuantizării.
• Comportament în context lung: plasați un fapt aproape de începutul unui prompt lung și solicitați-l aproape de sfârșit. Dacă modelul eșuează în ciuda contextului disponibil, problema poate fi calitatea modelului sau promptarea, mai degrabă decât memoria.

Pentru comparații repetabile, mențineți constante setările de temperatură și eșantionare. Temperatura are o relevanță redusă pentru reglarea VRAM, dar modificarea simultană a acesteia poate face ca ieșirile să arate mai bine sau mai rău din motive care nu au legătură cu setările memoriei.

Când să schimbi abordarea

Dacă modelul nu se încarcă

Reduceți contextul la 2K, închideți aplicațiile care utilizează mult GPU, utilizați Q4_K_M și permiteți descărcarea parțială a GPU-ului. Dacă Q4_K_M lasă în continuare mașina să utilizeze intens schimburi, Q3_K_M ar putea fi justificat. Nu presupuneți că un model de 3,7 GB se va potrivi perfect în 4 GB VRAM; timpul de execuție necesită memorie dincolo de fișierul de ponderare.

Dacă se încarcă, dar solicitările sunt lungi, se blochează.

Reduceți contextul și dimensiunea lotului înainte de a modifica cuantizarea modelului. Solicitările lungi cresc utilizarea memoriei cache KV, în timp ce loturile mari pot crea vârfuri de alocare de scurtă durată.

Dacă este stabil, dar prea lent

Măriți încărcarea GPU până când vă apropiați de VRAM-ul disponibil, dar fără a-l epuiza. Dacă sistemul este deja suprasolicitat de CPU deoarece modelul nu se poate potrivi, o cuantizare mai mică poate rula mai rapid, chiar dacă pierde din calitate. Testați înainte de a decide.

Dacă răspunsurile sunt vizibil mai proaste

Treceți de la Q3_K_M înapoi la Q4_K_M sau de la Q4_K_M la Q5_K_M dacă un GPU de 8 GB are suficient spațiu. De asemenea, confirmați că utilizați varianta Instruct și șablonul de chat corect. Reducerea contextului nu reduce în mod inerent calitatea raționamentului, cu excepția cazului în care promptul necesită de fapt eliminarea istoricului.

LM Studio și echivalentele Ollama

Dacă preferați o interfață grafică (GUI), LM Studio expune direct lungimea contextului și descărcarea GPU și poate estima memoria înainte de încărcare. Interfața sa CLI actuală acceptă și o simulare:

lms load --estimate-only <model-key> --context-length 4096 --gpu auto

Estimatorul ia în considerare lungimea contextului și descărcarea GPU-ului, deci este o modalitate convenabilă de a compara 2K cu 4K înainte de validare. Consultați documentația oficială LMS load .

Pentru Ollama, comanda oficială originală Llama 3 rămâne:

ollama run llama3

Se utilizează ollama pspentru a verifica dacă modelul este complet pe GPU sau împărțit cu memoria CPU. Dacă un context 4K este prea încărcat pe un GPU de 4 GB, reduceți num_ctxla 2.048 pentru sesiunea respectivă. Documentația oficială a lui Ollama descrie atât configurarea contextului, cât și raportarea divizării procesorului.

Profile finale recomandate

Pentru 4 GB VRAM: utilizați instrucțiunea Llama 3 8B Q4_K_M, context 2K, o singură solicitare, batch și micro-batch 128/64, Flash Attention activat automat și descărcare parțială a GPU-ului. Alegeți Q3_K_M numai după ce confirmați că Q4_K_M este prea lent sau instabil cu memoria RAM disponibilă.

Pentru 6 GB VRAM: utilizați Q4_K_M, context 4K, o singură solicitare, setări batch 256/128 sau 256/256 și descărcare automată a GPU-ului. Acest profil oferă de obicei mai mult spațiu de manevră util decât încercarea de a forța Q5_K_M într-o placă grafică aproape plină.

Pentru 8 GB VRAM: începeți cu Q5_K_M la context 4K dacă fidelitatea răspunsului contează cel mai mult. Dacă aveți nevoie de contextul complet de 8K, Q4_K_M ar putea fi echilibrul mai bun, deoarece lasă mai mult spațiu pentru memoria cache KV și bufferele de execuție. Confirmați cu același prompt setat înainte de a decide.

Limitele acestui sfat

Aceste recomandări presupun un laptop cu 4–8 GB de memorie GPU dedicată și suficientă RAM de sistem pentru a absorbi descărcarea parțială. GPU-urile integrate și Apple Silicon utilizează memorie partajată sau unificată, astfel încât o tabelă VRAM dedicată nu se mapează corect la acestea. Versiunile de drivere, backend-urile CUDA/Vulkan/ROCM, limitele de putere ale laptopului și răcirea pot, de asemenea, modifica substanțial performanța.

Modelul original Llama 3, modelul 70B, nu reprezintă o țintă realistă cu un spațiu VRAM redus pentru această clasă de laptopuri dacă scopul este viteza interactivă; pachetul actual al lui Ollama este de aproximativ 40 GB înainte de costurile de execuție. Pentru sistemele de gamă medie, modelul 8B este punctul de plecare potrivit.

Prin urmare, cea mai fiabilă strategie de ajustare este simplă: păstrarea unui model Q4_K_M sau mai bun atunci când este posibil, reducerea contextului înainte de reducerea calității ponderării, menținerea concurenței la unu și creșterea încărcării GPU doar cât timp memoria rămâne stabilă. O setare este „cea mai bună” atunci când supraviețuiește celei mai lungi solicitări reale și produce în continuare răspunsuri pe care le-ați folosi efectiv.

Referințe oficiale

• Carte de model Meta Llama 3
• Documentația de cuantizare llama.cpp
• Documentația CLI llama.cpp
• Încărcarea modelului LM Studio și estimarea memoriei
• Documentația lungimii contextului Ollama
• Intrarea la bibliotecă Ollama Llama 3