Copyright © 2022-2026 basebox GmbH, all rights reserved.
Licensed to be used in conjunction with basebox, only.

// installation

Inferenz-Architektur

Gilt für

Produkt: Server · Zielgruppe: Platform Operator

Wo Inferenz läuft (derselbe Knoten, separater GPU-Host, separater Cluster, externer Anbieter), wie AISRV mit ihr spricht (OpenAI-kompatible API) und wie die Datengrenze verläuft. Die Architektur ist bewusst so gebaut, dass Sie das Modell wechseln oder verschieben können, ohne basebox anzufassen.

Die Schnittstelle

AISRV ruft die Inferenz über eine OpenAI-kompatible API auf:

GET /v1/models – welche Modelle der Endpunkt anbietet; der Bezeichner muss AISRV_LLM_MODEL entsprechen
POST /v1/chat/completions – Chat Completions, mit Streaming (Server-Sent Events) und Tool Calling, wenn das Modell es unterstützt

Der Endpunkt verlangt einen API-Schlüssel (Bearer), den AISRV aus einem Kubernetes-Secret bezieht. Was AISRV sonst über das Modell wissen muss – Kontextgröße, Ausgabelimit, Sampling-Standardwerte – steht in den AISRV_LLM_*-Variablen: Modelle konfigurieren.

Wo Inferenz laufen kann

flowchart LR
  AISRV["AISRV<br/>basebox-Plattform"]
  AISRV -->|"http://inference:8000"| A["A · Gebündeltes vLLM<br/>derselbe Kubernetes-Knoten"]
  AISRV -->|"https://…  TLS + API-Key"| B["B · Separater GPU-Host<br/>im Kundennetz"]
  AISRV -->|"https://…  TLS + API-Key"| C["C · Anderer Cluster<br/>oder andere Sicherheitszone"]
  AISRV -.->|"https://…  nur wo freigegeben"| D["D · Externer Anbieter"]
  style AISRV fill:#f4f2ee,stroke:#524e47,color:#1d1e1c
  style A fill:#dbeafe,stroke:#1e40af,color:#1d1e1c
  style B fill:#dbeafe,stroke:#1e40af,color:#1d1e1c
  style C fill:#dbeafe,stroke:#1e40af,color:#1d1e1c
  style D fill:#e5e7eb,stroke:#6b7280,color:#1d1e1c

Variante	Beschreibung	Typisch für	Datengrenze
A – Gebündelt	Das Chart stellt `inference` (vLLM) auf demselben Knoten bereit; Verkehr bleibt im Cluster	Referenzkonfigurationen, Einzelknoten	Innerhalb des Servers
B – Separater GPU-Host	Reiner CPU-Anwendungsserver + GPU-Host; AISRV spricht den Endpunkt über TLS an	Vorhandenes GPU-System, getrennte Verwaltung	Beide Hosts in derselben Datenverarbeitungsgrenze
C – Anderer Cluster / Sicherheitszone	Wie B, mit Cluster- oder Zonengrenze; Firewall nur AISRV → Endpunkt	Größere Organisationen	Beide Zonen freigegeben
D – Externer Anbieter	Ein freigegebener API-Anbieter mit OpenAI-kompatibler API	Nur wo Datenschutz und Vertrag es erlauben	Prompts und Kontext verlassen Ihre Umgebung

A ist der Standard und unter Inferenz anbinden beschrieben; B und C mit ausgearbeitetem vLLM-Beispiel unter Deployment-Topologien. D ist eine Datenschutz- und Vertragsentscheidung der Organisation – siehe Modellanbieter; Closed-Source-Modelle sind nicht Teil der basebox-Lieferung.

Was über die Grenze geht

Bei jeder Anfrage wandern vom Anwendungsserver zum Inferenzserver: der Prompt (Systemnachricht, organisationsweiter System-Prompt, persönliche Instruktionen, Nutzerfrage), die Historie der Unterhaltung, abgerufener Kontext aus Wissensbasen (die relevantesten Abschnitte), Inhalte hochgeladener Dokumente und Werkzeugergebnisse aus Konnektoren. Zurück kommen Tokens der Antwort und gegebenenfalls Reasoning-Inhalte.

Deshalb: Liegen Anwendungsserver und Inferenz auf verschiedenen Hosts, gehören beide in dieselbe freigegebene Datenverarbeitungsgrenze, der Pfad ist TLS-geschützt, und nur AISRV darf den Endpunkt erreichen. Nutzer und Browser sprechen nie direkt mit der Inferenz.

Was die Inferenz nicht sieht

Keine Zugangsdaten von Nutzern oder Konnektoren – die bleiben in AISRV.
Keine Identitäten über das hinaus, was im Prompt steht.
Keine Dokumente, die für die Frage nicht abgerufen wurden – RAG liefert Abschnitte, nicht Wissensbasen.

Verhalten im Betrieb

Kaltstart: Modelle laden beim ersten Start mehrere Minuten (2 × H200: etwa 6 Minuten bis Warm-up). Probes mit langem initialDelaySeconds; eine Warm-up-Generierung vor der Nutzerfreigabe.
Kein stiller Rückfall: Ist der Endpunkt offline, zeigt basebox den Fehler und erholt sich, sobald der Endpunkt wieder bereit ist.
Health und Metriken: Der Endpunkt stellt /health und Runtime-Metriken bereit; GPU-Metriken über DCGM – siehe Monitoring.
Streaming: AISRV streamt Tokens an die Oberfläche und die API weiter; Ingress und Proxies auf dem Pfad dürfen nicht puffern.

GPU-Layouts der Inferenz

Eine komplette GPU für ein Modell – der Normalfall.
Tensor-Parallelismus über zwei oder mehr GPUs für große Modelle oder lange Kontexte (NUM_GPUS); TP muss die Attention-Heads teilen; das GPU-Paar mit dem schnellsten Peer-Pfad wählen – siehe Multi-GPU.
Mehrere Modelle oder Instanzen nebeneinander – siehe Mehrere Inferenz-Instanzen.
Nie MIG für die Inferenz-GPU in den Referenzkonfigurationen; MIG dient den Service-Modellen.

Abgrenzung zu den Service-Modellen

Embeddings, RAG-Verarbeitung, OCR und Sprache-zu-Text sind keine Inferenz im Sinne dieser Seite. Sie laufen in ragsrv/ragsrv-support und eigenen Modell-Endpunkten auf einer dedizierten Service-GPU oder MIG-Slices – siehe Service-Modelle. Ein Wechsel des Sprachmodells berührt sie nicht.

Nächster Schritt: Unterstützte Inferenz-Backends