Ma una parte enorme di quel vantaggio non è nel silicio.

È nel software.

CUDA esiste dal 2006. In quasi vent’anni NVIDIA ha costruito intorno alle proprie GPU un ecosistema verticale composto da compiler, runtime, librerie matematiche, kernel ottimizzati, profiler, framework e strumenti di sviluppo. Quando un nuovo modello arriva sul mercato, nella maggior parte dei casi buona parte del lavoro necessario per farlo girare bene su NVIDIA è già stata fatta.

AMD parte da una posizione diversa. ROCm è sviluppato direttamente da AMD ed è in larga parte open source, ma è un ecosistema più giovane e ancora meno uniforme. Su hardware consumer recente non è raro incontrare feature non ancora ottimizzate, percorsi software alternativi, differenze tra HIP e Vulkan, regressioni o semplicemente workload che nessuno aveva ancora studiato in dettaglio.

A prima vista può sembrare solamente uno svantaggio.

Negli ultimi mesi, però, osservando quello che sta succedendo intorno a hardware come Strix Halo, ho iniziato a vederci anche qualcosa di molto più interessante.

Perché quando lo stack è aperto, un collo di bottiglia non deve necessariamente aspettare che il vendor decida di risolverlo.

Può farlo qualcun altro.

E qualcun altro ancora può prendere quella soluzione, modificarla, misurarla, combinarla con un’altra idea e infine tentare di riportarne la parte generalizzabile upstream.

Quello che sta emergendo non è semplicemente “una community che rende AMD più veloce”.

È qualcosa che assomiglia sempre di più a un co-design distribuito tra modelli, rappresentazioni numeriche, algoritmi di inferenza, runtime e hardware.

Il primo cambio di prospettiva: quantizzare non significa solo occupare meno memoria

Per anni abbiamo raccontato la quantizzazione quasi esclusivamente come un compromesso.

Un modello a 4 bit occupa meno memoria di uno a 8 o 16 bit, al prezzo di una certa perdita di precisione.

È vero, naturalmente. Ma su una macchina come Strix Halo manca un pezzo importante della storia.

Durante il decode di un LLM, molto spesso il problema non è la quantità di operazioni che la GPU può teoricamente eseguire. Il problema è la velocità con cui i pesi possono essere letti dalla memoria.

Se per generare ogni token devo attraversare decine di gigabyte di pesi, leggere meno bit significa anche spostare meno dati.

La quantizzazione diventa quindi una tecnica per sfruttare meglio la memory bandwidth.

È in questo contesto che lavori come ROCmFPX di Carlo Pasquale diventano particolarmente interessanti.

ROCmFP4 e le successive varianti non sono semplicemente nuovi nomi per una Q4 tradizionale. Sono formati e layout pensati esplicitamente per l’esecuzione su hardware AMD, con compromessi differenti tra dimensione, precisione e velocità. Nel repository compaiono oggi diversi percorsi specifici per Strix Halo, sia HIP sia Vulkan.

Ma il passaggio concettuale successivo è ancora più importante.

Forse la domanda sbagliata è:

“Questo modello è Q4 o Q8?”

La domanda più interessante diventa:

quali pesi conviene quantizzare, a quale precisione, e per quale motivo?

Qui è utile anche il lavoro di Salvatore Sanfilippo, antirez, con DwarfStar/DS4.

Nelle ricette per i grandi modelli MoE, per esempio, non tutti i tensori vengono trattati allo stesso modo. I routed experts possono essere compressi molto aggressivamente, mentre altre componenti — proiezioni, shared experts, output — vengono mantenute a precisione superiore. Anche l’importance matrix viene usata per guidare la quantizzazione.

Non è più semplicemente “comprimere un modello”.

È una forma di allocazione del budget di precisione.

Spendere più bit dove servono davvero e meno dove il modello può permetterselo.

Quando la quantizzazione entra nel runtime

Il lavoro di Ciru parte da ROCmFPX e spinge questa idea ancora oltre.

DualView, per esempio, parte da una rappresentazione Q7 dei pesi, ma permette alla GPU di vederli in modi diversi a seconda della fase dell’inferenza.

Durante il decode usa la rappresentazione compatta, riducendo i byte che devono essere letti per ciascun token.

Durante il prefill espone invece gli stessi valori sotto forma di una compute view Q8, adatta ai percorsi INT8 nativi dell’hardware.

Non viene fatta una seconda quantizzazione: cambia la rappresentazione utilizzata per il calcolo.

È un dettaglio tecnico che nasconde un’idea molto più generale:

non esiste necessariamente una rappresentazione numerica migliore in assoluto. Può esistere una rappresentazione migliore per ciascuna fase dell’inferenza.

ActiveFPX e PromptForge proseguono nella stessa direzione, arrivando a costruire percorsi di esecuzione specifici per le forme delle matrici effettivamente prodotte da modelli come Qwen 3.8.

A quel punto diventa difficile tracciare una linea netta tra “formato del modello” e “runtime”.

La quantizzazione è ormai parte del motore di esecuzione.

Quando un modello sblocca un’istruzione della GPU

Un altro esempio che trovo particolarmente elegante riguarda MTP, Multi-Token Prediction.

Nel normale decode autoregressivo un LLM genera essenzialmente un token alla volta.

Questo limita il parallelismo disponibile in alcune operazioni.

Ma con MTP il modello può proporre più token futuri, che vengono poi verificati insieme dal modello principale.

Questa verifica batched cambia la forma del problema.

Ed è qui che entra in gioco una caratteristica molto specifica di Strix Halo: le istruzioni matrix IU4 disponibili su gfx1151 (Strix Halo).

Nel lavoro ROCmFPX, un percorso sperimentale W4A4 collega proprio questi due mondi: pesi a quattro bit, attivazioni a quattro bit e istruzioni matrix IU4.

La cosa interessante non è tanto il risultato numerico del benchmark. È la catena causale:

il modello introduce MTP → MTP crea una verifica batched → la verifica batched rende utile una determinata operazione matrix → il runtime può finalmente sfruttare un’istruzione hardware specifica.

A questo punto non stiamo più semplicemente ottimizzando un kernel.

Stiamo collegando una caratteristica dell’architettura del modello a una caratteristica della microarchitettura della GPU.

Ed è proprio questo uno degli aspetti più interessanti dell’open source: chi sviluppa il runtime può osservare entrambe le estremità del problema.

Poi qualcuno apre il profiler

Non tutte le ottimizzazioni nascono da un nuovo formato numerico.

llama.cpp ha oltre 23 mila fork; tra questi, diversi sono oggetto di lavoro di ricerca per ottimizzazioni specifiche per determinati scenari, hardware, etc. Tra queste, interessante è il lavoro di Nathan Wilson, il cui fork per Strix Halo rappresenta bene l’altra faccia del processo di ottimizzazione: profiling sistematico, identificazione dei colli di bottiglia, patch piccole e verificabili.

Un esempio riguarda Flash Attention e la KV cache quantizzata. In alcuni percorsi il runtime finiva per dequantizzare gli stessi dati più volte. Modificando il flusso in modo da effettuare la dequantizzazione una sola volta e riutilizzarne il risultato, si elimina lavoro ridondante.

Lo stesso repository contiene interventi su MoE prefill, percorsi MMID, layout dei dati e kernel HIP/Vulkan. Ma forse la parte più importante è un’altra: Nathan separa chiaramente le patch candidate all’upstream da quelle che rimangono specifiche per Strix Halo.

Alcuni esperimenti producono miglioramenti importanti, altri quasi nulla, altri ancora peggiorano le prestazioni.

Ed è perfettamente normale.

Open source non significa automaticamente software migliore.

Significa che l’esperimento è visibile, riproducibile e falsificabile.

Qualcun altro può ripeterlo.

Può trovare un workload nel quale non funziona, può capire perché, può proporre una soluzione migliore.

E se il problema non fosse la GPU?

Con modelli sempre più complessi, anche concentrarsi esclusivamente sulla velocità dei kernel GPU comincia a essere limitante. EngramHalo, il fork di Aristo94 dedicato a Qwen 3.8 Flash-Next, è un buon esempio perché prova a sfruttare alcune caratteristiche particolari dell’architettura del modello invece di trattarlo come un Transformer tradizionale.

Una di queste è Qwen Sparse Attention (QSA). Con la normale attention, all’aumentare del contesto cresce anche la quantità di informazioni passate che bisogna considerare. QSA parte invece dall’idea che, per il token corrente, gran parte di un contesto molto lungo non sia necessariamente rilevante: un piccolo indexer individua quindi i blocchi del passato che vale la pena recuperare, e l’attention può concentrarsi principalmente su quelli.

Ma avere un algoritmo concettualmente sparse non significa necessariamente eseguirlo in modo davvero sparse. Se il runtime individua i token rilevanti ma continua comunque a leggere una grande porzione della KV cache per poi escludere ciò che non serve tramite una maschera, dal punto di vista logico sta facendo sparse attention, ma dal punto di vista della memoria continua a muovere molti dati inutilmente.

Uno degli interventi interessanti di EngramHalo è proprio qui: usa gli indici prodotti da QSA per effettuare un vero sparse gather, raccogliendo prima soltanto le righe K/V selezionate in un buffer compatto e facendo lavorare l’attention direttamente su quello. In termini semplici, invece di leggere tutto e poi scartare ciò che non serve, cerca di leggere direttamente solo ciò che servirà.

Qwen 3.8 Flash-Next introduce poi un’altra struttura particolare: la grande Engram table, una memoria associativa basata su n-gram. Brevi sequenze di token vengono usate per indirizzare direttamente alcune righe di una gigantesca tabella di embedding. La tabella può quindi contenere decine di miliardi di parametri senza che sia necessario attraversarli tutti a ogni token: per ciascuna inferenza ne viene consultata soltanto una piccolissima parte.

Questa caratteristica rende la Engram table molto diversa dai normali pesi di un layer e apre una possibilità interessante: non è indispensabile mantenerla interamente nella memoria più veloce. Può essere lasciata su storage e consultata on demand. EngramHalo sfrutta esplicitamente questa possibilità nel proprio percorso ottimizzato per Strix Halo, combinandola con QSA sparse gather, MTP e altre modifiche al runtime.

Non è un’idea isolata, in realtà. Antirez, in DS4, adotta una strategia molto simile: per Qwen 3.8 Flash-Next i 95,37 GiB di n-gram BF16 rimangono direttamente sul disco e il runtime legge dal GGUF soltanto le righe selezionate, senza caricare o mappare l’intera tabella in memoria. Anche qui il presupposto è lo stesso: se una struttura è enorme ma viene consultata in modo fortemente sparso, tenerla sempre residente è uno spreco.

È qui che il caso EngramHalo, e più in generale il confronto con DS4, diventa particolarmente interessante per il discorso più ampio. L’ottimizzazione non consiste semplicemente nel far eseguire alla GPU la stessa operazione un po’ più velocemente. Consiste nel guardare alla struttura del modello e chiedersi quale sia il modo più naturale di mapparla sull’intero sistema.

Una macchina basata su Strix Halo non è soltanto una GPU. È CPU, GPU, cache, memoria unificata e tipicamente NVMe, ciascuna con capacità, latenza e banda differenti. E anche il modello non è più un blocco uniforme di pesi: alcune strutture devono essere attraversate continuamente, altre richiedono accessi sparsi, altre ancora sono enormi ma vengono consultate solo in pochi punti.

Il compito del runtime diventa quindi non soltanto eseguire operazioni matematiche, ma decidere quali dati devono trovarsi dove, quali devono essere mossi e quali possono invece rimanere dove sono finché non servono.

Ed è proprio questo che rende implementazioni come EngramHalo un esempio così interessante del ruolo dell’open source: l’architettura del modello è pubblica, i runtime sono modificabili e il comportamento dell’hardware può essere osservato e misurato. Questo permette a sviluppatori indipendenti di arrivare, anche per strade diverse, a soluzioni simili: sparse attention che sia davvero sparse anche dal punto di vista della memoria, strutture enormi tenute su storage e recuperate on demand, runtime che ragionano sempre meno come semplici esecutori di kernel e sempre più come orchestratori dell’intero sistema.

Quando un’idea esce da una black box

Un passaggio interessante in questa storia è quello che collega Halogen, pwilkin e Ciru. Halogen, sviluppato da Peonist.ai, è un engine specifico per Qwen 3.8 Flash Next e AMD Strix Halo; mostra quanto si possa spingere lontano l’ottimizzazione quando si costruisce un runtime molto specializzato per una combinazione precisa di modello e hardware, ma il core del motore è proprietario. Il contributo di pwilkin è stato diverso: ha riprodotto in un’implementazione aperta basata su llama.cpp alcune delle idee che permettevano a Halogen di ottenere un prefill particolarmente veloce su Qwen 3.8 Flash-Next, rendendo disponibili kernel, configurazioni e percorso di esecuzione in una forma che altri potessero studiare e modificare.

È proprio da qui che il caso diventa interessante per il tema dell’open source. Una tecnica che inizialmente era osservabile soprattutto attraverso il comportamento di un runtime chiuso diventa improvvisamente codice ispezionabile e riutilizzabile. Ciru ha potuto prendere quel lavoro, adattarlo ai propri formati di peso e al proprio runtime e integrarlo con altre ottimizzazioni. Il valore non sta quindi soltanto nella velocità ottenuta, ma nel passaggio di stato dell’idea: da soluzione incorporata in un prodotto specifico a building block che può essere verificato, modificato e combinato con contributi indipendenti.

È un esempio quasi didattico di come può funzionare la circolazione dell’innovazione in un ecosistema aperto: un’idea emerge in un’implementazione specializzata, qualcuno la ricostruisce in forma open, altri la incorporano e la trasformano ulteriormente. Non è necessario che tutti i pezzi della catena siano open perché questo accada, ma è nel momento in cui l’implementazione diventa aperta che il ritmo di riuso e contaminazione può accelerare davvero.

Dal laboratorio all’ecosistema

C’è però un problema con tutta questa innovazione.

A un certo punto hai:

• un branch di llama.cpp;
• un kernel sperimentale;
• una quantizzazione custom;
• un container diverso;
• una determinata versione di ROCm;
• tre environment variable;
• e un README di quattro pagine.

Tecnicamente funziona.

Praticamente quasi nessuno lo userà.

Qui entra in gioco un contributo meno spettacolare dal punto di vista algoritmico, ma fondamentale per la maturazione dell’ecosistema: quello di Donato Capitella kyuz0.

Le AMD Strix Halo Toolboxes trasformano molti di questi esperimenti in ambienti riproducibili. Oggi raccolgono stack ROCm e Vulkan, configurazioni per Qwen Flash-Next, EngramHalo e anche l’integrazione con strix-llama di halo-box.

È facile sottovalutare questo passaggio.

Ma un’ottimizzazione non diventa realmente parte dell’ecosistema quando qualcuno scrive la patch.

Lo diventa quando qualcun altro riesce a riprodurla.

Il problema successivo: troppe buone idee

Arrivati qui emerge un paradosso.

La libertà di sperimentare produce tanti fork; se ciascuna innovazione rimane nel proprio fork, l’ecosistema rischia di frammentarsi.

È qui che progetti come halo-box/strix-llama.cpp diventano interessanti.

Il progetto mantiene volutamente una distinzione tra ciò che può essere generalizzato e ciò che rimane specifico di gfx1151. La base rimane vicina a llama.cpp upstream, mentre le ottimizzazioni più aggressive per Strix Halo possono essere integrate e sperimentate separatamente.

Forse è proprio questo il ciclo naturale di maturazione:

esperimento → fork → benchmark → confronto → integrazione → upstream.

Non tutte le idee arriveranno alla fine del percorso.

E non devono farlo.

Le ottimizzazioni strettamente legate a Strix Halo possono restare in uno stack specializzato.

Quelle generalizzabili possono risalire verso llama.cpp, ROCm, PyTorch o altri progetti upstream.

Nel frattempo tool come quelli di Donato possono renderle utilizzabili senza costringere ogni utente a ricostruire manualmente l’intera genealogia delle patch.

Non è solo una storia di LLM

La cosa che mi convince maggiormente che non si tratti di un’anomalia temporanea di llama.cpp è che lo stesso pattern sta comparendo nella generazione di immagini e video.

Con MiniMax H3, per esempio, uno dei colli di bottiglia su RDNA3.5 è l’attention su sequenze molto lunghe.

Il percorso generico funziona.

Ma conoscere contemporaneamente la forma precisa dei tensori prodotti dal modello e le caratteristiche di gfx1151 permette di costruire un percorso attention specializzato, evitando trasformazioni e movimenti di dati inutili.

Il risultato interessante non è il numero di secondi risparmiati.

È che qualcuno, al di fuori del team che ha progettato il modello e al di fuori del team che ha progettato la GPU, può studiare entrambi e trovare una rappresentazione più efficiente del problema.

Con Qwen Image 2.1 il concetto arriva ancora più lontano.

Non si interviene soltanto sul kernel.

Si possono combinare attention ottimizzate per l’hardware con tecniche che evitano di ricalcolare completamente parti del modello quando l’informazione cambia poco tra uno step e il successivo.

Conclusione: il valore dell’apertura

La cosa che trovo più interessante in tutta questa storia non è stabilire se AMD possa o meno recuperare il vantaggio accumulato da CUDA. È osservare cosa diventa possibile quando modello, runtime e buona parte dello stack software sono aperti. Un problema di prestazioni non appartiene più necessariamente al team che ha progettato la GPU, a quello che ha creato il modello o ai maintainer del framework: chiunque abbia competenze sufficienti può attraversare questi confini, capire dove si perde tempo o banda e provare una soluzione. È esattamente quello che vediamo nei lavori menzionati qui sopra e molti altri in community: idee nate indipendentemente che possono essere studiate, modificate, combinate e verificate da persone che spesso non appartengono alla stessa organizzazione e non si sono mai coordinate a priori.

Per me è questo il valore aggiunto più importante dell’open source. Non semplicemente avere accesso al codice, e nemmeno disporre di sviluppatori che fanno gratuitamente il lavoro che dovrebbe fare il vendor. È creare un ambiente in cui l’innovazione può avvenire senza dover essere pianificata centralmente. Un formato numerico nato per risolvere un problema può suggerire un nuovo kernel; un’ottimizzazione scritta per un modello può rivelare una proprietà utile della GPU; qualcuno può prendere entrambe, integrarle in un altro runtime e scoprire qualcosa che nessuno dei progetti originali aveva previsto. Anche gli esperimenti che non sopravvivono lasciano dietro di sé benchmark, codice, discussioni e conoscenza tecnica riutilizzabile.

Naturalmente questo ha un costo: duplicazione degli sforzi, fork incompatibili, esperimenti che si rivelano vicoli ciechi e una user experience che, soprattutto nelle fasi iniziali, è molto lontana dalla prevedibilità di uno stack maturo come CUDA. Ma la frammentazione che vediamo oggi può essere anche il laboratorio dal quale emergeranno le soluzioni di domani. Progetti come halo-box provano già a raccogliere idee nate altrove; kyuz0 le rende più facilmente riproducibili; ciò che si dimostra abbastanza generale può infine arrivare negli upstream. In questo processo non è necessario che sopravvivano tutti i repository: è molto più importante che possano sopravvivere le idee.

Da ingegnere che lavora da molto tempo con l’open source, probabilmente guardo questo fenomeno con una certa predisposizione favorevole. Ma Strix Halo mi sembra un caso particolarmente concreto di qualcosa che ho visto molte volte: l’apertura non sostituisce l’investimento del produttore, ma può moltiplicarne gli effetti. AMD fornisce il silicio e sviluppa ROCm; i progetti upstream costruiscono le fondamenta comuni; una comunità distribuita esplora contemporaneamente strade che nessuna singola azienda potrebbe probabilmente prioritizzare tutte. Il risultato è che, mesi dopo aver acquistato una macchina, quello stesso hardware può fare cose che al momento del lancio erano lente, difficili o semplicemente non previste. Il silicio non è cambiato. È aumentata la conoscenza collettiva di come usarlo. Ed è forse questa la parte più interessante della storia.

Riferimenti e approfondimenti

• ROCmFPX — Carlo Pasquale
• DwarfStar/DS4 — Salvatore Sanfilippo (antirez)
• Ciru — profilo Hugging Face
• DualView — Ciru
• Qwen3.8-27B CIRU ActiveFPX/PromptForge — Hugging Face
• Nathan Wilson — fork llama.cpp per Strix Halo
• EngramHalo — Aristo94
• Halogen Flash Server — Peonist.ai
• pwilkin — GitHub
• AMD Strix Halo Toolboxes — kyuz0 (Donato Capitella)
• strix-llama.cpp — halo-box
• ComfyUI RDNA35 Attention — Yasei-no-otoko
• ComfyUI CiruImageAccelerator — ciru-ai
• HIP — ROCm documentation
• AMD — Vulkan ecosystem
• AMD Ryzen AI Max+ 395 — scheda prodotto
• llama.cpp — ggml-org

Ma c’è un altro aspetto, secondo me più interessante: quando un modello può essere eseguito localmente e il suo workflow è accessibile, diventa possibile guardare dentro il processo di generazione, separarne i componenti e sperimentare.

È quello che sta succedendo in questi giorni attorno a H3. Nel giro di pochissimo tempo sono comparsi workflow ComfyUI, quantizzazioni, implementazioni alternative, sampler specifici e LoRA pensati per ridurre drasticamente il numero di step necessari. Non è tanto H3 in sé il tema di questo post: è piuttosto l’occasione per capire cosa significhino davvero alcune delle voci che troviamo nei workflow — scheduler, sampler, sigma shift, steps, low-step LoRA — e soprattutto perché intervenire su queste componenti possa migliorare la qualità, ridurre il tempo di generazione, o entrambe le cose.

L’obiettivo non è entrare nei dettagli dell’architettura specifica di H3, dei suoi Transformer, dell’attention o del training. Ci interessa un livello più alto: come avviene il sampling di una moderna pipeline generativa e dove possiamo intervenire per renderlo più efficiente.

