Przegląd
GoModel udostępnia endpointy obrazów kompatybilne z OpenAI do generowania i edycji. Klienci i SDK, które już wywołują/v1/images/generations
lub /v1/images/edits w OpenAI, mogą bez zmian wskazać na GoModel.
Requesty są routowane według modelu przez ten sam rejestr, którego używają czat i
embeddingi, więc obowiązują wybór model, wskazówki provider, modele wirtualne, reguły dostępu
do modeli per klucz (ścieżki użytkownika), budżety
i rate limity. Generowanie obrazów obsługują
OpenAI i providerzy kompatybilni z OpenAI, którzy implementują ten endpoint
(Azure OpenAI, OpenRouter, xAI), oraz
Google Gemini – modele obrazowe Gemini przez natywne
API, a także Imagen w Vertex AI. Edycję obrazów obsługują
OpenAI i Azure OpenAI,
modele obrazowe Gemini (gemini-2.5-flash-image, …) oraz każdy
provider kompatybilny z OpenAI, który akceptuje multipartowy upload OpenAI na
/images/edits. Provider bez tej możliwości zwraca
czytelny błąd model "…" does not support image generation (lub image edits),
zamiast błędnie routować request, a modele wyłącznie obrazowe są ukryte w /v1/models dla
providerów bez obsługi obrazów.
Obsługiwane endpointy
Generowanie obrazu
model i prompt są wymagane. Każde inne pole – n, size, quality,
style, response_format, background, output_format, output_compression,
moderation, user i każdy przyszły parametr – jest przekazywane do providera
bez zmian, więc opcje specyficzne dla modelu działają bez aktualizacji gatewaya.
Provider decyduje, jakie wartości akceptuje, a w przeciwnym razie zwraca własny błąd.
Wyjątkiem jest natywny adapter Gemini, który tłumaczy n i size na
ich natywne odpowiedniki – zobacz Google Gemini.
Odpowiedź to koperta obrazów OpenAI. Wpisy data[] zawierają albo
hostowany url (DALL·E, response_format: "url"), albo osadzony b64_json
(gpt-image-1 zawsze zwraca base64). GoModel dodaje pole provider z nazwą
typu providera, który obsłużył request; wszystko inne jest przekazywane bez zmian,
w tym blok usage i odsyłane parametry wyjściowe raportowane przez gpt-image-1.
Edycja obrazu
Edycja przesyła obraz(y) źródłowe i opcjonalną maskę jakomultipart/form-data,
dokładnie tak, jak oczekuje tego endpoint OpenAI. image, prompt i model są
wymagane; kilka obrazów źródłowych wyślij jako image[] (gpt-image-1 akceptuje do
16). mask to plik PNG, którego przezroczyste piksele oznaczają obszar do zmiany.
n, size, quality,
response_format, background, output_format, input_fidelity, user, …)
jest przekazywane do providera bez zmian. Przesłane pliki wliczają się do
limitu rozmiaru body requestu w gatewayu (BODY_SIZE_LIMIT).
Śledzenie kosztów
Wywołania obrazów są zapisywane w śledzeniu użycia pod endpointami/v1/images/generations i /v1/images/edits:
Prompt jest zawsze wyceniany według input_per_mtok, gdy provider raportuje tokeny
wejściowe. Wygenerowane obrazy są rozliczane na jeden z dwóch sposobów, nigdy oba naraz –
decyduje o tym raportowane użycie:
- Modele rozliczane za tokeny (
gpt-image-1, modele obrazowe Gemini) raportująusage. GoModel zapisuje liczby tokenów i wycenia wygenerowane tokeny stawkąoutput_image_per_mtokmodelu (z powrotem dooutput_per_mtok, jeśli jej brak). To właśnie stawkę za obrazy wyjściowe naliczają tu providerzy:gpt-image-1w ogóle nie ma ceny za tekst wyjściowy, a Gemini 3 Pro Image nalicza za obrazy wyjściowe $120/Mtok wobec $12/Mtok za tekst. Taka wycena jest dokładna dla każdego rozmiaru i jakości. - Modele rozliczane za obraz (DALL·E,
grok-imagine-image, Imagen) nie raportują tokenów. GoModel zapisuje liczbę zwróconych obrazów (imagesw surowych danych użycia) i wycenia ją stawkąper_imagemodelu.
per_image
to ryczałtowy odpowiednik tokenów jednego typowego obrazu ($0.039 dla 1290 tokenów
gemini-2.5-flash-image). Odpowiedź, która zaraportowała wygenerowane tokeny, jest wyceniana
wyłącznie według tych tokenów, więc obie stawki nigdy się nie sumują.
Gdy cennik nie pozwala wycenić wygenerowanych obrazów – brak stawki dla wyjściowych tokenów
obrazu zaraportowanych w odpowiedzi albo brak zaraportowanych tokenów wyjściowych i brak
stawki per_image/per_request – wiersz użycia jest oznaczany
zastrzeżeniem dotyczącym obliczenia kosztu, żeby był czytany jako „niezaraportowane użycie”, a nie darmowe
wywołanie.
Ustaw per_image przez nadpisanie cennika
lub w config.yaml, gdy katalog modeli nie ma ceny dla modelu obrazowego:
Ograniczenia
Endpointy obrazów to cienka, routowana według modelu warstwa przekazująca do providera i nie przechodzą przez pełny orkiestrator inferencji. W porównaniu z/v1/chat/completions:
- Brak failoveru, guardrails i cache’u odpowiedzi – te etapy są pomijane. Requesty są nadal autoryzowane, sprawdzane pod kątem budżetu, objęte limitem żądań, mierzone i zapisywane w logu audytowym.
- Brak streamingu –
stream: truejest odrzucane z kodem400, bo streamowane generowanie obrazów jest dostarczane jako server-sent events, których te endpointy nie przekazują. Pomiństream(lub ustaw je nafalse), żeby otrzymać kompletną odpowiedź JSON. - Wariacje (
/v1/images/variations) nie są udostępniane. Użyj passthrough API (/p/{provider}/v1/images/...), żeby dotrzeć do nich u konkretnego providera. - Na wejściu kształt requestu OpenAI – natywne API obrazów Google Gemini (Imagen
predict,generateContentmodeli obrazowych Gemini) są tłumaczone za tymi endpointami; zobacz uwagi o providerze poniżej. Inni providerzy, których natywne API obrazów różni się od OpenAI, nie są tłumaczeni; dla nich użyj passthrough.
Google Gemini
Gdy provider Gemini działa w trybie natywnego API (domyślnie), modele obrazowe Gemini (gemini-2.5-flash-image, …) generują przez generateContent,
a modele imagen-* przez API predict Imagen. Google wycofał Imagen
z Gemini API (AI Studio) 17 sierpnia 2026 – używaj tam modelu obrazowego Gemini;
Imagen pozostaje dostępny w Vertex AI.
- Modele obrazowe Gemini nie obsługują wielu kandydatów na wyjściu, więc
n(do 10) jest realizowane jakonrównoległych wywołańgenerateContent, których wyniki są scalane – każde wywołanie jest rozliczane przez Google. Dla Imagennmapuje się nasampleCount;sizemapuje się na najbliższe obsługiwane proporcje (1024x1024→1:1,1536x1024→3:2, …), a surowe proporcje, takie jak"16:9", są przekazywane bez zmian. Nieznane pola JSON są przekazywane dosłownie, więc parametry natywne (personGeneration,sampleImageSize,imageConfig, …) działają bez zmian. - Obrazy są zawsze zwracane jako
b64_json. Tekst, który model obrazowy Gemini wygeneruje obok obrazu, jest udostępniany jakorevised_prompt. - Modele obrazowe Gemini raportują
usagew tokenach (rozliczane za tokeny); Imagen nie raportuje nic (wyceniaj go przezper_image). - Edycja działa tylko z modelami obrazowymi Gemini: uploady stają się osadzonymi częściami
obrazu przed promptem.
masknie jest obsługiwane – opisz w prompcie obszar do zmiany. Modele Imagen tylko generują.
/openai/images/generations, a edycje są odrzucane (ten interfejs nie ma
endpointu edycji).
Logowanie audytowe
Requesty obrazów pojawiają się w logu audytowym jak każda inna interakcja z modelem. GdyLOGGING_LOG_BODIES jest włączone:
- Request generowania jest zapisywany jako JSON. Request edycji jest zapisywany jako body obrazu: prompt i parametry oraz jeden element na każdy przesłany obraz źródłowy i maskę (nazwa pliku, typ zawartości, rozmiar).
- Odpowiedź również jest zapisywana jako body obrazu – koperta (
created,usage,size,quality, …) oraz jeden element na każdy zwrócony obraz. Hostowane URL-e są zachowywane jako linki.
LOGGING_LOG_IMAGE_BODIES=true. Gdy
jest włączone, uploady i wygenerowane obrazy są zapisywane w
storage’u mediów, a każdy element zawiera
media_id, który dashboard wyświetla bezpośrednio przez GET /admin/media/{id};
LOGGING_LOG_IMAGE_BODIES_SCOPE ogranicza to do input (uploady do edycji) lub
output (wyniki). Bez tego ustawienia każdy obraz to placeholder z rozmiarem
(stored: false). W obu przypadkach wpis pozostaje mały i kompletny – nigdy
nie podlega ogólnemu obcinaniu body do 1 MB, nawet przy dużych wynikach b64_json, i
nie ma limitu zapisanych obrazów na wpis. Pliki są przechowywane tak długo jak
wpisy audytowe, które się do nich odwołują (LOGGING_RETENTION_DAYS).