Un modèle vidéo de 22 milliards de paramètres tourne sur une RTX 3080 avec 10 Go de mémoire

Le propriétaire d'une RTX 3080 avec 10 Go de VRAM a fait tourner chez lui le modèle vidéo LTX-2.5, qui compte 22 milliards de paramètres, c'est-à-dire 22 milliards de valeurs numériques apprises, les poids. Le transformer seul, cœur du modèle, occupe 39 Go, et l'encodeur de texte Gemma en ajoute 24,5. Sur le papier, cet ensemble ne tient pas dans une carte de 10 Go. En pratique, il fonctionne, mais au prix de beaucoup de RAM, de temps et de bricolage avec l'environnement. L'auteur présente toutes les mesures de temps de l'article comme des observations préliminaires, et non comme un benchmark reproductible.

Comment 65 Go de poids passent par 10 Go de VRAM

L'auteur assemble des vidéos verticales de 6 à 8 plans. Plusieurs modèles se relaient sur le même ordinateur :

• Gemma, via llama.cpp, aide à écrire le scénario ; • FLUX.2 [klein] dessine les images avec le même visage pour le héros ; • LTX-2.5 anime les images ; • Qwen3-TTS fait la voix off ; • ACE-Step compose la musique ; • ffmpeg assemble le montage.

LTX reçoit une image finie et la transforme en un court plan vidéo. L'auteur utilise la version distilled, c'est-à-dire simplifiée et plus rapide. La génération se déroule en deux étapes. D'abord, 8 pas de débruitage (nettoyage progressif de l'image) en basse résolution, à environ 1,4 s par pas. Ensuite, un upscaler latent double la taille du résultat. Viennent enfin 3 pas supplémentaires en pleine résolution 576×1024, à 5 s par pas.

L'ensemble tient en mémoire grâce à deux options du dépôt Lightricks/LTX-2 :

• --quantization fp8-cast : les poids sont stockés en bf16 et convertis en fp8 au chargement sur le GPU. Il faut deux fois moins de mémoire, et aucun checkpoint fp8 séparé n'est nécessaire. • --offload cpu : les blocs du transformer résident en RAM et sont envoyés un à un à la carte graphique, au fil du calcul. • La variable PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True supprime les erreurs de manque de mémoire dues à la fragmentation sur les longs plans.

La mémoire ne disparaît pas pour autant : elle se déplace. Il faut au minimum 32 Go de RAM, 64 Go de préférence, et un fichier d'échange d'au moins 32 Go. Dire que le modèle « tourne sur 10 Go » sans ces précisions est trompeur.

Deux écueils : safetensors sous

Windows et la mémoire qui ne se libère pas

Le premier lancement n'a même pas atteint la génération. Il s'est terminé par une access violation (accès mémoire illégal) à l'ouverture des poids, sans message clair. Dans l'environnement de l'auteur, la cause tenait à la lecture des gros fichiers au format safetensors sous Windows. La bibliothèque tentait de mapper tout le fichier en mémoire et plantait sur les fichiers de plus de 2 Go environ.

Il a contourné le problème en remplaçant la fonction safe_open. À la place de la lecture standard, un np.memmap en lecture seule prend le relais. L'en-tête du fichier est analysé à la main, et les tenseurs sont renvoyés comme des vues sur le fichier mappé. Aucune copie séparée des poids n'occupe la mémoire commit, l'interface reste la même et le code de LTX n'a pas eu besoin d'être modifié. Le patch se trouve dans site-packages, et un fichier .pth contenant import ltx_sft_patch remplace le module au démarrage de l'interpréteur.

Le second problème concerne le déchargement des modèles. Au départ, chaque modèle vivait dans un processus worker permanent : il faisait son travail, on appelait unload, puis la carte passait au modèle suivant. Mais avec le CPU offload, après un tel déchargement, une partie de la VRAM et de la RAM épinglée (pinned) restait occupée, et le modèle suivant ne tenait plus. Seule la fin complète du processus fonctionnait de façon fiable. Désormais, chaque modèle a son propre processus et son propre venv, et pour LTX, un processus est lancé à chaque plan. Les environnements séparés règlent aussi un autre problème : les modèles exigent des versions incompatibles de torch et de diffusers.

Cinq minutes par plan, 25 secondes de calcul

Ces redémarrages de processus ont un coût. D'après les mesures préliminaires, un plan prend environ cinq minutes, dont environ 25 secondes de débruitage, soit moins de 10 % du temps. Le reste sert à lire et à préparer les quelque 65 Go de poids du transformer et de l'encodeur Gemma. Cette opération se répète à chaque plan.

Enseignements pour ceux qui montent un pipeline similaire :

• Le goulot d'étranglement est ici le disque et la RAM, pas le GPU. Avant d'acheter une carte graphique plus rapide, mieux vaut mesurer la vitesse de chargement des poids et la consommation de mémoire. • Une vidéo de six plans s'assemble en une demi-heure environ, une vidéo courte en quelques minutes. • La prochaine étape d'optimisation consisterait à garder l'encodeur et le transformer en mémoire entre les plans. L'auteur n'a pas encore testé cette option. Elle ramènerait le problème de libération de la mémoire pour les autres modèles.

L'auteur partage par ailleurs ses astuces pour obtenir un mouvement exploitable :

• L'image de départ doit montrer l'état avant l'action. Si la porte est déjà ouverte alors que le prompt demande de l'ouvrir, le modèle se met à inventer ce qui se passe. • Le contact des mains avec les objets se découpe en deux plans.

Dans le premier, la main se tend vers la poignée ; après la coupe, la porte est déjà ouverte. Le moment où les doigts traversent la poignée reste hors champ. • Si la fin du mouvement compte, la dernière image est passée comme second paramètre --image.

• Pour la synchronisation labiale (lipsync), il faut un autre schéma : le modèle complet, non distilled, la LoRA distilled et la branche audio a2vid_two_stage. Du résultat, on ne garde que la vidéo ; le son reste celui de la voix off.

En résumé, un modèle vidéo de 22 milliards de paramètres sur une carte domestique de 10 Go donne un résultat exploitable pour de courtes vidéos. Tout se fait en local, sans cloud ni abonnement. Les limites sont connues : beaucoup de RAM, un long chargement des poids à chaque plan et des environnements séparés pour chaque modèle.