Guia completo para reutilizar workflows do ComfyUI: checklist de importação, depuração e reprodução

Depois de importar o workflow do ComfyUI de outra pessoa, a interface pode aparecer cheia de nodos vermelhos e com a lista de modelos vazia. Na primeira vez que passei por isso, levei meia hora para perceber que o problema caía em três grupos: nodos faltantes, caminho de modelo errado e dependência de Python não instalada. Este guia não trata da instalação do ComfyUI. Ele foca em uma pergunta: quando você recebe um JSON de workflow ou um PNG, como completa o que falta, depura passo a passo e reproduz algo próximo da imagem de exemplo? O núcleo é uma checklist reutilizável, do import ao arquivamento.

Por que o workflow de outra pessoa não roda?

Um workflow do ComfyUI é, na prática, um grafo de nodos conectados. JSON ou metadata PNG registra tipos de nodos, valores de parâmetros e conexões, mas não inclui arquivos de modelos, plugins de custom nodes nem dependências de Python. Quando você importa um workflow compartilhado, tudo o que falta no seu ambiente aparece imediatamente.

Um nodo vermelho significa que o ComfyUI não encontrou aquele tipo de nodo. Alguns são core nodes, integrados ao programa, e não deveriam faltar. Outros são extensões de terceiros, os custom nodes, que você talvez nunca tenha instalado. Mesmo depois de corrigir os nodos, o menu de Load Checkpoint ou Load LoRA pode continuar vazio porque o arquivo do modelo não está no diretório padrão ou a configuração de caminho está errada. E, depois disso, alguns custom nodes ainda podem reclamar de pacotes Python ausentes, como insightface ou onnxruntime.

Esses três problemas se acumulam. Um workflow pode faltar três custom nodes, dois modelos checkpoint e um pacote Python ao mesmo tempo. Sem uma ordem de diagnóstico, é fácil travar em uma etapa e instalar um monte de coisa sem relação. A checklist abaixo separa esses problemas e trata cada um por prioridade.

Duas fontes de workflow: JSON vs metadata PNG

Quando alguém compartilha um workflow, geralmente usa um de dois formatos: um arquivo JSON independente ou uma imagem PNG com metadata. JSON é o formato nativo exportado pelo ComfyUI e preserva as informações dos nodos. Metadata PNG é uma forma embutida: algumas imagens geradas carregam dados do workflow dentro do arquivo, desde que o criador tenha preservado isso.

Arrastar um arquivo JSON

Ao receber um JSON, arraste o arquivo diretamente para a interface do ComfyUI. A interface carrega o grafo e mostra todas as conexões. É o caminho mais confiável: JSON não depende de compressão de imagem e mantém intactas as informações dos nodos.

Se o JSON foi exportado do ComfyUI, o layout importado deve ser igual ao do autor. Se a disposição vier bagunçada, pode haver diferença de versão do ComfyUI no momento da exportação ou o JSON pode ter sido editado manualmente.

Condições para carregar metadata PNG

Algumas imagens PNG geradas por IA embutem metadata de workflow. Você pode carregá-las arrastando a imagem para o ComfyUI ou escolhendo “Load” no menu e selecionando o PNG.

A condição é simples: a imagem precisa manter a metadata. Muitas redes sociais e hospedagens de imagem comprimem ou removem metadata durante o upload, apagando os dados do workflow. Se a imagem veio de uma rede social, há boa chance de a metadata já ter sumido e o ComfyUI abrir apenas uma tela vazia.

Prefira arquivos JSON. Metadata PNG é útil para o autor guardar o próprio histórico de geração, mas não é um formato confiável para compartilhar entre plataformas.

Comparação entre JSON e metadata PNG

Antes de importar, verifique a origem. Um pacote com lista de nodos, lista de modelos ou README é mais seguro do que depender apenas do JSON ou do PNG.

Nodos vermelhos: diferencie Core Node de Custom Node

Depois de importar, podem aparecer nodos vermelhos com títulos como “Missing” ou “Unknown node type”. Não saia instalando pacotes. Primeiro identifique o tipo de nodo e só depois escolha onde procurar.

Diferença entre Core Node e Custom Node

Core node é um nodo integrado ao ComfyUI. Ele vem com o programa principal e não deveria faltar. Exemplos comuns: Load Checkpoint, KSampler, VAE Decode, Save Image. Se esses nodos aparecerem vermelhos, a instalação do ComfyUI pode estar incompleta ou desatualizada.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Custom node é uma extensão de terceiros, instalada separadamente. Exemplos comuns: IP-Adapter Apply, ControlNet Apply, FaceDetailer. A maioria dos nodos vermelhos vem de custom nodes ausentes.

