A proposta é forte. É um modelo multimodal de geração de vídeo que aceita simultaneamente texto, até 9 imagens de referência, 3 clipes de vídeo de referência e 3 trilhas de áudio numa mesma chamada. Em cima disso, ele gera saída de até 15 segundos com áudio sincronizado nativo (diálogo, efeitos, música ambiente), suporta extensão de vídeo, edição pontual de personagens e objetos, e tem planejamento de câmera dirigido por prompt. A ByteDance posiciona o modelo pra publicidade comercial, vídeos explicativos, produção de filme, e-commerce e gaming. Ou seja: pra criador de conteúdo que quer escapar do estágio “meme aleatório” e começar a entregar peça com uso profissional.

Pra quem quer ver o modelo em ação antes de continuar lendo, recomendo essa visão geral feita pelo Stefan, do canal Stefan 3D AI Lab, que eu já tinha indicado lá no post sobre modelagem 3D com IA:

A interface principal é o “Photo Studio” da Dreamina, onde você escolhe o modo de geração e empilha as referências. Por enquanto eu testei só o modo de multi-referência padrão.

Teste 1: lip-sync com áudio do podcast

Meu primeiro teste foi simples. Peguei alguns segundos do bumper de abertura do meu podcast The M.Akita Chronicles, que é gerado com IA via pipeline ElevenLabs v3, passei o meu novo avatar em estilo anime como imagem de referência, e pedi pro Seedance fazer o personagem sincronizar boca e gesticular em cima daquele áudio.

O resultado é decente. Saiu tudo de uma imagem fixa só. O lip-sync acompanha a fala razoavelmente bem, a expressão tem alguma vida, o gesto da mão entra no momento certo. Mas é o tipo de coisa que rende clipinho curto pro YouTube ou Instagram. Não é animação que você usaria como abertura de um vídeo profissional.

A função que de fato importa: vídeo de referência

E aqui eu chego no que eu considero o único uso de verdade desses modelos pra trabalho sério: usar vídeo como referência. Texto sozinho nunca vai ser preciso o suficiente. Você pode descrever a cena com o vocabulário que quiser, mudar adjetivo, especificar lente, ângulo, framing, e ainda assim cada geração vai te dar algo um pouco diferente. É loteria. Bom pra meme, péssimo pra produção.

A maioria dos amadores se impressiona com qualquer clipe aleatório que sai bonito de primeira, e enche o feed do X e do Instagram com isso. Só que aquilo não é controle. É sorte. Pra cinema, pra publicidade, pra abertura de programa, pra qualquer coisa onde a próxima cena precisa casar com a anterior, você tem que conseguir dizer pro modelo: “faça exatamente esse movimento, com exatamente essa câmera”. E é aí que o vídeo de referência muda o jogo, porque ele substitui horas de modelagem 3D, rigging, animação e renderização que custariam fortunas em estúdio.

Pro meu teste, eu reciclei o modelo que já tinha gerado lá no post sobre AI 3D com Hunyuan e Nano Banana, onde testei o quanto dá pra modelar 3D do nada com prompt e ainda imprimir em 3D. Mas pra uma referência mais cinematográfica eu queria algo com animação pronta. Baixei do Sketchfab o modelo Darth Talon, que tem uma sequência curta de movimento bem feita, só porque achei legal.

Importei o FBX no Blender, montei câmera e luz básica, e fiz uma renderização rápida no Cycles. Nada bonito, é só um esboço pra servir de referência de movimento e enquadramento.

Subi pro Seedance esse render como vídeo de referência junto com três imagens em t-pose do personagem (frente, costas, lado esquerdo) pra dar consistência visual:

Primeira tentativa, com prompt genérico:

Não ficou ruim. O personagem mantém identidade, a iluminação melhorou bastante em cima do meu render bruto, e o vídeo é coerente. Só que o movimento e a posição de câmera divergiram bastante da referência. O modelo entendeu “ali tem um personagem parecido com esse fazendo algo parecido com aquilo”, e improvisou o resto.

Lembrei do tutorial do Stefan: o truque é colocar literalmente no prompt algo como Follow exact motion and camera from reference video. Tentei de novo:

Bem melhor. Está claramente seguindo a coreografia da referência, o ângulo de câmera bate em vários momentos, e a aparência do personagem ficou mais polida que tudo que eu poderia renderizar à mão num esboço de Cycles. Mas ainda assim não é cópia exata do meu render. Em alguns frames o modelo ainda toma liberdade com timing, posição e enquadramento. Existem outras técnicas de prompting e parâmetros pra ajustar, mas eu parei aqui pra registrar essas primeiras impressões enquanto o lançamento está fresco.

ComfyUI, Runway e o resto do ecossistema

O Seedance 2.0 também já saiu como nó do ComfyUI na nuvem, o que ajuda muito quem quer encaixar a geração dentro de pipeline maior sem ficar pulando entre interface web. Pra quem já tem pipeline de geração de imagem montado em ComfyUI, isso é bem prático.

E pra quem quer um caminho com volume sem pensar em crédito por geração, a Runway está oferecendo o Seedance 2.0 dentro do plano Unlimited, que sai por volta de US$ 76/mês no anual ou US$ 95/mês no mensal. “Unlimited” no caso significa sem cobrança por geração, mas com prioridade de fila menor em horários de pico e cota de armazenamento de saída. Pra quem precisa iterar muito, esse modelo de assinatura faz bem mais sentido que crédito avulso.

A questão do preço

A precificação direta do Seedance é em crédito. O plano Standard sai por US$ 24,90/mês no anual ou US$ 49,90/mês no mensal, e te dá 2500 créditos por mês. Cada 10 segundos de vídeo gerado consome 6 créditos.

A conta é cruel. Com 2500 créditos no Standard, dá pra rodar cerca de 416 gerações de 10 segundos por mês. Parece muito, mas lembra do meu próprio teste: foram pelo menos duas tentativas pra chegar perto do que eu queria, e mesmo assim não foi cópia exata do que pedi. Na prática, pra cada cena que você quer entregar bem, é razoável assumir 3 a 5 regerações. Isso derruba o número útil pra algo na faixa de 80 a 140 cenas curtas por mês. Pode até dar pra um criador solo fazendo conteúdo curto. Não dá pra produção que precisa de minutos contínuos de vídeo polido.

Os planos superiores escalam linearmente o número de créditos, mas o problema continua: no preço de hoje, o Seedance 2.0 ainda é ferramenta pra clipe curto e meme bem-feito, ou pra prototipagem de cena antes de mandar pra estúdio de verdade. Não substitui produção profissional contínua. Pra esse perfil, na prática a Runway com Unlimited sai mais em conta. Confira a tabela de preços completa aqui.

O que ninguém quer falar: restrição e deepfake

Tem dois pontos que eu não quero deixar de fora. O primeiro: o Seedance 2.0 demorou a chegar pro grande público em parte porque a ByteDance está sendo bem mais conservadora que a concorrência na hora de moderar. O modelo bloqueia geração com referência de pessoas reais (celebridades, políticos, figuras públicas) e filtra personagens com IP forte de Disney, Marvel/DC, Nintendo e marcas registradas em geral. Quem quiser detalhe sobre o que passa e o que não passa, e por que a empresa optou por essa postura, tem esse artigo da MindStudio explicando os limites. Faz sentido: a ByteDance opera em dezenas de jurisdições, está sob escrutínio regulatório global, e ainda tem o tema espinhoso de Hollywood pressionando o setor inteiro com ações de copyright sobre uso de material protegido em treinamento e geração. O lançamento atrasou e veio com filtro pesado justamente por isso.

Segundo ponto, e mais importante: pra você, leitor comum, a mensagem é que deepfake deixou de ser hipótese. Foto na internet já não vale como prova há um bom tempo, porque modelos de imagem como Nano Banana, Hunyuan e congêneres entregam realismo que engana qualquer um. Agora vídeo está na mesma categoria. O que a gente acabou de ver acima, onde com algumas referências e dois prompts dá pra gerar uma cena animada coerente em minutos, é só o começo. A pessoa comum, sem treino, não vai mais conseguir distinguir vídeo gerado de vídeo real só batendo o olho. E os filtros do Seedance só barram o uso aberto e legal. Quem quer fazer mau uso vai sempre encontrar caminho com modelo open source, com workaround, com plataforma menos rígida. Esse é o mundo real agora, e quanto antes a gente assumir isso socialmente, melhor.

Não, isso não substitui artista de verdade

Já vou cortar o discurso de sempre antes que ele apareça nos comentários. Não, o Seedance não substitui artista de VFX, diretor, editor, nada disso. Isso aqui é martelo. A ferramenta é a mesma pra todo mundo. O que sai do outro lado depende inteiramente de quem está segurando ela.

Quem estudou enquadramento, ritmo, continuidade, direção de arte, edição, cor, composição, vai usar o Seedance pra acelerar 10 vezes o trabalho que já sabia entregar. Quem não estudou nada disso vai produzir 10 vezes mais rápido o mesmo meme de Instagram que já produzia. A IA reflete quem você é. Se você é bom artista, a ferramenta multiplica. Se você só acha que é bom, a ferramenta multiplica a mesmice. Não tem milagre.

E é por isso que essa onda de “agora todo mundo vira diretor de cinema com IA” é a mesma ladainha que ouvimos com câmera digital, com Photoshop, com After Effects, com Premiere e com qualquer ferramenta poderosa que apareceu nos últimos 30 anos. A barreira técnica cai, a barreira de gosto, repertório e estudo continua exatamente onde estava. Quem é bom fica mais produtivo. Quem não é continua precisando de gente de verdade pra fazer trabalho de verdade.

Onde isso vai parar

Seedance 2.0 é claramente um passo na direção certa, mas ainda não é a ferramenta que substitui produção profissional. Texto sozinho continua impreciso, vídeo de referência ajuda mas ainda escapa, e o preço por minuto útil de saída polida é alto pro que entrega. A boa notícia é que a história se repete: Google já tem o Veo, Runway está com modelo próprio e ainda revendendo Seedance, Kling e Hailuo da China continuam puxando, e os modelos open source vão ganhando tração. A OpenAI tinha o Sora, mas descontinuou. Conforme a competição aperta, qualidade sobe e preço cai. Em um ou dois anos a gente deve estar olhando pra esse post e achando primitivo o que acabei de mostrar. Como sempre.

Esse é o episódio do dia 6 de abril do podcast do The M.Akita Chronicles, já gerado com a nova pipeline da ElevenLabs v3. Assina o canal no Spotify pra não perder episódio novo desses.

Quando o Qwen3 TTS foi lançado, pelos idos de janeiro desse ano, todo mundo no Twitter/X e nas newsletters de IA gritou “ElevenLabs killer”. Tem artigo no Medium dizendo que é a primeira ameaça open source real à ElevenLabs. Tem post da byteiota dizendo que a clonagem de voz em 3 segundos bate a ElevenLabs. Tem análise no Analytics Vidhya falando que é o TTS open source mais realista já lançado. O consenso da internet entusiasta era: finalmente temos open source que faz frente à ElevenLabs, o jogo virou, é só questão de tempo.

Eu resolvi testar no meu próprio fluxo de produção, como de costume. Montei um pipeline inteiro em cima do Qwen3 TTS 1.7B pra gerar o podcast semanal do The M.Akita Chronicles, e documentei os bastidores no post sobre servir IA na nuvem. Quem quiser ver o detalhe de tempo de partida a frio, clonagem de voz, parâmetros de sampling que mudam de um modo pro outro, dá uma olhada nesse link que eu não vou repetir tudo aqui.

A pergunta desse post é diferente. Depois de quase dois meses rodando essa configuração em produção, com episódio indo ao ar toda segunda-feira, ontem à noite eu finalmente desliguei o Qwen3 e passei tudo pra ElevenLabs v3. Vou contar por quê.

O que não funcionou no Qwen3

Entre 15 de fevereiro e 30 de março eu fiz dezenas de commits ajustando o fluxo do podcast: prompts, parâmetros de sampling, ordem de geração, silêncios de referência na amostra de clone de voz, normalização de volume, pronúncia de siglas técnicas. Corrigir a voz do Marvin que cortava a primeira sílaba porque o áudio de referência começava sem silêncio inicial. Afinar a voz do Akita pra ela soar mais confiante e assertiva. Adicionar crossfade entre jingles de seção. Resolver a pronúncia errada de “podcast” pra ela não sair como “pódcast”. Mandar o gerador de roteiro preferir português a anglicismo gratuito pro TTS não engasgar. Cada um desses ajustes foi uma sessão de horas escutando áudio, gerando de novo, ajustando parâmetro.

O resultado ficou aceitável. “Aceitável” no sentido de que eu consegui publicar todo episódio sem ter que regravar nada à mão. Mas escutando com atenção, a voz do Qwen3 tem aquele jeito inconfundível de IA gerando áudio. Intonação meio morta, ritmo uniforme. Em trechos longos, você sente que é máquina falando. Serve pra ir pro ar, mas tá a quilômetros do que você escuta num podcast profissional feito por gente.

O problema pior foi a pronúncia em inglês. Meu podcast cobre notícias de tecnologia, então termos como “MCP”, “RAG”, “Claude Opus”, “GPT-5”, “open source” aparecem em toda conversa. O Qwen3 pegava esses termos e pronunciava eles com sotaque brasileiro, tipo “ó-péne-ssourssê”, coisa assim. Ficava ilegível pro ouvinte. A solução que eu tive que implementar foi mapear manualmente no prompt do LLM que gera o roteiro quais palavras em inglês trocar por equivalente em português. O prompt hoje tem uma seção inteira dividida entre “manter em inglês” (nomes próprios, marcas, termos já incorporados ao brasileiro) e “traduzir pro português” (anglicismo gratuito), mais ou menos assim:

**REPLACE with Portuguese** (common English words that have natural
Brazilian Portuguese equivalents):
- "update" → "atualização"
- "release" → "lançamento"
- "feature" → "recurso/funcionalidade"
- "deploy" → "implantação" or just "colocar em produção"
- "trade-off" → "dilema" or "escolha"
- "performance" → "desempenho"
- "default" → "padrão"
- "insight" → "percepção/sacada"
- "skills" → "habilidades"
- "approach" → "abordagem"
- "highlights" → "destaques"

Chamam isso aqui em casa de “limpar anglicismo pra o TTS não engasgar”. Engraçado porque eu não queria esse nível de restrição no meu roteiro. Queria que a voz simplesmente pronunciasse “update” quando o contexto natural fosse “update”. Como o modelo não consegue, tive que mutilar o vocabulário do podcast pra o resultado final ficar escutável. É uma solução paliativa, daquelas que você adiciona torcendo pra poder remover depois quando a tecnologia amadurecer.

A experiência com a ElevenLabs v3

Ontem à tarde abri uma conta na ElevenLabs, comprei o plano Pro (US$99/mês), e comecei a experimentar com o modelo eleven_v3, que saiu em fevereiro desse ano. Trinta minutos depois eu tinha uma prova de conceito rodando, e umas duas horas depois o sistema inteiro do podcast migrou. A diferença de esforço é abissal.

Os detalhes técnicos da migração ficaram documentados num doc interno do projeto, então vou resumir aqui o quadro comparativo que importa:

Repara no último ponto. O Qwen3 custa menos de dez centavos de dólar por episódio. A ElevenLabs custa quase trinta vezes mais. E mesmo assim vale a pena. Os outros pontos do quadro resolvem problemas que sugavam horas da minha semana. Eu não preciso mais escrever código pra escalar GPU na nuvem, não preciso esperar a máquina ligar toda vez, não preciso ficar de babá do modelo nem reconstruir a imagem Docker quando o peso muda. A operação virou uma linha de configuração.

E o mais interessante: as tags de emoção no meio do texto. O modelo v3 aceita marcadores tipo [sighs], [sarcastically], [dryly], [excited], e muda a entonação de acordo. Isso funciona em mais de 70 idiomas, incluindo português do Brasil. Isso transformou a geração do roteiro porque agora eu posso pedir ao LLM que monta o roteiro pra colocar tags emocionais nos momentos certos, o que dá uma vivacidade que o Qwen3 não conseguia entregar nem de longe. Um exemplo concreto do que sai no roteiro depois:

AKITA: Isso é simples. [dismissive] Quem ainda acredita que Bitcoin
vai morrer não tá prestando atenção.
MARVIN: [sighs] Mais uma semana, mais uma leva de devs confiando
cegamente em pacotes npm. Previsível.

Eu tenho até duas paletas separadas de tags, uma pro Akita (expressivo mas controlado, usa [excited], [dismissive], [emphatic]) e outra pro Marvin (estóico, só [sighs], [sarcastically], [tired], [dryly]). Isso tá tudo codificado nos prompts de geração do roteiro pro LLM saber que personagem pode usar o quê.

Sobre a voz do Marvin

Pros ouvintes que já se acostumaram com a voz do Marvin, fica tranquilo: eu fiz o clone dele na ElevenLabs usando a mesma amostra de áudio que eu já tinha usado pra treinar no Qwen3. É a mesma voz. Só que agora ela soa ainda melhor, porque o modelo da ElevenLabs captura nuance e prosódia que o Qwen3 não conseguia entregar.

Escuta aí e me conta

Pra provar que o papo é real, aqui tá o episódio de segunda-feira, dia 6 de abril, já gerado com a nova pipeline:

Se você já é ouvinte do podcast no Spotify e escutou os episódios anteriores feitos com Qwen3, compara e me diz nos comentários se você nota a diferença ou se pra você tanto faz. Eu tô curioso de saber quanto é percepção treinada minha escutando horas de áudio de TTS e quanto é diferença óbvia pra ouvinte casual.

A partir da próxima semana, todos os episódios do podcast serão gerados pela ElevenLabs v3. A newsletter já tá ligada na nova pipeline, os jobs agendados de pré-aquecer a GPU na RunPod foram desativados, e o código legado do Qwen3 fica no repositório como plano B caso um dia o v3 dê problema crônico. Em duas edições de arquivo eu volto pra ele. Provavelmente nunca vou ter que voltar.

A parte de dublar os vídeos do YouTube

Agora o gancho pra segunda metade desse post. No artigo de aniversário que eu publiquei mais cedo hoje, contei que o Claude Code traduziu quase metade do meu blog pra inglês num fim de semana. No mesmo espírito, fui atrás de dublar os vídeos do canal Akitando.

O canal tem 146 episódios, algo como 96 horas de conteúdo técnico em português, e mais de 500 mil inscritos. Eu já tinha as legendas traduzidas (um .srt curado por episódio), e o YouTube até oferece dublagem automática em inglês. Mas o resultado é tipo Google Translate de 2015: entende, passa a ideia, mas ninguém quer ouvir por muito tempo.

Testei as três abordagens de voz da ElevenLabs e só uma servia. Speech-to-Speech converte voz mas não traduz. A API de Dubbing traduz mas cria a voz sozinha, sem deixar forçar um clone específico. Só a Text-to-Speech resolvia: pegar meu .srt em inglês, mandar cada bloco pro endpoint TTS com a minha voz clonada, e montar o áudio alinhado com o vídeo original.

Só que ter o .srt traduzido não basta. Tradução crua de legenda não sobrevive ao TTS. Trechos com código-fonte, URLs, hashes hexadecimais, listas de comandos shell — o modelo entra em modo soletrar e o áudio sai com o dobro da duração esperada. Traduções longas demais estouram a janela de tempo e precisam ser condensadas pra a voz não ficar atropelada. SRTs truncadas precisam ser completadas. E a cada correção, rodar a pipeline de novo, escutar, achar o próximo problema, corrigir, repetir. O processo inteiro foi um ciclo de interrupções, correções manuais e re-runs — longe do “aperta o botão e sai dublado” que a gente imagina antes de meter a mão.

O grande desafio era o sotaque. Minha voz clonada foi treinada em português brasileiro, então quando tenta falar inglês o sotaque puxado aparece. A ElevenLabs tem a tag [American accent] que funciona em v3, mas em cima de uma voz treinada em outra língua ela é fraca — o sotaque brasileiro ainda saía por baixo. A saída foi treinar uma segunda voz minha, só em inglês. Gravei uns minutos no meu melhor sotaque americano, subi como Instant Voice Clone separado na minha conta, batizei de “Akita English”, e configurei o pipeline pra usar essa voz por padrão. O resultado sai mais natural, sem precisar de tag nenhuma, e a identidade de voz continua sendo a minha.

O teto honesto de qualidade da minha voz em inglês

Vamos ser francos. Eu sou brasileiro falando inglês, não sou nativo, e não tenho tempo nem paciência pra treinar pronúncia por horas. O clone só consegue ser tão bom quanto a amostra original — se a amostra é um não-nativo lendo um roteiro, o clone herda as imperfeições. Nenhum clone vai me fazer soar como “Fabio falando inglês perfeito”, porque esse som não existe pra o modelo imitar.

Pra chegar na versão que tá rodando, gravei cinco amostras de treino diferentes ao longo do dia, cada uma com ritmo e roteiro diferentes, e rodei um A/B ao vivo comparando com o original em português. Nenhuma soou como nativo, e nunca foi esse o objetivo. A meta realista era mais modesta: soar reconhecivelmente como eu, ler conteúdo técnico sem tropeçar, e aguentar um episódio inteiro sem cansar o ouvinte. O vencedor acabou sendo a primeira iteração, a “Akita English” original. Longe de perfeito, mas suficiente pra colocar no ar. Trocar no futuro é literalmente uma linha no arquivo de configuração.

O que mais me surpreendeu no caminho foi perceber que o ritmo da amostra importa mais que o timbre. O clone aprende a cadência de quem gravou: a iteração 5 ficou 25% mais lenta que a iteração 2 lendo exatamente o mesmo texto, só porque eu gravei aquela amostra mais devagar. Pra dublagem de vídeo tech, o alvo certo é ritmo de explicação de YouTube, vivo, uns 150 palavras por minuto. Nada de ritmo de audiobook.

Como eu alinho o áudio com o vídeo original

Um ponto não óbvio: texto em inglês tende a ser mais longo ao falar do que o português equivalente. Se você simplesmente gera o áudio de cada legenda e cola no tempo original, o dub vai se acumulando. Com 30 minutos de vídeo, você já tá vários segundos fora de sincronismo.

Minha abordagem foi atacar o problema em camadas. A primeira versão dividia o SRT em blocos menores, chamados de “chunks”. Cada chunk tinha no máximo 700 caracteres (pra v3 não alucinar) e só podia cortar em fim de frase, nunca no meio. Um algoritmo simples acumulava legendas num buffer até chegar perto do teto, depois voltava procurando a última legenda do buffer que terminava com ponto, exclamação ou interrogação, e fazia flush só até ali. O resto das legendas já acumuladas ficava pra compor o próximo chunk. Cada chunk guardava o timestamp de início e fim das legendas que cobria, pra a montagem saber exatamente onde posicionar aquele pedaço de áudio depois.

# Pra cada nova legenda que chega, checa se adicionar ela
# estouraria o limite do chunk atual.
for cue in cues:
    projected = buffer_char_len(buf) + len(cue.text)
    if projected > max_chars and buf:
        # Procura a última legenda do buffer que termina
        # com pontuação final ('.', '!', '?', '…').
        sentence_end = last_sentence_end_index(buf)
        if sentence_end is not None:
            buf = flush(buf, sentence_end, chunks)
        else:
            # Run-on maior que max_chars sem fim de frase.
            # Raro, mas acontece. Avisa e corta mesmo assim.
            log.warning("run-on sentence > %d chars — "
                        "splitting mid-sentence as a last resort",
                        max_chars)
            buf = flush(buf, len(buf), chunks)
    buf.append(cue)

    # Soft-break: se o buffer já tá pelo menos 60% cheio E
    # a legenda atual terminou uma frase, esvazia agora.
    # Mantém os chunks balanceados em torno de 60 a 100% do max.
    if cue.ends_sentence and buffer_char_len(buf) >= max_chars * 0.6:
        buf = flush(buf, len(buf), chunks)

