Un simulatore di kebab nello stile Döner che ruota verticalmente davanti a un bruciatore a gas. Non è il solito benchmark, ma la provocazione lanciata da un utente su Reddit ha avuto il merito di far discutere di una domanda che interessa da vicino chi lavora con LLM in locale: quanto valgono realmente i salti di versione tra GLM 5.1 e 5.2 o tra Qwen 3.5 e 3.6?

La risposta, almeno nella community, ha preso una piega singolare. La menzione del Döner avrebbe “attivato i pesi tedeschi” di GLM 5.2—Spiess per lo spiedo, Brenner per il bruciatore—dimostrando forse un miglioramento nel riconoscimento di contesti linguistici specifici. Un dettaglio curioso, ma che nasconde un problema più serio: come valutare l’effettivo progresso di un modello quando i benchmark standard non raccontano tutto.

Il test: tra OpenRouter e lama.cpp

La prova ha messo a confronto diversi modelli: GLM 5.2, Qwen 3.6 da 35 miliardi di parametri, Qwen 3.5 e Gemma 4. Sul fronte dell’inference, due percorsi distinti: alcuni modelli sono stati interrogati via API tramite OpenRouter, altri eseguiti in locale con llama.cpp, sfruttando le quantizzazioni Unsloth Q8 K XL.

Questa scelta non è banale. La quantization Q8 riduce l’occupazione di memoria a circa un byte per parametro, portando un modello da 35B a richiedere intorno ai 35 GB di VRAM (o RAM di sistema, a seconda del backend). Un carico gestibile da workstation equipaggiate con GPU di fascia alta o da server con sufficiente memoria CPU. llama.cpp, in particolare, consente di spostare parte del calcolo su CPU, abbassando la soglia di ingresso per il deployment on-premise.

Quantization e sovranità del dato

Per chi valuta opzioni self-hosted, la prospettiva è chiara: le quantizzazioni aggressive permettono di eseguire modelli di grandi dimensioni senza dipendere dal cloud, mantenendo il pieno controllo sui dati. Un requisito sempre più sentito in ambiti regolamentati o dove la privacy è critica. Il test del kebab, pur nella sua leggerezza, tocca un tasto reale: la capacità del modello di gestire contesti culturali o linguistici specifici, cosa che può fare la differenza in scenari aziendali.

Tuttavia, la quantization introduce un compromesso. Il formato Q8 K XL cerca di bilanciare perdita di precisione e velocità, ma resta il fatto che ogni riduzione dalla precisione originale (FP16 o FP32) può influenzare le prestazioni su compiti complessi. Ecco perché testarne l’impatto con prompt creativi—persino uno spiedo rotante—non è solo un gioco: diventa un modo empirico per capire se il modello quantizzato mantiene le sfumature che servono.

Cosa dice il passaggio da 3.5 a 3.6 (e da 5.1 a 5.2)

Gli incrementi di versione dei modelli sono spesso descritti con numeri che sembrano minimi, ma possono nascondere ottimizzazioni significative nell’architettura, nel dataset di training o nella gestione di lingue diverse dall’inglese. Il caso di GLM 5.2 suggerisce che alcuni modelli potrebbero avere “pesi” specializzati, attivati da contesti particolari. Per chi sceglie quale versione mettere in produzione su un’infrastruttura locale, questi dettagli contano: non si tratta solo di un numero in più, ma di valutare se l’aggiornamento risolve problemi reali nei propri casi d’uso.

In assenza di benchmark condivisi per il test del Döner, i dati completi pubblicati dall’utente su Reddit restano l’unico punto di riferimento. L’invito implicito è a fare lo stesso: testare con i propri prompt, valutare la qualità in relazione ai costi computazionali e alle esigenze di latenza.

Oltre il divertissement: l’analisi che serve

Su AI-RADAR, chi affronta decisioni di deployment on-premise trova framework per pesare TCO, throughput e requisiti di quantization senza scorciatoie. Il kebab rotante ci ricorda che, a volte, i test più strambi svelano limiti e pregi che i report ufficiali non mostrano. E per chi lavora con stack locali, è proprio questo tipo di verifica empirica che fa la differenza tra un proof of concept e una scelta di produzione sostenibile.