Nachweisgrenze
Eine öffentliche Vertragsreferenz, kein privates Infrastrukturdiagramm
Verwenden Sie sie, um zu entscheiden, wo Eigentümerschaft, Validierung, Aufgabenstatus, Wiederholung, Abrechnung, Auslieferung, Löschung und Nachweise in Ihrer eigenen Integration leben sollen. Für genaue Multipart-Felder und Antworten verwenden Sie den API-Dokumentation und OpenAPI 3.1-Vertrag. Für die Forschungskonzepte hinter Gesichtslokalisierung, Identitätstransfer, Synthese, Blending und Videokonsistenz lesen Sie wie KI-Gesichtsaustausch funktioniert.
Verifizierter öffentlicher Vertrag
Fünf asynchrone Workflows teilen eine Kontrollform
Jeder aktuelle Generierungs-Workflow authentifiziert mit einem Bearer API-Schlüssel, akzeptiert Multipart-Medien, gibt eine taskIdzurück und macht eigentümerbezogenen Status durch GET auf derselben Route zugänglich. Der Abschluss verwendet Polling; Webhook-Callbacks und offizielle Sprach-SDKs werden derzeit nicht veröffentlicht.
| Workflow | POST und Polling-GET | Kosteneinheit | Primäre Grenze |
|---|---|---|---|
| Foto | /api/ai-tasks | 3 Credits pro Aufgabe | 30 MB pro Bild |
| Batch-Foto | /api/ai-tasks/batch-face-swap | 3 Credits pro Ausgabe | 20 Bilder, 95 MB kombiniert |
| Zugeordnetes Gruppenfoto | /api/ai-tasks/multi-face-swap | 3 Credits pro ersetztem Gesicht | 10 zugeordnete Gesichter, 95 MB kombiniert |
| Video | /api/ai-tasks/video | Nur Gesicht mit Szenenerhaltung: 1/s, mindestens 5 bei 1080p | 600 Sekunden, 95 MB kombinierter Upload |
| GIF / kurzer Clip | /api/ai-tasks/gif | 1 Credit pro Sekunde, mindestens 5 | 30 Sekunden, 95 MB Ziel |
Der Live-Arbeitsbereich und die API-Dokumentation bleiben maßgeblich für genaue Formate, Mindestgebühren und Anforderungsfelder. Eine verifizierte Konto-E-Mail ist erforderlich, eine Generierung kann pro Konto aktiv sein, und erschöpfte Grenzen können HTTP 429 mit Wiederholungsinformationen zurückgeben.
Referenzarchitektur
Geben Sie jeder irreversiblen Entscheidung einen Eigentümer
Eingang und Identität
Beenden Sie TLS, authentifizieren Sie den serverseitigen Schlüssel, weisen Sie eine Korrelations-ID für die Anfrage zu und binden Sie jede Aufgabe an ein Konto.
Richtlinie und Validierung
Überprüfen Sie den Berechtigungsstatus, die Workflow-Felder, den erkannten Medientyp, die Byte-Größe, Anzahl, Dauer, Zuordnung, Kontobereitschaft und Kreditverfügbarkeit.
Aufgabenbuch
Persistieren Sie die taskId, den Eigentümer, den Workflow, die erwartete Gebühr, Zustandsübergänge, Zeitstempel und das Abrechnungsergebnis, bevor Sie die Kontrolle zurückgeben.
Begrenzte Verarbeitung
Entkoppeln Sie die Anfrageannahme von der Generierung, begrenzen Sie die aktive Arbeit und unterscheiden Sie wiederholbare Transportfehler von ungültigen Eingaben.
Abrechnung
Verwenden Sie eine atomare Autorität für Reservierungs-, Abschluss- und Rückerstattungsentscheidungen bei fehlgeschlagenen Aufgaben, sodass eine Wiederholung nicht zweimal belasten oder erstatten kann.
Auslieferung und Löschung
Autorisieren Sie den Ergebniszugriff durch den Aufgabeninhaber, wenden Sie die Berechtigung zum Bildexport an und löschen Sie Medien gemäß dem dokumentierten 24-Stunden-Zeitplan.
Acht-Schritte-Anfragesequenz
Vom Anfragevertrag bis zur nachweisgestützten Löschung
- Frieren Sie den öffentlichen Anfragevertrag ein. Wählen Sie den genauen Workflow und notieren Sie Felder, Mediabeschränkungen, Kosteneinheit und Endzustände.
- Steuern Sie Autorisierung, Einwilligung und Kontobereitschaft. Halten Sie den API-Schlüssel serverseitig und fordern Sie eine Berechtigungsentscheidung, bevor Sie Medien akzeptieren.
- Validieren Sie Medien und berechnen Sie die Kosten vor dem Einreihen. Überprüfen Sie den erkannten Typ, die Größe, Anzahl, Dauer, Zuordnung und verfügbare Credits, bevor Sie teure Arbeiten durchführen.
- Erstellen Sie einen dauerhaften Aufgabenrekord. Persistieren Sie Eigentümerschaft, Workflow, erwartete Gebühr, Eingabereferenzen, Status und taskId.
- Verarbeiten Sie asynchron hinter einer begrenzten Warteschlange. Begrenzen Sie die Parallelität und klassifizieren Sie vorübergehende versus permanente Fehler.
- Berechnen Sie Credits genau einmal ab. Buchen Sie abgeschlossene Arbeiten und wenden Sie den dokumentierten Rückerstattungspfad für fehlgeschlagene Verarbeitung an, ohne doppelte Abrechnung.
- Machen Sie eigentümerbezogenen Status und Ergebniszugriff zugänglich. Pollen Sie in einem gemessenen Intervall und stoppen Sie bei COMPLETED, FAILED oder CANCELLED.
- Löschung erzwingen und Betriebsnachweise aufbewahren. Remove Medien planmäßig löschen, während nur die minimal erforderlichen Aufgaben-, Abrechnungs-, Sicherheits- und Supportaufzeichnungen aufbewahrt werden.
Status und Abrechnung
Verarbeitungsstatus vom Geldstatus getrennt halten
| Ereignis | Aufgabenaufzeichnung | Gutschriftaktion | Kundenaktion |
|---|---|---|---|
| Anfrage vor Aufgabenerstellung abgelehnt | Keine akzeptierte Aufgabe | Keine Gebühr ableiten | Anfrage oder Kontostatus korrigieren |
| Aufgabe akzeptiert | taskId und erwartete Kosten speichern | Abrechnung als servereigen behandeln | Messbasiertes Polling beginnen |
| Aufgabe abgeschlossen | Endgültiges Ergebnis | Abgeschlossene Arbeit bleibt abgerechnet | Ergebnisabruf autorisieren |
| Verarbeitung fehlgeschlagen | Endgültiger Fehler | Aktueller Vertrag erstattet fehlgeschlagene Verarbeitung automatisch | Fehler vor Entscheidung zur erneuten Übermittlung lesen |
| Antwortausgang unsicher | Vor einem weiteren POST abgleichen | Nie aus einem Timeout raten | Gespeicherte taskId oder Kontohistorie verwenden |
Im öffentlichen Vertrag ist kein Idempotenz-Schlüsselfeld dokumentiert. Der aufrufende Dienst sollte doppelte Übermittlungen deaktivieren, die erste taskId speichern und eine unsichere Netzwerkantwort abgleichen, bevor er einen weiteren POST ausgibt.
Fehlerrichtlinie
Nur wiederholen, wenn die Fehlerklasse es erlaubt
| Status | Fehlerklasse | Architekturantwort |
|---|---|---|
| 400 | Ungültige Anfrage oder Medien | Dauerhaft ablehnen, bis sich Felder oder Medien ändern. |
| 401 / 403 | Schlüssel- oder Kontobereitschaft | Schlüssel rotieren oder Verifizierung abschließen; keine Schleife ausführen. |
| 402 | Unzureichende Credits | Credits hinzufügen und nur nach Bestätigung eine neue Aufgabe einreichen. |
| 404 | Falscher Eigentümer, Route oder taskId | Identität und gespeicherte Aufgabenmetadaten abgleichen. |
| 429 | Raten- oder Aktivgenerierungslimit | Retry-After beachten, falls angegeben, Jitter hinzufügen und Wiederholungen begrenzen. |
| 500 | Vorübergehende Annahme oder Lesefehler | Begrenztes exponentielles Backoff verwenden und vor doppelter Übermittlung abgleichen. |
Beobachtbarkeit und Sicherheit
Steuerungsentscheidungen nachverfolgen, ohne sensible Medien in Protokolle zu kopieren
Empfohlene Aufgabentelemetrie umfasst eine Korrelations-ID, taskId, Kontoidentifikator, Workflow, bereinigte Medienfakten, erwarteten Creditbetrag, Zustandsübergänge, Wiederholungsanzahl, Fehlerklasse, Abrechnungsereignis und Löschzeitstempel. Keine API-Schlüssel, Gesichtsbilder, vollständige hochgeladene Dateinamen, signierte Ergebnis-URLs oder Multipart-Bodies protokollieren. Die W3C Trace Context Empfehlung definiert interoperablen Anforderungskontext; es ist eine Designoption, kein Anspruch über die private Implementierung von DeepSwapAI.
Für Upload-Abwehrmaßnahmen dekodierte Dateinamen, erkannte Inhalte, erlaubte Formate, Anzahlen und Größen validieren; dem vom Browser gelieferten Content-Type allein nicht vertrauen. Die OWASP File Upload Cheat Sheet ist die externe Sicherheitsreferenz. Verwenden Sie den Einwilligungs- und Offenlegungsplaner für das menschliche Autorisierungsgate und das Trust Center für aktuelle öffentliche Servicestandards.
Gesamtbetriebskosten
Managed, selbst gehostet und hybrid auf derselben gemessenen Arbeitslast vergleichen
Eine API-Gebühr nicht mit reiner GPU-Miete allein vergleichen. Zuerst ein Arbeitslastfenster festlegen: Workflow-Mix, Mediendauer und -auflösung, Spitzenparallelität, Wiederholungsrate, Aufbewahrung, Prüfvolumen und erforderliche Verfügbarkeit. Dann jede wiederkehrende und fehlerbedingte Kosten demselben Fenster zuordnen.
| Kostendimension | Managed API | Selbst gehostet | Hybrid | Zu sammelnde Nachweise |
|---|---|---|---|---|
| Verarbeitungskapazität | Veröffentlichte Aufgaben- oder Dauergebühr | GPU-Leasing oder -Kauf, Leerlaufreserve, Skalierung und Modelllaufzeit | Interne Basislinie plus externer Überlauf oder Spezialverarbeitung | Abgeschlossene Einheiten, Dauer, Auflösung, Parallelität und Auslastung |
| Entwicklung und Betrieb | Integration, Aufgabenpersistenz, Polling, Überprüfung und Anbieterwechsel-Handhabung | Modellbereitstellung, Warteschlange, Upgrades, Kapazitätsplanung, Bereitstellung und Bereitschaftsdienst | Orchestrierung, Anbieterabstraktion und interne Plattformverantwortung | Gemessene Entwicklerstunden, Release-Rhythmus und Bereitschaftsdienstlast |
| Sicherheit und Governance | Anwendungs-Einwilligungsgate, Kontorichtlinie, Überprüfung und Nachweise | Alle Moderation, Speicherung, Löschung, Zugriffskontrolle und Prüfkontrollen | Geteilte Kontrollen mit explizitem Verantwortlichen für jede Entscheidung | Überprüfungsminuten, Eskalationsrate, Aufbewahrungsumfang und Kontrollverantwortliche |
| Speicherung und Bereitstellung | Anwendungsseitige Eingabe-, Ergebnis- und Netzwerkverarbeitung | Eingabe-, Zwischen-, Ergebnis-, Backup-, Ausgangs- und Löschvorgänge | Interne Aufzeichnungen plus begrenzte Anbieterübertragungen | Aufbewahrte Bytes, Übertragungsvolumen, Aufbewahrungszeit und Löschaufwand |
| Fehler und Zuverlässigkeit | Wiederholung, Abgleich, Anbieterausfall-Handhabung und Wechselkosten | Redundanz, Vorfallreaktion, fehlgeschlagene Aufträge, Wiederherstellung und ungenutzte Kapazität | Beide Abhängigkeitsfehler und interner Orchestrierungsfehler | Fehlerrate, Wiederherstellungszeit, doppelte Arbeit und Supportlast |
Dieses Framework veröffentlicht keinen Preisvergleich für selbst gehostete Lösungen und behauptet nicht, dass Managed, selbst gehostet oder hybrid universell günstiger ist. Die Entscheidung hängt von der Arbeitslast und den Kontrollen ab, die für denselben Zeitraum nachgewiesen werden können.
Baueinscheidung
Wählen Sie Managed, selbst gehostet oder hybrid basierend auf den Kontrollen, die Sie besitzen müssen
| Modell | Sie besitzen | Externe Abhängigkeit | Beste Eignung |
|---|---|---|---|
| Managed API | Einwilligungsgate, Anwendungs-UX, Aufgabenpersistenz, Polling, Überprüfung und Geschäftsrichtlinie | Veröffentlichte API, Limits, Preise und Verarbeitungsverhalten | Teams, die Integrationsgeschwindigkeit über Infrastrukturkontrolle priorisieren |
| Selbst gehostet | Modell, GPU-Kapazität, Warteschlange, Moderation, Speicherung, Sicherheit, Abrechnung, Löschung und Vorfallreaktion | Modell- und Infrastruktur-Lieferkette | Teams mit einem gerechtfertigten Kontroll- oder Bereitstellungsbedarf und Betriebskapazität |
| Hybrid | Interne Richtlinie, Orchestrierung, Prüfaufzeichnung, Überprüfung und Anbieterabstraktion | Ein oder mehrere begrenzte Generierungsdienste | Teams, die Anwendungssteuerung benötigen, ohne jede Modellkomponente zu betreiben |
Quellen und Methode
Aktuelle Produktfakten plus primäre externe Standards
Das DeepSwapAI-Produktteam hat die fünf öffentlichen Routen, Bearer-Authentifizierung, Multipart-Anfragen, Aufgabenstatus, Polling-Fluss, Fehlerantworten, Parallelitätsgrenze, Credit-Abrechnung, Testbildberechtigung und 24-Stunden-Medienlöschung am 22. Juli 2026 überprüft. Die empfohlenen Kontrollen basieren auf der OpenAPI-Spezifikation 3.1.2, OWASP-Upload-Anleitung, NIST AI RMF 1.0, und W3C Trace Context. Siehe die Anspruchsverifizierungsmethodik für die Trennung aktueller Produktaussagen von allgemeinen Designrichtlinien.
Architekturfragen
Wissen, was der öffentliche Vertrag festlegt und was nicht
Ist dies die private Produktionsarchitektur von DeepSwapAI?
Nein. Es ist eine Designreferenz für den öffentlichen Vertrag und legt keine Anbieter-Topologie, Warteschlangentechnologie, Modellplatzierung, Worker-Anzahl, internes Netzwerk oder Service-Level-Ziele offen.
Wie erfährt ein Client, dass eine Aufgabe abgeschlossen ist?
Die von POST zurückgegebene taskId behalten und GET auf derselben Workflow-Route abfragen, bis ABGESCHLOSSEN, FEHLGESCHLAGEN oder ABGEBROCHEN. Webhook-Callbacks werden derzeit nicht veröffentlicht.
Kann der API-Schlüssel im Client-Code platziert werden?
Nein. Behandeln Sie ihn als serverseitiges Geheimnis und halten Sie ihn aus Browser-Bundles, mobilen Binärdateien, Repositories, Analysen, Protokollen und Support-Nachrichten heraus.
Veröffentlicht API einen Idempotenz-Schlüssel?
Es ist kein Idempotenz-Schlüsselfeld dokumentiert. Doppelte Übermittlung verhindern, die erste taskId speichern und unsichere Antworten vor einem weiteren POST abgleichen.
Garantiert dieses Design Durchsatz oder Qualität?
Nein. Es ist kein Benchmark, SLA, Genauigkeitswert oder Qualitätsgarantie.