Der Gemeinsame Nenner: “OpenAI‑Compatible API”

In der LLM‑Welt gibt es aktuell (Dez. 2025) keinen formal spezifizierten Standard wie etwa HTTP oder SQL, der von einem Gremium normiert wird. Stattdessen hat sich ein De‑facto‑Standard herausgebildet der von den meisten Anbietern unterstützt wird: die „OpenAI‑Compatible“ API.

Im folgenden, praxis-nahen Artikel werden wir:

  1. Die wichtigste API, die “Chat Completion”, im OpenAI‑Format erklären
  2. Die bekanntesten LLM-Modelle und deren Steuerparameter anschauen
  3. Mithilfe von LiteLLM verschiedene Modelle mit einer einheitlichen API ansteuern
  4. Weiterfuehrende Themata wie Multimodalität, Structured Outputs, Reasoning, Tool Calling, MCP etc. anschneiden

1. Die wichtigste API: “Chat Completion” im OpenAI‑Format

Für „einfach mal Text generieren“ ist die zentrale Schnittstelle heute die Chat‑Completion‑API im OpenAI‑Stil. LiteLLM spiegelt dieses Format 1:1 wider und übersetzt es intern für verschiedene Provider. So kann ein Anwender mit einem und demselben API-Call auf verschiedene Modelle zugreifen und die Ausgabe in einem einheitlichen Format erhalten.

Grundprinzip

Die API ist HTTP + JSON und arbeitet typischerweise so:

  • Endpoint: POST http://localhost:4000/chat/completions
  • Authentifizierung: Authorization: Bearer <API-KEY> (API-KEY wird in LiteLLM konfiguriert)
  • Body (minimaler Request ohne optionale Parameter):
{
  "model": "ollama/qwen2.5:32b",
  "messages": [
    { "role": "system", "content": "Du bist ein hilfreicher Assistent." },
    { "role": "user", "content": "Beschreibe Neurales Netzwerk in zwei Sätzen." }
  ],
  "stream": false
}

Die Antwort sieht wie folgt aus:

{
  "id": "chatcmpl-xyz",
  "object": "chat.completion",
  "choices": [{
    "message": {
      "role": "assistant",
      "content": "Ein Neurales Netzwerk ist ein mathematisches Modell, das aus künstlichen Neuronen besteht. Es wird trainiert, um bestimmte Aufgaben zu erfüllen, wie beispielsweise das Erkennen von Bildern oder das Verstehen von Sprache."
    },
    "finish_reason": "stop"
  }
  ],
  "usage": { "prompt_tokens": 10, "completion_tokens": 15, "total_tokens": 25 }
}
  • id: technische Request‑ID
  • choices[^0].message.content: der eigentliche Antwort‑Text
  • usage: Token‑Statistik (Prompt‑Tokens, Completion‑Tokens, Total). Tokens sind ein umfangreiches Thema für einen anderen Artikel. Hier ist es ausreichend zu wissen, dass 1.000 Tokens in etwa 750 Wörtern entsprechen.

Zentrale Request‑Felder

Die wichtigsten Felder im OpenAI‑kompatiblen Quasi‑Standard:

  • model (Pflicht) String, der das gewünschte Modell beschreibt. Die genaue Syntax variiert je nach Provider (z. B. ollama/qwen2.5:32b oder ollama/gpt-oss:20b für On-Premise-Modelle), aber das Feld ist überall vorhanden.

  • messages (Pflicht) – Das Herzstück der API

Das messages‑Array ist der zentrale Mechanismus, um mit dem Modell zu kommunizieren. Es ist eine chronologische Liste von Nachrichten, die einen Konversationsverlauf bilden. Diese messages‑Struktur mit ihren drei Rollen (system, user, assistant) ist ein universeller gemeinsamer Nenner, den praktisch alle modernen LLM‑APIs verstehen.

Auch bei Use Cases, die keine echte Konversation sind (wie einmalige Dokumentenanalysen, Code-Generierung oder Datenverarbeitung), wird dieses Format verwendet. In solchen Fällen besteht das Array typischerweise aus nur zwei Nachrichten: einer system‑Nachricht für die Instruktionen und einer user‑Nachricht mit der eigentlichen Aufgabe.

Die drei Kern‑Rollen:

