Vidu S1: il video generato in diretta che risponde alla voce

Al cinema il film è già finito prima che si spengano le luci. Si può ridere, piangere, gridare al protagonista di non aprire quella porta: la porta si aprirà comunque, perché la pellicola è stata girata mesi prima. Al teatro dei burattini è diverso. Quando i bambini gridano «dietro di te!», il burattinaio sente, e Pulcinella si gira. Lo spettacolo si scrive mentre lo si guarda, e chi guarda ci mette le mani.

I generatori video degli ultimi due anni (Sora, Veo, Wan, Seedance) sono cinema: si scrive un prompt, si aspettano minuti, si riceve una clip finita. Vidu S1: A Real-Time Interactive Video Generation Model, depositato su arXiv il 3 luglio 2026 (2607.03118, seconda versione il 21 luglio), prova a fare il burattinaio. Lo firmano ventisette autori della Tsinghua University e di Shengshu Technology, l’azienda che commercializza i modelli Vidu, con Jintao Zhang come responsabile del progetto e Jun Zhu, Jianfei Chen, Fan Bao e Zhijie Deng come supervisori. In questi giorni è fra i paper in tendenza su Papers with Code.

Che cosa fa, esattamente

Vidu S1 non è un generatore video generico. È un modello per personaggi digitali: si carica un’immagine di partenza (una persona reale, un personaggio anime, un animale domestico), si sceglie un timbro di voce, e il modello produce un flusso continuo in cui quel personaggio parla, con labbra sincronizzate all’audio, e si muove. La novità dichiarata è che il flusso si può dirigere mentre scorre: si dice «saluta con la mano», «fai un cuore con le mani», «siediti», e il gesto compare nei fotogrammi successivi.

Gli autori individuano quattro difetti nei modelli precedenti: molti sono passati alla generazione autoregressiva senza però permettere di intervenire mentre genera; la maggior parte non usa la voce come comando esplicito; molti degradano su orizzonti lunghi, perché i piccoli errori si accumulano fino al collasso visivo; e il tempo reale, osservano, non è solo un problema di modello ma di kernel, serving e infrastruttura.

C’è anche un argomento di mercato, tutto costruito su ipotesi. Se ogni utente ha una domanda $\alpha$ di contenuti interattivi e una domanda $\beta$ di video preconfezionati, la prima cresce come $\alpha N$ con il numero di utenti, la seconda come $\beta N/m$, perché un video generato si guarda in media $m$ volte. Con $\alpha \approx \beta$ e $m > 100$, concludono, la domanda di video in tempo reale è «molto maggiore»: nel loro conto, oltre cento volte. Il conto regge solo se si accetta che le due domande siano uguali, e il paper non porta dati per sostenerlo.

Da bidirezionale a causale, in tre tappe

Il modello genera insieme video e audio: a ogni fotogramma $i$ associa uno stato congiunto $x^i_0 = [v^i_0; a^i_0]$, concatenazione delle rappresentazioni latenti di immagine e suono. Le condizioni (voce, testo, immagine di riferimento) arrivano come una sequenza $c^{1:\infty}$ che non ha una fine prefissata.

L’addestramento procede in tre tappe. Prima si allena un modello bidirezionale, che vede l’intera sequenza e impara a ripulirla dal rumore: è il maestro che dà la qualità. Poi lo si converte in un modello causale, con una maschera di attenzione che gli impedisce di guardare il futuro. Ogni nuovo fotogramma viene ripulito guardando solo le condizioni arrivate fin lì e la storia già generata:

$$\hat{x}^i_0 = f_\theta\big(x^i_{t_j},\, t_j,\, c^{\le i},\, x^{<i}_{\tau_j},\, \tau_j\big)$$

dove $x^i_{t_j}$ è il fotogramma corrente ancora rumoroso e $x^{<i}_{\tau_j}$ è la storia, rappresentata a un livello di rumore $\tau_j$. Il dettaglio che conta è proprio quel $\tau_j$. Per ogni esempio di addestramento si tira una moneta, una Bernoulli di parametro $p$: con un esito la storia è pulita, presa dai dati veri ($\tau_j = 0$, teacher forcing); con l’altro è volutamente sporca ($\tau_j > 0$, diffusion forcing). Così impara a proseguire anche da un passato imperfetto, che in diretta è quello che il modello stesso ha appena prodotto.

La terza tappa è la velocità. Un modello di diffusione che per ogni fotogramma fa molti passi non regge i trenta fotogrammi al secondo. Gli autori usano la Distribution Matching Distillation (DMD) per comprimere la generazione in pochi passi (tre, nella configurazione valutata) e segnalano un problema: da sola la DMD va spesso incontro al collasso di modo, con la telecamera che deriva, il contenuto che degenera e fotogrammi incoerenti fra loro. Per tenerla ferma aggiungono come regolarizzazione l’obiettivo di coerenza dei Phased Consistency Models, misurato con una distanza percettiva.

Come si genera un video che non finisce

Un flusso infinito non può ricordare tutto. In inferenza l’attenzione è limitata a una finestra scorrevole di lunghezza fissa, fatta di tre pezzi: un contesto di riferimento permanente (i latenti dell’immagine caricata più il primo stato generato), la storia recente in memoria, e il fotogramma che si sta ripulendo. Il contesto permanente fa la parte che negli LLM in streaming fanno i sink token: un’àncora che tiene ferma l’identità del personaggio anche quando i primi fotogrammi sono usciti dalla finestra.

