Mese: Settembre 2026

Ollama: Ottimizzare la Finestra di Contesto (Context Window)

Lavorando con risorse ristrette (neanche tanto, ho 20 GB di VRAM sulla scheda, ma comunque poche per modelli oltre una certa dimensione), devo limitare la Finestra di Contesto, ovvero, quella zona di memoria usata dall’LLM per immagazzinare i dati che gli diamo in pasto (prompt, file, …).

Più è grande questa finestra, più il modello ha capacità di immagazzinare dati e svolgere lavori sempre più complessi, tuttavia, questo aumenta linearmente la richiesta di memoria al sistema, superata la quale, viene utilizzato un meccanismo (da parte di Ollama, in questo caso, ma immagino che anche gli altri software analoghi adottino la medesima tecnica) di sdoppiamento tra VRAM e RAM; in altri termini, i layer che compongono il modello, vengono suddivisi tra VRAM e RAM e il risultato è che si riesce a far girare comunque un modello che non riuscirebbe a risiedere nella sola VRAM, salvo riducendo la finestra di contesto a valori che poi lo rendono pressoché inutile (ovviamente parliamo di modelli per hardware terrestre).

Tuttavia, questa modalità, ha una penalizzazione: il drastico crollo delle prestazioni.

Quindi?

Sei fottuto.

Spera che la riduzione della finestra non debba scendere sotto i 64k, altrimenti, forse è meglio evitare. Per come la penso io (e dai test che ho fatto), il minimo sindacale è 32k, non meno, sotto: lascia perdere.

Ma come si fa?

Ecco i passaggi:

  1. Creati una cartella (ad es.: Qwen-27B-48k , per un modello che deve avere la finestra a 48k, che però è solo un nome mnemonico, non stabilisce la dimensione voluta, ci fa solo ricordare per cosa è stata creata la cartella); dimenticavo, il tutto va fatto da terminale, quindi Alt+x i (su Windows), quindi mkdir Qwen-27B-48k.
  2. All’interno della cartella ci dobbiamo creare un file “Modelfile”, ad esempio: edit Modelfile_48k.
  3. Il contenuto del file in questione deve essere analogo a questo di esempio:
FROM Qwen3.8-27B
PARAMETER num_ctx 49152

La misura del contesto va espressa in byte, quindi, dobbiamo ipotizzare la misura che desideriamo; solitamente i tagli sono 4k, 8k, 16k, 32k, 64k, 128k, 256k ma nulla vieta di fare tagli intermedi, importante è che siano interi e soprattutto, moltiplicare il taglio scelto per 1024, quindi, se ad esempio scegliamo 48k (un taglio intermedio), abbiamo: 48 * 1024 = 49152.

Potrebbe sorgere spontanea (anzi, dovrebbe) la domanda: ma in che modo ipotizzo la misura di contesto ottimale per il mio hardware?

Il metodo ortodosso non so quale sia, io mi sono arrangiato con un metodo empirico: lancio il modello e con ollama ps vedo come viene suddiviso e in base a questa informazione riduto per ottenere l’occupazione della VRAM ottimale.

Ad esempio ho provato un modello quantizzato a 4 bit e de-censurato di Qwen3.8-27b (sì, lo so, è un casino, tra finestre di contesto, layer, quantizzazione, ecc., un sacco di roba molto nebulosa, ma così è …) e questo è il risultato sul mio hardware (che ha 20 GB di VRAM e 64 GB di RAM):

ollama ps
NAME                                        ID              SIZE     PROCESSOR          CONTEXT    UNTIL
orcarouter/Qwen3.8-27B-Uncensored:iq4_xs    84e6355d6764    34 GB    48%/52% CPU/GPU    262144     4 minutes from now

Come si può notare, ben il 52% è collocato in RAM; questo significa che richiede oltre 40 GB di VRAM per girare (e già è quantizzato scarso).

Invece, con contesto a 48k, questo il risultato:

NAME                   ID              SIZE     PROCESSOR    CONTEXT    UNTIL
Qwen-27B-48k:latest    b5fff7ca760e    18 GB    100% GPU     49152      4 minutes from now

