Video-Rate Streaming Stylization on a Vision-Aware MLLM-Conditioned Edit Diffusion: Asymmetric Batched Inference on a Distilled UNet + MLLM Text Encoder

Sintesi Tecnica: Stilizzazione di Streaming a Velocità Video su un Modello di Diffusione per l'Editing Condizionato da MLLM Vision-Aware

Problematica
La traduzione video in tempo reale tramite modelli di diffusione si è tradizionalmente basata su stack di diffusione d'immagine condizionati dal testo, dove il denoiser U-Net rappresenta il collo di bottiglia computazionale per frame e l'encoder testuale è una rete leggera di classe CLIP (~125M di parametri). Tuttavia, una distillazione aggressiva del denoiser (riducendolo a uno studente a 4 o 1 step) inverte questo collo di bottiglia. Nel regime di "diffusione per l'editing vision-aware", dove il sistema deve elaborare sia un'immagine sorgente che un'istruzione testuale, l'encoder testuale viene sostituito da un modello linguistico multimodale (MLLM) pesante, come Qwen3-VL (2.13B di parametri).

In questo regime "Small-Distilled-Denoiser plus Heavy-MLLM-Encoder" (SDD-MTE), l'encoder testuale MLLM diventa il percorso critico. Le tecniche di streaming standard progettate per pipeline dominate dal denoiser falliscono qui perché:

1. Latenza dell'Encoder: L'encoder MLLM è significativamente più grande del denoiser e contiene punti di sincronizzazione intrinseci CPU-GPU (ad esempio, nelle rotazioni dei posizionamenti rotary), che impediscono una semplice distribuzione a singolo stream.
2. Overhead della Coerenza Temporale: Gli existing temporal adapter come ControlNet-LLLite si affidano a branch Python e controlli di identità di tensori che interrompono la cattura del grafo di torch.compile, causando implementazioni naive che girano circa 3.5× più lentamente rispetto alla U-Net base.
3. Instabilità Numerica: L'ampio intervallo di output MLLM (std=37, max=1160) causa l'overflow dei meccanismi di attenzione FP16, rendendo non disponibili i percorsi TensorRT (su cui si basano sistemi come StreamDiffusion).

Il documento affronta la sfida di raggiungere una velocità di throughput di streaming video su una singola GPU consumer all'interno di questo regime di collo di bottiglia invertito.

Metodologia
Gli autori propongono una pipeline di streaming costruita attorno a tre specifici meccanismi di ingegneria progettati per il regime SDD-MTE, istanziati su un U-Net distillato da 0.39B (DreamLite-mobile) accoppiato con un encoder Qwen3-VL da 2.13B.

1. Pipelining Asimmetrico Side-Stream / Main-Stream:

   • La pipeline si divide in due stream CUDA concorrenti. Il Main Stream gestisce il denoising della U-Net compilata e la decodifica VAE per il batch corrente ($n$).
   • Il Side Stream elabora concorrentemente l'encoding testuale (TE) dell'MLLM e l'encoding VAE per il batch successivo ($n+1$).
   • Questo design nasconde la latenza di sincronizzazione intrinseca dell'encoder MLLM dietro la computazione della U-Net.
   • Ammortizzazione del Batch: Il sistema bufferizza $B$ frame (ad esempio, $B=8$ o $16$) prima di ogni chiamata di pipeline. Poiché l'encoder MLLM scala in modo sub-lineare con la dimensione del batch (sub-linearità $s \approx 0.226$ a $B=8$) mentre la U-Net compilata scala quasi linearmente ($s \approx 0.77$), il batching riduce significativamente il costo per-frame del TE senza aumentare proporzionalmente il costo della U-Net.
   • Caching del Prompt Statico (Opzionale): Per stream con istruzioni fisse, il sistema può codificare un singolo frame rappresentativo e trasmettere i suoi tensori key/value al resto del batch, oppure aggiornare l'encoding solo ogni $N$ batch.

2. Riformulazione di ControlNet-LLLite Compatibile con la Compilazione:

   • Per abilitare l'ottimizzazione torch.compile, gli autori hanno rifattorizzato l'adapter ControlNet-LLLite per rimuovere i branch Python e i cambiamenti di identità dei tensori che precedentemente forzavano la ricompilazione di Dynamo su ogni frame.
   • Le modifiche chiave includono la registrazione degli embedding di condizionamento come buffer a dimensione fissa con aggiornamenti in-place, la rimozione dei percorsi di solo training (dropout, controlli dtype) e l'esposizione di un metodo dedicato forward_inference.
   • Ciò consente di ripiegare l'intero stack U-Net + adapter in un singolo grafo fuso, ottenendo un aumento di velocità di 4.75× rispetto all'implementazione di riferimento eager.