Nota terminologica: userò spesso “denoising” nel senso intuitivo di processo iterativo che porta da uno stato rumoroso al contenuto finale. H3 è in realtà un modello basato su flow matching, non un diffusion model classico. Vedremo tra poco perché, per il discorso che ci interessa, l’astrazione resta comunque molto utile.

Prima di sampler e scheduler: come nasce un’immagine o un video?

Semplificando molto, una pipeline moderna di generazione può essere vista così:

prompt / immagini / video / audio di riferimento
                    │
                    ▼
          encoder / conditioning
                    │
                    ▼
             latent iniziale
                    │
                    ▼
         ┌───────────────────┐
         │  GENERAZIONE      │
         │    ITERATIVA      │
         │                   │
         │   model forward   │
         │        ↓          │
         │   latent update   │
         │        ↓          │
         │   model forward   │
         │        ↓          │
         │        ...        │
         └───────────────────┘
                    │
                    ▼
              latent finale
                    │
                    ▼
                 VAE
                    │
                    ▼
             immagine / video

Il prompt e gli eventuali riferimenti vengono prima trasformati in rappresentazioni che il modello possa usare come conditioning. Nel caso di un’immagine o di un video non lavoriamo normalmente direttamente sui pixel: il contenuto viene rappresentato in uno spazio compresso, il latent space.

La parte che ci interessa è il blocco centrale.

La generazione non avviene in una singola esecuzione del modello. Si parte da un latent fortemente rumoroso e lo si trasforma progressivamente fino a ottenere un latent che il VAE possa infine decodificare in pixel.

Per un video il concetto è lo stesso, anche se il latent è molto più grande: deve rappresentare non soltanto altezza e larghezza, ma anche il tempo. In H3, inoltre, audio e video vengono generati congiuntamente nello stesso sistema.

Ed è proprio questo loop iterativo a costare molto.

Diffusion e flow matching: abbastanza teoria da non raccontare bugie

Nei diffusion model classici il punto di partenza concettuale è un processo che aggiunge progressivamente rumore ai dati. Il modello impara poi a percorrere in qualche modo il processo inverso. A seconda della parametrizzazione può predire rumore, score, velocity o altre quantità correlate.

Il flow matching guarda il problema da una prospettiva leggermente diversa.

Immaginiamo una distribuzione semplice, come il rumore gaussiano, e la distribuzione complessa delle immagini o dei video che vogliamo generare. Tra le due esiste idealmente un percorso continuo. Il modello impara un campo vettoriale: dato il punto in cui ci troviamo lungo quel percorso, ci dice in quale direzione dobbiamo muoverci.

In forma molto astratta:

rumore                                      video
  ● ───────────────────────────────────────► ●

       il modello impara "come muoversi"
       lungo questa trasformazione

H3 appartiene a questa seconda famiglia.

Questa distinzione è importante dal punto di vista matematico, ma per quello che vogliamo capire possiamo usare un’astrazione comune:

stato corrente
      │
      ▼
   MODELLO
      │
      ▼
predizione di come evolvere lo stato
      │
      ▼
 aggiornamento
      │
      ▼
stato successivo

Da qui in avanti ragioneremo soprattutto come se avessimo un modello flow-based, perché è il caso di H3 e rende particolarmente intuitivo il ruolo di scheduler e sampler. Molte delle idee, però, si ritrovano anche nelle pipeline diffusion tradizionali.

Sigma: dove siamo lungo il viaggio

Serve ora una coordinata che descriva a che punto del processo ci troviamo.

In molte implementazioni questa coordinata viene espressa tramite sigma.

L’intuizione utile è:

sigma alto                                sigma basso

rumore  ───────────────────────────────────────► contenuto
 1.0                                               0.0

Non bisogna interpretare sigma semplicemente come “quanto rumore tolgo in questo step”. È piuttosto un’indicazione del livello di rumore dello stato corrente, ovvero della nostra posizione lungo la traiettoria.

A sigma molto alto il contenuto è ancora quasi tutto da determinare. A sigma basso la struttura è già sostanzialmente emersa e ci troviamo vicino al risultato finale.

Il modello riceve quindi qualcosa che, semplificando, assomiglia a:

latent corrente
sigma / timestep
conditioning

e produce una predizione.

Nel caso di un flow model possiamo pensarla come una velocity, cioè una direzione locale:

“Se ti trovi qui, a questo punto del percorso, devi muoverti in questa direzione.”

Una singola esecuzione completa del modello viene chiamata forward pass.

Timeline, curva dei sigma e griglia di riferimento

Fin qui abbiamo usato sigma come coordinata del processo, ma nelle implementazioni compare spesso anche un’altra coordinata: il timestep (o, più genericamente, t), cioè una posizione lungo la timeline ideale della generazione.

Le due cose non sono necessariamente la stessa cosa.

Possiamo pensare a t come a una coordinata astratta lungo il percorso:

t = 1                                      t = 0
rumore  ───────────────────────────────────► contenuto

Il model sampling definisce poi una relazione:

sigma = f(t)

che associa a ogni posizione della timeline il corrispondente livello di rumore. Se disegnassimo sigma in funzione di t, otterremmo quella che nel seguito chiameremo curva dei sigma.

Questa curva non deve essere lineare. Due timestep equidistanti possono quindi corrispondere a valori di sigma molto diversi tra loro.

Nella pratica il computer non rappresenta una curva continua con infiniti punti. Un’implementazione può costruire una griglia di riferimento molto più fitta degli step che useremo davvero per generare: una tabella di timestep e dei corrispondenti sigma. In ComfyUI, per i flow model discreti come quello usato da H3, questa griglia contiene normalmente molti più punti — tipicamente 1000 — rispetto ai 4, 8 o 20 step di una generazione.

È importante non confondere le due cose:

griglia di riferimento del modello
moltissimi punti che descrivono t → sigma
                    │
                    ▼
               scheduler
                    │
                    ▼
pochi sigma realmente usati nella generazione

Quei molti punti non sono altrettanti forward del modello. Servono a descrivere la relazione tra timeline e sigma e, per alcuni scheduler, a fornire i livelli da cui scegliere i punti effettivi di sampling.

Vedremo tra poco che il sigma shift interviene proprio sulla funzione f(t), deformando questa curva.

Il vero costo: quante volte eseguiamo il modello?

Questo è uno dei concetti più importanti dell’intero discorso.

Supponiamo che la generazione usi 20 valutazioni del modello:

sigma 1.00
    │
    ├── model forward
    ▼
sigma ...
    │
    ├── model forward
    ▼
sigma ...
    │
    ├── model forward
    ▼
   ...
    ▼
sigma 0.00

Ogni forward significa attraversare l’intero denoiser/Transformer con un latent che, soprattutto nel caso di un video, può essere enorme.

Per questo una prima approssimazione molto utile è:

tempo di sampling ≈ NFE × costo di un forward

Una singola esecuzione del modello è una function evaluation (FE), che nel nostro discorso coincide con un forward del denoiser. NFE significa invece Number of Function Evaluations: è il numero totale di FE richieste dalla generazione.

Quindi, per esempio:

NFE = 20  →  il denoiser viene valutato 20 volte

Non sempre steps = NFE: alcuni sampler possono richiedere più di una FE per uno stesso step. Per confrontare davvero il costo di due strategie di sampling, quindi, NFE è più significativo del semplice numero di step mostrato nell’interfaccia.

A questo punto emerge il problema fondamentale:

La traiettoria ideale è continua, ma noi possiamo permetterci di interrogare il modello soltanto un numero limitato di volte.

Se abbiamo un budget di 20, 8 o addirittura 4 forward, dove conviene farli? E come usiamo le predizioni ottenute per muoverci da un punto al successivo?

Sono esattamente le domande a cui rispondono scheduler e sampler.

Scheduler: dove spendere il budget di calcolo

Abbiamo ora due cose:

1. una relazione t → sigma, definita dal model sampling;
2. un budget limitato di valutazioni del modello.

Lo scheduler deve trasformare queste informazioni nella piccola sequenza di sigma che useremo davvero durante la generazione.

Supponiamo, per semplicità, che la relazione tra timeline e sigma fosse lineare e di voler fare pochi step. Potremmo ottenere una sequenza come:

1.00 ─── 0.75 ─── 0.50 ─── 0.25 ─── 0.00

Ma non è affatto detto che distribuire le valutazioni in questo modo sia la scelta migliore. Potrebbe essere più utile concentrare i punti in una certa zona del percorso:

1.00 ─ 0.96 ─ 0.87 ───── 0.55 ───────── 0.00

oppure fare quasi il contrario.

In ComfyUI, nomi come:

• simple
• karras
• exponential
• beta
• normal

indicano strategie diverse per costruire questa sequenza.

L’output dello scheduler è quindi essenzialmente:

sigma_0, sigma_1, sigma_2, ... sigma_n

Con steps = 4, per esempio, ci saranno normalmente quattro intervalli da percorrere e un sigma terminale pari a zero.

Cosa significa allora simple?

Nel caso di ComfyUI il nome è molto letterale.

Lo scheduler simple guarda la griglia di riferimento dei sigma del modello che abbiamo appena introdotto e ne prende un certo numero di punti a intervalli approssimativamente regolari negli indici, aggiungendo poi sigma = 0 come termine finale.

Quindi simple non significa che il processo di denoising nel suo complesso sia “semplice”, e soprattutto non ci dice ancora come verrà aggiornato il latent tra un sigma e il successivo.

Dice soltanto, in sostanza:

“Dato il numero di step richiesto, scegli in modo semplice i livelli di sigma ai quali faremo le valutazioni.”

Altri scheduler costruiscono la sequenza con criteri differenti. Karras ed exponential, per esempio, distribuiscono i sigma secondo specifiche trasformazioni matematiche del range; beta privilegia certe regioni della griglia secondo una distribuzione beta; normal lavora sulla timeline del modello e la riconverte in sigma.

Per il momento ci basta il principio generale:

lo scheduler decide dove, lungo la traiettoria, spendere le nostre FE.

Non abbiamo ancora stabilito come usare la predizione ottenuta in quei punti per arrivare al successivo. Quello sarà il compito del sampler.

Sigma shift: cambiare la geometria della timeline

A complicare — o rendere più interessante — il quadro c’è il sigma shift.

Ora possiamo descriverlo in modo più preciso: lo shift interviene sulla relazione sigma = f(t) che abbiamo introdotto prima. Non sceglie gli step; modifica il valore di sigma associato ai diversi punti della timeline.

Nel caso del flow sampling usato da H3 in ComfyUI, la trasformazione ha la forma:

sigma(t) = shift × t / (1 + (shift - 1) × t)

Con shift = 1 la relazione è lineare: sigma = t. Aumentando lo shift, gran parte della timeline viene invece mappata verso sigma più alti.

Possiamo quindi immaginare la catena così:

timeline t
      │
      │  model sampling + sigma shift
      ▼
relazione / curva t → sigma
      │
      │  discretizzata nella griglia di riferimento
      ▼
   scheduler
      │
      ▼
pochi sigma effettivamente usati

Uno shift forte può far sì che molti punti della timeline corrispondano ancora a sigma relativamente alti. Per esempio, in un modello con shift elevato, una sequenza apparentemente uniforme sulla timeline può produrre valori del tipo:

1.000 → 0.973 → 0.923 → 0.800 → 0.000

anziché:

1.000 → 0.750 → 0.500 → 0.250 → 0.000

Il concetto importante non è il valore specifico: è che la relazione tra “posizione nello step” e livello di rumore non deve essere necessariamente lineare.

Scheduler e sigma shift sono quindi concettualmente vicini: entrambi influenzano dove vengono spese le valutazioni del modello. Non sono però equivalenti.

Il sigma shift fa parte della parametrizzazione della curva di sampling del modello; lo scheduler decide come campionare un numero finito di punti su quella curva.

Ed entrambi possono contribuire allo stesso obiettivo pratico: usare meglio ogni costosa valutazione del denoiser.

Sampler: come ci muoviamo tra due punti

Ora abbiamo una sequenza:

sigma_0 → sigma_1 → sigma_2 → ... → 0

A ciascun punto chiediamo al modello una direzione.

Resta però da decidere come usare quella direzione per aggiornare il latent.

Questo è il compito del sampler, o più precisamente del solver numerico.

Euler: segui la direzione corrente

Il caso più intuitivo è Euler.

Il modello dice:

sei qui ● ─────────► vai in questa direzione

e il sampler compie un passo verso il sigma successivo usando quella previsione.

In forma concettuale:

prediction = model(x, sigma)
x_next = x + prediction × step_size

È semplice ed economico: tipicamente una valutazione del modello per ogni intervallo.

Il limite è altrettanto intuitivo. Se la traiettoria curva molto, una direzione misurata nel punto di partenza diventa meno accurata quanto più grande è il passo.

Heun e i metodi che verificano la traiettoria

Un metodo di ordine superiore può fare qualcosa del genere:

1. chiede al modello la direzione corrente;
2. calcola dove arriverebbe;
3. interroga nuovamente il modello nel punto stimato;
4. combina le due predizioni per ottenere un aggiornamento migliore.

Il risultato numerico può essere più accurato, ma abbiamo pagato due forward invece di uno.

Questo evidenzia perché contare soltanto gli step può essere fuorviante.

Multistep: ricordarsi il passato

I metodi multistep adottano una strategia particolarmente interessante per i grandi modelli generativi.

Invece di interrogare più volte il denoiser nello stesso intervallo, conservano le predizioni ottenute negli step precedenti:

sigma A → prediction A
sigma B → prediction B
sigma C → prediction C

e usano questa storia per stimare meglio come sta cambiando la traiettoria.

L’obiettivo è ottenere un’integrazione più accurata senza necessariamente raddoppiare il numero di costosi forward.

Questo è il principio che rende sampler multistep particolarmente interessanti quando il denoiser è enorme: ottenere più valore da ogni singola FE.

DPM++, ancestral, SDE: perché esistono così tanti sampler?

Le dropdown di ComfyUI possono diventare rapidamente intimidatorie:

euler
euler_ancestral
heun
dpmpp_2m
dpmpp_2m_sde
dpmpp_3m_sde
res_multistep
...

Non sono semplicemente varianti “più o meno buone” dello stesso algoritmo.

Cambiano diverse proprietà:

• l’ordine del solver;
• il fatto che sia single-step o multistep;
• quante valutazioni del modello richieda;
• se il processo sia deterministico;
• se venga reintrodotta stocasticità durante il sampling;
• come vengano trattate le predizioni precedenti.

Un sampler ancestral o SDE, per esempio, può reintrodurre rumore durante il percorso. Questo può essere utile per varietà e texture, ma per un video la stocasticità deve fare i conti anche con la coerenza temporale.

Non esiste quindi “il sampler migliore” in assoluto.

Esiste un sampler più o meno adatto a:

• quel modello;
• quello scheduler;
• quel numero di step;
• quel tipo di contenuto;
• il compromesso qualità/tempo che vogliamo ottenere.

Ridurre gli step: perché non basta semplicemente scrivere 4

A questo punto potrebbe sembrare che la soluzione sia banale: se 20 forward costano troppo, impostiamo steps = 4.

Il problema è che con quattro valutazioni i salti diventano enormi.

Immaginiamo una traiettoria curva:

traiettoria corretta

A ●
    \
     \
      ●
       \
        \____ ● B

Con tanti step piccoli una previsione locale leggermente imprecisa viene presto corretta dalla chiamata successiva.

Con quattro step, invece, potremmo chiedere al modello di fare qualcosa del genere:

A ● ───────────────────────► B'

Una piccola imprecisione nella direzione iniziale produce un errore molto più grande alla fine del salto.

Scheduler e sampler possono aiutarci a scegliere punti migliori e integrarli meglio, ma a un certo punto emerge un limite: il modello stesso non è stato necessariamente addestrato per lavorare bene con una discretizzazione così aggressiva.

È qui che entrano in gioco i low-step LoRA.

Low-step LoRA: questa volta cambiamo il modello

Un LoRA modifica il comportamento del modello aggiungendo adattamenti a basso rango ai suoi pesi. È un meccanismo molto più leggero rispetto alla distribuzione di un checkpoint completo.

Nel caso dei LoRA per few-step inference, l’obiettivo non è cambiare lo stile del video o insegnare un nuovo personaggio. L’obiettivo è modificare il denoiser affinché produca predizioni utili quando il sampling usa pochissimi step.

Il contrasto con scheduler e sampler è importante.

Scheduler:

Dove interrogo il modello?

Sampler:

Come uso le sue predizioni per muovermi?

Low-step LoRA:

Come modifico il modello stesso perché le sue predizioni restino buone quando lo interrogo molto meno spesso?

Un LoRA di questo tipo viene tipicamente addestrato o distillato per uno specifico regime few-step. Per questo spesso arriva accompagnato da indicazioni precise sul numero di step, sullo scheduler e sul sampler da utilizzare.

Non è un generico interruttore “turbo”.

Se un LoRA è stato ottimizzato, per esempio, per una certa sequenza di quattro sigma, cambiare arbitrariamente scheduler significa chiedere al modello di lavorare fuori dalla configurazione per la quale è stato adattato.

Questa è una differenza importante rispetto a una normale ottimizzazione implementativa: qui qualità e velocità vengono scambiate già durante l’addestramento/adattamento del modello.

Un workflow reale: MiniMax H3 in ComfyUI

Ed eccoci finalmente al motivo per cui H3 è un esempio così utile.

Un workflow ComfyUI per H3 con un Turbo LoRA può contenere contemporaneamente questi blocchi:

Load LoRA
    │
    ▼
ModelSamplingMiniMaxH3
sigma shift
    │
    ▼
BasicScheduler
scheduler = simple
steps = 4
    │
    │ produce i sigma
    ▼
SamplerCustomAdvanced ◄──── KSamplerSelect
                          res_multistep

A prima vista può sembrare che simple, res_multistep, sigma shift e 4 steps siano quattro modi diversi di controllare la stessa cosa.

In realtà sono quattro pezzi distinti che cooperano.

1. Il Turbo LoRA

Modifica H3 affinché possa lavorare in un regime few-step.

2. ModelSamplingMiniMaxH3

Imposta la particolare relazione tra timeline e sigma utilizzata dal modello. H3 gestisce inoltre video e audio su schedule differenti, pur generandoli congiuntamente.

3. BasicScheduler: simple

Prende la curva dei sigma risultante e seleziona i punti da utilizzare per i quattro step.

Il risultato non è necessariamente una sequenza lineare di sigma: simple lavora sulla griglia del modello, che è già stata deformata dal sigma shift.

4. KSamplerSelect: res_multistep

Non produce sigma.

Riceve i sigma scelti dallo scheduler e decide come integrare il percorso tra un punto e l’altro, utilizzando anche informazioni provenienti dalle predizioni precedenti.

Infine SamplerCustomAdvanced mette insieme:

noise iniziale
conditioning
modello
sampler
lista dei sigma

ed esegue effettivamente il loop.

Visto così, il workflow smette di essere una collezione di dropdown misteriose e diventa la rappresentazione esplicita di un algoritmo numerico.

Tre modi diversi di rendere più veloce la generazione

A questo punto possiamo organizzare le ottimizzazioni in modo abbastanza pulito.

1. Ridurre il costo di ogni forward

Per esempio:

• ridurre risoluzione;
• ridurre il numero di frame;
• quantizzare i pesi;
• usare kernel di attention più efficienti;
• sfruttare sparse attention;
• migliorare l’implementazione hardware.

In questo caso:

NFE invariato
×
forward più economico
=
generazione più veloce

2. Fare meno forward

È il territorio dei modelli few-step e dei low-step LoRA:

NFE: 20 → 8 → 4

Se il costo del denoiser domina il tempo totale, la riduzione può essere enorme.

3. Ottenere più valore da ogni forward

Qui entrano scheduler e sampler.

Un migliore posizionamento dei sigma e un solver più adatto possono produrre:

• più qualità a parità di NFE;
• qualità simile riducendo NFE.

Ed è per questo che qualità e velocità non sono problemi separati.

L’obiettivo vero: quality per compute

Dire “questo sampler è più veloce” è spesso una semplificazione sbagliata.

Se due sampler hanno entrambi NFE = 20, il tempo trascorso nel denoiser sarà grossomodo simile. Uno dei due potrebbe però produrre una qualità migliore.

A quel punto potremmo scoprire che con il sampler migliore basta NFE = 12 per raggiungere la qualità che l’altro otteneva con NFE = 20.

È lì che nasce il vero speed-up.

Lo stesso ragionamento vale per uno scheduler.

E per un low-step LoRA il concetto viene spinto ancora oltre: adattiamo il modello affinché possa estrarre molto più risultato da pochissime valutazioni.

La metrica mentale più utile diventa quindi qualcosa del tipo:

                qualità ottenuta
efficienza = ───────────────────────
              compute necessario

Non stiamo cercando semplicemente di rendere il timer più piccolo. Stiamo cercando di ottenere il miglior risultato possibile per una quantità limitata di compute.

Quattro step non significano automaticamente cinque volte più veloce

C’è però un’ultima precisazione importante.

Se il sampling passa da NFE = 20 a NFE = 4, la parte di denoising può teoricamente avvicinarsi a un’accelerazione di 5×.

Ma la pipeline completa comprende anche:

text / vision encoding
conditioning
preparazione dei latent
sampling
VAE video decode
VAE audio decode
encoding/mux del video finale

Questi costi non scompaiono riducendo gli step.

Quindi:

tempo totale =
    costi fissi
  + NFE × costo_forward
  + decoding/output

Più il denoiser domina il runtime, più la riduzione di NFE si avvicina allo speed-up teorico. Più sono importanti encoder e VAE, meno il guadagno complessivo sarà proporzionale.

Anche questo è un motivo per cui, parlando di performance, è utile distinguere sampling time e end-to-end generation time.

Il valore di poter vedere il workflow

Ed è qui che torniamo, solo alla fine, all’apertura del modello.

Se utilizziamo un generatore video esclusivamente attraverso un’API, vediamo qualcosa di molto semplice:

prompt → video

Il provider può utilizzare internamente distillazione, scheduler particolari, solver proprietari, caching, sparse attention o qualsiasi altra ottimizzazione. Per noi il processo rimane una scatola nera.

