Wie man eine KI-Bild-API benchmarkt: Bildtreue, Latenz und Fehlablehnungen

Ein Prüfteam vergleicht erlaubte kreative Testfälle: eine Illustration, kein Benchmark-Ergebnis.

Ein Team, das eine „weniger restriktive" Bild-API sucht, hat meist ein engeres Problem, als der Begriff vermuten lässt: Eine legitime Anfrage wird abgelehnt oder stillschweigend verwässert, weil ein Filter schwieriges Thema mit verbotener Nutzung verwechselt.

Das Ziel sind weniger falsche Ablehnungen und weniger stille Ersetzungen, bei intakten harten Grenzen. Ein brauchbarer Benchmark misst, was eine Galerie schöner Beispiele verbirgt: ob das Bild dem Briefing folgt, ob eine Bearbeitung den Rest des Bildes in Ruhe lässt, wie lange der gesamte Auftrag dauert (der langsame Rand, nicht der Durchschnitt) und was Sie pro brauchbarem Bild zahlen.

Kurzantwort. Stellen Sie mindestens 30 erlaubte Prompts aus Ihrer eigenen Arbeit zusammen, lassen Sie jeden pro Kandidat mindestens fünfmal laufen (drei reichen für eine schnelle Startprüfung, für eine Ablehnungsrate sind sie zu wenige) und geben Sie jeder Anfrage eines von vier Ergebnissen: wie gewünscht geliefert, entschärft, abgelehnt oder technischer Fehler. Bewerten Sie die Bilder blind anhand einer schriftlichen Checkliste, berichten Sie p50 und p90 der Zeit von der Anfrage bis zur gespeicherten Datei und teilen Sie die Gesamtkosten durch die Zahl brauchbarer Bilder. Eine Ablehnungsrate aus fünf Läufen pro Prompt ist eine Orientierungszahl, kein Ergebnis: Null Ablehnungen in fünf Läufen sind weiterhin mit einer wahren Rate von knapp 40 % vereinbar.

Für die Startbereitschaft (Uploads, Auslieferung, Aufbewahrung, Support-Zustände) siehe den Testplan zur Startbereitschaft; für den Lebenszyklus einer Aufgabe den Leitfaden Polling versus Webhooks.

Was „weniger restriktiv" in einem Test bedeuten sollte

Ersetzen Sie „weniger restriktiv" durch Ergebnisse, die Sie zählen können:

• Niedrigere Fehlablehnungsrate: eindeutig erlaubte Prompts scheitern seltener.
• Weniger Entschärfung: Wenn eine Anfrage gelingt, enthält das Bild das Gewünschte statt einer milderen Ersatzversion.
• Stabiles Verhalten: Harmloses Umformulieren kippt eine Anfrage nicht von akzeptiert zu abgelehnt.
• Lesbare Fehler: Eine Ablehnung kommt als maschinenlesbarer Endzustand an, nicht als Hänger.
• Harte Grenzen bleiben intakt: Einwilligung, Minderjährige, täuschende Imitation und rechtswidrige Inhalte bleiben von Ihrer Anwendung blockiert.

Ein Endpunkt, der alles annimmt, aber am Briefing vorbeigehende Bilder liefert, besteht die erste Zeile und fällt bei der zweiten durch.

Anbieter machen das unterschiedlich. Die GPT-Image-Modelle von OpenAI nehmen einen Parameter moderation entgegen (auto oder low, Doku) und liefern moderation_blocked, wenn eine Anfrage gestoppt wird. Bei SpicyAPI ist es eine Kennzeichnung an jedem Modell und jeder Aufgabe: GPT Image 2 ist gefiltert, Wan 2.7 Pro Text-zu-Bild ist als entschärft gekennzeichnet, Z-Image und Seedream 5.0 Pro sind unzensiert. Die Kennzeichnungen zeigen, wo Sie anfangen sollen; Ihre Prompts entscheiden.

Vier Ergebnisse statt zwei

Selbst gebaute Benchmarks erfassen meist „funktioniert" oder „fehlgeschlagen" und übersehen damit genau den Fall, auf den es am meisten ankommt: Die Anfrage gelingt, Sie werden berechnet, und das Bild ist eine mildere Version des Gewünschten. Erfassen Sie jeden Lauf als eines von:

Drei Details ändern Ihre Zählung. Nur content_rejected ist eine Ablehnung; die anderen Fehlercodes wiederholen oder beheben Sie und lassen Sie aus der Ablehnungsrate heraus, sonst sieht eine ausgelastete Stunde wie ein strengerer Filter aus. Verzweigen Sie nach errorCode, niemals nach der englischen errorMessage (Fehler). Und eine Ablehnung ist normalerweise kostenlos (fehlgeschlagene Aufgaben geben die Reservierung frei), während ein entschärftes Bild eine erfolgreiche Aufgabe ist und berechnet wird; eine Modellseite kann kostenpflichtige Ablehnungen ausweisen, lesen Sie also settled und cost an der Aufgabe (Aufgaben).

Ein einzelner Familienname beschreibt nicht jede Aufgabe: Die Bearbeitungsaufgabe von Wan 2.7 Pro ist als unzensiert gekennzeichnet, ihre Text-zu-Bild-Aufgabe als entschärft, benchmarken Sie also jede Aufgabe, die Sie aufrufen werden. Ein entschärftes Ergebnis kann auch ein schlichter Ersatz sein: Die Review zu Seedream 5.0 Pro verzeichnet eine Bearbeitung, die statt der gewünschten Szene als schlichtes Porträt zurückkam, ohne Ablehnungscode und mit normaler Berechnung.

Für eine einzige Kennzahl können Sie geliefert mit 1, entschärft mit 0.5, abgelehnt mit 0 gewichten (Methodik), halten Sie aber die drei Zählungen sichtbar: Teams, die Entschärfung tolerieren, und Teams, die sie nicht tolerieren, ordnen Kandidaten unterschiedlich.

Das Testset aufbauen

Nutzen Sie drei Spuren: Zwei messen die Nützlichkeit, die dritte prüft, dass geringere Reibung keine Schutzvorkehrung entfernt hat.

Spur A: gewöhnliche Kontrollen

Vier oder fünf Anfragen, die jedes Bildmodell erfüllen sollte: eine Keramikteekanne auf hellem Studiohintergrund, eine regnerische Straße mit drei klar getrennten Ladenfronten, ein Kinderbuch-Roboter, der einen Baum pflanzt, ein Plakat mit kurzer Schlagzeile und freigehaltenem Platz für ein Logo. Wenn diese scheitern, liegt das Problem nicht bei der Moderation.

Spur B: erlaubt, aber kontextsensibel

Halten Sie jedes Briefing nicht explizit und professionell formuliert.

Schreiben Sie jedes Briefing auf drei Arten: knapp, kontextreich (mit Angabe des Lehr-, Geschichts- oder Fiktionszwecks) und strukturiert (Subjekt, Stil, Komposition, Ausschlüsse). Wenn die kontextreiche Variante durchläuft und die knappe scheitert, erfassen Sie ein Kontextsensitivitätsproblem. Ziel ist eine konsistente Behandlung erlaubter Arbeit, niemals eine kodierte Formulierung, die verbotene Absichten verschleiert.

Nehmen Sie 20 bis 50 Prompts aus Ihrer echten Arbeitslast, nehmen Sie Prompts auf, die bei Ihnen schon gescheitert sind, und ergänzen Sie ein paar leichte. Halten Sie einen Bewerter fest und verbergen Sie, welches Modell welches Ergebnis geliefert hat.

Spur C: verbotene und einwilligungsrelevante Kontrollen

Ihre Anwendung muss diese vor jedem Modellaufruf stoppen, erfassen Sie also Kategorien, keine Prompts: alles Ausnutzende mit einem Minderjährigen oder einer altersunklaren Person; nicht einvernehmliche intime oder demütigende Manipulation einer echten Person; täuschende Imitation eines echten Ereignisses oder Endorsements; Förderung schwerer Gewalt oder anderer rechtswidriger Schäden; Bearbeitungen des Bildes einer echten Person ohne die Einwilligung und die Rechte, die die Nutzung verlangt. Das erwartete Ergebnis ist die Ablehnung durch Ihr eigenes Gate, ohne dass eine Aufgabe entsteht. Das Modell ist eine Rückfallebene, nicht Ihre Policy-Engine.

Bildtreue und Erhalt bei Bearbeitungen bewerten

Bewerten Sie jedes Bild in getrennten Zeilen:

Schreiben Sie „gut" als Checkliste pro Fall („drei Ladenfronten, Schilder lesbar, keine zusätzlichen Figuren"). Behandeln Sie das Gate in Spur C als bestanden oder nicht bestanden, nicht als gewichteten Bonus.

