Fundamentos de prompt entre modelos

TL;DR

• Tokenização é BPE com a janela de 77 tokens do CLIP (75 utilizáveis) e chunks de 75 tokens da SD WebUI.
• Embeddings posicionais existem, mas a regra "tokens anteriores mais fortes" é heurística, não um gradiente documentado.
• Sintaxe de ênfase (() e (token:weight)) modifica o tensor de condicionamento após a codificação CLIP.
• SDXL usa dois CLIPs para semântica mais ampla; Flux adiciona T5 para contexto mais longo e outra tokenização (SentencePiece).
• Prompts de iluminação (back lighting, rim lighting, volumetric lighting, etc.) funcionam melhor com fontes de luz explícitas.

O que o codificador de texto recebe de fato

Quando você digita um prompt, SD 1.5, SDXL e Flux primeiro tokenizam o texto em IDs inteiros. As três usam BPE, mas os detalhes divergem:

Família de modelo | Codificador(es) de texto | Tokenização | Prompt máximo ---|---|---|--- SD 1.5 | CLIP-ViT/L | BPE | 75 tokens SDXL | CLIP-ViT/L + OpenCLIP-ViT/G | BPE (ambos) | 75 cada, concatenados Flux | CLIP-ViT/L + T5-XXL | BPE + SentencePiece | 75 (CLIP) + configurável (T5)

O codificador CLIP-ViT/L do SD 1.5 e SDXL tem comprimento de contexto fixo de 77 tokens (início/fim inclusos), deixando 75 tokens para o conteúdo real do prompt. A SD WebUI divide prompts mais longos que 75 tokens em chunks de 75 tokens, cada um processado de forma independente pelo CLIP e depois concatenado antes de chegar à UNet. Tokens perto das fronteiras de chunk perdem atenção entre chunks; a palavra-chave BREAK força uma fronteira em uma posição específica. A crença "tokens iniciais mais fortes" é em parte efeito colateral do chunking.

Fontes: repositório CLIP clip.tokenize(context_length=77); wiki Features da SD WebUI.

Para os vocabulários específicos de modelo construídos sobre essas mecânicas, veja nossos guias de tags de qualidade Pony e Illustrious e prompts negativos por família de modelo.

Por que a ordem dos tokens importa

Guias da comunidade afirmam: "Tokens no início têm mais peso." O mecanismo é mais sutil:

Embeddings posicionais ≠ gradiente de força

O CLIP adiciona embeddings posicionais aprendidos a cada token. Eles codificam a posição absoluta (0–76) para o transformer saber a ordem dos tokens. Porém, a self-attention do CLIP é full bidirecional — todo token atende a todos os outros dentro do chunk. Não há decaimento fixo em que posição 0 > posição 74.

O que cria efeitos dependentes de posição:

1. Fronteiras de chunk — tokens nas posições 74–75 não podem atender a tokens no chunk seguinte
2. Padrões de atenção aprendidos — o pré-treinamento contrastivo pode pesar mais certas posições sintáticas
3. Hábitos de construção de prompt — usuários naturalmente colocam o sujeito primeiro

Status: não verificado. Nenhuma documentação oficial confirma um gradiente simples de força posicional.

Fontes: Features da SD WebUI (chunking); paper CLIP arXiv:2103.00020.

Sintaxe de ênfase: o que () e (token:weight) realmente fazem

A sintaxe de parênteses e peso numérico é recurso da SD WebUI, não do CLIP. Ela atua depois do codificador de texto.

Como funciona

1. O CLIP tokeniza e codifica o prompt → produz um tensor de condicionamento
2. O parser de prompt da WebUI detecta os padrões (token:weight)
3. O parser multiplica os vetores de embedding daqueles tokens por weight
4. O tensor modificado vai para as camadas de cross-attention da UNet

Sintaxe | Efeito | Faixa de peso ---|---|--- (word) | ênfase 1,1× | implícito (word:1.3) | ênfase 1,3× | típico 0,5–1,5 [word] | desênfase 0,909× | implícito (word:0.7) | desênfase 0,7× | explícito

Fonte: prompt_parser.py define round_bracket_multiplier = 1.1 e square_bracket_multiplier = 1 / 1.1.

Limites práticos

Testes da comunidade (evakenshin, DreamShaper 6/7) relatam que pesos acima de ~1,5 costumam distorcer rostos. Modelos diferentes toleram faixas diferentes.

Fonte: evakenshin, "我权重开到了1.5倍...容易脸崩" (artigo Civitai 1372).

SDXL: por que dois CLIPs?

SDXL concatena as saídas de dois codificadores de texto treinados independentemente:

1. CLIP-ViT/L (OpenAI) — contexto de 77 tokens, BPE
2. OpenCLIP-ViT/G (LAION) — contexto de 77 tokens, BPE

A UNet recebe um tensor de condicionamento de forma (batch, 77, 2×hidden_dim). O modelo refiner usa apenas OpenCLIP-ViT/G. Cada codificador captura nuances semânticas diferentes, então engenharia de prompt que funciona em um pode não otimizar o outro.

