💻 computer science

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

Este artigo apresenta um pipeline de estilização de streaming em taxa de vídeo que supera o gargalo do codificador de texto em difusão de edição condicionada por MLLM ao combinar um U-Net destilado de 0,39B com um codificador Qwen3-VL de 2,13B, utilizando inferência em lote assimétrica e otimizações de grafo fundidas para alcançar até 74,1 fps em GPUs de consumo.

Autores originais: Yoshiyuki Ootani

Publicado 2026-06-05

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Yoshiyuki Ootani

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você tem um estúdio de arte mágico onde um robô pintor consegue transformar instantaneamente qualquer vídeo em uma pintura a óleo. Normalmente, a parte mais lenta desse processo é o próprio pintor (o "U-Net"), que leva tempo para misturar cores e aplicar pinceladas.

No entanto, este artigo descreve uma nova configuração onde o pintor foi supertreinado para trabalhar incrivelmente rápido — tão rápido que ele não é mais o gargalo. Em vez disso, o novo "lento" é o Diretor de Arte (um MLLM massivo). Antes que o pintor possa começar, o Diretor de Arte precisa olhar para o quadro do vídeo e para as instruções do usuário (ex: "faça parecer um Van Gogh") e escrever um briefing detalhado. Como o Diretor de Arte é pesado e complexo, ele retém toda a linha, mesmo que o pintor esteja pronto.

Os autores construíram um sistema para resolver este problema específico: Como manter o vídeo fluindo suavemente quando o Diretor de Arte é lento, mas o Pintor é rápido?

Eles fizeram isso usando três truques principais:

1. A Linha de Montagem de "Duas Faixas" (Pipelining Assimétrico)

Imagine uma fábrica com duas esteiras rolantes correndo lado a lado.

A Esteira Principal: O Pintor rápido trabalha no quadro atual.
A Esteira Lateral: O Diretor de Arte lento trabalha nas instruções do próximo quadro enquanto o Pintor está ocupado.

Ao executar essas duas tarefas ao mesmo tempo em "faixas" diferentes (streams CUDA), o sistema esconde a lentidão do Diretor de Arte. Enquanto o Pintor está ocupado pintando o Quadro 1, o Diretor de Arte já está lendo as instruções para o Quadro 2. Quando o Pintor termina, as instruções para o próximo quadro já estão prontas. Isso mantém a linha em movimento sem parar.

2. A Estratégia do "Briefing em Grupo" (Inferência em Lote/Batched Inference)

O Diretor de Arte é lento, mas ele fica mais rápido se processar um grupo de pessoas de uma vez, em vez de uma por uma.

Em vez de pedir ao Diretor de Arte para escrever um briefing para apenas um quadro, o sistema reúne um lote de 8 ou 16 quadros.
O Diretor de Arte escreve um briefing único e eficiente que cobre todos eles.
Esse "desconto de atacado" no tempo significa que o Diretor de Arte gasta menos tempo por quadro, mesmo processando mais dados de uma só vez.

3. O Cronograma de "Atualização Inteligente" (Condicionamento Periódico)

Às vezes, as instruções não precisam ser reescritas para cada quadro. Se o vídeo é apenas uma pessoa caminhando, o "estilo de pintura a óleo" não precisa ser recalculado a cada milissegundo.

O sistema utiliza um "cronograma de atualização". Ele calcula as instruções de estilo detalhadas uma vez e depois reutiliza essa mesma instrução para vários quadros seguidos.
Ele só para para recalcular as instruções quando a cena muda significamente ou após um determinado número de quadros.
Isso economiza uma enorme quantidade de tempo porque o sistema não desperdiça energia perguntando a mesma coisa ao Diretor de Arte repetidamente.

Os Resultados: Um Fluxo Rápido e Suave

Os autores testaram isso em uma única placa de vídeo de consumo (uma RTX 3090 Ti).

Velocidade: Eles alcançaram uma taxa constante de 27 a 30 quadros por segundo (FPS). Isso é rápido o suficiente para assistir a um vídeo em tempo real sem travamentos.
Latência: Há um pequeno atraso (cerca de 0,5 a 1 segundo) porque o sistema precisa de um buffer de alguns quadros para fazer o sistema de "Duas Faixas" funcionar, mas o vídeo roda suavemente assim que começa.
Qualidade: O sistema funciona bem em vídeos que não viu antes (como diferentes tipos de dança ou parkour) e pode lidar com diferentes estilos de arte, embora tenha dificuldade com padrões muito complexos e de alto contraste, como pontos de histórias em quadrinhos.

O Que Eles Tentaram (e Falharam)

O artigo também lista algumas ideias que não funcionaram, servindo como "lições de cautela" para outros:

