OpenAI-API selbst hosten — Drop-In-Replacement richtig aufbauen

Der OpenAI-API-Standard hat sich 2024/25 als De-facto-Schnittstelle für LLM-Integrationen etabliert. Praktisch jedes SDK, jedes IDE-Plugin und jedes SaaS-Add-on kann gegen /v1/chat/completions sprechen. Wer eine eigene Inferenz-Infrastruktur betreibt, sollte genau dieses Schema bedienen — nicht aus Bequemlichkeit, sondern weil es Migrationskosten gegen Null drückt. Dieser Artikel zeigt, wie ein produktionsreifer, OpenAI-kompatibler Stack aussieht, der 2026 für den Mittelstand belastbar ist.

Warum Drop-In-Kompatibilität die richtige Architektur ist

Eine native, proprietäre API mag kurzfristig einfacher wirken. Mittelfristig zwingt sie aber jedes Team, jeden Connector und jedes Drittanbieter-Tool zu Sonderbehandlungen. Ein OpenAI-kompatibler Endpoint dagegen funktioniert sofort mit dem offiziellen Python-SDK, dem Node-SDK, mit LangChain, LlamaIndex, n8n, Continue.dev, Open WebUI, Cursor und Hunderten weiterer Tools. Die einzige Anpassung ist eine geänderte base_url. Damit wird die KI-Plattform beliebig austauschbar — ein wichtiges Argument gegenüber Geschäftsführung und Einkauf, weil die Lock-in-Risiken sinken.

Architektonisch besteht ein robuster Stack aus drei Schichten: einem TLS-terminierenden Reverse-Proxy am Edge, einem Policy- und Routing-Layer in der Mitte sowie einer oder mehreren Inferenz-Engines im Backend. Jede Schicht hat eine klar abgegrenzte Verantwortung und lässt sich unabhängig skalieren oder ersetzen.

vLLM als Inferenz-Backend

vLLM hat sich als pragmatische Standardlösung für Open-Weight-Modelle durchgesetzt. Der eingebaute API-Server bringt out-of-the-box die wichtigsten OpenAI-Endpoints mit: /v1/chat/completions, /v1/completions, /v1/embeddings und /v1/models. Streaming via Server-Sent-Events funktioniert ebenso wie logprobs, response_format für JSON-Mode und seit Mitte 2025 stabil auch Tool-Calling.

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.3-70B-Instruct \
  --served-model-name llama-3.3-70b \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --enable-auto-tool-choice \
  --tool-call-parser llama3_json \
  --port 8000

Wichtig: Pro Modell läuft eine eigene vLLM-Instanz. Das ist gewollt, weil vLLM dann Page-Attention und Continuous Batching maximal ausnutzen kann. Mehrere Modelle hinter einer einzigen URL bündelt der nachgelagerte Routing-Layer.

LiteLLM als Policy- und Routing-Proxy

LiteLLM-Proxy ist die zweite Schicht. Er übersetzt nicht nur zwischen Backends, sondern bringt produktionskritische Funktionen mit: virtuelle API-Keys, Token-Quotas pro Key, Team-Budgets, Audit-Logging in PostgreSQL, Caching, Retries und ein eingebautes Cost-Tracking. Die Konfiguration erfolgt deklarativ in config.yaml:

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/llama-3.3-70b
      api_base: http://vllm-llama:8000/v1
      api_key: sk-internal
  - model_name: gpt-4o-mini
    litellm_params:
      model: openai/qwen-2.5-7b
      api_base: http://vllm-qwen:8000/v1
  - model_name: text-embedding-3-large
    litellm_params:
      model: openai/bge-m3
      api_base: http://vllm-embed:8000/v1

router_settings:
  routing_strategy: usage-based-routing-v2
  fallbacks:
    - gpt-4o: ["gpt-4o-mini"]

general_settings:
  master_key: sk-master-rotate-me
  database_url: postgres://litellm:***@db:5432/litellm

Der Trick: Das Modell heißt nach außen gpt-4o. Anwendungen, die hartcodiert auf diesen Namen setzen, funktionieren ohne eine einzige Code-Änderung. Intern wird transparent auf Llama, Qwen oder Mistral geroutet — abhängig vom Use-Case. So lassen sich teure Modelle für komplexe Aufgaben reservieren und günstige Varianten für Bulk-Workloads.

Reverse-Proxy, mTLS und Zugriffsschutz

Vor LiteLLM gehört ein TLS-terminierender Reverse-Proxy. Traefik und Caddy sind dafür gleichermaßen geeignet. Caddy punktet mit automatischer ACME-Integration für interne CAs, Traefik mit dynamischer Service-Discovery in Kubernetes- oder Docker-Swarm-Umgebungen. Für hochsensible Workloads empfiehlt sich mTLS: Jeder Client weist sich mit einem eigenen Zertifikat aus, ausgestellt von der internen PKI. Damit ist nicht nur der Transportweg verschlüsselt, sondern auch die Identität des Aufrufers kryptografisch nachweisbar.