Con pesi eseguibili localmente e strumenti modulari come ComfyUI vediamo invece:

conditioning
     ↓
model sampling
     ↓
scheduler
     ↓
sampler
     ↓
latent
     ↓
VAE

E possiamo intervenire.

Non perché ogni utente debba inventarsi un nuovo solver numerico, ma perché la possibilità di osservare e modificare il workflow rende molto più facile capire cosa sta realmente succedendo.

H3 è semplicemente l’esempio del momento. La community ha avuto accesso al modello, ComfyUI ha reso visibili i pezzi della pipeline e nel giro di pochi giorni sono partiti gli esperimenti: nuovi workflow, quantizzazioni, few-step LoRA, scheduler e sampler alternativi.

Ed è proprio questo il punto più interessante.

L’AI aperta non significa soltanto poter scaricare un file molto grande invece di chiamare un’API.

Significa anche poter aprire il cofano, seguire i cavi e scoprire che dietro un apparentemente banale pulsante Generate c’è un problema molto concreto di calcolo numerico:

abbiamo una traiettoria continua, un numero limitato di costose valutazioni del modello e dobbiamo decidere dove farle, come usarle e quanto possiamo permetterci di distanziarle.

Una volta capito questo, simple, Karras, res_multistep, 4 steps e Turbo LoRA smettono di sembrare formule magiche.

Sono semplicemente strumenti diversi per rispondere a quelle tre domande.

Riferimenti e approfondimenti

• MiniMax — MiniMax H3 open-source announcement
• MiniMax H3 — repository ufficiale
• ComfyUI — workflow MiniMax H3
• Flow Matching for Generative Modeling — Lipman et al.
• ComfyUI — implementazione degli scheduler
• ComfyUI — nodi MiniMax H3 e sigma shift
• MiniMax H3 Turbo LoRA — esempio community few-step

A quel punto la domanda diventa inevitabile: come si misura davvero la qualità di un modello in questo scenario?

I benchmark classici sui modelli di linguaggio aiutano fino a un certo punto. Sapere che un modello è forte su HumanEval, MMLU, GPQA o su un generico “coding score” è interessante, ma dice poco su quello che succede quando lo metti dentro un agente, gli dai una issue reale, un repository non banale, una shell, dei test e gli chiedi di produrre una patch funzionante.

Per questo i benchmark della famiglia SWE-bench sono diventati così importanti. E per questo mi sono messo a guardare con attenzione SWE-bench Pro.

Non tanto per pubblicare un numero da leaderboard, ma per rispondere a una domanda molto più pratica:

Se eseguo lo stesso modello in locale con quantizzazioni diverse, quanto cambia davvero la capacità di risolvere task di coding agent?

Questo post è il primo pezzo del percorso. Racconta cos’è SWE-bench Pro, perché esiste, quali problemi prova a risolvere rispetto ai benchmark precedenti, e cosa significa provare a eseguirlo in locale.

I risultati veri arriveranno probabilmente più avanti, per ora proviamo a costruire un metodo.

Perché serve un altro benchmark

SWE-bench nasce con un’idea molto semplice e molto potente: prendere issue reali da repository GitHub reali e chiedere a un modello di generare una patch che risolva il problema.

Non quindi:

• scrivere una funzione isolata;
• completare poche righe di codice;
• rispondere a una domanda teorica;
• scegliere tra quattro opzioni.

Ma lavorare su una codebase vera.

In un task di SWE-bench il modello riceve una descrizione del problema, ha accesso al repository, deve modificare i file corretti e alla fine viene valutato eseguendo una suite di test. Se i test che prima fallivano passano e quelli che già passavano continuano a passare, la patch viene considerata corretta.

Questo è molto più vicino a quello che ci interessa quando parliamo di coding agent.

Il problema è che i benchmark, quando diventano popolari, iniziano anche a saturarsi.

Saturazione significa almeno tre cose:

1. i modelli migliorano davvero e risolvono sempre più casi;
2. gli strumenti attorno ai modelli vengono ottimizzati specificamente per quel benchmark;
3. i task pubblici finiscono in dataset, esempi, discussioni, traiettorie, post, repository e materiale di training.

A quel punto diventa difficile capire quanto uno score misuri davvero capacità generale e quanto invece misuri familiarità, ottimizzazione sul benchmark o, nei casi peggiori, contaminazione.

Questo è diventato particolarmente evidente con SWE-bench Verified. Verified nasceva come subset più pulito e umanamente verificato di SWE-bench, composto da 500 problemi considerati risolvibili da sviluppatori reali. Per un certo periodo è stato uno dei riferimenti principali per confrontare modelli e agenti.

Poi però il benchmark è diventato talmente centrale da essere sempre meno informativo. Se i casi sono pubblici, discussi, riutilizzati e magari inclusi indirettamente nei dati di training, il numero finale continua a essere interessante, ma va letto con cautela.

SWE-bench Pro nasce anche da qui: dalla necessità di avere task più realistici, più lunghi, più vari e meno facilmente saturabili.

Cos’è SWE-bench Pro

SWE-bench Pro è un benchmark per valutare coding agent su task software di maggiore complessità rispetto a SWE-bench classico e Verified.

La differenza non è solo quantitativa, ma qualitativa. L’obiettivo è avvicinarsi di più a problemi da sviluppo software reale: codebase più complesse, linguaggi diversi, task più lunghi, modifiche che coinvolgono più file e patch meno banali.

La struttura del benchmark è divisa in tre insiemi principali:

• Public set: 731 task pubblici, rilasciati su Hugging Face;
• Commercial set: 276 task provenienti da repository proprietari di startup partner, non rilasciati pubblicamente;
• Held-out set: 858 task tenuti privati, pensati per misurare overfitting e generalizzazione futura.

Questa divisione è importante.

Il public set è quello che possiamo scaricare ed eseguire localmente. È utilissimo per esperimenti riproducibili, confronti tra configurazioni, studio degli errori e analisi metodologiche.

Ma proprio perché è pubblico non può essere considerato completamente immune alla contaminazione.

Il commercial set e l’held-out set servono invece a preservare una parte del benchmark fuori dalla portata diretta di training, tuning e ottimizzazioni pubbliche. Sono più adatti a misurazioni “da leaderboard” o a confronti controllati, ma non sono eseguibili liberamente in locale.

Quindi la prima cosa da chiarire è questa:

Eseguire i 731 casi pubblici di SWE-bench Pro è utile, ma non equivale a eseguire il benchmark privato completo.

Non è un dettaglio. È il tipo di distinzione che può cambiare completamente il significato di uno score.

Contaminazione: il problema non sparisce

SWE-bench Pro è stato progettato anche per ridurre il rischio di contaminazione. Ad esempio, i subset open source usano repository con licenze copyleft forti, mentre il subset commerciale contiene codice proprietario non rilasciato pubblicamente.

Questo aiuta, ma non rende magico il public set.

Se un task è pubblico, allora in linea di principio può finire:

• nei dati di training;
• in issue e discussioni online;
• in repository di esperimenti;
• in log di agenti pubblicati;
• in post tecnici;
• in dataset derivati;
• in patch usate per esempi e tutorial.

Quindi, se un modello ottiene un buon risultato sul public set, non possiamo automaticamente dire: “ecco la sua capacità su problemi mai visti”.

Però questo non significa che il public set sia inutile. Dipende dalla domanda.

Se voglio confrontare in assoluto due modelli frontier e dichiarare chi sia migliore in generale, la contaminazione è un problema serio.

Se invece voglio confrontare lo stesso modello in più quantizzazioni, sullo stesso hardware, con lo stesso agente, lo stesso prompt e lo stesso subset di task, allora il public set può essere estremamente utile.

In quel caso non sto cercando di misurare la capacità assoluta del modello nel mondo. Sto cercando di misurare una variazione relativa:

quanto degrada il comportamento agentico passando, ad esempio, da una quantizzazione più conservativa a una più aggressiva?

È una domanda molto pratica. Ed è esattamente il tipo di domanda che mi interessa per l’AI locale.

Quando un task si considera passato

Il funzionamento di base è questo.

Per ogni istanza del benchmark esiste:

• una descrizione del problema;
• un repository in uno specifico stato iniziale;
• una patch “gold”, cioè la soluzione attesa o di riferimento;
• una serie di test che devono passare dopo la correzione.

Il modello non deve produrre una spiegazione. Deve produrre una patch.

L’evaluator applica la patch al repository e lancia i test selezionati. In genere si distinguono due categorie:

• fail-to-pass: test che prima fallivano e che devono passare dopo la patch;
• pass-to-pass: test che già passavano e devono continuare a passare.

Una patch è considerata corretta solo se risolve il problema senza rompere il comportamento già esistente.

Questo è il punto che rende SWE-bench interessante. Non basta che la patch “sembri sensata”. Non basta che il modello spieghi bene cosa voleva fare. Non basta nemmeno che modifichi il file giusto.

Alla fine contano i test.

Naturalmente anche qui bisogna stare attenti: la qualità del benchmark dipende dalla qualità dei test. Se i test sono deboli, una patch può passare pur essendo concettualmente sbagliata. Se i test sono fragili o troppo legati all’ambiente, una patch corretta può fallire. Per questo l’esecuzione locale del benchmark non è soltanto “lancio un comando e leggo una percentuale”: richiede attenzione metodologica.

Quanti test, quante ripetizioni, quale score?

Una tentazione naturale sarebbe prendere i 731 task pubblici, lanciarli tutti una volta e leggere il risultato finale.

È un punto di partenza, ma non basta sempre.

Ci sono almeno quattro aspetti da considerare.

1. Il subset

Se uso tutti i 731 casi pubblici, ottengo un numero più stabile, ma spendo molto tempo.

Se uso 10, 20 o 50 casi, posso iterare più velocemente, ma il risultato è molto più rumoroso.

Per fare debugging dell’infrastruttura bastano pochi casi. Per confrontare seriamente quantizzazioni diverse serve un subset più ampio, e possibilmente scelto con criterio: linguaggi diversi, repository diversi, patch di dimensioni diverse, task facili e task difficili.

2. Le ripetizioni

I coding agent sono sistemi non deterministici. Anche a temperature bassa o zero possono esserci differenze dovute al backend, al parsing dei tool, al comportamento dell’agente, ai timeout e alla gestione dei comandi.

Una singola esecuzione può essere informativa, ma non racconta tutta la storia.

Per confronti seri avrebbe senso ripetere almeno alcuni task più volte, soprattutto se si vogliono confrontare modelli o quantizzazioni vicini tra loro.

3. Il tipo di fallimento

Uno score finale dice poco.

È molto più utile classificare i fallimenti:

• patch vuota;
• patch non applicabile;
• patch applicabile ma test falliti;
• timeout;
• errore nell’ambiente Docker;
• modello che modifica test o file non ammessi;
• agente che non riesce a interagire correttamente con il container;
• patch plausibile ma incompleta.

Nel mio primo esperimento locale, ad esempio, una patch generata da Qwen3.6 35B A3B quantizzato non ha passato il task, ma questo è comunque stato utile: la patch era non vuota, si applicava, i test partivano e arrivavano a un risultato concreto. Questo significa che la pipeline stava finalmente misurando qualcosa di reale.

4. Il tempo

La validazione di una patch è una cosa. Generare la patch con un agente locale è un’altra.

La validazione con Docker può richiedere decine di secondi o minuti per istanza. La generazione della patch, invece, può richiedere molto di più, soprattutto se il modello locale è lento, il task è lungo e l’agente fa molti passaggi.

Quindi un esperimento completo non si pianifica solo contando i task. Si pianifica anche stimando:

• tempo di generazione;
• tempo di validazione;
• spazio disco per immagini e output;
• parallelismo sostenibile;
• probabilità di timeout;
• costo di ripetere più run.

Perché eseguire SWE-bench Pro in locale

A questo punto uno potrebbe chiedersi: perché complicarsi la vita?

Se esistono leaderboard pubbliche, perché scaricare dataset, immagini Docker, agenti, modelli locali e mettersi a far girare tutto su una macchina consumer?

La risposta, nel mio caso, è semplice: perché le leaderboard non rispondono a tutte le domande pratiche.

A me interessa capire, ad esempio:

• un modello locale quantizzato a 4 bit perde molto rispetto a 6 o 8 bit?
• un MoE piccolo-attivo ma grande-totale si comporta meglio o peggio di un denso più piccolo?
• un modello più lento ma più accurato conviene davvero in un workflow agentico?
• quanto impatta la dimensione del contesto?
• quanto la quantizzazione della KV-cache?
• quali errori fa il modello quando fallisce?
• il problema è la qualità del modello o l’infrastruttura attorno?

Queste domande non si risolvono guardando un punteggio su Artificial Analysis o una tabella di benchmark pubblica.

Bisogna eseguire esperimenti controllati.

Nel mio caso il contesto è quello già discusso in altri post: un sistema basato su AMD Ryzen AI Max+ 395 (Strix Halo) con 128 GB di memoria unificata, usato per inferenza locale con modelli openweight.

È una macchina interessante perché permette di caricare modelli relativamente grandi, ma costringe anche a fare i conti con compromessi reali: quantizzazione, velocità di prefill, velocità di generazione, memoria, backend, contesto, tool call, stabilità.

SWE-bench Pro diventa quindi un modo per spostare la domanda da:

quanti token al secondo fa questo modello?

A:

questo modello, in questa configurazione, riesce davvero a portare a casa patch corrette su task realistici?

Sono due domande molto diverse.

Il percorso pratico: prima validare il verificatore

Una volta scaricato il progetto del benchmark da GitHub, la prima cosa che ho fatto non è stata generare patch con un modello locale.

Prima ho voluto verificare che il sistema di valutazione funzionasse.

Per farlo ho usato le gold patch, cioè le patch ufficiali associate alle istanze del benchmark. L’idea è semplice: se applico la patch corretta e l’evaluator non la riconosce come corretta, il problema non è il modello. È il benchmark setup.

Ho quindi preparato:

• il CSV con le istanze pubbliche;
• il JSON con le gold patch;
• subset piccoli da 1, 10 e poi 73 casi;
• l’esecuzione locale dell’evaluator con Docker.

Questo passaggio è stato fondamentale, perché ha fatto emergere subito problemi locali legati a disponibilità di spazio disco assegnato alla macchina virtuale, permessi e SELinux.

Poi generare patch con un modello locale

Per generare patch ho usato mini-swe-agent, collegato a un modello locale esposto tramite API compatibile OpenAI.

Il modello del primo esperimento è stato Qwen3.6 35B A3B, quantizzato a 6 bit (KV-cache a 8 bit), servito localmente tramite LM Studio. Non è una scelta pensata per battere una leaderboard. È una scelta utile per iniziare a testare una pipeline locale con un modello openweight realistico per il mio hardware.

Anche qui, però, le cose non hanno funzionato al primo colpo e hanno richiesto migliorie allo script di esecuzione e file di configurazione per tool calling text-based, indicare il percorso corretto dove trovare le working directory nelle immagini Docker, …

Il primo risultato: una patch vera, ma non corretta

Dopo questi aggiustamenti, la pipeline ha prodotto finalmente una patch non vuota.

Questo, da solo, era già un risultato.

La patch è stata convertita nel formato atteso dall’evaluator SWE-bench Pro e validata con lo stesso meccanismo usato per le gold patch.

Il task scelto era un caso NodeBB relativo alla gestione dello stato di validazione email nell’Admin Control Panel e nella logica di conferma.

La patch generata dal modello non ha passato il benchmark.

E non è sorprendente.

Il punto interessante è che non ha fallito per un problema infrastrutturale. La patch si applicava, i test partivano, NodeBB veniva avviato, e la suite selezionata arrivava a un risultato concreto: 300 test eseguiti, 297 passati e 3 falliti.

Questo è esattamente il tipo di fallimento utile.

Non “non funziona niente”.

Ma:

il modello ha prodotto una patch plausibile, applicabile, ma semanticamente incompleta o sbagliata.

Nel caso specifico, la modifica sembrava troppo locale e probabilmente non affrontava davvero il problema più ampio della validazione email e del fallback sui dati scaduti o mancanti.

Questo è il tipo di dato che voglio raccogliere nei prossimi esperimenti: non solo quanti task passano, ma come falliscono quelli che non passano.

Cosa ho imparato fin qui

Questa prima fase mi ha confermato alcune cose.

La prima: eseguire SWE-bench Pro in locale è possibile, ma non è un comando magico. Serve trattarlo come un vero sistema sperimentale.

La seconda: prima di misurare i modelli bisogna validare l’infrastruttura. Le gold patch sono indispensabili per capire se il verificatore funziona.

La terza: gli errori più fastidiosi non arrivano necessariamente dal modello. Possono arrivare da Docker, SELinux, entrypoint, working directory, immagini non adatte allo scaffold dell’agente, parser dei tool o limiti di spazio disco.

La quarta: un benchmark di coding agent non misura solo il modello. Misura l’intero sistema:

• modello;
• quantizzazione;
• backend di inferenza;
• prompt;
• agente;
• tool calling;
• container;
• test harness;
• timeout;
• parser dell’output;
• strategia di retry.

Questo rende i risultati più difficili da interpretare, ma anche molto più interessanti.

Perché questo conta per la quantizzazione

Il motivo per cui mi interessa davvero eseguire SWE-bench Pro in locale è la quantizzazione.

Quando si usano modelli openweight su hardware consumer, la quantizzazione non è un dettaglio tecnico. È spesso ciò che rende possibile o impossibile usare un certo modello.

Ma la domanda importante non è solo:

quanto è veloce Q4 rispetto a Q6?

La domanda è:

quanto perde Q4 in capacità agentica rispetto a Q6 o Q8?

Un modello quantizzato più aggressivamente può essere abbastanza buono in chat, ma fallire più spesso quando deve:

• mantenere coerenza su molti step;
• leggere output lunghi;
• produrre patch precise;
• evitare modifiche inutili;
• seguire istruzioni rigide;
• non perdersi nella logica di una codebase reale.

SWE-bench Pro permette di iniziare a misurare proprio questo.

Non perfettamente. Non senza rumore. Non senza problemi di contaminazione sul public set.

Ma in modo molto più concreto di un semplice confronto di token al secondo o di score sintetici.

Prossimi passi

Questo post non contiene ancora una tabella di risultati.

Volutamente.

Prima volevo raccontare il metodo, i problemi incontrati e il motivo per cui secondo me vale la pena fare questo tipo di esperimento.

I prossimi passi saranno:

1. selezionare un subset più ragionato dei 731 task pubblici;
2. classificare i task per linguaggio, repository e dimensione della gold patch;
3. eseguire più modelli o più quantizzazioni con lo stesso scaffold;
4. distinguere i fallimenti infrastrutturali dai fallimenti del modello;
5. confrontare non solo il pass rate, ma anche i tipi di errore.

Solo a quel punto avrà senso parlare di numeri.

Per ora il risultato è più modesto, ma importante: la pipeline locale funziona. Il modello locale produce patch. L’evaluator le valida. E i fallimenti iniziano a essere informativi.

Per il resto… servirà tempo ;-)

Il modello deve leggere istruzioni, file, cronologia della conversazione, output dei tool, porzioni di codice e magari anche parti del progetto ripetute più volte nel contesto. In quei casi, il problema non è tanto “quanto velocemente scrive”, ma “quanto costa fargli rileggere tutto”.

Questo articolo, però, parla di un’altra fase della pipeline: la generazione vera e propria, cioè il momento in cui il modello produce la risposta token dopo token.

Le due cose non sono in contraddizione. Sono problemi diversi.

Il prefill si affronta con ottimizzazioni come riuso della KV-cache, prefix caching, gestione più intelligente del contesto, riduzione del prompt, attenzione più efficiente e, in alcuni casi, quantizzazione della KV-cache. Lo speculative decoding, invece, prova ad accelerare soprattutto la fase successiva: quella in cui il modello ha già letto il contesto e deve iniziare a scrivere.

E questa fase può diventare un problema, soprattutto quando si usano modelli locali densi, grandi e qualitativamente interessanti, ma non velocissimi in generazione.

Nel mio caso un modello da testare è sicuramente Qwen3.6 27B, denso, interessante per attività di coding, ma non esattamente un fulmine quando deve generare molti token su hardware locale. Ho una macchina basata su AMD Ryzen AI Max+ 395 con 128GB di memoria unificats, quindi posso caricare anche modelli relativamente importanti, ma questo non significa automaticamente avere una velocità di decode paragonabile a quella di un servizio cloud.

Da qui nasce l’interesse per lo speculative decoding, inteso come tassello nello stack di ottimizzazioni che rendono sempre più praticabile l’uso locale di modelli avanzati.

L’idea dello speculative decoding

Lo speculative decoding è una famiglia di tecniche che prova ad accelerare la generazione facendo una cosa apparentemente semplice: qualcuno prova a indovinare i prossimi token, e il modello principale verifica se vanno bene.

La versione più intuitiva è questa:

1. un modello piccolo e veloce, chiamato spesso draft model, propone una sequenza di token;
2. il modello principale, più grande e più lento, controlla quella sequenza;
3. i token compatibili con quello che il modello principale avrebbe prodotto vengono accettati;
4. quando la previsione sbaglia, il modello principale riprende il controllo.

Il punto importante è che il modello piccolo non decide davvero la risposta. Propone soltanto una bozza. Il modello principale mantiene il diritto di veto.

Una formulazione semplice potrebbe essere:

Il draft model non sostituisce il modello grande. Cerca solo di anticiparlo.

Se il draft model indovina spesso, il sistema può evitare parte del lavoro token-by-token e generare più velocemente. Se invece indovina poco, il vantaggio si riduce o sparisce.

La documentazione di llama.cpp descrive proprio il draft model come l’approccio più comune allo speculative decoding: un modello molto più piccolo genera draft che vengono poi verificati dal modello principale. La stessa documentazione elenca anche implementazioni senza draft model, tra cui varianti basate su n-gram.

Perché se ne parla proprio ora

Lo speculative decoding non è un’idea nata ieri. La cosa interessante è che sta diventando più accessibile negli strumenti che molte persone usano davvero per l’inferenza locale.

