C’è un momento, quando si spinge un modello linguistico piccolo oltre la semplice chat, in cui la generazione si sfilaccia. La scena 3D perde coerenza, le luci diventano incoerenti, la prospettiva non regge. Non manca la conoscenza dei singoli elementi, ma la capacità di orchestrarli in un tutto stabile. L’esperimento descritto su un forum di ricerca parte proprio da qui: e se la disciplina di pianificazione di un modello più grande potesse essere esternalizzata in uno scaffold, un’impalcatura procedurale applicabile a modelli più contenuti?

L’impalcatura invisibile

Lo scaffold in questione non è un prompt più raffinato. È una serie di contratti e vincoli derivati da un dominio Three.js: prima pianificare, definire il soggetto, l’ambiente, l’illuminazione e la camera, poi costruire a strati, preservare la silhouette, aggiungere segnali di identità, evitare oggetti puramente primitivi, verificare l’output finale. Non modifica i pesi del modello né richiede fine-tuning. Viene inserito nel contesto di inference come un binario che forza il modello a seguire una sequenza logica.

I risultati preliminari, ottenuti manualmente, mostrano miglioramenti asimmetrici. Il modello più grande già performante migliora in lucidatura; i modelli più piccoli fanno un salto di qualità in struttura e leggibilità del codice generato. È come se il piccolo sapesse cucinare, ma dimenticasse l’ordine delle portate: lo scaffold gli consegna la scaletta e la cena diventa presentabile.

Perché interessa a chi sceglie l’on-premise

Qui si apre un varco rilevante per il deployment locale dei LLM. Le aziende che valutano l’adozione di modelli self-hosted conoscono il trade-off: i modelli massivi richiedono GPU con decine di gigabyte di VRAM, consumi elevati e costi di infrastruttura. I modelli più piccoli girano su hardware modesto – a volte una singola scheda consumer – ma faticano a mantenere coerenza strutturale in task complessi come la generazione di scene, la scrittura di codice o la reportistica analitica.

Se uno scaffold ricavato da un dominio affine può trasferire una disciplina procedurale senza addestramento aggiuntivo, allora si apre la possibilità di potenziare modelli quantizzati o compatti, esattamente quelli che oggi finiscono su server aziendali o su appliance edge. Nessuna pretesa di pareggiare i modelli da centinaia di miliardi di parametri, ma la prospettiva di ottenere output organizzati con risorse di calcolo ridotte è concreta. E ciò impatta direttamente TCO (Total Cost of Ownership) e sovranità dei dati: meno cloud, più controllo locale.

Il test futuro: separare il codice dal rendering

L’autore dell’esperimento progetta ora un blind test: un valutatore esterno confronterà solo le immagini renderizzate, senza vedere il codice sorgente né sapere quale modello le abbia prodotte. L’ipotesi è che lo scaffold alzi il punteggio dei piccoli modelli ben oltre la baseline. Se il risultato si mantenesse su centinaia di prompt variati, non sarebbe più un semplice miglioramento di un singolo esempio, ma un trasferimento di una procedura riutilizzabile, qualcosa che somiglia a una competenza procedurale.

Uno sguardo più ampio

L’esperimento tocca un nervo scoperto della ricerca attuale. Gran parte degli sforzi sul miglioramento dei modelli piccoli passa per il fine-tuning o per la distillation, con costi di preparazione dei dataset e cicli di training. Un approccio che agisca solo a tempo di inference, senza alterare il modello, è più leggero e potenzialmente più flessibile. Se il concetto verrà validato, potremmo vedere la nascita di librerie di scaffold specializzati per domini: uno per query SQL, uno per la generazione di codice Python, uno per la robotica. Ognuno esternalizzerebbe la saggezza di un modello grande in una struttura riutilizzabile da modelli più snelli.

Certo, siamo ancora alle battute iniziali. I risultati sono manuali, il test non è blind, il campione è limitato. Ma la direzione indica una via pragmatica per chi lavora con LLM su hardware controllato: invece di inseguire il modello più potente nel cloud, si può iniziare a pensare a una stratificazione dell’intelligenza, dove la pianificazione viene fornita dall’esterno e il modello esegue. Per AI-RADAR, il segnale è chiaro: le strategie di inference-time stanno diventando cruciali come la scelta del modello stesso. E l’on-premise, con i suoi vincoli, è un terreno ideale per sperimentarle.