Fable e Sol a confronto: due cartoni animati creati su un PC con RTX 3090

Nell'ultimo articolo su GPT-5.6 avevo scritto che il test che conta non è quello scelto dal laboratorio, ma quello fatto sui propri compiti reali. Avevo anche promesso di confrontare il nuovo ecosistema di ChatGPT con Fable 5 di Anthropic. Nel frattempo, sul disco del mio computer si era formato un test molto più ingombrante di una domanda a un chatbot.

Ci sono due cartoni animati, due applicazioni che dovrebbero produrne altri e una quantità imbarazzante di immagini, file temporanei, registri degli errori e versioni intermedie. Nel primo film Anna ha nove anni, ama i dinosauri e scopre che PIP, un pappagallo digitale, può rispondere con sicurezza anche quando sbaglia. Nel secondo il protagonista è Martino, l'assistente si chiama TOBI e il problema educativo è simile: capire che una risposta ben formulata non è automaticamente una risposta vera.

Il primo sistema si chiama Storyboard Studio ed è stato costruito dialogando con ChatGPT/Codex. Il secondo si chiama Fucina ed è nato dal lavoro affidato a Fable 5 di Anthropic. Entrambi hanno usato lo stesso computer, con una GeForce RTX 3090 da 24 GB, e la stessa famiglia di strumenti locali: FLUX per creare le tavole, LTX-2.3 per animarle, ComfyUI per eseguire i workflow e FFmpeg per montare il risultato.

I due agenti non si sono limitati a scrivere qualche riga di codice. Hanno progettato la pipeline, prodotto e corretto l'applicazione, preparato i prompt, diagnosticato crash, organizzato i file e portato il lavoro fino a un video finale. È esattamente il tipo di attività lunga e concreta che i benchmark sintetici misurano male.

La conclusione, per chi vuole saltare direttamente alla fine, è questa: Storyboard Studio è il progetto complessivamente migliore, ma vince con un margine stretto. Fucina è più espressiva, più musicale e molto più efficiente nel calcolo. Storyboard Studio è più coerente nel tempo, più verificabile e più vicino a una piattaforma riutilizzabile.

• Prima avvertenza: questo non è un benchmark scientifico
• Due modi opposti di fabbricare il tempo
• I numeri dei due master
• Fucina vince l'impatto, soprattutto all'inizio
• Storyboard Studio perde il trailer e vince la continuità
• Le app: una demo elegante e un laboratorio più robusto
• Il costo locale non compare sulla carta di credito, ma esiste
• Il verdetto: Storyboard Studio, di stretta misura
• Metodologia e materiali
• Una scena da dieci secondi non è una richiesta piccola
• Perché tanti pezzi piccoli
• Come si uniscono 252 generazioni senza mandare il tempo al contrario
• Perché ho scartato il raffinamento più sofisticato
• Quattordici ore e sette decimi non sono la durata del progetto
• Il master finale conserva anche i compromessi
• Locale e API comprano cose diverse
• Che cosa rifarei nello stesso modo

Prima avvertenza: questo non è un benchmark scientifico

Non ho dato ai due sistemi lo stesso prompt, lo stesso seme, gli stessi personaggi e un identico numero di ore. Le storie non coincidono, i cicli di correzione sono stati diversi e le applicazioni sono state costruite mentre producevano il loro primo film. Fucina ha anche addestrato una LoRA specifica per Martino e TOBI; Storyboard Studio ha lavorato soprattutto con immagini di riferimento e una catena molto più lunga di segmenti.

Questo confronto non stabilisce quindi che "ChatGPT è migliore di Claude" o viceversa. Non separa nemmeno con rigore la qualità del modello dalla qualità delle mie richieste e dalle scelte maturate lungo la lavorazione. È un confronto di due progetti reali, sullo stesso hardware e con un obiettivo comparabile: costruire una piccola fabbrica locale di video educativi, non soltanto generare una clip da mostrare sui social.

Ho distinto tre livelli: il processo necessario per arrivare al risultato; l'app che dovrebbe rendere il processo ripetibile; il video finale, misurato e poi guardato per intero. I numeri vengono dai file e dai log conservati nei due progetti. Le valutazioni estetiche, invece, restano valutazioni: per questo le dichiaro come tali.

Un'altra precisazione è importante. ChatGPT/Codex e Fable 5 non hanno disegnato direttamente ogni fotogramma. Sono stati progettisti e orchestratori. Le immagini vengono da FLUX.1, il movimento da LTX-2.3, il miglioramento dei segmenti di Storyboard Studio da Real-ESRGAN. ComfyUI collega i nodi e FFmpeg assembla audio e video. La domanda corretta non è quindi quale agente sappia "disegnare meglio", ma quale sia riuscito a organizzare meglio la fabbrica.

