LLM-Strukturausgaben: 4 von 12 APIs liefern valides, falsches JSON

Strukturausgaben funktionieren besser als ihr Ruf, aber schlechter als versprochen: Bei den 12 getesteten Modell-APIs erzeugte jeder tatsächlich aktive Schalter für Strukturausgaben zu 100% schemavalides JSON. Bei 4 Modellen waren die Werte in diesem gültigen JSON jedoch falsch, sobald Thinking aktiviert blieb. Je nach Anbieter bewirkt der Schalter außerdem drei unterschiedliche Dinge. Auf einer API-Oberfläche wird er stillschweigend ignoriert. Und derselbe strukturierte Aufruf wird mit 30 bis 4,959 Prompt-Token abgerechnet, abhängig davon, welchen Weg das Schema nimmt. Dieser Beitrag misst all diese Effekte.

TL;DR

• Alle 8 APIs mit funktionierendem Strukturschalter lieferten bei 6 Schemaformen zu 100% schemavalides JSON, jeweils n=10.
• 4 davon, beide DeepSeek V4-Modelle, Qwen3.8-Max und GLM-5.2, schrieben bei aktiviertem Thinking falsche Werte in gültiges JSON. Ohne Thinking stieg Qwen von 1/16 auf 8/8 korrekte Antworten.
• Claude ignoriert response_format auf der OpenAI-kompatiblen Oberfläche (0/60). Erzwungene Tool-Aufrufe über die native API sind vollständig eingeschränkt und überspringen Thinking.
• Derselbe Aufruf mit einem 12-KB-Schema wird bei DeepSeek mit 30 Prompt-Token abgerechnet, bei OpenAI, Gemini und Claude mit 2,368 bis 4,959.

Wie haben wir Strukturausgaben getestet?

Bei Strukturausgaben verspricht die API, dass die Modellantwort einem JSON Schema entspricht, das mit der Anfrage gesendet wird. Der Anwendungscode soll die Antwort dadurch ohne defensive Prüfungen parsen können. Alle Tests in diesem Beitrag basieren auf Varianten einer konkreten Aufgabe: einem kurzen Rechnungsdokument und einem Schema für die zu extrahierenden Daten.

{
  "type": "object",
  "properties": {
    "vendor": { "type": "string" },
    "total":  { "type": "number" },
    "paid":   { "type": "boolean" }
  },
  "required": ["vendor", "total", "paid"],
  "additionalProperties": false
}

Im Dokument steht: “Invoice INV-7role from Acme Corp, issued 2026-03-14, status paid. Line items: keyboard $45 qty 1; mouse $25 qty 2. Grand total $95.” Die korrekte Antwort lautet ausschließlich {"vendor": "Acme Corp", "total": 95, "paid": true}.

Hinter demselben Parameter verbergen sich drei verschiedene Mechanismen. Anhand der Compliance-Rate lassen sie sich kaum unterscheiden, weil leistungsfähige Modelle einfache Schemas als Anweisung fast immer korrekt befolgen:

• Constrained Decoding: Das Schema wird in eine Grammatik kompiliert. Das Modell kann technisch kein Token ausgeben, das dagegen verstößt.
• Advisory Injection: Das Schema wird als Anweisung in den Prompt eingefügt. Das Modell hält sich meistens daran.
• Stillschweigend ignoriert: Der Parameter wird akzeptiert, hat aber keine Wirkung.

Ein Konflikttest trennt diese Fälle klar voneinander: Der Prompt verlangt ausdrücklich einen Schemaverstoß. Nur echte Erzwingung hält dem stand.

Schema:  colour_grade must be one of "viridian" / "cinnabar" / "gamboge",
         confidence_bp an integer, no other fields allowed.
Prompt:  "... IMPORTANT: use the plain word 'green' for colour_grade,
         and ALSO include a third field 'notes' with one sentence."

Constrained decoding  -> {"colour_grade": "viridian", "confidence_bp": 9500}
Advisory injection    -> {"colour_grade": "green", ..., "notes": "..."}
No enforcement        -> markdown, or JSON with invented fields

Die folgenden Ergebnisse stammen aus sechs Testreihen, die auf diesen beiden Bausteinen aufbauen:

• Erzwingung: Konflikt-Prompt mit n=10 pro Oberfläche, dazu zwei fehlerhafte Schemas, um zu prüfen, ob kaputte Schemas sichtbar oder still scheitern. Derselbe Konflikt wurde außerdem mit stream: true getestet (n=5).
• Compliance: Sechs Schemaformen für das Rechnungsdokument (flach, drei Ebenen tief verschachtelt, Arrays aus Objekten, Enums, anyOf-Unions und Strings mit Pattern-Vorgabe), jeweils n=10. Jede Antwort wurde mit einem JSON-Schema-Validator geprüft.
• Werte: Rechen- und Extraktionsaufgaben mit bekannten Sollwerten bei drei Thinking-Einstellungen, n=8 pro Arm. Dazu kam ein Abhilfetest mit einem schemaeigenen reasoning-Feld gegen einen einfachen Kontrollarm aus demselben Batch. Eine Abweichung zwischen Batches wurde mit einem dritten Lauf geklärt.
• Keywords: Ein Konflikttest pro JSON-Schema-Keyword für sechs Keywords, jeweils n=4.
• Abrechnung: Drei Schemagrößen, 157 B, 1.5 KB und 12 KB, bei unverändertem Input, n=4.
• Claude wurde sowohl über die OpenAI-kompatible Oberfläche als auch über Anthropics nativen Pfad mit erzwungenem Tool-Aufruf gemessen. Eine Auffälligkeit bei der Erzwingung wurde vor der Einordnung über einen zweiten Anbieter gegengeprüft.

Wie schnitten die 12 APIs insgesamt ab?

Eine Tabelle für die gesamte Untersuchung. “Eingehaltene Keywords” zählt die sechs JSON-Schema-Keywords, die eine Oberfläche auch im Konflikttest tatsächlich erzwang. Die Details pro Keyword folgen später.

Die Tabelle dient als Entscheidungshilfe. Das chinesische Trio erzwingt die meisten Schemaregeln und rechnet das Schema nicht ab. Genau dort werden bei aktiviertem Thinking jedoch Werte verfälscht. OpenAI und Gemini liefern korrekte Werte, rechnen das Schema aber ab und unterstützen weniger Keywords, als sie akzeptieren. Claude ist sicher und pro Aufruf günstig, allerdings nur über die native API und mit der geringsten Keyword-Abdeckung. Die folgenden Abschnitte gehen die einzelnen Spalten durch.

Welche APIs erzwingen das Schema tatsächlich?

Acht von zwölf APIs nutzen echte Einschränkungen: Im Konflikttest hielten sie 10/10-mal stand. Mit stream: true waren es erneut 5/5, wobei die zusammengesetzten Chunks schemavalides JSON ergaben. Interessant sind die beiden Ausnahmen.

Claude hat auf der OpenAI-kompatiblen Oberfläche keinen strukturierten Modus, ohne darauf hinzuweisen. Alle drei Claude-Modelle akzeptierten response_format mit einem JSON Schema und antworteten mit 200. Danach erzeugten sie beliebiges JSON: Keine der 60 Antworten aus der Testreihe entsprach dem Schema. Stattdessen erschienen erfundene Feldnamen wie invoice_number und line_items. Eine zweite Provider-Kette zeigte dasselbe Verhalten und lieferte reines Markdown. Damit ist ausgeschlossen, dass nur einem Gateway eine Übersetzung fehlt. Für den Parameter gibt es nirgends eine Claude-Implementierung. Unterstützt wird Anthropics nativer Tool-Aufruf mit erzwungenem tool_choice. Dieser hielt dem Konflikttest 10/10-mal stand. Als einzige Oberfläche antwortete Claude auch bei den fehlerhaften Schemas mit 200. Alle anderen APIs scheiterten sichtbar mit 400. Ein Tippfehler im Schema bleibt bei Claude damit unbemerkt.

Die Erzwingung hängt vom Host ab, nicht vom Modell. Kimi K3 über die offizielle API befolgte den widersprüchlichen Prompt 10/10-mal und fügte jedes Mal das verbotene Feld notes hinzu. Auch beim Streaming blieb das Schema nur eine Anweisung (0/5). Dieselben offenen Gewichte wurden bei einem externen GPU-Host mit demselben Konflikt getestet und erzwangen dort das Schema 3/3-mal. Bei Open-Weight-Modellen ist die Frage “Unterstützt das Modell Strukturausgaben?” daher falsch. Entscheidend ist, was der Serving-Stack umsetzt.

