Un lungo thread su r/LocalLLaMA ha acceso il dibattito su cosa serva davvero per fare lavoro agentic su GPU workstation di ultima generazione. L’autore ha messo alla prova diversi modelli su una macchina con due RTX Pro 6000, cercando una sorta di “Sonnet locale” capace di reggere contesti fino a 150mila token senza fermarsi. Il verdetto? Software e modelli sono ancora fuori sincrono, e i risultati premiano le architetture che non dipendono da kernel ottimizzati per i data center.

L’attenzione fa la differenza, non la potenza bruta

Il cuore della questione è come ogni modello gestisce l’attenzione quando la finestra di contesto si allunga. Mimo 2.5 adotta la stessa attenzione ibrida a finestra scorrevole 5:1 già vista in Gemma 3: la maggior parte degli strati guarda solo i token recenti, alcuni continuano a leggere l’intero contesto. Così la velocità non collassa. Step 3.7 Flash usa una variante 3:1 e a 178k token arriva a circa 40 token al secondo.

All’opposto, MiniMax M3 e DeepSeek V4 si appoggiano a kernel CUDA scritti per la Blackwell da datacenter (SM100, classe B200). Su RTX Pro 6000 – una Blackwell “consumer” – quei kernel non sono disponibili. MiniMax M3 ricade silenziosamente su attenzione densa e rallenta fino a diventare inutilizzabile; DeepSeek V4 scarica parte delle operazioni sulla CPU e arranca a 14 t/s.

Il buco software che frena le nuove GPU

La radice del problema non è teorica. Il repository di llama.cpp discute apertamente la difficoltà di spedire una GGUF con flash attention per DeepSeek V4, e il thread su SGLang segnala bug con NVFP4 su SM120. In pratica, chi compra oggi una RTX 5090 o una Pro 6000 per fare inference locale su larga scala si trova con hardware potente ma senza il software per sfruttare appieno i modelli più recenti.

Per chi valuta deployment on-premise, il messaggio è chiaro: non basta confrontare i benchmark ufficiali, bisogna verificare se il modello scelto può funzionare senza accelerazioni proprietarie. Le architetture che usano meccanismi di attenzione standard o già supportati nei runtime consolidati – sliding window, grouped query attention – sono al momento la scelta più pragmatica per tenere alta la velocità su GPU workstation.

Qualità agganciata a Sonnet, ma i tempi cambiano tutto

Un dato sorprendente è la qualità del codice prodotto. Nel benchmark privato dell’autore, Mimo 2.5, MiniMax 2.7, MiniMax M3 e Step 3.7 Flash si sono piazzati tutti al livello di Sonnet (Qwen 3.5 122B escluso). La differenza sta nei minuti necessari per completare il task: Mimo 2.5 ci mette circa 4 minuti, come Opus e Sonnet; MiniMax M3 ne impiega circa 40. Un divario che trasforma un flusso di lavoro interattivo in un collo di bottiglia ingestibile.

Questo significa che, in uno scenario agentic dove la finestra di contesto si riempie rapidamente, la scelta del modello non può prescindere dal rapporto tra qualità e latenza su contesti lunghi. Anche un modello più grande (427B contro 229B) non porta miglioramenti tangibili se la limitazione di VRAM lo forza allo stesso livello di quantization e se il kernel lo penalizza.

Cosa aspettarsi (e cosa no) dall’ecosistema locale

La situazione attuale racconta una verità scomoda per chi immagina il self-hosting di LLM come un’alternativa immediata al cloud: il software di serving è ancora in ritardo sulle GPU più nuove e sulle architetture custom. Progetti come Unsloth e llama.cpp stanno lavorando per colmare il gap, ma senza date certe. Nel frattempo, modelli come Mimo 2.5 e Step 3.7 Flash dimostrano che soluzioni “vecchia scuola” nell’attenzione possono tenere testa a contesti di oltre 150k token con hardware tutto sommato accessibile.

Per chi segue AI-RADAR, il caso è un promemoria utile: quando si valuta un deployment on-premise su GPU consumer o prosumer, l’analisi deve includere non solo le specifiche del modello, ma anche la maturità del supporto software sulla piattaforma scelta. Altrimenti si rischia di investire in macchine costose per poi scoprire che i modelli più promettenti girano più lentamente di quanto si sperasse.