Ponowienia w API obrazów AI NSFW: nie płać dwa razy za ten sam obraz

Twoja aplikacja z dorosłą postacią obiecuje jeden nowy obraz. Klient naciska Generate, wskaźnik ładowania działa przez jakiś czas, a potem strona mówi o przekroczeniu czasu połączenia. Klient naciska ponownie. Minutę później pojawiają się dwa obrazy, a saldo spada dwukrotnie.

Drugi obraz może być piękny. Nadal jest to kosztowny sposób odkrycia, że przekroczenie czasu połączenia nie oznacza nieudanego generowania.

W API obrazów NSFW ludzie nazywają ponowieniem trzy różne działania: sprawdzenie istniejącego zadania, powtórzenie jego pierwotnego wysłania i zapłacenie za kolejną próbę twórczą. Oddzielaj te działania. Jeśli masz ID zadania, sprawdź je. Jeśli zniknęła odpowiedź tworzenia, powtórz niezmienione żądanie z pierwotnym kluczem idempotencji. Jeśli zadanie się zakończyło, ale obraz nie realizuje opisu, kolejne generowanie jest nowym zakupem.

Ostatnia różnica jest szczególnie istotna przy obrazach dorosłych postaci. Model może zakończyć się sukcesem, łagodząc żądaną scenę, zmieniając strój lub tworząc inną twarz. Sukces zadania mówi, że dostarczono wynik; nie obiecuje, że zechcesz go użyć.

Co się stało i jaki przycisk należy pokazać?

Czekanie, odzyskanie wysłania i nowy wariant to różne działania.

Użyteczny interfejs twórcy dla dorosłych może nazywać te działania Sprawdź istniejący obraz, Odzyskaj wysłanie, Wygeneruj kolejny wariant i Spróbuj pobrać ponownie. Jedna etykieta Ponów ukrywa różnicę między bezpłatnym sprawdzeniem statusu a zatwierdzeniem nowego wydatku generowania.

Jeśli masz ID zadania, zachowaj pierwotne zadanie

Asynchroniczny proces obrazowy SpicyAPI przyjmuje żądanie, zwraca ID zadania i udostępnia obraz później. Odpowiedź przyjętego tworzenia nie jest gotowym zdjęciem. Zadanie przechodzi przez stany takie jak queued, running i succeeded; failed, canceled i expired również są stanami końcowymi.

Zapisuj ID natychmiast po otrzymaniu przez serwer, przed aktualizacją przeglądarki. Jeśli klient odświeży stronę, zaloguje się ponownie lub otworzy projekt na innym urządzeniu, aplikacja powinna odnaleźć zapisane zadanie zamiast ponownie wysyłać prompt.

Na przykład twórca zamawia nowy wieczorny portret fikcyjnej dorosłej postaci. Serwer otrzymuje ID zadania, ale przeglądarka traci połączenie przed wyrenderowaniem oczekującej karty. Po powrocie karta powinna przywrócić połączenie z tym zadaniem. Odświeżając stronę, twórca nie prosił o drugi portret.

Użyj GET /api/v1/jobs/recordInfo z ID zadania do odzyskania aktualnego stanu. Dokumentacja zadań opisuje żądanie i odpowiedź. Możesz używać webhooka do powiadomień o ukończeniu, ale opóźniony webhook nie zamienia istniejącego zadania w awarię. Odpytywanie statusu nadal jest ścieżką odzyskiwania.

Nie zamieniaj lokalnego limitu czekania w decyzję o opłatach. Przeglądarka może przestać czekać po 30 sekundach, wychodzące żądanie HTTP serwera po 60 sekundach, a zdalne zadanie nadal może działać. Zwrócony rekord zawiera termin wykonania deadlineAt; dotyczy zdalnego wykonania, nie czasu utrzymywania połączenia przez stronę. Wygaśnięcie linku pobierania wyniku to jeszcze inny zegar.

