Il segnale: un ray tracer, tre sfere e un loop che si chiude

Non arriva da un benchmark ufficiale, e proprio per questo il confronto tra Qwen3.6-27B e Qwen3.8-27B ha un valore segnaletico. Un appassionato che da mesi ricostruisce demo grafiche in BASIC di fine anni Ottanta ha messo insieme un harness agentico con un transpiler da BASIC a JavaScript dentro una pagina web. Il sistema non si limita a generare codice: lo esegue, osserva l’immagine renderizzata e usa il risultato per iterare. È dentro questo ciclo che la differenza tra i due LLM diventa visibile, non in un test a singolo passaggio.

Il prompt chiedeva un ray tracer ricorsivo per tre sfere metalliche — rame, argento e oro — su un piano a scacchiera lucido e sotto un cielo blu intenso, con il modello Cook-Torrance per le sfere. Entrambi i modelli girano con quantization unsloth UD-Q8_K_XL. Qwen3.6 riesce ad arrivare a un ray tracer, ma spesso con qualche intervento dell’utente; quando qualcosa non torna nell’immagine, tende a non accorgersene o a non correggerla senza ulteriori prompt. Qwen3.8 invece in genere chiude il giro da solo e continua a iterare fino a un risultato buono.

La differenza è strutturale. Scrivere codice per un ray tracer è già un compito non banale; accorgersi che riflessi, ombre o materiali non sono coerenti guardando l’output e intervenire sul codice è un problema diverso. Qwen3.6 mostra il limite classico degli LLM usati come generatori one-shot: se l’errore non emerge nel testo del codice ma solo nell’immagine renderizzata, il modello resta cieco. Qwen3.8 sembra aver ridotto quella cecità, almeno in questo scenario. Non è un salto di benchmark astratto, è un cambiamento nella capacità di operare come agente.

Oltre il pass@1: la cecità del generatore one-shot

Le valutazioni tradizionali per gli LLM misurano spesso la generazione di codice in un singolo passaggio, confrontando l’output testuale con test o output attesi. In un compito grafico, però, il codice può essere sintatticamente corretto e comunque produrre riflessi sbagliati, ombre incoerenti o materiali non verosimili. Se il modello vede solo il sorgente e non i pixel renderizzati, non ha segnale per accorgersi dell’errore. È esattamente il punto che il confronto amatoriale porta in superficie.

Il comportamento di Qwen3.6 descrive bene il limite da generatore one-shot: produce codice plausibile, ma se l’errore vive nell’immagine e non nel testo, non avvia una correzione autonoma. Serve un prompt umano aggiuntivo, oppure il sistema si ferma. Qwen3.8, nel medesimo harness, riesce più spesso a usare il feedback visivo per correggere il tiro. Non sappiamo dalla fonte quali interventi di training o fine-tuning abbiano prodotto questo comportamento; il punto è che la differenza appare solo quando il ciclo si chiude.

La conseguenza di secondo ordine è che il pass@1 non basta più, o meglio non basta per le applicazioni agentiche. La metrica che inizia a contare è il tasso di correzione autonoma in un ambiente con esecuzione e osservazione visiva. In una pipeline locale, questo significa valutare quanti cicli servono per arrivare a un output accettabile senza intervento umano. Non è una questione di eleganza: è la differenza tra uno strumento che assiste e uno che lavora da solo.

C’è anche un effetto su come si leggono i leaderboard. I benchmark basati su testo o su test unitari possono non vedere miglioramenti nella capacità di percepire e correggere output visuali. Chi valuta un LLM per deployment on-premise deve quindi aggiungere al proprio framework di prova un esecutore e un confronto con l’immagine attesa, altrimenti rischia di premiare modelli che sembrano forti ma si fermano al primo errore visivo.

Il calcolo on-premise: la supervisione umana cambia il TCO

Per chi valuta deployment on-premise o self-hosted, la differenza tra Qwen3.6 e Qwen3.8 in questo scenario non è accademica. Un agente che richiede meno interventi umani riduce i costi di supervisione e rende più sostenibili pipeline locali di creative coding, prototipazione grafica o automazione visuale. Il costo del lavoro umano di revisione, non il costo per singola inference, diventa spesso la voce dominante del TCO quando un sistema deve operare su cicli lunghi.

Il fatto che entrambi i modelli girino con quantization spinta, unsloth UD-Q8_K_XL, suggerisce che il confronto avviene su un profilo di risorse compatibile con hardware locale, anche se la fonte non riporta specifiche di GPU o VRAM. Questo è un dettaglio importante: non stiamo parlando di un setup irraggiungibile, ma di un profilo che può entrare in una workstation o in un server locale. Il vincolo da misurare non è solo la latenza di una singola inference, ma il throughput iterativo: più cicli autonomi riesce a completare il modello, più il costo umano scende.

Il trade-off non va semplificato. Da un lato, quantization aggressiva riduce il footprint di VRAM e consente di eseguire modelli più grandi su hardware locale, ma può avere effetti sulla qualità della generazione; dall’altro, un modello che chiude il loop visivo con più costanza può valere più di uno con più parametri ma che richiede interventi frequenti. La scelta, quindi, non si riduce a una classifica di benchmark: va valutata sul ciclo completo, tenendo conto di quante volte un operatore deve guardare, correggere o rilanciare il processo.

