LTX-2.5, 22 milliards de paramètres, tourne sur une RTX 3080 de 10 Go, mais met 5 minutes par plan

L'auteur d'une étude publiée sur Habr a fait tourner en local le modèle vidéo LTX-2.5, 22 milliards de paramètres, sur une carte graphique RTX 3080 dotée de 10 Go de mémoire. Le transformer seul pèse 39 Go, et l'encodeur de texte Gemma en occupe 24,5 Go de plus. Le modèle fonctionne sous Windows et s'intègre à un pipeline de vidéos verticales composées de 6 à 8 plans. Mais cette petite quantité de mémoire vidéo a un coût : de la mémoire vive, du temps de chargement et du bricolage d'environnement.

La tâche de l'auteur est concrète : toute une chaîne de modèles s'enchaîne sur un seul ordinateur. Gemma, via llama.cpp, aide à écrire le scénario ; FLUX.2 [klein] dessine les images avec un visage de héros constant ; LTX-2.5 anime ces images. Ensuite, la voix vient de Qwen3-TTS, la musique d'ACE-Step, et le montage est assuré par ffmpeg. LTX reçoit une image toute prête et la transforme en un court plan vidéo.

Comment 39 Go de poids passent par 10 Go de VRAM

L'auteur utilise la version distilled de LTX-2.5, où la vidéo est générée en deux étapes. D'abord, 8 pas de débruitage en basse résolution (environ 1,4 s par pas). Ensuite, un upscaler latent double le résultat, et 3 pas supplémentaires sont exécutés en pleine résolution 576×1024 (environ 5 s par pas). L'auteur présente ces temps comme des observations préliminaires, et non comme un benchmark reproductible.

Dans le pipeline standard de Lightricks/LTX-2, deux options suffisent. Le paramètre --quantization fp8-cast conserve les poids en bf16 et les convertit en fp8 lors du chargement sur le GPU : il faut deux fois moins de mémoire, sans checkpoint fp8 séparé. Le paramètre --offload cpu active le mode streaming : les blocs du transformer résident en RAM et sont envoyés à la carte graphique à tour de rôle. Pour les plans longs, il a aussi fallu la variable PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True ; sans elle, la fragmentation de la mémoire provoquait des OOM.

La mémoire ne disparaît pas pour autant : elle passe de la carte graphique à la RAM. Selon l'estimation de l'auteur, ce montage exige au minimum 32 Go de mémoire vive (64 Go de préférence) et un fichier d'échange d'au moins 32 Go. La formule « tourne avec 10 Go » ne suffit donc pas à décrire la configuration requise.

Deux écueils : safetensors sous

Windows et le déchargement qui ne décharge pas

Le premier lancement s'est soldé par une access violation à l'ouverture des poids, sans message clair. Dans l'environnement de l'auteur, la bibliothèque safetensors tentait de projeter entièrement en mémoire les fichiers de plus de 2 Go environ, et plantait. Le contournement consiste à remplacer safe_open : l'en-tête du fichier est analysé à la main, et les tenseurs sont fournis sous forme de vues sur un np.

memmap en lecture seule. L'interface reste identique, si bien que le pipeline LTX ne remarque rien, et aucune copie distincte des poids ne consomme de commit memory. Le correctif s'applique sans toucher au code tiers : le fichier 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 est apparu lors du travail conjoint des modèles. Au départ, chacun vivait dans un processus worker permanent et était déchargé par un appel à unload après usage. Avec le CPU-offload, une partie de la VRAM et de la RAM verrouillée restait occupée ensuite, et le modèle suivant ne tenait plus. La solution fiable a consisté à terminer le processus entièrement. Désormais, chaque modèle tourne dans son propre processus et son propre venv, et pour LTX, un processus distinct est lancé pour chaque plan. Avantage collatéral : les modèles réclament des versions incompatibles de torch et de diffusers, et les environnements isolés les empêchent de se gêner.

Où le temps passe réellement

Les redémarrages ont un coût. D'après les mesures préliminaires, chaque plan prend environ cinq minutes, dont environ 25 secondes pour le débruitage proprement dit. Cela concorde avec l'arithmétique des pas : 8 fois 1,4 s plus 3 fois 5 s font environ 26 secondes. Le reste du temps est consommé par la lecture et la préparation d'environ 65 Go de poids du transformer et de l'encodeur Gemma, et ce pour chaque plan.

La conclusion pour ceux qui montent un pipeline similaire : avant d'acheter une carte graphique plus rapide, mieux vaut mesurer la vitesse de chargement des poids et l'utilisation de la mémoire. Une vidéo de 6 plans est assemblée en une demi-heure environ ; une vidéo courte, en quelques minutes. L'auteur voit comme prochaine étape de garder l'encodeur et le transformer en mémoire entre les plans, mais cette option reste à vérifier.

Par ailleurs, l'auteur partage des astuces pour contourner les faiblesses du modèle. L'image de départ doit montrer l'état avant l'action : si la porte est déjà ouverte et que le prompt demande de l'ouvrir, le modèle est obligé d'inventer ce qui se passe. Mieux vaut répartir le contact des mains avec les objets sur deux plans : dans le premier, la main se tend ; après le raccord, la porte est déjà ouverte, et le moment délicat reste hors champ.

Si la fin du mouvement est importante, l'image finale peut être transmise via un second --image. Pour la synchronisation labiale, il faut un autre montage : le modèle complet, et non distilled, le distilled-LoRA et la branche audio a2vid_two_stage ; seule la vidéo est conservée du résultat, le son restant celui de la voix off.

En résumé : un modèle de 22 milliards de paramètres sur une carte grand public de 10 Go s'est révélé une option viable pour des vidéos courtes. Tout tourne en local, sans cloud ni abonnement, mais au prix de beaucoup de RAM, d'un chargement long et d'une configuration manuelle de l'environnement.