De 80 para 43 segundos por vídeo: cada mudança testada, com as medições

A otimização inteira, escrita como aconteceu: o que medir primeiro, onde estava mesmo o gargalo, as três mudanças feitas, quanto cada uma economizou e quais ideias plausíveis foram descartadas de propósito.

2026-08-20　作者 William Hsu

Medir primeiro, mudar depois

O modelo expõe um número de passos de amostragem, e o instinto diz que baixar isso deixa tudo mais rápido. As medições disseram outra coisa.

O ComfyUI informa o progresso nó a nó via WebSocket enquanto roda, então registrei o tempo de cada etapa de um clipe de três segundos:

A amostragem é cerca de um quarto do total, então cortar passos só economiza até certo ponto.

O gargalo é um modelo de 30 GB entrando numa placa de 16 GB

A placa é uma RTX 5070 Ti com 16 GB de memória de vídeo. O codificador de texto mais o modelo principal já passam de 30 GB, não cabem, e por isso cada execução transfere os pesos para a VRAM.

O tempo vai em mover dados, não em calcular. As três mudanças abaixo empurram na mesma direção: deixar menor aquilo que precisa ser movido.

Mudança um: um codificador de texto menor

Trocar 25,3 GB por uma versão quantizada de 14,6 GB significa mover mais de 10 GB a menos toda vez. Das três mudanças, essa foi a que mais rendeu.

Na teoria, quantizar custa qualidade. Fiz a comparação antes/depois com a mesma semente aleatória — mesma foto, mesmo movimento, mesma semente — e lado a lado os resultados são indistinguíveis. Fixar a semente é essencial: sem isso duas execuções já saem diferentes e a comparação não quer dizer nada.

Mudança dois: da amostragem de 6 passos para 4

Parece um atalho arriscado, mas o LoRA de aceleração em uso foi desenhado exatamente para 4 passos. Rodar 6 não melhora nada, só demora mais. Esse parâmetro tinha vindo de outra configuração e não combinava com este modelo.

Mudança três: remover um decodificador de áudio que ninguém usava

O fluxo padrão do modelo inclui um nó de decodificação de áudio. Nosso resultado é um clipe em loop sem som, então o resultado daquele cálculo inteiro nunca era lido por nada.

Herdar o fluxo de trabalho de outra pessoa deixa esse tipo de sobra no fluxo. O jeito de achar é medir nó a nó e perguntar de cada nó custoso: a saída dele é usada de verdade?

Resultado

Um clipe saiu de 60–80 segundos (137 no pior caso) para 42–45 segundos estáveis.

A variância também despencou: o caso de 137 segundos parou de acontecer. Para quem usa, a diferença é “43 segundos sempre” contra “60 na média, mas de vez em quando 137”.

Uma confirmação acidental

Testando outra coisa, uma repetição com os mesmos parâmetros levou só 17,2 segundos, porque o ComfyUI tinha guardado em cache a codificação anterior e pulou aqueles 17,7 segundos inteiros. Bate exatamente com a tabela acima.

O que não foi feito

• Manter o modelo residente na memória de vídeo — 16 GB não seguram 30 GB. Isso é hardware, e a única solução é outra placa
• Quantização mais agressiva — apertando mais, a perda de qualidade começa a aparecer. O ponto desta ferramenta é a pessoa continuar reconhecível; alguns segundos não valem isso
• Um decodificador VAE menor (algo como o TAE) — aqueles 11,4 segundos ainda dão para espremer, mas exigem nós extras e o efeito na qualidade teria de ser verificado de novo. Está na lista; trabalho inacabado não vira resultado aqui

Olhando para trás

Três coisas que valem a lembrança. Sem medir nó a nó, eu teria gasto o esforço nos passos de amostragem, que são um quarto do tempo. Quando falta memória de vídeo, o gargalo é a movimentação de dados, e a otimização precisa mirar em deixar menor o que se move. E uma comparação antes/depois obriga a fixar a semente aleatória, senão você não sabe se a diferença de qualidade veio da mudança ou do acaso.

這篇文章寫的是本站實際的實作與量測。工具本身在老照片動起來與變老變年輕，都可以直接試。

看其他文章