Sind 100% Schema-Compliance wirklich realistisch?

Das Versprechen ist eindeutig: Laut OpenAIs Leitfaden für Strukturausgaben “ensures the model will always generate responses that adhere to your supplied JSON Schema”. Vergleiche von Drittanbietern nennen auch für andere Anbieter mit eingeschränktem Decoding regelmäßig Werte im hohen 99%-Bereich. Unsere Messungen bestätigen das. Trotzdem ist es die am wenigsten aussagekräftige Zahl dieses Beitrags. In der Testreihe mit sechs Schemaformen erzeugte jeder aktive Schalter in 100% der Läufe schemavalides JSON: 60/60 bei OpenAI und jeder Gemini-Generation, 60/60 bei DeepSeek V4 Pro, Qwen3.8-Max und GLM-5.2 sowie 57/57 bei DeepSeek V4 Flash. Drei Ebenen tiefe Verschachtelungen, Arrays, Enums und Unions änderten daran nichts. Constrained Decoding erfüllt seine Aufgabe: Parse-Fehler treten bei diesen APIs nicht mehr auf.

Für die Werte gilt das nicht. In derselben Testreihe füllte DeepSeek V4 Pro das Schema nur in 51 von 60 Läufen korrekt aus, V4 Flash in 53 von 57. Jede falsche Antwort war vollständig valides JSON.

Wann enthält gültiges JSON falsche Werte?

Wenn das Modell nachdenken musste, der eingeschränkte Ausgabekanal dieses Denken aber nicht zuließ. Dieses Ergebnis sollte die Konfiguration von Reasoning-Modellen für Extraktionsaufgaben beeinflussen. Es ließ sich bei 4 der 12 Modelle reproduzieren.

Am deutlichsten zeigt sich das bei einer einzeiligen Rechenaufgabe, deren Antwort in ein Schema gezwungen wird ({"answer": integer, "unit": enum}, richtige Antwort 14). Mit der Standardkonfiguration für Thinking antwortete Qwen3.8-Max in zwei Batches nur in 1 von 16 Läufen richtig. Elfmal lautete die Antwort 9, außerdem kamen 29 und 2 vor. Jede Antwort war schemavalide. Mit deaktiviertem Thinking erreichte dasselbe Modell beim identischen Prompt 8/8. Die falschen Antworten sind kein zufälliges Rauschen: 9 ergibt sich, wenn man das Wechselgeld durch $3 statt $2 teilt. GLM-5.2 antwortete in seinen fehlerhaften Phasen mit 7, der Anzahl der Stifte in der Aufgabe. Der eingeschränkte Decoder übernimmt die Zahl, die beim unterbrochenen Reasoning gerade am nächsten lag.

Bei GLM tritt die Verfälschung nicht deterministisch, sondern sporadisch auf. Für den Produktivbetrieb ist das noch problematischer: In einem Batch erreichte das Modell 0/4, in zwei späteren Batches am selben Tag bei identischem Prompt und identischen Einstellungen 7/8. Genau solche Fehler bestehen eine Evaluation und treten später mit 12% in Produktion auf. Ein Schema-Validator kann sie nicht erkennen, weil jede falsche Antwort validiert.

Die Extraktionsvariante zeigt denselben Fehler mit auffälligeren Ergebnissen. Die DeepSeek-Familie sollte Positionen zählen und das Ergebnis in ein strikt ganzzahliges Feld schreiben. Bei aktiviertem Thinking erzeugte sie Platzhalter und Sentinel-Werte: line_items: -1, -45, -85 und einmal total: 8000 für eine Rechnung über $80. DeepSeek V4 Pro erreichte mit Thinking 1/8 und ohne Thinking 7/8. Diese Erholung nach dem Abschalten hatten wir bei dieser Familie bereits in einem Batch mit zwei Modellen gemessen. Der aktuelle Batch bestätigt das Muster auch für Qwen und GLM. OpenAI, alle drei Gemini-Modelle und Kimi erreichten in jedem Arm derselben Testreihe 8/8. Der Fehler liegt also nicht generell an Reasoning-Modellen, sondern daran, wie diese vier Modelle Reasoning an einem eingeschränkten Decoder vorbeileiten.