Misturando tinta velha: Tentar misturar a tinta do quadro anterior diretamente no novo fez com que o vídeo se tornasse um borrão de cor única e sem definição.
Pulando o pintor: Tentar adivinhar o próximo quadro apenas deformando o anterior (pulando o pintor inteiramente) resultou em um vídeo trêmulo e de baixa qualidade.
Cortando caminhos: Remover partes das instruções do Diretor de Arte para economizar tempo na verdade piorou o vídeo, provando que aquelas instruções eram necessárias.

A Conclusão

Este artigo não é sobre tornar o robô pintor mais rápido; é sobre reorganizar a fábrica para que o lento Diretor de Arte não pare o rápido Pintor. Ao executar tarefas em paralelo, agrupar instruções e reutilizá-las com sabedoria, eles conseguiram transmitir a estilização de vídeo em tempo real em um computador doméstico comum.

Resumo Técnico: Estilização de Streaming em Taxa de Vídeo em um Modelo de Difusão de Edição Condicionado por MLLM com Percepção Visual

Declaração do Problema
A tradução de vídeo em tempo real usando modelos de difusão tradicionalmente dependia de stacks de difusão de imagem condicionadas por texto, onde o denoiser U-Net é o gargalo computacional por quadro, e o codificador de texto é uma rede leve da classe CLIP (~125M de parâmetros). No entanto, a destilação agressiva do denoiser (reduzindo-o para estudantes de 4 ou 1 passo) inverte este gargalo. Em uma difusão de edição "com percepção visual", onde o sistema deve processar tanto uma imagem de origem quanto uma instrução textual, o codificador de texto é substituído por um Modelo de Linguagem Grande Multimodal (MLLM) pesado, como o Qwen3-VL (2.13B de parâmetros).

Neste regime de "Denoiser Pequeno Destilado mais Codificador MLLM Pesado" (SDD-MTE), o codificador de texto MLLM torna-se o caminho crítico. Técnicas de streaming padrão projetadas para pipelines dominados pelo denoiser falham aqui porque:

Latência do Codificador: O codificador MLLM é significativamente maior que o denoiser e contém pontos de sincronização intrínsecos CPU-GPU (ex: em embeddings de posição rotativos) que impedem o despacho simples de fluxo único.
Sobrecarga de Consistência Temporal: Adaptadores temporais existentes como o ControlNet-LLLite dependem de ramificações Python e verificações de identidade de tensor que quebram a captura de grafo do torch.compile, causando implementações ingênuas que rodam ~3.5× mais devagar que o U-Net base.
Instabilidade Numérica: Saídas de amplo alcance do MLLM (std=37, max=1160) causam overflow nos mecanismos de atenção FP16, tornando os caminhos TensorRT (utilizados por sistemas como o StreamDiffusion) indisponíveis.

O artigo aborda o desafio de alcançar throughput de streaming em taxa de vídeo em uma única GPU de consumo dentro deste regime de gargalo invertido.

Metodologia
Os autores propõem um pipeline de streaming construído em torno de três mecanismos de engenharia específicos projetados para o regime SDD-MTE, instanciados em um U-Net destilado de 0.39B (DreamLite-mobile) pareado com um codificador Qwen3-VL de 2.13B.

Pipelining de Fluxo Lateral Assimétrico / Fluxo Principal:
- O pipeline se divide em duas streams CUDA concorrentes. A Stream Principal lida com a denoiseção U-Net compilada e a decodificação VAE para o lote atual ( $n$ ).
- A Stream Lateral processa concorrentemente a codificação de texto (TE) do MLLM e a codificação VAE para o próximo lote ( $n+1$ ).
- Este design oculta a latência de sincronização intrínseca do codificador MLLM atrás da computação do U-Net.
- Amortização de Lote: O sistema faz o buffer de $B$ quadros (ex: $B=8$ ou $16$) antes de cada chamada de pipeline. Como o codificador MLLM escala sublinearmente com o tamanho do lote (sublinearidade $s \approx 0.226$ em $B=8$ ) enquanto o U-Net compilado escala quase linearmente ( $s \approx 0.77$ ), o lote reduz significativamente o custo de TE por quadro sem aumentar proporcionalmente o custo do U-Net.
- Cache de Prompt Estático (Opcional): Para fluxos com instruções fixas, o sistema pode codificar um único quadro representativo e transmitir seus tensores chave/valor para o restante do lote, ou atualizar a codificação apenas a cada $N$ lotes.
Reformulação do ControlNet-LLLite Amigável à Compilação:
- Para permitir a otimização torch.compile, os autores refatoram o adaptador ControlNet-LLLite para remover ramificações Python e mudanças de identidade de tensor que anteriormente forçavam a recompilação do Dynamo a cada quadro.
- As mudanças principais incluem o registro de embeddings de condição como buffers de tamanho fixo com atualizações in-place, a remoção de caminhos exclusivos de treinamento (dropout, verificações de dtype) e a exposição de um método forward_inference dedicado.
- Isso permite que todo o stack U-Net + adaptador seja dobrado em um único grafo fundido, alcançando um aumento de velocidade de 4.75× sobre a implementação de referência eager.
Atualização Periódica de Condicionamento e Subconjunto de Hooks:
- Cronograma de Atualização: Em vez de recomputar o embedding de condicionamento LLLite (derivado do quadro anterior deformado/warped) para cada lote, o sistema reconstrói o mesmo a cada $N$ lotes (ex: $N=8$ ). Isso amortiza o custo do CNN de condicionamento, que domina o tempo de execução do caminho LLLite.
- Subconjunto de Hooks: O hook completo de 108 para um subconjunto de 38 hooks localizados apenas nos down_blocks. Isso reduz a carga de trabalho do codificador de condicionamento em ~65%, enquanto recupera a nitidez espacial perdida ao usar todos os 108 hooks (que tendem a produzir um artefato de "roxo suave").
- Fluxo Assíncrono: O cálculo do fluxo óptico de Farneback é threadado e iniciado assincronamente durante o prefetch para sobrepor com o próximo slot da stream lateral.

