Limite des preuves
Une référence de contrat public, pas un diagramme d'infrastructure privée
Utilisez-la pour décider où la propriété, la validation, l'état de la tâche, le réessai, le règlement, la livraison, la suppression et les preuves doivent résider dans votre propre intégration. Pour les champs et réponses multipart exacts, utilisez le Documentation API et contrat OpenAPI 3.1. Pour les concepts de recherche à l'intérieur de la localisation du visage, du transfert d'identité, de la synthèse, du mélange et de la cohérence vidéo, lisez comment fonctionne le face swap IA.
Contrat public vérifié
Cinq workflows asynchrones partagent une forme de contrôle
Chaque workflow de génération actuel s'authentifie avec une clé Bearer API, accepte un média multipart, retourne un taskId, et expose un statut limité au propriétaire via GET sur la même route. L'achèvement utilise le polling ; les callbacks webhook et les SDK linguistiques officiels ne sont actuellement pas publiés.
| Workflow | POST et polling GET | Unité de coût | Limite principale |
|---|---|---|---|
| Photo | /api/ai-tasks | 3 crédits par tâche | 30 Mo par image |
| Photo par lot | /api/ai-tasks/batch-face-swap | 3 crédits par sortie | 20 images, 95 Mo combinés |
| Photo de groupe mappée | /api/ai-tasks/multi-face-swap | 3 crédits par visage de remplacement | 10 visages mappés, 95 Mo combinés |
| Vidéo | /api/ai-tasks/video | Visage uniquement avec préservation de la scène : 1/s, min 5 à 1080p | 600 secondes, 95 Mo combinés téléchargement |
| GIF / clip court | /api/ai-tasks/gif | 1 crédit par seconde, min 5 | 30 secondes, 95 Mo cible |
L'espace de travail en direct et la documentation API restent faisant autorité pour les formats exacts, les frais minimum et les champs de requête. Un email de compte vérifié est requis, une génération peut être active par compte, et les limites épuisées peuvent retourner HTTP 429 avec des informations de réessai.
Architecture de référence
Donner à chaque décision irréversible un propriétaire
Entrée et identité
Terminez TLS, authentifiez la clé détenue par le serveur, attribuez un ID de corrélation de requête et liez chaque tâche à un compte.
Politique et validation
Vérifiez l'état d'autorisation, les champs du workflow, le type de média détecté, la taille en octets, le nombre, la durée, le mappage, l'état du compte et la disponibilité des crédits.
Registre des tâches
Persistez le taskId, le propriétaire, le workflow, le coût attendu, les transitions d'état, les horodatages et le résultat du règlement avant de retourner le contrôle.
Traitement borné
Découplez l'acceptation de la requête de la génération, plafonnez le travail actif et distinguez les échecs de transport réessayables des entrées invalides.
Règlement
Utilisez une autorité atomique unique pour les décisions de réserve, d'achèvement et de remboursement des tâches échouées afin qu'un réessai ne puisse pas facturer ou rembourser deux fois.
Livraison et suppression
Autorisez l'accès au résultat par le propriétaire de la tâche, appliquez le droit d'exportation d'image et supprimez le média selon le calendrier documenté de 24 heures.
Séquence de requête en huit étapes
Suppression de la demande de contrat à la suppression avec preuves
- Geler le contrat de requête public. Choisissez le workflow exact et enregistrez les champs, les limites de média, l'unité de coût et les états terminaux.
- Contrôler l'autorisation, le consentement et l'état du compte. Gardez la clé API côté serveur et exigez une décision d'autorisation avant d'accepter le média.
- Valider le média et calculer le coût avant la mise en file d'attente. Inspectez le type détecté, la taille, le nombre, la durée, le mappage et les crédits disponibles avant un travail coûteux.
- Créer un enregistrement de tâche durable. Persistez la propriété, le workflow, le coût attendu, les références d'entrée, l'état et le taskId.
- Traiter de manière asynchrone derrière une file d'attente bornée. Limitez la concurrence et classez les échecs transitoires par rapport aux échecs permanents.
- Régler les crédits exactement une fois. Engagez le travail terminé et appliquez le chemin de remboursement documenté pour le traitement échoué sans double règlement.
- Exposer un statut et un accès au résultat limités au propriétaire. Pollen à un intervalle mesuré et arrêtez-vous à COMPLETED, FAILED ou CANCELLED.
- Appliquer la suppression et conserver les preuves opérationnelles. Reproduisez les médias selon le calendrier tout en conservant uniquement l'enregistrement minimal autorisé de la tâche, de la facturation, de la sécurité et du support.
État et règlement
Maintenez l'état de traitement séparé de l'état monétaire
| Événement | Enregistrement de tâche | Action de crédit | Action client |
|---|---|---|---|
| Demande rejetée avant la création de la tâche | Aucune tâche acceptée | N'inférez pas de frais | Corrigez la demande ou l'état du compte |
| Tâche acceptée | Conservez l'ID de tâche et le coût prévu | Traitez le règlement comme appartenant au serveur | Commencez l'interrogation mesurée |
| Tâche terminée | Résultat final | Le travail terminé reste réglé | Autorisez la récupération du résultat |
| Échec du traitement | Échec terminal | Le contrat actuel rembourse automatiquement les échecs de traitement | Lisez l'échec avant de décider de soumettre à nouveau |
| Résultat de la réponse incertain | Conciliez avant un autre POST | Ne devinez jamais à partir d'un délai d'attente | Utilisez l'ID de tâche stocké ou l'historique du compte |
Aucun champ de clé d'idempotence n'est documenté dans le contrat public. Le service appelant doit désactiver la soumission en double, conserver le premier ID de tâche et concilier une réponse réseau incertaine avant d'émettre un autre POST.
Politique d'échec
Ne réessayez que lorsque la classe d'échec le permet
| Statut | Classe d'échec | Réponse d'architecture |
|---|---|---|
| 400 | Demande ou média invalide | Rejetez définitivement jusqu'à ce que les champs ou les médias changent. |
| 401 / 403 | Clé ou état de préparation du compte | Faites pivoter la clé ou terminez la vérification ; ne bouclez pas. |
| 402 | Crédits insuffisants | Ajoutez des crédits et soumettez une nouvelle tâche uniquement après confirmation. |
| 404 | Mauvais propriétaire, route ou ID de tâche | Conciliez l'identité et les métadonnées de tâche stockées. |
| 429 | Limite de débit ou de génération active | Respectez Retry-After lorsqu'il est fourni, ajoutez de la gigue et limitez les nouvelles tentatives. |
| 500 | Acceptation temporaire ou échec de lecture | Utilisez un backoff exponentiel borné et conciliez avant la soumission en double. |
Observabilité et sécurité
Tracez les décisions de contrôle sans copier les médias sensibles dans les journaux
La télémétrie recommandée des tâches comprend un ID de corrélation, un ID de tâche, un identifiant de compte, un flux de travail, des faits sur les médias nettoyés, le montant de crédit prévu, les transitions d'état, le nombre de nouvelles tentatives, la classe d'erreur, l'événement de règlement et l'horodatage de suppression. Ne journalisez pas les clés API, les images de visage, les noms de fichiers téléchargés complets, les URL de résultats signés ou les corps multipartites. La recommandation de contexte de trace W3C définit un contexte de requête interopérable ; c'est une option de conception, pas une affirmation sur l'implémentation privée de DeepSwapAI.
Pour les défenses de téléchargement, validez les noms de fichiers décodés, le contenu détecté, les formats autorisés, les comptes et les tailles ; ne faites pas confiance au seul Content-Type fourni par le navigateur. Le OWASP File Upload Cheat Sheet est la référence de sécurité externe. Utilisez le planificateur de consentement et de divulgation pour la passerelle d'autorisation humaine et le Centre de confiance pour les limites actuelles des services publics.
Coût total de possession
Comparez les solutions gérées, auto-hébergées et hybrides sur la même charge de travail mesurée
Ne comparez pas une facturation API avec la seule location brute de GPU. Fixez d'abord une fenêtre de charge de travail : mix de flux de travail, durée et résolution des médias, concurrence de pointe, taux de nouvelles tentatives, rétention, volume de révision et disponibilité requise. Ensuite, attribuez chaque coût récurrent et lié aux échecs à la même fenêtre.
| Dimension de coût | API géré | Auto-hébergé | Hybride | Preuves à collecter |
|---|---|---|---|---|
| Capacité de traitement | Facturation publiée par tâche ou durée | Location ou achat de GPU, marge de manœuvre inactive, mise à l'échelle et exécution du modèle | Base de référence interne plus débordement externe ou traitement spécialisé | Unités terminées, durée, résolution, concurrence et utilisation |
| Ingénierie et opérations | Intégration, persistance des tâches, interrogation, révision et gestion des changements de fournisseur | Service de modèle, file d'attente, mises à niveau, planification de capacité, déploiement et réponse d'astreinte | Orchestration, abstraction du fournisseur et propriété de la plateforme interne | Heures d'ingénieur mesurées, cadence de publication et charge d'astreinte |
| Sécurité et gouvernance | Passerelle de consentement de l'application, politique de compte, révision et preuves | Tous les contrôles de modération, stockage, suppression, contrôle d'accès et d'audit | Contrôles partagés avec un propriétaire explicite pour chaque décision | Minutes de révision, taux d'escalade, périmètre de rétention et propriétaires de contrôle |
| Stockage et livraison | Gestion côté application des entrées, résultats et réseau | Opérations d'entrée, intermédiaire, résultat, sauvegarde, sortie et suppression | Enregistrements internes plus transferts limités vers le fournisseur | Octets conservés, volume de transfert, durée de rétention et travail de suppression |
| Échec et fiabilité | Nouvelles tentatives, réconciliation, gestion des pannes du fournisseur et coût de changement | Redondance, réponse aux incidents, tâches échouées, récupération et capacité inutilisée | Échec de dépendance et échec d'orchestration interne | Taux d'échec, temps de récupération, travail en double et charge de support |
Ce cadre ne publie aucun benchmark de prix auto-hébergé et ne prétend pas que la solution gérée, auto-hébergée ou hybride est universellement moins chère. La décision dépend de la charge de travail et des contrôles qui peuvent être prouvés pour la même période.
Décision de construction
Choisissez géré, auto-hébergé ou hybride en fonction des contrôles que vous devez posséder
| Modèle | Vous possédez | Dépendance externe | Meilleure adéquation |
|---|---|---|---|
| API géré | Passerelle de consentement, UX de l'application, persistance des tâches, interrogation, révision et politique métier | API publié, limites, tarification et comportement de traitement | Équipes privilégiant la vitesse d'intégration au contrôle de l'infrastructure |
| Auto-hébergé | Modèle, capacité GPU, file d'attente, modération, stockage, sécurité, règlement, suppression et réponse aux incidents | Chaîne d'approvisionnement du modèle et de l'infrastructure | Équipes ayant une exigence justifiée de contrôle ou de déploiement et une capacité opérationnelle |
| Hybride | Politique interne, orchestration, enregistrement d'audit, révision et abstraction du fournisseur | Un ou plusieurs services de génération limités | Équipes ayant besoin d'un contrôle au niveau de l'application sans exploiter chaque composant du modèle |
Sources et méthode
Faits actuels sur le produit plus normes externes principales
L'équipe produit DeepSwapAI a vérifié les cinq routes publiques, l'authentification Bearer, les requêtes multipartites, les états de tâche, le flux d'interrogation, les réponses d'erreur, la limite de concurrence, le règlement des crédits, le droit aux images d'essai et la suppression des médias après 24 heures le 22 juillet 2026. Les contrôles recommandés sont informés par les Spécification OpenAPI 3.1.2, directives de téléchargement OWASP, NIST AI RMF 1.0, et Contexte de trace W3C. Voir la méthodologie de vérification des affirmations pour savoir comment les déclarations actuelles sur le produit sont séparées des conseils de conception généraux.
Questions d'architecture
Sachez ce que le contrat public établit et n'établit pas
S'agit-il de l'architecture de production privée de DeepSwapAI ?
Non. C'est une référence de conception de contrat public et ne divulgue pas la topologie du fournisseur, la technologie de file d'attente, le placement du modèle, le nombre de travailleurs, le réseau interne ou les objectifs de niveau de service.
Comment un client apprend-il qu'une tâche est terminée ?
Conservez l'ID de tâche renvoyé par POST et interrogez GET sur la même route de flux de travail jusqu'à COMPLETED, FAILED ou CANCELLED. Les rappels Webhook ne sont actuellement pas publiés.
La clé API peut-elle être placée dans le code client ?
Non. Traitez-la comme un secret côté serveur et gardez-la hors des bundles de navigateur, des binaires mobiles, des référentiels, des analyses, des journaux et des messages de support.
API publie-t-il une clé d'idempotence ?
Aucun champ de clé d'idempotence n'est documenté. Empêchez la soumission en double, conservez le premier ID de tâche et conciliez les réponses incertaines avant un autre POST.
Cette conception garantit-elle le débit ou la qualité ?
Non. Ce n'est pas un benchmark, un SLA, un score de précision ou une garantie de qualité.