Due modi opposti di fabbricare il tempo

Fucina usa una soluzione economicamente brillante. Il film dura 6 minuti e 44 secondi ed è diviso in 17 scene, ma il sistema ha generato soltanto 19 clip da 5,04 secondi. Il movimento originale ammonta a circa 95,8 secondi, meno di un quarto della durata finale.

Per coprire la voce, ogni clip viene riprodotta in avanti e poi al contrario, rallentata di 1,6 volte e ripetuta. È il corrispettivo digitale di una scenografia teatrale riutilizzata: con poco materiale si copre molto tempo. Il vantaggio è evidente. Si risparmiano ore GPU, si riduce il numero di generazioni che possono fallire e si ottiene subito un gesto abbastanza ampio da sembrare animazione.

Lo svantaggio emerge quando si guarda il film, invece del trailer. Una mano si alza e poi torna esattamente indietro; uno sguardo cambia direzione e subito annulla il movimento; il corpo oscilla come un pendolo. Il tempo audiovisivo continua, ma quello del personaggio è una sorta di "ping-pong" avanti e indietro.

Storyboard Studio sceglie il problema opposto. Divide 6 capitoli in 36 scene e genera 252 segmenti. Ogni segmento contiene 49 fotogrammi a 25 fps, quindi dura circa 1,96 secondi. Il segmento successivo riparte dall'ultimo fotogramma del precedente; Real-ESRGAN interviene sui risultati e il montaggio li concatena senza invertirli.

Il movimento grezzo supera i 493 secondi, abbastanza per coprire praticamente tutto il film di 7 minuti e 39 secondi. La freccia del tempo non torna indietro, ma il costo computazionale cresce di oltre cinque volte rispetto alla quantità di movimento originale di Fucina.

Perché non generare direttamente clip da trenta secondi? Perché un modello video da 22 miliardi di parametri su una GPU con 24 GB non si comporta come una videocamera. Allungare una generazione aumenta la memoria richiesta, il tempo perso in caso di crash e la probabilità che il volto, gli abiti o la geometria della scena cambino durante la stessa ripresa. Con segmenti brevi si può rigenerare soltanto il pezzo difettoso e riprendere dopo un errore. In cambio si moltiplicano le giunzioni e la deriva può accumularsi da un tratto al successivo.

Fucina accetta la ripetizione pur di spendere poco. Storyboard Studio accetta la complessità pur di far procedere il movimento sempre in avanti. Gran parte del verdetto nasce da questa scelta.

I numeri dei due master

Fucina: composizione più teatrale e movimento più deciso.

Storyboard Studio: tavola più stabile e costruzione didattica più leggibile.

La misura con mpdecimate non assegna un voto alla bellezza: stima quanti fotogrammi restano dopo aver eliminato quelli abbastanza simili da apparire duplicati. Il 58,8% di Fucina è coerente con rallentamenti, ripetizioni e inversioni. L'82,9% di Storyboard Studio indica un flusso più continuamente variabile. Anche la misura di immobilità va letta con cautela, perché una tavola può restare quasi ferma mentre piccoli elementi si muovono. Serve solo a descrivere il montaggio e non a sostituire la visione.

Storyboard Studio consegna un master Full HD H.264 da circa 9 Mbit/s, molto più definito, ma anche quasi sei volte più pesante. Per la pubblicazione web servirebbe una copia compressa. Il file dichiara inoltre 30 fps, mentre i segmenti sono nati a 25: nel passaggio vengono inseriti duplicati regolari. Sarebbe più corretto esportare a 25 fps o applicare una vera interpolazione, invece che limitarsi a cambiare il contenitore.

Fucina vince l'impatto, soprattutto all'inizio

Se mostrassi trenta secondi dei due film durante una presentazione, sceglierei Fucina. Le tavole sono calde, la composizione è cinematografica, i personaggi compiono gesti più ampi. Sei profili vocali, ricavati da quattro voci Edge, danno ai dialoghi una parvenza di recitazione; musica e dissolvenze completano l'illusione. La quantità di emozione ottenuta per secondo calcolato è notevole.

Anche il valore mediano del movimento misurato fra fotogrammi è superiore: 9,74 contro 7,59. Non significa automaticamente "animazione migliore", ma conferma quello che l'occhio vede: Fucina muove di più il soggetto nei brevi tratti che genera. Storyboard Studio spesso anima foglie, occhi, carta, luce e dettagli dello sfondo, mentre Anna conserva una posa prudente.