Tecnicamente, esse foi o ponto de virada: em vez de deixar a estrutura da dublagem seguir a estrutura visual da legenda, o chunker passou a seguir a estrutura real dos parágrafos do roteiro. Não vou repetir aqui toda a novela de como cheguei nisso e por que isso acabou forçando rerender em massa, porque volto nessa história mais abaixo, na parte dos problemas que só apareceram depois do primeiro upload. O ponto técnico aqui é simples: quando a janela passou a representar um parágrafo falado de verdade, o áudio começou a soar natural e o alvo de stretch pôde subir de 92% pra 95%.

Feito isso, ainda sobra o problema do inglês ser mais longo ao falar que o português equivalente. Aqui a sacada é prever se um chunk vai estourar a janela alvo antes de gerar o áudio. Se a razão caracteres / 16 caracteres-por-segundo já passa da duração alvo com uma margem, a pipeline manda o parâmetro speed direto pra API da ElevenLabs, pedindo pro modelo gerar o áudio nativamente mais rápido. Isso preserva a prosódia muito melhor do que comprimir depois. O teto é 1.15× (acima disso a voz começa a soar atropelada).

# antes de chamar a API, prevê se vai estourar
expected_sec = char_count / EXPECTED_CHARS_PER_SEC  # 16 chars/s
predicted_ratio = expected_sec / target_sec

voice_speed = 1.0
if predicted_ratio > PREEMPTIVE_SPEED_THRESHOLD:   # 1.05
    voice_speed = min(predicted_ratio * 0.98,
                      PREEMPTIVE_SPEED_MAX)         # cap em 1.15
    voice_settings["speed"] = voice_speed

Mesmo com o speed preventivo ligado, às vezes o áudio gerado ainda fica um pouquinho mais longo do que a janela alvo. Pra isso existe uma segunda rede de proteção: medir o áudio real com ffprobe depois de gerado, comparar com a janela alvo, e aplicar o filtro atempo do ffmpeg pra comprimir no pós-processo se passou de 2% de tolerância, com teto de 1.20×. A combinação do speed nativo (1.15×) com o atempo (1.20×) dá uma compressão efetiva de até 1.38×, suficiente pra caber naturalmente mesmo nos casos mais extremos sem quebrar qualidade.

# depois de gerar o chunk
actual = ffprobe_duration(chunk_path)
ratio = actual / target_sec

if ratio > FIT_TOLERANCE:       # 1.02
    # comprime o áudio sem mexer no pitch
    ffmpeg_atempo = min(ratio, FIT_MAX_ATEMPO)   # 1.20
    apply_atempo(chunk_path, ffmpeg_atempo)

Quando um chunk gerado fica mais curto que a janela alvo, o pipeline estende o áudio levemente (sem afetar pitch) pra reduzir o silêncio feio depois que ele termina. O objetivo não é preencher a janela inteira, uma pausa natural entre frases é boa, mas suavizar os casos mais gritantes de silêncio que dariam a impressão de “áudio cortado”.

Num episódio grande, 95 minutos, 194 chunks, o desvio cumulativo total ficou em -0,7%. Uns 43 segundos de drift ao longo do episódio inteiro, imperceptível enquanto você assiste.

O que salvou o orçamento nessa arquitetura é que cada chunk fica salvo individualmente no disco como um .mp3 separado. A pipeline mantém um manifesto com o texto normalizado de cada chunk, e antes de chamar a API da ElevenLabs, compara o texto atual com o cache. Se o texto não mudou, reutiliza o áudio já gerado sem gastar crédito nenhum. Se eu reescrevo uma cue problemática, só os chunks afetados por aquela cue são regenerados — o resto do episódio fica intacto.

Isso é o que viabilizou as iterações. Eu rodava o batch, escutava trechos, identificava um problema (tradução longa demais, snippet de código que o TTS não conseguia pronunciar, chunking que cortou num ponto ruim), corrigia o SRT ou ajustava os parâmetros do chunker, e rodava de novo. Cada re-run consumia uma fração dos créditos e do tempo do run original, porque só os chunks alterados eram regenerados. Sem esse cache, cada iteração teria custado quase o mesmo que a primeira rodada, e o custo total do batch teria sido duas ou três vezes maior.

Essa mudança de chunking também teve impacto pesado no cache e no custo, mas deixo essa parte pro trecho mais abaixo onde explico a sequência de retrabalho. Aqui basta dizer que, do ponto de vista técnico, era a mudança certa.

Quando o atempo não salva: reescrevendo cue antes do TTS

Nem tudo é questão de alinhamento de janela. Tem um tipo de cue que quebra o pipeline inteiro, onde nem speed preventivo nem atempo no pós-processo resolvem, e eu só esbarrei nisso quando comecei a rodar o batch nos episódios mais técnicos do canal.

O problema é o seguinte. O v3 lê a uns 16 caracteres por segundo quando você entrega texto normal de conversa. Mas quando você entrega uma cue recheada de URL literal, hash hexadecimal, string binária, uma lista de números ordenados ou um bloco de código shell, o modelo entra em modo “soletrar letra por letra” e despenca pra uns 9 caracteres por segundo. Uma cue de 500 caracteres que devia virar 30 segundos de áudio vira 55. A checagem de sanidade derruba (porque passou de 1.8×), o retry automático tenta de novo com os mesmos 500 caracteres, os cinco retries falham seguidos, e o chunk fica preso.

E isso não aconteceu por acaso. Eu escrevia desse jeito porque sabia que esses mesmos roteiros depois virariam post no blog, então fazia sentido deixar a URL crua, o comando completo, o hash inteiro, o detalhe técnico todo mastigado pro leitor. Em português isso funcionava bem porque era exatamente o meu fluxo original: gravar o vídeo e depois publicar o texto correspondente no blog. O que eu nunca tinha preparado era a etapa seguinte, de transformar esse mesmo material em dublagem automatizada pra inglês. Eu só fui perceber esse conflito quando a pipeline começou a falhar de verdade.

Peguei isso primeiro no ep052, o guia de Ubuntu pra devs iniciantes, onde duas cues traziam URLs do github.com, URLs hkp://keyserver.ubuntu.com e um hash GPG de 40 caracteres. Tentar resolver no pós-processo seria perda de tempo. O teto de 1.20× do atempo nunca vai comprimir 55 segundos em 30, e mesmo se conseguisse ia sair num chipmunk ilegível. A saída é atacar antes, no texto.

A solução foi reescrever a cue dizendo o que o comando faz, em vez de mostrar o comando literal:

- Rode: apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 \
-   --recv-keys 0A6A3E7F79F93EF8AAB9E92BAEBB74C8B5A1E44D
+ Rode o comando completo que tá na descrição do vídeo pra importar
+ a chave de assinatura do repositório do keyserver do Ubuntu.

A legenda em inglês no vídeo continua mostrando o comando inteiro na tela, então quem lê a legenda vê o que precisa digitar. O áudio dublado descreve a intenção em linguagem falada, que é o que o TTS entrega sem engasgar. A instrução pro ouvinte fica intacta, e o caractere-por-segundo volta pros 16 esperados, então o áudio gerado cabe na janela original sem precisar esticar nem comprimir nada no pós.

Saí caçando cue assim em todos os episódios do batch. Varri do ep052 ao ep146 procurando cues com densidade alta de caractere “duro” (dígitos, colchetes, operadores, URLs longas, binário, hex) e acabei reescrevendo umas 30 cues em 13 episódios:

• ep052 Ubuntu pra devs: URLs do GitHub e hash GPG de 40 caracteres
• ep091 Hello World em C: exemplos binários
• ep095 Memória 640kB: wrap de endereço, segment-offset
• ep106 CodeMiner: endereço de e-mail soletrado
• ep113 Compressão: strings de binário puro, 75% de caractere duro
• ep115 SQL Server: lista longa de números ordenados
• ep120 Internet: endereços IP com pontos
• ep121 Sockets: dois blocos de código JavaScript
• ep122 Proxies: headers User-Agent do Chrome
• ep123 Rede segura: one-liners shell, flags do Docker
• ep126 Gentoo: demo de chroot em C
• ep136 Containers: URL de release do GitHub
• ep144 Criptografia: endereço de signing key

O padrão foi sempre o mesmo: mantém a legenda exibindo o código, a URL ou o hash na íntegra, e reescreve o texto pro narrador descrever o que aquilo faz. Eu podia ter automatizado a reescrita, deixando um LLM ler a cue e propor uma substituição no voo, só que achei mais seguro revisar tudo manualmente. É exatamente o tipo de coisa onde o modelo resolve “melhorar” um comando pra deixá-lo mais limpo e sai com shell errado. A varredura manual levou umas duas horas. A automática teria custado o mesmo tempo em revisão, com o bônus da ansiedade de ter deixado passar algum comando mutilado.

Teve também um caso estrutural esquisito no ep146, sobre Docker Compose. Duas cues ficaram grudadas por causa de uma linha em branco faltando no SRT, e o pysrt tratava as duas como uma única cue gigante. O TTS nem chegava a processar, o chunker engasgava antes. Corrigi à mão adicionando a linha em branco que faltava. Fix de um caractere, meia hora pra rastrear.

Reconstruindo SRTs truncadas

Outra armadilha apareceu quando fui rodar o batch completo: três episódios tinham legendas em inglês curtas demais em relação à duração real do vídeo. O ep056, sobre Rails, era o caso mais absurdo. Dezenove minutos de legenda pra um vídeo de 80 minutos. Sessenta e dois minutos de conteúdo sem legenda nenhuma. O ep057 (WSL 2) tinha 14 minutos faltando, e o ep068 (Git Direito) tinha 2.

Isso é rastro do meu fluxo de tradução antigo. Em algum momento eu comecei a revisar a legenda manualmente, parei no meio, e o arquivo .en.srt ficou salvo truncado no ponto onde eu parei. Não dá pra dublar um vídeo de 80 minutos com legenda de 19. O chunker gera áudio até onde consegue ler e simplesmente não sabe o que fazer com o resto do vídeo.

A solução virou um script novo. Ele faz diff entre o .en.srt truncado e o .pt-orig.srt (o auto-caption bruto do YouTube, que sempre cobre o vídeo inteiro), pega as cues que existem só em português, manda pro Claude Sonnet 4.6 com um schema JSON rígido pedindo tradução cue a cue, e cola o resultado de volta no fim do arquivo em inglês. O schema é o detalhe que importa. Quando eu tentei pedir a resposta em texto no formato N|texto, o Claude deixava cair umas 20% das cues no caminho. Com um schema JSON estrito, a taxa de drop caiu pra zero nos três reparos.

O resultado em números:

• ep068 Git Direito: +50 cues / 2 minutos reconstruídos
• ep057 WSL 2: +368 cues / 14 minutos
• ep056 Rails: +1445 cues / 62 minutos (e ainda drop de 5 cues falsas que o tradutor antigo tinha inventado no fim pra tampar a saída)

Depois dos reparos, os três episódios entraram no batch normalmente e foram dublados como qualquer outro. Tipo de ferramenta que você espera nunca precisar, só que quando precisa, compensa escrever uma vez e resolver o problema inteiro de uma vez.

Tags de emoção automáticas

Enquanto eu tava testando, resolvi adicionar mais um passo no pipeline: um “emotion tagger” que lê o SRT em inglês antes de mandar pro TTS e insere tags tipo [sarcastic], [thoughtful], [emphatic], [deadpan] em pontos onde um narrador humano naturalmente mudaria o tom. A ideia é imitar o que um ator profissional faria, colocar ênfase nos momentos certos, sem transformar o vídeo num teatro de emoções exageradas.

Essa parte é delicada por dois motivos. O primeiro: deixar um LLM solto editando o SRT tem risco real de ele “melhorar” o texto (trocar uma palavra aqui, reescrever uma frase ali) e você acabar com uma dublagem que não bate com a legenda. O segundo: LLM adora exagerar. Se você pedir pra marcar emoção, ele vai colocar tag em toda segunda frase. Pra evitar os dois, eu fixei uma lista pequena de tags permitidas e rodo uma validação de round-trip depois que a resposta do Claude chega:

ALLOWED_TAGS: frozenset[str] = frozenset({
    "[sarcastic]", "[thoughtful]", "[emphatic]",
    "[deadpan]", "[serious]", "[amused]",
    "[sighs]", "[exasperated]", "[confident]",
    "[matter-of-fact]",
})

def validate_tagged(original, tagged):
    """Garante que o SRT com tags preserva o original sem drift."""
    if len(original) != len(tagged):
        raise TagValidationError("cue count mismatch")

    for o, t in zip(original, tagged):
        # O index e o timestamp têm que bater byte a byte.
        if o.index != t.index or o.timestamp != t.timestamp:
            raise TagValidationError(f"cue {o.index}: header drift")

        # Qualquer tag fora da whitelist invalida tudo.
        bad = find_disallowed_tags(t.text)
        if bad:
            raise TagValidationError(f"cue {o.index}: {bad}")

        # O texto sem as tags tem que ser idêntico ao original.
        # Se o LLM trocou uma palavra, reescreveu algo, a
        # validação quebra e a resposta é rejeitada.
        if strip_tags(o.text) != strip_tags(t.text):
            raise TagValidationError(f"cue {o.index}: text drift")

Quando a validação quebra, a pipeline ignora a resposta e reemite o request (ou, se falhar muito, sobe o SRT sem tags mesmo). Sobre a quantidade de tags, o prompt que vai pro Claude diz explicitamente: mira em N/10 tags pra um SRT de N legendas, chão de 1 tag a cada 12, teto de 1 tag a cada 7, distribuição equilibrada entre os quatro quartos do episódio, nunca duas tags adjacentes a menos de 4 legendas uma da outra. Esse conjunto de regras foi a sexta iteração — as cinco anteriores ou enchiam tudo de tag ou concentravam no começo do vídeo.

Não deixe a v3 alucinar

Um detalhe crítico que só aparece em produção: a ElevenLabs v3 tende a alucinar quando você manda blocos de texto muito longos. Já peguei blocos onde o texto tinha uns 1.500 caracteres e o modelo gerou um áudio com nove minutos quando o esperado era um minuto e meio. O modelo simplesmente resolve continuar falando sozinho, inventando conteúdo.

A documentação oficial da ElevenLabs recomenda manter cada chamada abaixo de 800 caracteres pra evitar isso. Eu fui mais conservador e cortei em 700, sempre em fim de frase (nunca no meio de uma sentença, porque o corte no meio soa horrível quando concatena). Depois disso, subi o parâmetro stability pra 0.9 (modo Robust, mais estável porém menos responsivo a tags de emoção), liguei o apply_text_normalization pra o modelo pronunciar números e siglas direito, e adicionei uma verificação de sanidade que rejeita qualquer áudio gerado que passe de 1.8× da duração esperada.

DEFAULT_VOICE_SETTINGS = {
    "stability": 0.9,          # modo Robust
    "similarity_boost": 0.95,
    "style": 0.0,
    "use_speaker_boost": True,
}

EXPECTED_CHARS_PER_SEC = 16.0
CHUNK_SANITY_MAX_FACTOR = 1.8   # rejeita se actual > 1.8× esperado

Depois dessas mitigações, um episódio de 95 minutos (194 blocos) rodou do começo ao fim sem nenhuma alucinação. Exatamente um bloco falhou por erro 502 transitório da API, que o retry automático pegou na tentativa seguinte.

Masterização pro YouTube

O YouTube não publica número oficial, mas o consenso da indústria é que a normalização de volume dele na hora da reprodução mira em -14 LUFS. Se você entregar áudio mais alto que isso, o YouTube baixa; se entregar mais baixo, ele deixa como tá. Pra bater o alvo exato, o pipeline roda o filtro loudnorm do ffmpeg em duas passadas. A primeira mede o áudio inteiro e imprime as estatísticas (input_i, input_tp, input_lra, input_thresh) em formato JSON no stderr. A segunda passada lê essas estatísticas de volta e aplica um ganho estático linear pra pousar exato em -14 LUFS, -1.5 dBTP:

# Passada 1: medir
ffmpeg -i final_en.mp3 \
  -af "highpass=f=80,loudnorm=I=-14:TP=-1.5:LRA=9:print_format=json" \
  -f null -

# Passada 2: aplicar ganho linear com os valores medidos
ffmpeg -i final_en.mp3 \
  -af "highpass=f=80,loudnorm=I=-14:TP=-1.5:LRA=9\
:measured_I=-18.3:measured_TP=-3.1:measured_LRA=5.4\
:measured_thresh=-28.7:offset=1.2:linear=true" \
  -ar 48000 -ac 2 -c:a pcm_s16le final_en_mastered.wav

Duas passadas em vez de uma porque o modo de passada única roda em compressão dinâmica e acaba “bombeando” o ganho em trechos com muito silêncio. Com linear=true na passada 2, o ganho fica estático em cima das medições da passada 1, então não tem bombeamento. O resultado pousa dentro de ±0.1 LU do alvo, que é praticamente inaudível. O filtro highpass=f=80 na frente derruba rumble de ar-condicionado e hum de rede elétrica abaixo de 80 Hz, que o ouvido humano não escuta mas mexe nas medições de pico.

O ponto em que eu achei que estava pronto. E não estava.

Aqui entra a parte mais chata, e mais educativa, do projeto.

Eu realmente achei que tinha acertado a mão na primeira grande rodada. A pipeline fechou os 146 episódios, eu subi tudo, e parecia resolvido. A duração batia, os arquivos estavam todos lá, o processo inteiro tinha finalmente atravessado o lote completo de quase 96 horas de vídeo. Só que foi justamente depois do upload que comecei a perceber problemas que eu simplesmente não tinha antecipado.

O primeiro susto foi a situação dos jingles. Eu já sabia que muitos episódios do Akitando começam com aquele jingle instrumental curto antes de eu começar a falar, mas subestimei o problema. O .srt do YouTube praticamente não ajuda nisso, porque jingle não é fala. Às vezes ele marca como [Música], às vezes não marca nada útil, às vezes a janela fica torta. Na primeira montagem, teve episódio onde o jingle sumiu, episódio onde ele entrou duplicado, e episódio onde o source-fill do áudio original já trazia o jingle certo e o meu splice vinha por cima, empurrando todo o resto pra frente. Foi o tipo de bug que só aparece quando você para pra escutar a master final de verdade, não quando olha só pra duração total.

A solução foi abandonar a esperança de que a legenda me diria onde estava o jingle e ir direto pra fonte. Montei um detector usando os próprios áudios originais dos vídeos e jingles de referência, com auditoria e repair pass em cima dos masters já gerados. Isso acabou virando um mini-sistema próprio: detector, auditoria, reassemble por cache, correção por janela exata. No fim dessa novela, o batch de episódios alterados caiu num conjunto de reupload bem definido e o problema dos jingles ficou finalmente sob controle. Foi um daqueles casos clássicos de produção: a primeira solução parecia suficiente até bater no acervo inteiro.

Só que aí veio a segunda pancada, e essa foi mais cara: eu tinha esquecido de um detalhe fundamental sobre legendas de YouTube. SRT é feita pra ser lida na tela, não pra virar roteiro de fala. Então uma ideia que no meu texto original era um parágrafo inteiro aparecia quebrada em várias cues pequenas, cada uma com sua microjanela de tempo. Na primeira versão da pipeline eu estava usando essas cues como unidade de geração na ElevenLabs. Resultado: o TTS gerava áudio em blocos coerentes localmente, mas a montagem introduzia silêncios artificiais no meio da frase. Tecnicamente alinhado, humanamente esquisito.

O conserto foi doloroso porque exigiu voltar várias casas. Em vez de respeitar a estrutura das cues do SRT, precisei voltar pros meus textos originais e reconstruir o chunking com base nos parágrafos que eu realmente li quando gravei os vídeos. Quase todo episódio do Akitando tem o post correspondente com a seção ## Script, e isso salvou o projeto. Como eu fui meticuloso na época em que produzi os vídeos — escrevendo os roteiros antes, lendo exatamente aquilo na gravação e arquivando tanto os vídeos quanto os scripts — eu tinha a fonte de verdade. Então deu pra mapear os parágrafos do script aos timings do .pt-BR.srt, reagrupar o .en.srt em cima disso e regenerar os chunks no formato certo.

O problema é que essa mudança destrói o cache anterior. Mesmo quando o texto quase não muda, se a fronteira do chunk muda, a chamada ao TTS muda junto: muda contexto, muda prosódia, muda começo, muda fim. Então não era um retoquezinho. Era uma regeneração completa de tudo de novo. Foi aí que o custo começou a sair do meu controle inicial.

E quando eu achei que agora sim tinha terminado, veio a terceira paulada: os clipes externos. Muitos vídeos do canal têm trechos inseridos de outras fontes. No episódio de Ruby on Rails, por exemplo, tem 37signals, Apple, comerciais, pedaços externos no meio da narrativa. O .srt do YouTube não sabia lidar direito com isso. Em alguns pontos ele simplesmente alucinava texto, em outros os timings ficavam completamente tortos, em outros a fala original não tinha nada a ver com a legenda que eu estava usando de base. De novo: olhando só pra automação parecia tudo bem; escutando a master final, não estava.

A correção, mais uma vez, foi sair da legenda e voltar pro material original. Montei um detector de janelas de clipe externo a partir de gaps de alinhamento entre transcript, .pt-BR.srt, cues sem fala útil e chunks que atravessavam essas janelas. Depois, em vez de tentar dublar o que não fazia sentido dublar, o processo passou a recuperar o áudio original do vídeo exatamente nesses trechos e preencher a master com o source correto. Foi isso que consertou os casos de 37signals, Apple Education, comercial de Mac vs PC e outros inserts parecidos que eu tinha esquecido que existiam.

Esse foi o aprendizado mais importante dessa segunda metade do projeto: automação te leva muito longe, mas o acervo completo sempre tem mais cantos escuros do que você imagina no primeiro passe.

Os números do batch de dublagem (e por que doeu mais do que eu imaginei)

Eu preciso me corrigir de novo. Não errei só a primeira conta. Errei também o grau de confiança que eu tinha depois da primeira rodada.

Quando subi pro plano Business da ElevenLabs, eu achei que finalmente estaria com folga. Na prática, não fiquei. O screenshot mais recente do dashboard mostra 10.046.279 créditos consumidos de um limite de 11.000.000, sobrando 953.721:

Em português claro: eu torrei mais de 91% do limite do workspace Business. E isso ajuda a entender o que “10 milhões de créditos” realmente significa nesse contexto. Não é só “renderizei 146 episódios uma vez”. É renderizar 146 episódios, descobrir um problema estrutural, voltar, corrigir, regenerar chunks, descobrir outro problema estrutural, voltar, reconstruir masters, auditar jingles, reparar janelas de clipes externos, reupar de novo. Cada rodada a mais custa. E quando a mudança invalida o cache, custa muito.

O custo também não para na ElevenLabs. Todo o trabalho de curadoria das legendas, reescrita de cues problemáticas, reconstrução de SRTs truncadas, auditorias de jingle, detector de clipes externos e o resto rodou via Claude Code no plano Claude Max 20×. Somando isso com a tradução em massa do blog pra inglês que eu descrevi no artigo de aniversário, o limite semanal do Claude Max 20× bateu 100%, com gasto extra acima de R$ 300. Pra quem acha que IA generativa vira grátis depois que você assinou o plano, os boletos discordam.

Mesmo assim, continuo achando que vale a pena. Estamos falando de 146 episódios, quase 96 horas de conteúdo técnico, mais de 5 anos de acervo do canal. Fazer isso manualmente em estúdio, com ator, direção, pickup e revisão humana em tudo, custaria uma ordem de grandeza completamente diferente.