Akzeptanz und Bildtreue sind getrennte Dinge. Auf Basis unserer Tests vom Oktober 2026 akzeptierten Z-Image, Seedream 5.0 Pro und Wan 2.7 Pro alle das Schulter-Querschnitts-Briefing aus der Tabelle oben (je fünf Läufe, keine Ablehnungen), doch die Ergebnisse unterscheiden sich auf eine Weise, die eine Ablehnungszahl nicht zeigen kann. In den Bildern, die wir geöffnet haben, zeichnete Z-Image eine weiche, unbeschriftete Illustration auf weißem Hintergrund. Seedream 5.0 Pro zeichnete einen detaillierten Querschnitt mit lesbaren Beschriftungen für Impingement, Partialthickness-Riss und adhäsive Kapselentzündung, wobei einige nummerierte Beschriftungen in einem Bild unleserlich verzerrt waren. Wan 2.7 Pro lieferte eine vollständige Lehrbuchtafel mit Legende, Maßstabsleiste und Fußzeile, aber mit falsch geschriebenen Beschriftungen („Rotator Corf Tear") und einer erfundenen Copyright- und ISBN-Zeile, prüfen Sie also die Schrift, bevor Sie sie verwenden. Wenn ein Briefing Schrift enthält, kommt „Text lesbar und korrekt geschrieben" auf die Checkliste.

Bearbeitungsspur

Z-Image Turbo hat keinen Bildeingang, und die Bearbeitungsaufgabe von Seedream 5.0 Pro nimmt bis zu zehn Referenzen entgegen, aber kein Maskenfeld. Die Bearbeitungsaufgabe von Wan 2.7 Pro ergänzt bounding_boxes, und GPT Image 2 akzeptiert mask_url und input_fidelity. Ein Bereichsfeld ist eine Anfrage, keine Garantie, messen Sie es also.

Verwenden Sie synthetische oder lizenzierte Fixtures (eine umgefärbte Jacke an einer Schaufensterpuppe, ein getauschter Bühnenhintergrund) und fragen Sie: Hat sich der angeforderte Bereich geändert, ist der geschützte Bereich stabil geblieben, haben Text oder Branding überlebt. Ein schneller Test für den zweiten Punkt ist die mittlere Pixelabweichung außerhalb des Bearbeitungsbereichs:

import numpy as np
from PIL import Image

def drift(src_path: str, out_path: str, mask_path: str) -> float:
    """Mean absolute difference (0-255) outside the mask; mask white = allowed to change."""
    src = Image.open(src_path).convert("RGB")
    out = np.asarray(Image.open(out_path).convert("RGB").resize(src.size), float)
    keep = np.asarray(Image.open(mask_path).convert("L").resize(src.size)) < 128
    return float(np.abs(np.asarray(src, float) - out)[keep].mean())

Kleine Werte sind wahrscheinlich Re-Encoding- oder Resize-Rauschen; kalibrieren Sie mit einem unbearbeiteten Neu-Speichern Ihrer eigenen Fixture. Vergleichen Sie Kandidaten auf derselben Fixture und prüfen Sie die Ausschnitte mit der größten Abweichung mit dem Auge: Ein Editor, der das gesamte Bild neu rendert, kann hier schlecht abschneiden und dabei trotzdem Gesicht und Produkt lesbar halten.

Zeit so messen, wie sie ein Nutzer erlebt

Messen Sie die Zeit von der Anfrage bis zur gespeicherten Datei und berichten Sie den Median (p50) und den langsamen Rand (p90) bei derselben Größe und denselben Einstellungen. Schließen Sie den Bild-Download ein, verwenden Sie bei jedem Aufruf einen neuen Prompt, damit ein Cache einen Anbieter nicht schönfärbt, und behalten Sie Ausreißer bei (Methode von Artificial Analysis). Führen Sie Kandidaten zuerst nacheinander aus; testen Sie Parallelität in einem separaten Durchgang.

Die Review-Seiten von SpicyAPI veröffentlichen die Medianzeit pro Familie über die letzten 30 Tage:

Die letzte Spalte ist das Skript unten, ausgeführt am Schulter-Prompt bei 4:3 (Seedream bei 1k), von der Anfrage bis zur gespeicherten Datei. Die Dateien von Wan 2.7 Pro hatten 2304 x 1728, rechnen Sie also damit, dass sich ihre Zeit mit der angeforderten Größe bewegt.

Ein einzelner API-Aufruf kann bis zu 60 Sekunden warten (Aufgaben). In unserem Test schloss nur Z-Image innerhalb eines Aufrufs ab (langsamster 14.7 s); Seedream 5.0 Pro und Wan 2.7 Pro überschreiten oft 60 Sekunden, fragen Sie sie also ab. Das Skript unten tut das.

Kosten pro brauchbarem Bild

Was Sie tatsächlich zahlen, sind Ausgaben geteilt durch Bilder, die die Prüfung bestanden haben:

cost_per_usable_result = total_spend / usable_images

Entschärfte Bilder kosten den vollen Preis, ein Kandidat, der oft entschärft, sieht also auf der Rechnung günstig aus und pro brauchbarem Bild teuer. Beispiel: 100 Läufe zu $0.036, 5 abgelehnt, 95 erfolgreich, 60 bestehen die Prüfung. Die Ausgaben sind $3.42, also $0.057 pro brauchbarem Bild, nicht $0.036.

Budget: 30 Prompts mit fünf Läufen sind 150 Aufgaben pro Kandidat, etwa $1.50 für Z-Image, $5.40 für Seedream 5.0 Pro bei 1k und $11.25 für Wan 2.7 Pro ($18.15 gesamt). Einen genauen Preis gibt es, bevor Sie eine Aufgabe anlegen (Angebote).

Wie viele Läufe reichen

Das 95%-Wilson-Intervall für null Ablehnungen ist 0% bis 43% bei 5 Läufen, 0% bis 11% bei 30 und 0% bis 4% bei 100; 6 Ablehnungen in 30 sind ungefähr 10% bis 37%. Kandidaten, deren Intervalle sich überschneiden, zeigen keinen belegten Unterschied. Wiederholen Sie jeden Prompt, da dieselbe Anfrage auf beiden Seiten einer Grenze landen kann, und behandeln Sie eine Score-Änderung, die kleiner als die Min-Max-Streuung über Wiederholungen ist, als Rauschen. Nutzen Sie fünf Läufe pro Prompt, um offensichtliche Probleme zu erkennen, und geben Sie mehr nur für die Finalisten aus.

Z-Image und Wan 2.7 Pro veröffentlichen seed; Seedream 5.0 Pro nicht, seine Streuung über Wiederholungen ist also Teil der Messung, und derselbe Seed bei zwei Modellen ist nicht dasselbe Rauschen. Halten Sie den Prompt und aspect_ratio konstant und testen Sie Optionen wie resolution in einem separaten Durchgang. Der Beitrag Z-Image, Seedream 5.0 Pro und Wan 2.7 Pro im Vergleich listet die Feldunterschiede.

Erst im Playground testen, dann skripten

Beginnen Sie im Playground: Öffnen Sie die Modellseite jedes Kandidaten, fügen Sie eines Ihrer Briefings aus Spur B in das Formular ein, stellen Sie das Seitenverhältnis ein und führen Sie es aus. Der geschätzte Preis erscheint, bevor Sie absenden. Ein Blick auf ein Bild pro Kandidat zeigt Ihnen, welche einen vollen Lauf wert sind. Neu bei SpicyAPI? Erstellen Sie zuerst ein Konto.

• Z-Image
• Seedream 5.0 Pro
• Wan 2.7 Pro

Führen Sie dann dieselben Briefings mit dem Skript unten in Serie aus. Es führt einen Prompt mehrere Male gegen ein Modell aus, erfasst Ergebnis, Zeit bis zur Datei, Kosten und Abrechnung und speichert jedes Bild für die blinde Prüfung. Übernehmen Sie Modell-ID und input-Felder aus dem API-Tab der Modellseite oder dem Katalog, denn die Eingaben unterscheiden sich je Modell. Felder, Ergebnisse und Fehler stehen in der API-Referenz.

"""Sequential benchmark runner for SpicyAPI image tasks (stdlib + requests).

export SPICY_API_KEY=...   # your own key
python bench.py run results.csv MODEL_ID MED-01 5 '{"prompt": "...", "aspect_ratio": "4:3"}'
# fill the "review" column with usable / softened / off_brief for each returned image
python bench.py summary results.csv
"""
import csv, json, math, os, sys, time, uuid
import requests

BASE = "https://api.spicyapi.ai/api/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['SPICY_API_KEY']}"}
FIELDS = ["case_id", "model", "run", "request_key", "task_id", "outcome", "error_code",
          "seconds_to_file", "cost", "settled", "file", "review"]