Die Instruktions‑Ebene: "system"

  • Was: Definiert die Rolle, den Kontext und die Verhaltensregeln für das Modell
  • Wann: Meist als erste Nachricht im Array (optional, aber empfohlen)
  • Praktischer Einsatz:
    • Rollen‑Definition: "Du bist ein hilfreicher Assistent für Finanzanalysen."
    • Kontext setzen: "Du analysierst Quartalsberichte für ein Schweizer KMU."
    • Verhalten steuern: "Antworte immer auf Deutsch, sei präzise und zitiere Quellen."
    • Format‑Vorgaben: "Antworte immer im JSON‑Format mit den Feldern 'Zusammenfassung' und 'Risiken'."
  • Wichtig: System‑Nachrichten werden vom Modell als “Meta‑Instruktionen” behandelt – sie prägen die gesamte Konversation, werden aber nicht als Teil des eigentlichen Dialogs betrachtet.

Die Anfrage‑Ebene: "user"

  • Was: Die eigentlichen Fragen, Aufgaben oder Inputs des Benutzers
  • Wann: Immer wenn der Benutzer etwas fragt oder eine Aufgabe stellt
  • Praktischer Einsatz:
    • Einfache Fragen: "Was ist Docker?"
    • Aufgaben: "Analysiere diesen Vertrag auf Risiken: [Text...]"
    • Multi‑Turn‑Konversationen: Mehrere user‑Nachrichten nacheinander für Follow‑up‑Fragen
    • Kontext‑Anreicherung: "Hier ist der Code: [Code...]. Erkläre die Funktion."

Die Antwort‑Ebene: "assistant"

  • Was: Die vorherigen Antworten des Modells
  • Wann: Bei Multi‑Turn‑Konversationen, um dem Modell den bisherigen Verlauf zu zeigen
  • Praktischer Einsatz:
    • Konversations‑Gedächtnis: Wenn Sie eine zweite Frage stellen, fügen Sie die erste assistant‑Antwort ein, damit das Modell den Kontext behält
    • Korrekturen: Wenn das Modell einen Fehler macht, können Sie die falsche Antwort als assistant markieren und eine neue user‑Nachricht mit der Korrektur senden
    • Iterative Verbesserung: assistant → user (“Das ist gut, aber ergänze noch…”) → assistant → …

Beispiele zur Anwendung der 3 Kern-Rollen

Beispiel: Einfacher Single‑Turn‑Request

{
  "model": "ollama/qwen2.5:32b",
  "messages": [
    { "role": "system", "content": "Du bist ein hilfreicher Assistent." },
    { "role": "user", "content": "Nenne mir drei Vorteile von Docker." }
  ]
}

Beispiel: Multi‑Turn‑Konversation

{
  "model": "ollama/qwen2.5:32b",
  "messages": [
    { "role": "system", "content": "Du bist ein Experte für Cloud‑Infrastruktur." },
    { "role": "user", "content": "Was ist Docker?" },
    { "role": "assistant", "content": "Docker ist eine Containerisierungsplattform..." },
    { "role": "user", "content": "Wie unterscheidet es sich von Kubernetes?" }
  ]
}

Beispiel: Praktischer Business‑Use‑Case: Vertragsanalyse

{
  "model": "ollama/gpt-oss:20b",
"messages": [
    {
      "role": "system",
      "content": "Du bist ein Rechtsberater. Analysiere Verträge auf Risiken und fasse die wichtigsten Punkte zusammen. Antworte strukturiert auf Deutsch."
    },
    {
      "role": "user",
      "content": "Analysiere diesen Lieferantenvertrag:\n\n[50 Seiten Vertragstext...]"
    }
  ]
}

Die vierte Rolle: "tool" (Fortgeschritten)

  • Wird bei Function Calling verwendet, wenn das Modell eine externe Funktion aufruft
  • Tool Calling ist sehr umfangreich und würde hier den Rahmen sprengen, aber im Kapitel 4 wird es noch etwas detaillierter behandelt.

Antwortstruktur

Die Antwort ist im bekannten OpenAI‑Stil gehalten:

  • choices: Liste von möglichen Antworten; standardmäßig gibt es genau eine.
  • Jede Choice enthält:
    • message.role: meist "assistant"
    • message.content: der Text
    • ggf. message.tool_calls: falls Tools genutzt wurden.
  • usage:
    • prompt_tokens
    • completion_tokens
    • total_tokens

Beispiel:

{
  "id": "chatcmpl-xyz",
  "object": "chat.completion",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Docker ist eine Containerisierungsplattform, die Anwendungen in isolierten Umgebungen ausführt."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 20,
    "completion_tokens": 25,
    "total_tokens": 45
  }
}

2. Bekannte LLM-Modelle und deren Steuerparameter

Auch wenn das OpenAI‑kompatible Format einen gemeinsamen Nenner bildet, unterscheiden sich Modelle bei der Unterstützung von Steuerparametern und bei technischen Limits deutlich. Das ist insbesondere bei On‑Premise‑Modellen relevant, da diese häufig unterschiedliche Architekturen, Quantisierungen und Laufzeit‑Implementierungen nutzen. Die Steuerparameter variieren je nach Modell und Backend.

