Ho visto un modello da 27GB andare in crash durante l’inferenza mentre un’alternativa da 6,6GB continuava a girare come se niente fosse.
Quell’istante—seduto davanti alla mia RTX 5070 Ti, fissando un errore di segfault in WSL2—mi ha fatto capire una cosa su cui nutrisco dubbi da vent’anni che seguo questa industria: il numero di parametri è solo fumo negli occhi. È quello che vedi nei comunicati stampa e nelle slide per gli investitori. È quello che rassicura i venture capitalist. Ma raramente è quello che rende un modello davvero utile sulla tua macchina.
Ho messo qwen3.5:9B sotto 18 test contro cinque competitor, in particolare per il lavoro con agenti locali—il genere di cose reali dove chiami tool, parsi dati strutturati e ottieni risultati così velocemente che non ti serve una pausa caffè. Il vincitore non era nemmeno una partita serrata.
Il Benchmark che Nessuno Fa: Structured Tool Calling
Qui è quello che separa i buoni dai cattivi negli agenti locali, e gli ingegneri di Alibaba l’hanno capito meglio della maggior parte.
Quando chiedi a un modello linguistico di usare un tool—per esempio, listare una directory o interrogare un database—lo seppellisce da qualche parte in mezzo a una risposta di prosa farragginosa. Poi devi scrivere logica di parsing, error handling, meccanismi di retry. È un casino. Alcuni modelli se la cavano meglio, ma la maggior parte ti costringe a costruire uno strato di estrazione improvvisato.
“Solo i modelli con supporto nativo a tool_calls e quantizzazione Q4_K_M funzionavano lisci.”
Qwen3.5:9B restituisce un campo tool_calls JSON pulito e autonomo. Basta. Niente parsing. Niente trucchi con regex. Niente riti magici ai dei di Python. Competitor più grandi come Qwen2.5:14B e Qwen2.5-coder:14B seppellivano la stessa informazione nel testo puro, costringendoti a construire strati di estrazione e debuggarli alle 23:00.
Ho testato questo scenario preciso su cinque modelli. Qwen3.5:9B ha risposto giusto il 100% delle volte. Gemma 4 E4B (un modello da 9,6GB) mi ha richiesto 30 minuti di tuning su Ollama per passare da 3 a 14 chiamate di tool corrette. Anche così, staccava dalla consistenza del modello più piccolo. Le varianti da 27B? Problemi di stabilità che rendevano impossible il deployment in produzione.
Dove la VRAM Diventa il Vero Collo di Bottiglia (Spoiler: Sempre Lì)
Diamolo: la memoria della GPU consumer è il vincolo reale nell’AI locale, non la sofisticazione del modello.
Qwen3.5:9B consumava 6,6GB di VRAM sulla mia RTX 5070 Ti, lasciando spazio abbondante per il KV cache e context window più lunghe. Un modello da 27B quantizzato Q4_K_M? 16GB—maxava la scheda. E poi sono arrivati i crash. Il bug di segfault di TurboQuant in WSL2 ha peggiorato le cose, trasformando quella che dovrebbe essere un’inferenza banale in un incubo di debugging.
Ho tenuto appunti precisi. Ecco quello che è successo davvero:
Gli apostoli dei modelli più grandi ripetono sempre “aggiungi più VRAM”. Certo, se hai 8.000 dollari da buttar via in un A100. Ma se stai usando agenti locali su una GPU consumer—che, ammettiamolo, siamo noi—la VRAM è il limite duro. Non la capacità teorica. Non i punteggi dei benchmark. La memoria vera, fisica.
Qwen3.5:9B rispetta questa realtà fisica.
Il Trucco di Efficienza dei Token che Nessuno Nomina
Qui è dove le cose diventano strane, e qui arrivano le vere vittorie.
Qwen3.5:9B supporta un parametro think=false che disabilita i token di ragionamento interno. Stesso task. Consumo di token diverso. Parliamo di 1024+ token che diventano 131. Una riduzione di 8-10x. Non è un arrotondamento—è un cambio di fase nel comportamento del modello.
Perché import