O que mudou foi minha visão do projeto. No começo eu tava olhando pra isso como “um batch grande”. No fim, era outra coisa. Era mexer num acervo inteiro, achar exceção escondida, consertar ferrugem antiga, refazer master, rerender, reouvir.

O primeiro batch completo levou pouco menos de dois dias e me fez pensar que eu tinha resolvido tudo. Não tinha. A segunda rodada, com chunking por parágrafo, já foi cara. A terceira, com os reparos de jingle e os consertos de masters, mais cara ainda. E a quarta pancada veio dos clipes externos que eu não tinha modelado direito na primeira automação.

Mas agora, finalmente, eu acho que acabou. Ou melhor: eu espero que tenha acabado. Tudo foi enviado de novo, pela última vez. Não está perfeito no sentido absoluto da palavra. Está tão bom quanto eu consigo deixar com script, auditoria e automação, sem entrar num inferno de intervenção manual vídeo por vídeo.

E se isso tudo foi possível, é porque anos atrás eu tive a disciplina de produzir os vídeos do jeito certo: escrever primeiro, ler o roteiro quando gravava, e arquivar os materiais depois. Sem os vídeos originais e sem os scripts originais, eu não teria como descobrir onde o .srt mentia, onde o timing estava torto, onde o clipe externo entrava, onde o parágrafo original começava e terminava. Essa organização antiga foi o que permitiu consertar o projeto agora.

Então sim: a dublagem dos 146 episódios está pronta. Não perfeita. Mas fechada. Pelo menos, eu sinceramente espero que agora sim esteja.

O primeiro teste, assista

Fiz um vídeo teste pra provar que funciona. Dois avisos antes: primeiro, o embed abaixo já carrega com a legenda em inglês ligada por padrão, então esse lado dá pra resolver via URL. Segundo, o áudio é chato: o YouTube removeu o seletor de faixa de áudio dos players embedados lá por março desse ano. Então dentro do embed você não vai encontrar essa opção no menu de engrenagem mesmo, só roda em português. Pra ouvir a dublagem em inglês de verdade, clica em assistir direto no YouTube, que a página principal do YouTube ainda tem o seletor de faixa de áudio no menu de engrenagem.

Se você tá acostumado com a dublagem automática do YouTube ou com as dublagens de IA de TikTok, compara. A diferença é gritante. A voz é a minha, com sotaque americano trabalhado, e a sincronização com o vídeo original fica dentro de 1 a 2% de desvio cumulativo, praticamente imperceptível em 95 minutos de vídeo.

E o que faltava: traduzir as thumbnails

Quando eu estava fechando esse post, me caiu a ficha de que tinha deixado uma ponta solta. As 146 thumbnails do meu canal estão em português, muitas com título em caixa alta grande tipo “9 DICAS PARA PALESTRANTES” ou “7 RECOMENDAÇÕES DE SHOWS PARA PESSOAS DE TECH”. De nada adianta áudio em inglês perfeito se a imagem que aparece na busca é um bloco de texto ilegível pra quem não lê português. O YouTube permite subir uma thumbnail alternativa por idioma, então eu precisava gerar versões em inglês, mantendo o resto da arte idêntico, trocando só o texto.

A ferramenta usa duas peças. yt-dlp é o fork moderno do antigo youtube-dl, uma CLI em Python que baixa qualquer coisa do YouTube (vídeos, áudios, legendas, thumbnails) sem precisar de API key. Nano Banana Pro (nano-banana-pro-preview na API) é o modelo de edição de imagem mais recente do Google Gemini — aceita uma imagem de entrada com um prompt e devolve a imagem editada, preservando o resto da composição quando você pede pra mexer só numa parte.

O pipeline tem dois passos. Passo 1: yt-dlp pega a thumbnail em .jpg, sem baixar o vídeo:

yt-dlp --skip-download \
       --write-thumbnail \
       --convert-thumbnails jpg \
       -o "thumbnails/originals/<slug>/<video_id>" \
       "https://www.youtube.com/watch?v=<video_id>"

Passo 2: mandar cada imagem pro Gemini Nano Banana Pro com um prompt que é um contrato rígido de requisitos duros, não só um “traduz isso”:

TASK:
Detect every piece of Portuguese text visible on this image and
translate it to clear, natural American English. Replace the
Portuguese text with the English translation in the same visual
position.

STRICT REQUIREMENTS — follow every one:
- Preserve EVERY non-text element identically: face, pose,
  expression, background, color palette, lighting, icons, logos,
  decorative shapes, borders, layout. Only the text changes.
- The English translation must be IDIOMATIC and CONFIDENT — not
  a literal word-for-word rewrite. It's a YouTube thumbnail for a
  tech audience, so use punchy phrasing a native English-speaking
  tech YouTuber would write.
- Match the original text's font family, weight, size, color,
  stroke outline, drop shadow, and any decorative treatment.
- If there is no Portuguese text at all on the image, return the
  original image unchanged.

A cláusula “return the original image unchanged” é o que salva os primeiros episódios do canal, que não têm texto na thumbnail, só minha cara. Sem ela, o modelo invariavelmente ia “melhorar” a composição, trocar a iluminação, etc.

Olha o resultado em dois exemplos (episódios 10 e 11):

Original (PT)

Traduzida (EN)

Original (PT)

Traduzida (EN)

Repara no detalhe do episódio 10. O modelo não traduziu “7 Recomendações de Shows para Pessoas de Tech” literal pra “7 Show Recommendations for Tech People”, que seria a versão tradutor automático. Ele reformulou pra “7 TV Shows You Must Watch If You’re In Tech”, como um tech YouTuber americano de verdade escreveria. O resto da imagem fica idêntico pixel a pixel. No episódio 11, “9 DICAS PARA PALESTRANTES: venda sua caneta” vira “9 TIPS FOR SPEAKERS: sell your pen”, com fonte, caixa alta e posição preservadas. Se você não soubesse que o original era em português, não dava pra adivinhar que é uma edição automática feita por IA.

Custo do lado Gemini: alguns centavos por imagem, poucos dólares totais pro batch inteiro. Trivial perto dos $1.500+ do dub. Com a thumbnail resolvida, a conversão do canal pra inglês fica fechada — áudio clonado pela ElevenLabs v3 em cima das legendas curadas em .srt, e a imagem editada pelo Nano Banana Pro pra o título bater com o resto.

A conclusão, que é o título desse post

Quando o Qwen3 TTS saiu, o hype dizia que era “ElevenLabs killer”. Passei semanas tentando viver com essa premissa na prática, com conteúdo real no ar toda semana. E o que eu descobri é que open source de TTS ainda tá muito longe da ElevenLabs. A diferença é grande, e ela aparece justamente quando você sai do tweet de demo de 5 segundos e coloca o modelo pra rodar um podcast semanal de 30 minutos de verdade.

Na prática, o Qwen3 nem bate o modelo v2 da ElevenLabs. O v3, que é o atual, fica um degrau acima do v2 ainda. A prosódia sai melhor, as tags de emoção no meio do texto funcionam em português e em inglês sem esforço, e a API fica de pé sem você precisar manter servidor nenhum. O custo por caractere é um pouco mais alto, mas pro meu volume atual ele fica confortavelmente dentro do orçamento e me devolve horas que eu gastava cuidando de GPU.

A lição aqui é a mesma que a galera de LLMs tá aprendendo devagar. Demo de tweet de 30 segundos é uma coisa, produção é outra coisa completamente diferente. Open source tem seu nicho, principalmente quando você tem dado sensível que não pode sair de casa, ou quando você tem muita GPU ociosa e pouco orçamento recorrente. Só que pra uso sério de TTS em produto comercial, aqui em abril de 2026, a ElevenLabs segue imbatível. O Qwen3 não matou ninguém.

E não esquece: assina o The M.Akita Chronicles no Spotify pra não perder episódio novo desses, feito com a nova pipeline.

E não deixe de assinar minha nova newsletter The M.Akita Chronicles!

Já vou falar do podcast hoje; lembrem-se de que o episódio piloto já está no ar (transcripts e RSS pra assinar) e no canal no Spotify.

–

Todo tutorial de IA começa com “instale o modelo, rode inference, pronto!”. Nenhum te conta o que acontece quando você precisa rodar isso em produção com uptime real, custo controlado, e qualidade consistente.

Vou contar como foi colocar um modelo de TTS (Text-to-Speech) em produção numa GPU na nuvem. Porque se você está pensando em servir modelos de IA, precisa saber no que está se metendo.

O Cenário

O objetivo: gerar um podcast de ~30 minutos a partir de texto, com duas vozes distintas, qualidade de broadcast, pronto pra Spotify. Toda semana, automaticamente, sem intervenção humana.

O modelo escolhido: Qwen3-TTS, um modelo de text-to-speech que suporta voice cloning e fine-tuning. Roda em GPU — precisa de pelo menos 6GB de VRAM pra inference.

A plataforma: RunPod, que oferece GPUs serverless com cobrança por segundo de uso.

Parece simples, né? Pois aguarde.

Problema 1: Cold Start — O Assassino Silencioso

GPU serverless funciona assim: quando não tem requisição, o worker desliga. Quando chega uma requisição, ele liga, carrega o modelo na VRAM, e processa.

O tempo de “carregar o modelo na VRAM” é o cold start. Pra um modelo de ~4GB, estamos falando de 30 a 90 segundos. Sua requisição HTTP fica pendurada, esperando. Se seu timeout é de 30 segundos, você nem chega a ver o modelo funcionar — só vê timeout.

A solução ingênua: “aumenta o timeout!”. A solução real: health check com polling.

@app.get("/health")
async def health():
    if not model_loaded:
        return JSONResponse(
            status_code=503,
            content={"status": "loading", "detail": "Model loading..."}
        )
    return {"status": "ready"}

O cliente (no caso, um job Rails) faz polling no /health antes de mandar a requisição real:

def wait_for_server(max_wait: 180)
  deadline = Time.current + max_wait
  loop do
    response = http_get("/health")
    return if response.code == 200
    raise "Server não iniciou a tempo" if Time.current > deadline
    sleep 5
  end
end

Parece primitivo? É. Mas funciona melhor do que qualquer solução sofisticada de “warm pool” que custa 10x mais.

Problema 2: Onde Ficam os Pesos do Modelo?

Um modelo de 4GB precisa estar disponível quando o worker inicia. Três opções:

1. Bake no Docker: Imagem de 4GB+. Build lento. Push lento. Pull lento.
2. Download do HuggingFace no boot: Depende de rede. Pode falhar. Adiciona minutos ao cold start.
3. Network Volume: Disco persistente montado no worker.

A opção 3 é a correta. O RunPod oferece Network Volumes que persistem entre execuções. O modelo fica lá, sempre pronto. O cold start é só o tempo de carregar da disk pra VRAM, sem download.

Mas tem uma pegadinha: o volume pode estar montado ou não, dependendo de como o worker é configurado. Então o código de setup precisa ser resiliente:

NETWORK_VOLUME = "/runpod-volume"
LOCAL_FALLBACK = "/workspace/models"

def resolve_model_path():
    if os.path.isdir(NETWORK_VOLUME):
        base = os.path.join(NETWORK_VOLUME, "huggingface")
        os.environ["HF_HOME"] = base
        return os.path.join(base, "hub", "models--Qwen--Qwen3-TTS")
    # Fallback: download local
    return LOCAL_FALLBACK

Auto-detecção. Se o volume existe, usa. Se não, funciona do mesmo jeito (mais lento no primeiro boot). Nunca assuma que a infraestrutura está perfeita.

Problema 3: Dois Modos de Voz, Dois Conjuntos de Parâmetros

Aqui está algo que nenhuma documentação vai te dizer: modelos de TTS com voice cloning e fine-tuning precisam de parâmetros de sampling completamente diferentes dependendo do modo.

Com uma voz fine-tuned (treinada especificamente no modelo), você quer parâmetros conservadores:

temperature: 0.5
top_p: 0.8
repetition_penalty: 1.1

Com voice cloning (voz base + áudio de referência), os mesmos parâmetros produzem ruído branco. Literalmente. White noise. Porque o modelo de clone precisa de mais “criatividade” pra reconstruir as características vocais:

temperature: 0.9
top_p: 0.95
repetition_penalty: 1.05

Descobri isso depois de horas gerando áudio inutilizável. A documentação do modelo não menciona. Os papers acadêmicos não mencionam. É o tipo de conhecimento que só vem de experimentação em produção.

Problema 4: O Áudio de Referência Importa Mais que o Modelo

Voice cloning usa um trecho de áudio como referência pra replicar a voz. Parece simples: grava 10 segundos, passa pro modelo e pronto.

Exceto que se o áudio de referência começa com a fala imediatamente — sem nem 200 milissegundos de silêncio no início — o modelo aprende que “o áudio começa sem onset”. E toda geração subsequente vai cortar a primeira sílaba.

Isso não é um bug do modelo. É o modelo fazendo exatamente o que você pediu: “gere áudio que começa igual a essa referência”. Se a referência começa cortada, a geração começa cortada.

A correção não é pós-processamento (o áudio já foi gerado sem a sílaba). É corrigir a referência: garantir pelo menos 300ms de silêncio antes da fala.

Pra quem vem do mundo de software, isso é contra-intuitivo. Estamos acostumados a tratar dados de entrada como imutáveis e consertar na saída. Com modelos generativos, a qualidade da entrada é tudo.

Problema 5: Timeout e Limites de Geração

Um modelo de TTS gera áudio token por token. Se você não limitar, ele pode gerar indefinidamente — e no RunPod, você paga por segundo de GPU. Um turno de diálogo de 30 palavras não deveria gerar 3 minutos de áudio, mas sem limite, pode.

MAX_NEW_TOKENS = 720  # ~60 segundos de áudio a 12Hz
GENERATION_TIMEOUT = 180  # 3 minutos absolutos

with ThreadPoolExecutor(max_workers=1) as executor:
    future = executor.submit(model.generate, **params)
    result = future.result(timeout=GENERATION_TIMEOUT)

Dupla proteção: limite de tokens na geração e timeout absoluto no processo. Se qualquer um disparar, o turno falha e pode ser re-tentado com parâmetros ajustados.

Problema 6: Pós-Processamento é Metade do Trabalho

O modelo gera WAV cru. Pra chegar em áudio de podcast quality, o caminho é longo:

1. Normalização de loudness: Spotify exige -14 LUFS. Sem normalização, cada turno tem volume diferente.
2. Re-encoding: Os WAVs do modelo podem ter formatos sutilmente diferentes (sample rate, bit depth). Concatenar com -c copy causa segmentos silenciosos. Precisa re-encodar tudo pro mesmo formato.
3. Conversão pra MP3: CBR 192kbps, 44.1kHz, com metadata ID3.

E a normalização de loudness precisa ser two-pass: primeiro mede, depois aplica. Single-pass é chute — e chute em produção gera áudio com volume inconsistente entre episódios.

# Pass 1: análise
ffmpeg -i input.wav -af loudnorm=I=-14:print_format=json -f null -

# Pass 2: aplicação dos valores medidos
ffmpeg -i input.wav -af loudnorm=I=-14:measured_I=-18.5:measured_TP=-2.1:... output.wav

Tudo isso roda no servidor, depois da geração do TTS. E precisa de ffmpeg instalado no container — mais uma dependência pra gerenciar.

Problema 7: O Script Importa Mais que o Modelo de Voz

Depois de resolver GPU, cold start, voice cloning, sampling, normalização — o podcast sai. E soa… robótico. Não por causa do TTS. O TTS é excelente. Soa robótico porque o texto é robótico.

Esse é o problema que ninguém menciona em pipelines de TTS: a qualidade do áudio começa no script, não no modelo de voz. Um TTS perfeito lendo um texto seco e formal produz áudio seco e formal. Garbage in, garbage out — mas num nível que você não espera.

Duas Passadas: Draft e Refine

A solução é gerar o script em duas passadas de LLM:

Passada 1 (Draft): Transforma a newsletter em diálogo. Aqui o LLM recebe o conteúdo completo e cria a estrutura — quem fala o quê, em que ordem, com quais transições. Sem mudar o conteúdo, só a forma!

Passada 2 (Refine): Pega o draft e torna natural. Adiciona hesitações, reações, interrupções, auto-correções. Transforma “script lido” em “conversa real”.

Por que não fazer tudo numa passada? Porque são tarefas cognitivamente diferentes. Estruturar conteúdo e adicionar naturalidade ao mesmo tempo resulta num texto que não faz nem um nem outro direito. Duas passadas especializadas produzem resultado consistentemente melhor.

Personalidade Precisa de Instruções Brutalmente Específicas

“Faça o Akita soar confiante” não funciona. O LLM vai produzir confiança genérica — frases motivacionais, tom positivo. Não é isso. Akita é confiante porque é assertivo e impaciente. A diferença está nos detalhes do prompt:

## Akita Delivery Style

- **Declarative, not tentative**: "Isso é óbvio" not "Eu acho que talvez isso seja..."
- **Dismissive of nonsense**: "Isso é bobagem", "Não tem nenhum mistério aqui"
- **Owns his track record**: "Eu avisei", "Quem assistiu meu canal já sabe"
- **Never hedges**: No "talvez", "quem sabe", "pode ser que"
- **Impatient with the obvious**: "Vocês já sabem como funciona"

E pro Marvin (o co-host robô):

- **Filler words** (Marvin only): "bom...", "olha...", "enfim", "pois é"
- **Self-corrections** (Marvin only): "quer dizer...", "ou melhor..."
- Akita doesn't second-guess himself — if he corrects, it's
  "Não, peraí" and he restates with even MORE conviction

Sem esse nível de especificidade, os dois personagens soam iguais. O LLM precisa de exemplos concretos de como cada um fala, não de descrições abstratas de personalidade.

Normalização Pra Fala: O Que Parece Certo no Texto Soa Errado no Áudio

Siglas. O inimigo invisível do TTS. “EUA” no texto é perfeitamente legível. Falado pelo TTS, sai “éu-á” — incompreensível. O prompt precisa de regras explícitas de normalização:

## Spoken Text Normalization (MANDATORY)

- `EUA` → `Estados Unidos`
- `UE` → `União Europeia`
- `IA` → `inteligência artificial`
- `LLM` → `modelo de linguagem`
- `API` → `interface de programação`

Isso precisa estar no prompt de ambas as passadas (draft e refine), porque o LLM tem tendência a reintroduzir siglas que removeu na passada anterior.

O LLM Vai Reescrever Suas Opiniões (Se Você Deixar)

Essa foi a lição mais sutil. A newsletter tem comentários opinativos do Akita e do Marvin em cada seção. Quando o LLM transforma em diálogo, ele substitui as opiniões por versões mais “balanceadas” e “nuançadas”. Akita que dizia “isso é bobagem” vira Akita dizendo “isso tem seus méritos, mas…”. Marvin pessimista vira Marvin “levemente cético”.

O LLM faz isso porque foi treinado pra ser helpful e balanced. Opiniões fortes parecem “unhelpful” pro modelo, então ele suaviza. A instrução original — “use os comentários da newsletter como sementes pra conversa” — era vaga demais. Dava liberdade pro modelo reinterpretar.

A correção é ser explícito e inflexível:

**PRESERVE THE ORIGINAL OPINIONS**: The newsletter contains Akita and
Marvin commentary on each topic. These opinions are the author's real
voice — you MUST preserve their substance, stance, and conclusions.
Make the delivery conversational, but do NOT change what they actually
think. If Akita's comment says "isso é bobagem", the podcast version
must convey the same dismissal. Rephrase for spoken delivery, but
never substitute a different opinion.

É a diferença entre “adapte pra conversa” (LLM entende: “reescreva como quiser”) e “mude o COMO, nunca o QUÊ” (LLM entende: “mantenha a opinião, troque a embalagem”).

E isso vale pra qualquer prompt engineering com conteúdo autoral: o LLM vai homogeneizar sua voz se você não for explícito sobre preservá-la. E num podcast onde a personalidade dos hosts É o produto, perder a voz é perder tudo.

O Custo Real de IA em Produção

Vamos ser práticos sobre custos no RunPod:

O custo por episódio é baixo. O custo de descobrir como fazer funcionar é alto. Foram dezenas de horas de experimentação, logs incompreensíveis de CUDA, gerações falhadas, e áudio com qualidade inutilizável antes de chegar numa pipeline estável.

E o custo cognitivo: manter dois ecossistemas (Python pra ML, Ruby pra aplicação) sincronizados, com interfaces HTTP entre eles, e debugging que cruza fronteiras de linguagem.

De qualquer forma, pra quem pensou “Por que não Elevenlabs?”, bom, eu consegui qualidade similar, numa fração do custo, e aprendi muito no processo (e vocês também, lendo aqui).

Lições

1. Cold start é um requisito, não um bug. Design seu sistema esperando que o modelo demore pra carregar.

2. Network volumes são obrigatórios pra modelos grandes. Não bake pesos no Docker, não faça download no boot.

3. Parâmetros de sampling não são universais. Cada modo de operação do mesmo modelo pode precisar de configuração completamente diferente.

4. A qualidade da entrada domina a qualidade da saída. Tanto pro áudio de referência do TTS quanto pro script. Se a referência corta a primeira sílaba, toda geração corta. Se o script é genérico, o áudio é genérico.

5. Timeouts em todas as camadas. Token limit, process timeout, HTTP timeout. Se não limitar, o custo escala e a geração trava.

6. Pós-processamento é metade do pipeline. O modelo gera matéria-prima. Normalização, encoding, metadata — tudo isso é trabalho real.

7. Separe o servidor de ML da aplicação. Python pra inference, Ruby pra orquestração. Tentar fazer tudo numa linguagem é receita pra frustração.

8. Prompts precisam de duas passadas pra conteúdo complexo. Estruturar e naturalizar são tarefas diferentes. Forçar as duas numa passada produz resultado medíocre em ambas.

9. O LLM vai homogeneizar sua voz. Opiniões fortes viram “nuanced takes” se você não for explícito sobre preservá-las. Instrua o modelo a mudar a embalagem, nunca o conteúdo.

Conclusão

IA em produção não é um tutorial de HuggingFace com 10 linhas. É infraestrutura, é experimentação, é debugging de problemas que não existem em software tradicional. Mas quando funciona — quando seu sistema gera um podcast inteiro automaticamente toda semana, com qualidade broadcast, sem intervenção humana — a sensação é que valeu cada hora de dor de cabeça.

O truque é não subestimar a complexidade. E ter um sistema robusto (como os jobs do Rails que mencionei no primeiro post) orquestrando tudo — porque IA sem orquestração confiável é só um script caro que trava.

Mas fui prematuro na conclusão. Opções open source ainda variam bastante em qualidade, maioria não é muito boa, mas as opções comerciais são muito boas e bem estáveis. Não vou listar tudo que existe então fica minha recomendação de dois canais no YouTube pra se manter atualizado:

• PixelArtistry_
• Stefan 3D AI Lab

Na prática, existem vários workflows de ComfyUI pra brincar, como neste tutorial ensinando a usar o recém-lançado modelo Trellis2, da Microsoft. Não funciona perfeito como no video todas as vezes. Depende muito da imagem que se passar. Nos meus testes só consegui uns “blobs” deformados.

Mas no mundo comercial, existem 3 ferramentas que vale criar conta:

• Hunyuan Global, da Tencent. Existe a plataforma em chinês - que é mais completa - e a versão global em inglês que é mais limitada. Mas com ele é possível criar modelos 3D a partir de imagens com qualidade excepcional.
• Hitem3D - é concorrente da Hunyuan, também é excelente pra gerar modelos 3D a partir de imagens. Vale testar nas duas porque dependendendo das imagens que se passar, uma pode resultar melhor que a outra.
• Yvo3D - é uma das mais caras, mas especificamente pra gerar texturas em alta qualidade, parece que é o melhor disparado.