Il problema di Fucina è la tenuta sulla distanza: le scene durano mediamente quasi 24 secondi, ma quasi tutte dispongono di circa cinque secondi originali. Dopo qualche ciclo il trucco diventa leggibile. Otto blocchi di almeno un secondo risultano sostanzialmente immobili, per 13,32 secondi complessivi; il più lungo dura 3,2 secondi.

La LoRA specifica, addestrata per circa 2 ore e 10 minuti con 23 coppie immagine-didascalia, 2.000 passi e rango 16, migliora la riconoscibilità ma non la garantisce. TOBI appare per gran parte del film come un pappagallo verde o turchese con grandi occhiali rossi e nel finale diventa un uccello rosso senza occhiali. Martino cambia abiti, proporzioni e in alcuni passaggi stile grafico. La scena conclusiva conserva perfino "Fine della prima parte. Nella prossima puntata", prima che la seconda parte inizi immediatamente.

L'audio aiuta la recitazione ma è troppo basso: −26,6 LUFS. Occorre alzare sensibilmente il volume rispetto a Storyboard Studio, che si trova a −18,2 LUFS. La musica migliora l'atmosfera, ma è semplice e ripetitiva.

Fucina è dunque il progetto che capisce meglio il trailer e peggio la lunga durata. Non è una bocciatura: ottenere quell'impatto con 19 clip è una soluzione ingegnosa. È però una soluzione che mostra il proprio meccanismo quando il racconto supera i sei minuti.

Storyboard Studio perde il trailer e vince la continuità

Storyboard Studio è meno teatrale. Anna resta però riconoscibile lungo 36 scene: capelli castani, fiore rosa, abito viola, età e stile generale cambiano meno di Martino. PIP continua a essere instabile (a volte pappagallo, a volte quasi gufo, a volte creatura verde molto semplificata) ma non viene sostituito nettamente nel finale come TOBI.

Il movimento procede sempre in avanti e i blocchi immobili rilevati scendono a 3,17 secondi complessivi. La corrispondenza fra testo e immagini è più fitta, perché le scene sono più del doppio. Sei intestazioni di capitolo aiutano inoltre a seguire una storia pensata per un bambino.

Storyboard Studio rispetta meglio anche il brief pedagogico. L'errore di PIP non è una nota, ma lo snodo della trama. Anna verifica l'informazione, non consegna dati privati, rifiuta di farsi fare tutto il compito e formula lei l'idea finale. Questo non dipende soltanto dall'animazione, ma indica che il sistema ha conservato più fedelmente i vincoli del progetto lungo la produzione.

L'audio, però, rivela un bug importante. L'app supporta ruoli e voci differenti, ma tutte le porzioni di dialogo sono finite sotto il ruolo del narratore. Il master usa quindi una sola voce. La traccia è tecnicamente stereo, ma sostanzialmente dual mono; mancano musica ed effetti e sono stati misurati 145,95 secondi sotto −45 dB. Le pause aiutano la comprensione, ma senza un ambiente sonoro fanno sembrare il montaggio incompleto.

Anche il video non è un cartone animato tradizionale. Mani, occhi, corna e piccoli oggetti oscillano; alcuni dinosauri cambiano geometria; compaiono frammenti colorati senza una funzione narrativa. È un motion storybook, un albo illustrato in movimento, non un film con labiale e recitazione continua.

Storyboard Studio vince perché il suo difetto principale è correggibile senza cambiare l'architettura: servono più regia nei prompt, musica, voci correttamente assegnate e un montaggio audio migliore. In Fucina, invece, eliminare il ping-pong significa generare più movimento e quindi modificare il compromesso centrale della pipeline.

Le app: una demo elegante e un laboratorio più robusto

Fucina dispone il lavoro in cinque passaggi: storia, tavole, clip, voci e film. L'interfaccia è compatta, consente di rigenerare un singolo elemento e rende visibile una buona regola: la macchina propone, la persona approva. È il progetto più semplice da capire guardando lo schermo.

La portabilità, però, è in gran parte apparente. Il pacchetto pesa circa 32 kB, contiene 17 file e presume che sul computer esistano Python, ComfyUI, FFmpeg, nodi aggiuntivi e circa 53 GB di modelli. Contiene percorsi rigidi verso E:\StorybookAI, E:\Fucina e D:\ComfyUI; il workflow predefinito richiede la LoRA di Martino e TOBI, che non fa parte del pacchetto. Nella cartella progetti non c'è una produzione completa generata dall'app confezionata, quindi manca la prova end-to-end su un soggetto nuovo.