Come si può notare, risiede completamente nella VRAM!
Questo implica prestazioni e stabilità completamente diverse dalla situazione precedente.

5. L’ultimo passaggio consiste nel creare il modello, ad esempio:

ollama create Qwen-27B-48k -f Modelfile_48k

Dopodiché, vi basta un semplice ollama run Qwen-27B-48k per lanciarlo e ollama ps (in un altro terminale) per vedere il consumo di risorse.

Da lì potete aumentare o calare con il contesto (importante: ricordarsi di modificare il Modelfile, tipicamente mi scordo di farlo!) per ottimizzare alle vostre esigenze.

Linux: cambiare cartella corrente navigando con le frecce della tastiera

Per come è intrinsecamente sviluppato il kernel di Linux, non risulta possibile creare un’app che:
1. L’utente lancia.
2. Naviga nella cartella desiderata.
3. Esce e si trova nella cartella desiderata.

Per farlo bisogna adottare un escamotage.

Come prima cosa, consiglio di installare “nnn” (o n3), tramite sudo apt install nnn .

Dopodichè, bisogna creare o aggiungere al file ~/.bash_aliases il seguente codice:

n() {
    # Blocca un file temporaneo per memorizzare l'ultima directory
    export NNN_TMPFILE="${XDG_CONFIG_HOME:-$HOME/.config}/nnn/.lastd"

    # Avvia nnn
    nnn "$@"

    # Legge l'ultima directory ed esegue il cd se il file esiste
    if [ -f "$NNN_TMPFILE" ]; then
        . "$NNN_TMPFILE"
        rm -f "$NNN_TMPFILE"
    fi
}

Per farlo è sufficiente un nano ~/.bash_aliases è incollare il codice sopra, quindi, riavviare il terminale.

Dopodiché, con n parte il programma, con le frecce ci si sposta e con q si esce nella cartella scelta!

Il programma nnn è un file manager minimale e atipico, con ? si ottiene la guida agli altri comandi disponibili, a voi la scelta se usarli o meno.

Ollama: Prova empirica con Finestre di Contesto (ContextWindow) diverse

Ho a disposizione una workstation HP Z2, con processore Inter(R) Core(TM) i9-14900K, 64 GB di RAM, Scheda video NVIDIA RTX A4500 20 GB.

Su questa macchina ci ho installato Ollama e alcuni modelli.

Tramite il setup di ollama, ho provato a fare inferenza modificando la “ContextWindow” (Finestra di Contesto), uno dei parametri fondamentali affinché i modelli riescano fattivamente a realizzare un ragionamento compiuto e prolungato (non la semplice domanda, ma proprio una discussione, un lavoro, ecc.).

Più è grande la finestra di contesto, più il modello riuscirà ad immagazzinare informazioni ed elaborarle, ragionandoci sopra (se previsto il ragionamento).

Ma è chiaro che, all’aumentare di questa finestra, Ollama deve allocare sempre più risorse (in realtà, come si vedrà poi dalla tabella di comparazione, non sempre) hardware: prima andrà ad occupare la VRAM (la memoria della scheda video), quindi farà uno “split” e userà la RAM di sistema; nel mio caso specifico sono esattamente 20 GB (VRAM) e 64 GB (RAM).

Tuttavia, ho constatato alcuni aspetti fondamentali:

  1. Finché il modello gira totalmente in VRAM, le prestazioni sono ottime, al pari di un servizio online a pagamento (ChatGPT, Claude, Gemini, ecc.).
  2. Appena il contesto non riesce più ad essere allocato in VRAM, Ollama “spezza” e qui le prestazioni crollano, ma non solo perché …
  3. … ho constatato che anche i crash del modello si fanno MOLTO più probabili.

Quindi: scegliere la finestra di contesto in base al modello e al proprio hardware, diventa estremamente dirimente, fa la differenza tra “tirare fuori un lavoro anziché un fallimento”.