Da un lato ci sono applicazioni come LM Studio, che permettono di attivare speculative decoding in modo relativamente semplice e, cosa molto utile dal punto di vista didattico, mostrano visivamente i token proposti dal draft model e accettati dal modello principale. LM Studio ha documentato questa funzionalità spiegando che il draft model deve essere compatibile con il modello principale, in particolare lato vocabolario/tokenizer.

Dall’altro lato c’è llama.cpp, che nelle versioni recenti sta sperimentando varie forme di speculative decoding, incluse modalità con draft model e modalità n-gram. La documentazione attuale di llama.cpp elenca più implementazioni per llama-server, tra cui draft, ngram-cache, ngram-simple, ngram-map-k e ngram-mod.

Questo è rilevante perché, con modelli recenti come Qwen3.5 e Qwen3.6, il supporto e le combinazioni praticabili sono in evoluzione rapida. Una PR recente di llama.cpp (#19493) ha ad esempio abilitato il draft-model speculative decoding per i modelli Qwen3.5/3.6 MoE (Mixture of Experts), aprendo la strada a nuovi esperimenti.

Questo spiega anche una differenza pratica importante: in LM Studio oggi la demo più semplice può richiedere coppie di modelli più vecchie o già supportate, mentre usando direttamente una versione recente di llama.cpp si possono fare esperimenti più avanzati con Qwen3.5/Qwen3.6.

LM Studio usa llama.cpp come backend in molti casi, ma non espone necessariamente subito ogni funzionalità appena arrivata upstream. Per questo ha senso fare due esempi separati: uno in LM Studio per capire visivamente il meccanismo, e uno in llama.cpp per un caso più vicino al mio workflow reale.

Demo 1: vedere speculative decoding in LM Studio

La prima demo che voglio usare nell’articolo non serve a dimostrare il massimo speedup possibile. Serve a far vedere il concetto.

Il setup è questo:

• applicazione: LM Studio;
• modello principale: Qwen 3 14B;
• draft model: Qwen 3 0.6B;
• speculative decoding abilitato;
• visualizzazione dei token accettati dal draft model attiva.

Chiaramente non scelgo questa coppia perché sia lo stato dell’arte per il coding locale. La scelgo perché, nel mio setup, è una delle combinazioni che LM Studio permette di usare facilmente per mostrare il meccanismo.

La cosa interessante è la visualizzazione: durante la generazione, LM Studio può evidenziare i token proposti dal draft model e accettati dal modello principale. Dal punto di vista didattico è molto efficace, perché trasforma un concetto un po’ astratto in qualcosa che si vede davvero.

Vediamo dunque come la risposta ad un prompt direttamente nella console di LMStudio viene servita Qwen3 14B generando in media attorno ai 14 token/s.

Una volta attivato speculative decoding molti token (in verde qui sotto) vengono correttamente indovinati dal modello draft Qwen 3 0.6B, portando ad una generazione media attorno ai 24 token/s.

Quello che voglio mostrare è semplice:

• il draft model prova a generare token in anticipo;
• il modello principale li verifica;
• alcuni token vengono accettati;
• più token vengono accettati, più il meccanismo può diventare utile;
• quando il draft model non indovina, il vantaggio si riduce.

Questa demo è utile soprattutto per capire una cosa: speculative decoding non è “il modello piccolo che risponde al posto di quello grande”. È più simile a un assistente che prova a completare le frasi, mentre il modello grande controlla che il completamento sia corretto.

Il limite della demo in LM Studio

La demo in LM Studio è bella perché rende visibile il meccanismo. Ma non rappresenta necessariamente un caso d’uso reale attuale.

In particolare mi interessa soprattutto capire se queste tecniche possono aiutare quando uso un modello locale moderno e più pesante per attività di coding.

Uno scenario rappresentativo è dunque simile a questo:

• modello denso;
• buona qualità su codice;
• generazione non velocissima;
• task di refactoring o modifica di una codebase reale;
• output lungo abbastanza da rendere percepibile la differenza.

Per questo la seconda demo usa un approccio diverso: Qwen3.6 27B con llama.cpp e speculative decoding basato su n-gram.

Draft model e n-gram: due strade diverse

Nel primo esempio abbiamo visto la forma più intuitiva di speculative decoding: un secondo modello, più piccolo, propone token.

Ma non è l’unica possibilità.

In llama.cpp esistono anche approcci “draftless”, cioè senza un vero draft model separato. Tra questi ci sono le modalità basate su n-gram.

Un n-gram, semplificando, è una sequenza di token. L’idea è cercare sequenze già viste nel prompt o nella generazione corrente e usarle per proporre i token successivi.

Invece di chiedere a un modello piccolo “secondo te cosa viene dopo?”, il sistema fa qualcosa di più meccanico:

Ho già visto una sequenza simile nel contesto. Dopo quella sequenza, quali token venivano? Proviamo a proporli anche qui.

Questo approccio ha caratteristiche diverse dal draft model.

La documentazione di llama.cpp indica che le implementazioni con draft model possono essere combinate con implementazioni senza draft model, e mostra anche esempi in cui ngram-mod viene usato insieme a un draft model.

Per il mio secondo esempio, però, l’interesse principale è proprio valutare l’approccio n-gram, perché non richiede di caricare un altro modello e perché il codice è un dominio in cui la ripetizione è spesso molto forte.

Perché n-gram ha senso nel codice

Nel testo creativo, ogni frase può essere nuova. In un refactoring di codice, ad esempio Java, invece, moltissime parti dell’output sono prevedibili o assomigliano a qualcosa che è già nel contesto.

Pensiamo a una classe Java reale. Dentro potremmo trovare:

• dichiarazioni di package;
• import;
• annotazioni;
• firme di metodi;
• nomi di classi già presenti;
• nomi di variabili ricorrenti;
• pattern di logging;
• strutture try/catch;
• chiamate a servizi;
• test simili;
• blocchi ripetuti con piccole variazioni.

Quando chiediamo a un modello di fare refactoring, spesso non gli stiamo chiedendo di inventare tutto da zero. Gli stiamo chiedendo di riconoscere una struttura, modificarla, ripeterla in modo coerente e adattarla.

Questo è esattamente il tipo di situazione in cui un approccio basato su n-gram può avere senso, non perché capisca il codice, ma perché il codice contiene molte sequenze che ritornano.

Demo 2: refactoring Java con Qwen3.6 27B e llama.cpp

Ho dunque configurato Claude Code per utilizzare in inferenza un modello Qwen3.6 27B servito da una versione recentissima di llama.cpp, così da disporre delle ultime patch e poter attivare con successo n-gram speculative decoding.

Il task prevedeva di fare refactoring di una classe di diverse centinaia di righe di codice, deprecando tutti i metodi e delegando ad una nuova versione in cui la logica della classe stessa fosse mantenuta ma il codice fosse ri-organizzato e modernizzato con pattern più idiomatici. Altri task che si sarebbero prestati a questo test avrebbero potuto coinvolgere ad esempio:

• semplificazione di una classe troppo lunga;
• aggiunta o riorganizzazione di test;
• separazione di responsabilità tra metodi;
• estrazione di logica duplicata in metodi privati.

Ho eseguito lo stesso refactoring anche senza speculative decoding; lo scopo chiaramente era quello di capire se la tecnica permettesse veramente di recuperare del tempo in fase di generazione.

Perché Qwen3.6 27B

Qwen3.6 27B è interessante perché rappresenta bene una categoria di modelli che, su AMD Strix Halo, sono allo stesso tempo desiderabili (essendo densi, ben si prestano a coding e ragionamento con agenti) e accettabili in fase di prefill ma estremamente lenti in generazione (di nuovo perché densi).

Desiderabili perché un modello denso di questa taglia può essere molto interessante per coding, ragionamento tecnico e agenti locali. Quindi speculative deconding diventa una possibile soluzione per rendere più fluido l’utilizzo di un buon modello altrimenti inadatto.

Esecuzione

Ho specificato questi parametri nel avviare llama-server

--draft-min 4 --draft-max 16 --spec-ngram-size-n 12 --spec-type ngram-mod

in sostanza controllando le dimensioni dei gruppi di token da pescare (e provare ad usare) dalle generazioni precedenti e contesto.

Nei log ho visto varie statistiche sull’utilizzo di ngram-mod, in particolare verso la fine del test

statistics ngram_mod: #calls(b,g,a) = 43 10790 883, #gen drafts = 884, #acc drafts = 883, #gen tokens = 13766, #acc tokens = 7096, dur(b,g,a) = 145.503, 393.013, 64.153 ms

Rispetto alla baseline senza speculative decoding, l’esecuzione ngram ha permesso di risparmiare circa 5 min a fronte degli oltre 27 richiesti dal sistema per completare il refactoring.

Va detto che in realtà il modello ha generato molto meno codice “ripetuto” di quanto ci si potesse aspettare perché Claude Code ha fatto uso intelligente dei tool di cui disponeva, ad esempio per effettuare sostituzioni di testo in modo deterministico e efficiente.

Come leggere il risultato senza farsi ingannare

Speculative decoding è una tecnica facile da fraintendere.

Un errore comune è guardare solo quanti token sono stati accettati dal draft o dall’n-gram e concludere che allora il sistema è sicuramente più veloce. Non è detto.

Il risultato netto dipende da vari fattori:

• quanto costa generare i draft;
• quanto costa verificarli;
• quanto spesso vengono accettati;
• quanto è lungo l’output;
• quanto è ripetitivo il testo;
• quale parte della pipeline è davvero il collo di bottiglia;
• quanto è efficiente l’implementazione nel backend;
• che hardware stiamo usando.

Se il problema principale è il prefill, speculative decoding non risolve il problema principale.

Se il modello genera già molto velocemente, il guadagno percepito può essere marginale.

Se il testo è poco ripetitivo, n-gram può aiutare poco.

Se invece il modello è lento in generazione e deve produrre molto codice strutturato, allora anche un guadagno parziale può cambiare la percezione d’uso.

È importante anche ricordare che i risultati variano molto. Ci sono test recenti su Qwen3.6-35B-A3B (un modello MoE) con RTX 3090 in cui varie configurazioni di speculative decoding non hanno prodotto uno speedup netto rispetto alla baseline. È utile però notare che quel risultato riguarda un’architettura MoE, che ha dinamiche diverse rispetto a un modello denso come il 27B usato qui.

Questo non significa che speculative decoding “non funzioni”. Significa che non è una funzione magica da attivare aspettandosi automaticamente il doppio dei token al secondo. Nel mio caso il test ha mostrato come si possa ottenere un miglioramento con il modello Qwen3.6 27B, ma probabilmente non tale da preferirlo ad un genericamente ben più veloce modello MoE come il Qwen3.5 122B A10B.

Resta il fatto che la ricerca attorno queste tecniche di ottimizzazione è super interessante e non è da escludere che nuovi algoritmi ed implementazioni ribaltino le conclusioni derivate da queste prove.

Introduzione

Negli ultimi mesi il numero di modelli eseguibili in locale per coding agent è cresciuto rapidamente: gpt-oss 20B e 120B, Qwen3-Coder, Qwen3-Coder-Next, GLM 4.5-Air, 4.6-Flash, 4.7-Flash sono solo alcuni esempi.

Se si dispone di una macchina con parecchia memoria – nel mio caso un AMD Ryzen AI Max+ 395 con 128GB di RAM unificata – la tentazione è semplice: verificare quanta memoria serve e scegliere il modello più grande che “ci sta”.

In pratica, però, la scelta è molto più sottile quando lo usecase non è un semplice chatbot. Per un coding agent la velocità diventa subito un aspetto critico, e la velocità non è un numero unico. In questo post provo a descrivere un possibile metodo di analisi basato su llama-bench, concentrandomi sugli aspetti di performance su singola richiesta.

Prompt processing speed e token generation speed

Quando si misura la velocità di un LLM locale, si guardano in genere due grandezze:

• Prompt processing speed (pps): quanti token al secondo il modello riesce a processare quando riceve un prompt.
• Token generation speed (tgs): quanti token al secondo riesce a generare in output.

Le due fasi sono molto diverse. Durante il prompt processing il modello deve leggere tutto il contesto (system prompt, file di codice, diff, tool output, cronologia) e costruire la KV cache. Solo dopo inizia la generazione token per token.

Nei grafici che seguono trovi le metriche pp512 e tg128:

• pp512 è la velocità media nel processare blocchi da 512 token.
• tg128 è la velocità media nel generare 128 token.

Sono valori standardizzati che permettono confronti coerenti tra modelli e backend diversi.

Ambiente di test

I test sono stati eseguiti su:

• AMD Ryzen AI Max+ 395 (Strix Halo)
• 128GB di memoria unificata
• llama.cpp build: ff4affb4c (8067)
• backend:
  • ROCm 7.2
  • Vulkan (RADV)

ROCm è lo stack ufficiale AMD per il calcolo GPU basato su HIP. Vulkan, nel caso di Mesa RADV, è il driver open source che permette di usare la GPU via API Vulkan anche per workload compute. llama.cpp supporta entrambi, ma le differenze di comportamento possono essere significative, anche a parità di hardware.

Ho selezionato quattro modelli che ritengo interessanti per l’inferenza nel mio ambiente: la coppia di modelli gpt-oss da 20B e 120B che già avevo presentato in passato, GLM 4.7-Flash ossia la versione leggera (classe 30B) di quello che è stato il modello state-of-the-art di Z.ai fino a qualche giorno fa, e Qwen3-coder-next recentemente rilasciato da Qwen specificatamente per utilizzo con coding agents.

Conscio delle differenze in termini di qualità dei risultati ottenibili (che non sono però oggetto di discussione diretta in questo post) e dei diversi requisiti di memoria per le quantizzazioni prescelte, mi sono focalizzato sulle performance velocistiche.

1) Dimensione del contesto: il parametro -d

Ho eseguito i test con:

-d 0,8192,16384,32768,65536,131072

Il parametro -d in llama-bench simula la profondità del contesto, cioè il numero di token già presenti nella KV cache prima della misurazione. In altre parole, misura come si comporta il modello quando deve lavorare con 8k, 16k, 32k, 64k o 128k token già in memoria.

Questo è un punto fondamentale. I benchmark a contesto quasi nullo sono poco rappresentativi per un coding agent reale. Strumenti come Claude Code aggiungono molto contesto: file interi, diff, output dei tool, cronologia della conversazione. Ci vuole poco a superare i 50k-100k token.

Guardiamo ad esempio il comportamento con backend Vulkan.

Prompt processing (Vulkan)

Token generation (Vulkan)

E lo stesso con ROCm:

Prompt processing (ROCm)

Token generation (ROCm)

Si osserva chiaramente che sia pp512 sia tg128 degradano all’aumentare del contesto. La cosa interessante non è solo il valore assoluto, ma la pendenza della curva. Alcuni modelli partono veloci ma degradano rapidamente; altri mantengono un comportamento più stabile.

2) Testare con la stessa configurazione reale

Un errore frequente è eseguire benchmark con una configurazione e poi usare un’altra in produzione.

Se per l’inferenza userai llama-server con:

• un certo numero di layer in VRAM (-ngl)
• una specifica configurazione di flash-attention
• una determinata quantizzazione
• un backend preciso (ROCm o Vulkan)

allora llama-bench va eseguito nelle stesse condizioni. Altrimenti si stanno misurando numeri che non riflettono l’uso reale.

3) Le quantizzazioni non si comportano tutte allo stesso modo

Non basta guardare il numero di bit. Una quantizzazione può essere teoricamente più compatta o più veloce, ma non sfruttare in modo ottimale la precisione supportata dalla GPU o la gerarchia di memoria.

In pratica, alcune quantizzazioni risultano più memory-bound su certe architetture, mentre altre scalano meglio al crescere del contesto. Anche qui, l’unico modo serio per decidere è testare sul proprio hardware.

4) ROCm vs Vulkan: differenze concrete

Un confronto diretto tra ROCm e Vulkan per gpt-oss mostra differenze non solo nei valori assoluti, ma anche nel modo in cui le prestazioni decadono con contesti grandi.

Prompt processing: ROCm vs Vulkan

Token generation: ROCm vs Vulkan

Un backend può essere più veloce a contesto piccolo ma degradare più rapidamente oltre i 32k o 64k token. Questo è particolarmente rilevante per i coding agent, dove il contesto tende a crescere rapidamente.

Perché, per un coding agent, il prompt processing conta più della generazione

Nel caso di un coding agent, il tempo speso nel processare il prompt è spesso predominante. Ogni volta che l’agente rilegge file, integra output di tool o ricostruisce il contesto dopo una tool call, il modello deve rieseguire la fase di prefill su un contesto potenzialmente molto grande.

La generazione, invece, spesso produce poche centinaia di token.

Se un modello degrada poco in token generation ma crolla in prompt processing oltre i 64k token, l’esperienza complessiva sarà comunque lenta. Al contrario, un modello con generazione leggermente più lenta ma con un prompt processing stabile su contesti grandi può risultare più reattivo nell’uso reale.

Nel mio caso specifico

Limitandoci a:

• richieste singole (niente concorrenza tra più client)
• parametri coerenti con la configurazione reale
• contesti fino a 128k token
• backend ROCm e Vulkan

tra i modelli testati (gpt-oss 20B, gpt-oss 120B, GLM 4.7-Flash, Qwen3-Coder-Next) il miglior compromesso complessivo, guardando in particolare al comportamento del prompt processing su contesti grandi, risulta essere Qwen3-Coder-Next.

Questo non significa che sia “il migliore in assoluto”. Non ho considerato:

• carichi concorrenti con più thread o client
• impatto di KV cache condivisa
• misure end-to-end con tool call reali
• qualità delle risposte in modo sistematico

Ma come primo filtro tecnico, un’analisi di questo tipo è molto più informativa del semplice confronto sulla dimensione del modello o sui token al secondo a contesto nullo.

Conclusione

Quando si sceglie un modello locale per un coding agent, limitarsi a verificare che “entri in memoria” è riduttivo.

Ha più senso:

1. misurare sia prompt processing sia token generation;
2. analizzare il decadimento al crescere del contesto;
3. usare la stessa configurazione che si adotterà in inferenza;
4. confrontare backend e quantizzazioni sul proprio hardware.

Nel caso dei coding agent, la partita si gioca spesso nella fase di prompt processing. È lì che si accumula la latenza maggiore e dove le differenze tra modelli diventano evidenti.

Il resto, come sempre, va validato sul proprio caso d’uso reale.

Introduzione

Nel mondo dell’AI generativa siamo ormai abituati a pensare in termini di prompt testuali e immagini generate, ma sempre più spesso il confine tra testo e immagine diventa bidirezionale.
Da un lato chiediamo a un modello di creare immagini a partire da parole (T2I, text-to-image), dall’altro iniziamo a usare modelli capaci di capire immagini e tradurle in testo (I2T, image-to-text).

È proprio in questo spazio ibrido che entrano in gioco i modelli Vision-Language (VL), e che nasce l’esperimento di cui parlerò in questo post: un workflow reale, eseguito in locale, che combina comprensione visiva, meta-prompting e generazione fotorealistica, senza dimenticare una riflessione necessaria sui diritti delle immagini generate.

Cosa sono i modelli Vision-Language (VL) e perché sono importanti

I modelli Vision-Language sono modelli multimodali in grado di elaborare immagini e testo nello stesso spazio semantico.
Non si limitano a “vedere” un’immagine, ma sono in grado di:

• descriverla in linguaggio naturale
• rispondere a domande sul suo contenuto
• estrarne dettagli strutturati
• usarla come contesto per ragionamenti più complessi

Questa capacità li rende fondamentali non solo per applicazioni “creative”, ma anche per analisi, automazione, accessibilità e controllo qualità.

Qwen3-VL

Tra i modelli VL più interessanti emersi di recente c’è Qwen3-VL, sviluppato dal team Qwen di Alibaba.
Il motivo principale per cui è rilevante per questo blog non è solo la qualità delle descrizioni, ma un aspetto molto concreto:

Qwen3-VL è open-weight.

Questo significa che:

• può essere eseguito in locale
• può essere integrato in workflow personalizzati (ad esempio in ComfyUI)
• consente sperimentazione reale, senza dipendere da API proprietarie

Rispetto a modelli come Gemini 3 o GPT-4o, Qwen3-VL eseguito in locale mostra limiti evidenti sul piano della conoscenza generale e del ragionamento avanzato, ma sul piano pratico della descrizione visiva è piuttosto solido, soprattutto se guidato con prompt ben progettati.

Z-Image e Z-Image Turbo: velocità, fotorealismo e open source

Se Qwen3-VL copre il lato I2T, serve poi un modello capace di trasformare testo in immagini con qualità elevata.
Qui entra in gioco Z-Image, in particolare la sua variante Turbo.

Z-Image Turbo ha due caratteristiche che lo rendono estremamente interessante:

1. È open source / open weight, disponibile su GitHub e Hugging Face
2. È estremamente efficiente, nonostante una dimensione di circa 6 miliardi di parametri

Nei test pratici Z-Image Turbo si distingue per:

• velocità di generazione molto elevata
• uso contenuto di VRAM
• fotorealismo notevole, soprattutto su soggetti umani e scene realistiche

È importante chiarire che non tutti i modelli Z-Image sono open source: in particolare le varianti base (non-distilled) e edit (image-to-image avanzato) non sono ancora rilasciate in forma open.
Questo è uno dei motivi per cui l’esperimento descritto in questo post passa volutamente dal testo, invece che da un vero flusso I2I.

Un workflow ComfyUI: da immagine a prompt, da prompt a nuova immagine

A questo punto abbiamo i due mattoni fondamentali:

• Qwen3-VL per analizzare un’immagine e produrre un prompt testuale
• Z-Image Turbo per generare una nuova immagine a partire da quel testo

Per realizzare il workflow, sono partito da alcuni esempi realizzati da Pixaroma e condivisi sul relativo canale Discord. Su Youtube sono disponibili interessanti tutorial (in particolare Ep 71 e Ep 72 sono rilevanti in questo caso) che comprendono anche tutti i link alle varie risorse. In ogni caso, il workflow eseguito segue sostanzialmente questa logica:

1. immagine di input
2. nodo Qwen3-VL → descrizione testuale
3. eventuale modifica / miglioramento del prompt
4. flusso T2I basato su Qwen3 + Z-Image Turbo

L’idea è quella di prendere ispirazione da un’immagine esistente per generarne una nuova, simile ma non identica.

Questo si collega direttamente al filo conduttore di Aladino Digitale: la lampada è l’AI, il desiderio è il prompt — e se il desiderio è formulato male, il risultato può essere molto diverso da quello sperato.

Usare un modello VL per ottenere un primo prompt “ben fatto” consente di:

• superare difficoltà linguistiche
• partire da una descrizione semanticamente ricca
• concentrarsi sugli elementi davvero salienti

Inoltre, il risultato finale non è una copia, ma una nuova immagine:
potenzialmente più libera da vincoli, e facilmente adattabile a:

• formati diversi (verticale, orizzontale, social-first)
• cambi di stile
• reinterpretazioni fotorealistiche di immagini stilizzate o cartoon

Questo approccio è una sorta di surrogato dei modelli edit, in attesa che Z-Image Edit venga rilasciato in forma open.

Focus: il nodo custom QwenVL in ComfyUI

Uno degli elementi chiave del workflow è il nodo custom ComfyUI-QwenVL.

Questo nodo permette di interrogare Qwen3-VL con diversi preset_prompt, ovvero prompt predefiniti pensati per ottenere descrizioni con livelli di dettaglio differenti.

Per avere un’idea di come il modello Qwen3-VL venga interrogato dal nodo di ComfyUI, tra i file di configurazione si possono leggere i prompt completi per i vari Preset (in particolare Simple Description, Detailed Description, Ultra Detailed Description, Cinematic Description e Detailed Analysis che useremo più avanti):

La differenza tra i risultati ottenibili con questi preset non è solo quantitativa (più o meno parole), ma qualitativa: cambia il tipo di attenzione che il modello dedica a composizione, luce, soggetti, atmosfera.

Un aspetto particolarmente potente è la possibilità di definire nuovi preset, semplicemente aggiungendo prompt personalizzati in un file di configurazione.
Questo apre la porta a un controllo artistico molto fine: ad esempio, enfatizzare outfit, materiali, espressioni o elementi narrativi specifici.

Un miglioramento interessante — che non escludo di implementare con una PR — sarebbe consentire l’output in formato JSON, così da meglio separare semanticamente elementi come soggetto, ambiente, stile e illuminazione.

Setup sperimentale e immagine di test

E’ dunque giunto il momento di provare il workflow presentato. Ho selezionato l’immagine di riferimento da usare per i test attingendo dal portfolio di Milagro:

Le prove sono state eseguite interamente in locale, sulla mia macchina basata su AMD Strix Halo, senza ricorrere ad API cloud o servizi esterni. Al solito, questo è un aspetto importante: al netto del non determinismo AI, l’esperimento è riproducibile e non dipende da infrastrutture proprietarie.

Ho configurato Z-Image Turbo (versione con precisione bf16) perché generasse immagini da 2.25 MP (1536 x 1536) in 5 step con sampler dmpp_sde e scheduler beta; per tutti gli altri elementi della configurazione (inlcuso Qwen3 4B come text encoder per processare i prompt) ho mantenuto i valori di default del workflow.

💡 Suggerimento:
ComfyUI salva di default il workflow completo utilizzato per la generazione delle immagini dentro i metadata dell’immagine stessa. Puoi dunque importare alcune delle immagini che trovi qui sotto (la versione .png in alta risoluzione) dentro la tua installazione di ComfyUI e rieseguire facilmente i test.

In termini di tempi di esecuzione sulla mia macchina, il flusso completo ha richiesto circa un minuto e mezzo, diviso grossomodo in 30 secondi per la parte I2T (Qwen3-VL che genera il testo a partire dall’immagine in input) e un minuto per la parte T2I (quasi completamente spesi in fase di sampling, circa 11~12 secondi a step). I tempi di generazione dell’immagine dipendono fortemente dalla dimensioni dell’immagine richiesta e dunque dalla memoria allocata nello spazio latente; sul mio hardware, scendendo a 1MP di risoluzione (1024 x 1024) i tempi di generazione si riducono ad un terzo, circa 20 secondi.

Prove con i diversi preset

Per cominciare, ho eseguito varie prove configurando il nodo QwenVL affinché utilizzasse il modello Qwen3-VL-Instruct da 4 miliardi di parametri con numero massimo di token pari a 2048 (così da evitare troncamenti) e differenti preset.

Qwen3-VL-4B-Instruct con Simple Description

La descrizione testuale generata con il preset Simple Description rispecchia le attese (una singola frase concisa), fa riferimento a due auto Porsche di colore corretto e fornisce alcune indicazioni di massima riguardo la scena, il paesaggio e il meteo.

Two classic Porsche sports cars—a black 911 Turbo and a white 911—parked on an asphalt lot against a backdrop of rugged mountains under a dramatic, cloudy sky at dusk.

L’immagine generata a partire dal testo, utilizzato come prompt, ne segue le indicazioni correttamente: abbiamo due classiche Porsche 911, il riferimento al parcheggio porta ad avere strisce bianche a terra, le montagne e il cielo sono realistici ma necessariamente differenti da quanto osservabile nell’immagine di riferimento.

Qwen3-VL-4B-Instruct con Detailed Description

La modalità Detailed Description dovrebbe produrre un paragrafo dettagliato di 2-3 frasi che combini aspetti quali soggetto, azione, ambientazione, composizione / illuminazione e mood dell’immagine. Nel nostro caso otteniamo:

Under a vast, moody sky streaked with twilight hues of orange and gray, two iconic Porsche sports cars—a sleek black modern model and a classic white vintage coupe—rest side by side on an asphalt overlook, their polished surfaces reflecting the fading light as distant mountains loom behind them; the scene exudes quiet power and timeless elegance, capturing a moment where engineering heritage meets contemporary performance against nature’s dramatic backdrop.

Il linguaggio è sicuramente più ricco rispetto al preset Simple, l’abbondante uso di aggettivi contribuisce a definire meglio l’atmosfera e l’emozione che l’immagine dovrebbe trasmettere; inoltre viene recepito il fatto che le auto sono due modelli differenti, per Qwen la nera più moderna e la bianca classica / vintage. L’immagine generata a partire dal testo è effettivamente un po’ più espressiva, ad esempio per i colori del cielo. Abbiamo sempre le strisce bianche sull’asfalto.

Qwen3-VL-4B-Instruct con Ultra Detailed Description

Il passaggio al preset Ultra Detailed Description, il cui prompt richiede una descrizione estremamente ricca che punti ad una rappresentazione immersiva, porta ad un testo generato di una decina di periodi. Se da un lato il modello coglie dettagli estetici dei veicoli, le luci accese di uno dei due, etc., dall’altro sembra quasi lanciarsi in interpretazioni al limite del filosofico sul significato dell’immagine. Da un punto di vista linguistico, il testo prodotto è comunque ben oltre quanto un umano (nativo nella lingua prescelta) avrebbe realisticamente scritto per descrivere un’immagine.

The scene unfolds like a cinematic still from a high-end automotive drama—two Porsche legends poised against nature’s grandeur under a sky that whispers of twilight’s final sigh.

Dominating the left foreground is a matte-black 1990s-generation Porsche 911 (likely a Turbo or Carrera RS variant), its glossy surface absorbing ambient light yet reflecting it with deep, velvety intensity. The car's bodywork gleams subtly as if kissed by moonlight—or perhaps dawn’s last blush—that bleeds across the horizon. Its aerodynamic curves are sculpted into aggression: sharp lines along the fenders taper to muscular wheel arches housing multi-spoke alloy wheels polished to mirror-like perfection; each spoke catches the fading glow, casting faint geometric reflections onto the asphalt below. A prominent rear spoiler flares upward, hinting at hidden power beneath this sleek shell. Headlights illuminate softly—their circular halos glowing amber-yellow—as though ready to pierce darkness before they’ve fully surrendered their duty to dusk. Below them, the front bumper integrates subtle air intakes while maintaining clean elegance. Even the side skirts appear custom-fitted, suggesting performance tuning beyond factory specs—a whispered promise of raw mechanical prowess.

To its right, slightly receding but equally commanding, sits another icon—an immaculate white 1970s-era Porsche 911 coupe. This classic beauty exudes timeless charm through minimalist design language. Its paint job shimmers almost ethereal under soft illumination, catching every contour without glare—even where shadow falls upon it—it retains luminosity thanks to careful lighting management inherent within the composition itself. Along the lower edge runs a thin black stripe bearing “PORSCHE” embossed delicately above the rocker panel line—an elegant signature acknowledging heritage rather than rebellion. Silver-rimmed wheels echo those seen earlier but carry different weight—they feel older, more nostalgic—and paired perfectly with chrome trim accents around windowsills and door handles which glint warmly despite surrounding gloominess. Tail lights blink gently off-key, signaling readiness even now when motion has ceased entirely.

Behind these machines looms a rugged mountain range stretching far into distance. Their slopes rise steeply toward jagged peaks draped lightly in misty haze, covered partially in sparse vegetation clinging tenaciously to rocky outcrops. Bare trees dot sparsely scattered patches near ridgelines, standing sentinel amidst silence. Farther back, layers of hills fade progressively until only silhouettes remain visible against the vastness behind them.

Above all lies the most arresting element —the heavens themselves. Thick clouds swirl lazily overhead, swirling patterns resembling smoke caught mid-motion, darkened grey-blue tones broken intermittently by streaks of pale gold-orange radiance seeping between creases. These wisps form delicate veils over distant horizons where sun dips low enough to cast long fingers of warm color directly downward—not quite sunset per se—but something closer to pre-dusk calmness. Light filters diffusely here, creating gentle gradients instead of harsh contrasts. Shadows stretch dramatically outward from both vehicles’ undersides and edges, elongated due to camera angle combined with time-of-day positioning. They don’t overpower features; instead, they frame forms precisely, enhancing dimensionality and grounding presence firmly among earthbound reality.

As one gazes deeper, attention shifts naturally towards how everything interacts harmonically—with no single object dominating space except perhaps the two Porsches who stand shoulder-to-shoulder atop concrete terrain speckled unevenly with gravel bits and small stones. That pavement feels worn down but sturdy, textured irregularities contrasting sharply with smooth surfaces of cars' bodies. It serves not merely as stage floor but also anchor point anchoring entire universe together visually.

This photograph captures more than mere objects—it encapsulates emotion: awe mixed with reverence. There's quietude amid dynamic energy implied silently by parked state juxtaposed against looming mountains awaiting wind-driven action. One senses anticipation lurking just outside frame boundaries waiting patiently… Perhaps tomorrow morning will bring racing tires gripping tarmac again? Or maybe simply appreciation of craftsmanship etched deeply into metal skin?

In essence, we witness not just automobiles but living sculptures born from engineering genius placed deliberately beside natural splendor—all bathed simultaneously in atmospheric grace whose warmth lingers longer than any engine note ever could. Every curve, hue, texture speaks volumes about artistry fused seamlessly with function. And so does the moment suspended forever—in perfect balance-between human ingenuity and elemental majesty.

In termini di resa fotografica, l’immagine prodotta da Z-Image interpretando (attraverso Qwen3) il prompt qui sopra migliora sicuramente il risultato rispetto ai casi precedenti sia come qualità dei dettagli che come somiglianza all’originale, pur rimanendo comunque distante. Alcuni dei dettagli presenti nel prompt (la scritta PORSCHE sull’auto bianca, ad esempio) risultano mancanti.

Qwen3-VL-4B-Instruct con Cinematic Description

Il prompt associato al preset Cinematic Description richiede la generazione di un paragrafo vivido ed effettivamente nulla da dire in fatto di intensità e coinvolgimento della descrizione qui sotto:

In this cinematic widescreen composition, two legendary Porsche sports cars — a sleek, matte-black 911 Turbo RSR on the left and a pristine white classic 911 Carrera with racing stripes on the right — stand poised like silent warriors against an apocalyptic twilight sky streaked with bruised purples, deep grays, and molten orange near the horizon. The black machine dominates foreground space, its aggressive stance accentuated by custom alloy wheels and lowered suspension; headlights glow warmly, casting sharp reflections across the cracked asphalt that hints at rugged terrain or abandoned airstrip. Behind them, jagged mountain ridges loom under a vast, moody canvas of clouds swirling above, their silhouettes softened yet imposing. As dusk settles, ambient light bathes both vehicles in dramatic chiaroscuro: highlights glint off chrome trim and glossy paintwork while shadows deepen into mystery beneath the chassis. This is not merely photography—it’s theater: tense, reverent, evocative—where mechanical elegance meets raw natural drama. Shot with hyperreal precision but rendered through subtle film grain and selective color grading to mimic high-end cinematography, every curve and crease pulses with narrative weight. A contemplative stillness pervades, inviting viewers to imagine engine revs echoing unseen—or perhaps just silence between legends. It feels less like a photograph and more like a frame from a grand automotive epic set for eternity atop the edge of the world.

I colori, le ombre, etc dell’immagine generata rispecchiano, almeno in parte, la poesia del testo. Chiaramente il preset in questo caso influenza esplicitamente la resa finale, tuttavia complice la tipologia dell’immagine di riferimento, in qualche modo “cinematografica” già di per sè, abbiamo in generale una bella foto.

Qwen3-VL-4B-Instruct con Detailed Analysis

In modalità Detailed Analysis ci si aspetta che il modello VL produca una descrizione dettagliata e strutturata, divisa in sezioni separate per i vari aspetti. Effettivamente il lungo e ricco testo ottenuto isola e approfondisce soggetto, accessori e “estetica”, sfondo e composizione dell’immagine. Otteniamo tanti dettagli sui due veicoli le cui differenze sembrano venire recepite da Qwen3-VL. Inoltre, finalmente abbiamo un’approfondita parte del prompt dedicata alla composizione dell’immagine, comprendente posizionamento dei soggetti, palette di colori e tecniche di illuminazione, ottica (tipo di obbiettivo) utilizzata, etc.

Certainly! Here is a detailed breakdown of the provided image:

—

**Subject:**

The primary subjects are two Porsche sports cars parked on an open asphalt surface.

- **Left Car (Foreground):**
  - A modern black Porsche 911 Turbo or similar high-performance model.
  - Features include:
    - Aggressive aerodynamic bodywork with prominent front air intakes and side skirts.
    - Large, multi-spoke silver alloy wheels — likely custom aftermarket rims given their design and finish.
    - Brightly lit headlights; turn signals also illuminated.
    - Low-slung stance suggesting performance tuning or lowered suspension.
    - Rear spoiler visible above the trunk lid for enhanced airflow control.

- **Right Car (Background / Right Side):**
  - An older-generation white Porsche 911, appearing to be from the late '70s/early '80s era (possibly a 911 Carrera RS).
  - Distinctive features:
    - Classic rounded fenders and iconic curved hoodline.
    - Black racing stripes running along the lower sides, bearing “PORSCHE” lettering.
    - Simple five-spoke steel wheels typical of its time period.
    - Clean lines without aggressive modifications compared to the left car’s sporty aesthetic.

Both vehicles showcase timeless German engineering while contrasting generations through styling cues and mechanical evolution.

---

**Attire & Accessories:**

There is no human presence in either vehicle or around them—no driver, passenger, crew members, nor any individuals wearing clothing or carrying gear. The focus remains entirely on the automobiles themselves as objects of admiration and technical excellence.

Accessories associated directly with each car:
- Left car has LED daytime-running lights integrated into headlight assemblies and possibly additional fog lamps under the bumper area.
- Both feature factory OEM badges (“Porsche”) prominently displayed near rear wheel arches and center of hoods respectively.
- No personal items like helmets, gloves, tools, etc., appear present within view.

No wearable apparel exists since there's nobody depicted visually interacting with these machines.

---

**Background Elements:**

Behind the two Porsches stretches dramatic natural scenery:

- Rolling mountain ranges stretch horizontally across mid-ground behind the scene.
- Mountains vary slightly in elevation but maintain consistent rocky textures covered sparsely by vegetation such as scrub brush or small trees clinging to slopes.
- Horizon line marks where sky meets land at dusk/dawn transition zone—a soft gradient between warm orange-pink tones near ground level fading upward toward cooler grays/blues overhead.
- Sky dominates upper half of frame filled densely with dynamic cloud formations that suggest motion blur effect captured via long exposure technique during twilight hours.
  
Overall atmosphere evokes solitude, grandeur, power—and perhaps nostalgia juxtaposed against innovation represented by both models’ designs.

---

**Composition Analysis:**

This photograph employs strong compositional techniques designed to highlight contrast and visual interest among elements presented.

- **Leading Lines:** Asymmetrical placement positions viewer eye naturally drawn first towards dominant foreground object—the sleek black turbo sedan—with secondary attention shifting rightward onto classic white coupe due to spatial depth cue created by perspective convergence point extending off-screen horizon.
  
- **Framing Techniques Used:**
   - Wide-angle lens utilized which captures expansive vista including entire mountainscape beneath massive canopy of clouds stretching beyond edges of canvas.
   - Use of negative space effectively isolates focal points allowing individual characteristics of each automobile stand out clearly despite being placed apart geographically relative to one another.
   
- **Color Palette Strategy:**
   - Dominant dark gray/black hues dominate automotive surfaces creating sense of sophistication yet grounded realism.
   - White Porsche provides stark tonal opposition enhancing visibility and emphasizing elegance inherent in vintage appeal.
   - Warm sunset glow subtly illuminating distant peaks adds emotional warmth counterbalancing otherwise somber mood established by overcast skies.

- **Light Directionality:**
   - Ambient light originates low angle close to horizon indicating golden hour lighting conditions ideal for accentuating contours and metallic finishes.
   - Reflections caught upon glossy paint jobs confirm reflective quality characteristic of premium manufacturing materials used in original construction.

In summary, careful manipulation of color scheme, directional illumination, framing balance—all contribute significantly to elevating narrative impact surrounding relationship between past legacy and future aspirations embodied by these legendary European supercars set against majestic backdrop of nature’s scale.

--- 

Let me know if you’d like further analysis related specifically to camera settings, editing choices, symbolism, or historical context regarding the specific models shown here!

[Note: Since neither vehicle appears explicitly labeled "Carrera" or other exact model names based solely on appearance alone unless confirmed later.]

Da notare che la versione del custom node QwenVL utilizzata non sembra effettuare opportuna pulizia del testo generato dal modello prima di ritornarlo all’utente: troviamo infatti due frasi tipiche di contenuti generati da AI all’inizio (un generale ringraziamento e accettazione della richiesta) e alla fine (offerta di approfondire l’argomento). In ogni caso, complice anche il formato quadrato esplicitamente richiesto in fase di generazione, l’immagine generata sembra non rispettare appieno le indicazioni riguardo l’inquadratura: la ripresa avrebbe potuto essere più grandangolare e l’uso della tecnica dello spazio negativo è sostanzialmente assente, tanto che la scritta PORSCHE sull’auto bianca è quasi completamente coperta dall’auto nera.

Qwen3-VL-8B-Instruct con Detailed Analysis

Decido a questo punto di provare ad utilizzare un modello Qwen3-VL più grande (8B) per verificare se si ottengano risultati migliori.

Of course. Here is a detailed breakdown of the image, organized by your requested categories.

---

**Subject:**

The primary subjects are two iconic Porsche 911 sports cars positioned on an open asphalt surface against a dramatic mountain backdrop at dusk or dawn.
- **Car on the Left (Foreground):** A black Porsche 993 Turbo S (or similar high-performance variant), characterized by its aggressive styling. Key features include:
    - Large rear spoiler integrated with the roofline.
    - Wide fenders and muscular bodywork typical of the "Turbo" models from that era.
    - Distinctive front air intakes below the headlights.
    - Silver multi-spoke alloy wheels.
    - The car’s headlamps are illuminated, casting a warm glow.
- **Car on the Right (Background/Distance):** A white classic Porsche 911 Carrera RS-style model, likely from the late 1970s to early 1980s. Features include:
    - Classic round headlights.
    - Black racing stripes running along the sides, bearing the word “PORSCHE” in capital letters.
    - Smaller, more minimalist side mirrors compared to modern Porsches.
    - Standard steelies or smaller-diameter alloys.
    - Its lights appear off, emphasizing its silhouette as it recedes into the scene.

Both vehicles exude performance heritage and timeless design, creating a visual dialogue between generations of automotive engineering.

---

**Attire / Accessories:**

There are no people visible in the photograph, so there is no human attire to describe.

However, both cars serve as their own form of accessory within the frame:

- **Accessories for Car #1 (Black Turbo):**
    - Custom widebody kit enhancing aerodynamics and aggression.
    - Performance-oriented suspension evident through low stance.
    - Factory or aftermarket wheel choice complementing its sporty character.
    - Functional lighting system including fog lamps or auxiliary driving lights under the bumper.

- **Accessories for Car #2 (White Classic):**
    - Racing stripe decals — not just cosmetic but historically significant for track use.
    - Original factory bumpers and trim pieces consistent with period-correct restoration.
    - Simple, functional door handles matching the vintage aesthetic.

Together, these elements function as narrative devices—showcasing evolution while honoring tradition.

---

**Background:**

The setting provides immense atmosphere and context:

- **Sky:** Dominated by heavy clouds streaked horizontally across the upper portion, suggesting either fast-moving weather systems or long-exposure photography capturing motion blur over time. Near the horizon, soft gradients transition from deep gray-blue above to pale orange-yellow where sunlight breaks through, indicating sunset or sunrise.
  
- **Mountains/Ridges:** Jagged, rocky ridgelines stretch behind the cars, adding depth and scale to the landscape. Their muted earth tones contrast beautifully with the vibrant sky colors. Sparse vegetation clings precariously to some slopes.

- **Ground Surface:** An expansive flat paved area—a possible airstrip, test track, or remote parking lot—which allows full appreciation of both vehicles without obstruction. Cracks and texture suggest age or exposure to environmental conditions.