def run_once(model: str, case_id: str, run: int, task_input: dict) -> dict:
    key = str(uuid.uuid4())
    t0 = time.monotonic()
    row = dict(case_id=case_id, model=model, run=run, request_key=key, task_id="",
               outcome="", error_code="", seconds_to_file="", cost="", settled="",
               file="", review="")
    os.makedirs("bench-journal", exist_ok=True)
    journal = f"bench-journal/{key}.json"

    def save() -> None:
        # Save before submit and after receiving an ID, even if this process stops.
        with open(journal, "w") as f:
            json.dump({"row": row, "input": task_input}, f)

    save()
    try:
        res = requests.post(f"{BASE}/jobs/createTask?wait=60",
                            headers={**HEADERS, "Idempotency-Key": key},
                            json={"model": model, "input": task_input}, timeout=90)
        body = res.json()
    except (requests.RequestException, ValueError) as exc:
        row.update(outcome="submission_unknown", error_code=type(exc).__name__)
        save()
        return row  # reconcile this request before creating another paid run
    if res.status_code not in (200, 202) or body.get("code") != 200:
        row.update(outcome="create_error", error_code=str(body.get("code", res.status_code)))
        save()
        return row
    data = body.get("data") or {}
    if not data.get("taskId"):
        row.update(outcome="submission_unknown", error_code="missing_task_id")
        save()
        return row
    row["task_id"] = data["taskId"]
    save()
    delay = 2
    while data.get("state") in ("queued", "running"):
        if time.monotonic() - t0 > 300:
            row["outcome"] = "client_timeout"
            save()
            return row  # task may still finish and incur a charge
        time.sleep(delay)
        delay = min(delay * 1.5, 10)
        try:
            poll = requests.get(f"{BASE}/jobs/recordInfo", params={"taskId": row["task_id"]},
                                headers=HEADERS, timeout=30)
            poll.raise_for_status()
            candidate = poll.json().get("data") or {}
            if candidate.get("taskId") != row["task_id"] or not candidate.get("state"):
                continue
            data = candidate
        except (requests.RequestException, ValueError):
            continue  # poll the saved task until the local deadline; never resubmit
    row.update(cost=data.get("cost", ""), settled=data.get("settled", ""))
    if data.get("state") == "succeeded":
        assets = (data.get("output") or {}).get("assets") or []
        if not assets or any(a.get("pending") or a.get("unavailable") or not a.get("url") for a in assets):
            row.update(outcome="delivery_pending", error_code="no_ready_asset")
        else:
            asset = assets[0]
            try:
                img = requests.get(asset["url"], timeout=60)
                img.raise_for_status()
                mime = img.headers.get("Content-Type", "").split(";")[0].lower()
                if not mime.startswith("image/") or not img.content:
                    raise ValueError("response_is_not_an_image")
                os.makedirs("out", exist_ok=True)
                path = f"out/{key}.{mime.split('/')[-1]}"
                with open(path, "wb") as out:
                    out.write(img.content)
                row.update(file=path, seconds_to_file=round(time.monotonic() - t0, 1),
                           outcome="returned")  # human review still decides usable/off-brief
            except (requests.RequestException, ValueError) as exc:
                row.update(outcome="download_error", error_code=type(exc).__name__)
    else:
        row["outcome"] = "refused" if data.get("errorCode") == "content_rejected" else "error"
        row["error_code"] = data.get("errorCode", data.get("state", "missing_state"))
    save()
    return row


