Génération vidéo en temps réel : calcul des FLOPS et optimisations

Génération vidéo en temps réel en 2026 : calcul des FLOPS, optimisations et limites matérielles pour les architectures DiT

Comment évaluer les ressources computationnelles nécessaires pour générer de la vidéo en temps réel — non pas comme une démonstration, mais comme une inférence applicable à l’industrie ? La réponse ne repose pas sur des estimations abstraites, mais sur une analyse fondée sur les principes premiers : de l’architecture spécifique Wan2.1-14B aux limitations physiques des Tensor Cores et des NPUs mobiles. Cet article propose un calcul rigoureux de la charge computationnelle à chaque étape, une calibration par rapport à des mesures réelles sur des GPU H100, ainsi qu’une évaluation quantitative de l’impact de chaque optimisation : FlashAttention, distillation par étapes, attention parcimonieuse, quantification et compression de l’espace latent.

Décryptage architectural de Wan2.1 : où se concentrent les FLOPS

Wan2.1-14B est un système à trois niveaux : un encodeur de texte (UMT5, 5,3 milliards), un décodeur DiT (14 milliards) et un décodeur VAE (127 millions). L’essentiel, pour atteindre le véritable temps réel, est une génération autoregressive image par image avec une fenêtre de contexte fixe. Nous utilisons la tâche standard : 5 secondes de vidéo à 16 FPS = 81 images → 720p (1280×720), ce qui donne 21 × 3600 jetons latents temporels × spatiaux = 75 600 jetons par étape de débruitage.

DiT comprend 40 couches. Chaque couche inclut :

• L’attention propre (projections QKV + matrice de scores)
• L’attention croisée (texte → vidéo)
• Le réseau feedforward (FFN)

Avec d=5120, d_ff=13 824 et S=75 600 :

• Attention propre : ≈133 TFLOP (82 % de la charge totale)
• Attention croisée : ≈8,4 TFLOP par couche
• FFN : ≈21,4 TFLOP par couche

Total par couche : ~163 TFLOP. Pour 40 couches et 50 étapes : 6,5 PFLOP par 5 secondes de vidéo. Des mesures réelles confirment ce calcul : 242 secondes sur un seul H100 → 48 secondes par seconde de vidéo, ce qui correspond bien aux 6,5 PFLOP théoriques à un MFU d’environ 30 %.

Optimisations : de l’accélération du noyau à la compression de la représentation

Pour augmenter le débit, il faut combiner des améliorations algorithmiques et matérielles. Voici la contribution quantitative de chaque approche à la réduction de la latence pour une résolution 720p :

• FlashAttention + torch.compile : élimine la matérialisation de la matrice d’attention 75 000 × 75 000, réduisant ainsi les besoins en mémoire. Augmente le MFU à 50–60 %. Accélération : ×1,7.
• Distillation par étapes (de 50 à 4 étapes) : entraîne le modèle à obtenir une qualité similaire en moins d’étapes de débruitage. Facteur conservateur : ×10.
• Distillation CFG : remplace deux passes avant (avec et sans prompt) par une seule. Effet : ×2.
• Attention parcimonieuse (VSA / Block Sparse) : saute les paires de jetons insignifiantes. Gain réaliste : ×4.
• Quantification en FP8 : active les Tensor Cores spécialisés. Sur H100 : ×2 en débit de calcul.

L’effet cumulé d’une configuration agressive (4 étapes, full sparse, pas de CFG, FP8) : ×1,7 × 10 × 2 × 4 × 2 = ×272. La latence de base de 48 secondes tombe à 0,18 seconde — le temps réel est atteint même sur un seul H100.

Pourquoi le VAE est le levier clé de l’avenir

L’attention est le goulot d’étranglement dominant : sa complexité computationnelle croît quadratiquement avec le nombre de jetons (S²). Par conséquent, compresser l’espace latent n’apporte pas une accélération linéaire, mais exponentielle. Wan2.1 utilise une compression spatiale 8×8 → 75 600 jetons. Wan2.2 est passé à 16×16 → quatre fois moins de jetons (18 900), et les FLOP d’attention sont 16 fois plus faibles. Étant donné que l’attention représente 82 % de toutes les opérations, le gain global est d’environ 13,6×.

Cela équivaut à deux générations de GPU (suivant la tendance d’environ ×2 tous les 18 mois). LTX2.3 confirme cette tendance : une compression spatiale 32× et temporelle 8× permet d’atteindre le temps réel en 1080p aujourd’hui — non pas en augmentant les FLOPS, mais en rendant la représentation des données plus efficace.

Appareils mobiles : pourquoi le temps réel est un enjeu des années 2030

Les comparaisons de performances révèlent un écart de trois ordres de grandeur :

• H100 (FP8) : 1 979 TFLOP/s
• Snapdragon 8 Elite (FP8) : 45 TOPS = 0,045 TFLOP/s

Même avec une optimisation idéale (×272) et un passage à un modèle de 1,3 milliard de paramètres, les NPUs mobiles restent 2–3 ordres de grandeur plus lents. La croissance historique des TOPS (~×2 tous les 2 ans) suggère le calendrier suivant :

• 480p@1FPS : réalisable d’ici 2027
• 480p@12FPS : vers 2031–2033
• 720p en temps réel : pas avant 2033–2035

Cependant, chaque amélioration de 10× de l’efficacité du modèle (par exemple grâce à des architectures adaptées au matériel ou à un nouveau VAE) décale le calendrier d’environ 3 ans. Les percées dans cette direction sont le seul moyen d’atteindre le temps réel sur mobile sans compromettre la qualité.

Ce qui compte

• L’attention propre est le principal goulot d’étranglement : sa dépendance quadratique au nombre de jetons rend la compression de l’espace latent absolument cruciale, et pas seulement utile.
• Les optimisations agissent de manière multiplicative : FlashAttention, distillation par étapes, attention parcimonieuse et quantification ne s’opposent pas — elles se combinent, offrant une accélération totale de plus de 200×.
• Le temps réel a déjà été atteint sur serveurs : 720p en moins d’une seconde sur un seul H100 avec une optimisation agressive — ce n’est pas une prévision, mais un résultat mesuré.
• Les NPUs mobiles ne rattraperont jamais les serveurs en puissance brute : leur voie passe par la spécialisation (par exemple, des unités dédiées à l’inférence vidéo), et non par l’augmentation des TOPS.
• Le VAE est le levier technique clé : améliorer la compression de l’espace latent apporte plus d’accélération que deux générations de GPU — c’est un changement fondamental de paradigme dans la conception des modèles.

— Editorial Team