Na ekranie oczekiwania użyj komunikatu w rodzaju „Twój obraz nadal jest przetwarzany. Możesz opuścić tę stronę i wrócić do tego samego zadania”. Nie obiecuj dokładnego czasu ukończenia bez pomiarów dla konkretnego modelu i obciążenia. Zmierzona przez konkurenta latencja zwykłych zdjęć produktów nie gwarantuje czasu twoich promptów NSFW.

Jeśli odpowiedź tworzenia zaginęła, powtórz to samo wysłanie

Trudnym przypadkiem jest zerwanie połączenia po wysłaniu żądania przez serwer, ale przed otrzymaniem potwierdzenia. Sam błąd połączenia nie mówi, czy platforma przyjęła zadanie.

SpicyAPI daje rzeczywiste zabezpieczenie serwerowe: opcjonalny nagłówek Idempotency-Key. Dla tego samego konta i klucza API powtórzenie klucza z tym samym znormalizowanym modelem, wejściem i URL callbacku w ciągu 24 godzin zwraca pierwotne zadanie zamiast ponownie blokować środki. Zmienione żądanie powoduje konflikt tego klucza. Inny klucz API tego samego konta również nie może odtworzyć mapowania; otrzymuje konflikt bez ujawnienia pierwotnego ID zadania.

Utwórz stały klucz dla obrazu zamówionego przez klienta zamiast dla każdej próby HTTP. Wartość generowana przez aplikację, taka jak project-8-image-12-v1, pokazuje ideę. Nie umieszczaj w niej danych osobowych ani surowego promptu. Wygeneruj i zapisz ją przed pierwszym żądaniem tworzenia. Nowa próba sieciowa używa jej ponownie; rzeczywiście nowy obraz dostaje nową wersję lub ID operacji.

Minimalna sekwencja odzyskiwania:

1. Zapisz w aplikacji zamierzoną operację obrazu, pierwotne body żądania i klucz.
2. Wyślij to żądanie z Idempotency-Key.
3. Jeśli potwierdzenie zaginie, oznacz lokalną operację jako oczekującą na potwierdzenie.
4. Powtórz niezmienione body z niezmienionym kluczem przez te same poświadczenia API.
5. Zapisz zwrócone ID zadania i przejdź do sprawdzania statusu.

Podczas odzyskiwania zachowaj dokładnie wysłane żądanie. Nie proś interfejsu, by odtworzył je z ustawień, które klient mógł zmienić. Jeśli twórca zmienia bliski portret na szeroką kompozycję, podnosi rozdzielczość, modyfikuje prompt lub URL callbacku, nie jest to już pierwotne wysłanie.

Zabezpieczenie ma granicę: 24 godziny nie oznaczają bezterminowego przechowywania ochrony przed duplikatami aplikacji. Po upływie okna nie zakładaj, że stary klucz odzyska stare zadanie. Własne trwałe mapowanie operacji na zadanie musi obsługiwać późniejsze powroty. Jeśli przyjęcie pozostaje niepewne i nie możesz zidentyfikować pierwotnego zadania, uzgodnij rekordy zadań konta lub zapytaj wsparcie przed automatycznym tworzeniem zastępstwa.

Wyłączenie Generate jest przydatne, ale niewystarczające

Przycisk wyłączony podczas ładowania zapobiega częstemu podwójnemu naciśnięciu. Nie zapobiega wysyłaniu duplikatów z dwóch kart, ponownie łączącego się klienta mobilnego, procesu w tle lub restartu serwera.

Aplikacja powinna wiązać wszystkie te wydarzenia z jedną logiczną operacją obrazu. Reguła unikalności we własnej bazie zapobiega niezależnemu przejęciu tej samej operacji przez dwa procesy robocze. Klucz idempotencji platformy następnie chroni zdalną granicę tworzenia. To różne zabezpieczenia; potrzebujesz obu, jeśli aplikacja ma więcej niż jeden sposób wysłania zadania.

