Zum Inhalt

// installation

Unterstützte Inferenz-Backends

Gilt für

Produkt: Server · Zielgruppe: Platform Operator

Gegen welche Inferenz-Runtimes basebox validiert ist, welche voraussichtlich funktionieren und was jeder OpenAI-kompatible Endpunkt erfüllen muss. Kurz: vLLM ist das validierte Backend; alles andere ist kompatibel, sofern es die Anforderungen unten erfüllt – geprüft ist es damit nicht.

Status der Backends

Backend Status Anmerkung
vLLM Validated Gebündelt im Chart (inference); als externer Endpunkt mit basebox 1.7.1 und vLLM 0.15.0 erprobt. GPT-OSS-Modelle benötigen vLLM 0.10.1+ und einen konfigurierten Reasoning-Parser
TGI (Text Generation Inference) Wartungsmodus Bis basebox 1.5 die Inferenz-Engine; seit 1.6 durch vLLM ersetzt. Nicht für neue Installationen
Andere OpenAI-kompatible Runtimes (z. B. SGLang, TensorRT-LLM mit OpenAI-Frontend, llama.cpp-Server, Ollama) Kompatibel, nicht getestet Funktionieren voraussichtlich, wenn die Anforderungen unten erfüllt sind; Status Experimental bis zur Prüfung
Externe Anbieter (OpenAI, Anthropic, Vertex AI) Kompatibel, vertraglich zu prüfen AISRV kennt providerspezifische Auth-Schemata; Closed-Source-Modelle sind nicht Teil der Lieferung, Datenschutz und Vertrag liegen beim Kunden

Was jeder Endpunkt erfüllen muss

Unabhängig vom Backend gilt für einen Endpunkt, den AISRV nutzen soll:

Anforderung Warum
GET /v1/models liefert den Modellbezeichner, der in AISRV_LLM_MODEL steht AISRV prüft und adressiert das Modell darüber
POST /v1/chat/completions im OpenAI-Format, mit Streaming (SSE) Oberfläche und API streamen Antworten
Nachrichtenrollen system, user, assistant, tool Konnektoren und API nutzen Tool-Nachrichten
Tool Calling (Function Calling), wenn Konnektoren genutzt werden sollen Der Assistent ruft Werkzeuge über Funktionsaufrufe des Modells auf
Reasoning-Ausgabe getrennt vom Antworttext (Reasoning-Parser), wenn Denkmodi genutzt werden sollen Sonst landet der Gedankengang im Antworttext
Kontext- und Ausgabelimits passend zu AISRV_LLM_CONTEXT_SIZE / AISRV_LLM_MAX_TOKENS Sonst Abbrüche bei langem Kontext
API-Zugangsberechtigung (Bearer) Kein offener Endpunkt
TLS, wenn Verkehr Hosts oder Sicherheitszonen überschreitet Prompts und Kontext wandern über diesen Pfad
Nur von AISRV erreichbar Nutzer sprechen nie direkt mit der Inferenz
Health-Endpunkt und Runtime-Metriken Monitoring, Probes, Alarmierung
Stabile Latenz unter Parallelität (Batching) Mehrere Nutzer gleichzeitig

Zusätzlich sinnvoll: KV-Cache-Quantisierung (verdoppelt etwa die Kapazität an gleichzeitigen Nutzern) und Unterstützung der nativen Quantisierungsformate FP8, AWQ, GPTQ – GGUF ist in vLLM experimentell (nur Einzeldatei, eingeschränkte Funktionen) und für Produktion nicht empfohlen.

Provider in AISRV

AISRV_LLM_PROVIDER bestimmt das Authentifizierungsschema gegenüber dem Endpunkt. Bekannte Werte aus den Beispielen der Dokumentation:

Wert Verwendung
vLLM vLLM-Endpunkte; aktuelle Releases leiten daraus VLLM_API_KEY ab – beide Schlüsselvariablen auf dasselbe Secret setzen
openai-compatible Generischer OpenAI-kompatibler Endpunkt mit Bearer-Schlüssel

Für Anthropic-Modelle fügt basebox keine künstlichen Instruktionen hinzu; ein Vertex-AI-Modus mit Tool-Call-Unterstützung existiert seit 1.7. Die vollständige Provider-Liste erhalten Sie von basebox.

Was „validiert" bei vLLM bedeutet

  • Die gebündelte inference-Komponente ist ein vLLM-Image aus der basebox-Registry; Modell, GPUs, Kontext und Cache werden über MODEL_ID, NUM_GPUS, MAX_INPUT_TOKENS, HF_HOME gesetzt – siehe Inference Server.
  • Externe vLLM-Endpunkte sind mit dem dokumentierten Values-Beispiel erprobt – siehe Deployment-Topologien.
  • Die Referenzkonfigurationen und die LLM-Empfehlungen beziehen sich auf vLLM.

Ein anderes Backend einsetzen

  1. Anforderungen oben gegen die Dokumentation der Runtime prüfen – besonders Tool Calling, Reasoning-Parser, Streaming.
  2. Als externen Endpunkt anbinden (Inferenz anbinden, Variante B), damit die gebündelte Komponente unberührt bleibt.
  3. GET /v1/models aus dem AISRV-Pod prüfen; Chat, langer Kontext, Streaming, Tool-Aufruf über einen Konnektor, Reasoning-Anzeige testen.
  4. Ergebnis mit Backend-Version, Modell und Hardware an basebox melden – so wird aus Experimental gegebenenfalls Supported. Vorlage: Andere Modelle nutzen.

Nächster Schritt: Modelle konfigurieren