Non ci sono test automatici. Lo stato dei lavori vive in memoria, la cache è condivisa, un file esistente può essere scambiato per un risultato valido e un montaggio può risultare completato anche se alcune scene sono state saltate. Il wizard ignora i paragrafi più corti di 40 caratteri e tronca il progetto a 15 scene. Fucina è una buona prova di concetto personale, non ancora un prodotto distribuibile.

Storyboard Studio usa sei fasi guidate e aggiunge controlli dei prerequisiti, diagnostica, manifest, checksum, ripresa dei lavori interrotti, stime di tempo e un quality gate. Il pacchetto pesa circa 185 MB e i 21 test automatici risultano superati. I 252 segmenti hanno nomi deterministici e la pipeline sa ripartire da ciò che manca: con Windows, CUDA e memoria virtuale messi alla prova più volte, non è un dettaglio.

Neppure questa è un'app "un clic". Non include ComfyUI, FFmpeg e i modelli. Alcune impostazioni richiedono ancora la modifica di project.json; una cache può diventare obsoleta dopo aver cambiato prompt o protagonista; il pulsante di arresto non interrompe necessariamente il lavoro già consegnato a ComfyUI.

Ci sono inoltre due bug molto concreti. Il pannello dei costi cerca il campo generation_seconds, mentre i dati prodotti usano seconds: un progetto finito può quindi mostrare circa 1,55 ore invece di oltre 12,8. Nel pacchetto, il launcher dal nome più intuitivo richiama uno script assente; l'altro funziona. Sono difetti correggibili, ma impediscono di raccontare Storyboard Studio come un prodotto finito.

La differenza è questa: Fucina è più elegante come idea di interazione; Storyboard Studio è più seria come infrastruttura operativa. Nessuna delle due è ancora pronta per un genitore o un insegnante che non sappia cosa siano VRAM, modelli e pagefile. Storyboard Studio è però più vicina a diventarlo.

Il costo locale non compare sulla carta di credito, ma esiste

Per Storyboard Studio i log misurano circa 22 minuti per le 36 tavole FLUX, 71 minuti per le clip guida, 11,29 ore per 246 segmenti LTX registrati e 1,55 ore per Real-ESRGAN. Stimando i sei segmenti privi di metrica, una corsa lineare riuscita richiede circa 14,7 ore di calcolo. La produzione reale ha occupato oltre 60 ore di calendario fra crash, riavvii e riprese. Il progetto completo raggiunge circa 2,54 GiB e 2.667 file.

Fucina genera molto meno video, ma è nata non senza attrito: 52 file di log, otto versioni della prima parte, quattro della seconda, riparazioni e blocchi di memoria. Il lavoro si è esteso su più giorni, oltre alle due ore e dieci minuti della LoRA.

Non ho un contatore energetico né registri comparabili dei token consumati dai due agenti, quindi non attribuisco un prezzo preciso. "Senza costo per clip" non vuol dire gratis: servono hardware, corrente, spazio, configurazione e tempo umano. Dall'altra parte, confrontare il tutto con un'API esterna senza fissare provider, modello, risoluzione, durata e numero di rigenerazioni produrrebbe una cifra ornamentale, non un dato.

Il vantaggio del locale è il controllo: i file restano disponibili, la pipeline è ispezionabile e non si dipende da crediti per ogni tentativo. Lo svantaggio è che l'utente diventa anche il reparto informatico. E "locale" non è assoluto: Edge TTS invia il testo a Microsoft, mentre gli agenti che hanno scritto il software lavorano nel cloud. Tavole, movimento e montaggio sono locali; non lo è necessariamente l'intera catena.

Il verdetto: Storyboard Studio, di stretta misura

Fucina: nel finale TOBI cambia colore e perde gli occhiali.

Storyboard Studio: Anna resta riconoscibile, con piccoli artefatti decorativi.

Se dovessi mostrare trenta secondi, sceglierei Fucina. Se volessi ottenere il massimo impatto con il minimo movimento generato, sceglierei ancora Fucina. Le sue voci, la musica e i gesti ampi fanno sembrare vivi i personaggi prima che si notino le ripetizioni.

Se dovessi scegliere il sistema da usare per il prossimo film, sceglierei Storyboard Studio.

Non perché ogni suo fotogramma sia migliore: non lo è. Ha una sola voce, non ha musica, il movimento è troppo spesso decorativo, il master è sovradimensionato e PIP cambia aspetto più del dovuto. Vince perché affronta meglio i problemi che compaiono quando il risultato non è una clip ma un racconto di quasi otto minuti: continuità temporale, stabilità del protagonista, ripresa dopo un crash, tracciabilità dei materiali, aderenza al brief e possibilità di diagnosticare ciò che manca.