In ottica TCO, il punto è che la supervisione umana non è un costo fisso. Se un modello autonomo fa dieci iterazioni senza prompt e un altro si ferma alla seconda, la differenza di costo operativo può superare la differenza di canone per l’hardware. Per le organizzazioni che gestiscono dati visivi o demo prototipali in locale, mantenere il ciclo dentro i propri sistemi ha anche un valore di sovranità: non è necessario inviare immagini o rendering a servizi cloud per ottenere un giudizio qualitativo.

L’infrastruttura di valutazione deve uscire dal testo

Il punto sollevato dalla fonte è che i benchmark tradizionali non catturano quasi nulla di tutto questo. Valutare una demo visiva richiede un ambiente con rendering, esecuzione e confronto con l’immagine attesa. Chi costruisce tooling per LLM locali dovrà esporre in modo nativo l’output visuale e il risultato dell’esecuzione, non solo la generazione del testo. Il transpiler da BASIC a JavaScript descritto nell’esperimento è un esempio minimo, ma sufficiente a mostrare la direzione.

I framework di orchestrazione locali dovranno integrare sandbox di esecuzione, rendering deterministico e confronto automatico tra immagini. In questo modo il feedback può diventare parte del contesto dell’LLM, non un passaggio separato affidato all’occhio umano. La differenza tra Qwen3.6 e Qwen3.8 è visibile proprio perché l’harness consente all’agente di vedere il risultato; se il tooling non espone quell’output, la capacità di autocorrezione resta inutilizzata.

Anche chi mantiene modelli aperti avrà un incentivo a pubblicare valutazioni multi-turno che misurino il tasso di correzione autonoma, non solo il pass@1. Questo sposterebbe il confronto da «quanto è bravo a completare un campione» a «quanto è capace di restare in carreggiata quando il compito evolve». Per le pipeline on-premise significa poter scegliere i modelli sulla base di un comportamento operativo, non solo di un punteggio statico.

Il caso Qwen3.6 vs Qwen3.8, pur essendo un esperimento amatoriale, segnala che la frontiera si sta spostando dal singolo token al ciclo completo. Il token resta l’unità di costo e di calcolo, ma il valore per l’utente finale si accumula nei cicli chiusi. Un’infrastruttura di valutazione che non include esecuzione e percezione visiva misura solo metà del problema.

Chi beneficia e chi resta esposto alla vecchia metrica

I beneficiari più immediati sono i team piccoli che lavorano con hardware locale su creative coding, prototipazione grafica e automazione visuale. Possono adottare modelli self-hosted con quantization spinta e un harness agentico, ottenendo un ciclo iterativo senza dover spostare dati visivi su piattaforme cloud. Per loro, un modello capace di chiudere il loop riduce il numero di revisioni manuali e rende il progetto più sostenibile.

Anche i manutentori di modelli aperti possono trarne vantaggio, se iniziano a pubblicare metriche che riflettono la correzione autonoma su compiti visuali. Questo li aiuterebbe a differenziare versioni che sembrano simili nei benchmark testuali ma che si comportano in modo diverso in un ciclo reale. Chi invece continua a valutare gli LLM solo con test a singolo passaggio rischia di non vedere miglioramenti operativi importanti e di orientare male gli acquisti o i deployment.

Sul fronte hardware, la fonte non riporta specifiche di GPU o VRAM. Tuttavia, l’uso di quantization unsloth UD-Q8_K_XL indica una direzione: la valutazione deve includere il profilo di risorse, non solo il nome del modello. Un confronto che non dichiara il contesto di esecuzione può essere fuorviante, perché la capacità di iterare in autonomia dipende anche dalla latenza e dalla stabilità del sistema locale.

Chi resta esposto alla vecchia metrica è soprattutto chi compra o adotta modelli in base a parametri o leaderboard generici. Il numero di parametri non dice se il modello è in grado di osservare un rendering e correggere il codice. In un contesto on-premise, questa differenza si traduce direttamente in ore di supervisione e in sostenibilità della pipeline.

Cosa guardare nei prossimi mesi

Primo, bisognerà osservare se emergono benchmark multi-turno legati a compiti visivi per LLM locali. La pubblicazione di suite che includono esecuzione, rendering e confronto automatico sarebbe un segnale che il settore sta cercando di misurare ciò che oggi è solo un esperimento amatoriale. Secondo, i manutentori di modelli aperti potrebbero iniziare a dichiarare metriche di correzione autonoma accanto al pass@1.

Un secondo fronte è il profiling delle risorse. I prossimi confronti dovranno riportare non solo il metodo di quantization, ma anche la VRAM disponibile, il numero di cicli autonomi e il tempo medio per iterazione. Questi dati aiuterebbero chi gestisce deployment self-hosted a stimare il TCO reale, invece di limitarsi a una fotografia di qualità su un singolo prompt.

Infine, vale la pena seguire l’evoluzione degli harness agentici open source per compiti grafici. L’esperimento del ray tracer in BASIC mostra che un transpiler, un esecutore e un osservatore visivo sono sufficienti per far emergere differenze operative. Se questi componenti diventano moduli standard nei framework locali, la capacità di autocorrezione potrà essere testata in modo più sistematico.

La conclusione di AI-RADAR è che la chiusura del loop, più della dimensione del parametro, è ciò che rende un modello utile quando deve lavorare da solo. La frontiera si è spostata dal singolo token al ciclo completo: per chi costruisce infrastrutture locali per LLM, progettare fin dall’inizio per l’osservazione dell’output e per la correzione iterativa è un criterio da considerare.