> Wie Structured Outputs und Constrained Decoding bei OpenAI, Claude, Gemini und vLLM funktionieren, welche Schemaregeln zählen und was du validierst.
>
> Web page: https://balazscsorba.com/de/blog/structured-outputs-json-schema-llm · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/structured-outputs-json-schema-llm.md) · [Magyar](https://balazscsorba.com/hu/blog/structured-outputs-json-schema-llm.md)
> Author: Balázs Csorba · Published: 2026-10-16 · Keywords: structured outputs LLM, JSON schema LLM output, OpenAI structured outputs strict mode, Claude structured outputs, Gemini structured output, constrained decoding, JSON mode vs structured outputs, validate LLM JSON output, Zod structured output, Pydantic LLM output, vLLM structured outputs

[Blog](https://balazscsorba.com/de/blog)/LLMOps & Evals

# Structured Outputs mit JSON Schema: was die Garantie abdeckt und was nicht

Wie Structured Outputs und Constrained Decoding bei OpenAI, Claude, Gemini und vLLM funktionieren, welche Schemaregeln zählen und was du validierst.

[Balázs Csorba](https://balazscsorba.com/de/about)·16\. Oktober 2026·9 Min. Lesezeit

-   Structured outputs
-   JSON Schema
-   Constrained decoding
-   LLM APIs
-   Validation

![Ein JSON Schema wird zu einer Grammatik kompiliert, die Tokens maskiert und schemagültiges JSON erzeugt, das danach eine fachliche Validierung durchläuft.](https://balazscsorba.com/images/blog/structured-outputs-json-schema-llm/cover.webp?v=54f5de15d0)

## Das Wichtigste in Kürze

-   Structured Outputs kompilieren dein JSON Schema zu einer Grammatik und maskieren ungültige Tokens, sodass Antworten konstruktionsbedingt parsebar und schemakonform sind.
-   Der JSON-Modus garantiert nur gültiges JSON; Structured Outputs garantieren die Form, und strikte Tools übertragen dieselbe Garantie auf Tool-Argumente.
-   OpenAI, Claude und Gemini unterstützen jeweils eine andere Teilmenge von JSON Schema; entwirf für die Schnittmenge mit Pflichtfeldern, null und additionalProperties false.
-   Verweigerungen, Abbruch bei max\_tokens, Enum-Schreibweise und abgelehnte Schemas sind dokumentierte Ausnahmen mit eigenem Codepfad.
-   Ein schemagültiges Objekt kann trotzdem falsch sein: Referenzen und Plausibilität im Code prüfen und Qualität mit und ohne Schema messen.

Auf dieser Seite

1.  [JSON-Modus, Structured Outputs und strikte Tools](https://balazscsorba.com/#json-mode-vs-structured-outputs)
2.  [Wie Constrained Decoding funktioniert](https://balazscsorba.com/#how-constrained-decoding-works)
3.  [OpenAI, Claude, Gemini und vLLM im Vergleich](https://balazscsorba.com/#provider-comparison)
4.  [Schemaregeln, die bei jedem Anbieter gelten](https://balazscsorba.com/#schema-design-rules)
5.  [Eine typisierte Extraktion in TypeScript](https://balazscsorba.com/#code-example)
6.  [Wann die Garantie nicht greift](https://balazscsorba.com/#when-the-guarantee-breaks)
7.  [Schadet die Formatvorgabe der Antwortqualität?](https://balazscsorba.com/#does-it-hurt-quality)
8.  [Die Validierungsschicht hinter dem Schema](https://balazscsorba.com/#validation-layer)
9.  [Structured Outputs bei selbst gehosteten Modellen](https://balazscsorba.com/#self-hosted-models)
10.  [Checkliste](https://balazscsorba.com/#checklist)
11.  [Quellen](https://balazscsorba.com/#sources)

Diesen Artikel anhören

0:000:00

Ein Modell zu bitten, "in JSON zu antworten", funktioniert so lange, bis es das nicht mehr tut: ein Kommentar am Ende, ein fehlendes Feld, ein String, wo dein Code eine Zahl erwartet. **Structured Outputs** lösen die syntaktische Hälfte dieses Problems. Der Anbieter kompiliert dein JSON Schema zu einer Grammatik und lässt das Modell nur Tokens ausgeben, die die Ausgabe gültig halten. Die Antwort ist damit parsebar und schemakonform, und zwar konstruktionsbedingt. OpenAI, Anthropic, Google und die Open-Source-Inferenzserver bieten inzwischen alle eine Variante davon an.

Die andere Hälfte bleibt deine Aufgabe. Ein schemagültiges Objekt kann den falschen Kunden, ein erfundenes Datum oder eine Verweigerung enthalten. Dieser Leitfaden erklärt, wie Constrained Decoding funktioniert, wie sich die drei großen APIs unterscheiden, welche Schemaregeln Leute stolpern lassen, welche Fehlerfälle die Garantie nicht abdeckt und welche Validierungsschicht dahinter gehört.

## JSON-Modus, Structured Outputs und strikte Tools

Es gibt drei Stufen, und man verwechselt sie leicht. **JSON nur per Prompt** ist eine Anweisung, sonst nichts. Der **JSON-Modus** garantiert syntaktisch gültiges JSON, aber nicht deine Struktur: Laut OpenAI-Leitfaden erzeugen beide Modi gültiges JSON, aber "nur Structured Outputs stellen die Einhaltung des Schemas sicher". Der JSON-Modus hat sogar eine eigene Falle: Erwähnt der Prompt JSON nicht, kann das Modell einen endlosen Strom aus Leerzeichen ausgeben. Deshalb lehnt die OpenAI-API eine Anfrage im JSON-Modus ab, wenn der String "JSON" nirgends im Kontext vorkommt.

**Structured Outputs** beschränken die finale Antwort auf ein Schema. **Strikte Tool-Nutzung** überträgt dieselbe Garantie auf Tool-Argumente: Setze `strict: true` in der Tool-Definition, und die Argumente, die das Modell schickt, validieren gegen das Input-Schema des Tools. Nimm das Erste, wenn das Modell deinem Code antwortet, das Zweite, wenn das Modell deinen Code aufruft. Die Anthropic-API erlaubt beides in einer Anfrage.

## Wie Constrained Decoding funktioniert

Bei jedem Generierungsschritt berechnet ein Modell eine Wahrscheinlichkeit für jedes Token seines Vokabulars. Constrained Decoding führt einen aus deinem Schema abgeleiteten Zustandsautomaten mit und maskiert jedes Token, das die Ausgabe an dieser Stelle ungültig machen würde. Nach einer öffnenden Klammer und einem Pflichtschlüssel steht eine schließende Klammer schlicht nicht zur Wahl. Den Inhalt wählt weiterhin das Modell; die Grammatik entfernt nur Optionen, die nicht zu gültiger Ausgabe führen können.

Das Kompilieren dieser Grammatik kostet Zeit. Laut Anthropic-Doku hat die erste Anfrage mit einem neuen Schema zusätzliche Latenz, weil die Grammatik kompiliert wird; kompilierte Grammatiken werden 24 Stunden ab letzter Nutzung zwischengespeichert. Eine Änderung der Schemastruktur oder der Tool-Menge invalidiert den Cache; eine Änderung nur an `name` oder `description` nicht. OpenAI nennt eine ähnliche Verzögerung bei der ersten Anfrage nur für feinabgestimmte Modelle. Praktisch heißt das: Schemas stabil und versioniert halten und nach einem Deploy vorwärmen, wenn nicht der erste Nutzer die Kompilierung bezahlen soll.

Structured Outputs garantieren die obere Reihe. Die untere Reihe, Stoppgrund prüfen und Inhalt validieren, bleibt dein Code.

## OpenAI, Claude, Gemini und vLLM im Vergleich

Alle vier akzeptieren JSON Schema, alle vier unterstützen nur eine Teilmenge davon, und die Teilmengen unterscheiden sich. Das sagen die aktuellen Dokus:

Aktivierung

Wichtige Schemaregeln

Dokumentierte Grenzen

tagchildren

`text.format` mit `type: "json_schema"` und `strict: true` (Responses API)

Alle Felder required (optional per null-Union nachbilden); additionalProperties false; kein allOf, not, if/then/else; Schlüssel kommen in Schemareihenfolge

Bis zu 5.000 Objekteigenschaften, 10 Verschachtelungsebenen, 1.000 Enum-Werte

tagchildren

`output_config.format`; `strict: true` bei Tools

additionalProperties muss false sein; keine Zahlen- oder Längen-Constraints; minItems nur 0 oder 1; Pflichtfelder werden vor optionalen ausgegeben

20 strikte Tools, 24 optionale Parameter, 16 Parameter mit Union-Typ pro Anfrage

tagchildren

`response_format` mit `mime_type: application/json` und `schema`

Unterstützt enum, format, minimum/maximum, minItems/maxItems, prefixItems; null über Typ-Arrays

"Sehr große oder tief verschachtelte Schemas können abgelehnt werden"

tagchildren

`structured_outputs` (`json`, `regex`, `choice`, `grammar`)

Backends: xgrammar oder guidance; die alten guided\_json-Felder wurden in v0.12.0 entfernt

Abhängig von Backend und Modell

Zwei Details aus dieser Tabelle verursachen die meisten Überraschungen. Erstens unterscheiden sich die Reihenfolgeregeln: OpenAI gibt Schlüssel in Schemareihenfolge aus, Claude stellt Pflichtfelder zuerst und optionale danach. Wenn du dich auf die Reihenfolge verlässt (etwa um Teilobjekte in eine UI zu streamen), mach alle Eigenschaften zu Pflichtfeldern. Zweitens zählen Claudes Grenzen über alle strikten Schemas einer Anfrage hinweg: Vier strikte Tools mit je sechs optionalen Parametern erreichen bereits die Grenze von 24. Wird die kombinierte Grammatik zu groß, kommt ein 400 mit "Schema is too complex for compilation".

## Schemaregeln, die bei jedem Anbieter gelten

Wenn ein Schema bei mehr als einem Anbieter laufen muss, entwirf es für die Schnittmenge. Das sind meine Regeln:

-   **Mach jedes Feld zum Pflichtfeld und modelliere "unbekannt" als null.** Ein Typ `["string", "null"]` ist eindeutig und funktioniert überall; ein fehlender Schlüssel ist mehrdeutig. Bei Claude zählen Union-Typen zur Grenze von 16 Parametern, also nur dort einsetzen, wo null eine echte Antwort ist.
-   **Setze additionalProperties bei jedem Objekt auf false.** Claude und OpenAIs strikter Modus verlangen es, und es verhindert, dass das Modell Felder erfindet, die dein Code stillschweigend ignoriert.
-   **Nimm Enums statt Freitext für alles, worauf du verzweigst.** Status, Kategorie, Intent. Vergleiche Enum-Werte trotzdem ohne Groß-/Kleinschreibung: Claudes Doku warnt, dass die Schreibweise von enum- und const-Werten nicht garantiert ist.
-   **Regeln gehören in die Beschreibung, nicht in Constraints.** Claude unterstützt minLength, maximum und Ähnliches nicht; schreib "ISO-4217-Code, drei Buchstaben" in die Beschreibung und prüfe es im Code.
-   **Flach und klein halten.** Verschachtelung, Unions und optionale Parameter vervielfachen die Grammatikgröße. Zwei einfache Aufrufe schlagen oft ein Schema, das alles erfassen will.
-   **Baue einen expliziten Ausweg ein.** Ein Feld wie `"confidence": "low" | "high"` oder `"not_found": true` gibt dem Modell eine gültige Möglichkeit zu sagen, dass es etwas nicht weiß. Ohne so ein Feld erzwingt das Schema eine Antwort.

## Eine typisierte Extraktion in TypeScript

Die SDKs verstecken die Schema-Mechanik. Mit dem Anthropic-TypeScript-SDK packst du ein Zod-Schema in `zodOutputFormat()` und rufst `client.messages.parse()` auf; das schickt es als `output_config.format` und liefert ein typisiertes `parsed_output`. Das OpenAI-Pendant ist `responses.parse()` mit `zodTextFormat()`. Was das SDK dir nicht abnimmt, sind die Prüfung des Stoppgrunds und die Fachregel danach:

```
import Anthropic from "@anthropic-ai/sdk";
import { zodOutputFormat } from "@anthropic-ai/sdk/helpers/zod";
import { z } from "zod";

const OrderLine = z.object({
  sku: z.string().describe("Article number exactly as written in the email"),
  quantity: z.number().int().describe("Ordered quantity, a positive integer"),
  unit: z.enum(["piece", "box", "pallet"]),
  delivery_date: z.string().nullable().describe("ISO date, or null if none given"),
});
const Order = z.object({ lines: z.array(OrderLine), not_an_order: z.boolean() });

const client = new Anthropic();
const res = await client.messages.parse({
  model: "claude-opus-5-5",
  max_tokens: 4096,
  messages: [{ role: "user", content: `Extract the order lines:\n\n${email}` }],
  output_config: { format: zodOutputFormat(Order) },
});

if (res.stop_reason === "refusal" || res.stop_reason === "max_tokens") {
  throw new Error(`no usable output: ${res.stop_reason}`);   // schema not guaranteed here
}
const order = res.parsed_output!;
for (const line of order.lines) {
  if (line.quantity <= 0 || !(await skuExists(line.sku))) {   // business rules: your job
    await queueForHumanReview(email, order);
    break;
  }
}
```

Die Zod-Angaben (`.int()`, die Beschreibungen) helfen trotzdem: Die Beschreibung erreicht das Modell als Hinweis, und du kannst `Order.parse()` selbst noch einmal ausführen, wenn du eine zweite, lokale Prüfung der Constraints willst, die der Anbieter nicht durchsetzt.

## Wann die Garantie nicht greift

"Garantierte Schemakonformität" hat dokumentierte Ausnahmen, und jede braucht einen Codepfad:

-   **Verweigerungen.** Claude liefert `stop_reason: "refusal"` mit HTTP 200, und die Ausgabe passt womöglich nicht zum Schema. OpenAI setzt ein eigenes Feld `refusal` in die Antwort. Anthropic warnt außerdem, dass eine Eigenschaft, die das schrittweise Denken des Modells abfragt, eine Verweigerung wegen Reasoning-Extraktion auslösen kann; frag stattdessen nach einer kurzen Begründung.
-   **Abbruch.** Erreicht die Antwort `max_tokens` (Claude) oder `max_output_tokens` (OpenAI, Status `incomplete`), ist das JSON abgeschnitten. Erhöhe das Limit oder verkleinere die Ausgabe; nie optimistisch parsen.
-   **Enum-Schreibweise.** Siehe oben: ohne Groß-/Kleinschreibung vergleichen.
-   **Abgelehntes Schema.** Nicht unterstützte Schlüsselwörter oder zu viel Komplexität liefern ein 400, bevor überhaupt generiert wird. Teste jedes Schema in der CI, nicht erst in Produktion.
-   **Feature-Konflikte.** Bei Claude sind Citations und Structured Outputs inkompatibel (400), ebenso Prefills. Wenn du belegte Antworten und JSON brauchst, mach es in zwei Schritten.

**Gültiges JSON ist keine richtige Antwort**

Geminis eigene Doku sagt es deutlich: Die Ausgabe ist syntaktisch korrektes JSON, also validiere die Werte immer in deiner Anwendung und behandle schemakonforme, aber inhaltlich falsche Ausgaben. Das Schema garantiert die Form. Ob die Artikelnummer existiert, sagt es nicht.

## Schadet die Formatvorgabe der Antwortqualität?

Das ist die umstrittenste Frage, und die Belege zeigen in beide Richtungen. ["Let Me Speak Freely?"](https://arxiv.org/abs/2408.02442) (Tam et al., 2024) berichtete von einem "deutlichen Rückgang der Reasoning-Fähigkeiten unter Formatvorgaben", wobei strengere Vorgaben stärker schadeten. [JSONSchemaBench](https://arxiv.org/abs/2501.10868) (Geng et al., 2025) wiederholte drei Aufgaben mit korrigiertem Prompt und fand das Gegenteil: Jedes Constrained-Decoding-Framework lag auf oder über der Baseline ohne Constraints; Guidance erreichte bei GSM8K 83,8 % gegenüber 80,1 % für das Modell allein.

Meine Lesart: Prompt- und Schemadesign zählen mehr als der Mechanismus. Schädlich ist, das Modell auf ein Antwortfeld festzulegen, bevor es nachgedacht hat. Zwei Lösungen funktionieren. Bei Reasoning-Modellen findet das Denken in den Thinking-Blöcken statt: Claudes Grammatik gilt dort nicht, das Modell denkt frei, und nur die finale Antwort ist eingeschränkt. Bei anderen Modellen setzt du ein kurzes Feld `explanation` vor das Feld `answer` (OpenAI gibt Schlüssel in Schemareihenfolge aus). Und miss es an deiner eigenen Aufgabe, mit [einem kleinen Eval-Set](https://balazscsorba.com/de/blog/llm-evals-for-product-features), einmal mit und einmal ohne Schema.

## Die Validierungsschicht hinter dem Schema

Behandle die Modellausgabe wie Eingaben eines nicht vertrauenswürdigen Clients: parsen, validieren, dann handeln. Das Schema beseitigt eine Fehlerklasse (Syntax und Form), die übrigen Prüfungen werden dadurch einfacher, aber nicht optional. Das setze ich hinter jeden strukturierten Aufruf:

1.  **Stoppgrund-Gate.** Alles außer einem normalen Ende geht in einen Fehlerpfad.
2.  **Referenzprüfungen.** IDs, Artikelnummern, Kundennummern und Daten werden gegen deine Daten nachgeschlagen. Hier zeigen sich die meisten echten Fehler, und hier zählt [Grounding](https://balazscsorba.com/de/blog/llm-hallucination-grounding-citations) mehr als das Format.
3.  **Plausibilitätsregeln.** Mengen über einem Schwellenwert, Daten in der Vergangenheit, Summen, die nicht aufgehen.
4.  **Ein Reparaturversuch, dann ein Mensch.** Gib den Validierungsfehler einmal zurück; scheitert es weiter, kommt der Fall in eine Prüfwarteschlange statt in eine Schleife.
5.  **Schemaversion loggen.** Wenn du ein Schema änderst, müssen alte Traces interpretierbar bleiben, und deine Evals sollten gegen die Version in Produktion laufen.

Bibliotheken wie [Pydantic AI](https://balazscsorba.com/de/tools/pydantic-ai) und [Guardrails AI](https://balazscsorba.com/de/tools/guardrails-ai) bündeln Teile dieser Schleife. Für Routing- und Triage-Entscheidungen, bei denen du zusätzlich wissen musst, wie sicher sich das Modell ist, siehe [typisierte Entscheidungen mit kalibrierter Konfidenz](https://balazscsorba.com/de/blog/jev-typed-decisions-llm-routing).

## Structured Outputs bei selbst gehosteten Modellen

[vLLM](https://balazscsorba.com/de/tools/vllm) unterstützt Structured Outputs mit xgrammar oder guidance als Backend, über seinen OpenAI-kompatiblen Server (`response_format` mit JSON Schema) oder den Parameter `structured_outputs`, der auch eine Regex, eine feste Auswahlliste oder eine kontextfreie Grammatik akzeptiert. Wenn du von einem älteren vLLM aktualisierst: Die Felder `guided_json`, `guided_regex` und verwandte wurden in v0.12.0 entfernt. vLLM kombiniert Structured Outputs außerdem mit Reasoning-Parsern, sodass ein Reasoning-Modell frei denken und trotzdem eingeschränktes JSON liefern kann.

JSONSchemaBench ist hier die nützliche Referenz: Es testete Guidance, Outlines, llama.cpp, XGrammar, OpenAI und Gemini an 10.000 realen Schemas auf Effizienz, Abdeckung und Qualität und fand, dass keine einzelne Engine bei jeder Instanz die beste war. Wenn du selbst hostest, schick deine eigenen Schemas durch das gewählte Backend, bevor du dich festlegst.

## Checkliste

1.  Structured Outputs (nicht JSON-Modus) für Antworten, strikte Tools für Tool-Argumente.
2.  Schemas für die Schnittmenge entwerfen: alle Felder required, null für unbekannt, additionalProperties false, Enums für alles, worauf du verzweigst.
3.  Jedes Schema in der CI gegen die Grenzen jedes Anbieters prüfen.
4.  Verweigerung und Abbruch behandeln, bevor du parst.
5.  Enums ohne Groß-/Kleinschreibung vergleichen.
6.  Referenzen und Plausibilität im Code prüfen; ein Reparaturversuch, dann ein Mensch.
7.  Schemas versionieren, die Version mit jedem Trace loggen und neue Schemas nach einem Deploy vorwärmen.
8.  Qualität mit und ohne Schema am eigenen Eval-Set messen.

Wenn du das in ein Nuxt-Frontend einbaust, zeigt [der Leitfaden zu LLM-Features in Nuxt](https://balazscsorba.com/de/blog/nuxt-llm-features-ai-sdk-streaming) die Streaming-Seite. Für Unterstützung beim Entwurf von Extraktionspipelines siehe [AI Engineering](https://balazscsorba.com/de/expertise/ai-engineer).

## Quellen

1.  [OpenAI API docs: Structured model outputs](https://platform.openai.com/docs/guides/structured-outputs)
2.  [Claude API docs: Structured outputs](https://platform.claude.com/docs/en/build-with-claude/structured-outputs)
3.  [Gemini API docs: Structured outputs](https://ai.google.dev/gemini-api/docs/structured-output)
4.  [vLLM docs: Structured Outputs](https://docs.vllm.ai/en/latest/features/structured_outputs.html)
5.  [Tam et al.: Let Me Speak Freely? A Study on the Impact of Format Restrictions on Performance of LLMs (2024)](https://arxiv.org/abs/2408.02442)
6.  [Geng et al.: JSONSchemaBench: A Rigorous Benchmark of Structured Outputs for Language Models (2025)](https://arxiv.org/abs/2501.10868)

## Häufige Fragen

Was ist der Unterschied zwischen JSON-Modus und Structured Outputs?

Der JSON-Modus garantiert syntaktisch gültiges JSON, aber nicht, dass es die Felder und Typen hat, die du brauchst. Structured Outputs beschränken die Generierung auf dein JSON Schema, sodass die Antwort dem Schema entspricht, außer in dokumentierten Fällen wie Verweigerung oder Abbruch. Nutze Structured Outputs, wann immer Anbieter und Modell sie unterstützen.

Machen Structured Outputs LLM-Antworten schlechter?

Die Beleglage ist gemischt. Eine Studie von 2024 berichtete schwächeres Reasoning unter strengen Formatvorgaben, während JSONSchemaBench 2025 mit korrigiertem Prompt Constrained Decoding auf oder über der Baseline ohne Constraints fand. Lass das Modell nachdenken, bevor es sich auf ein Antwortfeld festlegt, entweder in Thinking-Blöcken oder in einem vorangestellten Begründungsfeld, und miss es an deiner eigenen Aufgabe.

Muss ich die Ausgabe im strikten Modus noch validieren?

Ja. Das Schema garantiert die Form, nicht die Wahrheit. Prüfe den Stoppgrund, schlage IDs und Artikelnummern in deinen Daten nach, wende Plausibilitätsregeln an und schick fehlerhafte Fälle in einen Reparaturversuch und dann zu einem Menschen.

Warum liefert mein JSON Schema einen 400-Fehler?

Meist, weil es Schlüsselwörter nutzt, die der Anbieter nicht unterstützt, etwa allOf bei OpenAI oder minLength bei Claude, oder weil die kombinierte Komplexität zu hoch ist. Claude zählt seine Grenzen von 20 strikten Tools, 24 optionalen Parametern und 16 Parametern mit Union-Typ über alle Schemas einer Anfrage.

Wie mache ich ein Feld im strikten Modus von OpenAI optional?

Der strikte Modus verlangt, dass jedes Feld als required gelistet ist. Bilde ein optionales Feld mit einer Union nach, die null enthält, etwa dem Typ string oder null, und behandle null in deinem Code als unbekannt.

Geschrieben von Balázs Csorba

Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten.

[KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about)

## Weitere Artikel

-   [KI-Agenten evaluieren: Trajektorien, Ergebnisse und Zuverlässigkeit bewerten](https://balazscsorba.com/de/blog/evaluating-ai-agents-trajectories)
-   [LLM-Modellmigration ohne Regressionen: Deprecations, Evals, Shadow-Traffic](https://balazscsorba.com/de/blog/llm-model-migration-regression-testing)
-   [Semantisches Caching für LLM-Apps: wann Antworten wiederverwenden sicher ist und wann nicht](https://balazscsorba.com/de/blog/semantic-caching-llm-responses)
-   [LLMs selbst hosten für die DSGVO: wann es nötig ist und was es kostet](https://balazscsorba.com/de/blog/self-hosted-llm-gdpr-cost)

## Klingt nach dem, was du suchst?

Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören.

[Kontakt aufnehmen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)