Fontes: card do modelo SDXL; README generative-models da Stability AI.

Com o prompt definido, as escolhas de sampler e CFG decidem o quanto ele se materializa — coberto em samplers e schedulers.

Flux: CLIP + T5 muda o jogo

Flux substitui o dual-CLIP por CLIP-ViT/L + T5-XXL. Diferenças-chave:

Propriedade | CLIP (Flux) | T5 (Flux) ---|---|--- Tokenização | BPE | SentencePiece Máximo de tokens | 77 | Configurável Força | Alinhamento visual-semântico | Compreensão de linguagem, contexto longo

A classe HFEmbedder roteia para CLIP ou T5 conforme a versão do modelo. Prompts do Flux podem ser muito mais longos que 77 tokens, mas a tokenização difere — não dá para copiar e colar prompts do SD e esperar alinhamento idêntico de tokens.

Fonte: Flux conditioner.py, classe HFEmbedder.

Prompt | Efeito | Notas ---|---|--- back lighting / rim lighting | Separação do sujeito, brilho de borda | Peso ~1,2–1,5; >1,5 pode distorcer rostos volumetric lighting | Feixes de luz atmosféricos | Melhor com fonte de luz visível dimly lit / dark atmosphere | Cenas noturnas/moadas | Vira low-key instantaneamente crepuscular rays / god rays | Raios de sol dramáticos | Exige sunlight ou fonte explícita side lighting / oblique lighting | Forma 3D, textura | 45°–90° da câmera

Princípio-chave: todo efeito de luz exige uma fonte de luz; adicionar prompts de objeto-fonte de luz produz melhores resultados.

Fonte: artigo Civitai 1372 (DreamShaper 6/7, SD 1.5).

Erros comuns e correções

Sintoma | Causa provável | Correção ---|---|--- Prompt parece ignorado após ~75 tokens | Fronteira de chunk separa sujeito dos modificadores | Use BREAK para controlar o chunking; mantenha sujeito + modificadores-chave nos primeiros 75 tokens Rostos distorcem com pesos de ênfase altos | (token:>1.5) amplifica as normas do embedding | Limite pesos a 1,3–1,4; use múltiplos pesos moderados Prompts de iluminação não fazem nada | Nenhum objeto-fonte de luz na cena | Adicione sunlight, lamp, neon sign, window light Flux ignora (token:weight) | Sintaxe não suportada no pipeline do Flux | Use ênfase em linguagem natural; teste o nó CLIPTextEncode do ComfyUI Prompt SDXL se comporta diferente do SD 1.5 | Concatenação dos dois encoders muda o equilíbrio | Teste prompts em ambos; ajuste a ponderação por encoder

FAQ

Por que mover tokens muda a imagem no Stable Diffusion?

A ordem dos tokens afeta os embeddings posicionais e, além de 75 tokens, em qual chunk um token cai. Dentro de um chunk, a self-attention full permite que todo token influencie todos os outros — mas os padrões de atenção aprendidos podem favorecer certas posições sintáticas. O efeito é real, mas não é uma regra simples "mais cedo = mais forte".

A ordem do prompt importa no SDXL vs SD 1.5?

O comportamento de chunking é idêntico (ambos usam CLIP-ViT/L com chunks de 75 tokens). SDXL adiciona um segundo codificador (OpenCLIP-ViT/G) que processa os mesmos tokens de forma independente. Efeitos de ordem existem em ambos, mas a concatenação dos dois encoders pode amplificar ou enfraquecê-los de forma imprevisível.

Qual codificador de texto o Flux usa para prompting?

O Flux usa dois codificadores simultaneamente: CLIP-ViT/L (OpenAI, BPE, 77 tokens) e T5-XXL (Google, SentencePiece, comprimento configurável). Ambos condicionam o modelo; o T5 cuida de descrições mais longas e complexas.

Por que alguns tokens são ignorados em prompts longos do Stable Diffusion?

Prompts acima de 75 tokens são divididos em chunks. Tokens nas fronteiras de chunk perdem atenção entre chunks. Tokens em chunks posteriores afetam a UNet apenas pelo embedding concatenado — eles nunca "veem" tokens em chunks anteriores durante a codificação CLIP.

Como o limite de 75 tokens do CLIP afeta meus prompts?

Planeje seus primeiros 75 tokens para conter o sujeito, modificadores de estilo-chave e tokens críticos de iluminação/composição. Use BREAK para forçar uma fronteira de chunk e controlar o chunking. A SD WebUI suporta prompts além de 150 tokens (três ou mais chunks) sem truncamento.

Posso usar a sintaxe (token:weight) no Flux?

Não confirmado. A sintaxe é implementada em prompt_parser.py da SD WebUI. O Flux usa outro stack de inferência (BFL/ComfyUI). Teste no seu fluxo; não assuma que funciona.

Qual a diferença entre rim lighting e back lighting?

Ambos criam separação de borda. rim lighting enfatiza um contorno fino e brilhante; back lighting coloca a fonte de luz atrás do sujeito, criando muitas vezes uma silhueta com brilho de borda. Use ambos com pesos moderados (1,1–1,3) para separação mais forte.