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:
- 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), quindimkdir Qwen-27B-48k. - All’interno della cartella ci dobbiamo creare un file “Modelfile”, ad esempio:
edit Modelfile_48k. - Il contenuto del file in questione deve essere analogo a questo di esempio:
FROM Qwen3.8-27B
PARAMETER num_ctx 49152La 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 nowCome 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_48kDopodiché, 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.
