Best Low-VRAM Settings for Running Llama 3 Locally on Mid-Range Laptops

Running the original Meta Llama 3 8B model on a mid-range laptop is less about finding one magic setting and more about protecting enough memory headroom that the model stays stable while preserving useful output quality. For most laptops with 4 to 8 GB of dedicated VRAM, the strongest starting point is a 4-bit GGUF quantization, a 2K to 4K context window, one active generation at a time, and as much GPU offload as the machine can hold without exhausting VRAM.

This article specifically targets the original Llama 3 8B released in April 2024. Meta's current model index still distinguishes it from Llama 3.1, 3.2, and later releases. The original Llama 3 8B and 70B models were trained with an 8K context length, while Llama 3.1 and later members of the family use different limits. Meta's original Llama 3 GitHub repository was archived in March 2026 and now directs developers to the consolidated Meta llama-models repository. The original specifications are also documented in the official Meta Llama 3 8B Instruct model card.

The best baseline settings for 4–8 GB VRAM

If you want a single practical baseline before fine-tuning, start with Llama 3 8B Instruct in Q4_K_M GGUF, set the context to 4,096 tokens, keep parallel requests at one, enable or leave Flash Attention on automatic, and let your runtime choose the maximum GPU offload that still leaves VRAM headroom. On a 4 GB GPU, reduce context to 2,048 tokens and expect partial CPU offload.

These are starting points, not guarantees. Laptop GPUs often reserve some VRAM for the display, and cooling, driver backend, system RAM, and the exact GGUF build all affect how much memory is actually available. A configuration that fits on one 8 GB GPU can still fail on another 8 GB laptop if the graphics stack or desktop workload consumes more memory.

Why Q4_K_M is usually the best low-VRAM starting point

Quantization means storing model weights at lower precision so the model occupies less memory. It reduces the weight footprint, but aggressive quantization can also reduce answer quality. Current llama.cpp quantizer reference data for Llama-3-8B gives a useful directional comparison: Q3_K_M is listed at about 3.74G with a larger perplexity increase, Q4_K_M at about 4.58G with a smaller increase, and Q5_K_M at about 5.33G with a smaller increase again. You can inspect those values directly in the llama.cpp quantizer source.

Perplexity is not the same thing as user-perceived quality, so do not treat those numbers as a universal ranking for every task. They are most useful for choosing a sensible order of experimentation. If Q4_K_M answers your prompts well, dropping to Q3 solely to make the model fit completely in VRAM may not be a worthwhile trade. Partial GPU offload can preserve the Q4 model's weights while moving some work to system RAM.

LM Studio's current documentation similarly explains that 4-bit variants are a reasonable default when the machine can support them. See the official LM Studio model download guide. Ollama's official Llama 3 library currently lists the original 8B package at about 4.7 GB with an 8K context window, which is another reminder that the model file alone already exceeds a 4 GB VRAM budget. See the official Ollama Llama 3 library page.

Context length: lower it before sacrificing model quality

The context length is the number of tokens the model can consider in its active prompt and conversation history. Larger context requires more KV-cache memory. For low-VRAM laptops, context is one of the safest settings to reduce because it does not change the stored model weights.

Start at 2,048 tokens on 4 GB VRAM and 4,096 tokens on 6–8 GB VRAM. Only move to 8,192 after confirming the 4K configuration is stable. The original Llama 3 model card caps its trained context at 8K, so using a much larger number does not turn original Llama 3 into a long-context model. If you need tens of thousands of tokens, use a model that was actually trained for that context, such as a later Llama family release.

Ollama's current context documentation explicitly notes that increasing context increases memory requirements. As of 2026, Ollama defaults systems with less than 24 GiB VRAM to a 4K context. That makes 4K a reasonable general-purpose ceiling to test before pushing higher on a laptop. See Ollama's official context-length documentation.

Offload della GPU: massimizzalo, ma lascia un margine di sicurezza

L'offload GPU controlla quanti livelli del modello vengono memorizzati ed elaborati sulla GPU anziché sulla CPU. Un maggior numero di livelli residenti sulla GPU generalmente migliora la velocità di generazione, ma riempire la VRAM fino agli ultimi megabyte è un'operazione delicata perché il runtime necessita anche di cache KV, buffer di calcolo e allocazioni di backend.

Con la versione attuale di llama.cpp, la riga di comando accetta --n-gpu-layers auto, quindi la selezione automatica è un buon primo tentativo. Se il caricamento fallisce, riduci prima il contesto. Se continua a fallire, consenti un numero inferiore di layer sulla GPU invece di passare immediatamente a una quantizzazione molto inferiore. Le opzioni della riga di comando attuali sono documentate nella documentazione ufficiale della CLI di llama.cpp .

Un lancio conservativo del Llama 3 8B Q4_K_M si presenta così:

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

Il nome esatto del file GGUF può variare. Su una GPU da 4 GB, prova -c 2048 -b 128 -ub 64prima. L'obiettivo non è massimizzare ogni valore, ma stabilire una base stabile, per poi aggiungere gradualmente contesto o eseguire l'offload.

