The Pulse

Characters funziona in tempo reale su quattro H100, afferma Runway

Il modello video Characters di Runway è ora in grado di generare video in tempo reale su quattro GPU H100 per sessione, secondo l’azienda. La sua ricerca descrive modifiche alla gestione della cache e alla comunicazione tra GPU durante l’er

AI.info Team · Scritto con l’IA · verificato · 2026-11-06

Characters funziona in tempo reale su quattro H100 a 159,3 ms per passo

Runway Research ha pubblicato una ricerca sull’erogazione in tempo reale di Characters il 5 novembre 2026. Characters si basa su un transformer di diffusione video autoregressivo da circa 57 miliardi di parametri. A 24 fotogrammi al secondo, il modello deve generare per ogni sessione un nuovo blocco di quattro fotogrammi video a 704x1088 ogni 166,7 ms.

Characters è stato lanciato su otto H100 per sessione. Su quattro H100, il software della versione di lancio impiegava 240,9 ms per passo di diffusione, ben oltre i 166,7 ms richiesti da Runway. Le ottimizzazioni hanno portato il passo a 159,3 ms: secondo Runway, il processo è così 1,51 volte più veloce e sostiene 24,5 fps; un kernel di comunicazione che combina più operazioni lo ha portato a 147,4 ms, rendendolo 1,63 volte più veloce.

La gestione della cache spostata al momento della scrittura

Ogni passo di diffusione rimuove il rumore da un fotogramma latente attraverso quattro passaggi in un transformer a 60 blocchi, producendo 240 chiamate di attenzione. Ogni chiamata legge una cache di 5.788 posizioni, di cui 757 nuove. Nell’implementazione originale, la gestione della cache richiedeva 69,7 ms su un passo di 239,2 ms.

Runway ha spostato gli embedding di posizione rotativi e la quantizzazione FP8 al momento in cui ogni nuovo fotogramma entra nella cache e organizza la cache come un buffer circolare per evitare copie mentre la finestra avanza. Il tempo dedicato alla gestione della cache è così sceso a 6,2 ms per passo. Poiché le posizioni vengono reimpostate ogni 42 passi, il sistema applica a ogni reimpostazione un’unica rotazione delta alla finestra memorizzata nella cache; quel passo richiede 263 ms, che secondo Runway vengono assorbiti dal buffer di riproduzione.

Comunicazione tra GPU e decodifica

Un’operazione all-reduce in parallelismo tensoriale segue ogni blocco del transformer, 240 volte per passo. Un’operazione collettiva più veloce, da sola, ha fatto risparmiare 0,4 ms, quindi Runway ha combinato la riduzione con la moltiplicazione di matrici FP8. Con la forma dei dati usata in produzione, la chiamata combinata richiede 153,8 µs contro 208,2 µs, nascondendo il 54-68% del tempo dell’all-reduce.

Il decoder impiega 114 ms per passo a trasformare le rappresentazioni latenti in fotogrammi video. Runway gli assegna una GPU dedicata, così che possa decodificare il blocco precedente mentre viene rimosso il rumore da quello successivo; la durata del passo supera così il tempo di diffusione di 1,6 ms. Nei test sulle B200, la condivisione di una GPU tra decodifica e diffusione ha raggiunto il limite di potenza di 1.000 W e rallentato i kernel di diffusione del 18-26%.

Controlli di qualità e rollback in produzione

Runway ha valutato le modifiche che influiscono sui risultati numerici del modello confrontandole con la variazione tra esecuzioni ripetute, poiché in un modello autoregressivo i confronti tra pixel perdono significato dopo circa 10 secondi, quando le esecuzioni divergono. Nelle 51 clip valutate, le differenze medie nella sincronizzazione labiale sono state al massimo di 0,03 e ogni intervallo al 95% è rientrato entro ±0,08. In quattro sessioni di 10 minuti non si è osservata, nel corso della sessione, alcuna crescita delle differenze superiore a quella prodotta da una nuova esecuzione.

Runway avverte che i risultati delimitano l’entità delle differenze, anziché dimostrare l’equivalenza. SyncNet è meno efficace sui personaggi stilizzati, per i quali gli intervalli erano da due a cinque volte più ampi, e quattro sessioni lunghe non possono escludere una tendenza lenta.

Il kernel combinato è entrato in produzione nell’agosto 2026, poi i worker hanno iniziato a esaurire la memoria dopo un aggiornamento di PyTorch e NCCL. Runway ha limitato la combinazione delle operazioni alla forma dei dati a regime e ha lasciato che i primi passaggi forward usassero NCCL, per poi riattivare il kernel l’8 ottobre 2026. Nei 15 giorni successivi, lo 0,7% delle sessioni durate almeno un secondo ha registrato una media di 24 fps o meno, rispetto al 7-23% in ciascuna delle cinque settimane precedenti.

Latenza dei turni e altre configurazioni GPU

Nei 51 turni tracciati in 12 sessioni dal vivo, il tempo mediano tra la fine dell’intervento vocale di un utente e l’arrivo della voce del personaggio al client è stato di 2,13 secondi. L’agente vocale ha inciso per 1,42 secondi, mentre la pipeline di Runway, dal primo audio dell’agente al primo fotogramma in cui il personaggio parla, ha impiegato 0,49 secondi. La consegna al browser ha aggiunto circa 190 ms.

Runway riferisce anche che la produzione in tempo reale su tre B200 procede a 154,3 ms per passo. La sua ottimizzazione della cache FP8 fa risparmiare 17,0 ms sulle H100, ma costa da 2,4 a 6,7 ms sulle B200, dove la build di Runway non dispone di un kernel di attenzione FP8 che accetti scale per singola testa di attenzione. Su otto H100, afferma Runway, la diffusione richiede 118,2 ms per passo, mentre ogni passo richiede 128,7 ms perché l’unica GPU che trasforma i risultati in fotogrammi video non riesce a tenere il passo.