Steuerparameter: Was wird wo unterstützt?

Die wichtigsten Steuerparameter im OpenAI‑Format sind:

  • temperature: Steuert Kreativität/Zufälligkeit der Ausgabe (niedrig = deterministischer, höher = kreativer).
  • top_p: Alternative zu temperature (Nucleus‑Sampling).
  • max_tokens: Maximale Antwortlänge.
  • n: Anzahl der Varianten, die erzeugt werden sollen (nicht von allen Backends implementiert).
  • stop: String oder Liste von Strings, bei denen die Ausgabe beendet wird.
  • tools / tool_choice: Tool‑/Function‑Calling im OpenAI‑Stil (je nach Backend unterschiedlich verfügbar).
  • response_format: Z. B. {"type": "json_object"} für strikt JSON‑förmige Antworten (primär in neueren OpenAI‑kompatiblen APIs garantiert, bei anderen Anbietern/Pipelines oft nur teilweise umgesetzt).
  • logprobs, top_logprobs: Wahrscheinlichkeiten pro Token (werden von vielen Open‑Source‑Backends nicht oder nur eingeschränkt bereitgestellt).

Tabellarische Übersicht

Die folgende Tabelle gibt eine schnelle Übersicht, welche Steuerparameter typischerweise von verschiedenen On‑Premise‑Modell‑Familien unterstützt werden:

ParameterGPT‑OSSDeepSeek (Reasoning)LlamaDeepSeek (Chat)Qwen
temperature✅⚠️ (keine Wirkung)✅✅✅
top_p✅⚠️ (keine Wirkung)✅✅✅
max_tokens✅✅✅✅✅
stop✅✅✅✅✅
n (Varianten)⚠️⚠️⚠️✅⚠️
tools / tool_choice⚠️⚠️⚠️✅⚠️
response_format⚠️⚠️⚠️✅⚠️
logprobs⚠️❌ (Fehler möglich)⚠️✅⚠️

Legende:

  • ✅ = Zuverlässig unterstützt
  • ⚠️ = Unterstützung variiert je nach Backend/Implementierung
  • ❌ = Meist nicht verfügbar

Hinweise:

  • Universelle Parameter: max_tokens und stop funktionieren praktisch überall zuverlässig
  • Reasoning‑Modelle: Bei Reasoning‑Modellen (wie DeepSeek‑Reasoner) haben temperature und top_p keine Wirkung, da diese Modelle deterministisch arbeiten
  • Backend‑Abhängigkeit: Viele Features (besonders tools, response_format, n) hängen stark vom verwendeten Inferenz‑Server ab (vLLM, Ollama, TGI etc.), nicht nur vom Modell selbst

Typische Unterschiede bei On‑Premise‑Modellen

GPT‑OSS / Open‑Source‑GPT‑Varianten

  • Unterstützt: In der Regel die Standard‑Parameter temperature, top_p, max_tokens, stop; viele Distributionen orientieren sich explizit am OpenAI‑API‑Format. GPT‑OSS ist explizit für OpenAI‑Kompatibilität entwickelt.
  • Variiert stark: Unterstützung für tools / tool_choice, response_format, logprobs hängt von der konkreten Server‑Implementierung (z. B. OpenAI‑kompatibler Gateway, LiteLLM, Ollama, vLLM‑API) ab, nicht vom Modellgewicht selbst.
  • Besonderheit: GPT‑OSS ist explizit für OpenAI‑Kompatibilität und lokales bzw. selbst gehostetes Deployment gedacht, weshalb eine hohe Schnittstellen‑Übereinstimmung mit der OpenAI‑API angestrebt wird.

Llama‑Familie (Meta)

  • Unterstützt: Parameter wie temperature, top_p, max_tokens und stop funktionieren in den gängigen Servern (vLLM, TGI, Ollama etc.) zuverlässig.
  • Eingeschränkt: n (mehrere Varianten) und Tool‑Aufrufe werden nicht auf Modell‑Ebene, sondern – falls überhaupt – durch die jeweilige Serving‑Schicht implementiert; je nach Framework ist n, tools bzw. tool_choice gar nicht oder nur teilweise verfügbar.
  • Logprobs: Viele populäre Llama‑Backends bieten logprobs entweder gar nicht oder nur mit Performance‑Einbußen an; Unterstützung ist implementationsabhängig.
  • Besonderheit: Llama‑Modelle werden mit festen Kontextfenstern ausgeliefert (z. B. 4k, 8k, 32k Token), die durch Fine‑Tuning oder spezielle Varianten erweitert werden können, aber den „harten” Rahmen für In‑ und Output bilden.

