TurboServe, il video generato in diretta come servizio: sessioni che traslocano e GPU che si accendono

In un ristorante con i tavoli assegnati una volta per tutte all’ingresso, a metà serata succede sempre la stessa cosa: un cameriere ha quattro tavolate che ordinano il secondo nello stesso momento, un altro guarda la sala con le mani in tasca. Nessuno ha sbagliato all’ingresso: è che i clienti non mangiano tutti allo stesso ritmo, e alcuni restano tre ore. Il servizio lo decide il cameriere più carico, e il titolare, per non far aspettare nessuno nell’ora di punta, paga lo stesso numero di camerieri anche alle tre del pomeriggio.

È il problema che affronta TurboServe: Serving Streaming Video Generation Efficiently and Economically, uscito su arXiv il 17 giugno 2026 (2606.19271, categoria sistemi distribuiti). Lo firmano otto autori di Shanghai Jiao Tong University, Tsinghua University e Shengshu Technology, l’azienda che commercializza i modelli Vidu: Youhe Jiang, Haoxu Wang e Haotong Bao a pari merito, Jintao Zhang come autore di riferimento. Il codice, dichiarano, è pubblico. Non è un nuovo modello: è il pezzo di infrastruttura che sta dietro, quello che decide su quale GPU gira ciascun utente e quante GPU tenere accese.

Un carico di lavoro che prima non c’era

La generazione video classica funziona come una stampante: si manda un prompt, si aspetta da qualche secondo a qualche minuto, arriva il filmato intero. Una nuova famiglia di modelli, fra cui Self-Forcing, LongLive e StreamDiffusionV2, lavora invece a pezzi: produce il video un segmento alla volta, ogni segmento condizionato sui precedenti, e accetta nuovi comandi mentre genera. L’utente guarda il video formarsi e lo corregge in corsa. Perché l’esperienza regga, ogni segmento deve arrivare entro una scadenza stretta.

Per chi gestisce il servizio questo cambia la natura del lavoro. Una richiesta classica nasce, occupa una GPU, finisce e libera tutto. Una sessione in streaming invece vive a lungo e porta con sé uno stato, la cache dei segmenti già generati e i prompt, che va conservato anche quando l’utente si ferma a pensare. Il paper mostra, sulle tracce di produzione di Shengshu, sessioni che durano da meno di cinque secondi a oltre due minuti, e un numero di sessioni attive che in mezz’ora oscilla fra una dozzina e oltre cento. I sistemi esistenti per il video (FastVideo, xDiT, vLLM-Omni, TridentServe) sono pensati per richieste isolate; quelli per i modelli linguistici, come vLLM, tengono lo stato solo finché la risposta non è completa e ottimizzano il tempo di risposta o la latenza per token, non una scadenza fissa per segmento.

Gli autori riducono le difficoltà a due. La prima è l’eterogeneità delle durate: una sistemazione delle sessioni che all’inizio era equilibrata smette di esserlo man mano che le sessioni lunghe si accumulano e gli utenti passano da attivi a inattivi. La seconda è la domanda che va a raffiche: dimensionare il parco di GPU sul picco spreca soldi nelle ore morte, dimensionarlo sulla media fa saltare le scadenze nelle ore di punta.

Tre esperimenti prima del sistema

Il paper parte da uno studio su 8 GPU H100 che spiega l’architettura meglio di qualsiasi schema. Il punto di partenza è il runtime che Shengshu usa già in produzione, chiamato qui TurboServe_base: raggruppa in un unico passaggio del modello i segmenti delle sessioni attive sulla stessa GPU, parcheggia in memoria di sistema lo stato delle sessioni inattive, e assegna ogni nuova sessione alla GPU meno carica, dove resta. Su una traccia reale gli autori provano due leve, prima una alla volta e poi insieme: spostare periodicamente le sessioni fra le GPU, a parità di GPU, e accendere e spegnere GPU secondo la domanda, senza spostare nessuno.

La lezione che gli autori ne traggono è che le due leve vanno coordinate: quando si aggiunge una GPU conviene subito spostarci sopra delle sessioni, altrimenti resta vuota; prima di spegnerne una bisogna svuotarla.

Il sistema: due controllori che si parlano

TurboServe formalizza il problema come una decisione presa a ogni evento, cioè ogni volta che una sessione arriva, finisce, si attiva o si mette in pausa. A quel punto lo scheduler sceglie quante GPU tenere accese, $M(t)$, e dove mettere ogni sessione, $\phi(t)$, minimizzando una somma pesata di costo e latenza peggiore:

$$\min_{M(t),\,\phi(t)} \; c_{\text{gpu}}\,M(t) + \lambda(t)\,L(t),$$

con due vincoli: nessuna GPU ospita più di $K$ sessioni, e ogni sessione il cui utente sta interagendo deve stare su una GPU. Nel costo entrano anche le GPU che si stanno ancora avviando e non servono nessuno.

Il problema non viene risolto in modo esatto. Lo spezzano due controllori. Il primo, quello di piazzamento, parte dalla sistemazione precedente (per non spostare nulla senza motivo), assegna le sessioni nuove o appena riattivate alla GPU che peggiora meno la latenza peggiore, poi prova a togliere sessioni dalla GPU più carica. Una mossa si fa solo se conviene:

$$\Gamma = L – L’ – \eta\,\kappa_i,$$

