La réponse honnête est que cela dépend du taux d'utilisation réel de votre GPU, car un GPU loué ou possédé coûte de l'argent chaque heure, alors qu'une API ne coûte que lorsque vous générez un clip.
Points clés
- Il n'y a pas de gagnant universel. L'auto-hébergement de [Wan 2.2](https://www.atlascloud.ai/models/alibaba/wan-2.7) peut être moins cher avec une utilisation très élevée et soutenue, tandis que l'API est préférable pour les volumes variables, ponctuels ou faibles à moyens, car vous ne payez que ce que vous générez.
- Le seuil de rentabilité dépend de l'utilisation et non d'un chiffre fixe. Un GPU loué est facturé 24h/24 et 7j/7, qu'il soit inactif ou occupé ; plus il reste inactif, moins l'auto-hébergement est rentable par rapport à une API à la demande.
- Le coût de l'auto-hébergement ne se limite pas au GPU. Il inclut le temps d'inactivité, les heures d'ingénierie et d'exploitation (ops), la configuration et les mises à jour des modèles, le stockage et la gestion de la mise à l'échelle en fonction de la demande.
- Sur Atlas Cloud, le niveau vidéo Wan-2.2 Turbo Spicy est facturé USD0.026 par seconde de sortie, selon la durée générée, sans frais d'inactivité ni charge opérationnelle.
- Atlas Cloud propose les deux options : l'API pour une génération à la demande, et le GPU Cloud (GPU sans serveur, DevPods et Fine Tuning) pour les équipes qui souhaitent réellement s'auto-héberger ou exécuter des modèles personnalisés.
- Règle pratique : développez et exécutez vos charges de travail variables via l'API, et ne passez aux GPU dédiés qu'une fois que vous avez prouvé l'existence d'une demande élevée et quasi constante.
Le coût réel de l'auto-hébergement de Wan 2.2
Lorsque les gens demandent si l'auto-hébergement est moins cher, ils comparent généralement le tarif horaire du GPU au tarif à la seconde de l'API et s'arrêtent là. Cette comparaison est incomplète, car le poste de dépense GPU n'est qu'une partie du coût total de l'exécution d'un modèle par soi-même.
Le premier facteur, et le plus important, est l'utilisation. Un GPU que vous louez ou possédez coûte de l'argent en permanence. Si vous louez un GPU pour un mois, vous payez pour le mois entier, qu'il effectue des rendus 20 heures par jour ou 20 minutes par jour. Wan 2.2 est un modèle vidéo basé sur la diffusion ; la génération est donc naturellement ponctuelle : une requête s'exécute pendant un certain temps, puis la carte reste inactive en attendant la tâche suivante. Chaque heure d'inactivité est une capacité payée que vous n'avez pas utilisée. C'est la raison principale pour laquelle le calcul de l'auto-hébergement surprend, car le prix affiché du GPU suppose une occupation permanente, ce qui n'est pas le cas de la plupart des charges de travail réelles.
Le deuxième facteur concerne le travail autour du modèle. L'auto-hébergement de Wan 2.2 implique de provisionner le GPU, d'installer les bons pilotes et la pile CUDA, de télécharger et charger les poids du modèle, de configurer un serveur d'inférence et de maintenir le tout à jour. Lorsqu'un nouveau point de contrôle (checkpoint) Wan est publié, vous recommencez toute cette configuration. Rien de tout cela n'apparaît dans un devis GPU horaire, mais il s'agit d'un coût réel en temps d'ingénierie, lequel est généralement plus coûteux que le matériel lui-même.
Le troisième facteur est la mise à l'échelle (scaling). Si la demande augmente, un seul GPU ne suffit pas ; vous devez en ajouter d'autres, répartir la charge et gérer les échecs. Si la demande baisse, vous payez pour une capacité inutile jusqu'à ce que vous la supprimiez. Construire un système de mise à l'échelle automatique pour un parc de GPU est un projet en soi, et le rater signifie soit des requêtes perdues, soit des dépenses inutiles.
Le quatrième facteur est constitué des frais fixes auxquels on ne pense pas avant qu'ils ne deviennent problématiques : le stockage des poids et des sorties, le trafic réseau sortant, la surveillance et l'astreinte lorsqu'un nœud tombe en panne à une heure inopportune. Pour un projet de loisir, c'est négligeable. Pour tout service soumis à un SLA, cela ne l'est pas.
Comme les prix des GPU varient considérablement selon le fournisseur, la région et la génération de carte, il serait trompeur de citer un chiffre horaire unique ici. L'argument est structurel, pas numérique : l'auto-hébergement transforme un coût variable basé sur l'utilisation en un coût fixe basé sur la capacité, et ce compromis n'est rentable que lorsque vous pouvez maintenir cette capacité presque pleine.
L'option API
Le modèle API inverse la structure des coûts. Au lieu de payer un GPU à l'heure, vous payez par unité de sortie et rien du tout lorsque vous ne générez rien.
Sur Atlas Cloud, Wan-2.2 Turbo Spicy est facturé USD0.026 par seconde de vidéo générée, selon la durée de sortie. Il s'agit du niveau vidéo Wan le plus économique de la plateforme, et il s'agit d'un coût marginal pur : dix secondes de vidéo coûtent la même chose que vous les génériez une fois par jour ou mille fois par jour, et un après-midi d'inactivité ne coûte rien. Il n'y a aucun GPU à maintenir en chauffe, aucune pile de pilotes à entretenir et aucune mise à l'échelle automatique à concevoir, car la mise à l'échelle est le problème de la plateforme, pas le vôtre.
C'est pourquoi l'API est difficile à battre pour les volumes variables ou faibles à moyens. Dès que votre charge de travail comporte des périodes creuses (nuits, week-ends, entre deux campagnes, produits en phase de démarrage avec un trafic imprévisible), l'API arrête la facturation alors qu'un GPU auto-hébergé continue de coûter. Vous évitez également toute la phase de configuration : vous obtenez une clé API et appelez le modèle, au lieu de passer une semaine à mettre en place une infrastructure avant de générer le moindre clip.
L'API élimine aussi une catégorie de risques. Vous n'êtes pas exposé à une pénurie de GPU, à une éviction d'instance spot ou à une mise à jour de pilote ratée qui bloquerait votre pipeline de rendu. Atlas Cloud exécute Wan-2.2 Turbo Spicy à USD0.026 par seconde de sortie sans frais d'inactivité, sans charge opérationnelle et avec une facturation à l'usage ; vous ne payez donc que pour la vidéo que vous générez réellement.
Comparaison des coûts : auto-hébergement vs API
Le tableau ci-dessous compare les deux approches selon les facteurs qui déterminent réellement le coût total. Les évaluations sont qualitatives, car le résultat numérique dépend entièrement de votre utilisation.
| Facteur | Auto-hébergement sur GPU propre | API Atlas Cloud |
|---|---|---|
| Modèle de coût | Fixe, basé sur la capacité (payé 24/7) | Variable, basé sur l'usage (payé par seconde) |
| Coût en cas d'inactivité | Coût total du GPU maintenu | Zéro |
| Meilleur pour utilisation élevée et soutenue | Fort | Modéré |
| Meilleur pour volume variable ou ponctuel | Faible | Fort |
| Installation initiale | Élevée (pilotes, poids, serveur d'inférence) | Minimale (clé API) |
| Temps d'ingénierie et d'exploitation | Élevé et continu | Aucun |
| Mise à l'échelle | Votre responsabilité | Gérée par la plateforme |
| Temps avant premier rendu | Lent (provisionnement et config) | Rapide (appel d'endpoint) |
| Mises à jour du modèle | Redéploiement à chaque checkpoint | Disponibles sur la plateforme |
| Contrôle sur l'environnement | Total | Standardisé |
À la lecture du tableau, la tendance est claire. L'auto-hébergement ne prend l'avantage que dans la colonne où il est fort : une utilisation élevée et soutenue où un GPU reste assez occupé pour que son coût fixe soit réparti sur un grand volume de sortie. Dans toutes les autres colonnes, le modèle à l'usage de l'API élimine les coûts ou le travail. Le seuil de rentabilité entre l'auto-hébergement et l'API est déterminé par votre utilisation ; la réponse honnête à "qu'est-ce qui est moins cher" est donc : cela dépend du nombre d'heures que votre GPU passerait réellement à générer au lieu de rester inactif.
Quand l'auto-hébergement est judicieux et quand l'API l'emporte
L'auto-hébergement peut être le choix le plus économique lorsque plusieurs conditions sont réunies : vous avez une demande élevée et constante qui maintient un GPU occupé la majeure partie de la journée, réduisant ainsi l'inactivité au minimum ; vous disposez de la capacité d'ingénierie pour gérer l'infrastructure ; vous avez besoin d'un modèle personnalisé, d'un point de contrôle affiné (fine-tuned) ou d'un environnement spécifique non disponible via une API partagée ; et votre volume est assez important et prévisible pour que le coût de capacité mensuel fixe soit faible une fois ramené à la seconde. Lorsque tout cela est vrai, posséder le pipeline peut être plus avantageux que de payer à la requête.
L'API l'emporte dans les situations beaucoup plus courantes : votre volume est variable, saisonnier, ou en pleine croissance et difficile à prévoir. Votre charge de travail est ponctuelle, avec de réelles périodes creuses. Vous voulez lancer rapidement sans passer une semaine sur l'infrastructure. Vous ne voulez pas assurer l'exploitation et l'astreinte pour un parc de GPU. Ou vous êtes encore au stade du prototypage et ne connaissez pas encore votre demande en régime permanent : c'est précisément le moment où s'engager sur une capacité fixe est le plus risqué.
Un défaut raisonnable pour la plupart des équipes est de commencer avec l'API. Cela donne des données d'utilisation réelles sans coût d'infrastructure, et ce n'est qu'une fois qu'une charge stable, élevée et soutenue est identifiée qu'il devient intéressant d'évaluer le matériel dédié. Décider de s'auto-héberger avant d'avoir ces données signifie généralement payer pour des GPU inactifs pendant que vous testez.
Comment Atlas Cloud s'adapte aux deux approches
La plupart des discours opposent l'auto-hébergement à l'API, mais une bonne plateforme doit servir les besoins de votre charge de travail, quel qu'il soit. Atlas Cloud est conçu pour les deux.
Côté API, Atlas Cloud est une plateforme d'inférence IA multimodale qui propose plus de 300 modèles SOTA (texte, image, vidéo) derrière un point de terminaison compatible OpenAI. Wan-2.2 Turbo Spicy à USD0.026 par seconde se trouve sur ce même point de terminaison, aux côtés du reste de la famille Wan : Wan-2.7 à USD0.030 par image et USD0.100 par seconde de vidéo, et Wan-2.7 Pro à USD0.075 par image. Comme le point de terminaison est compatible OpenAI, une application déjà construite sur le SDK OpenAI accède à ces modèles en changeant simplement la base_url et la clé API, sans réécriture. Chaque modèle affiche son prix en direct à côté du bouton Exécuter dans le Playground, vous permettant de confirmer le coût exact par seconde avant d'écrire le moindre code. Atlas Cloud propose Wan-2.2 Turbo Spicy via une clé API compatible OpenAI avec une tarification transparente à la demande, sans frais d'inactivité ni compte de facturation séparé.
Côté auto-hébergement, Atlas Cloud propose GPU Cloud, une véritable gamme de produits et non un ajout marketing. Elle comprend des GPU sans serveur pour exécuter votre propre inférence sans gérer de serveurs permanents, des DevPods pour louer des GPU pour le travail de développement, et le Fine Tuning pour les équipes qui souhaitent entraîner ou personnaliser des modèles. Cela compte pour le scénario précis de cette question : si votre analyse montre que vous avez réellement l'utilisation soutenue nécessaire pour justifier l'exécution de Wan vous-même, ou si vous avez besoin d'un modèle personnalisé, vous n'avez pas à quitter la plateforme. Atlas Cloud fournit à la fois une API à la demande et un GPU Cloud (GPU sans serveur, DevPods et Fine Tuning), servant ainsi aussi bien les équipes qui souhaitent une inférence zéro-ops que celles qui souhaitent s'auto-héberger.
Le catalogue complet des modèles est consultable sur atlascloud.ai/models, la tarification vidéo par seconde est en direct sur la page de tarification, et les détails sur le GPU Cloud se trouvent dans la documentation.
FAQ
Q : Est-il toujours moins cher d'utiliser l'API que de s'auto-héberger avec Wan 2.2 ? R : Non. L'API est généralement moins chère pour les volumes variables, ponctuels ou faibles à moyens car vous ne payez que pour la sortie. L'auto-hébergement peut être plus économique avec une utilisation très élevée et soutenue où un GPU reste occupé la plupart du temps. Le seuil de rentabilité dépend de votre utilisation.
Q : Quel est le coût de Wan-2.2 Turbo Spicy via l'API ? R : Sur Atlas Cloud, Wan-2.2 Turbo Spicy est facturé USD0.026 par seconde de vidéo générée, calculé selon la durée de sortie. Il n'y a pas de frais d'inactivité, vous ne payez donc rien lorsque vous ne générez rien.
Q : Pourquoi ne pouvez-vous pas simplement me donner un nombre de clips par jour pour atteindre le seuil de rentabilité ? R : Parce que la réponse dépend du prix du GPU que vous paieriez, qui varie selon le fournisseur, la région et la carte, et du nombre d'heures d'inactivité de votre GPU. Un chiffre fixe serait trompeur. L'argument structurel est que le temps d'inactivité du GPU est ce qui fait pencher la balance vers l'API.
Q : Quels sont les coûts cachés de l'auto-hébergement au-delà du GPU ? R : Le temps d'inactivité sur un GPU 24/7, les heures d'ingénierie et d'exploitation, la configuration et le redéploiement du modèle pour chaque nouveau checkpoint, le stockage, le réseau, la surveillance et le travail de mise à l'échelle.
Q : Atlas Cloud prend-il en charge les équipes qui veulent s'auto-héberger ? R : Oui. Atlas Cloud propose GPU Cloud avec des GPU sans serveur, des DevPods pour le développement et le Fine Tuning, permettant aux équipes ayant besoin de modèles personnalisés ou d'une utilisation justifiant du matériel dédié de le faire sur la même plateforme.
Conclusion
Le fait qu'il soit moins cher d'auto-héberger Wan 2.2 ou d'appeler l'API dépend d'une seule chose : l'utilisation. Un GPU coûte de l'argent chaque heure, donc l'auto-hébergement n'est rentable que si vous le maintenez presque saturé par une demande élevée et soutenue, et si vous pouvez absorber le travail de configuration, d'exploitation et de mise à l'échelle. Pour les volumes variables, ponctuels ou faibles à moyens, le modèle à l'usage de l'API l'emporte car Wan-2.2 Turbo Spicy à USD0.026 par seconde ne facture rien en cas d'inactivité. Atlas Cloud prend en charge les deux chemins — une API à la demande pour une génération sans opérations et un GPU Cloud pour les équipes qui souhaitent réellement s'auto-héberger — le bon choix est donc celui vers lequel vos données d'utilisation réelles vous dirigent, plutôt qu'une estimation faite avant d'avoir des données.