Qwen‑Familie (Alibaba)

  • Unterstützt: temperature, top_p, max_tokens, stop werden von den offiziellen Qwen‑Servern und typischen OpenAI‑kompatiblen Gateways unterstützt.
  • response_format/strukturiertes JSON: Strikte JSON‑Schemas sind bei OpenAI‑Modellen über response_format definierbar; bei Qwen‑Deployments erreicht man strukturierte Antworten meist über sorgfältiges Prompting oder zusätzliche Schema‑Validatoren im Application‑Layer.
  • Besonderheit: Qwen‑Modelle gelten als stark bei strukturierten Outputs; viele Nutzer setzen explizite Format‑Anweisungen (System‑/User‑Prompts) anstelle von nativem response_format ein.

DeepSeek‑Modelle (DeepSeek‑V3, DeepSeek‑Reasoner/R1)

  • Unterstützt: DeepSeek stellt eine explizit OpenAI‑kompatible Chat‑Completion‑API bereit; Parameter wie temperature, top_p, max_tokens, n, stop, tools/Function‑Calling sowie response_format = {"type": "json_object"} werden analog zur OpenAI‑API unterstützt.
  • Logprobs: Für die Standard‑Chat‑Modelle (z. B. deepseek‑chat / DeepSeek‑V3) werden logprobs und top_logprobs explizit unterstützt und in der API‑Dokumentation beschrieben; der Reasoning‑Modellpfad (deepseek‑reasoner) dokumentiert hingegen, dass Sampling‑Parameter wie temperature/top_p keine Wirkung haben und logprobs/top_logprobs zu Fehlern führen können.
  • Besonderheit:
    • DeepSeek‑Modelle bieten große Kontextfenster (typisch 64k–128k Tokens, je nach Version), mit separaten Limits für Gesamtkontext und maximale Ausgabelänge (z. B. 128k Kontext, 4k–8k Output).
    • Die API ist bewusst als „Drop‑in‑Replacement“ zur OpenAI‑API entworfen, inklusive Nutzung der offiziellen OpenAI‑SDKs, so dass bestehende OpenAI‑Integrationen mit minimalen Änderungen auf DeepSeek umgestellt werden können.

Praktische Implikationen

Was bedeutet das für die Praxis?

  1. Basis‑Parameter sind (fast) universell: temperature, max_tokens und stop funktionieren bei den meisten OpenAI‑kompatiblen Backends und On‑Premise‑Setups zuverlässig, solange diese das Chat‑/Completion‑Schema der OpenAI‑API nachbilden.
  2. Erweiterte Features gezielt prüfen: Wenn tools, response_format, n oder logprobs benötigt werden, sollte vorab in der Modell‑ bzw. Server‑Dokumentation geprüft oder im Test gegen die konkrete API verifiziert werden, ob diese Parameter wirklich unterstützt werden.
  3. Fallback‑Strategien für strukturierte Outputs: Wenn response_format nicht implementiert ist, lassen sich strukturierte Antworten meist trotzdem über präzise System‑Prompts und nachgelagerte Validierung (z. B. JSON‑Parser + Retry) erreichen. Nachgelagerte Validierung und Sicherheitsaspekte sollten dabei berücksichtigt werden.
  4. LiteLLM als Abstraktions‑Layer: LiteLLM bietet mit get_supported_openai_params(model=..., custom_llm_provider=...) einen Mechanismus, um pro Modell/Provider abzufragen, welche OpenAI‑Parameter unterstützt und sauber gemappt werden. Optional können nicht unterstützte Parameter automatisch verworfen werden (drop_params=True), anstatt einen Fehler auszulösen.

Limits und Defaults

Neben den Steuerparametern unterscheiden sich Modelle auch in weiteren technischen Eigenschaften:

  • Kontextfenster: Reicht typischerweise von wenigen tausend Tokens bei kleineren bzw. älteren Modellen bis hin zu 128k+ Tokens bei großen, modernen Systemen; der exakte Wert hängt vom jeweiligen Modell‑Checkpoint ab.
  • Token‑Limits: Maximale Input‑ und Output‑Länge sind meist durch dasselbe Kontextlimit begrenzt und werden zusätzlich vom Inferenz‑Server bzw. Gateway beschränkt.
  • Default‑Temperatur: Voreinstellungen unterscheiden sich je nach Anbieter und Server‑Konfiguration; typische Defaults liegen im Bereich 0.0–0.7 und können in der Regel pro Request überschrieben werden.
  • Safety‑Einstellungen: Viele On‑Premise‑Deployments laufen ohne integrierte Content‑Filter oder Moderations‑Pipelines; Sicherheits‑ und Compliance‑Filter müssen deshalb oft als externe Guardrails (z. B. eigene Moderations‑Modelle, Content‑Safety‑Services oder regelbasierte Filter) ergänzt werden. Sicherheits‑ und Compliance‑Filter und Datenschutzaspekte sollten dabei berücksichtigt werden.