Rozważ produkt towarzyszący generujący opcjonalny nowy portret postaci po rozmowie. Użytkownik naciska również ręczny przycisk portretu, zanim automatyczne żądanie zostanie potwierdzone. Jeśli obie czynności mają realizować ten sam portret, powiąż je z jedną operacją. Jeśli ręczny przycisk wyraźnie zamawia drugi wariant, pokaż, że jest to kolejne płatne generowanie. Nie łącz po cichu dwóch świadomych zakupów ani nie naliczaj dwóch opłat za jedną obietnicę.

Sam klucz nie rozstrzyga tej semantyki produktu. Aplikacja decyduje, co liczy się jako to samo żądanie. Lokalnie odduplikowany wiersz bazy nie pomaga też wtedy, gdy klient wychodzący wysyła każde odzyskiwanie z nowym kluczem zdalnym. Wartość musi przetrwać całą ścieżkę.

Odmowa, awaria techniczna i niechciany obraz mają różne rachunki

Żądanie treści dla dorosłych może zakończyć się na kilka sposobów. Unikaj ogólnej obietnicy, że nieudane generowanie NSFW zawsze nic nie kosztuje, i przeciwnego twierdzenia, że każdy błąd jest płatny.

Stan zadania i satysfakcja twórcza są różne. Sprawdź rozliczony rekord i wyjątki opłat właściwe dla modelu.

SpicyAPI blokuje szacowaną kwotę, gdy przyjmuje zadanie. Dopóki settled jest false, cost zadania oznacza zablokowany szacunek. Po rozliczeniu oznacza końcową opłatę. Udane zadanie jest rozliczane do wysokości blokady; niewykorzystane środki są zwalniane.

Nieudane lub wygasłe zadanie zwykle zwalnia blokadę. Istnieją wyjątki opisane w zasadach zwrotów, w tym modele, których strony podają rozliczanie odrzuconych lub nieudanych żądań, oraz użycie dostarczone przed przerwanym żądaniem. Przy zadaniu obrazu odrzuconym przez model sprawdź uwagę o opłatach modelu i końcowy rozliczony rekord. Nie opieraj wyjaśnienia salda wyłącznie na błędzie HTTP.

Udany, lecz złagodzony obraz to inna sytuacja. Wyobraź sobie zamówienie pewnej siebie fikcyjnej dorosłej postaci w konkretnej dorosłej scenie edytorialowej, które dało zwykły portret. Jeśli zadanie odniosło sukces i dostarczyło wynik, niezadowolenie ze sceny nie zamienia rezultatu w awarię techniczną objętą zwrotem. To samo dotyczy niewłaściwej fryzury, niechcianego akcesorium lub nielubianej mimiki.

Dlatego użyteczna polityka ponowień wymaga limitu wydatków twórczych, nie tylko liczby ponowień sieciowych. Proces ponawiający każdy obraz, którego aplikacja nie lubi, może kupować udane wyniki długo po rozwiązaniu awarii technicznych.

Przeczytaj dokładną stronę modelu używanego zadania. Liberalna ścieżka text-to-image nie dowodzi identycznego zachowania edycji, a nazwa rodziny nie wystarcza do przewidzenia każdego żądania NSFW. Używaj tylko dorosłych postaci i materiałów, które masz prawo wysłać; ponowienia nie czynią niedozwolonych żądań dozwolonymi.

Ponowienie końcowej awarii tworzy nową pracę

API ma również POST /api/v1/jobs/retry, przyjmujące źródłowe ID zadania i tworzące nowe zadanie z kwalifikującej się końcowej awarii. Nie zamienia starego zadania z powrotem w działające. Aktualne wejścia modelu, uprawnienia, dostępność, saldo i ceny są ponownie oceniane. Źródło musi mieć zachowane wejście i ukończone uzgodnienie rozliczeń; aktywne lub udane zadanie nie kwalifikuje się do tej czynności.