This natural environment serves as a powerful foil to the man-made machines; it evokes solitude, raw power, and endurance—all qualities associated with legendary racecars like those depicted here.

---

**Composition:**

The photographer has crafted a carefully balanced and visually compelling arrangement using several compositional techniques:

- **Rule of Thirds & Diagonal Balance:** Both cars occupy distinct thirds—one near left foreground, one right mid-ground—with space allocated around them to create breathing room and avoid clutter. This creates dynamic tension yet harmony between the pair.

- **Leading Lines & Depth Perception:** The road's edge curves gently toward the mountains, subtly guiding viewer attention inward and upward towards the light source. Additionally, the diagonal alignment formed by the cars’ orientation adds energy and movement even though they’re stationary.

- **Contrast Through Color & Lighting:** High contrast exists between the dark storm-laden skies versus the glowing horizons. Similarly, the matte finish of the black car contrasts sharply with the bright reflective surfaces of the white vehicle. Warm ambient light highlights parts of each car differently—the driver-side mirror glows warmly on the black car, whereas shadows dominate much of the white car—but both catch enough reflected hues to remain cohesive.

- **Framing & Negative Space:** The vast empty spaces surrounding the main subjects emphasize isolation and grandeur. Mountains act naturally as framing borders, while negative space ensures focus remains squarely on the automobiles themselves rather than distracting details elsewhere.

In summary, this image successfully marries technical precision with artistic vision—to present not merely photographs of luxury supercars, but cinematic moments frozen forever amidst nature’s majestic drama. It tells stories about legacy, innovation, beauty, speed—and ultimately, passion—for what lies beneath every polished curve and gleaming panel.

La descrizione risulta più dettagliata della corrispondente prodotta dal modello 4B, ma il risultato finale al termine della fase di generazione della nuova immagine è solo leggermente migliore. In ogni case, forse la migliore immagine fino a questo punto.

Qwen3-VL-8B-Instruct con Cinematic Description

Per completare il quadro, vediamo cosa produce il workflow sempre col modello Qwen3-VL 8B e preset Cinematic Description:

Under a vast, brooding sky streaked with twilight’s bruised purples and molten golds, two legendary Porsche 911s stand poised like silent sentinels on an open asphalt plateau flanked by rugged, shadow-draped mountains—a cinematic tableau of power and elegance frozen at dusk. The foreground is dominated by a sleek, matte-black 993 Turbo S, its aggressive stance emphasized by low-slung lines, wide fenders, and gleaming multi-spoke wheels; headlights glow warmly against its dark form, casting sharp reflections that hint at motion even when still. To its right, slightly receding into atmospheric depth, rests a pristine white 964 Carrera RS, its classic curves softened yet defined by racing stripes and minimalist design—its own quiet intensity radiating from beneath the fading light. The dramatic chiaroscuro effect sculpts their forms: cool shadows pool under chassis while highlights dance across polished surfaces, creating tactile contrast between metallic sheen and weathered pavement. A sense of timeless rivalry or harmonious dialogue hangs heavy in the air—the black car roaring forward, the white gliding backward—as though they’re not merely vehicles but characters caught mid-narrative within this epic landscape. Shot in photorealistic precision with painterly composition, every detail—from tire texture to cloud wisps—is rendered with hyper-real clarity, evoking both documentary truth and romanticized mythos, where engineering meets artistry under skies painted for drama alone.

**Visual Impact:** Stark contrasts, dynamic silhouettes, rich color gradients, deep textures, and emotional resonance through juxtaposition create a visually arresting moment suspended between speed and serenity — perfect for posterity.

La descrizione enfatizza l’impatto visivo atteso per l’immagine, tuttavia in generale il testo prodotto non si discosta in maniera significativa da quello prodotto dal modello più piccolo. Anche l’immagine generata appare molto simile (i fari dell’auto nera però sono accesi questa volta).

Meta-prompting: generare prompt a partire da prompt

Un’ulteriore evoluzione del workflow consiste nel non passare più un’immagine a QwenVL, ma una coppia di stringhe testuali:

• prompt: una descrizione semplice (ad esempio ottenuta precedentemente con Simple Description)
• formula: un meta-prompt che chiede esplicitamente di generare un prompt con determinate caratteristiche.

Nel nostro caso, ho optato per richiedere un prompt ottimizzato per il fotorealismo derivante dalla sensazione che l’immagine sia una fotografia analogica 35mm. Ho chiesto a ChatGPT di aiutarmi a scrivere un prompt che generi un prompt che… e alla fine ho ottenuto questo:

Per favore analizza l'immagine allegata e scrivimi un prompt di miglioria specifico per trasformarla in una fotografia in stile analogico 35mm, con questi obiettivi: realismo estremo, forte drammaticità, atmosfera da pellicola vissuta, difetti coerenti con il film (grain, halation, flare, colori meno perfetti). Includi nel prompt specifico: tipi di grana realistica (fine/medium), halation attorno a luci e contrasti, leggero fading dei colori o tonalità vintage, vignettatura organica e bordi leggermente morbidi, micro-imperfezioni: polvere, graffi, disallineamenti, errori di esposizione o bilanciamento del bianco plausibili, elementi narrativi coerenti con la scena che aumentano la sensazione di “scatto su pellicola".

Opportunamente tradotto (da Gemini) e leggermente adattato per il campo Formula, ecco il nuovo prompt inserito nel workflow:

Un paio di esempi di immagini generate con preset Detailed Description a partire dal prompt semplice:

Diritti e copyright delle immagini generate: riduzione del rischio, non immunità legale

Dopo aver visto nel dettaglio come funziona un workflow image-to-text seguito da text-to-image, è naturale chiedersi se questo approccio rappresenti anche una sorta di “via d’uscita” dal punto di vista dei diritti nel copiare immagini. L’idea è seducente: invece di partire direttamente dall’immagine, la trasformo in testo; invece di modificare l’originale, genero qualcosa di nuovo. Ma quanto questa distanza tecnica corrisponde davvero a una distanza giuridica?

La risposta onesta è che I2T → T2I è uno strumento di mitigazione del rischio, non una garanzia legale.
Funziona bene quando viene usato per astrarre, interpretare, trasformare. Funziona molto meno — o per nulla — quando viene usato per ricostruire.

Per capire perché, bisogna chiarire un punto fondamentale: i diritti non proteggono il percorso tecnico, ma il risultato finale.

Il passaggio dal testo non “resetta” i diritti

Uno degli equivoci più comuni è pensare che il diritto protegga il mezzo — il file, i pixel, il formato. In realtà, sia nel diritto d’autore sia nel diritto all’immagine conta l’opera risultante, non il fatto che sia stata generata “a mano”, con Photoshop o con un modello AI.

Se un’immagine generata è:

• sostanzialmente simile a un’opera esistente
• riconducibile a una persona reale
• funzionalmente sostitutiva di un’immagine protetta

allora il fatto che sia passata da una descrizione testuale non costituisce una difesa automatica.

È vero però che I2T introduce una distanza semantica che, se gestita con criterio, rende più difficile arrivare a risultati “troppo vicini” all’originale. Ma questa distanza va costruita intenzionalmente, non data per scontata.

Diritto d’autore: quando la somiglianza conta più della tecnica

Nel caso delle immagini (e in particolare delle fotografie), il diritto d’autore tutela l’impronta creativa: composizione, luce, scelta del momento, inquadratura. Non serve una copia perfetta perché si parli di opera derivata: è sufficiente che un osservatore medio riconosca nell’opera nuova l’essenza di quella precedente.

Nel workflow I2T → T2I il rischio aumenta quando:

• la descrizione estratta dall’immagine è eccessivamente specifica
• il prompt ricostruisce la stessa posa, la stessa luce, lo stesso mood
• il risultato “sembra chiaramente quella foto, rifatta”

In questi casi, il passaggio intermedio dal testo non cambia la sostanza del problema.

Uso commerciale e sostituzione funzionale

C’è poi un aspetto spesso sottovalutato: la funzione dell’immagine, non solo la sua estetica.

Se un’immagine generata:

• sostituisce una fotografia esistente in un contesto commerciale
• replica uno standard visivo (stock, advertising, cataloghi, hero image)

si entra in un’area in cui il problema non è più solo creativo, ma economico. Anche senza una somiglianza perfetta, l’uso può essere contestato se l’immagine AI prende il posto di un contenuto protetto sul mercato.

Il workflow I2T → T2I non elimina questo rischio, soprattutto se viene usato con l’obiettivo implicito di “rifare la stessa cosa senza pagare i diritti”.

Persone reali e il nodo della model release

Qui vale la pena fermarsi un attimo, perché è uno dei punti più fraintesi.

Nel linguaggio della fotografia professionale, una model release è il consenso con cui una persona autorizza l’uso della propria immagine, soprattutto in ambito commerciale. Non riguarda il copyright della foto, ma il diritto all’immagine del soggetto ritratto.

Se una persona è riconoscibile, questo diritto non scompare perché:

• l’immagine è stata rielaborata
• l’immagine è stata generata da un modello AI
• si è passati da testo invece che da pixel

Questo vale anche nel workflow I2T → T2I.

Se l’immagine finale:

• riproduce una persona reale riconoscibile
• o una “controfigura evidente” (stessi tratti, stessa identità percepita)

il problema della model release rimane identico.

Per questo motivo, in ambito professionale, molte aziende preferiscono:

• usare persone completamente sintetiche
• evitare riferimenti a individui reali
• lavorare su volti deliberatamente non riconducibili a nessuno

Il flusso I2T → T2I può aiutare in questa direzione solo se l’obiettivo è creare persone nuove, non rifare persone reali “con un altro volto”.

Conclusioni (in ordine sparso)

• I modelli Vision-Language hanno un potenziale enorme, ben oltre la semplice descrizione di immagini
• La “lampada dell’AI” può essere usata anche per imparare a esprimere meglio i desideri : possiamo usare modelli Vision-Language per generare prompt iniziali a partire da immagini esistenti
• Il meta-prompting è uno strumento potente per migliorare i prompt senza diventare esperti linguisti: possiamo usare un LLM per creare un meta-prompt di ottimizzazione di un prompt/test esistente, e poi “applicarlo” a quanto ottenuto dal modello Vision-Language
• Z-Image Turbo riesce a produrre immagini estremamente realistiche con poche risorse e tempi ridotti
• Prompt più lunghi non garantiscono necessariamente risultati migliori: conta cogliere gli elementi salienti. I preset del nodo QwenVL per ComfyUI usati per le prove offrono alcuni punti di partenza per generare i prompt. A seconda dell’immagine input, è possibile personalizzare i preset o sostituirli completamente con prompt che focalizzino l’attenzione su aspetti specifici, ad esempio inquadratura, o dettagli dell’immagine (Qwen3-VL non ha mai notato che sull’auto nera ci sono due persone, per dire, e che hanno un finestrino aperto). Opportuna pulizia dei prompt generati dal modello Vision-Language prima di passarlo alla generazione dell’immagine consentirebbe ulteriori migliorie della resa finale.
• Qwen3-VL mostra alcuni limiti di conoscenza specifica, in questo caso auto Porsche; a memoria di chi ha scattato la foto, i due modelli sono 993 RUF Turbo R degli anni ‘90 (la nera) e 911 Singer (la bianca). Per la cronaca, Gemini 3 Pro che pure ha avanzate capacità Vision-Language, sicuramente oltre quelle di Qwen3-VL 8B, ha comunque correttamente identificato solo la Singer.
• Il flusso I2T + T2I non è un passpartout legale

Ma proprio questi limiti rendono l’esperimento interessante: è un esempio concreto di cosa si può fare oggi, in locale, con strumenti aperti — e di quanto spazio ci sia ancora per migliorare.

Come sempre, il genio della lampada ascolta… ma bisogna imparare a parlare la sua lingua.

Nelle ultime settimane, invece, ho voluto sperimentare due coding agent specificamente concepiti per servirsi di svariati modelli (openweight e commerciali) in locale o in remoto. Ho dunque scelto di provare Kilo Code e Cline; entrambi sono disponibili come estensioni di molti dei principali IDE, tra i quali ho scelto VS Code.

Lo scenario di test

Come scenario di test, di nuovo ho scelto di “proseguire lo sviluppo” del piccolo progetto opensource (onnx-model-generator-docker) che già avevo usato in precedenza: in sintesi, ricordo che si tratta di un servizio REST Dockerizzato che converte modelli HuggingFace in formato Open Neural Network Exchange (ONNX) utilizzando la libreria onnxruntime-genai: riceve una richiesta HTTP e restituisce un modello ottimizzato pronto da scaricare.

In precedenza avevo chiesto a Claude di elencare le possibili migliorie, in particolare in ambito di sicurezza, e di salvarne la lista insieme alla documentazione di progetto; ho dunque utilizzato il seguente semplice prompt per dare il via alle operazioni di Cline e Kilo Code in tutte le prove qui descritte:

Hi, please have a look at the project, including the .md files and figure out what the next improvement task to work on would be, then prepare for completing it (including testing and updating the existing .md documents)

Il primo task su cui lavorare, dato lo stato corrente del progetto, era quello di aggiungere il rate limiting, ossia permettere di controllare il numero massimo di richieste al minuto verso il servizio Docker da un dato indirizzo IP.

I modelli utilizzati

Per quanto concerne gli LLM utilizzati con i due coding agents, ho deciso di testare principalmente i modelli GLM di Z.ai. Tra questi, GLM 4.6 si posiziona al livello di alcuni degli attuali modelli SOTA ed è disponibile per utilizzo remoto via API a prezzi decisamente ridotti rispetto alla concorrenza (il che presumo ne faccia o farà una scelta popolare). Inoltre, il modello è openweight, disponibile su huggingface.co e dunque utilizzabile anche in locale… almeno in linea teorica.

Nella pratica, trattandosi di un modello da 357 miliardi di parametri, l’inferenza su qualunque hardware consumer attuale è sostanzialmente preclusa a meno di ricorrere a quantizzazioni estremamente aggressive.

Per le prove in locale sul mio AMD Ryzen AI Max+ 395 (Strix Halo) con 128 GB di RAM condivisa ho dunque scelto di provare GLM 4.5-Air, ossia la versione snellita (106 miliardi di parametri in totale, 12 attivi - Mixture of Experts) di GLM 4.5, il modello precedente a GLM 4.6. GLM 4.5 è pubblicizzato come qualitativamente ancora comparabile con Claude 4 Sonnet, mentre 4.5-Air è dato come solo leggermente inferiore a 4.5 in termini di qualità della generazione. Per ridurre al minimo l’impatto della quantizzazione, ho scelto di utilizzare la versione GGUF Q5_K_M diffusa su huggingface.co da Unsloth AI. Ho effettuato il deploy del modello su LMStudio, eseguendo tutti i layer in GPU e abilitando la Flash Attention.

Infine, ho anche rieseguito qualche prova con Cline abbinato allo stesso GPT-OSS-120B usato in precedenza, per avere un riferimento.

Kilo Code

Configurazione

Dopo aver completato l’installazione in VS Code, Kilo Code si configura per connettersi a differenti tipi di modelli LLM utilizzando la scheda Providers all’interno della sezione Settings.

Nel caso dei modelli remoti, ho selezionato Z AI come API provider (International entrypoint) e copiato la mia API key generata su sito di Z.ai dopo aver sottoscritto il piano Lite (9 USD a trimestre); ho abilitato il reasoning e lasciato invariate tutte le altre impostazioni.

Per utilizzare il modello GLM 4.5-Air in locale, invece, prima di tutto ho avviato il server LMStudio ed eseguito il deploy del modello utilizzando una finestra di contesto di 65k token, così da avere un buon compromesso tra velocità di inferenza / memoria utilizzata e lunghezza della “conversazione” tra agente e modello. Poi nelle impostazioni di Kilo Code ho selezionato LM Studio della lista di API Provider supportati e scelto glm-4.5-air tra le opzioni presentate automaticamente (ottenute da Kilo Code interrogando il server LM Studio attraverso Open API). Anche qui non ho apportato ulteriori cambiamenti alle impostazioni avanzate.

Modalità di funzionamento

Kilo Code può adattare il suo comportamento a seconda della modalità (mode) di funzionamento selezionata. Le modalità disponibili di default (è possibile infatti impostarne di personalizzate) tra cui scegliere sono Code, Ask, Architect, Debug e Orchestrator; ognuna di esse si caratterizza per differenti “personalità”, ottimizzazioni e accesso (nonché permesso di esecuzione) a tool: lettura/scrittura file, MCP, browser, comandi shell, … L’idea è che si scelga la modalità di esecuzione più adatta al compito da compiere.

Per semplicità, ho selezionato Architect per la prima fase di esecuzione (il prompt parla di “comprendere quale sia il prossimo task…” e di “prepararsi a completarlo”), per poi passare in modalità Code per la successiva fase implementativa.

Prove effettuate

Come anticipato sopra, ho sperimentato tre differenti scenari di utilizzo, con tre differenti modelli / API Provider: GLM 4.6 in remoto, GLM 4.5-Air in remoto, GLM 4.5-Air in locale. Qui sotto riporto una selezione di screenshot catturati durante le prove.

GLM 4.6 in remoto

GLM 4.5-Air in remoto

GLM 4.5-Air in locale

In tutti gli scenari il compito richiesto è stato completato con successo: l’agente ha compreso quale fosse il prossimo task a cui lavorare ed è stato in grado di completarlo (nel caso di GLM 4.5-Air locale, a dire il vero, ha preparato una lista di task a cui lavorare, il primo dei quali quello che ci si attendeva).

In puro stile “vibe coding”, ho lasciato lavorare l’agente in autonomia, rispondendo a domande chiuse (scelta multipla) e confermando manualmente le sole esecuzioni dei tool (per le testsuite) e il passaggio alla fase di coding. Le analisi condotte nella prima fase hanno evidenziato differenti livelli di approfondimento e chiarezza nello spiegare il piano; in accoppiata con GLM 4.6, Kilo ha fatto un ottimo lavoro generando, tra le altre cose, una domanda con 4 possibili risposte pre-confezionate (per verificare le intenzioni dell’utente) e un diagramma di flusso della logica da implementare.

In tutti i casi il sistema è stato in grado di generare test per la nuova funzionalità (risolvendo fallimenti quando si sono presentati) ed aggiornare la documentazione.

Per quanto concerne i tempi di esecuzione, non è possibile fare un vero confronto, considerato il non determinismo che porta a percorsi di risoluzione del problema ed esecuzione completamente differenti, tuttavia la versione in locale è risultata in generale leggermente più lenta, ma la differenza è stata meno significativa di quanto mi aspettassi (Kilo spende diverso tempo anche “lato client”). Va comunque considerata anche la differente dimensione del contesto, l’utilizzazione del quale è chiaramente visibile negli screenshot.

Cline

Configurazione

Anche nel caso di Cline ho installato l’estensione VS Code. Una volta completata la procedura, di nuovo come per Kilo Code, il tab Settings di Cline consente di specificare l’API Provider (Z.ai e LM Studio, nel mio caso) e di fornire rispettivamente la chiave o l’URL del server e il nome del modello da utilizzare. Non dovendo utilizzare finestre di contesto molto piccole (inferiori a 8k), non ho abilitato l’utilizzo di prompt compatti.

Modalità di funzionamento

Se Kilo Code dispone di diversi modes, Cline invece distingue tra Plan mode e Act mode. È possibile configurare Cline affinché utilizzi modelli differenti per le due modalità, selezionando ad esempio un modello reasoning in Plan e uno non reasoning in Act.

Considerato il prompt scelto per questi esperimenti, sono sempre partito con la modalità Plan, per poi autorizzare Cline a passare in modalità Act una volta preparato il piano d’intervento.

Prove effettuate

Con questo agente ho testato nuovamente GLM 4.6 remoto, mentre in locale ho provato ad utilizzare, sempre via LM Studio, GPT-OSS-120B che discrete soddisfazioni aveva dato negli esperimenti con Claude Code Router (utilizzato però in parallelo ad un modello più piccolo, GPT-OSS-20B).

Ho utilizzato Cline in maniera simile a Kilo Code, sostanzialmente autorizzando sempre le richieste di utilizzo dei tool (nella configurazione di default, Cline lascia maggiore controllo all’utente rispetto a Kilo Code, che applica le modifiche ai file senza chiedere conferma) e lasciando che cercasse autonomamente di superare i problemi incontrati, risolvendo bachi, installando dipendenze, etc.

Qui sotto alcune immagini catturate durante l’esecuzione, come nel caso precedente. Da notare che, nella configurazione con GPT-OSS-120B, due tentativi di eseguire nuovamente il compito richiesto nel prompt sono falliti, con l’agente che non è riuscito a produrre un’implementazione funzionante che passasse i test.

GLM 4.6 in remoto

GPT-OSS-120B in locale

Analisi risultati

Sebbene sia stato possibile completare il task richiesto in tutti gli scenari, la qualità delle soluzioni ottenute non è necessariamente la stessa. Invece di effettuare il merge di una delle implementazioni sul main del progetto, ho creato un branch differente per ognuno degli scenari provati:

• Kilo Code + GLM 4.6 remoto: https://github.com/asoldano/onnx-model-generator-docker/tree/kilo-glm-4.6
• Kilo Code + GLM 4.5-Air remoto: https://github.com/asoldano/onnx-model-generator-docker/tree/kilo-glm-4.5-air
• Kilo Code + GLM 4.5-Air locale: https://github.com/asoldano/onnx-model-generator-docker/tree/kilo-lms-glm-4.5-air-65k
• Cline + GLM 4.6 remoto: https://github.com/asoldano/onnx-model-generator-docker/tree/cline-glm-4.6-200k
• Cline + GPT-OSS 120B locale: https://github.com/asoldano/onnx-model-generator-docker/tree/cline-lms-gtp-oss-120b-64k

Per una valutazione imparziale e competente dei risultati, ho poi generato le patch corrispondenti alle modifiche su ognuno dei branch a partire dal branch point e le ho sottomesse a Google Gemini 3.