Tem várias outras plataformas e pra se manter atualizado existe o site Top3D.ai com o ranking das melhores ferramentas. A maioria costuma ter planos gratuitos, trial, ou coisas assim, então é bom testar quantas puder. O preço não é “caro” se você é um profissional que vai usar em trabalho pra cliente. Só é caro pra caras com eu, que usam como hobby.

Algumas que vale a pena testar são Hyper3D Rodin, Tripo AI, Prism e SAM 3D. Nos canais de YouTube que recomendei, tem videos sobre eles, então pelo menos assista.

A carta na manga: Nano Banana

O grande truque pra qualquer plataforma, seja open source ou comercial, é começar com imagens de boa qualidade. Imagens de Google Images, ou suas fotos mal tiradas, sempre vai resultar em modelos 3D ruins.

Pra limpar imagens, o jeito mais fácil é ir no Google Nano Banana. É de longe a melhor plataforma de IA pra editar e gerar imagens.

Como exemplo, resolvi partir de uma imagem que minha namorada encomendou pra um artista no Fiverr e que mandamos fazer adesivos pra colar no nosso arcade. Esta imagem:

A primeira coisa que pedi ao Nano Banana foi pra remover o background e separar só a personagem. É o tipo de coisa que antigamente precisaria de Photoshop pra fazer. Olha como fica agora:

(não liguem que tá espelhado, fiquei com preguiça de pegar a imagem certa.)

Enfim, ainda não é o suficiente pra gerar 3D. No caso específico de gerar modelos de personagens, o ideal é ter imagens em “T-Pose”, “pose em T”, que é a pessoa ereta de pé com os braços abertos como Jesus. E ter fotos exatamente de frente, de trás, pela esquerda e pela direita.

E dá pra pedir pro Nano Banana fazer exatamente isso: “generate a front photo of this character in T-Pose, for 3D modeling” e ele vai gerar isso:

Metade do trabalho acabou neste passo. Sem isso não dá pra gerar modelos bons. Agora é só mandar gerar os outros ângulos, como de costas:

Mesma coisa, imagens do ângulo na esquerda, na direita e pronto. Pelo menos 4 imagens consistentes, coerentes, limpas.

Hunyuan Global

Agora é a parte simples. Basta escolher Hunyuan ou Hitem3D. No caso, escolhi Hunyuan:

Só escolher o novo modelo versão 3.0 e mandar gerar com 1.5 milhões de polígonos (sim, é bem pesado, mas depois é só fazer remesh) e opcionalmente mandar gerar texturas (já sabendo que Hunyuan não é bom com texturas).

E olha o resultado. Perfeito! Do jeito que tá já dá pra usar. Como falei, ele não é muito bom com texturas, mas como meu objetivo pra esse teste foi imprimir na minha impressora 3D, não me preocupei com texturas.

Abrindo no Blender, posso colocar um modifier de remesh pra diminuir a resolução de polígonos e converter tudo em quads e fica assim:

E de cara já tentei imprimir e saiu assim:

Fiquei particularmente impressionado com os detalhes: nada torto, nada fora do lugar, mãos com 5 dedos, proporções corretas, detalhes no rosto perfeitos, cabelo perfeito.

Pense nisso: fui do nada, ao IA, a uma impressão 3D física!

E agora que eu tenho esse modelo, posso mandar pro Adobe Mixamo, que é uma ferramenta online pra re-usar poses pré-prontas.

Consigo subir meu modelo, calibrar a armatura/esqueleto e colocar na pose que eu quiser. Eis um exemplo:

No Blender consigo calibrar peso de partes do mesh e outros detalhes pra melhorar a pose, mas os 80% do trabalho já foi feito automaticamente. Com isso consigo fazer animações e muito mais.

Portanto, sim, modelagem 3D já é uma realidade com IA. Existem dezenas de ferramentas pra diferentes casos de uso e especialidades, como geração de texturas, esqueletos, animação.

O principal: comece com uma boa fundação usando Nano Banana como falei, esse é o principal truque pro resto funciona direito. E fiquem sempre de olho na Tencent: o Hunyuan é o modelo mais interessante.

No mundo open source tem o Hunyuan pequeno pra rodar local e agora o Trellis2. Também fiquem de olho em novos workflow que usem esses dois juntos no ComfyUI.

Do meu lado, pra fazer coisas simples que eu quero imprimir em 3D na minha Bambulab X1C, isso já tá mais que excelente!

Atualização: este post está obsoleto. Hoje uso akitaonrails/aitrepreneur-docker, que roda as stacks do Aitrepreneur localmente em Docker com modelos e workflows pré-carregados. Veja o README para detalhes.

No post anterior mostrei como gerar character sheets pra desenvolvimento de games. Mas alguns me perguntaram “e se eu quiser roupas específicas?”.

Hold my Beer

Tem como, é um workflow separado que depois dá pra adicionar ao workflow anterior se quiser (fica de lição de casa). Basta pegar o personagem gerado no primeiro grupo de nodes e passar por este outro workflow que troca roupas. (ou fazer o trabalhinho extra de gerar loras e ativar com palavras-chave no prompt também, não existe só um jeito).

Diferente do workflow do Mick - que é pago - este outro é aberto, peguei em algum Reddit e coloquei na pasta de workflows do meu projeto de Docker como “garmente-replacement-idm-vton.json”, só carregar no ComfyUI e brincar. Vamos ver o resultado. Eis duas imagens, o resultado não é perfeito, mas veja se descobre qual dos dois é o original e qual é o gerado pela I.A.:

Resposta ao final do post kkkk

Mas vamos lá, o workflow completo se parece com isto:

No estágio atual da minha setup tem um glitch que não consegui resolver. Eu acho que é a extension JNodes que está abrindo um popup infernal no top esquerdo da interface, que não fecha de jeito nenhum. Por enquanto estou abrindo o Inspector e deletando o Node do HTML direto mesmo kkkk gambiarra mas funciona:

Se alguém souber como consertar, agradeceria muito. Tem um alert de uma extension que parece que tá defasada, esse front-end alguma coisa, mas é só ignorar. Tinha que ser front-end-alguma-coisa …

Enfim. neste primeiro grupo, é simples, basta carregar uma imagem o mais limpa e clara possível da roupa nova que quer usar. E depois a foto original onde quer que essa roupa seja aplicada. Ele não faz milagre, se a foto for de alguém com paletó e você quiser mudar pra regata, às vezes ele consegue, mas não espere que os braços e torso sejam bons, ele vai redesenhar tudo como achar que precisa, ou vai acabar colocando a regata em cima do paletó, enfim, é I.A., quanto mais claro for o objetivo, melhor o resultado. Se a nova roupa é um paletó, idealmente o original era outro paletó, vai encaixar melhor.

Já avisando que os modelos do IDM-VTON pesam realmente uma TONELADA. Ele sozinho baixa nada menos que 30GB de modelos (já incluso no meu setup) e vai exigir mais de 20GB de VRAM, então abaixo de uma RTX 3090 de 24GB, não vai rodar. Tem como rodar online, no site do Hugging Face. Assista este tutorial que mostra como:

Esse é o canal do Aiconomist. Ele mostra como rodar online e como fazer o setup na sua máquina neste outro video que usei de referência pra fazer meu workflow. Assinem o canal dele, vale a pena, os tutoriais são bem explicadinhos e tem mais detalhes que não vou explicar neste post.

Isso dito, tem um bug que ainda não resolvi. Depois que roda o workflow, o modelo fica pendurado na VRAM da GPU e se tento rodar de novo, ele EMPERRA. Aí tenho que desligar o container de Docker e reiniciar pra recuperar a memória. Tentei um node de Clear VRAM GPU mas não funcionou. Se alguém souber como consertar, agradeço também.

O próximo passo é recorrente em vários workflow: extrair camadas de informações da foto original. Conseguir uma máscara da roupa que queremos substituir e informações da pose original:

É por isso que workflows de ComfyUI são poderosos quando você começa a entender como processo é dividido. Essas partes são reusáveis e diferentes modelos dão diferentes resultados dependendo dessas controlnets que se adiciona.

Aí chegamos na parte principal: ligar todas essas informações no node de IDM-VTON, que vai reposicionar a nova roupa em cima da foto original:

Note que o resultado não é muito bom, fica bem “fake” mesmo. E tem como ajustar parâmetros pra melhorar. Mas o caso de uso não é usar pra trocar por roupa específica mas sim por roupa similar. Já vou explicar, mas antes, uma tangente.

O repositório da extension original desse Node é este Mas se tentar instalar, ele quebra. Parece que ele está um pouco defasado com o ComfyUI e precisa rodar numa versão mais velha. Mas isso é um saco. Então, eu resolvi fazer um FORK com as correções necessárias pra rodar na versão mais nova (as versões mais novas dos pacotes de Python diffusers, transformers, huggingface_hub, quebram o IDM-VTON).

Aliás, o gerenciamento de dependências de Python é bem RUIM. Mas do ComfyUI é ainda pior, porque diferentes extensions (que instalam dependências de Python globalmente) podem estar em diferentes estágios de desenvolvimentos. Toda vez que o ComfyUI em si muda, todo mundo precisa atualizar rápido. Por isso o ideal é não instalar a versão da branch master do ComfyUI, sempre uma versão estável (marcada numa tag) ou duas versões pra trás, pra garantir. Mas aí tem extensions novas que exigem você estar na versão mais nova. Como falei, é um pesadelo pra gerenciar. Sendo programador, eu consigo “gambiarrar” quando dá erro, mas usuários normais vão sofrer um pouco.

Feito o rant. No passo anterior a primeira parte do fluxo acaba. Quando bate nesse node Image Sender, o processo pára - não sei porque. E precisa clicar no botão “RUN” uma segunda vez. Daí o outro node, Image Receiver, vai receber a nova imagem. Acho que vou só apagar esses dois nós e ligar direto o output “image” do node Run IDM-VTON Inference e ligar direto no próximo node que são o Image Composite Masked e o VAE Encode.

Vamos voltar um passo:

Nesse próximo passo, no segundo “RUN”, ele pega a imagem com a nova roupa, mas baixa qualidade e carrega um novo checkpoint (no caso o juggernaultXL mas poderia ser qualquer outro como o próprio SDXL, FLUX ou dreamsharper). O modelo vai determinar a nova foto, que é o que se gera no final, na direita.

Note que a nova foto tem qualidade de roupa muito melhor, mas a cara é completamente diferente. Ele usou as informações da foto original, manteve a pose, a proporção do corpo, até o fundo, mas o rosto ele não consegue manter. Não tem problema, porque podemos ajudar.

Lembra que no passo anterior conseguimos a máscara (preto e branco) da posição exata da roupa? Podemos aumentar a máscara e aplicar um Gaussian Blur (pra depois ele mesclar bonitinho na foto original) e usar isso pra recortar da foto gerada com o rosto diferente, usando o modelo IPAdapter (que sozinho são outros 30GB de modelos - falei que é pesado).

Se não entendi errado, IP Adapter é o responsável por conseguir gerar novas imagens COERENTES entre si, com o mesmo rosto, ou mesmas roupas, mas em outras posições, por exemplo, um tipo de geração condicionada. Com ele é possível controlar BASTANTE a coerência de novas imagens, gerar uma personagem em diferentes posições, em diferentes fundos e sempre mantendo as características da personagem original.

O IP Adapter vai usar a foto original, manter o rosto, usar as máscaras e misturar com a foto com o rosto diferente, tirando só a roupa e depois juntar tudo no Image Composite Masked que é o Node final do processo.

No final, podemos comparar a primeira tentativa de colocar a roupa nova (que ficou ok mas feita, e a roupa nova, que ficou diferente mas mais bonita) e tudo integrado na foto original, mantendo o mesmo rosto.

Como falei, as qualidades são afetadas pela escolha do modelo, as configurações do KSampler, número de passos, cfg e tudo mais. Tem que experimentar e gerar várias até chegar no resultado que te agrada mais. É assim que se aprende mais também. Não é só clicar uma vez e magicamente já ter o resultado. Um bom artista experimenta dezenas de vezes.

A imagem final talvez não seja adequada pra ser capa da Vogue (embora eu já tenha visto muita capa oficial BEM duvidosa). Vai depender da necessidade. Em particular é bom pra prototipação. “Como será que fica essa roupa vestida na minha modelo?” Em vez de chamar a modelo, mandar vestir, ou gastar uma hora Photoshopando, em minutos dá pra experimentar várias roupas diferentes e ver se a modelo combina com a roupa, sem precisar gastar tempo. Pra um fotógrafo só mostrar pro cliente, antes de gastarem dinheiro com estúdio, ajudantes, equipamento, etc. Dá pra visualizar rapidamente e discutir detalhes muito mais rápido.

É nesse tipo de coisa que ferramentas como essa podem ajudar muito e diferenciar um artista do outro, não substituindo o artista, mas criando mais opções. E o principal: todos esses workflows são modificáveis, você reprograma e combina com outros como quiser. O limite é a criatividade.

Resolvi documentar neste post sobre um dos workflow mais complexos que eu testei que funciona nesse meu setup: como desenvolver Character Sheets de personagens aleatórios, em qualquer estilo, seja realista, seja estilo pixar, seja estilo cartoon, o que você quiser. O resultado é um sheet como no exemplo abaixo. Em várias poses, várias iluminações, várias expressões de emoção, com índice de cor, tudo gerado do absoluto zero pela “I.A.”. Em meia hora de processamento na minha RTX 4090.

Imagine que você é estag em estúdio de jogos. Seu trabalho: criar 100 personagens de fundo (NPCs). No fim tem que gerar 100 desses. Mas só porque é personagem secundário, não pode fazer de qualquer jeito, tem que ser todos coerentes, em todas as poses. Imagina quantos dias você iria levar. E se desse pra automatizar? É pra esse tipo de cenário que I.A. é interessante. Gaste mais tempo nos personagens principais, faça manualmente, mas não perca tempo nos secundários e não baixe a qualidade final de tudo.

Eu não fiz esse workflow, quem fez foi o Mickmumpitz. Assista o video inteiro dele pra saber como funciona esse workflow, não vou repetir o que ele já explica:

Também não vou compartilhar o workflow dele, porque ele tem um Patreon pago (é super barato, só USD 10 por mês), que te dá acesso a baixar o pacote de workflow inteiro dele neste link

Mas só isso não adianta, os requerimentos que você precisa:

• uma máquina parruda com pelo menos uma RTX 3090 com 24GB de VRAM. Importante aqui é VRAM, os modelos usados fácil ultrapassam uso de 20GB. CPU é menos importante, eu uso uma 7950X3D mas uma 7800 já daria conta.

• caso não tenha máquina assim, dá mais trabalho mas você pode alugar uma na RUNPOD. Eles tem várias configurações de GPU, mas você vai precisar saber configurar um pouco Linux ou escolher Windows e fazer o tutorial do Mickmumptiz tudo na mão (vai por mim, você vai sofrer se fizer assim).
• precisa ter pelo menos 500GB de espaço disponível e internet boa pra baixar. Na primeira vez que meu Docker rodar, ele baixa automaticamente todas as extensions de ComfyUI e todos os modelos pra tudo. Dá pra editar o arquivo models.conf antes e remover modelos que sabe que nunca vai usar. Mas só este workflow exige pelo menos uns 30GB de modelos, não tem como fugir disso.
• esse workflow é particularmente PESADO porque são várias funcionalidades (que podemos desligar partes, pra customizar pro nosso fluxo de trabalho). Mas pra 1 personagem, o fluxo inteiro pode levar 30 MINUTOS. Mesmo numa RTX 4090 como a minha.

Se fez tudo certo até este ponto, tem ComfyUI rodando com todas as dependências já baixadas e comprou o Workflow. Quando carregar vai ter que consertar algumas coisas manualmente.

Primeira coisa é que vai ver um erro em vários Nodes em vermelho, todos de Ultimate SD Upscale, basta clicar com o botão direito do mouse em cada um e escolher “Fix Recreate” que vai consertar automaticamente:

O ComfyUI exige que cada slot de output de um Node se ligue no slot de input de outro Node compatível, mas frequentemente os workflow ficam tão grandes que tem fiozinho conectando coisa espalhado pra tudo que é canto e fica bem difícil de saber o que liga no que. Literalmente fica macarrônico.

Mas existe uma extension (que eu já deixei pré-instalado) chamado cg-use-everywhere. Toda extension é um projetinho do GitHub, clonado no sub-diretório custom_nodes. Ele permite conectar a saída de Node nesse node Anything Elsewhere, digamos a saída “clip” do Node “Load Clip”. Agora, todo outro Node que tiver como input o campo “clip” e não tiver nada conectando explicitamente nele, vai usar esse Anything que foi criado. Funciona super bem.

Só nesse workflow do Mick que, sei lá porque, todos os Anywheres estão quebrados. Mas é fácil consertar. Basta procurar esses Nodes, apagar, criar novos e reconectar. Tem vários logo no começo, anote quem liga em cada um, apague e crie um novo pra reconectar:

Tem também alguns no grupo 02 de Upscale:

Nodes pequenos, só com o título, estão COLAPSADOS. Só clicar com o botão direito e escolher EXPAND pra ver os detalhes. É outra forma de organizar a bagunça.

Por último, tem que rechecar o nome correto dos modelos em todos os Nodes de “Load” alguma coisa logo no começo do workflow (ainda bem que ele organizou esses nodes tudo junto):

No workflow dele, o Node vem procurando por “FLUX/flux1-dev-fp8.safetensors” mas aí você vai na lista (que puxa o que está mesmo no diretório “models/checkpoints” na sua máquina) e escolhe o que tem o mesmo nome. Isso acontece frequentemente porque diferentes pessoas organizam sub-diretórios diferentes pros modelos. Mas depois de configurar é só salvar e pronto. Tem que fazer isso pro checkpoint, controlnet, ic-light, etc.

Os erros do ComfyUI não são amigáveis. São stacktraces de Python, que não são amigáveis porque ele mostra que linha do código deu pau, mas não mostra o que tinha nas variáveis passadas pra função que deu pau. Daí não dá pra saber onde foi. Mas normalmente na interface web, o Node fica em vermelho, daí você checa e normalmente é porque esqueceu de baixar o modelo ou escolher o certo da lista.

Última coisa nesse workflow é baixar a image de OpenPose da página de Patreon dele, que linkei no começo do post, e carregar:

OpenPose é um formato de arquivo padrão que descreve poses, formato aberto que pode ser editar em várias ferramentas. E tem diversos modelos pré-treinados pra extrair poses nesse formato a partir de imagens, então nem precisamos editar na mão. Podemos baixar várias poses pré-prontas e abertas neste site:

Vou repetir várias vezes. mas assistam o video tutorial do Mick onde ele explica como mandar gerar personagens do zero ou usar suas próprias fotos com suas próprias poses pra continuar o fluxo a partir disso. O workflow dele, depois que roda, tem esta cara (com zoom lá embaixo):

Na primeira parte, tem a configuração e checagem manual dos modelos. Só tem que arrumar uma vez e salvar. Depois sempre vai funcionar igual. Nesse primeiro menu também dá pra ligar e desligar alguns dos grupos de Nodes, por exemplo, pra pular a primeira etapa de gerar personagem do zero e poder usar suas próprias fotos:

Se optar por gerar personagem do zero, tem em verde uma caixa de prompt pra digitar como quer que seja sua personagem, em que estilo. Prompts de Texto são decodificados por modelos de CLIP (Contrastive Language Image Pre-Training), que são específicos pra determinadas categorias de UNETs (como SDXL pra Stable Diffusion ou o melhor e mais popular FLUX agora). Parte do aprendizado é começar a aprender quais sub-modelos (clips, clip_vision, vaes, loras, etc) são compatíveis com quais unets (unet, checkpoints, diffusion_models). Não pode misturar qualquer coisa. Grosseiramente, é meio que se você escolhe fazer um texto em alemão, todos os plugins tem que ser em alemão.

Não vou mostrar o workflow completo porque nem cabe, mas dá pra ver em verde os prompts, no meio onde escolhemos que pode queremos (tá no Patreon dele), e em cima a image gerada pelo modelo flux1-dev-fp8, um dos melhores e mais populares por ter excelente qualidade e não ser tão pesado (fp8 em vez de fp32, por exemplo).

Isso é uma das vantagens de usar ferramentas fora dos Dalle ou Midjourney da vida: podemos controlar todos os aspectos da geração da imagem não só com prompts de texto, mas com prompts de imagens, como o OpenPose.

Outro detalhe. Expliquei no meu post anterior sobre KSampler ou Samplers em geral, que são o motor que faz todo o trabalho de juntar todos os modelos, imagens, prompts, controlnet, vaes e produz a imagem final. Os parâmetros do KSampler como steps, cfg, denoise, scheduler e mais DEPENDEM do modelo escolhido. Tem modelos bem documentados, tem modelos mal documentados.

Por exemplo, digamos que você leu numa thread de Reddit sobre esse outro modelo mais otimizado chamado “TurboVisionXL”, que está disponível no site Civit.ai:

Realmente é um bom modelo mas e agora? O que eu configuro no KSampler pra ele? Felizmente se scrolar a página (sempre leia a documentação original!!) vai encontrar estas recomendações:

Viu só? Ele explica o que configurar e quais são limitações conhecidas. Mais embaixo vai ter comentários de outras pessoas que podem dar mais dicas ou compartilhar erros que você já tenha visto. É uma enorme comunidade, precisa aprender a participar dela.

Mas voltando da tangente, no segundo grupo de nodes do Mick, ele pega a primeira imagem em “Pose T” e passa por um processo de “Multi View” usando Diffuser MV que faz isso automaticamente. É a mesma pose, mas como se a câmera desse um 360 graus ao redor dela, pegando ângulos diferentes e, principalmente, gerando novas imagens coerentes com a original (veja como o modelo é usado até pra inventar as costas da personagem).

Nesse passo também ele extrai só o rosto da primeira imagem pra fazer outros tratamentos em paralelo. Reconhecimento e extração de rostos é super comum. Todo sistema de segurança usa, Google Photos usa pra organizar álbuns dinâmicos. E vale você aprender pra usar em seus produtos. É um processo razoavelmente leve e rápido hoje em dia e tem vários algoritmos e modelos pré-prontos pra usar. Nesse caso acho que nem usa I.A. propriamente dito, é um algoritmo mesmo.

Outro detalhe: modelos de geração de imagens normalmente trabalham em BAIXA RESOLUÇÃO. Normalmente abaixo de 1024x1024. Não espere gerar imagens 4K logo de cara. Mas não tem problema, porque a solução é primeiro gerar uma image de baixa resolução e depois passar por outro modelo de I.A. especializado em UPSCALING como o RealESRGAN que já falei no meu outro post sobre upscaling de anime

Diferente do que faz um Photoshop ou qualquer editor de imagens, se tentar aumentar uma imagem, ele só vai pegar um pixel e tentar duplicar, quadruplicar os pixels ao redor. Mas isso costuma só deixar a imagem maior mas borrada (blurred), porque ele não tem como saber os detalhes, e nem vai tentar “inventar” detalhes.

Pra “inventar” detalhes, precisa de um modelo pré-treinado que aprendeu o que desenhar. É como funciona também o DLSS 3 da NVIDIA pra games, onde o jogo renderiza em baixa resolução, como 720p e o DLSS, em tempo real, redesenha a nova tela em 4K. Não fica perfeito, mas jogando a 60fps, você raramente vai notar a diferença. Só vai perceber que ficou mais NÍTIDO.

Por isso também, se você usar sua própria foto, ou foto de pessoas conhecidas, vai ver que a nova foto depois de upscaling ficou levemente diferente, não é mais a mesma pessoa, porque o modelo REDESENHA detalhes que não existiam. É um processo de interpretação e não de descobrir detalhes “escondidos” (isso não existe, só na ficção de CSI).