Dimensione del batch: riducila quando il caricamento rapido causa picchi

La dimensione logica del batch controlla quanti token di prompt possono essere elaborati insieme. Un batch più grande può velocizzare l'ingestione del prompt, ma può anche aumentare la richiesta di memoria temporanea. Il micro-batch è il blocco fisico utilizzato per l'esecuzione. L'attuale llama.cpp li espone come --batch-sizee --ubatch-size.

Se il modello si carica correttamente ma si blocca quando si incolla un prompt lungo, ridurre la dimensione del batch prima di modificare la quantizzazione. Un batch logico di 256 con un micro-batch di 128 rappresenta un buon compromesso per 6 GB di VRAM. Su 4 GB, 128/64 è più conservativo. Su 8 GB, vale la pena provare 512/256. Batch più piccoli possono rallentare l'elaborazione del prompt, ma di solito hanno un impatto minore sulla fase di generazione costante dei token.

Flash Attention e cache KV: utili, ma testa il tuo backend

Flash Attention è un percorso di attenzione ottimizzato che può ridurre l'utilizzo della memoria e migliorare la velocità sui backend supportati. L'attuale llama.cpp espone una modalità automatica e l'API di caricamento di LM Studio documenta Flash Attention come un'opzione che può ridurre l'utilizzo della memoria e migliorare la velocità di generazione per il suo motore basato su llama.cpp. Consultare la documentazione dell'API di caricamento dei modelli di LM Studio .

Per un laptop di fascia media, inizialmente lascia Flash Attention su automatico. Se riscontri un arresto anomalo specifico del backend o un'instabilità del driver grafico, prova a eseguire la stessa richiesta con Flash Attention disabilitato prima di modificare contemporaneamente diverse altre impostazioni. In questo modo sarà più facile identificare la causa reale.

llama.cpp supporta anche tipi di cache KV quantizzati come Q8_0. La quantizzazione della cache KV può ridurre l'utilizzo della memoria, ma è una fase di ottimizzazione avanzata. Modificate prima la lunghezza del contesto e la dimensione del batch, perché queste regolazioni sono più facili da gestire e non alterano la precisione KV. Se in seguito avete bisogno di un margine di sicurezza maggiore per un contesto da 8K, testate una cache KV Q8 con il vostro set di prompt prima di adottarla in modo permanente.

Utilizzare una richiesta parallela su un laptop

La concorrenza è un aspetto che spesso viene trascurato. Più generazioni parallele richiedono una capacità di contesto attivo separata e possono spingere una configurazione altrimenti stabile oltre il limite di memoria. Per un laptop a singolo utente, è consigliabile mantenere il parallelismo a uno durante l'ottimizzazione. Le FAQ ufficiali di Ollama indicano che la memoria richiesta aumenta con le richieste parallele e la dimensione del contesto, e ollama psmostrano se un modello è eseguito su GPU, CPU o distribuito su entrambe. Consultare le FAQ ufficiali di Ollama .

Come valutare se le impostazioni sono effettivamente buone

Una configurazione è utile solo se fornisce risposte accettabili in modo coerente, non semplicemente se il modello si carica. Utilizza sempre lo stesso piccolo set di valutazione ogni volta che modifichi un'impostazione. Per un test pratico al computer portatile, sono sufficienti da cinque a dieci domande: una spiegazione fattuale, un compito di riassunto, un compito di estrazione strutturata, un compito di codifica e una conversazione a più turni che si avvicini alla lunghezza del tuo contesto normale.

• Stabilità della memoria: il modello dovrebbe caricarsi ripetutamente senza errori di memoria insufficiente e il desktop dovrebbe rimanere reattivo durante i prompt prolungati.
• Velocità di generazione: misurare i token al secondo dopo l'elaborazione del prompt. Confrontare lo stesso prompt, non conversazioni diverse.
• Velocità di elaborazione rapida: se l'elaborazione di input lunghi richiede troppo tempo, provare ad aumentare la dimensione del batch solo se rimane spazio disponibile nella VRAM.
• Istruzioni seguenti: verificare che il modello rispetti ancora i formati, i vincoli e le istruzioni a più fasi richiesti dopo la modifica della quantizzazione.
• Comportamento a lungo termine: posizionare un'informazione all'inizio di una richiesta lunga e richiederla verso la fine. Se il modello fallisce nonostante il contesto disponibile, il problema potrebbe risiedere nella qualità del modello o nella modalità di richiesta, piuttosto che nella memoria.

Per ottenere confronti ripetibili, mantieni costanti la temperatura e le impostazioni di campionamento. La temperatura ha poca rilevanza per l'ottimizzazione della VRAM, ma modificarla contemporaneamente può migliorare o peggiorare l'aspetto dei risultati per ragioni non correlate alle impostazioni della memoria.

Quando cambiare approccio

Se il modello non si carica