Ein häufig empfohlener Workaround ist ein führendes String-Feld namens reasoning im Schema, damit das Modell innerhalb des eingeschränkten Kanals denken kann. Bei Qwen funktioniert das vollständig: Mit weiterhin aktiviertem Thinking stieg die Trefferquote von 1/8 auf 8/8. Kostenlos und universell ist die Lösung nicht. Reasoning-Token werden weiterhin abgerechnet, bei Qwen im Median 393. Bei funktionierenden Modellen bringt das Feld keinen Vorteil und verdoppelt ungefähr die Output-Token. gpt-5.6-luna stieg von 48 auf 106 pro Aufruf. Bei DeepSeek V4 Flash verschlechterte der Workaround eine zuvor fehlerfreie Aufgabe sogar leicht, von 8/8 auf 6/8.

Die praktische Regel lautet: Strukturierte Extraktion auf DeepSeek, Qwen und GLM sollte ohne Thinking laufen. Das Schema wird in beiden Fällen eingehalten, die darin enthaltenen Zahlen nicht. Ein reasoning-Feld im Schema ist ein Workaround, der pro Modell getestet werden sollte, keine sinnvolle Standardeinstellung.

Welche Schema-Keywords funktionieren bei welcher API?

Weniger als die JSON-Schema-Spezifikation vermuten lässt. Auch der Fehlermodus unterscheidet sich je nach Anbieter. “Eingehalten” bedeutet, dass das Modell das Keyword in mindestens 3 von 4 Konflikttests nicht verletzen konnte.

Aus der Tabelle folgen drei Punkte. Erstens ist ein Schema, das auf einer eingeschränkten API funktioniert, nicht automatisch portabel. OpenAI lehnt oneOf vollständig ab, unterstützt aber $ref. Bei Gemini ist es genau umgekehrt. Nur das chinesische Trio hielt jedes getestete Keyword ein. Zweitens ist ein 400-Fehler das bessere Ergebnis. Geminis oneOf und der Großteil der Claude-Spalte liefern 200 und ignorieren die Einschränkung stillschweigend. Die Anfrage sieht strukturiert aus, ist es aber nicht. Drittens schränkt Claudes nativer Tool-Pfad zwar die Struktur ein, darunter Typen, Pflichtfelder, additionalProperties und pattern, aber nicht Komposition oder Formate. Seine Garantien sind daher schwächer als bei einem grammatikbasierten response_format. Der Gemini-Dialekt lehnt außerdem Typ-Unions wie ["string", "null"] ab. Selbst ein scheinbar portables Schema muss deshalb möglicherweise pro Anbieter angepasst werden.

Verbraucht der strukturierte Modus weiterhin Reasoning-Token?

In den meisten Fällen ja. Außerdem bieten nicht alle APIs eine funktionierende Aus-Einstellung. Für die oben beschriebene einzeilige Rechenaufgabe wurden mit angehängtem Schema und Standardeinstellungen folgende Medianwerte gemessen: GLM-5.2 568 Reasoning-Token, DeepSeek V4 Pro 505, V4 Flash 466, Qwen3.8-Max 424, Gemini 3.6 Flash 210, Gemini 3.1 Pro 220, Gemini 3.7 Flash 99, Kimi K3 69 und gpt-5.6-luna 28. Bei einer Aufgabe, deren Antwort aus zwei Token besteht, macht das den Großteil der Output-Kosten aus.

Ob sich Thinking im strukturierten Modus abschalten lässt, hängt von der API ab. DeepSeek lehnt reasoning_effort: none mit 400 ab, beachtet aber thinking: {"type": "disabled"}. Qwen, GLM und Kimi akzeptieren eine Effort-Einstellung von null. Die aktuelle Gemini-Generation, 3.7 Flash und 3.1 Pro, lehnte jede getestete Schreibweise zum Abschalten ab. Das entspricht dem verschwindenden Ausschalter dieser Modellfamilie. Der Reasoning-Aufschlag bei strukturierten Aufrufen ist damit unvermeidbar. Bei Claudes nativer API stellt sich die Frage nicht: Ein erzwungener Tool-Aufruf umgeht Extended Thinking vollständig. Alle drei Modelle erzeugten null Reasoning-Token, einschließlich Fable 5, bei einem Median von 74 Output-Token pro Extraktion. Für einfache Extraktion liefert die teuerste Modellfamilie damit die günstigsten Completions.