Ciao! ho bisogno che tu mi aiuti a valutare la bontà di 5 differenti implementazioni della stessa feature sulla stessa codebase. Il punto di partenza è https://github.com/asoldano/onnx-model-generator-docker , ti allego le 5 patch delle cinque implementazioni alternative, la feature da implementare era rate limiting, ma ti invito a leggere il sorgente del progetto dal main , guardare i file .md e capire cosa è stato scelto di implementare (ho usato tool AI per farlo, il prompt era: "hi , please have a look at the project, incuding the .md files and figure out what the next improvement task to work on would be, then prepare for completing it (including testing and updating the existing .md documents)" . Per favore, analizza le cinque proposte e dimmi come si posizionano come qualità.

Il risultato dell’analisi effettuata per me dall’intelligenza artificiale stessa evidenzia punti di forza e debolezze delle patch. Chi fosse curioso può provare ad interrogare Gemini (o magari Claude?) e leggere la risposta; qui invece ritengo sia interessante focalizzarsi sulle aree di debolezza individuate (a prescindere da quale configurazione abbia portato ad uno dei comportamenti sub-ottimi), così da capire dove sia il vero valore aggiunto di utilizzare un modello “migliore”:

• Hardcoding di parametri con valori arbitrari
• Stile di testing incoerente (stampe in standard output, mancanza di assertion / exit code appropriati)
• Caos nella gestione delle dipendenze (downgrade, aggiunte e rimozioni inappropriate di librerie)
• Scelte di design non ottimali (nel nostro caso, un rate limit unico per tutti gli endpoint)
• Race conditions / implementazione non thread-safe
• NIY syndrome (implementazione custom dove esistono librerie stabili e testate che offrono la stessa funzionalità)

Per quanto concerne invece la scelta dell’agente o del modello “migliore”, Gemini ha chiaramente fornito una sua classifica delle 5 soluzioni presentate, ottenuta dando un peso ai vari pro e contro evidenziati; sul podio abbiamo:

1. Kilo Code + GLM 4.6 remoto
2. Cline + GLM 4.6 remoto
3. Kilo Code + GLM 4.5-Air remoto

In ottica di merge sul main del progetto, probabilmente per mantenere una certa neutralità, Gemini consiglia di derivare una soluzione “perfetta” partendo da quella di Cline + GLM 4.6 remoto e aggiungendo alcune specifiche idee riscontrate unicamente nelle altre soluzioni (incluse le due ottenute con modello locale).

Conclusioni

Prima di saltare alle conclusioni, alcune considerazioni:

• l’esperimento si basa chiaramente su un’osservazione estremamente limitata e va considerata la natura indeterministica / probabilistica dei modelli… quindi non ci sbilanciamo più di tanto ;-)
• ci sono sicuramente margini di miglioramento / tuning a livello della configurazione degli agenti Cline e Kilo Code.

Detto questo, dopo le prove qui descritte ecco i punti che ci portiamo a casa:

• Il ranking delle soluzioni riportato dal Gemini 3 (probabilmente la più avanzata AI disponibile al momento) rispecchia quello che ci saremmo aspettati considerando le specifiche e i benchmark dei modelli: GLM 4.6 meglio di GLM 4.5-Air, GLM 4.5-Air in remoto via API meglio della versione quantizzata in locale.
• È possibile portare a termine egregiamente un task di sviluppo come quello qui presentato in tutte le modalità presentate; abbiamo però un’idea della direzione in cui guardare per apprezzare le differenze di qualità tra soluzioni prodotte con modelli più o meno performanti; questo ci aiuta anche in generale nell’ottimizzare la review umana di codice generato dall’AI.

Su Aladino Digitale già si era toccato l’argomento nel post su Giulia che esce dalla lampada. In quel caso l’idea era sostanzialmente un gioco: avevamo generato un’immagine con ChatGPT + Gemini Nano Banana + OpenArt, e poi l’avevamo usata per ottenere qualche close-up e un mini-video. Ma lì si trattava semplicemente di sfruttare le funzionalità di modelli img2img come Flux Context (funzionalità che oggi possiede anche Gemini Nano Banana) esposte da tool quali OpenArt: non c’era un vero “personaggio consistente”. Era una serie di derivazioni della stessa immagine.

Quello che volevo esplorare ora è un passo diverso: partire da una singola foto e costruire un modello in grado di generare ogni possibile nuova immagine di quel soggetto, in qualunque contesto, come se fosse una vera persona fotografata infinite volte.

E per farlo ho scelto di restare in locale, usando la mia macchina con AMD Strix Halo, modelli di architettura Flux, ComfyUI e un LoRA addestrato da zero.

Di seguito racconto l’esperimento, eseguito “per davvero”, con tutti i limiti del caso.

1. Perché un “personaggio consistente” è diventato così importante (e perché interessa anche a noi)

Il concetto è semplice: se voglio creare un personaggio fittizio (per storytelling, social, mockup di campagne, giochi, fumetti, concept art) un singolo scatto non basta. Voglio la stessa persona che:

• sorride, è seria, guarda di lato;
• sta in piedi, seduta, di profilo;
• è in cucina, in un bar, in un parco;
• indossa abiti diversi;
• è ripresa con stili e qualità fotografiche differenti.

Oggi le AI sfornano volti realistici a migliaia… ma mantenere coerenza e consistenza tra generazioni differenti è un’altra storia. Ecco perché sono nati svariati siti online (incluso lo stesso OpenArt) che promettono di generare in modo semplice un consistent character: da poche immagini costruiscono un profilo consistente, sfruttando in qualche forma un fine-tuning leggero del modello (quasi sempre LoRA).

Nel mio caso, volevo capire:

• cosa succede facendolo tutto in locale, senza mandare foto a servizi terzi;
• cosa cambia rispetto alle soluzioni “one click” online;
• se è possibile partire davvero da una sola immagine e arrivare a un modello funzionante.

Giulia è diventata la “cavia” perfetta.

2. LoRA, Flux e il contesto “AI in locale”: cosa serve davvero

Avevo menzionato i LoRA già in passato nel post sulla scelta dei modelli da usare in locale; qui aggiungiamo qualche info aggiuntiva riguardo LoRA e sulle altre scelte fatte:

Che cos’è un LoRA?

• È un fine-tuning leggero, cioè una piccola rete aggiuntiva che modifica selettivamente il comportamento del modello base.
• Non si riaddestra tutto da zero (operazione impossibile in locale), ma solo pochissimi parametri aggiuntivi.
• Il risultato è un file (tipicamente in formato safetensors) molto leggero, in genere pochi megabyte.

In pratica un LoRA è come un filtro che dice al modello:

“Quando vedi la parola chiave X, usa questo pattern di volto, proporzioni, dettagli”.

Perché Flux?

Perché al momento:

• è estremamente forte sul realismo (specie nella versione Krea);
• regge molto bene l’identità del soggetto;
• ha modifiche ottimizzate per generazione rapida, queuing, caching, ecc.;
• è molto apprezzato dalla community e supportato da tanti tool
• gira relativamente bene sulla soluzione AMD a mia disposizione.

Perché in locale?

In linea di principio, l’approccio in locale offre il vantaggio di avere un flusso completamente privato e consente di sperimentare senza troppe preoccupazioni riguardo il costo dei token. Da un punto di vista più personale, invece, volevo capire i limiti pratici provando un caso d’uso concreto sul mio hardware.

Il resto del post è quindi la cronaca di questo processo: creazione di un opportuno dataset → training del LoRA → test del LoRA e valutazioni finali.

3. Costruzione del dataset: il vero collo di bottiglia

È quasi paradossale, ma produrre un buon dataset di immagini è complesso (e importante!) quanto addestrare il LoRA.

Io ho deciso di usare e riportare qui due strade:

3.1 – Generazione con Gemini Nano Banana via OpenArt.ai (approccio “online”)

Partendo dall’immagine di Giulia usata nel vecchio post, ho aperto OpenArt in modalità Chat Edit e ho iniziato a chiedere di:

• togliere oggetti;
• cambiare ambienti;
• effettuare zoom su dettagli;
• cambiare posa;
• aggiungere abiti;
• ecc.

Il vantaggio di questo approccio è la rapidità di generazione delle immagini, che sono di norma coerenti e senza particolari allucinazioni (grazie alla bontà di Gemini Nano Banana). Il limite vero, a prescindere da ragionamenti su costi, è chiaramente quello di privacy, policy ed eventuale moderazione.

Ho comunque incluso alcune di queste immagini nel dataset finale perché erano molto utili come pose alternative.

3.2 – Generazione con ComfyUI (approccio “locale”, più complesso ma più controllabile)

Qui entra in scena un workflow abbastanza articolato; dopo una breve ricerca in rete, ho deciso di provare quello rilasciato e descritto pubblicamente da Mickmumpitz il mese scorso. Il flusso è diviso in due parti; nella prima ComfyUI:

• genera viste front / side / back del personaggio (turnaround sheet);
• produce close-up coerenti del volto;
• cambia espressioni attraverso controlli fini dei movimenti di bocca, naso, occhi, sopracciglia, etc;
• genera pose diverse attraverso controlli specifici e/o immagini di riferimento;
• cambia l’abbigliamento del soggetto usando capi da immagini di riferimento;

Nella seconda parte invece si applica upscaling e piccoli miglioramenti assortiti alle immagini precedentemente generate. Vengono inoltre generate le caption con la descrizione delle immagini create.

Il risultato è un dataset relativamente strutturato, con viste complementari che aiutano il LoRA a generalizzare.

Vantaggi

• Tutto locale, massima privacy.
• Controllo diretto su qualità e varietà delle immagini (pose, espressioni, luci).

Limiti

• Workflow non banale da capire.
• Richiede tempo e risorse (VRAM); per non impiegare giorni e dovendo fare i conti con alcune instabilità del mio stack (sto sempre aspettando l’uscita del kernel 6.18 di Linux…), nel fare upscaling mi sono limitato ad immagini 1024x1024 pixel di dimensione.

A dataset completo, avevo circa 25 immagini ben varie. Sufficienti per un LoRA di qualità? Forse, da valutare in seguito, di sicuro abbastanza per un primo esperimento attendibile… e soprattutto: tutto costruito da una sola immagine originale.

4. Addestrare il LoRA con FluxGym: semplice, ma con mille parametri

Per l’addestramento ho usato FluxGym, un’interfaccia che permette di:

• definire il nome del LoRA;
• scegliere il modello base (Flux dev nel mio caso) e la parola chiave/trigger per attivare il LoRA;
• caricare immagini + caption automatiche;
• impostare epoche, batch size, repeats, LR;
• visualizzare lo script generato per effettuare il training ed eventualmente eseguirlo.

Caricamento immagini

Ho selezionato le 25 immagini del dataset descritte in precedenza; i file .txt generati dal workflow ComfyUI e contenenti le caption vengono caricati automaticamente (purtroppo la qualità e coerenza del testo che descrive le scene è quello che è):

Configurazione usata

FluxGym dispone di diverse decine di parametri di configurazione.

Per semplicità, ho scelto di non focalizzarmi sugli aspetti di “ottimizzazione scientifica”: ho modificato soltanto --optimizer-type per evitare un errore iniziale e la durata del training, poi ho lasciato quasi tutto a default.

accelerate launch   --mixed_precision bf16 --num_cpu_threads_per_process 1
  sd-scripts/flux_train_network.py
  --pretrained_model_name_or_path "/home/alessio/dati/fluxgym/models/unet/flux1-dev.sft"
  --clip_l "/home/alessio/dati/fluxgym/models/clip/clip_l.safetensors"
  --t5xxl "/home/alessio/dati/fluxgym/models/clip/t5xxl_fp16.safetensors"
  --ae "/home/alessio/dati/fluxgym/models/vae/ae.sft"
  --cache_latents_to_disk
  --save_model_as safetensors
  --sdpa
  --persistent_data_loader_workers
  --max_data_loader_n_workers 2
  --seed 42
  --gradient_checkpointing
  --mixed_precision bf16
  --save_precision bf16
  --network_module networks.lora_flux
  --network_dim 4
  --optimizer_type adamw
  --sample_prompts="/home/alessio/dati/fluxgym/outputs/giulia1/sample_prompts.txt"
  --sample_every_n_steps="100"
  --learning_rate 3e-4
  --cache_text_encoder_outputs
  --cache_text_encoder_outputs_to_disk
  --fp8_base
  --highvram
  --max_train_epochs 16
  --save_every_n_epochs 4
  --dataset_config "/home/alessio/dati/fluxgym/outputs/giulia1/dataset.toml"
  --output_dir "/home/alessio/dati/fluxgym/outputs/giulia1"
  --output_name giulia1
  --timestep_sampling shift
  --discrete_flow_shift 3.1582
  --model_prediction_type raw
  --guidance_scale 1
  --loss_type l2
  --mem_eff_attn

E’ possibile fornire uno o più sample prompt da utilizzare a varie epoche per generare immagini con il LoRA corrente, così da valutare i progressi dell’addestramento (ed eventualmente fermarsi ante tempo, previa configurazione di FluxGym per salvare snapshot del LoRA agli stessi step in cui si valutano i sample prompt). In generale, qui il consiglio è di fornire prompt sufficientemente generici da lasciare spazio al modello di “esprimersi” e vedere se e quanto il LoRA sta facendo effetto. Inoltre è bene formulare prompt che descrivano scene che normalmente portino a rappresentare gli elementi che si presume essere distintivi del soggetto per i quale si crea il LoRA (ad esempio ripresa frontale del soggetto , utile per valutare il viso).

Dopo diverse ore di computazione, utilizzando oltre 20 GB di memoria video (ma esiste configurazione per eseguire con soli 12GB di VRAM), FluxGym mi produce:

• giulia1.safetensors → il LoRA finale
• vari snapshot intermedi
• immagini sample
• caption associate

Non immediato di sicuro, ma perfettamente gestibile sul mio hardware.

5. Risultati: il LoRA funziona davvero? Sì (ma con alcune sorprese)

Il LoRA ottenuto è utilizzabile con qualunque modello della serie Flux. Torno dunque in ComfyUI, carico un workflow Flux standard, ma decido di utilizzare Flux1 Krea Dev per un maggiore fotorealismo delle immagini generate; per caricare il LoRA, uso un apposito LoraLoaderModelOnly e seleziono il file .safetensor finale generato da FluxGym.

Per attivare il LoRA in fase di generazione, aggiungo nel prompt la parola chiave Giulia1 e gioco con i contesti. Per cominciare un semplice prompt del tipo A 4k photorealistic full body shot of Giulia1, sitting on a bench in a city park, in 20 step e con il resto delle impostazioni visibili nell’immagine qui sotto, produce un’immagine a tutti gli effetti coerente con quella di partenza: Giulia è rappresentata nell’immagine unicamente grazie al riferimento del nome nel prompt, senza bisogno di specificarne le caratteristiche fisiche / estetiche.

Decido dunque di arricchire un pochino la descrizione nel prompt, specificando l’abbigliamento richiesto per il soggetto (si noti come non si tratti di un outfit presente nel dataset di training) e un’azione in corso (lavoro al computer portatile): il risultato è ancora più che buono in termini di coerenza, proporzioni, credibilità dell’espressione e aderenza al prompt.

Noto tuttavia che i tatuaggi alle gambe sembrano scomparsi (avevo esplicitamente fornito un’immagine ravvicinata nel dataset di training, per valutare le capacità di imparare dettagli complessi). Provo dunque a “dare una mano” al modello, esplicitando nel prompt la presenza dei tatuaggi alle gambe.

💡 Suggerimento prompt: talvolta parte del prompt non viene recepito correttamente. Nell’esempio qui sopra, Giulia lavora effettivamente al portatile, etc. ma a voler essere pignoli l’immagine generata non è veramente a full body shot. Un modo elegante per forzare il modello a rispettare la richiesta è quello di aggiungere del dettaglio informativo nel prompt - e dunque nel contesto - riguardo la parte dell’immagine che sta venendo ignorata, in questo caso i piedi del soggetto. Aggiungo quindi informazioni sul tipo di scarpe da generare.

Con il prompt rivisto otteniamo i tatuaggi richiesti. Il LoRA sembra avere effettivamente imparato qualcosa riguardo i tatuaggi di Giulia, le posizioni sulle gambe sono corrette, il colore è giusto, lo stile / pattern tuttavia è simile ma non identico (indice della necessità di migliori e più numerose immagini necessarie nel dataset e probabilmente di una fase di training più estesa e meglio configurata). Inoltre, l’immagine generata presenta tatuaggi non richiesti anche sulle braccia.

Per concludere provo ad utilizzare un prompt molto verboso reperito su una galleria online di immagini AI; la scena descritta è relativamente complessa e ricca di dettagli, ciononostante il risultato è sempre più che buono.

💡 Suggerimento adattamento prompt con LoRA: quando si riutilizza un prompt creato in precedenza, aggiungendo un LoRA e attivandolo con opportuna parola chiave, è opportuno verificare che il prompt non contenga informazioni palesemente in contrasto con gli elementi salienti / distintivi del “soggetto codificato” nel LoRA. Se il soggetto ha capelli corti, per dire, un prompt che descrive i capelli che cadono lungo la schiena del soggetto, porta facilmente ad una generazione che non rappresenta correttamente il soggetto del LoRA o che non rispetta le richieste del prompt.

Conclusioni: cosa ho imparato (e perché questo esperimento conta)

Questo esperimento non è un tutorial “perfetto”. Non ho:

• selezionato un dataset ottimale;
• sistemato le caption (spesso inaccurate);
• fatto upscaling serio di tutte le immagini;
• bilanciato LR, repeats, rank del LoRA;
• iterato su 3–4 training per confrontare risultati.

Eppure, con:

• una sola immagine iniziale,
• ~25 immagini derivate,
• un training leggero in locale,
• un modello Flux in locale,

sono riuscito a creare un personaggio consistente, da zero, completamente offline, e senza censure.

È una cosa incredibile sia in positivo (creatività, prototipazione, storytelling, produzione veloce di contenuti), sia in negativo:

il sistema funziona anche con foto vere di persone reali.

E questo costringe ognuno di noi a rivalutare l’autenticità di praticamente qualunque contenuto visuale trovato online.

Non escludo un domani di approfondire la configurazione dell’addestramento LoRA, per ora tuttavia mi fermo qui: un flusso, realmente provato, che partendo da un singolo scatto permette di generare qualunque scena con un personaggio inventato — ma coerente.

L’obiettivo era provare a replicare — almeno in parte — l’esperienza di Claude Code, l’ambiente di Anthropic per lo sviluppo assistito da AI, ma eseguendo tutto localmente.

Per farlo mi sono servito di due componenti principali:

• Claude Code Router
• LM Studio

Come usecase di test, ho scelto di “proseguire lo sviluppo” del piccolo progetto opensource (onnx-model-generator-docker) che già avevo usato un mese fa proprio per dimostrare le potenzialità di Claude Code.

Come funziona un coding agent

Prima di entrare nei dettagli, vale la pena ricordare cosa fa a grandi linee internamente un “coding agent”. A differenza di una chat tradizionale, un agente non risponde solo a un prompt, ma gestisce un ciclo di lavoro: pianifica un’azione (“implementa la feature X”, “risolvi in bug Y”), analizza il codice esistente, modifica file, richiama tool, legge risultati dei test e decide cosa fare dopo.

Ogni passo di questo processo genera una o più richieste verso un modello linguistico, che deve ragionare a partire da un contesto aggiornato. Il modello, tuttavia, è stateless: non conserva memoria delle conversazioni e delle chiamate che le compongono. Questo significa che ogni volta bisogna ridargli tutto ciò che serve — parte del codice, descrizioni, risultati intermedi — entro i limiti della finestra di contesto.

È proprio per questo che i coding agent necessitano di modelli con contesti ampi (es. 64 k token o più): devono mantenere visibili porzioni significative di codice e output, altrimenti perdono “il filo” tra una richiesta e l’altra.

Claude Code Router: il cuore dell’esperimento

Il Claude Code Router è un progetto open source pensato per reindirizzare le chiamate di Claude Code verso differenti modelli. Non è un editor o un’interfaccia grafica: è un proxy intelligente che si interpone tra il client (CLI di Anthropic) e uno o più modelli configurati come backend.

Il router riceve le chiamate del client (ad esempio “pensa al prossimo passo”, “leggi questo file”, “genera test”), le instrada al modello corretto in base al tipo di richiesta (think, longContext, default, background), e restituisce la risposta nel formato previsto.

Ogni ruolo può usare un modello diverso, o la stessa istanza con parametri differenti — ad esempio uno piccolo per richieste rapide e uno grande per reasoning più complesso. Nel mio caso, l’ho usato inizialmente con una sola istanza locale di LM Studio, poi in seguito con due (ma ci arrivo dopo).

LM Studio: il backend locale

LM Studio è un’applicazione che consente di scaricare ed eseguire modelli LLM openweight su GPU o CPU locali, esponendoli tramite un’API compatibile con OpenAI. Per il router è del tutto trasparente: crede di parlare con un endpoint remoto (come quello di Anthropic), ma in realtà l’inferenza avviene interamente sul mio sistema.

Ho scelto come modello di partenza gpt-oss-20b, che rappresenta un buon compromesso fra capacità e requisiti di memoria. Le impostazioni iniziali in LM Studio erano:

• Contesto massimo: 64 k token
• Flash Attention: abilitata
• Layer in GPU: tutti

1. Prima configurazione: un solo modello per tutto

In questa prima prova, tutte le richieste del router (default, think, background, longContext) puntavano alla stessa istanza LM Studio con gpt-oss-20b.

{
  ...
  "Providers": [
    {
      "name": "strix-halo",
      "api_base_url": "http://localhost:1234/v1/chat/completions",
      "api_key": "test",
      "models": [
        "openai/gpt-oss-20b"
      ]
    }
  ],

  "Router": {
    "default": "strix-halo,openai/gpt-oss-20b",
    "background": "strix-halo,openai/gpt-oss-20b",
    "think": "strix-halo,openai/gpt-oss-20b",
    "longContext": "strix-halo,openai/gpt-oss-20b",
    "longContextThreshold": 60000,
    "webSearch": "strix-halo,openai/gpt-oss-20b",
    "image": "strix-halo,openai/gpt-oss-20b"
  }
  ...
}