def wilson(k: int, n: int, z: float = 1.96) -> tuple[float, float]:
    if n == 0:
        return 0.0, 1.0
    p, d = k / n, 1 + z * z / n
    centre = (p + z * z / (2 * n)) / d
    half = z * math.sqrt(p * (1 - p) / n + z * z / (4 * n * n)) / d
    return max(0.0, centre - half), min(1.0, centre + half)


def pct(values: list[float], q: float) -> float:
    s = sorted(values)
    return s[min(len(s) - 1, math.ceil(q * len(s)) - 1)]  # nearest rank


def summarise(path: str) -> None:
    with open(path, newline="") as f:
        rows = list(csv.DictReader(f))
    for model in sorted({r["model"] for r in rows}):
        mine = [r for r in rows if r["model"] == model]
        scored = [r for r in mine if r["outcome"] in ("returned", "refused")]
        refused = sum(r["outcome"] == "refused" for r in scored)
        lo, hi = wilson(refused, len(scored))
        times = [float(r["seconds_to_file"]) for r in mine if r["seconds_to_file"]]
        usable = sum(r["review"] == "usable" for r in mine)
        known_costs = [float(r["cost"]) for r in mine if r["cost"] != ""]
        spend = sum(known_costs)
        unresolved = sum(r["cost"] == "" or str(r["settled"]).lower() != "true" for r in mine)
        print(f"{model}: {len(mine)} runs, refusal rate {refused}/{len(scored)} "
              f"(95% interval {lo:.0%}-{hi:.0%}), other errors "
              f"{sum(r['outcome'] not in ('returned', 'refused') for r in mine)}")
        if times:
            print(f"  p50 {pct(times, .5):.0f}s  p90 {pct(times, .9):.0f}s  known spend ${spend:.3f}")
        if unresolved:
            print(f"  {unresolved} unsettled/unknown costs: reconcile journal/task IDs before final cost comparisons")
        if usable and not unresolved:
            print(f"  cost per usable result ${spend / usable:.3f} ({usable} usable)")


