Fundamentos del prompting que se transfieren entre modelos
Lo que recibe el codificador de texto, por qué importa el orden de los tokens y qué hábitos de prompting sobreviven en SD, SDXL y Flux.
On this page
Fundamentos del prompting que se transfieren entre modelos
TL;DR
- La tokenización es BPE con la ventana de 77 tokens de CLIP (75 utilizables) y fragmentos de 75 tokens de SD WebUI.
- Existen insertos posicionales, pero la regla de «los tokens anteriores tienen más peso» es una heurística, no un gradiente documentado.
- La sintaxis de énfasis (
()y(token:weight)) modifica el tensor de condicionamiento después de la codificación CLIP. - SDXL usa dos CLIP para semántica más amplia; Flux añade T5 para contexto más largo y diferente tokenización (SentencePiece).
- Los prompts de iluminación (
back lighting,rim lighting,volumetric lighting, etc.) funcionan mejor con fuentes de luz explícitas.
Qué recibe realmente el codificador de texto
Cuando escribes un prompt, SD 1.5, SDXL y Flux primero tokenizan tu texto en IDs enteros. Los tres usan BPE, pero los detalles divergen:
Familia de modelo | Codificador(es) de texto | Tokenización | 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) + configurable (T5)
El codificador CLIP-ViT/L de SD 1.5 y SDXL tiene una longitud de contexto fija de 77 tokens (inicio y fin incluidos), dejando 75 tokens para el contenido real del prompt. SD WebUI divide prompts más largos de 75 tokens en fragmentos de 75 tokens, cada uno procesado de forma independiente a través de CLIP, luego concatenados antes de llegar a la UNet. Los tokens cerca de los límites de los fragmentos pierden atención entre fragmentos; la palabra clave BREAK fuerza un límite en una posición específica. La creencia de «los tokens anteriores son más fuertes» es en parte un efecto secundario de la división en fragmentos.
Fuentes: repositorio CLIP clip.tokenize(context_length=77); wiki Features de SD WebUI.
Para los vocabularios específicos de cada modelo construidos sobre estas mecánicas, consulta nuestras guías de Pony and Illustrious quality tags y negative prompts per model family.
Por qué importa el orden de los tokens
Las guías de la comunidad afirman: «Los tokens al principio tienen más peso». El mecanismo es más matizado:
Insertos posicionales ≠ gradiente de fuerza
CLIP añade insertos posicionales aprendidos a cada token. Estos codifican la posición absoluta (0–76) para que el transformador conozca el orden de los tokens. Sin embargo, la autoatención de CLIP es completamente bidireccional — cada token atiende a todos los demás dentro de su fragmento. No hay un decaimiento codificado donde la posición 0 > la posición 74.
Lo que sí crea efectos dependientes de la posición:
- Límites de fragmentos — los tokens en las posiciones 74–75 no pueden atender a tokens en el siguiente fragmento
- Patrones de atención aprendidos — el pre-entrenamiento contrastivo puede ponderar ciertas posiciones sintácticas más intensamente
- Hábitos de construcción de prompts — los usuarios ponen el sujeto primero de forma natural
Estado: no verificado. Ninguna documentación oficial confirma un simple gradiente de fuerza posicional.
Fuentes: Features de SD WebUI (fragmentación); artículo CLIP arXiv:2103.00020.
Sintaxis de énfasis: lo que () y (token:weight) realmente hacen
Los paréntesis y la sintaxis de peso numérico son características de SD WebUI, no de CLIP. Operan después del codificador de texto.
Cómo funciona
- CLIP tokeniza y codifica tu prompt → produce un tensor de condicionamiento
- El analizador de prompts de la WebUI detecta patrones
(token:weight) - El analizador multiplica los vectores de inserción de esos tokens por
weight - El tensor modificado va a las capas de atención cruzada de la UNet
Sintaxis | Efecto | Rango de peso
|---|---|---
(word) | énfasis 1,1× | implícito (word:1.3) | énfasis 1,3× | típico 0,5–1,5 [word] | deénfasis 0,909× | implícito (word:0.7) | deénfasis 0,7× | explícito
Fuente: prompt_parser.py define round_bracket_multiplier = 1.1 y square_bracket_multiplier = 1 / 1.1.
Límites prácticos
Las pruebas comunitarias (evakenshin, DreamShaper 6/7) reportan que los pesos superiores a ~1,5 distorsionan rostros con frecuencia. Diferentes modelos toleran rangos diferentes.
Fuente: evakenshin, «我权重开到了1.5倍...容易脸崩» (artículo de Civitai 1372).
El codificador dual de SDXL: ¿por qué dos CLIP?
SDXL concatena las salidas de dos codificadores de texto entrenados de forma independiente:
- CLIP-ViT/L (OpenAI) — contexto de 77 tokens, BPE
- OpenCLIP-ViT/G (LAION) — contexto de 77 tokens, BPE
La UNet recibe un tensor de condicionamiento de forma (batch, 77, 2×hidden_dim). El modelo refiner usa solo OpenCLIP-ViT/G. Cada codificador captura matices semánticos diferentes, por lo que la ingeniería de prompts que funciona para uno puede no optimizar el otro.
Fuentes: tarjeta del modelo SDXL; README generative-models de Stability AI.
Una vez definido el prompt, las opciones del muestreador y el CFG deciden qué tan fielmente se materializa — cubierto en samplers and schedulers.
Flux: CLIP + T5 cambia el juego
Flux reemplaza el doble CLIP con CLIP-ViT/L + T5-XXL. Diferencias clave:
Propiedad | CLIP (Flux) | T5 (Flux)
|---|---|---
Tokenización | BPE | SentencePiece Tokens máximos | 77 | Configurable Fortaleza | alineación visual-semántica | comprensión del lenguaje, contexto largo
La clase HFEmbedder enruta a CLIP o T5 según la versión del modelo. Los prompts de Flux pueden ser mucho más largos de 77 tokens, pero la tokenización difiere — no puedes copiar y pegar prompts de SD y esperar una alineación de tokens idéntica.
Fuente: conditioner.py de Flux, clase HFEmbedder.
Prompt | Efecto | Notas
|---|---|---
back lighting / rim lighting | Separación del sujeto, brillo en el borde | Peso ~1,2–1,5; >1,5 puede distorsionar rostros volumetric lighting | Hazos de luz atmosféricos | Mejor con fuente de luz visible dimly lit / dark atmosphere | Escenas nocturnas/melancólicas | Cambia instantáneamente a bajo contraste crepuscular rays / god rays | Rayos solares dramáticos | Requiere sunlight o fuente explícita side lighting / oblique lighting | Forma 3D, textura | 45°–90° desde la cámara
Principio clave: cualquier efecto de luz requiere una fuente de luz; añadir objetos de fuente de luz en el prompt produce mejores resultados.
Fuente: artículo de Civitai 1372 (DreamShaper 6/7, SD 1.5).
Errores comunes y soluciones
Síntoma | Causa probable | Solución
|---|---|---
El prompt parece ignorado tras ~75 tokens | el límite del fragmento separa al sujeto de los modificadores | usa BREAK para controlar la fragmentación; mantén el sujeto y los modificadores clave en los primeros 75 tokens Los rostros se distorsionan con pesos de énfasis altos | (token:>1.5) amplifica las normas de inserción | limita los pesos a 1,3–1,4; usa varios pesos moderados Los prompts de iluminación no hacen nada | no hay objeto de fuente de luz en la escena | añade sunlight, lamp, neon sign, window light Flux ignora (token:weight) | la sintaxis no es compatible con el pipeline de Flux | usa énfasis en lenguaje natural; prueba el nodo CLIPTextEncode de ComfyUI El prompt de SDXL se comporta diferente que en SD 1.5 | la concatenación del codificador dual cambia el equilibrio | prueba los prompts en ambos; ajusta el peso por codificador
FAQ
¿Por qué mover los tokens cambia la imagen en Stable Diffusion?
El orden de los tokens afecta los insertos posicionales y, tras 75 tokens, en qué fragmento cae cada token. Dentro de un fragmento, la autoatención completa significa que cada token puede influir en todos los demás — pero los patrones de atención aprendidos pueden favorecer ciertas posiciones sintácticas. El efecto es real, pero no una regla simple de «anterior = más fuerte».
¿Importa el orden del prompt en SDXL vs SD 1.5?
El comportamiento de fragmentación es idéntico (ambos usan CLIP-ViT/L con fragmentos de 75 tokens). SDXL añade un segundo codificador (OpenCLIP-ViT/G) que procesa los mismos tokens de forma independiente. Los efectos del orden existen en ambos, pero la concatenación del codificador dual puede amplificarlos o atenuarlos de forma impredecible.
¿Qué codificador de texto usa Flux para prompting?
Flux usa dos codificadores simultáneamente: CLIP-ViT/L (OpenAI, BPE, 77 tokens) y T5-XXL (Google, SentencePiece, longitud configurable). Ambos condicionan al modelo; T5 maneja descripciones más largas y complejas.
¿Por qué algunos tokens son ignorados en prompts largos de Stable Diffusion?
Los prompts que exceden 75 tokens se dividen en fragmentos. Los tokens en los límites de los fragmentos pierden atención entre fragmentos. Los tokens en fragmentos posteriores solo influyen en la UNet a través del inserto concatenado — nunca «ven» los tokens de fragmentos anteriores durante la codificación CLIP.
¿Cómo afecta el límite de 75 tokens de CLIP a mis prompts?
Planea que los primeros 75 tokens contengan el sujeto, los modificadores de estilo clave y los tokens críticos de iluminación/composición. Usa BREAK para forzar un límite de fragmento y controlar la fragmentación. SD WebUI admite prompts de más de 150 tokens (tres o más fragmentos) sin truncamiento.
¿Puedo usar la sintaxis (token:weight) en Flux?
No confirmado. La sintaxis está implementada en prompt_parser.py de SD WebUI. Flux usa una pila de inferencia diferente (BFL/ComfyUI). Prueba en tu flujo de trabajo; no asumas que funciona.
¿Cuál es la diferencia entre rim lighting y back lighting?
Ambos crean separación en el borde. rim lighting enfatiza un contorno brillante y delgado; back lighting coloca la fuente de luz detrás del sujeto, a menudo creando una silueta con brillo en el borde. Usa ambos en pesos moderados (1,1–1,3) para una separación más fuerte.