# Caddyfile
api.ki.intern {
    tls /etc/ssl/api.crt /etc/ssl/api.key {
        client_auth {
            mode require_and_verify
            trusted_ca_cert_file /etc/ssl/internal-ca.crt
        }
    }
    reverse_proxy litellm:4000
}

Multi-Model-Routing nach Use-Case

Eine zentrale Stärke des Stacks ist das gezielte Routing. Nicht jeder Request braucht das größte Modell. Sinnvoll ist eine Differenzierung nach drei Klassen:

Klasse	Modell-Beispiel	Use-Case	Zielzeit
Schnell & günstig	Qwen 2.5-7B, Llama 3.2-3B	Klassifikation, Routing-Entscheidungen, Auto-Complete	< 200 ms TTFT
Standard-Chat	Llama 3.3-70B, Mistral Small 3	Mitarbeiter-Assistent, RAG-Antworten, Zusammenfassungen	< 1.5 s TTFT
Reasoning & Tools	Qwen 2.5-72B, DeepSeek-V3	Code-Reviews, Multi-Step-Agents, Auswertungen	< 3 s TTFT
Embeddings	BGE-M3, Jina-v3	Vektorisierung für RAG, semantische Suche	< 50 ms / Doc

Über LiteLLMs model_group_alias oder Tags lassen sich Anwendungen pro Team auf passende Klassen lenken. Fallback-Ketten fangen Ausfälle ab — etwa, wenn ein 70B-Modell wegen GPU-Wartung nicht erreichbar ist und temporär auf ein 32B-Modell ausgewichen wird.

Streaming, Tool-Calls und Strukturierte Ausgaben

Streaming-Responses sind kein Nice-to-have, sondern ein UX-Faktor. vLLM liefert Server-Sent-Events kompatibel zum OpenAI-Format. Wichtig ist, dass auch der Reverse-Proxy buffering off setzt — sonst sammeln sich Chunks an und der Effekt verpufft. In Caddy genügt flush_interval -1, in Traefik das Header-Pass-Through.

Tool-Calling ist 2026 produktionsreif. Modelle der Llama-3.3-, Qwen-2.5- und Mistral-Large-Familien beherrschen das OpenAI-Tool-Schema einschließlich paralleler Aufrufe. Beim Start von vLLM müssen --enable-auto-tool-choice und ein passender --tool-call-parser gesetzt sein. Für strukturierte Ausgaben unterstützt vLLM response_format: {"type": "json_schema"} mit garantierter Schema-Konformität via Outlines oder XGrammar — ein massiver Vorteil gegenüber Free-Form-Prompting.

Monitoring, Rate-Limits und Cost-Tracking

vLLM exportiert Prometheus-Metriken auf /metrics: Time-to-First-Token, Inter-Token-Latency, GPU-Utilization, Running- und Waiting-Requests, KV-Cache-Belegung. Das sind die vier Kennzahlen, die in jedem Grafana-Dashboard sichtbar sein sollten. Capacity-Engpässe zeigen sich zuerst an steigenden Waiting-Queues — das Signal für horizontale Skalierung oder härtere Quotas.

Rate-Limits gehören in LiteLLM, nicht in vLLM. Pro virtuellem Key lassen sich Requests pro Minute, Tokens pro Tag und Monatsbudgets festlegen. Cost-Tracking funktioniert über hinterlegte Token-Preise: Auch wenn das Modell intern läuft, berechnet LiteLLM einen synthetischen Preis, der für die interne Leistungsverrechnung an Fachbereiche genutzt werden kann. Das schafft Akzeptanz im Controlling, weil jede Abteilung sieht, was sie verbraucht.

Betrieb, Updates und Härtung

Im Produktionsbetrieb gelten dieselben Regeln wie für jeden anderen kritischen API-Service. Container-Images werden pinned, Updates laufen über einen Staging-Cluster, Modell-Wechsel werden per Canary-Deployment validiert. LiteLLMs master_key liegt in Vault, virtuelle Keys werden alle 90 Tage rotiert. Logs landen zentral in Loki oder OpenSearch und enthalten request_id, user_team, model_name sowie Token-Counts — niemals den Prompt-Inhalt selbst, sofern keine ausdrückliche Genehmigung der Datenschutzbeauftragten vorliegt.

Ein häufig unterschätzter Punkt ist Prompt-Injection-Schutz. Auch ein perfekt isolierter Endpoint hilft nichts, wenn ein Tool-Call externe Inhalte unkritisch in den Kontext zieht. Hier greift eine separate Schutzschicht — mehr dazu im verlinkten Artikel zur Injection-Abwehr.

Häufige Fragen