3. Aggiornamento Periodico del Condizionamento e Hook Subset:

   • Programma di Aggiornamento: Invece di ricalcolare l'embedding di condizionamento LLLite (derivato dal frame precedente deformato/warped) per ogni batch, il sistema ricostruisce l'embedding ogni $N$ batch (ad esempio, $N=8$). Questo ammortizza il costo della CNN di condizionamento, che domina il tempo di esecuzione del percorso LLLite.
   • Hook Subset: Il set completo di 108 hook viene ridotto a un sottoinsieme di 38 hook situati solo nei down_blocks. Ciò riduce il carico di lavoro dell'encoder di condizionamento di circa il 65% pur recuperando la nitidezza spaziale persa quando si utilizzano tutti i 108 hook (che tendono a produrre un artefatto "viola liscio").
   • Flusso Async: Il calcolo del flusso ottico Farneback è threadato e avviato in modo asincrono durante il prefetch per sovrapporsi allo slot del side-stream successivo.

Contributi Chiave

• Architettura di Sistema: Una nuova strategia di pipelining asimmetrica che tratta l'encoder MLLM come un carico di lavoro separato e concorrente per superare il collo di bottiglia invertito nei regimi SDD-MTE.
• Ottimizzazione del Compilatore: Un'implementazione di ControlNet-LLLite rifattorizzata compatibile con torch.compile, che consente l'esecuzione di grafi fusi per gli adapter temporali.
• Meccanismi di Efficienza: Una combinazione di ammortizzazione del TE tramite batch, aggiornamento periodico del condizionamento e selezione del subset di hook che riducono collettivamente la latenza per frame senza una significativa degradazione della qualità.
• Validazione Empirica: Valutazione completa su hardware consumer (RTX 3090 Ti, 4090, 5090) che dimostra throughput sostenuto e coerenza temporale in scenari in-domain e cross-dataset.

Risultati
Valutato su una singola RTX 3090 Ti a risoluzione 512×512 con dimensione del batch $B=8$ e inferenza a 1 step ($K=1$):

• Throughput: La pipeline sostiene 27.4 FPS (latenza p50 ~0.5s) e 29.6 FPS a $B=16$ (latenza p50 ~1.0s) su una corsa di 480 frame.
• Scalabilità Hardware: Le prestazioni scalano a 54.9 FPS su RTX 4090 e 74.1 FPS su RTX 5090.
• Qualità: La configurazione "champion" (down_blocks hook subset + periodic refresh) raggiunge un errore di warping ($\epsilon_w$) di 18.34, una riduzione del 20% del flickering rispetto alla baseline senza LLLite (22.97), mantenendo al contempo il dettaglio spaziale (score Sobel 4.74 vs. 5.10 della baseline).
• Generalizzazione: L'adapter temporale rilasciato si generalizza bene a 19 sequenze DAVIS-2017 non utilizzate e 15 clip da 7 fonti non-DAVIS, con metriche di performance entro il rumore in-clip del champion in-domain.
• Generalizzazione del Prompt: Il modello gestisce bene prompt di stile non visti (ad esempio, Van Gogh), sebbene le prestazioni degradino per stili con texture ad alta frequenza al di fuori del manifold di addestramento (ad esempio, halftone di fumetti).

Significato e Rivendicazioni
Il paper si posiziona come uno studio sui sistemi piuttosto che una rivendicazione di superiorità di benchmark. Afferma esplicitamente di non rivendicare la superiorità rispetto ai sistemi di classe StreamDiffusion (che usano encoder CLIP), ma colloca i propri numeri rispetto a una ri-esecuzione dello stesso stack di StreamDiffusion per fornire contesto.

La portata principale risiede nel dimostrare che lo streaming a velocità video è raggiungibile su una singola GPU consumer anche quando l'encoder testuale è un MLLM pesante, a condizione che il sistema sia riprogettato per accomodare il collo di bottiglia invertito. Gli autori sottolineano che le tecniche standard di accelerazione del denoiser sono insufficienti per questo regime e che i meccanismi proposti (pipelining asimmetrico, adapter compatibili con la compilazione e condizionamento ammortizzato) sono necessari per sbloccare le prestazioni in tempo reale.

Il paper funge anche da guida per i professionisti documentando i risultati negativi (ad esempio, mixing di latenti ingenuo, fallimenti FP16 di TensorRT con output MLLM e gli errori comuni nell'usare solo l'errore di warping come metrica per gli artefatti di smoothing) per evitare comuni vicoli ciechi ingegneristici in questo specifico dominio.