Użyj tego samego klucza API, który utworzył źródłowe zadanie. Jeśli zastosujesz klucz idempotencji do ponowienia, chroni tę konkretną nową próbę i jest ograniczony do zadania źródłowego. Powtórzenie czynności ponowienia może odzyskać nowo utworzone zadanie; różni się od powtórzenia pierwszego tworzenia w celu odzyskania oryginału.

W aplikacji twórcy pokazuj to jako świeżą próbę generowania z ceną. Jeśli sam prompt wymaga zmian, utwórz nowe żądanie ze zmienionym wejściem zamiast oczekiwać edycji przez ponowienie zadania źródłowego. Nieudane żądanie spowodowane wygasłą referencją również wymaga działającej referencji przed udaną kolejną próbą. Zwolnienie pierwotnej opłaty i blokada nowej próby to osobne wpisy.

Ile naprawdę kosztują powtarzane próby

Oto aktualne początkowe konfiguracje trzech endpointów obrazowych. Ceny opisują generowanie, a nie gwarancję, że każde zdjęcie zrealizuje opis NSFW.

Hipotetyczny przykład planowania: przypadkowe podwójne zadania dodają $2.40 do $7.20 świadomych prób twórczych.

Szczegóły są ważne. Z-Image Turbo z włączonym rozwijaniem promptu kosztuje $0.016 zamiast $0.010 za obraz. Seedream 5.0 Pro domyślnie używa 2K za $0.072 zamiast $0.036 w 1K. Wyraźny wybór poziomu dopasowuje obliczenie do zadania.

Załóżmy plan 100 końcowych portretów Qwen Image 2.1 w 1K. Jeśli każdy końcowy obraz wymaga średnio trzech płatnych prób twórczych, wydatek generowania wynosi $7.20: 100 × 3 × $0.024. Jeśli błąd potwierdzenia dodatkowo duplikuje jedno wysłanie dla każdego końcowego obrazu, dodaje 100 × $0.024 = $2.40, zwiększając wydatek do $9.60. To przykłady planowania, nie zmierzony odsetek sukcesu.

Zmiana limitu HTTP nie skraca twórczego procesu trzech prób do jednej. Możesz usunąć przypadkową czwartą próbę. Licz świadome warianty i przypadkowe duplikaty osobno, aby widzieć, za który problem płacisz.

W małym przepływie twórcy ustal limit przed generowaniem: może jeden początkowy obraz i dwie poprawione próby dla konkretnego miejsca. To sugestia budżetu aplikacji, nie limit platformy. Jeśli wszystkie trzy pomijają to samo wymaganie, przestań kupować niemal identyczne żądania i zmień podejście.

Ukończony obraz NSFW nie realizuje opisu: zmień jedną istotną rzecz

Jeśli twarz jest właściwa, lecz pokój lub strój nie, celowa edycja może być lepszym kolejnym zakupem niż całkowicie nowe text-to-image. Zachowaj użyteczny wynik, opisz zmianę i wybierz model z odpowiednim zadaniem edycji. Edycja nadal kosztuje; nie jest bezpłatną poprawką w cenie pierwotnego generowania.

Jeśli to samo żądanie stale daje złagodzoną scenę, najpierw ustal, czy problemem jest odmowa treści, zachowawcza interpretacja dozwolonego żądania czy przeciążony prompt. Powtarzanie identycznego promptu nie mówi, co się wydarzyło. Patrz na dostarczony obraz i stały kod błędu, jeśli istnieje, zamiast traktować NSFW jako uniwersalny przełącznik.

Jako niedosłowny przykład planowania opis portretu może wymagać jednej fikcyjnej dorosłej postaci, ciemnej satynowej marynarki, siedzącej pozy, ciepłego światła bocznego i niezatłoczonego pokoju. Jeśli każdy wynik daje zatłoczony pokój, usuń drugorzędne detale scenografii, pozostawiając postać i światło. Jeśli pojawia się zła twarz, przejdź do odpowiedniego przepływu referencji zamiast dodawać przymiotniki do czysto tekstowego promptu.