Principais Contribuições

Arquitetura de Sistema: Uma estratégia de pipelining assimétrico inovadora que trata o codificador MLLM como uma carga de trabalho separada e concorrente para superar o gargalo invertido nos regimes SDD-MTE.
Otimização de Compilador: Uma implementação de ControlNet-LLLite refatorada compatível com torch.compile, permitindo a execução de grafo fundido para adaptadores temporais.
Mecanismos de Eficiência: Uma combinação de amortização de TE em lote, atualização periódica de condicionamento e seleção de subconjunto de hooks que coletivamente reduzem a latência por quadro sem degradação significativa de qualidade.
Validação Empírica: Avaliação abrangente em hardware de consumo (RTX 3090 Ti, 4090, 5090) demonstrando throughput sustentado e consistência temporal em cenários in-domain e cross-dataset.

Resultos
Avaliado em uma RTX 3090 Ti com resolução de 512×512, tamanho de lote $B=8$ e inferência de 1 passo ( $K=1$ ):

Throughput: O pipeline sustenta 27.4 FPS (latência p50 ~0.5s) e 29.6 FPS em $B=16$ (latência p50 ~1.0s) ao longo de uma execução de 480 quadros.
Escalabilidade de Hardware: O desempenho escala para 54.9 FPS na RTX 4090 e 74.1 FPS na RTX 5090.
Qualidade: A configuração "campeã" (subconjunto de hooks de down_blocks + atualização periódica) alcança um erro de warping ( $\epsilon_w$ ) de 18.34, uma redução de 20% no flicker comparado à baseline sem LLLite (22.97), enquanto mantém o detalhe espacial (score Sobel 4.74 vs. 5.10 da baseline).
Generalização: O adaptador temporal liberado generaliza para 19 sequências não utilizadas do DAVIS-2017 e 15 clipes de 7 fontes não-DAVIS com métricas de desempenho dentro do ruído in-clip do campeão.
Generalização de Prompt: O modelo lida bem com prompts de estilo não vistos (ex: Van Gogh), embora o desempenho degrade para estilos com texturas de alta frequência fora do manifold de treinamento (ex: halftone de quadrinhos).

Significância e Alegações
O artigo posiciona-se como um estudo de sistemas em vez de uma alegação de superioridade de benchmark. Ele afirma explicitamente que não reivindica superioridade sobre sistemas da classe StreamDiffusion (que usam codificadores CLIP), mas localiza seus números contra uma execução do mesmo stack do StreamDiffusion para fornecer contexto.

A principal significância reside em demonstrar que o streaming em taxa de vídeo é alcançável em uma única GPU de consumo, mesmo quando o codificador de texto é um MLLM pesado, desde que a arquitetura do sistema seja redesenhada para acomodar o gargalo invertido. Os autores enfatizam que técnicas padrão de aceleração de denoiser são insuficientes para este regime e que os mecanismos propostos (pipelining assimétrico, adaptadores amigáveis à compilação e condicionamento amortizado) são necessários para desbloquear o desempenho em tempo real.

O artigo também serve como um guia para profissionais ao documentar resultados negativos (ex: mistura de latentes ingênua, falhas de FP16 no TensorRT com saídas MLLM e as armadilhas de usar apenas o erro de warping como métrica para artefatos de suavização) para evitar comuns becos sem saída de engenharia neste domínio específico.