Übersicht
GoModel stellt die OpenAI-kompatiblen Bild-Endpunkte für Generierung und Bearbeitung bereit. Clients und SDKs, die bereits OpenAIs/v1/images/generations oder /v1/images/edits aufrufen, können unverändert
auf GoModel zeigen.
Requests werden nach Modell über dieselbe Registry geroutet, die auch für
Chat und Embeddings verwendet wird. Daher gelten die Auswahl über model,
provider-Hinweise, virtuelle Modelle, Modellzugriffsregeln pro Key
(User Paths), Budgets und
Rate-Limits. Bildgenerierung wird von OpenAI und
den OpenAI-kompatiblen Providern bedient, die den Endpunkt implementieren
(Azure OpenAI, OpenRouter, xAI), sowie von
Google Gemini – Gemini-Bildmodelle über die native API,
dazu Imagen auf Vertex AI. Bildbearbeitung wird von
OpenAI und Azure OpenAI bedient, von Gemini-Bildmodellen
(gemini-2.5-flash-image, …) sowie von jedem OpenAI-kompatiblen Provider,
der OpenAIs Multipart-Upload auf /images/edits akzeptiert. Ein Provider ohne
diese Fähigkeit liefert einen eindeutigen Fehler
model "…" does not support image generation (bzw. image edits), statt
falsch zu routen, und reine Bildmodelle werden bei Providern ohne
Bildunterstützung in /v1/models ausgeblendet.
Unterstützte Endpunkte
Ein Bild generieren
model und prompt sind erforderlich. Jedes andere Feld – n, size,
quality, style, response_format, background, output_format,
output_compression, moderation, user und jeder künftige Parameter – wird
unverändert an den Provider weitergeleitet, sodass modellspezifische
Optionen ohne Update des Gateways funktionieren. Der Provider entscheidet,
welche Werte er akzeptiert, und gibt andernfalls einen eigenen Fehler zurück.
Die Ausnahme ist der native Adapter für Gemini, der n und size in ihre
nativen Entsprechungen übersetzt – siehe Google Gemini.
Die Response ist die OpenAI-Bild-Hülle. Einträge in data[] enthalten
entweder eine gehostete url (DALL·E, response_format: "url") oder
eingebettetes b64_json (gpt-image-1 liefert immer Base64). GoModel ergänzt
ein Feld provider, das den Provider-Typ nennt, der den Request bedient hat;
alles andere wird durchgereicht, einschließlich des usage-Blocks und der
zurückgegebenen Ausgabeparameter, die gpt-image-1 meldet.
Ein Bild bearbeiten
Bei Bearbeitungen werden das oder die Quellbilder und eine optionale Maske alsmultipart/form-data hochgeladen, genau wie es der Endpunkt von OpenAI
erwartet. image, prompt und model sind erforderlich; senden Sie mehrere
Quellbilder als image[] (gpt-image-1 akzeptiert bis zu 16). Eine mask ist
ein PNG, dessen transparente Pixel den zu ändernden Bereich markieren.
n, size,
quality, response_format, background, output_format,
input_fidelity, user, …) unverändert an den Provider weitergeleitet. Die
hochgeladenen Dateien zählen zum Limit des Gateways für den Request-Body
(BODY_SIZE_LIMIT).
Kostenerfassung
Bildaufrufe werden in der Nutzungserfassung unter den Endpunkten/v1/images/generations und /v1/images/edits erfasst:
Der Prompt wird immer mit input_per_mtok bepreist, wenn der Provider
Eingabe-Tokens meldet. Die generierten Bilder werden auf eine von zwei
Arten abgerechnet, niemals auf beide – die gemeldete Nutzung entscheidet:
- Tokenbasiert abgerechnete Modelle (
gpt-image-1, Gemini-Bildmodelle) meldenusage. GoModel speichert die Token-Zahlen und bepreist die generierten Tokens mit dem Satzoutput_image_per_mtokdes Modells (mit Rückfall aufoutput_per_mtok). Der Satz für Bildausgaben ist derjenige, den Provider hier berechnen:gpt-image-1hat überhaupt keinen Preis für Textausgaben, und Gemini 3 Pro Image berechnet Bildausgaben mit $120/Mtok gegenüber $12/Mtok für Text. Diese Bepreisung ist für jede Größe und Qualität exakt. - Pro Bild abgerechnete Modelle (DALL·E,
grok-imagine-image, Imagen) melden keine Tokens. GoModel erfasst die Anzahl der zurückgegebenen Bilder (imagesin den Roh-Nutzungsdaten) und bepreist sie mit dem Satzper_imagedes Modells.
per_image das pauschale Äquivalent der Tokens eines typischen Bildes ist
($0.039 für ein gemini-2.5-flash-image mit 1290 Tokens). Eine Response, die
generierte Tokens gemeldet hat, wird allein nach diesen Tokens bepreist, die
beiden Sätze werden also nie addiert.
Kann die Preisgestaltung die generierten Bilder nicht bepreisen – kein Satz
für die gemeldeten Bildausgabe-Tokens oder keine gemeldeten Ausgabe-Tokens und
kein Satz per_image/per_request –, wird die Nutzungszeile mit einem
Vorbehalt zur Kostenberechnung markiert, sodass sie als „nicht gemeldete
Nutzung“ erscheint und nicht als kostenloser Aufruf.
Setzen Sie per_image über eine
Preisüberschreibung oder in
config.yaml, wenn der Modellkatalog keinen Preis für ein Bildmodell enthält:
Einschränkungen
Die Bild-Endpunkte sind eine schlanke, nach Modell geroutete Weiterleitung an den Provider und durchlaufen nicht den vollständigen Inferenz-Orchestrator. Im Vergleich zu/v1/chat/completions:
- Kein Failover, keine Guardrails, kein Response-Cache – diese Stufen werden übersprungen. Requests werden dennoch autorisiert, gegen Budgets geprüft, Rate-Limits unterworfen, gemessen und in das Audit-Log geschrieben.
- Kein Streaming –
stream: truewird mit400abgelehnt, weil gestreamte Bildgenerierung als Server-Sent Events geliefert wird, die diese Endpunkte nicht weiterreichen. Lassen Siestreamweg (oder setzen Sie es auffalse), um die vollständige JSON-Response zu erhalten. - Variationen (
/v1/images/variations) werden nicht bereitgestellt. Verwenden Sie die Passthrough-API (/p/{provider}/v1/images/...), um sie bei einem bestimmten Provider zu erreichen. - Request-Format von OpenAI als Eingabe – Die nativen Bild-APIs von Google
Gemini (Imagen
predict,generateContentfür Gemini-Bildmodelle) werden hinter diesen Endpunkten übersetzt; siehe die Hinweise zu Providern unten. Andere Provider, deren native Bild-API von der OpenAI-API abweicht, werden nicht übersetzt; verwenden Sie für diese Passthrough.
Google Gemini
Mit dem Gemini-Provider im nativen API-Modus (Standard) generieren Gemini-Bildmodelle (gemini-2.5-flash-image, …) über generateContent und
imagen-*-Modelle über die predict-API von Imagen. Google hat Imagen am
17. August 2026 aus der Gemini API (AI Studio) entfernt – verwenden Sie dort
ein Gemini-Bildmodell; Imagen bleibt auf Vertex AI
verfügbar.
- Gemini-Bildmodelle unterstützen keine Ausgabe mehrerer Kandidaten, daher
wird
n(bis zu 10) alsnparallelegenerateContent-Aufrufe bedient, deren Ergebnisse zusammengeführt werden – jeder Aufruf wird von Google abgerechnet. Bei Imagen wirdnaufsampleCountabgebildet;sizewird auf das nächstgelegene unterstützte Seitenverhältnis abgebildet (1024x1024→1:1,1536x1024→3:2, …), und ein direkt angegebenes Verhältnis wie"16:9"wird durchgereicht. Unbekannte JSON-Felder werden unverändert weitergeleitet, sodass native Parameter (personGeneration,sampleImageSize,imageConfig, …) ohne Anpassung funktionieren. - Bilder werden immer als
b64_jsonzurückgegeben. Text, den ein Gemini-Bildmodell zusätzlich zum Bild erzeugt, wird alsrevised_promptausgegeben. - Gemini-Bildmodelle melden Token-
usage(tokenbasiert abgerechnet); Imagen meldet keine (bepreisen Sie es mitper_image). - Bearbeitungen funktionieren nur mit Gemini-Bildmodellen: Uploads werden zu
eingebetteten Bildteilen vor dem Prompt.
maskwird nicht unterstützt – beschreiben Sie den zu ändernden Bereich im Prompt. Imagen-Modelle können nur generieren.
/openai/images/generations weitergeleitet, und Bearbeitungen werden
abgelehnt (diese Schnittstelle hat keinen Bearbeitungs-Endpunkt).
Audit-Logging
Bild-Requests erscheinen im Audit-Log wie jede andere Modellinteraktion. WennLOGGING_LOG_BODIES aktiviert ist:
- Der Generierungs-Request wird als JSON gespeichert. Ein Bearbeitungs-Request wird als Bild-Body gespeichert: Prompt und Parameter sowie ein Element pro hochgeladenem Quellbild und pro Maske (Dateiname, Content-Type, Größe).
- Die Response wird ebenfalls als Bild-Body gespeichert – die Hülle
(
created,usage,size,quality, …) sowie ein Element pro zurückgegebenem Bild. Gehostete URLs bleiben als Links erhalten.
LOGGING_LOG_IMAGE_BODIES=true ist
gesetzt. Ist die Option aktiv, werden Uploads und generierte Bilder in den
Medienspeicher geschrieben, und
jedes Element enthält eine media_id, die das Dashboard über
GET /admin/media/{id} direkt anzeigt; LOGGING_LOG_IMAGE_BODIES_SCOPE
beschränkt dies auf input (Uploads für Bearbeitungen) oder output
(Ergebnisse). Ohne die Option ist jedes Bild ein Platzhalter mit Größenangabe
(stored: false). In beiden Fällen bleibt der Eintrag klein und vollständig –
er erreicht nie die allgemeine Kürzung von Bodys bei 1 MB, selbst bei großen
b64_json-Ergebnissen, und es gibt keine Obergrenze für gespeicherte Bilder
pro Eintrag. Dateien werden so lange aufbewahrt wie die Audit-Einträge, die
auf sie verweisen (LOGGING_RETENTION_DAYS).