LTX-2 Local vs Cloud : ComfyUI vs WaveSpeed (Vitesse, Coût & Confidentialité)

Une petite chose m’a poussé à faire cela : une attente de 40 secondes. J’avais lancé un batch dans le cloud LTX-2 et je m’étais absenté pour remplir ma tasse. À mon retour, un job avait échoué avec une erreur vague, et je ne pouvais pas dire si c’était moi, le préréglage, ou le service. Cette petite pause a marqué les esprits. Le lendemain matin, j’ai lancé le même préréglage localement, et il a terminé avant que mon application de messagerie puisse se synchroniser. C’est ce contraste qui est au cœur de cet article : LTX-2 Local vs Cloud, pas comme une liste de fonctionnalités, mais le poids que chacun ajoute, ou supprime, d’une journée ordinaire.

J’ai testé les deux configurations en début janvier 2026 sur mon MacBook Pro 16 pouces (M2 Pro, 32 GB RAM) et une petite machine Ubuntu avec une RTX 4090, aux côtés du cloud LTX-2 dans une région américaine. Votre matériel et votre région changeront les chiffres, mais les compromis se sont alignés de manière familière. Pour plus de détails techniques sur le modèle, consultez l’article de recherche LTX-2.

Tableau de décision rapide (local vs cloud par cas d’usage)

Voici le chemin rapide que j’aurais aimé avoir avant de commencer à basculer d’avant en arrière.

Cas d’usage	Choisissez	Pourquoi c’était justifié
Aperçus simples, boucles de rétroaction serrées	Local	Mise en file d’attente quasi nulle, itération rapide, débogage plus facile des préréglages et des invites.
Grands batches avec des délais fermes	Cloud	Jobs parallèles, meilleur débit, moins de moments de surveillance une fois c’est réglé.
Données sensibles (PII, assets non publiés)	Local	Pas de téléchargement : vous contrôlez la rétention et l’accès par défaut.
Charges de travail imprévisibles (certaines semaines lourdes, d’autres calmes)	Cloud	Payez pour les pics : pas de GPU inactif qui bourdonne sous votre bureau.
Hors ligne ou connexion Internet instable	Local	Évident, mais cela compte dès que le Wi-Fi bafouille.
Partage en équipe et reproductibilité	Cloud	Préréglages centralisés, journaux et permissions réduisent les problèmes de « fonctionnait sur ma machine ».
Opérations expérimentales (builds personnalisés, flags de pointe)	Local	Vous pouvez épingler les versions, tester les branches et revenir en arrière instantanément.

Je ne m’attendais pas à ce que ce soit si équilibré. Mais après une semaine, je me suis retrouvé à faire des aperçus locaux par défaut et à envoyer tout ce qui dépasse 200 éléments au cloud.

Vitesse : matériel local vs débit cloud

Bien sûr, la vitesse s’est présentée de deux manières différentes pour moi.

• Local s’est senti rapide pour les cas isolés. Sur le M2 Pro, un seul job LTX-2 a démarré en ~1–2 secondes et s’est terminé assez rapidement pour que je reste dans le flux. Sur la machine 4090, c’était essentiellement instantané une fois réchauffée.
• Cloud a semblé constant pour le volume. Le premier job attendait parfois 5–15 secondes en file d’attente, mais 50 jobs parallèles ont lissé cela. Le débit a gagné sur la latence.

Une petite note du terrain : les démarrages à froid comptent plus que nous l’admettons. Les caches locaux, des poids aux fichiers intermédiaires, ont rendu les exécutions répétées plus légères. Je ne l’ai remarqué que quand j’ai vidé un cache et soudain tout s’est ralenti. Dans le cloud, je ne contrôlais pas cette couche, j’ai donc accepté la petite taxe de démarrage en échange de l’échelle.

Ce qui m’a surpris : mon aperçu simple le plus rapide a toujours été local. Mon heure la plus rapide pour 1 000 éléments a toujours été cloud. Le point de basculement était d’environ 150–250 éléments pour moi. Au-delà, taper une commande et laisser le service se déployer sauvegardait l’après-midi. En dessous, lancer un job local m’a tenu dans le travail.