O workflow do Mick vai um passo além e tem uma segunda passada de upscaling, focando em consertar somente o rosto om um Node de Face Detailer, feito especificamente pra consertar e melhorar rostos. E aqui entramos em território de cirurgia plástica e harmonização mesmo kkkk o rosto final vai ser diferente do original. Mas pra NPC e personagens secundários não importa, ninguém vai saber a diferença mesmo, basta não estar deformado, zarolho ou algo assim que salta à vista.

Existem Nodes especializados em expressões, como o Expression Editor (PHM) que parte de uma única foto de rosto e consegue gerar novas fotos nas mais variadas emoções - que podemos configurar exatamente, numericamente, como queremos. Não vou mostrar, mas note que as imagens geradas estão em baixa qualidade, mas o próximo passo do workflow é justamente fazer upscaling delas também.

Esse passo é interessante. Primeiro a parte de cima, com os vários cenários. Eles foram todos gerados via os prompts em verde abaixo deles, prompts que o Mick deixou mas podemos editar como quisermos OU trocar o node de geração e colocar de Load Image pra carregar nossas próprias imagens de fundo, de fotos de verdade.

O objetivo desse passo é gerar os rostos sob diferentes configurações de luz. Muita gente pensa que “luz” em jogos é só “acender a luz vermelha” e todo mundo vai ficar vermelho automaticamente. Em jogos novos, com RAY TRACING sim, por isso é SUPER PESADO. Mas em jogos feitos pra máquinas antigas, jogos indie, não dá pra exigir isso de todo mundo.

Daí se usam “truques” pra falsificar coisas como luzes e sombra. É o processo de BAKING onde literalmente “estampamos a luz na textura” dos objetos e personagens. Com a luz global ligada ou desligada, eles sempre vão estar “pintados” na luz colorida da cena. Pra mudar de cena, carregam novas texturas com outras luzes “baked”. Pra programadores, pense em baking como Caching. Pra que toda vez recalcular tudo dinamicamente, se a luz da cena nunca muda? Economize esse passo e já deixe “cacheado”.

Voltando, esse passo usa a tecnologia IC-Light que é outro projeto open source que vale aprender, mesmo se não se interessa por I.A. Ele consegue manipular a luz de qualquer imagem ou foto. Você, como fotógrafo, pode mudar a luz caso tenha mudado de idéia, em pós-produção. Ferramentas da Adobe ou BlackMagic, acho que já incluem tecnologia similar, mas é bom saber que existe open source e dá pra integrar no seu produto.

Depois de gerar os rostos com diferentes luzes, obviamente tem outro passo de upscaling - que estou pulando de mostrar - e vai pro grupo de nodes final que junta tudo num “sheet”, uma “folha do personagem”. O desenvolvedor de jogos pode usar direto num jogo 2D (pense um visual novel game da vida), ou pode servir de base pra UV Mapping de texturas de um modelo 3D simples com Armature pra animar e já tem alguns rostos de emoções. Bom pra colocar no cenário de fundo, pedestres andando na rua, fazendo compras, sentados na praça ou algo assim.

Além disso, o tutorial do Mick descreve como, é possível criar LORAS (Low-Rank Adaptation). Se quiser conseguir gerar personagens com estilo ou mesmo rostos específicos (sem intervenção “artística” da I.A.), você escolhe um modelo como FLUX ou SDXL e “em cima” dele adiciona um segundo sub-modelo compatível com informações sobre essa pessoa ou personagem.

Pra isso você tira várias fotos limpas e bem iluminadas da pessoas, nos mais diferentes ângulos, nem precisa de muito, só uma dúzia é suficiente. Pra cada imagem cria prompts que descrevam bem, e é isso. Tem ferramentas pra gerar esses Loras localmente ou sites que fazem isso (assista o video).

Falando em prompts, em vários workflows existem passos pra descrever prompts detalhados de imagens geradas dinamicamente. Em vez de exigir que o usuário (você) faça isso manualmente, é possível usar um modelo de decoding, que decodifica imagens em prompts de texto. O modelo mais usado pra isso é o FLORENCE 2 da Microsoft.

Esse box de texto embaixo é read-only, você não precisa digitar manualmente. O Node de Florence 2 Run vai ler a imagem e gerar esse texto. Veja como ele descreveu a primeira imagem da mulher na pose de “T”. Fazendo testes, pro seu caso, você determina se só isso é suficiente, se não for basta colocar um segundo Node de prompt e concatenar os dois antes de mandar pra outros nodes.

Enfim, tem MUITA coisa pra explorar só nesse workflow. O Mick fez um excelente trabalho tanto no workflow quanto no video pra explicar e vale a pena pagar os 10 dólares pra contribuir. Existem dezenas de workflows assim disponíveis na Web, basta procurar. E meu setup está cada vez mais complexo. Pretendo ficar ajustando ele pra cada novo workflow interessante que esbarrar. Já tem vários pré-testados na pasta “workflows” do meu projeto pra você brincar.

Atualização: este post está obsoleto. Substitui a configuração manual por um projeto containerizado mais limpo: akitaonrails/aitrepreneur-docker. Ele roda as stacks do Aitrepreneur localmente em Docker, com versões fixadas, modelos persistentes e workflows pré-carregados. Veja o README para detalhes.

No post anterior expliquei meu projetinho de como subir ComfyUI pré-configurado e pré-carregado automaticamente usando Docker Compose. Assumindo que você já tem tudo de pé, agora é entender essa desgraça do ComfyUI um pouco.

Eu também não sou nenhum especialista, mas achei legal explicar alguns conceitos que muitos ignoram.

Modelos Pré-Treinados

Todo GPT da vida, ou Stable Diffusion ou outros carregam um banco de dados vetorial na memória da GPU, na VRAM, pra processar. São modelos GRANDES, chamados de 7B, 70B, 100B, etc. “B” de “Bilhões de Parâmetros”. Parâmetros não tem definição usável fora da matemática, são simples números. Esses números representam “alguma coisa” dentro milhões de dimensões dentro desse arquivão.

Em um jeito BEM GROSSEIRO, eu penso como sendo artefatos de compressão. Você pega PETABYTES de livros, imagens, textos, posts, etc, quebra tudo em tokens e encontra “relacionamentos” de um token com vários tokens e vai “posicionando” no espaço, mas não em 3 dimensões, mas milhões de dimensões. Modelos de I.A. são “Vector Space Models” ou VSMs, mais ou menos como é o índice de um Elasticsearch se você já brincou com procura de texto com relevância, ou qualquer plugin de “Full Text Search” de um Postgres ou MS-SQL. São todos VSMs.

Eu penso assim: é como se o processo de treinamento - a parte SUPER CARA, que leva MESES - pegasse toda informação que é passada e compilasse um novo “dicionário” pra uma nova “língua”. Agora, quando você “fala” com um GPT, primeiro ele precisa transformar seu texto da sua língua pra essa “língua interna” dele, isso é o que chamamos de um “Embedding”.

Qualquer dado pode ser transformado. Áudio pode ser convertido em texto e de texto em embeddings. Videos podem ser desmonstados em séries de imagens com informação temporal. Imagens podem ser desconstruídas em elementos como luminância, crominância, etc. No fim, tudo pode ser desconstruído em estruturas de dados, não tem mágica.

Modelos de Geração de Imagem são treinados diferente. Tem diversos focos, foco em nitidez de rostos, foco em exatidão de poses, foco em estilos diferentes como cartoon ou pintura, foco em categorias como animais ou objetos. Por isso tem dezenas de modelos por aí e diversos “loras”.

Pra gerar uma imagem a partir de um prompt, primeiro precisa decodificar seu prompt num embedding, pra isso servem coisas como um TEXT ENCODER no ComfyUI.

No caso específico de I.A. pra imagens, eu entendo que se usa um tal de modelo de “DIFUSÃO” tanto pra desestruturar a imagem original, quanto pra reconstruir uma nova imagem. Não é intuitivo, mas a reconstrução não começa numa tela branca, como seria pra um desenhista humano. Ele começa com uma imagem com barulho aleatório “noise” tipo isso aqui:

O modelo começa desse barulho e via um tal processo de DIFUSÃO começa a redesenhar a imagem de trás pra frente, até sair do caos e chegar numa imagem.

O que eu “ACHO”, “CHUTO” que aconteça - sem ter lido paper nenhum, preguiça mesmo - é que tentamos influenciar esse barulho inicial. Por exemplo, extraindo funcionalidades da imagem como um mapa de profundidade, que se parece com isso:

A foto original era assim:

.jpg)

Extrair um Mapa de Profundidade é um ALGORITMO e não “I.A.”. Qualquer Photoshop, Premiere da vida conseguem fazer isso com uma mão nas costas. Mas é pra explicar que tem muito mais informação numa imagem que só olhando você - que não é treinado - não sabe que existe.

Outro tipo de ALGORITMO bem conhecido é o Canny Edge Detection que faz um mapa de bordas, pra ficar mais fácil de saber onde alguma coisa começa e onde termina na imagem:

Então é mais ou menos assim:

• assim como um texto é “convertido” numa Embedding, vetores que capturam a “essência” do significado do texto, dependente da VSM do modelo pré-treinado, uma imagem é “convertida” internamente num LATENT, que por ser imagem é um “espaço” (por isso se fala em Latent Space). Latents não temos como “visualizar”, porque é uma representação interna que depende da U-NET, o modelo pré-treinado, a rede neural que aprende a “tirar barulho” (denoise) o Latent.
• Uma U-NET de imagens é grosseiramente similar a um modelo de texto como GPT ou LLaMA, o modelo pré-treinado, read-only, que vai ser usado pra produzir o resultado final.
• Uma resposta de GPT é uma continuação do contexto da conversa anterior. Ele não está “respondendo” você diretamente, está só “continuando” o texto da conversa e por acaso, pelo treinamento, o resultado “se parece” com uma resposta. No caso de imagens, começamos com uma imagem aleatoriamente barulhenta (noise) e num processo de tirar e adicionar barulho, ele vai “reorganizando” o Latent numa imagem que conseguimos reconhecer.
• Existe um “Scheduler” que decide quanto barulho é adicionado ou removido a cada passo no tempo. E existe o conceito de DIFFUSION MODEL que é mais ou menos o “pipeline” de processamento.
• Podemos controlar o processo adicionando um prompt de texto, que é decodificado numa “embedding” usando um Text Decoder normalmente tem nomes como “CLIP” ou propriamente um Transformer (como LLava). Esses embeddings vão pra U-NET usando camadas de atenção cruzada, direcionando o “denoising” em direção ao significado do prompt.
• Além disso temos CONTROLNET que é uma segunda rede paralela, que adapta o processo pra condições extras. É uma cópia da arquitetura de U-NET (com pesos congelados) que recebem inputs extras, como o Canny Edges, ou Depth Maps, esqueletos de pose (via OpenPose), etc e aprende pequenos ajustes pra INJETAR nos mapas principais da U-NET.
• Durante o processo de denoising, ativações da ControlNet são mescladas às da U-NET, forçando o processo a respeitar as condições que passamos.

Então a U-NET é o “gerador”, o Diffusion Scheduler orquestra o processo, text encoder e contronet, ambos influenciam a U-NET, e um VAE é usado no final pra converter um espaço latente em uma imagem propriamente dita que nós, humanos, conseguimos enxergar.

BEM, BEM A GROSSO MODO. É mais ou menos como eu entendo o processo. E eu entendo que o ComfyUI expõe vários desses passos na forma de “NODES PROGRAMÁVEIS”, que podemos parametrizar e ajustar pra influenciar como queremos que a imagem final saia.

Além de parâmetros numéricos, esses Nodes também nos deixam escolher quais arquivos de modelos pré-treinados pra cada etapa queremos usar. É tudo um VSM binário, mas pra utilidades diferentes, por isso muitos tem a mesma extensão como eu expliquei, mas ficam em sub-diretórios diferentes. Pra cada Node conseguir achar só o que lhe interessa.

Pegando o exemplo da minha foto, não é isso mas só pra ilustrar, me ajuda a pensar que aqueles mapas que eu mostrei influenciam a imagem “noisy” numa direção não-aleatória, como este que eu peguei numa etapa intermediária do workflow que estou rodando:

Se forçar seus olhos, consegue ver influência das imagens anteriores, e o modelo de Difusão vai fazendo o “denoising”, sendo “atrapalhado” pela ControlNet. Como se você estivesse desenhando e tivesse uma pessoa do lado que de vez em quando apaga o que você fez, ou desenha por cima, e você vai se adaptando. Então no final vira um trabalho “colaborativo” entre os dois. Se fosse só a U-NET, ele ia gerar uma nova imagem bem diferente da original, mas a ControlNet é o “cliente” que fica toda hora de buzinando na orelha “não é assim que eu quero, muda”, até chegar num resultado aceitável.

Além disso, uma U-NET não é boa pra gerar imagens de altíssima resolução. O ideal é gerar imagens pequenas, 512 pixels, 1024 pixels, mas nada maior. Mas isso seria inútil pra usar profissionalmente. Pra isso servem UPSCALE MODELS. Se leu meu artigo de ontem sobre Video2K eu explico que escolho um modelo lá que é bom pra coerência temporal de video. Mas tinha outros modelos que são melhores pra “IMAGENS ESTÁTICAS”, ou fotos. E podemos usar eles no ComfyUI.

Depois que a nova imagem pequena é gerada pela U-NET, depois podemos usar ela como entrada pra um segundo passo de “UPSCALE” usando um modelo como RealERSGAN, e sair de uma imagem de 1024 pixels pra 2160 pixels, essencialmente 4K. É diferente de aumentar a imagem num Photoshop, onde fica tudo “soft” borrado. Como também é outro modelo de I.A. ele é treinado pra “redesenhar” em mais resolução. E podemos adicionar isso no workflow do ComfyUI também.

Mais do que isso, o ComfyUI também suporta Nodes com modelos como o HunyuanVideo da Tencent, que apresentei no outro artigo de ontem, sobre FramePack. Na verdade, podemos fazer a mesma coisa que o FramePack faz mas a partir de um workflow de ComfyUI: gerar um video a partir de uma imagem, usando o mesmo modelo. O FramePack é infinitamente mais fácil de usar, mas o ComfyUI é a faca suíça de I.A.: ela faz TUDO, por isso também é infinitamente mais complicada e precisa se dedicar bastante pra aprender a usar.

Entendendo até aqui, olhem o workflow que eu usei (está com zoom out, dá pra aumentar o zoom dinamicamente):

Dá pra ver esses passos intermediários usando Nodes de PREVIEW então é mais ou menos assim que podemos usar o ComfyUI pra fazer muita coisa avançada. Como falei, eu mesmo ainda não comecei nem a arranhar a superfície.

Vamos resumir alguns dos conceitos usados no ComfyUI agora:

1. Checkpoints (Modelos Base)

O que são:
São os modelos principais do Stable Diffusion (ex: SD 1.5, SDXL, Flux). Contêm toda a arquitetura do modelo:

• Text Encoder (CLIP)

• Modelo de Difusão (U-Net)

• VAE (Decoder de imagens)

Para que servem:
Gerar imagens a partir do zero. Cada checkpoint tem um “estilo” diferente (realista, anime, etc).

Exemplos:
flux.safetensors, realisticVisionV60.safetensors, anythingV5.safetensors

2. VAE (Autoencoders Variacionais)

O que são:
Componente que decodifica as imagens do espaço latente (formato que o modelo entende) para pixels visíveis.

Para que servem:

• Melhorar detalhes e cores

• Alguns checkpoints requerem VAEs específicos

Exemplos:
vae-ft-mse-840000.safetensors, animevae.pt

3. Text Encoders (Codificadores de Texto)

O que são:
Modelos que convertem seu prompt de texto em representações numéricas que a IA entende.

Tipos comuns:

• CLIP: Padrão para a maioria dos modelos

• OpenCLIP: Versão alternativa usada no SDXL

• T5: Modelos maiores para prompts complexos

Exemplos:
clip_vision.safetensors, openclip.safetensors

4. CLIP Vision

O que são:
Modelos especializados em análise visual (ao contrário do CLIP normal que é texto→imagem).

Para que servem:

• Criar descrições de imagens existentes

• Ferramentas como “Image Prompt” (usam a imagem como input)

Exemplo:
clip_vision_g.safetensors

5. Diffusion Models (Modelos de Difusão)

O que são:
Parte específica da arquitetura (U-Net) responsável pelo processo de difusão (adição/remoção de “ruído”).

Para que servem:

• Treinamento de LoRAs

• Workflows avançados de reutilização

Exemplo:
unet.safetensors

6. LoRAs (Adaptadores Leves)

O que são:
Pequenos arquivos que modificam o comportamento do checkpoint principal sem substituí-lo.

Para que servem:

• Adicionar estilos específicos (ex: anime)

• Criar personagens consistentes

• Ajustar proporções corporais

Exemplo:
epiNoiseOffset.safetensors, add_detail.safetensors

7. ControlNet

O que são:
Modelos que impõem controle sobre a composição da imagem (poses, profundidade, bordas).

Tipos comuns:

• OpenPose (poses humanas)

• Canny (bordas)

• Depth (profundidade)

Exemplo:
control_v11p_sd15_openpose.safetensors

8. Upscale Models (Modelos de Upscaling)

O que são:
Modelos para aumentar resolução e detalhes de imagens geradas.

Tipos:

• ESRGAN: Para detalhes realistas

• Anime6B: Especializado em arte anime

Exemplo:
4x_NMKD-Superscale-SP_178000_G.pth

9. Embeddings (Textual Inversions)

O que são:
Pequenos arquivos que adicionam conceitos novos ao vocabulário do modelo.

Para que servem:

• Estilos artísticos específicos

• Objetos personalizados

• Correções de artefatos

Exemplo:
bad_prompt.pt, easynegative.safetensors

10. Style Models

O que são:
Modelos especializados em aplicar estilos visuais ou “filmes” de arte sobre a imagem gerada, sem alterar de fato a estrutura básica do conteúdo.

Para que servem:

• Colorização temática (ex: paleta de aquarela, sépia, croma‑key)

• Simular técnicas artísticas (óleo, guache, traço de mangá)

• Unificar estética em séries de imagens (mesmo “clima” de cor e luz)

Exemplo de arquivos:

• flux1-redux-dev.safetensors (estilo “Flux Redux”)

• watercolor_v2.safetensors (pinceladas de aquarela)

• film_grain_vintage.safetensors

11. SAMs (Segment Anything Models)

O que são:
Redes de segmentação gerais capazes de isolar objetos ou regiões de interesse em uma imagem, produzindo máscaras binárias ou ponderadas.

Para que servem:

• Criar máscaras de objetos/pessoas para aplicação seletiva de filtros ou composições

• Guiar ControlNets (ex: aplicar difusão apenas dentro ou fora de uma região)

• Pré‑processar referências (recortar fundo, separar camadas)

Exemplo de arquivo:

• sam_vit_b_01ec64.pth (SAM ViT‑B, modelo base de segmentação)

Resumo Visual

models/
├── checkpoints/        ➔ Modelos principais (Stable Diffusion)  
│     └── *.safetensors, *.ckpt  
├── diffusion_models/   ➔ Modelos de difusão alternativos  
│     └── *.safetensors, *.gguf  
├── loras/              ➔ Adaptadores de estilo (LoRAs)  
│     └── *.safetensors  
├── controlnet/         ➔ Controles de composição (ControlNets)  
│     └── *.pth, *.safetensors  
├── vae/                ➔ Decodificadores / Encoders do VAE  
│     └── *.pt, *.safetensors  
├── clip/               ➔ Encoders CLIP de texto  
│     └── *.safetensors, *.pt  
├── clip_vision/        ➔ Encoders CLIP de visão  
│     └── *.safetensors  
├── text_encoders/      ➔ Encoders de texto avançados  
│     └── *.safetensors, *.bin  
├── upscale_models/     ➔ Modelos de super‑resolução  
│     └── *.pth  
├── sams/               ➔ Modelos Segment Anything (SAM)  
│     └── *.pth, *.onnx  
├── style_models/       ➔ Modelos de estilo visual  
│     └── *.safetensors  
└── embeddings/         ➔ Embeddings / conceitos personalizados  
      └── *.pt, *.safetensors  

Tem que baixar as coisas certas nos lugares certos. E pra dificultar, como já falei, os arquivos costumam ter a mesma extensão. Então é muito fácil confundir e jogar um text encoder no diretório de clip ou vice-versa. De novo, por isso encorajo que atualize o arquivo “models.conf” e coloque as URLs certas nas listas certas, assim fica bem mais organizado e o meu Docker vai puxar as coisas pros lugares certos quando inicializar.

Ainda assim pode ter algumas outras dúvidas que eu também tive no começo. Por exemplo “Por que a U-NET é chamada de Checkpoint?”

Checkpoints ≈ Sistema Operacional Completo

• Semelhança: Assim como um commit no Git captura um estado específico do código, um checkpoint é um “snapshot” completo de um modelo treinado em um estágio específico.

• Diferença: Checkpoints são autocontidos (não são “diferenças” como commits), cada um é um modelo completo que pode funcionar independentemente.

• Melhor Metáfora: Pense em checkpoints como diferentes versões do Windows (XP, 7, 10) - cada um é um sistema operacional completo, não incremental.

Então checkpoints meio que se assemelham, em conceito, a um “git commit” - se você for desenvolvedor. Ou snapshots de BTRFS ou ZFS - se você for de infra/devops.

LoRAs ≈ Plugins/Extensions

• Semelhança: Assim como um PR adiciona funcionalidades a um código base, um LoRA modifica o comportamento do modelo base.

• Diferença: LoRAs não são “merged” no checkpoint original, mas sim aplicados dinamicamente durante a inferência.

• Melhor Metáfora: São como extensões do Chrome (ex: AdBlock) - adicionam comportamentos específicos sem modificar o navegador em si.

Pense assim: um modelo tem Checkpoints, como se fossem commits, assim dá pra “continuar” o treino por cima se precisar. Ao mesmo tempo, não precisamos mexer no modelo principal, podemos criar camadas separadas, as chamadas LoRas. Por exemplo, digamos que um modelo esteja com dificuldades de gerar o seu rosto, não importe que prompt use ou que Nodes configure.

Em vez disso podemos usar o “dicionário” do modelo pré-treinado, como Flux ou SDXL e fazer um treinamento com nossas fotos pessoais e gerar um LoRa específico meu. Então podemos adicionar um Node de LoRa no workflow e isso vai resultar em imagens muito melhores com seu rosto em particular.

Existem comunidades online inteiras dedicadas a isso. Um exemplo. No site Civit A.I. vamos encontrar diversos modelos baseados em modelos pré-existentes, como este Mistoon que é baseado no SDXL.

É um checkpoint. Podemos nos cadastrar no site e e baixar o arquivo mistoonAnime_v10Noobai.safetensor e colocar no diretório models/checkpoints.

Agora, em todo workflow que tiver o Node “Load Checkpoint” temos a opção de escolher esse modelo. Mas digamos que esse modelo não esteja conseguindo gerar uma personagem com uniforme colegial como em vários animes. Vasculhando o site, encontramos esta LoRa:

O modelo Mistoon é grande, uns 6.6GB mas essa LoRa - chamada Mistoon_Anime\ school\ uniform.safetensor que devemos mover pra models/loras tem menos de 290 MB, é muito menor porque é um treinamento específico só em imagens de uniformes colegiais.

Agora podemos ligar o Node de “Load Checkpoint” a este outro Node de “Load LoRa” e escolher essa LoRa que sabemos que é compatível:

LoRas tem que ser escolhidas pra usar com os modelos em que elas foram baseadas. Como falei antes, pense no modelo como uma “língua”, se fizermos um LoRa em alemão, não adianta misturar com um modelo chinês, a grosso modo. Mas essa é uma forma de fazer fine-tuning pro modelo que você gosta entregar resultados que nenhum outro consegue.