Wichtig: Abstraktions‑Bibliotheken wie LiteLLM können Parameter‑Kompatibilität, Defaults und Fehlerbehandlung vereinheitlichen, verändern aber nicht die realen physikalischen Limits des zugrunde liegenden Modells. Ein Modell mit 4k‑Kontext kann nicht plötzlich 32k Tokens verarbeiten, nur weil ein Proxy oder ein API‑Adapter dazwischengeschaltet wird. LiteLLM hilft bei der Kompatibilität, kann aber physikalische Modelllimits nicht überschreiten.

3. LiteLLM: Verschiedene Modelle mit einer einheitlichen API ansteuern

LiteLLM ist kein eigenes LLM, sondern eine Art Proxy‑Server oder Gateway, welches nach aussen das einheitliche OpenAI‑Chat‑Format anbietet und intern sehr viele verschiedene LLM-Modelle mit varierenden APIs ansteuert.

Rolle von LiteLLM

Wichtige Aufgaben von LiteLLM:

  • API‑Angleichung: Unterschiedliche Provider sprechen unterschiedliche Dialekte – LiteLLM übersetzt alle auf das OpenAI‑Chat‑Format (Request und Response).
  • Routing & Loadbalancing: Mit config.yaml lassen sich mehrere Modelle / Anbieter hinter einem gemeinsamen Alias bündeln (z. B. „team-default“).
  • Auth & Quotas: Verwaltung von API‑Keys, Schlüssel‑Rotation, Rate Limits, Kostenlimits etc.
  • Monitoring & Metriken: Token‑Verbrauch, Latenzen, Fehlerraten, Spend‑Tracking etc. via Prometheus‑/metrics.
  • Integrationen: Diverse Frameworks (Langfuse, CrewAI, LangGraph, LlamaIndex, OpenAI Agents SDK etc.) können direkt mit LiteLLM sprechen.

Für den Einsteiger bedeutet das:

  • Es reicht, das OpenAI‑Chat‑API‑Modell ein Mal zu verstehen.
  • Danach kann mit demselben Code verschiedene On‑Premise‑Modelle (Ollama, lokale vLLM‑Instanzen, Hugging Face Inference) oder auch Cloud‑Anbieter (OpenAI, Anthropic, Azure) angesprochen werden – lediglich model und ggf. base_url werden angepasst.

Wie LiteLLM Provider zusammenführt

LiteLLM unterstützt eine sehr große Liste an Providern, darunter:

  • On‑Prem / Lokal: vLLM‑Server, Hugging Face‑Inference, Ollama, Triton Inference Server, Custom HTTP‑Server, die OpenAI‑Compatible sprechen.
  • Cloud (optional): OpenAI, Azure OpenAI, Google (Vertex AI / Gemini), AWS Bedrock, Anthropic, Cohere, AI21, Together, Groq, OpenRouter, Nscale (EU‑Sovereign) usw.
  • Spezialanbieter: Recraft (Bilder), Deepgram (Audio), RAGFlow, LangGraph‑Agents etc.

Im config.yaml wird festgelegt:

  • Welcher model_name nach außen sichtbar ist (z. B. team/gpt-default) und
  • welche Backend‑Parameter dazu gehören (Provider, API‑Key, Base‑URL, Kosteninformationen, Fallback‑Modelle usw.).

In der Anwendung wird dann nur noch model="team/gpt-default" verwendet – alles Weitere erledigt LiteLLM.

Metriken, Observability und Governance

LiteLLM bringt – vor allem in Proxy‑Betrieb – umfangreiche Metrik‑Funktionen mit:

  • Standard‑Metriken (Prometheus):
    • litellm_total_tokens_metric: Input + Output Tokens pro Modell / User
    • litellm_input_tokens_metric, litellm_output_tokens_metric
    • litellm_spend_metric: geschätzte Kosten pro User, Modell, Team
    • litellm_request_total_latency_metric: Gesamt‑Latenz
    • litellm_llm_api_latency_metric: reine Provider‑Latenz
    • Erfolgs-/Fehlerraten nach Modell/Fallback
  • Proxy‑Metriken:
    • Anfragen pro Endpoint (/chat/completions etc.)
    • Fehlerquote, Fallback‑Statistiken bei Ausfällen einzelner Modelle
  • Custom‑Labels: Über prometheus_metrics_config lassen sich eigene Labels setzen (z. B. team, service, feature_flag), um Dashboards zu segmentieren.