Gdy potrzebny jest prawdziwie nowy wariant, użyj nowej operacji i klucza. Powtórzenie pierwszego przyjętego żądania z pierwotnym kluczem odzyskuje pierwsze zadanie; nie prosi modelu o wymyślenie lepszego drugiego obrazu. Jeśli zmieniasz seed dla wariantu, zapisz go jako nową próbę twórczą. Seed pomaga identyfikować żądanie, ale nie gwarantuje tej samej postaci między różnymi modelami.

Po pierwszych kilku próbach porównaj końcowy koszt użytecznego obrazu, nie tylko reklamowaną cenę początkową. Generowanie za $0.010 użyte cztery razy kosztuje $0.040. Generowanie za $0.024 użyte raz kosztuje $0.024. Ta arytmetyka nie dowodzi większej niezawodności drugiego modelu; pokazuje, co mierzyć dla własnego opisu postaci.

Gdy istniejącego obrazu nie da się pobrać

Nie regeneruj udanego obrazu dlatego, że pobieranie zwróciło błąd. Plik może nadal istnieć, mimo że tymczasowy link dostępu przestał działać, albo aplikacja mogła zawieść podczas kopiowania.

Zachowaj ukończone zadanie i tożsamość zasobu wyjściowego. Odzyskaj aktualną autoryzowaną ścieżkę pobierania, dopóki wynik jest przechowywany, a potem ponów transfer tego zasobu. Nie dołączaj klucza API do osobnego podpisanego URL mediów. Potwierdź, że miejsce docelowe faktycznie zawiera bajty, zanim pokażesz Zapisano w bibliotece klienta.

Poradnik dostarczania mediów omawia kopiowanie wyników do własnego magazynu. Dla twórcy dla dorosłych jest to również granica prywatności: wygenerowany obraz lub referencja nie stają się publicznym zasobem galerii tylko dlatego, że kopiowanie się udało. Odzyskiwanie powinno zachować zamierzony prywatny dostęp.

Jeśli pierwotny wynik został już usunięty według obowiązującej polityki retencji zadania, ID nie przywróci brakujących bajtów. Zastępstwo będzie nowym generowaniem i może wyglądać inaczej. Wyjaśnij klientowi różnicę zamiast po cichu zastępować stary portret nowym i płatnym.

Dopasuj następne działanie klienta do opłaty

Pokazuj razem status istniejącego zadania i rozliczoną opłatę. Jeśli zadanie pozostaje nierozstrzygnięte, zachowaj jego miejsce w projekcie bez przedstawiania świeżego płatnego ponowienia jako jedynej drogi. Jeśli zawiodło, pokaż powód i informację o zwolnieniu blokady. Jeśli się udało, oddziel Pobierz ponownie od Wygeneruj kolejny wariant.

Dla wsparcia użyteczne są ID zadania, ID żądania, jeśli jest dostępne, czas, kwota i krótki opis problemu. Utworzenie dwóch różnych ID zadań różni się od dwukrotnego rozliczenia jednego. Zasady zwrotów wyraźnie proszą o zgłoszenie podwójnych opłat, opłat powyżej blokady, niedostarczonych udanych wyników lub niezwróconych blokad nieudanych zadań w ciągu 24 godzin. Nie umieszczaj kluczy API, podpisanych linków mediów lub wrażliwych promptów twórczych w zwykłych logach ani zrzutach dla wsparcia.

Twórca powinien rozumieć historię jako „zamówiono jeden portret, odzyskano jedno wysłanie, dostarczono jeden wynik” zamiast listy niewidocznych prób HTTP. Do tego zmierzaj: odzyskiwanie sieci zachowuje pierwotny zakup, a kolejna próba twórcza jest świadomą decyzją z widoczną ceną.