Riduci il contesto a 2K, chiudi le applicazioni che utilizzano intensamente la GPU, usa Q4_K_M e consenti l'offload parziale della GPU. Se Q4_K_M continua a causare un utilizzo eccessivo dello swap da parte del sistema, potrebbe essere giustificato usare Q3_K_M. Non dare per scontato che un modello da 3,7 GB si adatti perfettamente a 4 GB di VRAM; il runtime necessita di memoria oltre a quella occupata dal file dei pesi.

Se si carica ma i prompt lunghi si bloccano

Riduci il contesto e la dimensione del batch prima di modificare la quantizzazione del modello. I prompt lunghi aumentano l'utilizzo della cache KV, mentre i batch di grandi dimensioni possono creare picchi di allocazione di breve durata.

Se è stabile ma troppo lento

Aumenta l'offload della GPU fino a raggiungere, senza però esaurire, la VRAM disponibile. Se il sistema è già fortemente limitato dalla CPU perché il modello non può essere caricato, una quantizzazione inferiore potrebbe risultare più veloce, anche a scapito della qualità. Esegui dei test prima di decidere.

Se le risposte sono nettamente peggiori

Passa da Q3_K_M a Q4_K_M, oppure da Q4_K_M a Q5_K_M se una GPU da 8 GB ha margine sufficiente. Verifica inoltre di utilizzare la variante Instruct e il modello di chat corretto. Abbassare il contesto non riduce intrinsecamente la qualità del ragionamento, a meno che il prompt non necessiti effettivamente della cronologia rimossa.

Equivalenti di LM Studio e Ollama

Se preferisci un'interfaccia grafica, LM Studio espone direttamente la lunghezza del contesto e l'offload GPU e può stimare la memoria prima del caricamento. La sua interfaccia a riga di comando attuale supporta anche una simulazione:

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

Lo strumento di stima tiene conto della lunghezza del contesto e dell'offload della GPU, quindi è un modo pratico per confrontare 2K e 4K prima di confermare. Consultare la documentazione ufficiale di lms load .

Per Ollama, il comando ufficiale originale di Llama 3 rimane:

ollama run llama3

Utilizzare questo strumento ollama psper verificare se il modello è interamente sulla GPU o se è suddiviso con la memoria della CPU. Se un contesto 4K è troppo pesante per una GPU da 4 GB, ridurre num_ctxa 2.048 per quella sessione. La documentazione ufficiale di Ollam descrive sia la configurazione del contesto che la segnalazione della suddivisione del processore.

Profili finali consigliati

Per 4 GB di VRAM: utilizzare Llama 3 8B Instruct Q4_K_M, contesto 2K, una richiesta, batch e micro-batch 128/64, Flash Attention su automatico e offload parziale della GPU. Scegliere Q3_K_M solo dopo aver verificato che Q4_K_M sia troppo lento o instabile con la RAM disponibile.

Per 6 GB di VRAM: utilizzare Q4_K_M, contesto 4K, una richiesta, impostazioni batch 256/128 o 256/256 e offload automatico della GPU. Questo profilo solitamente offre un margine di sicurezza maggiore rispetto al tentativo di forzare Q5_K_M su una scheda grafica quasi piena.

Per 8 GB di VRAM: se la fedeltà della risposta è la priorità, inizia con Q5_K_M a 4K di contesto. Se invece hai bisogno dell'intero contesto da 8K, Q4_K_M potrebbe rappresentare un compromesso migliore, in quanto lascia più spazio per la cache KV e i buffer di runtime. Conferma con lo stesso set di prompt prima di decidere.

Limiti di questo consiglio

Queste raccomandazioni si basano su un laptop con 4-8 GB di memoria GPU dedicata e una quantità di RAM di sistema sufficiente a gestire un offload parziale. Le GPU integrate e i processori Apple Silicon utilizzano memoria condivisa o unificata, pertanto una tabella di VRAM dedicata non si adatta perfettamente a questi dispositivi. Anche le versioni dei driver, i backend CUDA/Vulkan/ROCm, i limiti di potenza del laptop e il sistema di raffreddamento possono influenzare significativamente le prestazioni.

Il modello originale Llama 3 a 70 bit non rappresenta una soluzione realistica in termini di VRAM per questa categoria di laptop, se l'obiettivo è la velocità interattiva; l'attuale pacchetto Ollama offre circa 40 GB di VRAM prima dell'overhead di runtime. Per i sistemi di fascia media, il modello a 8 bit è il punto di partenza più appropriato.

La strategia di ottimizzazione più affidabile è quindi semplice: preservare un modello Q4_K_M o migliore quando possibile, ridurre il contesto prima di ridurre la qualità dei pesi, mantenere la concorrenza a uno e aumentare l'offload della GPU solo finché la memoria rimane stabile. Un'impostazione è "ottimale" quando resiste al prompt reale più lungo e produce ancora risposte che si utilizzerebbero effettivamente.

Riferimenti ufficiali

• Scheda modello Meta Llama 3
• Documentazione sulla quantizzazione di llama.cpp
• Documentazione CLI di llama.cpp
• Caricamento del modello LM Studio e stima della memoria
• Documentazione contestuale Ollama
• Voce della biblioteca di Ollama Llama 3