Para decidir, olhe o nome. Se ele inclui prefixos conhecidos de extensões, como IPAdapter, ControlNet ou Impact, provavelmente é um custom node. Se houver dúvida, clique com o botão direito na interface e procure o nome em “Add Node”. Core nodes aparecem na lista padrão; custom nodes ausentes não aparecem.

Como encontrar um Custom Node

Depois de confirmar que é um custom node, há três caminhos.

ComfyUI Registry: é a plataforma de registro recomendada pelo projeto. Acesse registry.comfy.org e pesquise pelo nome do nodo ou da extensão. O Registry costuma indicar origem, instalação e dependências. Alguns nodos oferecem instalação com um clique, dependendo da versão do ComfyUI.

ComfyUI Manager: é uma ferramenta de terceiros para gerenciar extensões. Se você já tem o Manager instalado, abra ComfyUI, vá em “Manager” -> “Install Custom Nodes” e pesquise o nome do nodo. O Manager lista extensões compatíveis e mostra o estado de instalação. Ele não é parte do core do ComfyUI; sua estabilidade depende da comunidade.

Busca no GitHub: se Registry e Manager não encontrarem nada, pesquise o nome do nodo no GitHub. Muitos autores documentam os nomes dos nodos no README. Ao encontrar o repositório, clone-o dentro de custom_nodes seguindo o README.

Problemas de dependências Python

Alguns custom nodes exigem pacotes Python extras. Por exemplo, IP-Adapter pode precisar de insightface, e algumas extensões de ControlNet podem exigir onnxruntime.

Entre no diretório do custom node e leia o README ou requirements.txt. Na raiz do ComfyUI, rode:

pip install -r custom_nodes/diretorio-do-nodo/requirements.txt

Alguns README indicam diretamente pip install nome-do-pacote. Siga a instrução do projeto.

Confirme primeiro quais nodos faltam de verdade

Um workflow pode referenciar muitos custom nodes, mas talvez você precise instalar apenas os que aparecem em vermelho. Essa lista é o inventário real de faltantes. Não instale todos os pacotes populares de uma vez: cada pacote aumenta o tempo de inicialização e o risco de conflito.

Modelo não aparece? Revise diretórios e configure uma biblioteca externa

Depois de completar os nodos, os menus de Load Checkpoint, Load LoRA e Load VAE ainda podem ficar vazios. O JSON não carrega os modelos junto; você precisa colocá-los manualmente no diretório models do ComfyUI.

Estrutura do diretório models do ComfyUI

Ao iniciar, o ComfyUI escaneia subpastas dentro de models e carrega os modelos por tipo. As pastas mais comuns são:

Se o nodo Load Checkpoint do workflow aponta para sdxl_base.safetensors, coloque esse arquivo em models/checkpoints/sdxl_base.safetensors. O menu do nodo passa a mostrar os modelos dessa pasta.

Para que serve extra_model_paths.yaml

Se sua biblioteca de modelos fica em outro lugar, como um NAS compartilhado ou uma pasta centralizada, você não precisa copiar tudo para models. Use extra_model_paths.yaml para apontar caminhos externos.

O arquivo fica na raiz do ComfyUI e usa YAML. Exemplo:

my_custom_config:
  base_path: /path/to/external
  checkpoints: models/checkpoints
  loras: models/loras
  vae: models/vae
  controlnet: models/controlnet

Na inicialização, o ComfyUI escaneia os caminhos configurados e combina esses modelos com o diretório models padrão. O formato pode mudar entre versões; confira a documentação oficial ou as mensagens de inicialização quando algo não bater.

Confirmar a versão do modelo

O workflow pode apontar apenas para sdxl_base, mas esse nome pode existir em várias versões: oficial, fine-tune da comunidade, fp16, pruned. Versões diferentes podem gerar resultados bem diferentes.

Ao receber o workflow, pergunte primeiro a fonte e a versão do modelo. Se não houver explicação, procure o nome em bibliotecas como Civitai ou Hugging Face e veja se o autor marcou uma versão pública. Prefira a versão indicada pelo autor, não um arquivo qualquer com o mesmo nome.

Este guia não oferece links diretos de download. Licenças de modelos são complexas demais. O melhor é guardar nomes e páginas de origem, e deixar a verificação de licença por sua conta.

Por que o resultado não fica igual à imagem de exemplo?

Você completou nodos e modelos, o workflow rodou, mas a imagem final ficou diferente. Isso nem sempre é erro seu. A diferença pode vir de parâmetros, versões de modelo ou backend de execução.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Tabela de impacto dos parâmetros

