Confine delle prove
Un riferimento a contratto pubblico, non un diagramma dell'infrastruttura privata
Usalo per decidere dove dovrebbero risiedere proprietà, convalida, stato dell'attività, ripetizione, liquidazione, consegna, cancellazione e prove nella tua integrazione. Per campi e risposte multiparte esatti, usa il Documentazione API e contratto OpenAPI 3.1. Per i concetti di ricerca all'interno della localizzazione del volto, trasferimento dell'identità, sintesi, fusione e coerenza video, leggi come funziona l'AI face swap.
Contratto pubblico verificato
Cinque flussi di lavoro asincroni condividono una forma di controllo
Ogni flusso di lavoro di generazione corrente si autentica con una chiave Bearer API, accetta media multipart, restituisce un taskId, ed espone lo stato con ambito proprietario tramite GET sullo stesso percorso. Il completamento utilizza il polling; i callback webhook e gli SDK linguistici ufficiali non sono attualmente pubblicati.
| Flusso di lavoro | POST e GET di polling | Costo unitario | Limite principale |
|---|---|---|---|
| Foto | /api/ai-tasks | 3 crediti per attività | 30 MB per immagine |
| Foto batch | /api/ai-tasks/batch-face-swap | 3 crediti per output | 20 immagini, 95 MB combinati |
| Foto di gruppo mappata | /api/ai-tasks/multi-face-swap | 3 crediti per volto sostituito | 10 volti mappati, 95 MB combinati |
| Video | /api/ai-tasks/video | Solo volto con conservazione della scena: 1/s, minimo 5 a 1080p | 600 secondi, 95 MB di upload combinato |
| GIF / clip breve | /api/ai-tasks/gif | 1 credito al secondo, minimo 5 | 30 secondi, 95 MB di destinazione |
L'area di lavoro live e la documentazione API rimangono autorevoli per formati esatti, addebiti minimi e campi di richiesta. È richiesta un'email dell'account verificata, una generazione può essere attiva per account e i limiti esauriti possono restituire HTTP 429 con informazioni per il ritentativo.
Architettura di riferimento
Dai a ogni decisione irreversibile un proprietario
Ingresso e identità
Termina TLS, autentica la chiave detenuta dal server, assegna un ID di correlazione della richiesta e lega ogni attività a un account.
Policy e convalida
Controlla lo stato dell'autorizzazione, i campi del flusso di lavoro, il tipo di media rilevato, la dimensione in byte, il conteggio, la durata, la mappatura, la prontezza dell'account e la disponibilità di credito.
Registro delle attività
Persisti il taskId, il proprietario, il flusso di lavoro, l'addebito previsto, le transizioni di stato, i timestamp e il risultato della liquidazione prima di restituire il controllo.
Elaborazione limitata
Disaccoppia l'accettazione della richiesta dalla generazione, limita il lavoro attivo e distingue i guasti di trasporto ripetibili dagli input non validi.
Liquidazione
Usa un'unica autorità atomica per le decisioni di riserva, completamento e rimborso per attività fallita in modo che un tentativo non possa addebitare o rimborsare due volte.
Consegna e cancellazione
Autorizza l'accesso ai risultati dal proprietario dell'attività, applica il diritto di esportazione dell'immagine e cancella i media secondo la pianificazione documentata di 24 ore.
Sequenza di richiesta in otto passaggi
Dalla cancellazione del contratto di richiesta alla cancellazione supportata da prove
- Congela il contratto di richiesta pubblico. Scegli il flusso di lavoro esatto e registra campi, limiti dei media, costo unitario e stati terminali.
- Controlla autorizzazione, consenso e prontezza dell'account. Mantieni la chiave API lato server e richiedi una decisione di autorizzazione prima di accettare i media.
- Convalida i media e calcola il costo prima di accodare. Ispeziona il tipo rilevato, la dimensione, il conteggio, la durata, la mappatura e i crediti disponibili prima del lavoro costoso.
- Crea un record di attività durevole. Persisti proprietà, flusso di lavoro, addebito previsto, riferimenti di input, stato e taskId.
- Elabora in modo asincrono dietro una coda limitata. Limita la concorrenza e classifica i guasti transitori rispetto a quelli permanenti.
- Liquida i crediti una sola volta. Impegna il lavoro completato e applica il percorso di rimborso per elaborazione fallita documentato senza doppia liquidazione.
- Esponi uno stato con ambito proprietario e accesso ai risultati. Esegui il polling a un intervallo misurato e fermati a COMPLETED, FAILED o CANCELLED.
- Applica la cancellazione e conserva le prove operative. Cancella i media secondo la pianificazione, conservando solo il minimo record consentito di attività, fatturazione, sicurezza e supporto.
Stato e liquidazione
Mantieni lo stato di elaborazione separato dallo stato monetario
| Evento | Record attività | Azione credito | Azione client |
|---|---|---|---|
| Richiesta rifiutata prima della creazione dell'attività | Nessuna attività accettata | Non dedurre un addebito | Correggi la richiesta o lo stato dell'account |
| Attività accettata | Persisti taskId e costo previsto | Tratta la liquidazione come di proprietà del server | Inizia il polling misurato |
| Attività completata | Risultato terminale | Il lavoro completato rimane liquidato | Autorizza il recupero del risultato |
| Elaborazione fallita | Guasto terminale | Il contratto corrente rimborsa automaticamente l'elaborazione fallita | Leggi il guasto prima di decidere di reinviare |
| Esito della risposta incerto | Riconcilia prima di un altro POST | Non indovinare mai da un timeout | Usa il taskId memorizzato o la cronologia dell'account |
Nessun campo idempotency-key è documentato nel contratto pubblico. Il servizio chiamante dovrebbe disabilitare l'invio duplicato, persistere il primo taskId e riconciliare una risposta di rete incerta prima di emettere un altro POST.
Policy di guasto
Riprova solo quando la classe di guasto lo permette
| Stato | Classe di guasto | Risposta dell'architettura |
|---|---|---|
| 400 | Richiesta o media non validi | Rifiuta permanentemente finché i campi o i media non cambiano. |
| 401 / 403 | Chiave o prontezza dell'account | Ruota la chiave o completa la verifica; non ripetere il ciclo. |
| 402 | Crediti insufficienti | Aggiungi crediti e invia una nuova attività solo dopo la conferma. |
| 404 | Proprietario, percorso o taskId errati | Riconcilia l'identità e il record dell'attività memorizzato. |
| 429 | Limite di velocità o generazione attiva | Rispetta Retry-After quando fornito, aggiungi jitter e limita i tentativi. |
| 500 | Accettazione temporanea o errore di lettura | Usa backoff esponenziale limitato e riconcilia prima di un invio duplicato. |
Osservabilità e sicurezza
Traccia le decisioni di controllo senza copiare contenuti sensibili nei log
La telemetria consigliata per le attività include un ID di correlazione, taskId, identificatore dell'account, flusso di lavoro, dati multimediali anonimizzati, importo del credito previsto, transizioni di stato, numero di tentativi, classe di errore, evento di regolamento e timestamp di eliminazione. Non registrare chiavi API, immagini di volti, nomi di file caricati completi, URL dei risultati firmati o corpi multipart. La Raccomandazione W3C Trace Context definisce un contesto di richiesta interoperabile; è un'opzione di progettazione, non un'affermazione sull'implementazione privata di DeepSwapAI.
Per le difese di upload, convalida i nomi di file decodificati, il contenuto rilevato, i formati consentiti, i conteggi e le dimensioni; non fidarti solo del Content-Type fornito dal browser. Il OWASP File Upload Cheat Sheet è il riferimento di sicurezza esterno. Usa il pianificatore di consenso e divulgazione per il gate di autorizzazione umana e il Trust Center per i confini attuali del servizio pubblico.
Costo totale di proprietà
Confronta soluzioni gestite, self-hosted e ibride sullo stesso carico di lavoro misurato
Non confrontare un addebito API con il solo noleggio GPU grezzo. Fissa prima una finestra di carico di lavoro: mix di flussi di lavoro, durata e risoluzione dei contenuti multimediali, concorrenza di picco, tasso di tentativi, conservazione, volume di revisione e disponibilità richiesta. Quindi assegna ogni costo ricorrente e relativo ai guasti alla stessa finestra.
| Dimensione del costo | API gestito | Self-hosted | Ibrido | Prove da raccogliere |
|---|---|---|---|---|
| Capacità di elaborazione | Addebito per attività o durata pubblicato | Noleggio o acquisto GPU, capacità inattiva, scalabilità e runtime del modello | Baseline interna più overflow esterno o elaborazione specialistica | Unitá completate, durata, risoluzione, concorrenza e utilizzo |
| Ingegneria e operazioni | Integrazione, persistenza delle attività, polling, revisione e gestione dei cambiamenti del fornitore | Servizio del modello, coda, aggiornamenti, pianificazione della capacità, distribuzione e risposta alle chiamate | Orchestrazione, astrazione del fornitore e proprietà della piattaforma interna | Ore di ingegneria misurate, cadenza di rilascio e carico di chiamata |
| Sicurezza e governance | Gate di consenso dell'applicazione, policy dell'account, revisione e prove | Tutti i controlli di moderazione, archiviazione, eliminazione, controllo degli accessi e audit | Controlli condivisi con un proprietario esplicito per ogni decisione | Minuti di revisione, tasso di escalation, ambito di conservazione e proprietari dei controlli |
| Archiviazione e consegna | Gestione di input, risultato e rete lato applicazione | Operazioni di input, intermedio, risultato, backup, uscita ed eliminazione | Record interni più trasferimenti limitati al fornitore | Byte conservati, volume di trasferimento, tempo di conservazione e lavoro di eliminazione |
| Guasto e affidabilità | Tentativi, riconciliazione, gestione delle interruzioni del fornitore e costo del cambio | Ridondanza, risposta agli incidenti, lavori falliti, ripristino e capacità inutilizzata | Sia guasto di dipendenza che guasto di orchestrazione interna | Tasso di guasto, tempo di ripristino, lavoro duplicato e carico di supporto |
Questo framework non pubblica alcun benchmark di prezzo self-hosted e non afferma che la soluzione gestita, self-hosted o ibrida sia universalmente più economica. La decisione dipende dal carico di lavoro e dai controlli che possono essere dimostrati per lo stesso periodo.
Decisione di build
Scegli gestito, self-hosted o ibrido in base ai controlli che devi possedere
| Modello | Possiedi tu | Dipendenza esterna | Migliore vestibilità |
|---|---|---|---|
| API gestito | Gate di consenso, UX dell'applicazione, persistenza delle attività, polling, revisione e policy aziendale | API pubblicato, limiti, prezzi e comportamento di elaborazione | Team che danno priorità alla velocità di integrazione rispetto al controllo dell'infrastruttura |
| Self-hosted | Modello, capacità GPU, coda, moderazione, archiviazione, sicurezza, regolamento, eliminazione e risposta agli incidenti | Modello e catena di fornitura dell'infrastruttura | Team con un requisito di controllo o distribuzione giustificato e capacità operative |
| Ibrido | Policy interna, orchestrazione, registro di audit, revisione e astrazione del fornitore | Uno o più servizi di generazione limitati | Team che necessitano di controllo a livello applicativo senza gestire ogni componente del modello |
Fonti e metodo
Fatti attuali del prodotto più standard esterni primari
Il team prodotto DeepSwapAI ha verificato le cinque route pubbliche, l'autenticazione Bearer, le richieste multipart, gli stati delle attività, il flusso di polling, le risposte di errore, il limite di concorrenza, il regolamento del credito, il diritto alle immagini di prova e l'eliminazione dei contenuti multimediali in 24 ore il 22 luglio 2026. I controlli raccomandati sono informati dalle Specifica OpenAPI 3.1.2, linee guida OWASP per l'upload, NIST AI RMF 1.0, e W3C Trace Context. Vedi la metodologia di verifica delle affermazioni per come le dichiarazioni attuali del prodotto sono separate dalle linee guida generali di progettazione.
Domande sull'architettura
Sapere cosa stabilisce e non stabilisce il contratto pubblico
Questa è l'architettura di produzione privata di DeepSwapAI?
No. È un riferimento di progettazione del contratto pubblico e non divulga la topologia del fornitore, la tecnologia della coda, il posizionamento del modello, il numero di worker, la rete interna o gli obiettivi a livello di servizio.
Come fa un client a sapere che un'attività è terminata?
Conserva il taskId restituito da POST e fai polling su GET sulla stessa route del flusso di lavoro fino a COMPLETED, FAILED o CANCELLED. I callback webhook non sono attualmente pubblicati.
La chiave API può essere inserita nel codice client?
No. Trattala come un segreto lato server e tienila fuori da bundle del browser, binari mobili, repository, analisi, log e messaggi di supporto.
API pubblica una chiave di idempotenza?
Nessun campo idempotency-key è documentato. Previeni l'invio duplicato, persisti il primo taskId e riconcilia le risposte incerte prima di un altro POST.
Questo design garantisce throughput o qualità?
No. Non è un benchmark, SLA, punteggio di accuratezza o garanzia di qualità.