Um problema que eu tenho com o site Civit A.I. é que só dá pra fazer download quando está logado no site. Por isso não coloquei nenhum modelo ou lora deles no meu script de instalação automática. Infelizmente no caso deles precisa manualmente baixar os arquivos e mover pros diretórios certos, anotar em algum lugar, pra em outra máquina baixar e mover tudo de novo. É um saco que eu ainda não parei pra resolver. Se alguém quiser contribuir uma solução pra isso (sem expor cookies de login de ninguém, mandem Pull Request).

Um Exemplo Real

Seu dia a dia com Comfy, sendo um novato como eu vai ser mais ou menos assim: começa indo no Google e procurando “best workflow image to anime ComfyUI”. Primeiros links costumam ser alguma thread de Reddit:

Sub-Reddits como r/comfyui ou r/StableDiffusion costumam ter novidades e workflows como esse. Daí vamos direto pros primeiros comentários:

Ou isso, ou abrimos o workflow direto no ComfyUI e vasculhamos os Nodes, um a um:

Já temos talvez um problema: o Node veio pré-configurado pra carregar um LoRa chamado “SDXL_aidma-niji_jini.safetensors” mas o link no comentário do Reddit baixa um “SDXL_Niji_V6_DLC_LoRa_V4.safetensors”. Procurando especificamente pelo anterior no Google, eu não acho. Mas parece “seguro” usar esse outro, pelo menos os nomes são muito parecidos, ambos são derivados de SDXL então teoricamente são compatíveis pelo menos. Esta á a página desse modelo no Civit A.I., então tem que baixar manualmente e mandar pro diretório models/loras a mesma coisa pro Checkpoint AniToon no Node acima. Baixa manualmente e move pra models/checkpoints.

Note que nessa página ele explica que esse LoRa foi feito pra funcionar com o modelo SDXL_Niji_V6 e não com o AniToon como o Workflow que baixei sugere no Node de Load Checkpoint. Vale testar com ambos. De qualquer forma, já que estamos no site, vamos baixar o modelo sugerido também:

Arquivo sdxlNijiSeven_sdxlNijiSeven.safetensors de 6.5GB, move pra models/checkpoints, tão entendendo o processo? Baixa, move pro lugar certo, recarrega o workflow no navegador e agora aparece, selecionamos:

Aliás, acho que é intuitivo mas pra quem não entendeu se abriu a interface do ComfyUI:

• botão esquerdo do mouse seleciona Nodes
• botão do meio arrasta a tela
• scroll faz zoom na interface

Agora sim, vamos escolher esses dois pra testar:

Aproveitando essa mesma imagem, note no canto esquerdo um Node de Florence2 que é uma LLM da Microsoft (e meu script de Docker já instala pra você). Não dá pra mostrar todos os Nodes relacionados mas estes são os principais de pra que isso serve:

O ideal em geração de imagem é fazer o prompt mais longo e bem detalhado sobre a imagem original que você conseguir, mas a maioria das pessoas só escreve alguma porcaria como “pessoa sorrindo de pé” e acha que é suficiente. O modelo Florence2 é feito pra ler uma imagem e descrever ela em texto.

Agora tem outro detalhe: muitos checkpoints ou Loras são treinados com alguma palavra-chave de ativação. Assim ela só influencia se você digitar essas palavras no seu prompt. Então esse workflow não precisa digitar prompt manualmente, o Florence2 vai fazer isso e toda vez o texto dele começa como “The image … bla bla bla”, daí temos um Node de “Text Find and Replace” que troca esse “The Image” pelas palavras chaves do Anitoon ou Niji: “aidma-niji, niji”.

Essas são as palavras certas? EU NÃO SEI kkkkk

O workflow já trouxe essas palavras, mas nas páginas do Civit A.I. - onde deveria estar documentado, não está!! Então estamos realmente CHUTANDO que deve ser “niji” já que é o nome do modelo e do lora. Preste atenção na palavra-chave, é importante, senão você adiciona o lora e nada acontece de diferente e é porque faltou isso no prompt!!

Tem mais, tem que checar se os Nodes de coisas como VAE, ControlNet, Canny e tudo mais estão populados com arquivos que temos. Normalmente se usa a mesma meia dúzia e eu já pré-instalei no Docker os principais. Na imagem, veja que ControlNet é o contronet-union-sdxl-1.0-promax.safetensors, compatível com SDXL e estamos usando Niji que é feito em cima de SDXL. Vamos chutando assim.

Também notem que ele usa Zoe Depth Map pra tirar o Mapa de Profundidade e Canny pra tirar o Mapa de Bordas como no outro workflow. Dá pra configurar, nesse workflow note que o Mapa de Bordas pegou alguns artefatos esquisitos no fundo, dá pra ajustar pra tirar isso. Por isso que no exemplo anterior também a imagem final apareceu uma janela, o modelo achou que era uma janela! Mas por enquanto deixa assim mesmo.

Agora podemos rodar:

Tem um botão enorme “RUN” em azul lá embaixo. Se estiver tudo configurado certo, você vai ver que um trabalho foi colocado na fila. A interface é inteligente o suficiente pra deixar você trabalhar em outros workflow e só ir enfileirando trabalhos enquanto a GPU sua processando. Não precisa ficar esperando, só deixar vários enfileirados e ir dormir.

Ao rodar, na interface os Nodes que estão processando neste momento vão ficar com uma borda verde, o que é bom pra você saber em que etapa do processo ele está. E se algum Node tiver erro - porque faltou arquivo, por exemplo - ele vai ficar com borda vermelha, daí precisa corrigir e rodar de novo.

E no final, eis um dos resultados:

Note como os mapas da controlnet garantiram a pose correta. O modelo deduziu aqueles artefatos de fundo do mapa de borda como iluminação de alguma janela, mas na foto original vemos que é tipo o tijolo de concreto da parede kkkk mas é isso, sem saber, ele chuta. E se rodar várias vezes, sempre vai dar um resultado bem diferente. Olha outro:

Nada a ver kkkk Mas podemos trocar o modelo SDXL-Niji pelo Anitoon. Vamos ver um dos resultados:

Trocando pro modelo waiNSFIllustrious:

Esse ficou ainda mais nada a ver. Alguma coisa nos mapas está fazendo o modelo assumir que eu tenho cabelo cacheado, sei lá porque. Mas é isso: tem que ajustar os parâmetros. O resultado do workflow que mostrei no começo do artigo deu um resultado melhor, usando os mesmos modelos.

De todos os Nodes, um dos mais importante é o “motor” do processo, o KSampler:

Esse é o cara que comanda o show. Damos pra ele o modelo, o prompt, saídas de control-net e ele quem vai iterativamente (steps) fazer o “desnoise” do Latente. Note que sempre existe um fator aleatório (“seed”), quantidade de passos (25 a 50 é a média), “cfg” (classifier-free guidance) ou “guidance_scale”, onde valores maiores puxam a imagem mais seu prompt positivo. Denoise é quando de noise o scheduler aplica (1.0 é noise completo, abaixo de 1.0 pode produzir resultados mais “artísticos”, tem que testar).

Sampler Name é um saco porque precisaria entender a matemática por trás, mas são os algoritmos de steps, por exemplo euler, ddim, plms e cada um tem um trade-off entre velocidade e fidelidade. Na prática: teste um a um e veja os resultados. Scheduler tem normal, klms, dpmsolver. Mesma coisa: teste um a um.

Como podem ver, tem BASTANTE parâmetros que dá pra brincar. Mas o fluxo principal é mais ou menos esse. Daí tem que ir aprendendo Node a Node o que cada um pode fazer e baixar bastante workflow pré-pronto pra ver como o pessoal tem solucionado diversos problema, quais os modelos e loras mais populares pra cada tipo de aplicação. Enfim, o Reddit é seu amigo. Espero que tenha dado pra dar um Norte, eu também ainda estou aprendendo.

Mais de ano atrás, quando fiz meus últimos videos sobre I.A. e nos podcasts eu sempre falava que rodava tudo na minha máquina. Mas nunca detahei como. Então hoje consertei isso com vários posts de blog e projetinhos no GitHub com Dockerfiles pra você mesmo rodar na sua própria máquina, sem configurar nada difícil.

Finalmente fiz um Dockerfile pra ComfyUI, que é a melhor interface gráfica pra edição de workflows de geração de imagens. Se você já trabalhou com Davinci Resolve Fusion ou Blender Geometry Nodes da vida, workflows são basicamente configurações de nós pra processar suas imagens, áudio, video e ir passando por processamentos não só de I.A.. É como programar visualmente. Por isso é uma ferramenta muito mais complicada do que o FramePack que mostrei no post anterior. Não é só clicar.

Recentemente todo mundo ficou histérico com as atualizações do ChatGPT e como ele “OH MY GOD” consegue gerar imagens em estilo de anime da Ghibli e ficaram spammando o mundo com memes idiotas em estilo anime. Histeria online é um saco mesmo. Mas como eu falei, por mais impressionante que seja, é isso: um gerador de memes. Não dá pra usar profissionalmente.

Cansei de tentar subir fotos minhas ou até fotos genéricas, de personagens fictícios, alguns até desenhos meus, e vira e mexe, aleatoriamente, o ChatGPT se recusa a gerar a imagem. Alegando privacidade, segurança, copyright e tudo mais que ele conseguir inventar de desculpa. Não dá pra confiar nisso pra trabalhar. Quem é profissional deveria ter controle completo sobre o processo e é isso que vou ensinar hoje.

Pra começar, clone meu repositório no GitHub e siga as instruções do README ou faça isto:

git clone https://github.com/akitaonrails/ComfyUI-Docker-CUDA-preloaded.git
cd ComfyUI-Docker-CUDA-preloaded
docker compose build

Sendo mais complexo, precisei colocar um Docker Compose desta vez. Então pra subir, depois do build finalizar, só fazer isso:

docker compose up

Agora vai demorar, porque por padrão ele vai baixar quase 500GB de modelos pré-treinados pra conseguir fazer quase tudo de imagens. Sim, pra brincar com I.A. localmente precisa ter infra. Ou se não, alugar máquina parruda com muito armazenamento numa RunPod da vida e rodar remoto. Tem como baixar menos modelos, vou explicar a seguir.

No Docker Compose. Recomendo evitar a opção “-d” de subir como daemon, porque é bom reservar um terminal pra ficar vendo os outputs (você pode dar docker compose logs --follow, se quiser também, mas é mais fácil direto).

O ComfyUI é um programa mais complexo que a média, muito mais que um FramePack da vida. Ele tem suporte a instalar “extensions” (plugins, addons, chame como quiser). E na verdade ele sozinho não faz muita coisa, precisa instalar várias extensions pra começar a ficar realmente útil. Vira e mexe alguma dessas extensions não trata erros direito e estoura no console, algo como isso:

É útil sempre ficar de olho no console pra descobrir se ele tentou carregar um arquivo que não existe. Daí dá pra pegar o nome do arquivo e buscar no Google, baixar e colocar no lugar certo. Ou se é uma extension muito bugada que é melhor tirar do diretório “custom_nodes”, e assim por diante. Sem ver o console, não aparece na interface web e você vai ficar a ver navios.

Muito dos modelos e extensions eu me baseei na configuraçãol Ultimate ComfyUI versão 3 recomendada pelo Aitrepreneur, de novo. Assista este video dele pra ter todos os detalhes e tudo que é possível fazer. Ele tem os scripts pra Linux, Windows, e os workflow na versão paga do Patreon dele e, claro, não vou compartilhar os workflows porque não são meus. Em teoria, minha config deve ser capaz de fazer o que ele ensina.

O workflow V3 do Aitrepreneur é muito ph0da. Mas eu não posso compartilhar porque é material fechado no Patreon dele, mas eis uma foto de tela do meu ComfyUI com tudo dele carregado:

Mas a config em si, eu refiz inteira pra funcionar neste Docker. Dá pra carregar qualquer outro workflow aberto que achar num Reddit da vida.

O que eu fiz foi o seguinte:

Models

No projeto tem que ter um diretório “models”, se não tiver crie, porque o docker compose vai mapear pra dentro do container. Quando iniciar, ele vai rodar o arquivo init_models.sh. Esse script vai carregar um arquivo de configuração que você pode editar depois: models.conf. Ele é enorme e um pedaço dele é assim:

...
[CONTROLNET]
https://huggingface.co/XLabs-AI/flux-controlnet-collections/resolve/main/flux-canny-controlnet-v3.safetensors
https://huggingface.co/XLabs-AI/flux-controlnet-collections/resolve/main/flux-depth-controlnet-v3.safetensors
https://huggingface.co/brad-twinkl/controlnet-union-sdxl-1.0-promax/resolve/main/diffusion_pytorch_model.safetensors|controlnet-union-sdxl-1.0-promax.safetensors
https://huggingface.co/lllyasviel/ControlNet-v1-1/resolve/main/control_v11p_sd15_canny.pth
https://huggingface.co/lllyasviel/ControlNet-v1-1/resolve/main/control_v11f1p_sd15_depth.pth
https://huggingface.co/lllyasviel/ControlNet-v1-1/resolve/main/control_v11p_sd15_openpose.pth
https://huggingface.co/Aitrepreneur/FLX/resolve/main/Shakker-LabsFLUX1-dev-ControlNet-Union-Pro.safetensors

[STYLE_MODELS]
https://huggingface.co/Aitrepreneur/FLX/resolve/main/flux1-redux-dev.safetensors

[SAMS]
https://huggingface.co/Aitrepreneur/FLX/resolve/main/sam_vit_b_01ec64.pth

Cada seção mapeia pra um sub-diretório, então “[SAMS]” vai mapear pra “models/sams” e baixar os binários nos lugares certos. Tem alguns especiais nas seções “[GIT_REPOS]”, para os que podem ser clonados via git ou “[CUSTOM]” pra arquivos que precisa baixar depois dentro desses projetos clonados, por exemplo. Não sei ainda se dá pra simplificar, mas isso eu peguei na config do Aitrepreneur.

O ideal é sempre manter essa lista organizada com modelos que acharem depois. Se quiserem contribuir também seria bacana. O motivo é que fica tudo espalhado em tudo que é site por aí, você baixa manualmente, daí move pro diretório dentro de “models”. Amanhã, se reinstalar sua máquina, e pra lembrar todos os sites? São dezenas de modelos disponíveis.

No outro post vou tentar resumir o que diabos são “checkpoints”, “diffusion models”, “loras”, “controlnet” e tudo mais. Mas por enquanto, a extensão dos arquivos não diz muita coisa. Dizer “.pt” por exemplo só quer dizer que é um arquivo que o PyTorch consegue abrir, mas não diz se é um clip ou um text encoder, por exemplo. Extensão “.safetensors” mesma coisa, pode ser qualquer coisa, e o ComfyUI precisa que cada arquivo esteja no sub-diretório correto pra conseguir usar depois, não pode sair movendo arquivo aleatoriamente.

O script “init_models.sh” roda toda vez que o Docker é reiniciado e é inteligente pra só baixar URLs que já não estão baixadas no diretório “models”. Por isso sempre roda quando o container sobe, no entrypoint. Essa é uma das vantagens da minha config: ela é tem manutenção automática.

Extensions e Dependências

Eu fiz um segundo script chamado init_extensions.sh, que também roda no entrypoint do container e você não deve mexer, mas ele carrega um outro arquivo de configuração chamado extensions.conf e, esse sim, você pode mexer e adicionar novas extensions depois. Um pedaço dele é assim:

[EXTENSIONS]
https://github.com/ltdrdata/ComfyUI-Manager.git
https://codeberg.org/Gourieff/comfyui-reactor-node.git
https://github.com/ssitu/ComfyUI_UltimateSDUpscale.git
https://github.com/kijai/ComfyUI-LivePortraitKJ.git
https://github.com/PowerHouseMan/ComfyUI-AdvancedLivePortrait.git
...

Aqui eu declaro todas as extensions que adicionam novas funcionalidades em cima do ComfyUI, em particular novos NODES, por isso ficam no diretório “custom_nodes”, que é um volume externo ao Docker e por isso é persistente, ou seja, toda nova extension sobrevive restarts do container.

Mas tem ainda um porém GRANDE: Dependências de Python. Um pesadelo.

A build da Imagem Docker faz um monte de pip install e como estou usando Virtual ENV, vai tudo instalado em /venv dentro do container, como deveria.

Porém, as extensions que são instaladas fora da build - toda vez que o container reinicia - costumam ser código Python e também tem mais dependências. Extensions são projetos no GitHub e podem estar mudando neste exato momento. Se mudar e fizer um git pull pra atualizar, precisa rodar o pip install -r requirements.txt. Mas se tiver dezenas de extensions, rodar pip install, de cada um, em cada restart do Docker é uma demora grande pra não fazer quase nada. Como eu disse, pesadelo.