Coût : électricité + dépréciation vs crédits

J’ai essayé de fixer le prix comme un comptable calme, pas comme un partisan du battage publicitaire.

Le coût local ressemble à ceci :

• Matériel initial (ou location mensuelle)
• Électricité (ma machine 4090 au repos consommait ~90W et ~420W sous charge)
• Dépréciation et maintenance (ventilateurs, stockage, le lapin CUDA occasionnel)

Le coût cloud ressemble à ceci :

• Crédits par job ou par token
• Possible sortie/stockage si vous conservez les assets
• Suppléments quand les batches montent en flèche

Deux petits croquis de mes notes :

• Batch de 200 éléments, chaque job ~1 minute : Local a pris ~220 minutes en temps réel sur mon Mac (pas de GPU), essentiellement gratuit sauf l’électricité. Cloud l’a dévoré en ~8–12 minutes avec le parallélisme, à un coût en crédits facile à justifier la semaine où j’avais une date limite. Plus de conseils d’implémentation sont disponibles sur GitHub.
• Flux continu (20–30 éléments/jour) : Local a gagné. Garder la machine prête signifiait que j’ai absorbé le coût une fois. Les crédits cloud ont ajouté un petit coût cognitif chaque fois que j’ai appuyé sur exécuter. Pas cher, juste présent.

Je ne pense pas qu’il y ait un « moins cher » unique. Si vous possédez déjà du matériel capable et que vos charges de travail sont stables, local est doux pour le portefeuille. Si votre volume est imprévisible, payer la capacité de pic bat posséder un radiateur avec ventilateurs. J’ai eu un mois où local était presque gratuit et un autre où cloud était clairement plus intelligent.

Confidentialité : rétention des données et permissions d’équipe

Cette partie était simple pour moi. Si c’est sensible, je lance LTX-2 localement. Pas parce que je ne fais pas confiance au cloud, mais parce que je peux rendre compte de l’endroit où les fichiers se trouvent.

Local :

• Pas de téléchargement. Les artefacts restent sur mon disque ou mon partage réseau.
• Je peux m’aligner avec mes propres règles de rétention : purge automatique après X jours, chiffrement au repos, et c’est fini.

Cloud :

• Meilleures contrôles d’équipe dès le départ : rôles, limites de projet et journaux qui ne dépendent pas de ma mémoire.
• La rétention est basée sur la politique. C’est bien, mais c’est toujours un accord avec un fournisseur. Lisez la documentation et confirmez les défauts : certains services conservent les journaux et les artefacts plus longtemps que prévu.

Pour la collaboration au sein d’une petite équipe, le cloud a semblé plus sûr, non pas dans le sens de la confidentialité, mais dans le sens de « nous ne perdrons pas le préréglage canonique ». Pour tout ce qui contient des assets non publiés ou des PII, local m’a rassuré. Les deux peuvent être bien faits. Pour les poids ouverts généraux et les benchmarks, vous pouvez consulter Papers With Code.

Stabilité : mises à jour des dépendances et plantages de nœuds

J’ai perdu un après-midi à une mise à jour de pilote. C’est la partie honnête de l’exécution locale. Quand ça marche, c’est super. Quand une dépendance change et une autre reste en arrière, vous êtes le SRE.

Notes de terrain sur la stabilité locale :

• Épinglez tout ce que vous pouvez. Conteneurs, fichiers env, même les mises à jour du système d’exploitation si vous le devez.
• Gardez une liste de préréglages et de versions « connue pour fonctionner ». Je garde un court fichier texte à côté du projet avec le hash de commit et les flags clés.
• Attendez-vous au crash occasionnel sous les batches lourds. C’est rarement catastrophique, mais cela casse le flux.

Notes de terrain sur la stabilité cloud :

• Moins de surprises : plus de boîtes noires. Les jobs se terminent généralement, et s’ils ne le font pas, les messages d’erreur sont parfois plus polis que utiles.
• Les mises à jour des fournisseurs arrivent sans cérémonie. Sympa quand cela améliore la vitesse : ennuyeux quand un changement décale les sorties.