Il margine resta stretto perché Storyboard Studio ha generato più di cinque volte il movimento originale senza produrre cinque volte l'emozione. Fucina dimostra che regia, voce e musica valgono più del numero di fotogrammi. La versione ideale prenderebbe la continuità, i controlli e la struttura di Storyboard Studio; aggiungerebbe l'economia, le voci e l'atmosfera di Fucina; esporterebbe a 25 fps reali, normalizzerebbe l'audio, aggiungerebbe sottotitoli e permetterebbe di sostituire il protagonista da una sola schermata.

Quella versione non esiste ancora.

Esistono però due applicazioni imperfette e due film completi, costruiti su un computer domestico da una persona che non avrebbe potuto scriverne da sola l'intera infrastruttura. È un risultato più interessante del vincitore. I nuovi agenti non eliminano la necessità di competenza: spostano la persona dal lavoro di esecuzione a quello di specifica, verifica e giudizio. Quando la verifica manca, resta una demo. Quando c'è, può nascere uno strumento.

In questo caso Fable 5 ha costruito la dimostrazione più brillante. ChatGPT/Codex ha costruito il laboratorio più affidabile. Per ora, e per poco, vince il laboratorio.

Metodologia e materiali

• Master originale di Storyboard Studio: MP4 H.264 Full HD, durata 7:38,592, conservato come riferimento per le verifiche tecniche.
• Master originale di Fucina: MP4 H.264 1280×720, durata 6:43,950, conservato come riferimento per le verifiche tecniche.
• Copie web dei due film: versioni ricodificate e alleggerite per la pubblicazione, affiancate dal pilot Storyboard Studio da 49 fotogrammi.
• Applicazioni e manuali: pacchetto di Storyboard Studio 0.5.0, pacchetto di Fucina e relativa documentazione d'installazione e d'uso.
• Dossier di produzione: rapporti tecnici, registri delle generazioni, tempi, configurazioni, problemi incontrati e procedure di ripresa.
• Dossier comparativo consegnato alla redazione: analisi strumentale dei master, fotogrammi di controllo, contact sheet e articolo di sintesi in formato Word.
• Pagina ufficiale Fable 5 di Anthropic
• Repository ufficiale FLUX.1
• Documentazione open source LTX-2.3
• Documentazione ufficiale ComfyUI
• Repository ufficiale Real-ESRGAN

Le misure riportate derivano dai file finali e dai log conservati nei due progetti. Freeze e fotogrammi duplicati sono stati stimati con strumenti FFmpeg; i livelli audio sono espressi in LUFS. Non è stato condotto un test cieco con un campione di spettatori e non sono state effettuate nuove generazioni per uniformare prompt, semi o tempi di calcolo. Il giudizio estetico resta quindi quello dell'autore, separato dai dati tecnici.

Le 36 tavole del progetto Storyboard Studio in un unico foglio di controllo.

Contact sheet generato dal progetto effettivo.

Il video finale dura 7 minuti e 39 secondi. È diviso in sei capitoli e 36 scene, è codificato in Full HD e racconta la storia di Anna, nove anni, che usa un assistente digitale per preparare una ricerca sui dinosauri. A un certo punto l'assistente sbaglia, Anna controlla su un'enciclopedia e la storia prosegue.

La parte meno lineare è ciò che è successo dietro le immagini. Per mantenere le scene in movimento per quasi tutta la loro durata non ho generato 36 clip, una per scena. Ne ho generate 252, ognuna lunga meno di due secondi, poi le ho migliorate e concatenate.

Non è una scelta che consiglierei in astratto. È la soluzione che ha reso possibile il progetto sulla macchina disponibile: un PC Windows con 32 GB di RAM e una GeForce RTX 3090 da 24 GB. Il modello video era LTX-2.3 22B Dev in versione Q4_K_M, eseguito localmente dentro ComfyUI. La sigla 22B indica un modello da circa 22 miliardi di parametri; la quantizzazione Q4_K_M ne comprime i pesi abbastanza da farlo entrare, a fatica, nella memoria della scheda.

Questa non è la cronaca di un benchmark controllato. Non ho confrontato modelli diversi usando lo stesso seme, lo stesso prompt e lo stesso tempo macchina. È una ricostruzione ingegneristica di un progetto reale, basata sui file finali, sui workflow salvati e sui tempi registrati durante la produzione. Racconta perché una pipeline locale ha assunto questa forma, dove ha funzionato e che cosa ha fatto perdere per strada.

Una scena da dieci secondi non è una richiesta piccola