A tabela abaixo resume o impacto mais comum de cada parâmetro. Parâmetros de impacto alto precisam ficar alinhados; os de impacto menor permitem algum ajuste.

A versão do modelo é o fator principal

Mesmo que você baixe um modelo com o mesmo nome, a versão errada pode desviar completamente o resultado. sdxl_base, por exemplo, pode ser o modelo oficial, uma variante fp16 da comunidade ou um fine-tune de anime. Se o autor usou o oficial e você baixou uma variante de anime, o estilo muda por completo.

Depois de receber o workflow, confirme primeiro a fonte e a versão do modelo. Se o autor não informou, veja a página do modelo e procure notas de versão. Se ainda houver dúvida, pergunte em vez de chutar.

Mire em estilo e composição parecidos, não em clonagem perfeita

Reproduzir uma imagem exatamente exige versão do modelo, seed, parâmetros e ambiente de execução idênticos. É difícil alinhar tudo, principalmente quando faltam seed e versão exata.

O objetivo prático é se aproximar do estilo e da composição da imagem de exemplo. Se o assunto, o tom de cor e a estrutura geral estiverem parecidos, a reprodução funcionou. Diferenças finas, como rosto e textura, são esperadas.

Checklist de troubleshooting para reutilizar workflows do ComfyUI

A checklist abaixo cobre o processo completo, da importação ao arquivamento. Guarde-a e revise item por item sempre que reutilizar um workflow de outra pessoa.

Etapa 1: confirmar a fonte

Ao receber o workflow, identifique primeiro o formato e o material de apoio.

• Confira se é um arquivo JSON ou uma imagem PNG. Prefira JSON; metadata PNG pode ser removida por plataformas.
• Veja se há explicação junto: lista de nodos, lista de modelos, README ou comentário do autor.
• Se houver apenas PNG, tente carregar a metadata. Se falhar, ela se perdeu; peça o JSON ao autor ou abandone o workflow.
• Se a fonte é incerta ou uma postagem da comunidade tem mais de 12 meses, trate como baixa confiança.

Etapa 2: completar nodos

Depois de importar o workflow, revise os nodos vermelhos.

• Liste todos os nomes de nodos vermelhos e confirme se são core nodes ou custom nodes.
• Se faltar core node, verifique se a instalação do ComfyUI está completa ou se a versão é antiga demais.
• Se faltar custom node:
  • Pesquise o nome do nodo ou da extensão no ComfyUI Registry.
  • Se o Manager estiver instalado, pesquise em “Install Custom Nodes”.
  • Se não encontrar, pesquise o nome do nodo no GitHub e siga o README.
• Reinicie o ComfyUI depois de instalar o custom node.
• Verifique se os nodos vermelhos desapareceram. Se continuarem, pode faltar dependência Python; entre no diretório do custom node, veja requirements.txt e rode pip install -r requirements.txt.

Instale primeiro o que está realmente faltando. Não instale todos os pacotes famosos.

Etapa 3: mapear modelos

Depois dos nodos, revise os nodos de modelos.

• Liste todas as referências de modelos: checkpoint, LoRA, VAE, ControlNet, IP-Adapter e outros.
• Identifique o tipo de cada modelo para saber em qual subdiretório de models/ ele deve ficar.
• Veja se você já tem um modelo local com o mesmo nome. Se tiver, confirme a versão.
• Se não tiver, procure em uma biblioteca como Civitai ou Hugging Face e confirme fonte e versão.
• Depois de baixar, coloque na pasta correta ou aponte um caminho externo com extra_model_paths.yaml.
• Reinicie o ComfyUI e confirme que o modelo aparece no menu do nodo.

Versão de modelo é o maior fator de reprodução. Confirme isso antes de mexer nos outros parâmetros.

Etapa 4: travar parâmetros

Com os modelos no lugar, revise os parâmetros do workflow.

• Confira se o seed está fixo. Se não estiver, você não reproduz a mesma imagem; só aproxima o estilo.
• Revise sampler, steps, CFG Scale e tamanho da imagem.
• Verifique se há VAE carregado e quais pesos de LoRA foram usados.
• Compare a imagem de exemplo com os parâmetros e procure diferenças óbvias.
• Se o autor deixou notas de ajuste, siga essas notas.

Os parâmetros podem ter sido ajustados manualmente pelo autor. Quando a imagem de exemplo e o JSON não batem, alinhe manualmente.

Etapa 5: teste mínimo

Com os parâmetros claros, faça primeiro um teste simples.