Due accorgimenti rendono la finestra efficiente e stabile. Il primo, il riposizionamento RoPE, salva in memoria chiavi e valori prima di applicare la codifica di posizione, e la riapplica a ogni scorrimento secondo le nuove posizioni relative: niente ricalcolo della storia, e nessuna posizione esce dall’intervallo visto in addestramento. Il secondo, TwinCache, è il pezzo che il paper rivendica come nuovo. Di ogni fotogramma passato si conservano due copie: una presa a un passo intermedio prestabilito della pulizia, ancora rumorosa, e una pulita. Nei passi intermedi il modello guarda la copia rumorosa, il cui rumore residuo secondo gli autori trasmette l’andamento del movimento e frena l’accumulo degli artefatti ad alta frequenza: una specie di filtro passa-basso sulla memoria. Solo nell’ultimo passo guarda la copia pulita, per recuperare i dettagli e l’identità.

Lo stack che porta a 42 fotogrammi al secondo

Il resto è ingegneria, ed è la parte in cui il gruppo gioca in casa: TurboDiffusion, SageAttention, SpargeAttention e l’attenzione Sparse-Linear, che Vidu S1 adotta, sono lavori precedenti firmati in buona parte dagli stessi autori. A questi si aggiungono una quantizzazione W8A8 dei livelli lineari a blocchi (per tensore o per canale, osservano, pochi valori estremi dilatano l’intervallo e rovinano la precisione di tutti gli altri), la fusione di operatori in kernel Triton e CUDA, i CUDA Graph per ammortizzare il costo di lancio di tanti operatori brevi e ripetitivi, e il parallelismo di contesto in stile Ulysses per dividere il lavoro fra più GPU.

I numeri

Sul benchmark pubblico HDTF, video di volti che parlano, Vidu S1 è primo sulle tre metriche riportate: somiglianza dell’identità (CSIM), sincronizzazione labiale (Sync-D) e qualità percepita (DOVER). Il confronto include cinque modelli aperti (OmniAvatar, StableAvatar, Hallo3, Wan2.2-S2V-14B, LiveAvatar) e tre commerciali (LemonSlice, HeyGen, Kling Avatar 2.0). A 540p, con tre passi di pulizia, la produzione media è di 42 fotogrammi al secondo su GPU RTX 5090, sopra la soglia dei 30 che gli autori prendono come tempo reale.

Per la parte interattiva, che HDTF non misura, il gruppo ha costruito Vidu-StreamBench: 500 esempi, ognuno con un comando d’azione, un’immagine di partenza e una clip audio. Lì il confronto è un test di preferenza a coppie contro i tre sistemi commerciali. Nel giudizio complessivo Vidu S1 è preferito contro tutti e tre (46-56 per cento delle preferenze, contro il 28-30 dell’avversario), e sulla voce che misura il rispetto dei comandi raggiunge il 100% delle preferenze contro HeyGen e LemonSlice. Poco sorprendente: nella tabella degli autori solo Vidu S1 e Kling Avatar 2.0 seguono istruzioni d’azione.

Che cosa resta da verificare

I margini su HDTF sono sottili. Sulla somiglianza d’identità la differenza fra Vidu S1 e HeyGen è alla quarta cifra decimale, e anche LiveAvatar su DOVER e LemonSlice sulla sincronizzazione restano a ridosso. «Il migliore su tutte le metriche» è vero, ma dice poco più di «alla pari con i migliori». E la colonna della velocità è quasi vuota per i concorrenti: solo HeyGen ha un valore, 25 FPS.

«GPU consumer» va letto con attenzione. La RTX 5090 è una scheda da gaming, ma il paper parla di GPU al plurale e usa il parallelismo di contesto per distribuire un flusso su più schede, senza dire quante; e se l’abstract dice «fino a» 42 fotogrammi, il testo dice «in media». Non riporta nemmeno il dato che conta di più per un’interazione, cioè quanto passa fra la fine del comando vocale e il gesto sullo schermo: la produzione di fotogrammi al secondo non è la latenza.

L’«infinito» è mostrato, non misurato. La figura di apertura mostra un personaggio lungo una linea del tempo che arriva a 90:00, ma non c’è una metrica di deriva nel tempo, né un confronto a durate crescenti. E non ci sono ablazioni: quanto contribuiscano TwinCache, la regolarizzazione PCM o l’addestramento misto non si sa, così come mancano il valore di $p$ e la lunghezza della finestra.

La valutazione interattiva è in casa. Vidu-StreamBench è costruito dagli autori, e il paper non dice quanti valutatori abbiano espresso le preferenze né se il benchmark sarà pubblicato. Non annuncia pesi né codice (il repository ufficiale contiene un README e delle figure), e da settembre la demo sul sito commerciale di Vidu presenta il successore, Vidu S2 (arXiv 2609.11638): quello che si prova oggi non è necessariamente il modello descritto qui.

Due silenzi. I dati vengono da dirette, video di volti parlanti, film e serie televisive, senza una parola su licenze e provenienza. E un sistema che anima in tempo reale la foto di una persona vera, con una voce a scelta, si presta per costruzione al deepfake in diretta; il paper filtra i contenuti inappropriati dai dati di addestramento, ma non discute consenso, marcature o limiti d’uso.

Perché conta adesso

La corsa sui modelli video si è misurata finora sulla qualità di clip di pochi secondi. Vidu S1 sposta la domanda: non quanto è bello il video, ma quanto è vivo, cioè se risponde, per quanto regge e quanto costa tenerlo acceso. Le risposte del paper sono in larga parte ingegneria, e mostrano soprattutto che un gruppo con uno stack di accelerazione proprio può portare un generatore di diffusione ai ritmi del tempo reale. Quelle che mancano (latenza del comando, deriva misurata, costo per utente) decideranno se il burattinaio diventa un prodotto o resta una demo.