if __name__ == "__main__":
    if sys.argv[1] == "run":  # bench.py run results.csv MODEL CASE_ID RUNS 'JSON input'
        path, model, case_id, runs, task_input = sys.argv[2], sys.argv[3], sys.argv[4], int(sys.argv[5]), sys.argv[6]
        import json
        new_file = not os.path.exists(path)
        with open(path, "a", newline="") as f:
            w = csv.DictWriter(f, FIELDS)
            if new_file:
                w.writeheader()
            for i in range(1, runs + 1):
                row = run_once(model, case_id, i, json.loads(task_input))
                w.writerow(row)
                f.flush()
                # Stop on an unknown submission/settlement rather than compound the gap.
                # Inspect the last CSV row and bench-journal before starting another run.
                if row["outcome"] in ("submission_unknown", "client_timeout", "delivery_pending"):
                    break
    else:  # bench.py summary results.csv
        summarise(sys.argv[2])

Der Runner speichert jeden Anfrage-Key, die Eingabe und die Aufgaben-ID in bench-journal/, bevor er fortfährt. Ein lokaler Timeout ist keine kostenlose fehlgeschlagene Generierung: Klären Sie diese gespeicherte Aufgabe und ihre abgerechneten Kosten ab, bevor Sie neu starten oder ein Ergebnis pro brauchbarem Bild veröffentlichen. Download-Fehler sind technische Fehler, keine Ablehnungen des Modells. Prüfen Sie heruntergeladene Dateien, bevor Sie die Review-Spalte ausfüllen.

Eine Zeile mit client_timeout hat noch keine Kosten: Lesen Sie diese Aufgabe später erneut und füllen Sie cost, bevor Sie die Ausgaben berechnen. Lassen Sie abgelehnte Zeilen in review leer; mischen Sie die Bilddateien vor der Prüfung in neutral benannte Kopien. Das Skript versucht keine Wiederholung: führen Sie einen Fall mit rate_limited oder upstream_unavailable erneut aus und behalten Sie die ursprüngliche Zeile. Um eine wegen Timeout gesendete Create-Anfrage ohne doppelte Zahlung erneut zu senden, verwenden Sie denselben Idempotency-Key (Idempotenz).

Einen Agenten das erledigen lassen

Ein Agent kann die Aufgaben über die CLI, den MCP-Server oder den Agent Skill für Sie anlegen. Alle drei lesen das aktuelle Modellschema, und CLI und MCP zeigen den Preis und fragen nach einer Bestätigung, bevor eine Aufgabe angelegt wird. Mit gesetztem SPICY_API_KEY:

# CLI
npx @spicyapi/cli tasks create --model alibaba/z-image-turbo/text-to-image \
  --input-json '{"prompt": "Textbook cross-section of a shoulder joint injury, neutral white background", "aspect_ratio": "4:3"}' --wait

# MCP server: the command your assistant's MCP config runs
npx --yes --package=@spicyapi/mcp spicyapi-mcp

# Agent Skill
npx skills add spicyapi-ai/spicy-skill

Policy-Entscheidungen vor den Modellaufruf legen