Damit lässt sich LiteLLM sauber in Grafana‑Dashboards und bestehende Observability‑Stacks einhängen.

Multimodalität (Text + Bild + mehr)

Viele moderne Modelle sind multimodal – sie akzeptieren nicht nur Text, sondern auch Bilder (teilweise Audio/Video). LiteLLM integriert das in denselben completion‑Pfad:

  • Beispiel: Multimodale On‑Premise‑Modelle (z. B. LLaVA, Phi‑3.5 Vision) messages.content wird statt eines einfachen Strings ein Array von Content‑Blöcken, z. B.:
response = litellm.completion(
    model="ollama/llava:latest",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "Was ist auf diesem Bild?"},
                {"type": "image_url", "image_url": {"url": "https://.../bild.jpg"}}
            ]
        }
    ]
)
  • Für andere On‑Premise‑Provider (z. B. vLLM mit Vision‑Modellen, Hugging Face Inference) wird ebenfalls das OpenAI‑ähnliche Interface genutzt, intern jedoch in provider‑spezifische Calls übersetzt.

Der Vorteil für den Schnittstellen Nutzer:

  • Formell „nur“ messages verstehen – die gleichen Mechanismen wie beim reinen Text – und LiteLLM kümmert sich um das Provider‑Spezifikum.

4. Ausblick: Multimodalität, strukturierte Outputs, Reasoning und MCP

Moderne LLM‑Features gehen über einfache Text‑zu‑Text‑Interfaces hinaus. Multimodalität, kontrollierte Ausgabeformate, Reasoning‑Mechanismen und standardisierte Protokolle ermöglichen es, LLMs eng mit Business‑Systemen zu integrieren und Halluzinationen zu minimieren. Diese Features werden zunehmend in OpenAI‑kompatiblen APIs standardisiert, sind aber bei On‑Prem‑Modellen noch oft nicht konsistent verfügbar.

Multimodalität

Neue Modellgenerationen verarbeiten neben Text auch Bilder, Audio oder Dokumente. In on‑premise oder OpenAI‑kompatiblen Deployments wird dies durch erweiterte HTTP‑Payloads mit Base64‑ oder URL‑basierten Bildern ausgedrückt.

REST‑Request mit Bildquelle (vLLM, OpenAI‑kompatible API):

POST http://llm-intern.your-company.com/v1/chat/completions
Content-Type: application/json

{
  "model": "microsoft/Phi-3.5-vision-instruct",
  "messages": [{
    "role": "user",
    "content": [
      {"type": "text", "text": "Was ist auf diesem Bild zu sehen?"},
      {
        "type": "image_url",
        "image_url": {"url": "data:image/jpeg;base64,/9j/4AAQSkZJRg..."}
      }
    ]
  }],
  "max_tokens": 512
}

# Response (Status 200 OK)
{
  "choices": [{
    "message": {
      "role": "assistant",
      "content": "Das Bild zeigt eine Rechnung der Firma TechAG über CHF 1'250.00, Rechnungsnummer INV-2025-001, datiert 2025-01-15."
    }
  }]
}

Weitere Details zur Multimodalität: vLLM Multimodal Inputs.

Strukturierte Outputs und Guardrails

Strukturierte Ausgaben sorgen dafür, dass ein LLM gültiges JSON mit vordefinierter Struktur erzeugt, statt „ungefähr richtigem“ Text, der dann beim Parsen scheitert. Das lässt sich mit rein offenen Komponenten realisieren – zum Beispiel mit vLLM und dessen Structured‑Outputs‑Funktionalität – und bei Bedarf zusätzlich mit Guardrails AI absichern.

Open‑Source‑Beispiel: vLLM Structured Outputs (guided_json)

vLLM erweitert seinen OpenAI‑kompatiblen Server um zusätzliche Parameter wie guided_json, guided_choice, guided_regex und guided_grammar, die das Modell beim Decoding an ein JSON‑Schema oder eine Grammatik binden. Weitere Details finden Sie in der vLLM Structured Outputs Dokumentation.

Ein Request an euren internen vLLM‑Server könnte so aussehen:

POST http://llm-intern.your-company.com/v1/chat/completions
Content-Type: application/json