Il film era nato come albo illustrato narrato. Avevo 36 tavole, una voce sintetica e un montaggio statico con piccoli zoom e panoramiche. Era leggibile, ma le persone non si muovevano davvero. Il primo passaggio a un modello video ha risolto soltanto metà del problema: una tavola diventava una clip animata, ma la clip durava uno o due secondi. La voce, invece, poteva occupare dieci, quindici o venti secondi.

Le soluzioni da montaggio sono immediate. Si può ripetere il frammento in ciclo, riprodurlo in avanti e al contrario oppure rallentarlo. Le ho provate tutte. Il ciclo rendeva il gesto meccanico; il ping-pong faceva tornare indietro mani, sguardi e pagine; lo slow motion aumentava gli artefatti, perché i fotogrammi intermedi non erano pose realmente disegnate dal modello. Una mano deformata non diventava più naturale: rimaneva deformata più a lungo.

La richiesta corretta sembrava allora: generiamo direttamente tutta la scena. A 25 fotogrammi al secondo, dieci secondi significano circa 250 frame. Il segmento scelto per il progetto ne contiene 49. Dura quindi:

Cinque volte più durata non significa soltanto attendere cinque volte di più. Un modello generativo deve mantenere e trasformare una rappresentazione temporale della scena. Crescono il fabbisogno di memoria, i calcoli e le occasioni in cui volto, mani, vestiti e oggetti possono cambiare identità.

Nei test a 33 e 49 frame il workflow LTX a due stadi è arrivato a oltre 24,1 GB di VRAM osservata, cioè praticamente al limite della RTX 3090. In una prova corretta a 33 frame rimanevano circa 471 MB liberi nel momento di picco. Aumentare insieme durata e risoluzione non sarebbe stato prudente; chiedere 250 frame nelle stesse condizioni non era un semplice passo successivo.

La frammentazione ha risolto quattro problemi diversi.

Perché tanti pezzi piccoli risolvono diversi problemi

Il primo problema risolto è la memoria. Quarantanove frame erano una dimensione che la macchina riusciva a gestire, purché eseguisse un solo lavoro pesante alla volta. Il margine era ridotto, ma esisteva.

Il secondo è la deriva. LTX non sposta soltanto i pixel come un programma di compositing: interpreta e ridisegna progressivamente la scena. Più a lungo procede, più può spostare il fiore tra i capelli di Anna, cambiare l'espressione, trasformare una matita o aggiungere un dito. Limitare ogni tratto a 1,96 secondi riduce la distanza che il modello deve percorrere prima di essere riancorato a un fotogramma controllato.

Il terzo è il costo dell'errore. In un segmento del pilot Anna compariva doppia nei fotogrammi centrali, come in una fotografia mossa. Ho modificato il prompt, ridotto il movimento richiesto e cambiato il seme casuale. Ho rigenerato meno di due secondi. Se il difetto fosse apparso al nono secondo di una generazione lunga, avrei dovuto buttare l'intera scena.

Il quarto è la ripartenza dopo un crash. Python e ComfyUI si sono chiusi più volte. Salvando ogni segmento appena completato, un arresto al numero 173 lasciava validi i primi 172. Il batch successivo poteva cercare i file già presenti e ripartire dal lavoro mancante. Una singola generazione interrotta al 90% avrebbe lasciato, nella maggior parte dei casi, poco o nulla di utilizzabile.

Questa è la differenza tra ottimizzare soltanto per la velocità e progettare anche per il guasto. I 252 file non erano soltanto contenuto video: erano altrettanti checkpoint.

Come si uniscono 252 generazioni senza mandare il tempo al contrario

Il progetto contiene sei capitoli e sei scene per capitolo. La durata di ogni scena deriva dalla narrazione. I capitoli più lunghi richiedono più segmenti:

Per ogni scena esisteva una clip guida breve. Da questa venivano estratti quattro fotogrammi chiave, alle posizioni 0, 11, 22 e 32. Le rotte seguivano una sequenza ciclica, per esempio 0→11, 11→22, 22→32 e poi verso pose già note.

Il punto importante è che ogni tratto era una nuova generazione forward, condizionata da un'immagine iniziale e da una finale. Il file video non veniva mai riprodotto al contrario. Anche quando la posa-obiettivo tornava simile a una precedente, il modello generava un nuovo movimento nella direzione normale del tempo.

Due segmenti adiacenti condividevano un fotogramma. Durante l'assemblaggio eliminavo il primo frame del segmento successivo, evitando di mostrarlo due volte. Il risultato non era invisibile in ogni giunzione: piccoli dettagli potevano cambiare e l'immagine poteva "respirare". Ma non c'era più il gesto che avanzava e arretrava in modo identico.