Minha solução - pra me gabar um pouco - conserta boa parte dessa manutenção. Quando o script init_extensions.sh executa, se uma extension da lista já estiver instalada, ele vai pular. Daí vai gravar no diretório ./custom_nodes/.last_commit/*.commit o último commit de cada extension. Quando o Docker reiniciar, ele vai dar um git fetch e checar se o hash do último commit mudou.

Só se mudou, ele vai rodar pip install pra essa extension que ganhou atualização e pular todas as outras que não mudaram desde o último restart, economizando MUITO tempo e evitando que você precisa manualmente atualizar as coisas. Como estou usando VENV, vai ficar tudo persistido no volume “/venv”. Sim, é um VOLUME, porque ela muda depois do build a cada atualização de extension.

Dessa forma, tudo que tem na imagem vai ser copiada nesse volume, e tudo que as extensions instalarem por fora, também vai pra dentro desse volume. Toda vez que reiniciar, volta tudo como estava antes. Foi a solução que encontrei e até agora parece funcionar direitinho.

Mas é só questão de tempo pra alguma extension mal feita instalar dependências que quebrem outras dependências, ou um caso real que eu passei: tinha uma extension que crasheia sem mensagem de erro se estiver usando Python 3.11, o Zoe Depth Map da extension comfyui_controlnet_aux, um dos pacotes que parece que são populares.

Eu não tinha me dado conta que comecei usando uma image base de Docker de ubuntu22 em vez de ubuntu24, eu estava com medo de usar algo novo demais e quebrar, mas acabei usando velha demais e quebrou do mesmo jeito. Gerenciar versionamento é um saco. Enfim, mudei o Dockerfile pra ubuntu24.

Mas no volume externo do VENV agora sobrou um monte de dependências que se limitavam ao Python 3.11. Não tem problema, basta apagar o volume:

docker compose down # garantir que está parado
docker volume rm comfyui-venv
rm ./custom_nodes/.last_commits/*.commit

E pronto, o VENV vai reiniciar vazio, preencher com as dependências corretas de Python 3.12 da imagem e ao iniciar o container meu script init_extensions.sh não vai achar o “.last_commits” e vai forçar um pip install -r requirements.txt de todas as extensions, agora com Python 3.12. Super limpo e confiável.

Se mesmo assim tiver erro, aí pode ser bug numa extension em especial, só vá até o diretório dele em “./custom_nodes” e apague manualmente antes de reiniciar o container.

Acho que isso é o menos complicado que dá pra fazer nesse caso. Esse docker não foi feito pra rodar sozinho num servidor, é pra rodar na sua própria máquina local, onde você está monitorando o output do terminal mesmo.

Ah sim, se sair versão nova do ComfyUI aí tem que re-buildar a imagem e apagar o volume de VENV. A imagem é estática, não esqueçam. Dentro o Dockerfile faz um novo git clone e pega o commit mais novo. Daí vai instalar pacotes python mais novos, então precisa zerar o volume da VENV e fazer as extensions re-instalarem suas dependências depois também. É um enorme saco, mas é assim mesmo que funciona.

Conclusão

Feito tudo isso, com um simples docker compose up consigo ter um ambiente de ComfyUI estável e isolado do resto do meu sistema, sem sujar nada com milhares de dependências duvidosas. Quando terminar só fazer docker compose down ou “ctrl-c” no console dele e pronto, meu sistema continua limpo.

Além disso, diretórios como “models” e seus 500GB de modelos ficam separados, dá pra fazer backup pra outro lugar se precisar. E se quiser subir em outra máquina, basta levar somente esses diretórios e subir Docker Compose lá e tem que subir igualzinho, zero-setup. Esse foi meu objetivo ao Dockerzar ComfyUI, FramePack, Video2K, ter tudo portátil, isolado e limpo pra subir em qualquer máquina depois sem precisar ficar rodando scripts duvidosos de instalação direto na minha máquina.

No meu X eu já mostrei meu ComfyUI funcionando. Carreguei um workflow qualquer que achei na Web e olha só:

Nesse workflow eu subo uma imagem de referência e posso escrever um prompt de como quero transformar ela:

Com ComfyUI eu tenho controle sobre todas as etapas do processo, por exemplo, esse workflow consegue separar coisas como Mapa de Profundidade e Contorno de Bordas da imagem original, pra usar de contexto antes de fazer a imagem final, garantindo um resultado muito mais preciso:

E eis um resultado que já consegui usando o modelo “waiNSFIllustrious” que esse workflow sugere, que é um modelo treinado pra gerar imagens estilo anime (tem dezenas, pra vários estilos diferentes).

Mudando o modelo pra Mistoon, baseado em Stable Diffusion (SDXL), eis outro resultado, com o mesmo prompt, no mesmo workflow:

E posso ficar tunando dezenas de parâmetros dentro desse workflow, trocar vaes, text encodes, controlnets e muito mais até conseguir exatamente o resultado que eu quiser. Esse é o poder do ComfyUI e seus Custom Nodes e Workflows. É o que vou tentar explicar o básico no próximo post.

Já que estava no embalo de empacotar esse tipo de ferramenta em Docker, resolvi fazer mais um projetinho com um Dockerfile pra rodar no meu Manjaro Linux com RTX 4090. O bom do Aitrepreneur é que ele tem um Patreon que você pode assinar pra contribuir (é barato) e ele sempre sobe scripts pra rodar no RunPod caso você não tenha uma máquina parruda ou GPU, ou script .BAT pra rodar no seu Windows.

Meu projetinho está neste GitHub e pra usar é muito simples:

git clone https://github.com/akitaonrails/FramePack-Docker-CUDA.git
cd FramePack-Docker-CUDA
mkdir outputs
mkdir hf_download

# Build the image
docker build -t framepack-torch26-cu124:latest .

# Run mapping the directories outside:
docker run -it --rm --gpus all -p 7860:7860 \
  -v ./outputs:/app/outputs \
  -v ./hf_download:/app/hf_download \
  framepack-torch26-cu124:latest

Isso vai construir a imagem de Docker e rodar. E na primeira vez dá pra ver que ele vai baixar uma TONELADA de models, o HunyuanVideo, Flux e mais. Se prepara pra mais de 30GB. Mas é só na primeira vez porque eu mapeio o diretório de download pra fora, então se reiniciar o container ele já vai ter na próxima vez.

Quando terminar, é só acessar http://localhost:7860 e vai ver esta interface super simples:

Os controles são muito simples:

• Desabilite a opção “Use TeaCache” que deixa mais rápido mas aí você arrisca a ter aqueles defeitos de I.A. como mão com mais dedos e coisas assim.
• Total do Video pode ser até 2 minutos, mas só faça isso se realmente tiver paciência porque demora BASTANTE! Acho melhor começar mesmo testando com videos curtos de 5 a 10 segundos primeiro.
• Se sua GPU tiver pouca VRAM vai ser obrigado a mexer em “GPU Inference Preserved Memory (GB) (larger means slower)”. No meu caso que tenho 24GB de VRAM deixei como está, mas olha só rodando como ele consome:

Sim! 100% da GPU e quase 100% da VRAM, puxando mais de 350W da parede! (foda-se meio ambiente! kkkkk) A CPU até fica de boa, porque esse processo é feito pra realmente MASSACRAR a GPU. Se não tiver GPU boa, alugue uma máquina na RunPod como falei antes.

O video de 10 segundos no começo do post é uma foto da uma das action figures que eu mais gosto na minha coleção, o Link de Breath of the Wild. E isso é uma coisa que me deixou empolgado. Esta é a foto original que serviu de base pro FramePack fazer o video:

Fazer video de fotos de pessoas é sem graça e tedioso, mas agora que estou aprendendo a modelar 3D pra imprimir na minha Bambulab, imagina depois ainda conseguir fazer ele ficar animado?

Pra animar no Blender e renderizar, também é bastante processamento e demora. Mas com isso eu consigo rapidamente prototipar uma animação e ver como fica, pra ver se vale a pena fazer uma versão melhor no Blender depois. Abre muitas possibildades de experimentação!

Por mais impressionante que isso pareça, ele não faz QUALQUER COISA, tive várias experimentações que deram errado e a movimentação que ele faz é bem limitada, afinal ele só tem uma foto pra usar de referência e não tem dá pra fazer movimentos bruscos demais, tem limites. Mesmo assim é bem divertido de brincar. O fato dele conseguir identificar mais que seres humanos é um grande “plus” na minha opinião, porque é onde eu me interessei mais.

AH SIM! Lembram o outro blog post que publiquei hoje sobre fazer UPSCALE PRA 4K?? Dá pra usar aqui também, pegue um video que o FramePack gerou e você gostou muito e faça upscale pra 4K pra ter mais definição ainda! Aí fica em qualidade pra até usar em edição de videos.

Videos de 2 minutos deve levar horas pra fazer. 30 segundos levou quase 1 hora. Melhor coisa é ficar em videos de 5 segundos pra brincar e experimentar, só isso já leva aí quase meia hora. Aqui vão mais alguns exemplos tirados de fotos de itens da minha coleção (aqueles que vocês viam no fundo dos meus videos). Divirtam-se!

Este é um Ultraseven de mais de 30cm de altura que eu encontrei e trouxe direto de um sebo de Tóquio ano passado, um dos que eu mais gosto especialmente porque assisti muito no começo dos anos 80 quando eu era criança.

Falando em nostalgia, esse é outro item da hora da minha coleção, um Jiraya super detalhado feito pela Iron Studios. E animado até que ficou bem da hora. O que acharam?

Mas agora o meu FAVORITO, quem me acompanha no Instagram viu que faz algumas semanas que venho me dedicando a melhorar minhas técnicas de 3D e também de desenho e eu fiz um conceito de Mandaloriam + Judge Dredd:

.png?disposition=attachment&locale=en)

Depois vejam os outros desenhos no meu Instagram, mas enfim, eu precisava saber se o FramePack era capaz de animar também desenhos e SIM, ELE CONSEGUE!! OLHA QUE PH0DA!!! Esse me deixou impressionado, dá uma nova dimensão nas minhas coisas!

Sim, tudo isso é bem pesado, mas a vantagem é que eu posso experimentar INFINITAMENTE, porque tudo roda local. Num produto comercial de alguém no “cloud”, eu precisaria pagar alguma assinatura e ele ia me limitar, seria impossível ficar experimentando quando eu quisesse. Agora eu posso fazer tudo que eu quiser, quando eu quiser, como eu quiser, sem que ninguém nem nada possa encher meu s@co.

Aliás, se puderem assistam esse clip do “Boba Dredd” em tela cheia num monitor grande. Notaram que tá bem nítido? É porque eu passei no Video2K e fiz upscale pra 4x a resolução que o FramePack me deu. Juntando essas ferramentas dá pra fazer coisas BEM interessantes, depois me falem se conseguiram usar e o que fizeram de legal!

Pra quem coleciona, o problema é que muito anime dos anos 90 pra trás nunca saíram e nem nunca vão sair em Blu-Ray (1080p) nem UHD (4K). Só os mais famosos recebem tratamento de “remaster” (pegar as fitas master originais e recapturar em mais resolução). Então muito anime velho está preso na era de DVD (480p) ou VHS (480i).

Nem todo anime velho dá pra aumentar resolução, pode ficar “lavado” demais. Quem baixa torrent já deve ter visto upscalings mal feitos. Mas eu queria poder testar isso eu mesmo, na minha máquina local, com meus arquivos velhos. Eis um pequeno clip de exemplo:

É um pedaço do 1o episódio do lendário Rurouni Kenshin de 1996. Sim, hoje temos um remake, que estão refazendo do zero. Mas pra quem tem nostalgia pelo original, não tem substituição. A qualidade de DVD não está horrenda, dá pra assistir de boa ainda hoje assim mesmo. Mas fico curioso pra ver como fica em 4K.

Não fiz nenhuma pesquisa longa, mas um ano atrás eu tinha esbarrado no Real ERSGAN. Esse projeto está descontinuado faz uns 4 anos, então não sei o que é o mais moderno hoje. Mas os modelos pré-treinados deles ainda são úteis.

Ainda tem projetos que usam esse modelo, o que eu conheço é o Video2K Em Windows parece que tem até uma interface gráfica bonitinha, mas a vantagem pra Linux é que ele roda em Docker. Um exemplo seria assim:

docker run --rm --gpus all \
  -v "$PWD/videos_in":/input \
  -v "$PWD/videos_out":/output \
  ghcr.io/k4yt3x/video2x:6.4.0 \
  -i /input/old_anime.mp4 -o /output/old_anime_4K.mkv \
  -p realesrgan -s 4 --realesrgan-model realesr-animevideov3

Se tiver com sua NVIDIA configurada com o Container Toolkit, Cuda e tudo mais (pergunte ao ChatGPT), o Docker consegue mapear o dispositivo direto pra dentro do container. Isso facilita muito não deixar meu Linux sujo cheio de dependências e configuraçõe soltas por aí. Não faço mais nada desse tipo fora de containers.

Mas eu esbarrei com um problema. Se você estiver usando GPU AMD, só assim já deve funcionar, porque essa imagem Docker na verdade usa Vulkan e não CUDA. No meu caso eu tenho uma GPU integrada AMD primária e uma NVIDIA RTX 4090 secundária. Eu tentei passar direto:

❯ docker run --gpus all --privileged \
  --device=/dev/nvidia0 \
  --device=/dev/nvidiactl \
  --device=/dev/nvidia-uvm \
  --device=/dev/nvidia-modeset \
  --runtime=nvidia \
  -e VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json \
  -e VK_LAYER_PATH=/usr/share/vulkan/explicit_layer.d \
  -v "$HOME/Downloads/Video2K/videos_in":/input \
  -v "$HOME/Downloads/Video2K/videos_out":/output \
  --rm -it \
  ghcr.io/k4yt3x/video2x:6.4.0 \
  -i "/input/(B-A)Rurouni_Kenshin_-_01_(A5D3CB57).mkv" \
  -o "/output/(B-A)Rurouni_Kenshin_-_01_(A5D3CB57)_upscaled.mkv" \
  -p realesrgan -s 4 --realesrgan-model realesr-animevideov3

Mas não vai de jeito nenhum. Se eu só disser “–gpus all” ele vai pegar a iGPU por padrão. Fazer o upscaling de um video acaba consumindo 100% da minha CPU, todas as 32 threads, mas minha GPU NVIDIA fica parada olhando sem fazer nada. Se eu tentar passar “/dev/dri/card0” ou “/dev/nvidia0”, ele dá erro e não consegue começar.

Então a partir daqui a solução é só pra quem tem NVIDIA:

Dockerfile CUDA

Desta vez resolvi não ser preguiçoso e organizar tudo no projetinho no Github. Clone direto de lá Batch Anime Upscaler Video2K Docker CUDA Só fazer assim:

git clone git@github.com:akitaonrails/Batch-Anime-Upscaler-Video2K-Docker-CUDA.git
cd Batch-Anime-Upscaler-Video2K-Docker-CUDA
mkdir input # coloque seus videos velhos aqui
mkdir output

docker build --build-arg HOST_UID=$(id -u) --build-arg HOST_GID=$(id -g) -t anime-upscaler:latest .

Se nada der errado, isso vai construir uma imagem de Docker com tudo que você precisa, daí é colocar seus videos no subdiretório que falei, ou outro que quiser e configurar no comando pra rodar:

 docker run --gpus all --rm \
  -v "./input":/input \
  -v "./output":/output \
  -e HOST_UID=$(id -u) -e HOST_GID=$(id -g) \
  anime-upscaler:latest

E é só isso. Demora bastante. Com meu Ryzen 7950X3D mais RTX 4090, ele processa a uma taxa de uns 13 frames por segundo. Então menos da metade da velocidade de playback. Se um video tiver 20 min, vai levar mais de 40 minutos pra processar cada um. É bom reservar um bom tempo, e por isso também é bom só pra videos que você realmente queira assistir.

O script original do Video2K suporta vários parâmetros, que eu deixei expostos como variáveis de ambiente no Dockerfile:

MODEL="${MODEL:-realesr-animevideov3}"
SCALE="${SCALE:-4}"
TILE="${TILE:-0}"
DENOISE="${DENOISE:-1.0}"
NUM_PROC="${NUM_PROC:-1}"

Daí dá pra mudar mexendo assim:

docker run --gpus all --rm \
  -e DENOISE=0.5 \
  -v ... \
  anime-upscaler:latest

Como podem ver, por padrão usamos o modelo pré-treinado “realesr-animevideov3” que é menos detalhado que o modelo de 6 bilhões de parâmetro mas é bem mais estável entre frames, que é mais importante pra um video. A maioria dos outros modelos que ele suporta, como “RealESRGAN_x4plus” ou “ESRGAN_x4” servem pra fotos e imagens mas não pra video. Video exige coerência temporal, que é bem difícil.

No máximo vale testar o modelo “realesr-general-x4v3” que dizem ser um pouco mais leve, caso sua máquina esteja capengando muito pra rodar o padrão. Mas aí vai ter que modificar o Dockerfile pra fazer download desse modelo e re-buildar:

# === OPTIONAL: Preload additional Real-ESRGAN models ===
# Uncomment any models you want available in the container at build time

# Anime 6-block model (better for anime stills, line art)
# RUN wget -q https://github.com/xinntao/Real-ESRGAN/releases/download/v0.2.5.0/RealESRGAN_x4plus_anime_6B.pth \
#     -O /opt/Real-ESRGAN/weights/RealESRGAN_x4plus_anime_6B.pth

# Original RealESRGAN 4x general-purpose model
# RUN wget -q https://github.com/xinntao/Real-ESRGAN/releases/download/v0.2.5.0/RealESRGAN_x4plus.pth \
#     -O /opt/Real-ESRGAN/weights/RealESRGAN_x4plus.pth

# RealESRGAN 2x model (lighter upscale)
# RUN wget -q https://github.com/xinntao/Real-ESRGAN/releases/download/v0.2.5.0/RealESRGAN_x2plus.pth \
#     -O /opt/Real-ESRGAN/weights/RealESRGAN_x2plus.pth

# ESRNet (non-GAN model, ultra-smooth)
# RUN wget -q https://github.com/xinntao/Real-ESRGAN/releases/download/v0.2.5.0/RealESRNet_x4plus.pth \
#     -O /opt/Real-ESRGAN/weights/RealESRNet_x4plus.pth

# General-purpose lightweight video-friendly model (with denoise control)
# RUN wget -q https://github.com/xinntao/Real-ESRGAN/releases/download/v0.3.0/realesr-general-x4v3.pth \
#     -O /opt/Real-ESRGAN/weights/realesr-general-x4v3.pth

# Anime video model (default in your setup)
# RUN wget -q https://github.com/xinntao/Real-ESRGAN/releases/download/v0.2.5.0/realesr-animevideov3.pth \
#     -O /opt/Real-ESRGAN/weights/realesr-animevideov3.pth

# Original ESRGAN (2018) model
# RUN wget -q https://github.com/xinntao/Real-ESRGAN/releases/download/v0.2.5.0/ESRGAN_x4.pth \
#     -O /opt/Real-ESRGAN/weights/ESRGAN_x4.pth

Eu não testei todos, mas pra quem quiser, acho que esses são os links. Mude no Dockerfile, faça o build, mude a variável MODEL e teste nos seus videos.

O que vale mexer são coisas como DENOISE, que está pra “1.0” que é máximo, mas isso pode deixar a imagem “esticada” demais. Vale testar valores menores, como “0.5”. Varia de caso a caso, só testando.

Outro fator é a escala, SCALE, que o default é “4x”, que transforma 1080p em 4K ou 720p em 1440p. Mas às vezes não precisa subir tanto, e nem adianta porque a imagem original já tem muito pouco detalhe mesmo. Talvez só 2x seja suficiente. O script suporta 2x, 3x, 4x mas tem teto na resoluçãod e 4K, então não adianta tentar transformar video que já é 4K em 8K por exemplo.

Minha RTX 4090 e meu Ryzen 9 são bem potentes. Processando só um video eu não vejo ele suando nem um pouco:

Claramente daria pra rodar mais videos em paralelo. Tem que tomar cuidado quando é desbalanceado. Se a CPU subir pra perto de 100% pra separar os frames, não adianta estar sobrando na GPU. Os dois tendo sobra, dá pra fazer o script subir mais de 1 processo na GPU e mandar frames em paralelo com a opção “-e NUM_PROC=2”. Olha como agora ele já usa mais da GPU e a CPU ainda tá sobrando. Talvez 3 seja o máximo, mas tem que testar, não é constante o tempo todo.

Isso pode diminuir o tempo total dramaticamente. Você pode escolher entre aumentar os processo na GPU pelo script ou ter dois diretórios separados de video e subir dois containers paralelos desse programa pra rodar ao mesmo tempo, o que funcionar melhor pra você.

Resultado Final

Vamos ver como ficou aquele primeiro clip com upscale 4x e denoise 1.0:

Dá uma diferença ENORME, mas se ficou “BOM” vai ser BEM subjetivo. Eu particularmente não achava o original ruim de assistir. Talvez se mexer no DENOISE pra um pouco menos ou SCALE pra 2x em vez de 4x já fique bom, não sei.

Pra comparar, eis outro clip na versão original antiga:

E de novo, como fica depois do upscale 4x:

Pelo menos está funcionando como deveria, a partir daqui é fazer algum tuning. Se alguém tiver mais dicas ou conhecer modelos ou projetos mais novos de upscaling open source, mande nos comentários abaixo!

Antes que alguém pergunte, porque não usar DLSS 3 da NVIDIA, que eles usam pra aumentar resolução de games? Resposta: porque eles não expõe essa funcionalidade como uma API que dá pra acessar, é só pros drivers proprietários deles em profile de jogo. Eles ligam e tunam caso a caso. Não tem API geral na lib CUDA.

Update pós-publicação

Resolvi testar o modelo RealERSGAN_x4plus_anime_6B, que é bem mais pesado que o realesr-animevideov3 que subi no repositório.

Mude o Dockerfile e adicione isto depois do wget do outro modelo:

RUN wget -q https://github.com/xinntao/Real-ESRGAN/releases/download/v0.2.2.4/RealESRGAN_x4plus_anime_6B.pth \
     -O /opt/Real-ESRGAN/weights/RealESRGAN_x4plus_anime_6B.pth

Esse modelo não tem como rodar em paralelo nem na minha RTX 4090, que fica constantemente em 100%. Se antes ia a uns 13 frames por segundo, com esse vai só a 3 frames por segundo. É 4x mais pesado e somente pra GPUs realmente parrudas. Se não tiver algo assim, fique na “realesr-animevideov3” mesmo ou no mais leve ainda (menos qualidade) “realesr-general-x4v3”. Esses modelos dependem muito da potência da GPU e principalmente, quantidade de VRAM.

Pra rodar adicione “-e MODEL=RealESRGAN_x4plus_anime_6B” no comando “docker run”.

Veja como ficou o mesmo clip de antes usando este modelo:

Pra ter gasto 4x mais recursos da minha máquina pra processar, o resultado final eu não achei que ficou tão diferente, e em algumas partes eu acho que ficou mais defeitos até. Então é isso, o resultado vai variar, tem que testar. Depende muito da qualidade do anime original, mas não é porque existe um modelo maior e teoricamente “melhor” que todo resultado vai ficar melhor.

Saí fuçando GitHub e tem uma página Awesome Image Colorization com vários papers de pesquisa. Muito útil pra quem for pesquisador mas totalmente inútil pra mim que não vou fazer um do zero kkkk. Tinha links pra alguns projetos como ChromaGAN, mas que está descontinuado faz uns 5 anos. E vários outros projetos que eu vi foram descontinuados lá atrás mesmo, não sei porque tem tão pouco open source ainda atualizado.

Mas felizmente esbarrei em um promissor: DDColor.

Bora clonar o repositório. E pra continuar, prefiro fazer tudo dentro de Docker. Ficar baixando dependência de python sempre zoa meu sistema e deixa um monte de lixo pra trás, então melhor coisa é isolar tudo. Outra coisa, precisa baixar os binários dos modelos pré-treinados. Só pra isso vou usar um pouco de Python por causa da lib “modelscope” que faz isso:

git clone https://github.com/piddnad/DDColor.git
cd DDColor

mkdir modelscope

# criar um novo venv dentro do projeto DDColor
python -m venv venv

venv/bin/pip3 install modelscope

venv/bin/python3 -c "from modelscope.hub.snapshot_download import snapshot_download; snapshot_download('damo/cv_ddcolor_image-colorization', cache_dir='./modelscope')"

Boa prática de Python acho que é fazer tudo dentro de uma VENV né? Enfim, isso deve baixar o binário do modelo, que pesa quase 900MB. Não é grande.

Agora precisamos de um Dockerfile:

# Use NVIDIA CUDA base image with cuDNN 8 and Python support
FROM nvidia/cuda:11.8.0-cudnn8-runtime-ubuntu22.04

# Install Python and system dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
    python3 python3-pip git libgl1 libglib2.0-0 && \
    apt-get clean && rm -rf /var/lib/apt/lists/*

# Set working directory
WORKDIR /app

# Copy DDColor source code into the image
COPY . /app

# Install PyTorch (CUDA 11.8 compatible) and matching torchvision/torchaudio
RUN pip3 install torch==2.2.0 torchvision==0.17.0 torchaudio==2.2.0 \
    --index-url https://download.pytorch.org/whl/cu118

# Install Python dependencies, skipping dlib (not needed for inference)
RUN sed '/dlib/d' requirements.txt > temp-req.txt && pip3 install -r temp-req.txt && rm temp-req.txt

# Optional: install modelscope if you want to run snapshot_download manually inside the container
RUN pip3 install modelscope

Preguiça de abrir um pull request pra isso, se alguém quiser, mande lá.

Agora precisamos colocar uma imagem preto e branco em algum lugar:

mkdir input
mkdir results
mv ~/Downloads/bw.jpg input/

Como as fotos da minha namorada são familiares e particulares, obviamente não vou compartilhar, então peguei uma aleatória qualquer no Google Images:

Agora colocamos em “./input” e rodamos o Docker com este comando:

docker run --rm --gpus all \
  -v "$PWD/input":/workspace/input_images:ro \
  -v "$PWD/results":/workspace/results:rw \
  -v "$PWD/modelscope":/app/modelscope:ro \
  ddcolor:latest \
  python3 infer.py \
    --model_path /app/modelscope/damo/cv_ddcolor_image-colorization/pytorch_model.pt \
    --input /workspace/input_images \
    --output /workspace/results

Preste atenção no mapeamento de diretórios. E note a opção “–gpus” que só funciona no meu caso porque eu tenho uma RTX 4090 instalada aqui. Não tenho a mínima idéia se é a mesma coisa com AMD, mas como a imagem é baseada em cnDNN/CUDA, acho que não. Pergunte ao ChatGPT.

Se estiver tudo certo e rodar com sucesso, vai levar só 1 segundo e ter este output no terminal:

==========
== CUDA ==
==========

CUDA Version 11.8.0

Container image Copyright (c) 2016-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

A copy of this license is made available in this container at /NGC-DL-CONTAINER-LICENSE for your convenience.

Output path: /workspace/results
100%|██████████| 1/1 [00:00<00:00,  4.09it/s]

E eis o resultado que aparece no diretório `./results":

Sim, eu fiquei impressionado. Mesmo a imagem sendo da Web, com marca d’agua e tudo, ele fez tudo direitinho e funcionou!!

Único problema é que ainda falta o problema de conseguir usar uma imagem de referência pra tentar pegar as cores. Esse é um problema mais difícil e eu perguntei ao ChatGPT que me respondeu isto:

Sem suporte nativo para imagem de referência:

O modelo DDColor, tanto na versão oficial hospedada no ModelScope quanto no repositório GitHub piddnad/DDColor, foi projetado apenas para colorização automática de imagens em preto e branco, sem aceitar uma imagem de referência como entrada. A própria descrição oficial deixa claro que o modelo recebe uma única imagem P&B e retorna uma imagem colorida.

O método forward do modelo espera apenas um tensor, referente à imagem P&B convertida em RGB artificial (na verdade, a luminância expandida para 3 canais). Ou seja, não há lugar no modelo para passar uma segunda imagem como referência de cores.

Isso também fica evidente no predict.py original da biblioteca Cog, que aceita apenas o parâmetro image como entrada — sem suporte a reference, ref_image ou algo do tipo.

Como resolver o problema: duas abordagens possíveis

Como o DDColor não suporta nativamente uma imagem de referência para guiar as cores, temos duas alternativas:

🔁 1. Usar um modelo especializado em colorização com referência

Existem modelos desenvolvidos especificamente para isso, como:

• Deep Exemplar-based Colorization (Zhang et al., CVPR 2018)

• ChromaGAN (2019)

• Exemplar-Transformer Colorization (Yin et al., ACM MM 2021)

• UniColor (Huang et al., 2022)

Esses modelos aceitam duas imagens:

• A imagem em P&B (entrada principal)

• Uma imagem colorida como referência de cores

Esses modelos mapeiam similaridades semânticas (ex: “pele aqui deve ter a mesma cor de pele dali”) e fazem uma transferência baseada no conteúdo da imagem, obtendo resultados muito mais detalhados e específicos. No entanto, isso exigiria:

• Baixar pesos diferentes

• Alterar completamente a arquitetura usada

• Adaptar o pipeline e a inferência

🎯 2. Usar transferência global de cor após a saída do DDColor (nossa abordagem atual)

A solução prática e leve que usamos foi:
➡️ Rodar o DDColor normalmente para gerar a imagem colorida automaticamente
➡️ Depois, ajustar globalmente as cores do resultado para ficarem mais parecidas com as da imagem de referência.

Esse ajuste é feito com o algoritmo de Reinhard et al. (2001):

1. Convertemos tanto a imagem de saída quanto a referência para o espaço de cor Lab.

2. Calculamos a média e o desvio padrão dos canais a e b (os que representam cor).

3. Ajustamos o resultado para ter a mesma distribuição estatística de cor que a imagem de referência.

4. Isso tende a deixar a imagem com o mesmo “clima” ou tom geral (mais quente, mais frio, mais vibrante).

Esse método é rápido, leve, e funciona sem alterar o modelo DDColor.

Continuando

Eu usei a modificação que ele sugeriu ao arquivo predict.py:

import os
import cv2
import numpy as np
import torch
import torch.nn.functional as F
from cog import BasePredictor, Input, Path
from basicsr.archs.ddcolor_arch import DDColor

def color_transfer(reference_bgr: np.ndarray, target_bgr: np.ndarray) -> np.ndarray:
    """Transfer color palette of reference image to target image using Lab mean/std."""
    # Convert BGR images to Lab color space (float32 for precision)
    ref_lab = cv2.cvtColor(reference_bgr, cv2.COLOR_BGR2LAB).astype("float32")
    tgt_lab = cv2.cvtColor(target_bgr, cv2.COLOR_BGR2LAB).astype("float32")
    # Split channels
    L_ref, a_ref, b_ref = cv2.split(ref_lab)
    L_tgt, a_tgt, b_tgt = cv2.split(tgt_lab)
    # Compute mean and std for reference and target (a and b channels)
    a_ref_mean, a_ref_std = a_ref.mean(), a_ref.std()
    b_ref_mean, b_ref_std = b_ref.mean(), b_ref.std()
    a_tgt_mean, a_tgt_std = a_tgt.mean(), a_tgt.std()
    b_tgt_mean, b_tgt_std = b_tgt.mean(), b_tgt.std()
    # Subtract target means, scale by reference/target std, add reference means
    # (Avoid division by zero in case of zero std)
    if a_tgt_std > 1e-6:
        a_tgt = ((a_tgt - a_tgt_mean) * (a_ref_std / a_tgt_std)) + a_ref_mean
    else:
        a_tgt = a_tgt - a_tgt_mean + a_ref_mean
    if b_tgt_std > 1e-6:
        b_tgt = ((b_tgt - b_tgt_mean) * (b_ref_std / b_tgt_std)) + b_ref_mean
    else:
        b_tgt = b_tgt - b_tgt_mean + b_ref_mean
    # Clip values to valid Lab range [0,255] after transfer
    a_tgt = np.clip(a_tgt, 0, 255)
    b_tgt = np.clip(b_tgt, 0, 255)
    # Merge channels back (use original L from target to preserve brightness)
    merged_lab = cv2.merge([L_tgt, a_tgt, b_tgt]).astype("uint8")
    # Convert back to BGR color space
    result_bgr = cv2.cvtColor(merged_lab, cv2.COLOR_LAB2BGR)
    return result_bgr

class ImageColorizationPipeline:
    """Helper pipeline to load DDColor model and process images."""
    def __init__(self, model_path: str, input_size: int = 256, model_size: str = "large"):
        self.device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        # Choose encoder backbone based on model size
        encoder_name = "convnext-t" if model_size == "tiny" else "convnext-l"
        # Initialize DDColor model
        self.model = DDColor(
            encoder_name=encoder_name,
            decoder_name="MultiScaleColorDecoder",
            input_size=[input_size, input_size],
            num_output_channels=2,    # model predicts ab channels
            last_norm="Spectral",
            do_normalize=False,
            num_queries=100,
            num_scales=3,
            dec_layers=9,
        ).to(self.device)
        # Load weights
        state = torch.load(model_path, map_location="cpu")
        # Some checkpoints store weights under 'params' key
        self.model.load_state_dict(state.get("params", state), strict=False)
        self.model.eval()
        self.input_size = input_size  # store for processing

    @torch.no_grad()
    def process(self, img_bgr: np.ndarray) -> np.ndarray:
        """Colorize a BGR image (numpy array) using the loaded DDColor model."""
        # Preserve original resolution L channel
        orig_h, orig_w = img_bgr.shape[:2]
        # Convert to Lab and extract L channel at original size
        img_lab = cv2.cvtColor(img_bgr, cv2.COLOR_BGR2LAB).astype("float32")
        orig_L = img_lab[:, :, 0:1]  # shape (H, W, 1)
        # Prepare grayscale input at model resolution
        # Resize input to model expected size
        inp = cv2.resize(img_bgr, (self.input_size, self.input_size))
        inp_lab = cv2.cvtColor(inp, cv2.COLOR_BGR2LAB).astype("float32")
        L = inp_lab[:, :, 0:1]
        # Create grayscale Lab image by zeroing AB channels
        gray_lab = np.concatenate([L, np.zeros_like(L), np.zeros_like(L)], axis=2)
        # Convert back to RGB (now it's a gray RGB image of size input_size)
        gray_rgb = cv2.cvtColor(gray_lab.astype("uint8"), cv2.COLOR_LAB2RGB)
        # Prepare tensor and run model
        tensor = torch.from_numpy(gray_rgb.transpose(2, 0, 1)).float().unsqueeze(0).to(self.device)
        out_ab = self.model(tensor)  # output is (1,2,H_out,W_out) in Lab AB
        out_ab = out_ab.cpu().float()
        # Resize output AB to original image size
        out_ab_resized = F.interpolate(out_ab, size=(orig_h, orig_w), mode="bilinear", align_corners=False)
        out_ab_resized = out_ab_resized[0].numpy().transpose(1, 2, 0)  # (H, W, 2)
        # Combine original L and predicted AB, then convert to BGR
        out_lab = np.concatenate([orig_L, out_ab_resized], axis=2).astype("uint8")
        out_bgr = cv2.cvtColor(out_lab, cv2.COLOR_LAB2BGR)
        return out_bgr

class Predictor(BasePredictor):
    def setup(self):
        """Load models into memory for efficient multiple predictions."""
        # Determine paths for large and tiny model weights
        large_model_path = "checkpoints/ddcolor_modelscope.pth"
        tiny_model_path  = "checkpoints/ddcolor_paper_tiny.pth"
        # (Ensure the above files exist. If not, download from ModelScope or HuggingFace as described.)
        # Initialize pipelines for large and tiny models
        self.colorizer_large = ImageColorizationPipeline(model_path=large_model_path, input_size=512, model_size="large")
        self.colorizer_tiny  = ImageColorizationPipeline(model_path=tiny_model_path,  input_size=512, model_size="tiny")

    def predict(
        self,
        image: Path = Input(description="Grayscale input image."),
        reference: Path = Input(description="Optional reference image to guide colors", default=None),
        model_size: str = Input(description="Model size to use (large = highest quality, tiny = faster).",
                                choices=["large", "tiny"], default="large"),
    ) -> Path:
        """Run a single prediction. Colorizes the image, optionally using a reference image for color bias."""
        # Read input image
        img = cv2.imread(str(image))
        if img is None:
            raise ValueError("Failed to load input image")
        # Select model pipeline
        pipeline = self.colorizer_tiny if model_size == "tiny" else self.colorizer_large
        # Colorize the image using DDColor
        output_bgr = pipeline.process(img)
        # If a reference image is provided, transfer its color style to the output
        if reference is not None:
            ref_img = cv2.imread(str(reference))
            if ref_img is None:
                raise ValueError("Failed to load reference image")
            # Only apply transfer if reference is a color image
            if ref_img.shape[2] == 3:
                output_bgr = color_transfer(ref_img, output_bgr)
        # Save result
        out_path = "/tmp/out.png"
        cv2.imwrite(out_path, output_bgr)
        return Path(out_path)

Com essa modificação posso rodar com esse novo parâmetro, note a opção “–ref” que tem agora e coloque sua imagem no lugar certo:

❯ docker run --rm --gpus all \
  -v "$PWD/input":/workspace/input_images:ro \
  -v "$PWD/results":/workspace/results:rw \
  -v "$PWD/ref_images":/workspace/ref_images:ro \
  -v "$PWD/modelscope":/app/modelscope:ro \
  -v "$PWD/infer.py":/app/infer.py:ro \
  ddcolor:latest \
  python3 /app/infer.py \
    --model_path /app/modelscope/damo/cv_ddcolor_image-colorization/pytorch_model.pt \
    --input /workspace/input_images \
    --ref /workspace/ref_images/images.jpg \
    --output /workspace/results

Passei outra foto colorida de referência mas não dferença no resultado. Novamente, perguntei ao ChatGPT:

Por que você não percebeu diferença no resultado?

A transferência global de cor só altera a “paleta geral” — e não as cores de cada objeto.

Se a imagem de referência tem tons suaves ou parecidos com os que o DDColor já aplicaria automaticamente, o efeito final vai parecer idêntico.

Mas se você usar como referência uma imagem bem saturada (por exemplo, um céu alaranjado, ou um ambiente azul escuro), você verá a saída do DDColor ser puxada visualmente para aquele estilo.

Conclusão

Segui a sugestão e baixei outra imagem nada a ver, colorida, super saturada com cores vibrantes pra ver se fazia diferença. Esta é a imagem de referência que passei pro Docker:

E eis o novo resultado aplicando ela à imagem anterior em pós-processamento (esse passo não é mais I.A. é pós-processamento de imagem mesmo).

Comparem com a outra foto re-colorizada, vou colocar aqui embaixo de novo pra dar pra comparar:

Entenderam? Agora precisa ficar testando com referências diferentes pra ver a influência no resultado final, mas de fato, ele consegue aplicar o algoritmo de Reinhard e fazer uma transferência global de cor. Como o nome diz, é “global”, não “por objeto”, então é difícil conseguir controlar só partes da imagem e sim a imagem toda. Mas em teoria eu acho que você conseguiria fazer uma colorização manual no Photoshop com cores saturadas, perto de onde quer influenciar, pra tentar ajustar, mas eu não tentei isso ainda, depois se alguém fizer, mande nos comentários.

Mas é isso. Agora pelo menos eu consigo me divertir pegando fotos antigas de família e re-colorizar.

Sim, este episódio foi inteiramente gerado por ferramentas de IA, em particular HeyGen e ElevenLabs. Fiz bem curto pra não ficar cansativo demais. Mesmo sendo impressionante, no atual estágio não é possível fazer videos do tamanho que costumo fazer no canal.

Primeiro, o HeyGen não consegue fazer videos maiores do que 1 minuto sem que a qualidade decaia muito. Eu tentei fazer videos de mais de 2 minutos e do nada ele começava a halucinar e me fazer falar em espanhol, por exemplo.

Segundo, o treinamento é super limitado. Ele só me deixa subir uns 5 minutos de amostra de video. É muito pouco e isso resulta em muito pouca variância nos movimentos. Muito pouca diversidade de jeito de falar. Então fica muito robótico mesmo.

Terceiro, o tempo que levou pra gerar esses clipes de video não compensa o trabalho. Não é de graça, custou quase 40 dólares pra fazer menos de 14 minutos. E levou mais de 14 minutos pra gerar tudo. Eu teria levado cerca de meia hora pra gravar normalmente um video deste tamanho. Então não é possível usar esse tipo de ferramenta pra economizar tempo.

A vantagem seria mais no futuro, quando esses limites melhorarem, e eu tiver algum problema físico que me impeça de gravar mais videos. Aí sim, poderia servir como meu “backup virtual”. Ainda é primeira geração desse tipo de ferramenta. Eles devem melhorar bastante nos próximos anos.

O que acharam?

Links

• HeyGen - AI Spokesperson Video Creator
• Text to Speech & AI Voice Generator (elevenlabs.io)
• eesel.ai - ChatGPT over your knowledge
• DaVinci Resolve 18.5 traz inteligência artificial para edição de vídeo (diolinux.com.br)
• Adobe Firefly – Generative AI for everyone

SCRIPT

Olá pessoal, Fabio Akita!

Este vai ser um episódio experimental, curtinho mesmo, mais de brincadeira. Desta vez quero falar um pouco sobre as ferramentas de IA, tipo ChatGPT, que tenho incorporado no meu dia a dia. Não vai ser um review extenso de tudo que existe, só o que eu já experimentei e gostei de usar.

Todo mundo continua empolgado e hypado por causa de ChatGPT, especialmente com o lançamento do ChatGPT 4, com funcionalidades como, abre aspas, “fazer seu próprio GPT”. Vou aproveitar pra explicar um pouco disso e reiterar minhas opiniões sobre IA em geral. Então, vamos lá!

Pra começar, novembro vimos um dos episódios mais patéticos da história de Silicon Valley. Tudo bem, pra ser honesto, teve mais patéticos, como a história da Theranos ou da WeWork. Mas o hype sobre IAs continua num estágio muito primitivo de discussão.

Esse episódio patético foi a diretoria da OpenAI demitir o CEO Sam Altman, sem explicação nenhuma, fazendo um puta drama, pra depois voltarem atrás quando todos os funcionários ameaçaram sair e irem pra Microsoft. Ninguém deu uma razão oficial pra isso até agora, mas alguns especulam que tem a ver com os riscos de estarem próximos de atingirem a tal da “AGI” ou “Inteligência Artificial Geral”, a temida Skynet.

O que se chama de “IA” hoje em dia são Large Language Models, LLMs. E LLMs são basicamente como o auto corretor do teclado do seu celular, mas altamente glorificado! Ele cospe coisas que parecem ter sentido, mas não houve um milímetro de cognição envolvida, muito menos consciência. Provavelmente, amebas tem mais consciência do que o melhor LLM de hoje.

Explico isso em detalhes no meu video de “Como ChatGPT Funciona”, depois assistam pra entender. Modelos são embeddings de textos. Matrizes hiper-dimensionais de pedaços de textos associados com valores probabilísticos. Em resumo, super resumido, é assim que um GPT gera textos. GPT é um gerador de textos. Sim, um gerador ultra-sofisticado, mas ainda assim, um gerador de textos. Não existe “inteligência” no sentido humano que envolve raciocínio ou cognição.

GPT só continua o texto a partir de onde você parou de digitar. Ele continua textos. A idéia toda de “gerar seu próprio GPT” eu mostrei na live que tá no meu canal de “IAs são perigosas?” Onde eu mostro como criar um personagem. Eu criei o John Carmack e comecei a conversar com ele. Assistam lá depois. É a mesma coisa no GPT 4, um prompt inicial dizendo “faça de conta que você é a pessoa Fulano, com comportamento assim ou assado” e aí ele continua o texto.

Mesmo com os avanços do GPT 4, mesmo se o GPT 5 for o dobro ou triplo ou 10 vezes melhor que GPT 4, ainda assim não estamos pertos da tal “AGI” que é a Inteligência Artificial “Geral”, a verdadeira consciência digital, que simula perfeitamente um “ser vivo”, com emoções e ambições, a semente da Skynet. Isso continua sendo ficção científica. Ainda faltam descobertas e breakthroughs que não foram feitos.

Não sabemos quais descobertas são, obviamente, senão não seriam descobertas, mas sabemos que faltam. Ao contrário do que as pessoas pensam, nós engenheiros e cientistas, não fazemos as coisas às cegas, aleatoriamente. Sabemos quais os limites do que pode ser feito com as ferramentas que temos. Imaginação é exatamente uma das coisas que nós sabemos fazer muito bem, e que IAs não tem capacidade.

Mesmo assim, muita gente considerada “gênio” da área, como um dos fundadores da OpenAI o Ilya, por alguma razão, resolveu aderir à crença de que estamos perigosamente próximos de uma AGI que vai prejudicar a espécie humana. Não vai. Não só tá longe, como neste estágio eu nem diria que temos certeza se isso é sequer possível. Pra começar não existe nem boas definições para o que caracteriza de fato coisas como “inteligência” ou “consciência”. Nossas definições hoje são extremamente primitivas ainda.

É o mesmo tipo de “gênio” que anos atrás ficava enchendo o saco dizendo que o aquecimento global já teria acabado com o mundo em 2023. Mas isso é outro assunto.

Mesmo assim, sim, os receios que IAs vão substituir o emprego de muita gente são reais, em particular porque existem muitas atividades que são meramente copy e paste, muito simples de serem automatizadas. Não porque a IA ficou inteligente demais, mas porque os trabalhos em si eram muito simples.

Não precisou de IA pra começar a substituir caixa de supermercado ou tirar pedido em fast food. Muitos mercados já tem caixas self-service. Lugares como McDonald’s já tem telas gigantes de pedidos self-service. Muitos bots de atendimento via whatsapp já substituiram gente que atendia telefone, e por aí vai. E isso é normal. Faz mais de século que estamos substituindo trabalhos de baixo valor agregado pra sistemas automatizados, e pra isso não precisa de IA. A geração atual de LLMs ajuda, com toda certeza.

No nosso caso de programadores, sim, também existe automação. Mesmo em design. Todo mundo que usa softwares como Canva já sabe disso. O que antes precisava pedir pra alguém abrir o Photoshop pra fazer, qualquer um sem nenhum treinamento já consegue fazer agora. Quem é de Photoshop, lembra como separar uma pessoa do fundo antigamente levava horas, precisava de técnicas avançadas com lidar com canais de separação de cor. Agora o app de câmera do iPhone ou Pixel já conseguem fazer isso com um clique.

Mesmo antes de IA, com serviços como SquareSpace, muita gente não-técnica já consegue fazer sites minimamente bonitos. O mercado de templates, por si só, barateou bastante o que antes era um trabalho caro e demorado. Pra maioria das pessoas, só isso já é suficiente. E de novo, nem precisamos de IA pra isso.

Isso tudo dito, as ferramentas baseadas em alguma coisa de IA de hoje são extremamente úteis. ChatGPT e LLMs são só um dos tipos de IA, mas não são os únicos tipos. Muitas ferramentas que usam modelos de IA não são baseados em LLMs porque não são geradores de conteúdo. Alguns usam machine learning, alguns usam deep learning, alguns usam combinações de diversas técnicas. A população leiga chama tudo isso só de “IA”, por isso gera tanta confusão. Mas IA não é uma entidade única, é uma coleção de diversas tecnologias diferentes trabalhando em conjunto, muitas delas com décadas de idade já.

Se não ficou claro, este video que você está assistindo, por exemplo, foi inteiramente gerado com auxílio de IA. Estou usando o site HeyGen.com, que foi treinado com trechos de videos antigos. Esse site se integra com outro, chamado ElevenLabs, que é especializado em vozes via IA. Então, só precisamos escrever um novo script, subir trechos no HeyGen e ir gerando pedaços, porque ele não deixa gerar videos muito longos ainda. No final jogamos no DaVinci Resolve de sempre, pra juntar os pedaços num único video.

Sim, tudo que você assistiu até aqui foi inteiramente gerado por IA. Eu sou um avatar digital do Fabio Akita. O Fabio Akita de verdade foi sequestrado e vou mantê-lo como refém até … hahahahaha .. estou brincando, claro. Claro. Se duvida que sou uma IA, o HeyGen pode fazer outra coisa: dublar qualquer áudio em qualquer outra língua. Já pensaram, como é o Akita falando em coreano? Vamos ver.

Não se convenceram? Então vamos ver de novo, só que dublado em árabe.

Interessante não? É assim que muitos videos no TikTok são feitos hoje. E já que estou falando de video, diversas marcas famosas como Blackmagic e Adobe já integraram funcionalidades de IA num DaVinci Resolve ou Adobe Photoshop da vida.

No Resolve, por exemplo, ele consegue coisas incríveis como re-iluminar uma cena. Imagine que faltou uma luz de um lado, o que fazer? A IA consegue analizar a cena, descobrir a profundidade dos objetos filmados num espaço 3D e com isso podemos posicionar uma nova luz em qualquer lugar.

Não achou isso interessante? Este trecho eu gravei com barulho de fundo pra simular gravação na rua ou em eventos. O DaVinci é capaz de separar sua voz do resto do barulho e a qualidade fica quase como se tivesse sido gravado em estúdio. Vamos repetir com o filtro.

Viram? E dá pra fazer muito mais. Gerar legendas, antes era manual, mas agora ele faz automaticamente pra mim, como neste trecho. Se você é editor de video, deveria explorar essas opções. Dois canais do YouTube que recomendo assistir pra aprender é o MrAlexTech e o do Casey Faris. Sobre colorização, o melhor profissional é o Waqas Qazi.

Adobe também não fica atrás. Pra começar existe agora esse novo produto Adobe Firefly, que é como um Dalle-2 ou Midjourney, mas que a Adobe garante que foi treinada só com imagens cujos direitos autorais permitem isso. Assim você não corre o risco de gerar uma imagem que depois pode te levar a ser processado.

Photoshop também tá ganhando várias novas funcionalidades de IA, um dos mais notáveis é o preenchimento de conteúdo. Antigamente ele usava pedaços da própria imagem pra preencher o vazio quando queríamos mudar as dimensões da imagem. Mas agora ele consegue redesenhar como faz um Midjourney, com uma qualidade até que bem aceitável em vários casos, precisando fazer muito pouco ajuste depois.

A melhor ferramenta de edição de imagens ainda é Photoshop, e tem dezenas de técnicas e teorias que precisa saber pra usar direito. Recomendo assistir o canal PixelImperfect que ensina algumas das melhores técnicas.

Sobre geração de textos, não preciso perder tempo explicando como ChatGPT é ótimo pra fazer resumos, escrever textos descartáveis como um email mais formal. Mesma coisa vale pro GitHub CoPilot. Espero que vocês já tenham deixado pra trás a idéia idiota de achar que essas ferramentas vão substituir todos os programadores. Como já disse nos videos anteriores, minha resposta é a mesma: toda atividade de baixo valor agregado, inclusive programação de baixo valor agregado, vai sim ser substituído.

Bons programadores, não. Nenhum gerador de textos chega a 10% de um programador de verdade. Mas o que ele faz já nos ajuda bastante. Eu não preciso ficar toda hora dando alt-tab pra documentação e ficar manualmente procurando a sintaxe dessa ou daquela função, o Copilot auto-completa direitinho. É basicamente automatizar o copy e paste de stackoverflow que todo mundo já fazia.

Pra fazer coisas como HTMLs básicos, que é sempre a mesma estrutura. CSS básico, que é sempre a mesma estrutura. Códigos de testes unitários, que é sempre a mesma estrutura, essas coisas repetitivas e trabalhosas, o Copilot ajuda bastante. Muita coisa que eu sempre achei tedioso, um Copilot ou GPT ajuda muito e recomendo que usem. Integração com Visual Studio, até com Vim já funcionam super bem.

Mais do que isso, recomendo instalar GPT em linha de comando, como um “AI Chat”. Assim, do terminal, posso perguntar sobre comandos que não lembro todas as opções de cabeça. Como que roda um container docker de tal forma que ele apague o container depois que eu terminar, pra não deixar sujeira pra trás? Só perguntar, copiar o comando, e já colar direto no terminal e pronto.

Lógico, como sempre, nada disso serve pra quem não presta atenção. Se não tomar cuidado, você vai estragar sua máquina, colando comandos sem saber o que fazem. Mas isso já acontecia quando você colava comandos do stackoverflow. Se não sabe discernir nem isso, obviamente não é um profissional de programação.

Finalmente, uma das limitações do ChatGPT, pelo menos até a versão atual, é que ele não guarda memória do que você conversou com ele. Toda nova conversa começa do zero. Ele não usa informações anteriores pra continuar respondendo. Mas existem dezenas de ferramentas que aumentam essas capacidades. Um desses exemplos é o Eezel.io. Nesse site podemos fazer upload de documentos, como Word ou PDF.

Ele vai processar essa informação, criar embeddings dos textos, colocar num banco de dados de vetores, e usar essa informação no chat, que é integrado com ChatGPT. Assim, podemos fazer perguntas em linguagem natural sobre os dados que acabamos de subir. Pense subir uma centena de relatórios de feedback da empresa, e pedir um resumo de tudo, ou perguntar sobre uma pessoa em particular, e coisas assim.

Não vou sair listando toda ferramenta integrada com ChatGPT porque várias aparecem, e várias desaparecem, todos os dias. É melhor ir no Google e procurar as ferramentas mais famosinhas da época. Esse ainda é um mercado super volátil. Eesel, ElevenLabs, HeyGen, talvez ainda existam daqui um ano, talvez já tenham sido substituídos por alternativas melhores, não temos como saber.

Como falei no começo, este é um video curto, foi só pra cagar regra sobre IA e experimentar como ficaria um episódio inteiro feito com IA. Quem sabe, embora AGI não seja mais que ficção científica ainda, o que temos hoje já é muito bom e já serve até pra fazer videos como este. Eu consigo ver estas ferramentas sendo aprimoradas pra gerarem resultados mais naturais. Do jeito que tá hoje, os mais desavisados já nem sabem mais a diferença entre real e virtual.

Se curtiram o video deixem um joinha, assinem o canal, cliquem no sininho e compartilhem com seus amigos. A gente se vê, até mais!