dove $L – L’$ è quanto scende la latenza peggiore e $\kappa_i$ è il costo stimato del trasloco, pesato da un $\eta$ che gli autori tengono piccolo. Il controllore sceglie la mossa col guadagno più alto e ripete finché nessuna mossa rende. Il trasloco avviene solo fra un segmento e l’altro: la GPU di partenza congela lo stato, quella d’arrivo lo legge direttamente dalla memoria dell’altra, e la sessione cambia proprietario solo a copia finita. Il modello non si muove, ce n’è una copia per GPU; viaggia solo lo stato della sessione.

Il secondo controllore regola il numero di GPU. Guarda il carico della GPU più piena dopo il piazzamento, $\rho_{\max}$, e lo confronta con un’occupazione obiettivo $\hat\rho$ (ad esempio il 70% della capienza). Per evitare di accendere e spegnere a ogni oscillazione c’è una fascia di tolleranza $\delta$, ad esempio 0,1: si scala in su solo sopra $\hat\rho + \delta$, in giù solo sotto $\hat\rho – \delta$. Quando scatta, il numero di GPU diventa $\lceil N_{\text{req}} / (K\hat\rho) \rceil$, dove $N_{\text{req}}$ sono le sessioni da eseguire. Le GPU non vengono create dal nulla: il sistema le chiede al gestore del cluster di Shengshu, dove immagini e pesi del modello sono già copiati sui dischi locali.

Resta da scegliere $\hat\rho$. In un’appendice gli autori descrivono una tabella costruita offline: misurano quanto è irregolare il flusso di attivazioni in una finestra recente, dividono l’irregolarità in dieci livelli e per ciascuno cercano a griglia i parametri che costano meno rispettando la scadenza. Con traffico calmo l’occupazione obiettivo arriva a 0,80, con traffico a raffiche scende a 0,25.

I numeri

La valutazione gira su due cluster interni di Shengshu, 16 GPU H20 e 64 GPU B300, con modelli di tipo LongLive da 1,3 e 7 miliardi di parametri e sei tracce di produzione. I termini di paragone sono tre varianti del runtime di base: assegnazione a turno, alla GPU meno carica, alla GPU con meno memoria occupata. A parità di costo, TurboServe riduce la latenza peggiore per segmento del 37,5% in media, fino al 51,6%. A parità di latenza, riduce il costo delle GPU del 37,2% in media, fino al 49,0%.

Le ablazioni dicono quale leva pesa di più. Senza migrazione il costo sale del 15,0% in media; senza autoscaling del 42,9%, con punte dell’80,4%. Il trasloco di una sessione costa fra 23 e 30 millisecondi, il 2-3% del tempo di generazione di un segmento, che in queste prove sta fra 917 e 1201 millisecondi. Lo scheduler decide in meno di 15 millisecondi fino a 64 GPU e in meno di un decimo di secondo a 256, restando in media entro il 3,6% dalla sistemazione ottima trovata per ricerca esaustiva. Quanto all’autoscaling, su tre tracce costa, secondo gli autori, in media il 6,1% in più di un oracolo che conosce in anticipo tutto il traffico futuro.

Che cosa il paper non dice

I rivali sono fatti in casa. Non esistendo sistemi dedicati allo streaming video, i tre termini di paragone sono varianti semplici del runtime di Shengshu, senza migrazione né autoscaling. Il 37% di risparmio sul costo è quindi, in buona parte, il valore di avere una scalatura elastica rispetto a non averla: un risultato utile, ma meno sorprendente di quanto la cifra lasci intendere, come conferma il fatto che togliere l’autoscaling costa quasi tre volte più che togliere la migrazione.

Un solo fornitore di traffico. Tutte le tracce vengono da Shengshu, i costi sono in dollari equivalenti al cloud calcolati su un cluster interno, e l’avvio rapido delle GPU presuppone immagini e pesi già copiati sui dischi. E quanto tempo passi fra la richiesta di una GPU e il momento in cui è pronta, il paper non lo dice.

Il modello di carico è semplice. La latenza di una GPU viene stimata dal numero di sessioni che ospita, con una capienza fissa $K$. Il peso $\lambda$ della funzione obiettivo, presentato come uno dei due parametri di controllo, nella tabella dell’appendice vale 0,2 a tutti e dieci i livelli, e gli autori ammettono che il compromesso lo regola soprattutto l’occupazione obiettivo. Il confronto con l’oracolo in appendice, entro lo 0,73%, usa una traccia di cinque minuti costruita dagli autori; su due tracce reali il divario sale al 2,25% e al 3,99%.

Qualche dettaglio non torna. Nella tabella sull’autoscaling, sulla terza traccia TurboServe costa 152,36 dollari contro i 160,74 dell’oracolo, cioè meno di quello che viene presentato come limite inferiore, eppure la cella riporta un aumento del 5,5%. E il runtime di base cambia regola da una sezione all’altra: nello studio iniziale manda ogni sessione alla GPU meno carica, nella valutazione le assegna a turno, e la GPU meno carica diventa una delle varianti. Saranno sviste, ma in un paper di sistemi numeri e termini di paragone sono la sostanza.

Perché conta adesso

I modelli che generano video in diretta, comandati mentre girano, stanno uscendo dai laboratori, e con loro arriva una domanda che finora nessuno aveva dovuto porsi: quanto costa tenere aperte migliaia di sessioni lunghe, ciascuna con la sua memoria, ciascuna con una scadenza a ogni segmento. TurboServe non inventa tecniche nuove: migrazione, isteresi e scalatura proporzionale vengono dal calcolo distribuito classico. Il contributo è averle cucite su un carico di lavoro che ha la persistenza di un videogioco e i costi di un modello generativo, e averle misurate su traffico vero. Come per il cameriere e il titolare del ristorante, la differenza fra un servizio sostenibile e uno che non lo è si gioca meno nel piatto che nell’organizzazione della sala.