La prima scena completa è stata il banco di prova. Sei segmenti, 261 frame, 25 fps, 10,44 secondi e cinque giunzioni controllate visivamente. Solo dopo aver verificato quel pilot il metodo è stato esteso agli altri 35 shot.

La prima scena continua: fotogrammi di controllo attraverso cinque giunzioni. La scena 01-01 unisce sei segmenti generati in avanti.

Perché ho scartato il raffinamento più sofisticato

Il workflow LTX previsto inizialmente era a due stadi. Il primo generava a risoluzione ridotta; il secondo ingrandiva il latente e applicava una LoRA distilled per rifinire il video. In teoria era il percorso più elegante per arrivare a 1280×720.

Ho provato anche a separare i due stadi in processi distinti: salvare il latente base, chiudere il primo processo, ricaricarlo e applicare il refiner con più margine di memoria. La procedura ha effettivamente ridotto la pressione sulla VRAM e sul commit di Windows. Non ha però superato il controllo visivo.

Con due guide temporali, il refiner introduceva scie e trasformazioni incoerenti nei fotogrammi in movimento. Il grafico della memoria era migliore; il video era peggiore. È un caso utile perché mostra quanto sia facile ottimizzare la metrica sbagliata.

La pipeline di produzione è diventata più semplice:

1. LTX genera 49 frame a 640×384;
2. il segmento viene controllato;
3. Real-ESRGAN Anime 6B migliora i singoli fotogrammi;
4. FFmpeg ridimensiona a 1280×768 e ritaglia il centro a 1280×720;
5. i segmenti vengono concatenati a 25 fps;
6. il montaggio finale porta la scena nel master 1920×1080.

Real-ESRGAN non corregge un movimento sbagliato e non ricostruisce una mano. Rende più nitidi i frame che riceve, senza reinventare la dinamica. Nel pilot richiedeva circa 24 secondi per segmento e meno di 4,6 GB di VRAM. Era molto più leggero del modello video e, soprattutto, non aggiungeva le scie prodotte dal refiner latente.

Segmento LTX base prima del miglioramento.

Lo stesso segmento dopo Real-ESRGAN Anime 6B.
Real-ESRGAN migliora la nitidezza, ma non modifica il movimento generato.

Quattordici ore e sette decimi non sono la durata del progetto

I registri permettono di distinguere il tempo di calcolo riuscito dal tempo trascorso sul calendario. La generazione delle 36 tavole FLUX ha richiesto circa 22 minuti. Le 36 clip guida LTX circa 71 minuti. Per 246 segmenti continui sono disponibili metriche che sommano circa 11,3 ore di LTX; stimando con lo stesso passo i sei segmenti senza metrica, il totale della fase cresce ancora. Real-ESRGAN aggiunge circa 1,55 ore.

Mettendo insieme le fasi produttive riuscite si arriva a circa 14,7 ore di calcolo. Non significa che abbia acceso il computer la mattina e trovato il film pronto prima di cena. I timestamp dei file coprono più di 60 ore di calendario, tra test, controlli, crash, riavvii, tentativi scartati e periodi in cui la macchina non stava generando.

La distinzione conta. Le 14,7 ore descrivono quanto impiegherebbe la pipeline nelle condizioni osservate, se partisse già configurata e completasse i lavori validi. Le oltre 60 ore descrivono una produzione reale mentre il metodo veniva ancora corretto. Non includono tutto lo sviluppo precedente dell'app, i prototipi con altri protagonisti e il tempo umano passato a guardare occhi, mani e giunzioni.

La procedura stabile imponeva una disciplina poco cinematografica:

• un solo modello pesante alla volta;
• coda seriale per i segmenti LTX;
• salvataggio immediato di ogni risultato;
• arresto completo di ComfyUI dopo LTX;
• riavvio pulito prima di Real-ESRGAN;
• controllo della VRAM e della memoria impegnata di Windows;
• pagefile attivo su un disco sufficientemente veloce.

Il pagefile non aggiunge memoria video e non rende più rapido il modello. Offre a Windows una riserva quando il caricamento dei checkpoint e lo scaricamento asincrono dei modelli portano il commit vicino al limite. In alcuni tentativi riavviare ComfyUI non bastava: era necessario riavviare Windows perché driver e memoria virtuale tornassero in uno stato affidabile.

Il master finale conserva anche i compromessi

Il risultato verificato contiene tutte le 36 scene continue e tutti i 252 segmenti migliorati. Non ci sono più tavole statiche usate come fallback. Questo non lo trasforma in un cartone animato da studio.

