Sembrava un mistero. Su un Mac Studio M3 Ultra con 96 GB di memoria unificata, Qwen3.5-122B girava fluido, ma dopo qualche messaggio in sessioni di coding agentico il modello cadeva in un silenzio glaciale: dai 3 ai 5 minuti prima di cominciare a generare una risposta. Il contesto, formalmente “caldo”, nascondeva in realtà tre falle nel serving stack che mandavano in cortocircuito la cache KV.

Lo sviluppatore marzukia ha isolato i bug nel suo fork qMLX – una derivazione di rapid-mlx ottimizzata per Apple Silicon – e li ha corretti, pubblicando il codice e uno script di benchmark che isola le metriche di prefill e decode. Il risultato è un cambio di paradigma per chi usa modelli a contesto lungo su hardware locale: con 53.000 token in cache, solo 33 venivano ricalcolati, riportando l’inference a velocità sub-secondo.

Un intreccio tecnico poco visibile

Il primo colpevole era una questione di identità: l’ID univoco del messaggio nel prompt di sistema rompeva la corrispondenza esatta a livello di byte della cache KV. L’effetto era un ricalcolo completo del prompt a ogni turno, anche quando il contesto non era cambiato. Il secondo bug riguardava le risposte in streaming interrotte: la generazione parziale non veniva salvata, causando una divergenza nella cronologia che invalidava i successivi lookup. Infine, un checkpoint writer in background produceva istantanee inutilizzabili, che scalzavano quelle valide e attivavano un’evizione aggressiva della cache.

Sistemate queste tre condizioni, la differenza è prorompente. Il prefill – l’operazione che trasforma la conversazione in uno stato computabile – è collassato da diversi minuti a poche decine di millisecondi. Il modello ha cominciato a rispondere come ci si aspetta da un LLM da 122 miliardi di parametri su un hardware che, pur non avendo VRAM dedicata, sfrutta la banda elevata della memoria unificata.

Forchettare è un atto di realismo

C’è un dettaglio dirimente in questa storia: le ottimizzazioni introdotte sono specifiche per l’architettura hybrid attention di Qwen, tanto che l’autore ha deciso di non proporre un merge nel progetto principale. Una scelta che segnala qualcosa di più profondo delle solite divergenze tra fork. Su hardware locale, dove ogni watt e ogni byte di cache contano, le strategie di serving per modelli moderni sono sempre meno generalizzabili. L’attenzione ibrida, che combina meccanismi a finestra scorrevole e attenzione globale, richiede logiche di caching che mal si adattano a stack pensati per architetture più uniformi.

Questo significa che per costruire un assistente di coding realmente utilizzabile su una macchina on-premise non serve più solo un modello potente e un hardware adeguato: servono fork specializzati, mantenuti da comunità ristrette o da singoli, capaci di spremere ogni particolarità architetturale. Non è una stranezza: è la direzione che il deployment locale sta prendendo man mano che i modelli diventano più complessi e divergono tra loro. Il caso qMLX mostra che la linea tra “funziona” e “è inutilizzabile” può essere tracciata da tre bug di caching incrementali, invisibili senza un’analisi forense.

Chi oggi valuta una workstation come il Mac Studio per carichi di lavoro agentici non deve solo guardare le specifiche di targa – 96 GB unificati sembrano tanti, ma il diavolo abita nei dettagli del serving. La strada dell’inference on-premise a contesto lungo è lastricata di insidie simili. E se il fix non arriva da un vendor ma da uno sviluppatore indipendente che decide di forchettare, significa che il controllo del proprio stack è l’unica vera leva di affidabilità.