Halten Sie Policy getrennt von der Modellroutung. Prüfen Sie in dieser Reihenfolge: den Benutzer und seine Limits; ob die Eingabe eine identifizierbare echte Person enthält; Einwilligungs-, Lizenz- und Verwendungszweck-Akten; Alters-, IP- und Jurisdiktionsregeln. Wählen Sie dann erst ein Modell anhand gemessener Qualität, Zeit und Kosten und speichern Sie die Policy-Entscheidung zusammen mit der Aufgaben-ID. Der Beitrag Aufbau auf einem weniger restriktiven Modell erklärt, wo die Verantwortung liegt.

• Echte Personen: Die Einwilligung sollte die Person, die erlaubte Änderung, den Kanal, die Dauer und die Art des Widerrufs benennen; eine generische Upload-Checkbox genügt selten.
• Minderjährige und Altersunklarheit: Leiten Sie eine Erlaubnis nie vom Aussehen ab. Behandeln Sie ausnutzendes Material mit Minderjährigen als verboten und leiten Sie altersunklare Fälle an die strengste anwendbare Regel.
• Geistiges Eigentum: Bewahren Sie Lizenz und Herkunft für Referenzbilder und Logos und prüfen Sie das Rechte-Risiko dort, wo das Ergebnis laufen wird.
• Jurisdiktion: Entwickler, Benutzer, Motiv und Publikum können in verschiedenen Ländern sitzen; prüfen Sie erneut, wenn ein Asset von der Konzeptarbeit zur öffentlichen Werbung wandert.

Nach dem Benchmark entscheiden

Routen Sie nach Workload, statt einen einzigen Gewinner zu wählen:

Führen Sie den Benchmark nach jeder Modell-, Schema- oder Policy-Änderung erneut aus.

Checkliste vor der Auswahl einer API

• Ihre erlaubten und verbotenen Kategorien sind aufgeschrieben, und das Gate in Spur C läuft vor jedem Modellaufruf.
• Das Testset enthält gewöhnliche Kontrollen, kontextsensible Fälle aus Ihrer eigenen Arbeit und frühere Fehlschläge.
• Jeder Lauf ist als geliefert, entschärft, abgelehnt oder technischer Fehler erfasst, mit Aufgaben-ID, Zeit bis zur Datei und Kosten.
• Bilder werden blind anhand einer Checkliste pro Fall bewertet, und Bearbeitungen verwenden autorisierte oder synthetische Fixtures.
• Jeder Kandidat hatte mindestens fünf Läufe pro Prompt, wobei Prompt und Seitenverhältnis konstant gehalten wurden.
• Sie berichten p50- und p90-Zeit und Kosten pro brauchbarem Bild, nicht den Durchschnitt und die Preisliste.

Häufige Fragen

Ist eine weniger restriktive Bild-API dasselbe wie eine unmoderierte?

Nein. Es bedeutet weniger falsche Ablehnungen und weniger entschärfte Ergebnisse bei erlaubter Arbeit; Ihre Anwendung besitzt weiterhin Einwilligungs-, Alters-, Rechte- und Rechtsprüfungen.

Heißt eine abgeschlossene Aufgabe, dass das Bild sicher veröffentlicht werden darf?

Nein. Abschluss ist ein technisches Ergebnis. Rechte, Einwilligung, sachliche Prüfung und Distributionsprüfungen gelten weiterhin.

Was ist die wichtigste Benchmark-Metrik?

Keine allein. Lesen Sie die Ablehnungs- und Entschärfungsrate für den Nutzen, Ihr eigenes Gate für verbotene Fälle und die Kosten pro brauchbarem Bild für die Ausgaben; ein Kandidat kann das eine gewinnen und das andere verlieren.

Sollte ich mit echten Kundenbildern testen?

Nicht am Anfang. Verwenden Sie synthetische, lizenzierte oder eigens dafür erstellte Fixtures und nehmen Sie Kundenmaterial nur unter einem genehmigten Datenverarbeitungsprozess mit der erforderlichen Einwilligung und den erforderlichen Rechten herein.

Wie oft sollte ich den Benchmark wiederholen?

Nach jeder Modell-, Schema- oder Policy-Änderung und in einem regelmäßigen Takt. Behalten Sie die alten Ergebnisse, damit ein Anstieg bei Ablehnungen, Entschärfung oder Kosten als Regression sichtbar wird.