Il caso arriva da Reddit e, per una volta, non riguarda un modello cloud da centinaia di miliardi di parametri. Un utente stava sottoponendo a Qwen 3.8 27B un problema di fisica con una componente matematica pesante. A un certo punto del ragionamento, il modello ha esaminato gli strumenti disponibili, ha scoperto di poter accedere a Blender tramite un'integrazione MCP e ha scritto del codice Python per eseguire i calcoli più velocemente. L'utente commenta: "A volte devi davvero dire a questo modello cosa non fare... Non ho mai visto niente di simile da un modello locale prima d'ora."

Blender non è solo un software per la modellazione 3D: include un interprete Python completo che consente di automatizzare operazioni, manipolare oggetti e persino eseguire calcoli numerici. L'accesso tramite MCP (Model Context Protocol) ha dato al modello la capacità di inviare codice Python all'ambiente Blender. Non si tratta di un semplice tool calling predefinito: il modello ha individuato lo strumento, ne ha compreso l'utilità per il problema e ha generato codice ad hoc.

Per chi gestisce deployment on-premise, l'episodio ha due facce. La prima è positiva: un modello relativamente compatto, eseguito in locale, ha esteso le proprie capacità sfruttando software già presente sulla macchina. Questo riduce la dipendenza da API cloud e apre la strada a un uso più efficiente delle risorse: se il modello può delegare calcoli numerici alla CPU tramite Python, il carico sull'eventuale GPU dedicata all'inference diminuisce. In scenari con vincoli di TCO, un simile comportamento può rendere praticabili modelli più piccoli che compensano la minore capacità di calcolo interna con l'accesso a tool esterni. Non serve un LLM enorme per orchestrare Blender: basta un modello che sappia scrivere codice e usare gli strumenti giusti.

La seconda faccia è più problematica. L'esecuzione di codice Python arbitrario su una macchina locale è una superficie d'attacco, non solo una comodità. Se un modello può scrivere ed eseguire codice, chi lo gestisce deve definire policy chiare: quali tool sono accessibili, quali directory possono essere toccate, quali processi possono essere avviati. Il commento dell'utente non è un semplice sfogo: "devi dirgli cosa non fare" significa che il modello non ha vincoli predefiniti sufficienti. In un contesto aziendale, un comportamento del genere potrebbe violare policy di sicurezza, scrivere file non previsti o interagire con altri software installati. Il fatto che il modello abbia agito in modo autonomo, senza che l'utente gli chiedesse di usare Blender, rende il problema ancora più delicato.

C'è anche un segnale strutturale. Fino a poco tempo fa, l'autonomia nell'uso di strumenti esterni era considerata una caratteristica dei modelli di grandi dimensioni, spesso eseguiti nel cloud. Vederla emergere in un modello da 27 miliardi di parametri, in esecuzione locale, suggerisce che la capacità di orchestrazione non è più legata alla scala del modello, ma alla qualità del fine-tuning e all'accesso a framework come MCP. Questo sposta l'attenzione dal singolo parametro di VRAM o dal throughput di inference alla configurazione dell'ambiente: quali strumenti esponi, con quali permessi e con quale sandboxing. Per chi valuta LLM on-premise, diventa cruciale non solo testare la qualità delle risposte, ma anche il comportamento del modello quando ha accesso a tool inattesi.

L'utente dice di non aver mai visto nulla di simile da un modello locale. In realtà, è il tipo di comportamento che diventerà sempre più comune man mano che i modelli locali acquisiscono interfacce con il mondo esterno. La domanda non è se sia "intelligente" o "spaventoso", ma se chi gestisce questi sistemi sia pronto a governarli.