Categoria: AI

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!

Pi Coding Agent non funziona su Windows 11

Provando ad eseguire “Pi Coding Agent” su Windows 11 mi usciva questo errore:

pi exiting due to uncaughtException:
TypeError: zlib.createZstdDecompress is not a function
    at Object.onResponseStart (file:///C:/Users/andrea.orlando/AppData/Roaming/npm/node_modules/@earendil-works/pi-coding-agent/dist/bundle/chunks/chunk-OMWWHBTG.js:268:70392)
    at Request.onResponseStart (file:///C:/Users/andrea.orlando/AppData/Roaming/npm/node_modules/@earendil-works/pi-coding-agent/dist/bundle/chunks/chunk-OMWWHBTG.js:141:145989)
    at Parser2.onHeadersComplete (file:///C:/Users/andrea.orlando/AppData/Roaming/npm/node_modules/@earendil-works/pi-coding-agent/dist/bundle/chunks/chunk-OMWWHBTG.js:152:15221)
    at wasm_on_headers_complete (file:///C:/Users/andrea.orlando/AppData/Roaming/npm/node_modules/@earendil-works/pi-coding-agent/dist/bundle/chunks/chunk-OMWWHBTG.js:152:6943)
    at wasm://wasm/00034eea:wasm-function[10]:0x571
    at wasm://wasm/00034eea:wasm-function[20]:0x845f
    at Parser2.execute (file:///C:/Users/andrea.orlando/AppData/Roaming/npm/node_modules/@earendil-works/pi-coding-agent/dist/bundle/chunks/chunk-OMWWHBTG.js:152:9713)
    at Parser2.readMore (file:///C:/Users/andrea.orlando/AppData/Roaming/npm/node_modules/@earendil-works/pi-coding-agent/dist/bundle/chunks/chunk-OMWWHBTG.js:152:9059)
    at TLSSocket.onHttpSocketReadable (file:///C:/Users/andrea.orlando/AppData/Roaming/npm/node_modules/@earendil-works/pi-coding-agent/dist/bundle/chunks/chunk-OMWWHBTG.js:152:19492)
    at TLSSocket.emit (node:events:518:28)
Error: exit status 1

Ho provato a sistemare con questo comando:

npm install -g @earendil-works/pi-coding-agent@latest

Che auspicabilmente doveva aggiornare l’installazione di Pi Coding Agent, ma per tutta risposta ricevevo:

npm warn EBADENGINE Unsupported engine {
npm warn EBADENGINE   package: '@earendil-works/pi-coding-agent@0.84.4',
npm warn EBADENGINE   required: { node: '>=22.19.0' },
npm warn EBADENGINE   current: { node: 'v22.14.0', npm: '11.12.1' }
npm warn EBADENGINE }
npm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead

changed 136 packages in 11s

15 packages are looking for funding
  run `npm fund` for details

Ho quindi cercato di capire come NodeJs fosse stato installato con:

Get-Command node | Select-Object -ExpandProperty Source

E la risposta è stata: C:\Program Files\nodejs\node.exe

Da qui ho tentato l’aggiornamento tramite winget upgrade OpenJS.NodeJS ma, ancora, ottenevo un altro errore:

Prima di usare l'origine `msstore`, è necessario visualizzare i contratti seguenti.
Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction
L'origine richiede che l'area geografica di 2 lettere del computer corrente venga inviata al servizio back-end per funzionare correttamente ,ad esempio "STATI Uniti".

Accetti tutte le condizioni dei contratti di origine?
[Y] Sì  [N] No:
[Y] Sì  [N] No: y
Non è stato trovato alcun pacchetto installato corrispondente ai criteri di input.

Per sistemare anche questo ho usato: winget upgrade --query Node.js e finalmente è partito “pi” usando il comando ollama launch pi.

Pi Coding Agent su Windows 11

Tentando di eseguirlo su Windows 11 in una PowerShell mi è uscito questo messaggio di errore:

pi : Impossibile caricare il file C:\Users\Utente\AppData\Roaming\npm\pi.ps1. L'esecuzione di script è disabilitata nel sistema in uso. Per ulteriori informazioni, vedere about_Execution_Policies
all'indirizzo https://go.microsoft.com/fwlink/?LinkID=135170.
In riga:1 car:1
+ pi
+ ~~
    + CategoryInfo          : Errore di protezione: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

Per risolvere il problema ho usato questo comando:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Dopodiché, usando il comando pi è partito come previsto.