Pourquoi LTX 2.3
n'est pas Stable Diffusion
Tu connais Stable Diffusion — ou tu l'as utilisé. LTX 2.3 génère aussi des pixels, mais il "pense" différemment. Ce cours explique l'architecture de façon visuelle, sans formules mathématiques. Objectif : comprendre pourquoi les règles de ComfyUI (frames, résolution, conditioning) viennent directement de l'architecture.
Qu'est-ce que la diffusion ?
Tous les modèles qu'on utilise — SD, LTX, WAN, Flux — sont des modèles de diffusion. Le principe est le même pour tous : on apprend à retirer du bruit d'une image.
Pendant l'entraînement, on prend des millions d'images, on leur ajoute du bruit aléatoire (comme des parasites TV), et on apprend au modèle à prédire quel bruit a été ajouté. À la génération, on part de bruit pur et on l'enlève progressivement, guidé par le prompt.
L'architecture U-Net — Stable Diffusion
SD 1.5, SDXL, ControlNet, la plupart des modèles image connus jusqu'en 2023 utilisent un U-Net comme prédicteur de bruit. Le "U" décrit littéralement la forme du réseau : il va d'abord vers le bas (en comprimant), puis remonte.
Les skip connections (flèches pointillées teal) sont la clé du U-Net : elles copient les informations spatiales des couches d'encodage vers les couches de décodage correspondantes. Résultat : le modèle peut travailler avec des représentations compressées (donc rapides) tout en conservant les détails.
Le texte arrive via cross-attention au niveau du goulot — c'est là que le prompt guide la génération. Cette architecture est très efficace pour les images fixes, mais traiter la vidéo demande de l'empiler sur la dimension temporelle de façon "artisanale".
L'architecture Transformer — LTX, WAN, Flux
Le Transformer vient à l'origine du traitement du langage (GPT, BERT…). L'idée : une phrase est une séquence de mots, et chaque mot peut influencer n'importe quel autre mot. LTX applique la même logique à la vidéo — une vidéo est une séquence de "tokens visuels" et chaque token peut influencer n'importe quel autre.
La différence fondamentale : dans un U-Net, la frame 1 et la frame 40 de ta vidéo ne "se parlent" que de façon indirecte, après plusieurs couches. Dans un Transformer, chaque token voit tous les autres à chaque bloc — la frame 40 influence la frame 1 dès la première couche.
C'est pourquoi LTX maintient une cohérence temporelle bien plus naturelle sur de longues séquences : le modèle n'a pas besoin de "mémoriser" les frames précédentes — elles sont toutes présentes simultanément dans le calcul d'attention.
- Traitement local (convolutions 3×3)
- Context progressif — les infos "remontent" couche par couche
- Temps = dimension ajoutée après coup
- Plus rapide sur petites résolutions
- Architecture optimisée pour l'image fixe
- Traitement global (attention sur tous les tokens)
- Chaque token voit tout en même temps
- Temps = dimension native (tokens temporels)
- Scalable — plus de tokens = plus de calcul, mais cohérence accrue
- Architecture unifiée vidéo + audio naturellement
Un token — voir l'image comme des mots
Pour qu'un Transformer puisse traiter une image, il faut la découper en morceaux discrets — les tokens. C'est la patchification : l'image est découpée en petits carrés (patches), et chaque patch devient un vecteur de nombres — un token.
Pour la vidéo, les tokens s'empilent sur la dimension temporelle. 81 frames de tokens deviennent une longue séquence que le Transformer traite d'un seul tenant. C'est l'origine de la règle 8n+1 : le VAE de LTX compresse 8 frames en 1 token temporel, donc le nombre de frames doit être un multiple de 8, plus 1 pour la frame initiale.
Multimodal — vidéo et audio dans le même espace
LTX 2.3 (Lightricks) va plus loin que la plupart des modèles vidéo : il traite la vidéo et l'audio dans le même espace latent. L'audio n'est pas ajouté après coup — il est tokenisé comme les frames visuelles et entre dans les mêmes blocs d'attention.
Concrètement, le modèle apprend que "le son d'une vague qui se brise" et "les pixels d'eau à ce moment" sont liés — sans qu'on ait besoin de le lui expliquer. Cette synchronisation émergente est ce qui rend LTX 2.3 différent des modèles qui ajoutent l'audio en post-processing.
Les règles ComfyUI viennent de l'architecture
Maintenant que tu comprends l'architecture, les "règles" de LTX ne sont plus arbitraires — elles découlent directement de la façon dont le modèle tokenise les données.
| Règle | D'où ça vient | Ce que ça signifie |
|---|---|---|
| 8n+1 frames | VAE temporel | Le VAE compresse 8 frames en 1 latent temporel. +1 pour la frame initiale (anchor). Valeurs valides : 17, 25, 33, 41, 49, 57, 65, 73, 81. |
| ÷32 résolution | Taille des patches | Chaque patch fait 32×32 pixels. La résolution doit être divisible par 32 pour que la grille de patches soit entière. 720 → invalide → arrondi à 704 ou 736. |
| Pas de --lowvram | DynamicVRAM (Blackwell) | L'attention globale du Transformer a besoin de tout le contexte simultanément. La RTX 5090 gère ça automatiquement via comfy-aimdo — les flags manuels cassent le mécanisme. |
| mxfp8 > bf16 | Architecture Blackwell | Les blocs d'attention ont beaucoup de multiplications matricielles. Le format mxfp8 (microscaling float 8-bit) est optimisé hardware sur Blackwell pour exactement ce type de calcul. |
| Gemma text encoder | Architecture multimodale | LTX 2.3 utilise Gemma (Google) comme encodeur de texte — plus puissant que CLIP pour décrire les relations temporelles ("d'abord X, puis Y") et les nuances sonores. |
| Pas de CLIP vision | Architecture DiT pure | Les Transformers vidéo modernes n'utilisent pas CLIP pour le conditioning image — ils tokenisent l'image directement dans le même espace que la vidéo. CLIP n'est plus dans la boucle. |
Vidéos recommandées
Ces vidéos expliquent les briques de base avec des visuels interactifs. Regarde-les dans cet ordre si tu pars de zéro.