{
  "model": "Qwen/Qwen2.5-3B-Instruct",
  "messages": [{
    "role": "user",
    "content": "Extrahiere Rechnungsdaten und gib sie als JSON zurück: \
Rechnung #INV-2025-001 über CHF 1'250.00 von TechAG, 2025-01-15."
  }],
  "max_tokens": 256,

  "guided_json": {
    "name": "invoice_schema",
    "schema": {
      "type": "object",
      "properties": {
        "invoice_number": { "type": "string" },
        "amount":        { "type": "number" },
        "currency":      { "type": "string" },
        "date":          { "type": "string", "format": "date" },
        "vendor":        { "type": "string" }
      },
      "required": ["invoice_number", "amount", "currency", "date", "vendor"],
      "additionalProperties": false
    }
  }
}

Typische Response (vereinfacht):

{
  "id": "chatcmpl-struct-123",
  "object": "chat.completion",
  "model": "Qwen/Qwen2.5-3B-Instruct",
  "choices": [{
    "index": 0,
    "message": {
      "role": "assistant",
      "content": {
        "invoice_number": "INV-2025-001",
        "amount": 1250.0,
        "currency": "CHF",
        "date": "2025-01-15",
        "vendor": "TechAG"
      }
    },
    "finish_reason": "stop"
  }]
}

Wichtig:

  • Das Modell wird durch guided_json so geführt, dass es syntaktisch und semantisch valides JSON entsprechend dem Schema erzeugt. Dies wird auf Decoder‑Ebene durchgesetzt, wie in diesem Red Hat Artikel über Structured Outputs mit vLLM beschrieben.
  • Die gesamte Pipeline bleibt open source (Modell, vLLM‑Server, JSON‑Schema‑Definition).

Mehr dazu:

Kurz: Was ist Guardrails AI?

Guardrails AI ist ein open‑source Framework (Python/JavaScript), das LLM‑Anwendungen mit zusätzlichen „Guardrails“ versieht. Das Framework ist auf GitHub verfügbar und kann über PyPI installiert werden.

  • Input‑ und Output‑Guards prüfen und begrenzen Risiken (z. B. PII‑Leakage, Toxicity, Competitor Mentions) über wiederverwendbare Validatoren aus dem „Guardrails Hub”.
  • Strukturierte Daten: Guardrails kann LLM‑Antworten gegen Pydantic‑Modelle bzw. JSON‑Schemas validieren und bei Verstößen automatisch korrigieren oder neu generieren. Ein Beispiel finden Sie in der Guardrails AI Dokumentation zu strukturierten Daten.
  • Guardrails kann direkt in eure Anwendung integriert werden oder als separater Guard‑Service laufen, der eingehende/ausgehende LLM‑Calls vorfiltert.

Damit ergänzen sich beide Ansätze gut:

  • vLLM / Structured Outputs erzwingt auf Decoder‑Ebene formale Strukturen.
  • Guardrails AI fügt eine zusätzliche Validierungs‑ und Risiko‑Schicht darüber, inklusive Business‑ und Compliance‑Regeln.

Reasoning‑Modelle

Reasoning‑Modelle (wie DeepSeek‑Reasoner) generieren zunächst ausführliche Zwischenschritte (reasoning_content), bevor sie eine Antwort geben. Die API wird reasoning_content und content separat zurück.

REST‑Request + Response mit Reasoning‑Trace:

POST http://deepseek-reasoner.your-company.com/v1/chat/completions
Content-Type: application/json

{
  "model": "deepseek-reasoner",
  "messages": [{
    "role": "user",
    "content": "Analysiere unsere Q4‑Verkaufsdaten und identifiziere drei Haupttreiber für die Umsatzveränderung gegenüber Q3."
  }],
  "max_tokens": 8000
}

# Response – Beachte reasoning_content als separates Feld
{
  "id": "chatcmpl-reas456",
  "choices": [{
    "index": 0,
    "message": {
      "role": "assistant",
      "reasoning_content": "Zur Analyse der Umsatzveränderung muss ich folgende Fragen klären:\n1. Welche Kategorien haben den größten Umsatzanstieg?\n2. Welche externen Faktoren haben sich verändert?\n3. Gibt es saisonale Effekte zwischen Q3 und Q4?\n\n[Ausführliche Analysen...]\n\nSyntax des Outputs:",
      "content": "Die drei Haupttreiber der Umsatzveränderung sind:\n1) Gestiegene Nachfrage im Bereich Cloud‑Services (+18%)\n2) Verbesserte Margen durch Prozessoptimierung (+6%)\n3) Saisonale Effekte (Weihnachtsquartal +12%)"
    },
    "finish_reason": "stop"
  }]
}