Da qui nasce la mia idea di fare una tabella comparativa dove, semplicemente, ho provato a fare inferenza su tre modelli che sto usando (siamo a Settembre 2026) con soddisfazione, ma variando la Finestra di Contesto dal minimo di 4K fino al massimo di 256K (4K, 8K, 16K, 32K, 64K, 128K, 256K).

Ecco il risultato:

NameIDSizeProcessorContext
orcarouter/Qwen3.8-27B-Uncensored:iq4_xs84e6355d676434 GB48%/52% CPU/GPU262144
orcarouter/Qwen3.8-27B-Uncensored:iq4_xs84e6355d676425 GB28%/72% CPU/GPU131072
orcarouter/Qwen3.8-27B-Uncensored:iq4_xs84e6355d676420 GB10%/90% CPU/GPU65536
orcarouter/Qwen3.8-27B-Uncensored:iq4_xs84e6355d676417 GB100% GPU32768
orcarouter/Qwen3.8-27B-Uncensored:iq4_xs84e6355d676416 GB100% GPU16384
orcarouter/Qwen3.8-27B-Uncensored:iq4_xs84e6355d676415 GB100% GPU8192
orcarouter/Qwen3.8-27B-Uncensored:iq4_xs84e6355d676415 GB100% GPU4096
gemma4:26b5571076f3d7018 GB32%/68% CPU/GPU262144
gemma4:26b5571076f3d7018 GB17%/83% CPU/GPU131072
gemma4:26b5571076f3d7018 GB10%/90% CPU/GPU65536
gemma4:26b5571076f3d7017 GB100% GPU32768
gemma4:26b5571076f3d7017 GB100% GPU16384
gemma4:26b5571076f3d7017 GB100% GPU8192
gemma4:26b5571076f3d7017 GB100% GPU4096
gpt-oss:20b17052f91a42e12 GB100% GPU131072
gpt-oss:20b17052f91a42e12 GB100% GPU65536
gpt-oss:20b17052f91a42e12 GB100% GPU32768
gpt-oss:20b17052f91a42e12 GB100% GPU16384
gpt-oss:20b17052f91a42e12 GB100% GPU8192
gpt-oss:20b17052f91a42e12 GB100% GPU4096
ornith-1.5:9be5df7dcdd8a214 GB100% GPU262144
ornith-1.5:9be5df7dcdd8a29.9 GB100% GPU131072
ornith-1.5:9be5df7dcdd8a27.8 GB100% GPU65536
ornith-1.5:9be5df7dcdd8a26.7 GB100% GPU32768
ornith-1.5:9be5df7dcdd8a26.1 GB100% GPU16384
ornith-1.5:9be5df7dcdd8a25.8 GB100% GPU8192
ornith-1.5:9be5df7dcdd8a25.6 GB100% GPU4096

Analizzando la tabella, si possono fare alcune considerazioni:

  • Non è il numero di parametri a fare la differenza. Le diverse strutture interne degli LLM fanno una certa differenza, tant’è che “Qwen3.8:27b” è molto più esoso di risorse (da 64K in poi, prima sono analoghi) di un “Gemini4:26b” che ha “solo” 1b di differenza.
  • Esiste un caso emblematico fornito da “gpt-oss:20b”, il quale, ha comunque una finestra massima di 128K, ma consuma comunque la stessa RAM, indipendentemente dal contesto attribuito da Ollama.
  • Infine abbiamo “ornith-1.5:9b” che occupa pochissimo e riesce a stare sempre in VRAM, probabilmente anche su una scheda da 16 GB (la mia ha 20 GB, ma è una misura sfigata, l’ideale credo sarebbe 24 GB, molto più standard e che mi consentirebbe di arrivare tranquillamente a 64K anche con i modelli più grandi).

Ho provato (solo a livello di inferenza, non variando il contesto) in passato molti altri modelli, ma – quantomeno a livello “agentico” – non mi hanno dato grandi soddisfazioni.

Se usati solo come chatbot, effettivamente ce ne sarebbero diversi altri interessanti, penso a “mistral:7b” o il velocissimo “lfm2:24b”.

Se qualcuno vuole consigliarmi altri modelli da provare o ha suggerimenti o commennti, non esiti a scrivermi!