Aucun n’est parfaitement calme. Local vous donne des leviers et des tâches supplémentaires. Cloud vous donne moins de leviers et moins de tâches. Je choisissez en fonction du type d’interruption que je suis prêt à avoir cette semaine.

Meilleure approche hybride (aperçu local + batch cloud)

Ce qui s’est finalement cristallisé pour moi était un simple rythme :

• Rédiger et apercevoir localement. Je garde un petit ensemble d’échantillons, 10–20 éléments, qui reflètent les cas limites. J’itère jusqu’à ce que les sorties ressemblent correctement deux fois de suite, pas une seule.
• Batch dans le cloud. J’exporte le préréglage exact et l’exécute avec un nom de job horodaté. Je regarde les 5 % premiers journaux, puis je m’en vais.

Pourquoi cela a semblé juste :

• Les aperçus locaux maintiennent la latence près de zéro. Je peux ajuster les invites, les poids ou les paramètres sans changement de contexte.
• Les batches cloud maintiennent ma machine libre. Je peux continuer à écrire, ou je peux fermer l’ordinateur portable et aller dehors.

Deux petits tours qui ont aidé :

• J’ai corrigé mon « ensemble de prévisualisation ». Au début, j’avais l’habitude de permuter les entrées et de perdre de vue ce qui a changé. Avec un ensemble fixe, je sais que les améliorations sont réelles.
• Je fais un snapshot des préréglages avant chaque grande exécution. Même une mise à jour mineure de version peut légèrement modifier les sorties : les snapshots rendent les différences évidentes.

Sur les semaines avec moins de jobs, je garde parfois tout localement, en particulier si je suis hors ligne ou en voyage. Sur les semaines de production, je ne me bats pas contre le cloud. Le but de LTX-2 Local vs Cloud n’est pas la loyauté, c’est choisir l’environnement qui réduit les frictions pour le travail devant vous. C’est pourquoi nous avons créé WaveSpeed — pour gérer les aperçus locaux et les exécutions de batches cloud sans surveiller les files d’attente. C’est ce que notre équipe utilise chaque jour.

Liste de contrôle de migration (transfert de flux de travail / préréglage)

Le passage entre LTX-2 local et le cloud était plus fluide une fois que j’avais écrit les étapes. C’est la liste de contrôle que j’utilise maintenant. C’est ennuyeux, c’est pourquoi ça marche.

Parité des préréglages

• Exportez/importez le préréglage au lieu de copier manuellement. Si une exportation directe n’est pas disponible, stockez les préréglages dans le contrôle de version sous forme de JSON/YAML.
• Épinglez les versions. Notez l’ID du modèle/build, les versions d’extension, et les flags pertinents.
• Enregistrez les paramètres de graine/aléatoire si le déterminisme importe.

Chemins des assets

• Normalisez les chemins. Les chemins absolus locaux n’existeront pas dans le cloud : utilisez des chemins relatifs ou pré-téléchargez les assets vers un bucket ou dossier de projet connu.
• Confirmez les codecs et formats. Une inadéquation ici casse les pipelines silencieusement.

Environnement

• Documentez les variables d’environnement et les secrets séparément. Ne cuites jamais les secrets dans les préréglages.
• Alignez les suppositions matérielles. Si votre préréglage local s’attend à un certain encombrement de mémoire, testez d’abord un lot plus petit dans le cloud.

Validation

• Lancez un mini batch (1–5 % de l’ensemble complet) et comparez les sorties élément par élément.
• Conservez les journaux pour la première exécution réussie dans chaque environnement. Ils deviennent la ligne de base quand quelque chose dévie plus tard.

Restauration

• Gardez un préréglage « dernier connu pour fonctionner » des deux côtés. Nommez-le avec une date et une note courte comme, « pré-mise à jour CUDA » ou « graine verrouillée pour la version v1 ». Cela prend dix minutes tranquilles et se paie la première fois que quelque chose change sous vous. J’oublie toujours une étape de temps en temps : la liste de contrôle pardonne cela.

Si vous pesez LTX-2 Local vs Cloud, c’est la partie par laquelle je commencerais de toute façon. Même si vous ne basculez jamais, écrire vos suppositions a un moyen de calmer le travail.