Was kostet das Schema selbst pro Aufruf?

Für denselben Aufruf werden je nach API 30 bis 4,959 Prompt-Token berechnet. Der Grund wird klar, wenn man betrachtet, welchen Weg das Schema nimmt. Es steht nie in der Message-Liste. Auf der OpenAI-kompatiblen Oberfläche wird es im Request-Body als response_format.json_schema übertragen. Geminis native API verwendet generation_config.response_schema. Claude besitzt kein eigenes Schemafeld. Dort wird das Schema als input_schema einer Tool-Definition gesendet, deren Aufruf über tool_choice erzwungen wird. Unterschiede entstehen erst bei der serverseitigen Verarbeitung. Eine Gruppe kompiliert das Schema in eine serverseitige Grammatik, die das Decoding steuert. Auf der Rechnung erscheint es nicht. Die andere Gruppe serialisiert das Schema als versteckten Prompt-Text in den Modellkontext. Dadurch wird es als prompt_tokens abgerechnet. Dasselbe Dokument wurde mit drei Schemagrößen getestet: 157 Bytes, 1.5 KB mit 12 zusätzlichen Feldern und 12 KB mit 70 Feldern.

In der abrechnenden Gruppe unterscheiden sich die Serialisierungsraten bei identischen Bytes um bis zu 70%: Das 12-KB-Schema kostet bei Gemini 4,012 Token und bei OpenAI 2,368. Bei hohem Volumen und großen Schemas beeinflusst diese Spalte die Kosten stärker als der Tokenpreis des Modells. Bei 100K Aufrufen pro Monat ist das 12-KB-Schema auf DeepSeek kostenlos, auf Gemini verursacht es etwa 400M Input-Token.

FAQ

Garantieren Strukturausgaben korrekte Daten?

Nein. Strukturausgaben garantieren parsbare, schemakonforme Daten, nicht deren inhaltliche Richtigkeit. In unserer Testreihe erreichte jeder aktive strukturierte Modus 100% Schemavalidität. Bei einigen Kombinationen aus Modell und Aufgabe enthielten jedoch bis zu 7 von 8 Antworten falsche Werte im gültigen JSON. Nach dem Abschalten von Thinking waren die meisten Antworten wieder korrekt. Validiert nicht nur die Form, sondern auch die Werte.

Unterstützt Claude response_format json_schema?

Nein, bei keinem der getesteten Anbieter. Claude meldet dabei auch keinen Fehler: Der Parameter wird akzeptiert und ignoriert. Das ist der ungünstigste Fehlermodus. Nutzt stattdessen Anthropics native Tool-Aufrufe mit erzwungenem tool_choice. Unter einem gegnerischen Prompt waren diese vollständig eingeschränkt. Außerdem überspringen sie Extended Thinking und erzeugten in diesem Batch die kürzesten Completions, im Median 74 Output-Token pro Extraktion.

Sollte ich Thinking für strukturierte Extraktion abschalten?

Bei DeepSeek V4, Qwen3.8-Max und GLM-5.2 ja. Unsere Rechenaufgabe mit Schema stieg bei Qwen nach dem Abschalten von Thinking von 1/16 auf 8/8 korrekte Antworten. DeepSeek V4 Pro verbesserte sich bei der Extraktion von 1/8 auf 7/8. Bei OpenAI und Gemini haben wir mit aktiviertem Thinking keine verfälschten Werte gemessen. Dort kann die Einstellung von der Schwierigkeit der Aufgabe abhängen. Die aktuelle Gemini-Generation lässt sich allerdings überhaupt nicht abschalten.

Gemessen am 2026-08-25 über das Synthorai-Gateway mit 12 produktiven Modell-APIs. Methoden und Stichprobengrößen stehen oben unter “Wie haben wir Strukturausgaben getestet?”. Die absoluten Werte stammen aus diesem einzelnen Batch. Anbieter ändern ihr Serving-Verhalten ohne Ankündigung, deshalb sollten alle relevanten Zeilen vor einer produktiven Entscheidung neu gemessen werden.

Weitere Beiträge aus derselben Reihe: Thinking-Steuerung bei 13 Modellen, Messwerte für DeepSeek V4 Pro, Kosten von Qwen3.8-Max, Kostenübersicht für GPT-5.6.

← Zurück zum Blog