Per decidere se GLM o Qwen possono svolgere un lavoro in locale, non basta far generare una pagina HTML e vedere che si apre. Servono due verifiche distinte: il modello deve funzionare sull’hardware disponibile e il risultato deve superare prove coerenti con il compito.
Nel laboratorio Romiltec studio modelli e runtime per integrarli nel lavoro su software e prodotti. La lezione più utile è che una demo, un benchmark di velocità e un test di qualità rispondono a domande diverse. Confonderli porta a comprare hardware o spostare workflow troppo presto.
Il nome preciso del modello fa parte della configurazione
“Qwen3” è una famiglia, non un file. La scheda Qwen3-30B-A3B dichiara 30,5 miliardi di parametri totali e 3,3 miliardi attivati. La variante Instruct-2507 è un rilascio distinto: non trasferirei automaticamente tra i due istruzioni di prompting o risultati.
Anche GLM-4.7-Flash è presentato dal produttore come modello MoE della classe 30B-A3B. “Flash” non significa che qualunque file scaricato sia già una quantizzazione adatta alla propria GPU. Occorre controllare formato, precisione e supporto del runtime.
Per ogni prova registro repository, revisione dei pesi, quantizzazione, runtime, configurazione del contesto e template della conversazione. Senza questi dati, due test con lo stesso nome commerciale possono descrivere sistemi differenti.
Una misura reale: Qwen3 su CPU, settembre 2026
Nel benchmark interno del 5 settembre 2026 abbiamo eseguito Qwen3-30B-A3B-Instruct-2507 in Q4_K_M su un Intel Xeon Gold 5412U, con 24 core fisici. Il runtime era llama.cpp, build dal commit 4d91760, senza layer sulla GPU. Il file quantizzato indicato nel registro pesa 17,3 GB.
| Thread | Elaborazione prompt, pp512 | Generazione, tg128 |
|---|---|---|
| 24 | 114,0 token/s | 31,4 token/s |
| 48 | 137,4 token/s | 8,8 token/s |
Il comando di riferimento, eseguito con il file del modello e il numero di thread della riga, era:
llama-bench -m MODELLO.gguf -t 24 -p 512 -n 128 -pg 512,128 -ngl 0 -r 3La documentazione di llama-bench distingue prompt processing e generazione. In questa prova, più thread hanno migliorato il primo e peggiorato la seconda. Il dato non dimostra che 24 thread siano sempre ottimali: dimostra perché vale la pena misurare separatamente le fasi.
Sono misure sintetiche su prompt breve, riportate dal nostro registro tecnico; non una valutazione della qualità del codice e non una previsione della velocità su un portatile. Contraddicono però l’idea che un modello di questa taglia su CPU debba essere sempre inutilizzabile.
Il test di qualità deve avere un risultato indipendente
Per un refactor, fisserei prima il comportamento da preservare: endpoint, autorizzazioni, formati di risposta, errori e compatibilità. Farei eseguire la stessa richiesta su una copia del progetto e confronterei il risultato con test preesistenti e casi aggiunti a partire dai requisiti.
Per una classificazione editoriale servono esempi etichettati, criteri di annotazione e risultati per classe. Una media può nascondere che il modello riconosce bene la categoria più frequente e sbaglia proprio quelle meno rappresentate. Il campione usato per adattare il prompt deve restare distinto da quello usato per stimare il risultato finale.
Tool calling: conta il ciclo completo
Un modello che emette JSON non ha ancora dimostrato di usare correttamente gli strumenti. Deve scegliere lo strumento adatto, rispettarne lo schema, interpretare l’esito e fermarsi quando il compito è concluso. Anche il runtime deve trasformare la risposta nel formato che il client si aspetta.
Proverei almeno un comando riuscito, un errore, un risultato vuoto e una sequenza con dipendenze: il secondo passo deve attendere il dato prodotto dal primo. Misurerei tentativi, modifiche necessarie e interventi umani, oltre ai token al secondo.
Locale significa anche gestire il servizio
I pesi scaricabili non azzerano consumi, manutenzione o condizioni di licenza. Inoltre un agente collegato a un modello locale può usare strumenti che chiamano servizi esterni. Per stabilire dove passano i dati bisogna osservare l’intero workflow.
Prima di adottare un modello definirei il carico accettabile e il comportamento quando la macchina è occupata: coda, rifiuto esplicito o fallback autorizzato. Per dimensionare il nodo, la guida su VRAM, RAM e offload sviluppa il conto della memoria. Per il risultato sul software, resta centrale una review proporzionata al rischio.
Il criterio di scelta è concreto: sul mio compito, con questa configurazione, quante esecuzioni arrivano a un risultato verificato e quanto lavoro richiedono? È una risposta più utile di una posizione generica in classifica.