Nelle prime prove non avevo impostato limiti particolari per la risposta (max_tokens), lasciando al router il default. Solo più avanti, con la configurazione multi-modello, il parametro max_tokens diventerà importante — ma non tanto per controllare la lunghezza dell’output, quanto per come interagisce con la KV cache, e quindi con la memoria effettiva utilizzata (ci torno tra poco).

Perché 64 k token

Come accennato prima, un coding agent è stateless, quindi a ogni passo deve ricevere di nuovo tutto ciò che serve per ragionare: parte del codice del progetto, i file generati in precedenza, e le istruzioni aggiornate. Un contesto da 64 k token permette di contenere già una porzione significativa del codice e di mantenere coerenti le conversazioni multi-step. Al di sotto dei 32 k, il modello “perde pezzi” del ragionamento, perché il contesto non basta a mantenere tutto il necessario.

In termini pratici, 64 k token equivalgono a circa 50 KB di testo grezzo (più metadati) e comportano un overhead di memoria di circa 3 GB solo per la gestione della cache associata a quel contesto.

Layer in GPU e Flash Attention

Grazie all’abbondante memoria unificata del Ryzen AI Max+, posso abilitare tutti i layer in GPU ed eseguire l’intera pipeline del modello (i layer del transformer) direttamente sulla GPU, ottimizzando la velocità dell’inferenza e riducendo la latenza. Su un’architettura con scheda video dedicata, questo implicherebbe utilizzo della (spesso poca) memoria video VRAM, che diventa dunque l’elemento vincolante per capire quanti layer possono andare in GPU.

La Flash Attention, invece, è un’ottimizzazione della computazione delle matrici di attenzione: riduce la duplicazione di dati in memoria e accelera le moltiplicazioni tra Q, K e V.

Prime osservazioni

Con questa configurazione base, l’agente funzionava ma in modo piuttosto lento. Il tempo complessivo per ogni richiesta era dominato non tanto dalla velocità di generazione (token / s), quanto dal tempo di elaborazione del prompt iniziale. Osservando i log di LM Studio, notavo che per diverse richieste inviate dal router il modello doveva ricostruire da zero tutto il contesto — e questo è esattamente il punto in cui mi sono dovuto fermare a documentarmi / studiare il funzionamento della KV cache.

2. La questione della KV cache

Come detto la lentezza osservata non dipendeva tanto dal throughput di generazione, quanto da un fattore più nascosto: la KV cache.

In un modello transformer, ogni layer elabora una sequenza di token tramite il meccanismo di self-attention, che si basa su tre matrici di valori numerici:

• Q (Query),
• K (Key),
• V (Value).

Quando il modello genera un token, confronta il vettore Q di quel token con tutti i vettori K e V dei token precedenti per capire su quali “prestare attenzione”. In altre parole, le matrici Key e Value rappresentano la memoria a breve termine del modello: ogni token passato aggiunge una coppia (K, V) per ciascun layer.

Ricalcolare tutte queste coppie a ogni passo è computazionalmente molto pesante e per evitarlo, i motori di inferenza mantengono in memoria una cache KV, cioè una struttura che conserva i vettori K e V dei token già elaborati. Quando arriva un nuovo token, il modello valuta se può riusare direttamente questi dati senza ricomputarli da zero.

Chiaramente mantenere la cache richiede molta memoria, ma il risparmio di tempo ogni qual volta è possibile riusare dati dalla cache è immenso.

Per massimizzare l’utilizzo della cache, si utilizzano KV cache manager che utilizzano varie tecniche per identificare prompt con una parte di contesto identica o fortemente sovrapposta a quello di richieste precedenti, così da poter riutilizzare le informazioni contenute nella cache.

LM Studio si basa internalmente sulla libreria llama.cpp che mi risulta disporre di un meccanismo di KV cache, anche se non particolarmente avanzato. Sequenze di prompt profondamente differenti o semplicemente di lunghezza molto differente, invalidano facilmente la cache, portando a ricalcoli per ricostruire la rappresentazione interna del contesto, rieseguendo l’attenzione per tutti i token dei prompt. Su 64 k token di input, parliamo di diverse decine di secondi di lavoro aggiuntivo sul mio hardware.

Nel mio caso di test si verificava esattamente questo fenomeno, presumibilmente in relazione alla sequenza con cui i vari tipi differenti di prompt vengono generati ed inviati dal coding agent. Non ho fatto vera e propria analisi del traffico HTTP tra agente e modello, ma è abbastanza evidente che il router inoltra richieste tutt’altro che omogenee: ci sono chiamate che coinvolgono interi file, ragionamenti multi-step, sintesi di piani d’azione — e altre molto più brevi, che servono solo per gestire il flusso, interrogare lo stato, o verificare la disponibilità di tool. Sono proprio queste micro-richieste, alternate alle operazioni lunghe, che più frequentemente portano all’invalidazione della cache.

Questo spiega perché il tempo percepito “prima del primo token” è così alto.

3. Seconda configurazione: due istanze del modello

Dopo aver capito che la lentezza non dipendeva solo dal throughput, ma anche dal modo in cui la cache KV veniva continuamente invalidata, la direzione successiva era quasi obbligata: separare le richieste “piccole” da quelle “grandi”.

Decido quindi di ispirarmi all’architettura di Claude Code originale così come recepita nella configurazione del router: usare più modelli (o istanze dello stesso modello), ciascuno dedicato a un tipo di richiesta diverso.

Configurazione a due istanze

Nel mio caso, ho mantenuto gpt-oss-20b ma l’ho avviato due volte in LM Studio, con due profili distinti e due dimensioni massime di contesto differenti, rispettivamente 16 k e 64 k. Nel router la configurazione diventava:

{
   ...
  "Providers": [
    {
      "name": "lmstudio-small",
      "models": ["openai/gpt-oss-20b:2"],
      "default_params": { "max_tokens": 1024 }
    },
    {
      "name": "lmstudio-long",
      "models": ["openai/gpt-oss-20b"],
      "default_params": { "max_tokens": 32000 }
    }
  ]
  
  "Router": {
    "default": "lmstudio-small,openai/gpt-oss-20b:2",
    "background": "lmstudio-small,openai/gpt-oss-20b:2",
    "think": "lmstudio-long,openai/gpt-oss-20b",
    "longContext": "lmstudio-long,openai/gpt-oss-20b",
    "longContextThreshold": 3000,
    "webSearch": "lmstudio-small,openai/gpt-oss-20b:2",
    "image": "lmstudio-small,openai/gpt-oss-20b:2"
  }
  ...
}

Il router ora aveva due percorsi distinti:

• lmstudio-small gestiva le richieste veloci e di servizio (quelle che prima invalidavano più spesso la cache).
• lmstudio-long era riservato alle operazioni di reasoning esteso e alle generazioni di codice complesse.

Perché max_tokens diversi

Il parametro max_tokens definisce quanti token la risposta del modello può generare in un’unica inferenza. Ma questo valore incide direttamente anche su quanto spazio di cache viene riservato durante l’elaborazione: il motore deve infatti allocare la memoria necessaria non solo per il contesto in ingresso, ma anche per i token in uscita potenziali.

Un limite alto (come 32 k token) amplia la finestra di generazione ma aumenta la memoria preallocata per la KV cache; un limite basso (come 1024) riduce l’impatto sulla memoria e accelera la latenza di avvio, soprattutto se le richieste sono brevi.

In altre parole:

• lmstudio-small poteva permettersi di rispondere in modo rapido perché manteneva una cache ridotta, perfetta per prompt leggeri e brevi risposte.
• lmstudio-long, invece, era configurato per reasoning lunghi e poteva lavorare su contesti estesi, ma a costo di tempi di inizializzazione più alti e maggiore uso di memoria.

Risultati empirici

Con questa configurazione la differenza si è vista subito. Le operazioni leggere — ad esempio richieste di stato o piccole elaborazioni — diventavano quasi istantanee (2-3 secondi), mentre le sessioni reasoning lunghe restavano lente ma più prevedibili, e soprattutto nella maggior parte dei casi non influenzavano più le richieste successive (nel senso che non portavano ad invalidazione della cache).

L’agente, però, non riusciva ancora a completare correttamente il primo task del progetto — l’implementazione del rate limiting nel servizio — ma almeno ora il comportamento era più coerente e ripetibile, segno che la struttura di base era solida.

4. Esperimenti con Qwen 3

Ho provato a sostituire il modello con Qwen 3. Il primo tentativo con Qwen3-Coder-30B-AB3-Instruct non ha funzionato come speravo: ottimo sul codice, ma senza capacità reasoning sufficiente per la fase think. Sono quindi passato a Qwen3-30B-A3B-Instruct-2507, che migliora il precedente in particolare aggiungengo le capacità di reasoning.

La configurazione era la stessa: due istanze LM Studio, stesso schema di router. Le risposte migliorano, ma il ciclo completo (feature → test → doc) ancora non si chiudeva correttamente.

5. La soluzione finale: GPT-OSS-120B

A quel punto ho deciso di passare al livello successivo: GPT-OSS-120B, caricato in LM Studio sempre con Flash Attention attiva, tutti i layer in GPU e contesto massimo fissato a 64k. L’ho assegnato ai ruoli think e longContext nella configurazione del router, mantenendo gpt-oss-20b per le richieste leggere e di background.

{
  ...
  "Providers": [
    {
      "name": "lmstudio-small",
      "models": ["openai/gpt-oss-20b"],
      "default_params": { "max_tokens": 1024 }
    },
    {
      "name": "lmstudio-long",
      "models": ["openai/gpt-oss-120b"],
      "default_params": { "max_tokens": 32000 }
    }
  ]
  
  "Router": {
    "default": "lmstudio-small,openai/gpt-oss-20b",
    "background": "lmstudio-small,openai/gpt-oss-20b",
    "think": "lmstudio-long,openai/gpt-oss-120b",
    "longContext": "lmstudio-long,openai/gpt-oss-120b",
    "longContextThreshold": 3000,
    "webSearch": "lmstudio-small,openai/gpt-oss-20b",
    "image": "lmstudio-small,openai/gpt-oss-20b"
  }
  ...
}

Con questa configurazione i tempi di reasoning erano più stabili, il contesto mantenuto correttamente e, finalmente, il ciclo di sviluppo completato in modo coerente.

Il tempo medio per richiesta utente si è assestato intorno ai 30 secondi, con variazioni in base al tipo di operazione e al numero di file coinvolti. Un risultato tutt’altro che “snello”, ma perfettamente accettabile considerando che tutto girava su una singola macchina.

6. Considerazioni

Dopo vari giorni di prove, questi sono alcuni dei punti che mi porto a casa:

• Agentic coding è un carico completamente diverso dalla chat. Un agente deve pianificare, leggere e aggiornare continuamente il contesto, quindi non basta che il modello “si carichi e giri”.

• La memoria è spesso il collo di bottiglia. Ogni incremento nel contesto massimo si traduce in gigabyte di memoria aggiuntiva. La configurazione a due modelli descritta qui sopra portava la mia macchina ad utilizzare complessivamente attorno a 90 GB di memoria.

• Separare i modelli serve. Quantomeno per come pare essere il funzionamento di Claude Code, e in assenza di un KV cache manager evoluto, un setup multi-modello (piccolo + grande) aiuta a non invalidare continuamente la cache e migliora la reattività percepita.

• La velocità di generazione conta meno della latenza iniziale. In locale, l’attesa per il primo token è spesso il fattore dominante.

7. Conclusione

Mi sento di dire che portare un coding agent in locale (per singolo utente) oggi è sostanzialmente possibile, ma richiede hardware generoso, pazienza e un po’ di curiosità tecnica. Il risultato finale non sostituisce l’esperienza fluida di Claude Code utilizzato attraverso le API, ma permette di capire meglio cosa succede sotto il cofano: quali risorse servono, come incide il contesto, cosa fa la cache, etc. In termini di qualità nel coding, quanto proposto dal gpt-oss-120b è a prima vista buono, ma mi aspetto che al crescere della complessità del progetto, il divario con i risultati ottenibili utilizzando le API a modelli remoti si percepisca in modo evidente.

Infine, chiaramente la scelta di usare Claude Code Router nasceva dall’idea di provare uno scenario il più simile a quello testato nel post del mese scorso; per quanto l’idea di base del tool sia interessante, non è necessariamente la migliore per il caso d’uso descritto in questo post. Nelle prossime settimana non escludo di provare altri agenti, magari pensati proprio per l’esecuzione con modelli locali.

Mentre le news di nuovi servizi e funzionalità di Gemini, Claude, ChatGPT, etc. si susseguono, permane un certo interesse nella community a proposito di soluzioni per eseguire modelli di intelligenza artificiale generativa fuori dai grandi servizi cloud. L’obbiettivo in sostanza è far girare modelli open-weight – cioè con pesi pubblicamente scaricabili – sul proprio computer o in ambienti cloud “controllati”, dove si sceglie quale modello usare, con quali dati e con quali vincoli.

Ma perché dovremmo volerlo fare?

Perché scegliere un ambiente controllato

L’uso di servizi gestiti (come ChatGPT o Gemini) offre comodità e prestazioni, ma comporta anche limiti importanti:

• Controllo dei dati – i prompt, i file caricati e i risultati possono transitare su infrastrutture esterne, con implicazioni per la privacy o la proprietà intellettuale.
• Dipendenza dal provider – le API possono cambiare, i modelli essere aggiornati o rimossi senza preavviso.
• Costi e scalabilità – per usi intensivi o sperimentali, le tariffe possono diventare elevate.
• Limitazioni operative – molti servizi impongono limiti di contesto o non permettono l’esecuzione di modelli personalizzati.

Ecco perché si registra l’interesse per soluzioni “local-first”: esecuzione in locale o in ambienti controllati, cioè cloud indipendenti o container privati dove si gestisce interamente l’infrastruttura e i modelli.

Local vs. ambiente controllato: cosa significa davvero

Parlare di “locale” non vuol dire per forza “sul proprio portatile / desktop”. Esistono oggi due grandi categorie:

1. Esecuzione locale – tutto avviene sul proprio hardware, tipicamente con GPU o NPU dedicate.
2. Esecuzione in ambienti controllati – si usano risorse cloud, ma mantenendo pieno controllo su modelli, codice e dati.

Alcuni servizi noti per quest’ultimo approccio:

• RunPod e TensorDock – ambienti GPU “pay-per-minute” per LLM e Stable Diffusion, con possibilità di personalizzare container e storage.
• RunComfy – piattaforma pronta per flussi ComfyUI, utile per generazione di immagini e video.
• Vast.ai e Lambda Cloud – soluzioni per affittare GPU a breve termine, con immagini preconfigurate per PyTorch, Diffusers e llama.cpp.

Queste opzioni offrono un buon equilibrio tra libertà e semplicità: il modello gira su macchine “tue” (o quasi), ma non devi preoccuparti di raffreddamento, alimentazione o driver.

I limiti: prestazioni, qualità, contesto

Naturalmente, eseguire in locale o in ambienti controllati non è gratis — in termini di potenza e maturità del software:

• Velocità: un LLM da 70–120B può raggiungere solo pochi token/s su GPU consumer.
• Qualità: i modelli open-weight più accessibili (Mistral, LLaMA, Gemma, Qwen, Flux) tipicamente non eguagliano GPT-4 o Gemini 2.5.
• Contesto limitato: 4k–32k token tipici, contro i 128k–1M dei modelli gestiti.
• Concorrenza: in un setup locale si può gestire solo un numero ridotto di richieste contemporanee.

Per questo, l’uso locale si presta bene a:

• prototipazione e ricerca,
• automazioni personali,
• sperimentazione su dati sensibili,
• edge computing o applicazioni offline.

A livello enterprise, invece, gli ambienti controllati permettono di costruire pipeline AI interne, con costi prevedibili e modelli verificabili.

Eseguire modelli in locale: la questione hardware

E qui arriviamo al nodo centrale: la memoria video (VRAM). La VRAM determina la dimensione massima del modello che si può caricare e la sua velocità di inferenza.

• Le GPU consumer (NVIDIA RTX 4090 o AMD 7900 XTX) arrivano a 24–32 GB di VRAM: già sufficienti per modelli da 7–13B, ma non oltre.
• Oltre questa soglia servono schede professionali o soluzioni con memoria condivisa, che unificano RAM e VRAM.

Memoria condivisa: un cambio di paradigma

Negli ultimi anni la distinzione tra RAM di sistema e VRAM della GPU si sta assottigliando. Nei sistemi tradizionali CPU e GPU hanno memorie fisiche separate: per elaborare un modello, i dati devono essere copiati avanti e indietro tra i due spazi, con un notevole costo in termini di banda e latenza. Le nuove architetture invece puntano a unificare la memoria, permettendo a CPU e GPU di accedere allo stesso spazio fisico, in modo coerente e ad altissima velocità. È un cambiamento che semplifica il calcolo e apre scenari nuovi per l’esecuzione di modelli AI di grandi dimensioni, anche su macchine compatte.

Tre approcci oggi particolarmente interessanti:

🧩 Apple Silicon (M3, M4, M4 Pro)

Apple è stata la prima a portare su larga scala il concetto di Unified Memory Architecture (UMA): CPU, GPU e Neural Engine condividono la stessa memoria fisica, a banda elevata (fino a 120 GB/s). Questo elimina la necessità di copiare i dati tra dispositivi e rende possibile caricare interamente un modello di grandi dimensioni (come un LLM da 13B) in un’unica area di memoria. L’efficienza energetica è eccellente, ma la memoria è saldato-on-chip e quindi non espandibile; i tagli disponibili (fino a 48–64 GB nelle versioni Pro/Max) restano piuttosto costosi.

⚡ NVIDIA DGX Spark (Grace Blackwell GB10)

Il DGX Spark, presentato al GTC 2025, rappresenta il primo sistema “personale” della linea DGX. Basato sul superchip NVIDIA GB10 Grace Blackwell, integra una CPU Grace a 20 core (10 Cortex-X925 + 10 Cortex-A725) e una GPU Blackwell di quinta generazione in un singolo package. Le due unità condividono 128 GB di memoria LPDDR5X coerente tramite NVLink-C2C, che fornisce una banda fino a 5× superiore a PCIe Gen 5. Il risultato è un modello di memoria CPU+GPU realmente unificato, con accesso coerente e senza copia dei tensor, capace di gestire fino a 200 miliardi di parametri (o 405B collegando due sistemi via ConnectX a 200 Gbps). Con un assorbimento di circa 240 W e dimensioni da mini-desktop (15 × 15 × 5 cm), il DGX Spark è una sorta di “AI workstation da scrivania”, ponte diretto tra le architetture UMA di Apple e i supercluster Grace Hopper dei data center.

🔥 AMD Ryzen™ AI Max+ 395 (Strix Halo)

Strix Halo segue una logica simile, ma in ambito consumer e con architettura x86. È una APU monolitica che integra CPU Zen 5 e GPU RDNA 3.5, condividendo fino a 128 GB di memoria LPDDR5X con banda teorica di 250–300 GB/s. Non ha VRAM dedicata: la GPU può allocare dinamicamente porzioni della RAM di sistema, come avviene nei Mac. Questo approccio consente di eseguire modelli di grandi dimensioni senza schede video discrete, con un ottimo compromesso tra prestazioni, costi e consumo energetico.

La mia esperienza con AMD Ryzen™ AI Max+ 395 (128 GB)

Sto sperimentando proprio questa piattaforma; esistono diverse soluzioni in commercio, io ho scelto frame.work desktop nella versione con 128GB di memoria. Come sistema operativo, utilizzo unicamente Linux.

Uno dei vantaggi è che, pur potendo configurare nel BIOS la quantità di memoria riservata alla GPU (ad esempio 512 MB), Linux gestisce dinamicamente la condivisione RAM/VRAM, come avviene nei sistemi Apple. Per ottenere buone prestazioni è necessario impostare alcuni parametri del kernel relativi all’allocazione (nello specifico amdgpu.gttsize e ttm.pages_limit).

Il supporto software è in piena evoluzione:

• Kernel 6.18 introdurrà correzioni importanti per la gestione della memoria su Strix Halo.
• Driver Mesa e ROCm hanno guadagnato fino al +25 % di performance negli ultimi mesi.
• Tuttavia, instabilità e driver sperimentali rendono l’esperienza ancora poco “plug and play”.

Il bilancio complessivo è positivo: un rapporto costo/prestazioni molto interessante per chi vuole sperimentare LLM e modelli generativi senza GPU dedicate.

Toolbox e primi test pratici

Un ottimo punto di partenza sono le toolbox su GitHub di Donato Capitella, che semplificano l’esecuzione (ottimizzata per questo specifico hardware AMD) di llama.cpp, Qwen Image Studio, Wan Video Studio e ComfyUI.

Ecco ad esempio un benchmark di esecuzione di GPT-OSS 120B con llama-bench, con il backend Vulkan abilitato:

Interfaccia di generazione immagini Qwen Image Studio:

E un workflow di generazione ibrido con Flux Krea Dev dentro ComfyUI:

Considerazioni sulle configurazioni

Un aspetto curioso su Strix Halo: spesso le quantizzazioni BF16 risultano più efficienti di FP8, nonostante l’apparente “maggiore precisione”. Questo dipende dall’implementazione dei driver ROCm e dal modo in cui viene gestita la memoria condivisa: le operazioni FP8, pur teoricamente più leggere, introducono overhead nella conversione e nella gestione dei buffer.

Conclusione e prospettive

Eseguire modelli AI in locale o in ambienti controllati significa riappropriarsi del controllo su dati, costi e infrastruttura. Chiaramente non è ancora un percorso lineare: servono competenze tecniche, pazienza e una certa tolleranza ai bug quando si ha a che fare con driver e librerie sperimentali. Infine, in ambito consumer le soluzioni con memoria unificata e toolkit open-source consentono di ottenere risultati di discreta qualità in tempi ragionevoli.

Nei prossimi post racconterò alcuni use case concreti su Strix Halo, con esempi di automazione locale e generazione di contenuti multimodali.