• Rode uma vez com um prompt simples, como “a cat sitting on a chair”.
• Confira se a saída é normal: sem erro, sem imagem vazia e sem colapso visual evidente.
• Se houver erro, leia o log do terminal e localize o nodo ou modelo problemático.
• Se a saída estiver normal, ajuste prompt e parâmetros aos poucos para chegar perto do exemplo.
• Não comece com um prompt complexo. Prompt complexo pode esconder problema de nodo ou modelo.

Etapa 6: nomear e arquivar

Quando a reprodução funcionar, salve e organize o workflow.

• Salve o workflow como um novo JSON.
• Formato recomendado: [tema]-[modelo]-[data]-v1.json. Exemplo: portrait-sdxl-base-20260623-v1.json.
• Registre a versão do modelo. Prefira um README.txt junto ao workflow; não dependa de comentários no JSON.
• Registre checkpoint e versão, nomes e pesos de LoRA, VAE, sampler e parâmetros.
• Se for compartilhar, inclua lista de nodos, lista de modelos, imagem de exemplo e notas de parâmetros. Não compartilhe arquivos de modelos.

Essa checklist pode ser copiada e marcada a cada reutilização de workflow.

Gestão de workflows: nomes e recomendações de compartilhamento

Depois que a reprodução funciona, organizar e arquivar evita repetir a investigação na próxima vez. Se você compartilhar com alguém, informações completas reduzem o tempo de troubleshooting da outra pessoa.

🔥 Não perca meses em produtos sem demanda! Valide as propostas do seu SaaS com a Adsterra e pouco orçamento →

Testar agora →Anúncio

Convenção de nomes

Nomes bagunçados fazem você perder o workflow certo, principalmente quando já existem dezenas.

Formato recomendado: [tema]-[modelo]-[data]-v1.json

Exemplos:

• portrait-sdxl-base-20260623-v1.json: tema retrato, modelo SDXL Base, 23 de junho de 2026, versão 1
• landscape-sd15-controlnet-20260620-v1.json: tema paisagem, SD1.5 + ControlNet

O tema pode ser o uso: portrait, landscape, anime, product, concept-art. O modelo deve ser a abreviação do checkpoint principal. Use data em YYYYMMDD. v1, v2 distinguem iterações.

Como registrar versões de modelos

O JSON do workflow não registra a versão real do arquivo de modelo; ele registra apenas o nome. Se a biblioteca tiver várias versões com o mesmo nome, talvez você não saiba qual usou quando abrir no futuro.

Duas formas de registrar:

Método 1: README.txt junto ao workflow

Crie um README-[nome-do-arquivo].txt na mesma pasta e registre:

• nome do checkpoint e link de origem (não link direto de download; apenas URL da página do modelo)
• nomes, pesos e fontes dos LoRAs
• nome e fonte do VAE
• sampler, steps, CFG e tamanho
• outros parâmetros importantes

Use o README.txt como fonte principal de versão de modelos. Ele é mais compatível e também facilita compartilhar junto com o JSON e a imagem de exemplo.

Recomendações para compartilhar workflows

Ao compartilhar um workflow, informação completa ajuda a outra pessoa a começar rápido.

Conteúdo essencial:

• Arquivo JSON: o workflow completo, item mais importante.
• Lista de nodos: todos os custom nodes e sua origem, como link do Registry ou repositório GitHub.
• Lista de modelos: checkpoint, LoRA, VAE, ControlNet e outros modelos, com nomes e origem sugerida, sem link direto de download.
• Imagem de exemplo: uma saída gerada para confirmar o alvo de reprodução.
• Notas de parâmetros: se os parâmetros do JSON não baterem com a imagem de exemplo, indique os parâmetros realmente usados.

O que não compartilhar:

• Arquivos de modelos: licenças são complexas; não compartilhe os modelos.
• Links diretos de download: a página da biblioteca pode ser indicada, mas links diretos têm mais risco.
• Comandos de instalação de pacotes Python: se um custom node tiver dependência especial, indique o pacote; deixe a outra pessoa ler o README para o comando exato.

Inclua um README curto com essas informações. Quem receber o pacote poderá seguir a checklist item por item e resolver tudo mais rápido.

Próxima leitura

Se você ainda não instalou o ComfyUI, comece pelo guia completo de introdução ao ComfyUI para entender instalação, diretório de modelos e primeira imagem. Para melhorar prompts, veja Prompt Engineering em casos de negócio. Para fluxos criativos assistidos por IA entre mídias, leia criação entre mídias. Para rodar modelos de linguagem localmente, siga com introdução ao Ollama.