Il movimento è spesso prudente: respirazione, sguardi, pagine, foglie e piccoli cambi di luce. Limitare l'azione protegge la coerenza del personaggio, ma riduce la recitazione. Le giunzioni possono produrre variazioni di occhi, mani o particelle. Non c'è sincronizzazione labiale.

Il master è inoltre esportato a 30 fps, mentre il materiale continuo nasce a 25. Contiene quindi duplicazioni regolari dei fotogrammi: sarebbe più corretto distribuire una versione a 25 fps oppure applicare una vera interpolazione. Il file pesa 528 MB, dimensione utile come master di lavoro ma eccessiva per il web. La versione pubblicabile deve essere ricodificata e accompagnata da sottotitoli.

Sono difetti importanti perché ricordano che "movimento continuo" non significa automaticamente "animazione migliore". La pipeline ha eliminato il blocco dopo due secondi e il ping-pong, ma non ha sostituito regia, recitazione e montaggio sonoro.

Locale e API comprano cose diverse

La generazione locale non applica una tariffa a ogni clip. Se la workstation esiste già, il costo marginale diretto è soprattutto elettricità, spazio su disco e usura. Il costo dominante è però il tempo dell'operatore: installazione, controlli, rigenerazioni e manutenzione.

Un'API video acquista soprattutto comodità e infrastruttura. Può offrire clip più lunghe, evitare la gestione dei driver e permettere più lavori in parallelo. In cambio fattura i secondi generati, compresi quelli scartati, riceve prompt e immagini e lascia meno controllo sui passaggi interni.

Sui listini ufficiali consultati il 17 luglio 2026, Runway Gen-4 Turbo costa 5 crediti per secondo e ogni credito vale 0,01 dollari: il prezzo nominale è quindi 0,05 dollari al secondo. Applicato ai 458,592 secondi del master conservato, produce un minimo teorico di 22,93 dollari. Google Vertex AI Veo 3 e 3.1, alle risoluzioni 720p e 1080p, costano invece 0,20 dollari al secondo senza audio, pari a 91,72 dollari per la stessa durata. Con l'audio, a 0,40 dollari al secondo, Veo arriverebbe a 183,44 dollari già per una sola candidata completa.

Anche "locale" richiede una precisazione. Tavole e video sono stati generati sul PC, ma la voce predefinita usa Edge TTS e invia il testo al servizio Microsoft. Gli assistenti che hanno aiutato a progettare il software operano nel cloud. Il termine descrive quindi la parte visiva della produzione e la conservazione dei file, non necessariamente ogni passaggio del processo creativo.

Che cosa rifarei nello stesso modo

La lezione non è che ogni video debba essere spezzato in frammenti da 49 frame. Con più VRAM, un modello diverso o un servizio esterno si può scegliere una durata maggiore. La lezione è progettare l'unità di lavoro in modo che sia compatibile con l'hardware, verificabile e sostituibile.

In un nuovo progetto manterrei cinque decisioni:

1. generare la voce prima del video, perché stabilisce la durata reale delle scene;
2. approvare due tavole e un pilot animato prima di avviare il batch;
3. salvare prompt, semi, workflow e metriche accanto a ogni risultato;
4. controllare il movimento prima dell'upscale, perché un'immagine più nitida può contenere lo stesso errore;
5. esportare alla cadenza nativa del materiale, evitando un 30 fps soltanto nominale.

Cambierei invece il sound design, aggiungerei sottotitoli, renderei più attoriali alcune scene chiave e produrrei fin dall'inizio un master web. Valuterei inoltre un flusso ibrido: locale per tavole, scene semplici e controllo; API per pochi passaggi in cui servono movimenti lunghi o complessi.

I 252 segmenti non sono la prova che il locale sia superiore al cloud. Sono la prova che una workstation domestica può completare un lavoro oltre i propri limiti apparenti se la pipeline tratta memoria, errore e ripartenza come parti del progetto. Quando ho iniziato, il problema sembrava generare sette minuti e mezzo di animazione. Alla fine il problema utile era più piccolo: generare 1,96 secondi affidabili, salvarli e riuscire a farlo altre 251 volte.

Nota metodologica: dati tecnici e tempi derivano dal master, dai file intermedi e dai registri conservati nel progetto. Le valutazioni visive non costituiscono un benchmark scientifico. Prezzi API verificati live il 17 luglio 2026 sui listini ufficiali Runway e Google Cloud; per Veo 3/3.1 sono state considerate le tariffe 720p/1080p. I calcoli rappresentano minimi teorici basati sulla durata conservata di 458,592 secondi e non includono arrotondamenti delle clip, scarti, candidate alternative o rigenerazioni.