Die reasoning_content kann ausgewertet werden für Audit‑Trails oder Prompt‑Debugging. DeepSeek Reasoning Model Guide.

Tool Calling und Agentik

Tool Calling erlaubt es dem LLM, gezielt zwischen mehreren verfügbaren Funktionen zu wählen und mit korrekten Argumenten aufzurufen. Der Service führt die Funktion dann aus und antwortet dem Modell mit dem Ergebnis.

REST‑Request mit zwei verfügbaren Tools (LLM wählt eines):

# 1. Initiales Request mit Tool‑Definition
POST http://llm-platform.your-company.com/v1/chat/completions
Content-Type: application/json

{
  "model": "local-llama-3.1",
  "messages": [{"role": "user", "content": "What is the status of customer CUST-123 and their current contract value?"}],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "query_crm",
        "description": "Query customer data from on-prem CRM system (contact info, purchase history, etc.)",
        "parameters": {
          "type": "object",
          "properties": {
            "customer_id": {"type": "string", "description": "Customer ID"}
          },
          "required": ["customer_id"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "query_contracts",
        "description": "Query contract and billing data from on-prem ERP system",
        "parameters": {
          "type": "object",
          "properties": {
            "customer_id": {"type": "string", "description": "Customer ID"}
          },
          "required": ["customer_id"]
        }
      }
    }
  ]
}

# 2. Response – LLM wählt query_crm aus (nicht query_contracts)
{
  "id": "chatcmpl-tool789",
  "choices": [{
    "message": {
      "role": "assistant",
      "tool_calls": [{
        "id": "call_abc123",
        "type": "function",
        "function": {
          "name": "query_crm",
          "arguments": "{\"customer_id\": \"CUST-123\"}"
        }
      }]
    },
    "finish_reason": "tool_calls"
  }]
}

# 3. Interner Service führt Tool aus und schickt Ergebnis zurück
# POST http://crm-api.your-company.com/internal/query
# {"customer_id": "CUST-123"}
# Response: {"status": "active", "contact": "John Doe", "last_order": "2025-01-10"}

# 4. Zweites Request mit Tool‑Ergebnis
POST http://llm-platform.your-company.com/v1/chat/completions
{
  "model": "local-llama-3.1",
  "messages": [
    {"role": "user", "content": "What is the status of customer CUST-123 and their current contract value?"},
    {"role": "assistant", "tool_calls": [{"id": "call_abc123", "function": {"name": "query_crm", "arguments": "{\"customer_id\": \"CUST-123\"}"}}]},
    {
      "role": "tool",
      "tool_call_id": "call_abc123",
      "content": "{\"status\": \"active\", \"contact\": \"John Doe\", \"last_order\": \"2025-01-10\"}"
    }
  ],
  "tools": [...]
}

# 5. Final Response mit Interpretation
{
  "choices": [{
    "message": {
      "role": "assistant",
      "content": "Customer CUST-123 (John Doe) has status 'active'. The last order was placed on 2025-01-10."
    }
  }],
  "finish_reason": "stop"
}

Weitere Details: OpenAI Function Calling Guide.

Auch Ollama unterstützt inzwischen Tool Calling: Ollama Tool Calling Documentation.

Model Context Protocol (MCP)

Das Model Context Protocol (MCP) standardisiert bidirektionale Tool‑Integration über ein JSON‑RPC‑Interface. Server definieren Tools, Clients (LLMs, Assistants) können diese nutzen – ohne spezifische API‑Adapter.

REST‑Handshake mit MCP‑Server:

# 1. Verbindung initialisieren
POST http://mcp-gateway.your-company.com/mcp
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {},
    "clientInfo": {"name": "enterprise-llm-client", "version": "1.0.0"}
  }
}

# 2. Server antwortet mit Capabilities
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2024-11-05",
    "capabilities": {"tools": {}},
    "serverInfo": {"name": "internal-erp-mcp-server", "version": "2.1.0"}
  }
}

# 3. Verfügbare Tools abfragen
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {}
}

# 4. Server liefert Tool‑Liste
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "query_sales_data",
        "description": "Query sales data from on-prem ERP",
        "inputSchema": {
          "type": "object",
          "properties": {
            "region": {"type": "string"},
            "quarter": {"type": "string"}
          },
          "required": ["region", "quarter"]
        }
      }
    ]
  }
}

# 5. Tool aufrufen
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "query_sales_data",
    "arguments": {"region": "EMEA", "quarter": "Q4-2025"}
  }
}

# 6. Server antwortet mit Ergebnis
{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [{"type": "text", "text": "EMEA Q4-2025: Revenue CHF 2.5M, Growth +22%"}]
  }
}