Eigenes ChatGPT self-hosted: vLLM mit Qwen3.5-122B auf zwei RTX PRO 6000 Blackwell

vLLM einrichten und betreiben lassen - WZ-IT setzt produktive LLM-Inferenz auf, auch auf Ihrer eigenen GPU-Hardware: Modellwahl, Tensor-Parallelität, OpenWebUI-Anbindung, Monitoring und Betrieb. Kostenlosen Termin vereinbaren

Ein eigenes ChatGPT, das vollständig im eigenen Haus läuft: eine vertraute Chat-Oberfläche, dahinter ein großes Sprachmodell auf eigener Hardware, ohne dass ein einziger Prompt an einen externen Dienst geht. Das ist kein Zukunftsszenario mehr, sondern mit aktueller Hardware und Open-Source-Software gut umsetzbar.

Dieser Beitrag zeigt, wie ein solches Setup konkret aussieht: das Inferenz-Framework vLLM, das ein 122-Milliarden-Parameter-Modell per Tensor-Parallelität über zwei NVIDIA RTX PRO 6000 Blackwell verteilt, dazu OpenWebUI als Weboberfläche. Statt eines geschönten Hochglanz-Guides geht es um die Punkte, die in der Praxis wirklich Zeit kosten: die richtige Modellwahl, vLLM-Parameter, eine typische Start-Stolperfalle bei Hybrid-Modellen, die Speicherplanung und der saubere Betrieb.

Inhaltsverzeichnis

• Was dieses Setup leistet
• Die Architektur: zwei Server, klar getrennt
• Hardware und Treiber: RTX PRO 6000 Blackwell
• Das Modell: Qwen3.5-122B-A10B-FP8
• vLLM konfigurieren: Tensor-Parallelität und FP8
• Die Stolperfalle: max-num-seqs bei Hybrid-Modellen
• Wo das Modell landet: Cache und Speicherplanung
• OpenWebUI als Weboberfläche anbinden
• Sicherheit und Betrieb
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides
• Quellen

Was dieses Setup leistet

Das Ziel ist eine datensouveräne KI-Plattform: eine ChatGPT-ähnliche Weboberfläche mit einem großen, lokal laufenden Sprachmodell, on-premise und ohne Cloud-Abhängigkeit. Zwei Open-Source-Komponenten tragen das:

• vLLM als Inferenz-Server. Es lädt das Modell, verteilt es über die GPUs und stellt eine OpenAI-kompatible API bereit. Bestehende Tools und SDKs sprechen damit ohne Umbau mit dem lokalen Modell.
• OpenWebUI als Weboberfläche. Login, Nutzerverwaltung, Chat, Dokumenten-Upload mit RAG. Für die Nutzer fühlt es sich an wie ein gewohntes Chat-Frontend.

Der Reiz liegt in der Kombination aus Komfort und Kontrolle: Mitarbeiter bekommen eine vertraute Oberfläche, das Unternehmen behält die volle Hoheit über Modell, Daten und Infrastruktur.

Die Architektur: zwei Server, klar getrennt

Bewährt hat sich die Trennung von rechenintensiver Inferenz und leichtgewichtigem Frontend auf zwei Maschinen:

Diese Trennung hat handfeste Vorteile: Beide Komponenten lassen sich unabhängig aktualisieren, neu starten und absichern. Das GPU-Backend bleibt schlank und macht nur eine Sache, das Frontend kann mehrere Backends oder Modelle ansprechen. Die Kommunikation läuft über das interne Netz, abgesichert über einen API-Key.

Hardware und Treiber: RTX PRO 6000 Blackwell

Die Basis bilden zwei NVIDIA RTX PRO 6000 Blackwell mit je 96 GB GDDR7 (mit ECC). Zusammen stehen 192 GB VRAM zur Verfügung, genug für ein 122B-Modell in FP8 samt Cache.

Wichtig für Blackwell-GPUs ist ein aktueller Treiber-Stack. In der Praxis läuft das Setup mit dem NVIDIA-Treiber aus dem 580er-Branch und CUDA 13. Ältere Treiber kennen die Blackwell-Architektur noch nicht oder bringen nicht die nötige FP8-Unterstützung mit. Dazu kommen ein aktueller Docker-Stack und das NVIDIA Container Toolkit, damit die GPUs im Container sichtbar sind.

Ein Detail, das später wichtig wird: Für Tensor-Parallelität müssen die beiden GPU-Worker-Prozesse über Shared Memory kommunizieren. Im Container heißt das --ipc=host und ein ausreichend großzügig dimensioniertes --shm-size.

Das Modell: Qwen3.5-122B-A10B-FP8

Als Modell kommt Qwen/Qwen3.5-122B-A10B-FP8 zum Einsatz, veröffentlicht unter Apache-2.0-Lizenz. Die Eckdaten erklären, warum es gut auf diese Hardware passt:

• Mixture of Experts (MoE): rund 122 Milliarden Gesamt-Parameter, aber nur etwa 10 Milliarden aktiv pro Token (daher "A10B"). Das bringt die Qualität eines großen Modells bei der Rechenlast eines deutlich kleineren.
• FP8-Quantisierung: Die Gewichte belegen rund 125 GB statt etwa 245 GB in BF16. Erst das macht den Betrieb auf zwei 96-GB-Karten realistisch.
• Hybrid-Architektur: Qwen3.5 mischt Gated-DeltaNet-Layer (eine lineare Attention-Variante mit Recurrent-State) und klassische Full-Attention-Layer im Verhältnis 3:1. Das senkt den KV-Cache-Bedarf gegenüber einem reinen Attention-Modell deutlich und macht lange Kontexte auf dieser Hardware überhaupt erst praktikabel.
• Reasoning-Modus: Qwen3.5 erzeugt standardmäßig einen Denk-Block vor der eigentlichen Antwort. Das lässt sich pro Anfrage über enable_thinking: false abschalten.

Ein häufiges Missverständnis: Das native Kontextfenster beträgt nicht 64k, sondern 256k Tokens (per YaRN noch deutlich mehr). 64k ist eine bewusste Begrenzung im Setup, nicht das Limit des Modells.

vLLM konfigurieren: Tensor-Parallelität und FP8

Der Kern ist eine Docker-Compose-Datei für vLLM. Der entscheidende Parameter ist --tensor-parallel-size 2: vLLM teilt das eine Modell über beide GPUs auf (Tensor-Parallelität, nicht zwei Kopien). Der API-Key kommt über eine Umgebungsvariable, niemals als Klartext in die Datei.

services:
  vllm:
    image: vllm/vllm-openai:latest
    container_name: vllm-qwen
    restart: unless-stopped
    gpus: all
    ipc: host
    shm_size: "64gb"
    ports:
      - "8000:8000"
    environment:
      HF_HOME: "/models/huggingface"
      VLLM_API_KEY: "${VLLM_API_KEY}"
    volumes:
      - /srv/hf-cache:/models/huggingface
      - /srv/vllm-cache:/root/.cache/vllm
    command:
      - "--model"
      - "Qwen/Qwen3.5-122B-A10B-FP8"
      - "--served-model-name"
      - "qwen35-122b"
      - "--tensor-parallel-size"
      - "2"
      - "--max-model-len"
      - "65536"
      - "--gpu-memory-utilization"
      - "0.90"
      - "--max-num-seqs"
      - "16"
      - "--reasoning-parser"
      - "qwen3"

Die wichtigsten Stellschrauben:

• --max-model-len 65536 begrenzt den Kontext bewusst auf 64k. Mehr Kontext kostet mehr Cache und reduziert die mögliche Parallelität.
• --gpu-memory-utilization 0.90 reserviert 90 Prozent des VRAM für vLLM. Der vLLM-Default liegt bei 0.92; 0.90 lässt etwas mehr Reserve.
• --max-num-seqs 16 ist der Punkt, an dem die meisten Setups beim ersten Start scheitern. Dazu der nächste Abschnitt.
• --reasoning-parser qwen3 sorgt dafür, dass vLLM den Denk-Block von Qwen3.5 sauber von der Antwort trennt.

Die Stolperfalle: max-num-seqs bei Hybrid-Modellen

Der typische erste Startversuch endet mit einem Abbruch, der auf zu viele parallele Sequenzen und fehlende State-Cache-Blöcke hinweist. Der Hintergrund ist die Hybrid-Architektur.

max_num_seqs legt fest, wie viele Sequenzen vLLM maximal gleichzeitig bearbeitet. Der Default der aktuellen V1-Engine ist 1024. Bei reinen Attention-Modellen ist das meist unproblematisch. Bei Hybrid-Modellen wie Qwen3.5 hängt aber die Anzahl der Recurrent-State-Slots an diesem Wert, und vLLM verwaltet diese Slots über sein Mamba-Cache-Subsystem (daher tauchen beim Start "Mamba"-Begriffe auf, obwohl es kein klassisches Mamba-Modell ist). Reichen die verfügbaren State-Cache-Blöcke für 1024 Sequenzen nicht, bricht der Start ab.

Die Lösung ist, max_num_seqs explizit zu senken. Für den ersten erfolgreichen Start ist ein konservativer Wert sinnvoll:

--max-num-seqs 16

Das ist kein Verlust: 16 gleichzeitige Sequenzen reichen für viele interne Szenarien, und der Wert lässt sich später kontrolliert erhöhen. Wichtig ist, dieses State-Slot-Thema nicht mit einem klassischen VRAM-Engpass zu verwechseln. Geht vLLM später bei der Inferenz der Speicher für den KV-Cache aus, ist der Hebel ein anderer (kleinerer Kontext oder weniger parallele Sequenzen), nicht weiteres Hochdrehen von max_num_seqs.

Wo das Modell landet: Cache und Speicherplanung

Eine Frage, die im Betrieb regelmäßig aufkommt: Wo lädt vLLM das Modell eigentlich hin? Die Antwort liegt im HuggingFace-Cache. Über HF_HOME wird der Pfad gesetzt, im Container hier auf ein gemountetes Volume. Das Modell landet dann in einer Struktur wie:

$HF_HOME/hub/models--Qwen--Qwen3.5-122B-A10B-FP8/
  ├── blobs/
  ├── snapshots/
  └── refs/

Während des Downloads liegen dort temporäre Dateien, die erst nach vollständigem Laden in die finalen Blobs übergehen. Solange noch unvollständige Dateien existieren, lädt vLLM weiter, auch wenn die GPUs schon Speicher belegen. Das ist normal und kein Hänger.

Für die Planung heißt das konkret: Die FP8-Gewichte belegen rund 125 GB. Der Cache sollte auf schnellem Storage liegen (NVMe), mit deutlich Reserve für künftige Modelle. Ein Download dieser Größe dauert je nach Anbindung spürbar, und ein zweiter Modellwechsel sollte nicht am Plattenplatz scheitern.

OpenWebUI als Weboberfläche anbinden

Auf dem Frontend-Server läuft OpenWebUI als zweiter Container. Es wird über die OpenAI-kompatible API an vLLM gehängt. Ollama wird bewusst deaktiviert, da die Inferenz vollständig über vLLM läuft.

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    ports:
      - "3000:8080"
    environment:
      WEBUI_NAME: "Interne KI"
      WEBUI_AUTH: "true"
      WEBUI_SECRET_KEY: "${OPENWEBUI_SECRET_KEY}"
      ENABLE_OPENAI_API: "true"
      # IP/Hostname des Inferenz-Servers, hier als Platzhalter
      OPENAI_API_BASE_URL: "http://10.0.0.11:8000/v1"
      OPENAI_API_KEY: "${VLLM_API_KEY}"
      DEFAULT_MODELS: "qwen35-122b"
      ENABLE_OLLAMA_API: "false"
      ENABLE_SIGNUP: "false"
      RAG_FULL_CONTEXT: "false"
    volumes:
      - open-webui-data:/app/backend/data
volumes:
  open-webui-data:

Drei Punkte aus der Praxis:

• Self-Registrierung aus: ENABLE_SIGNUP: "false" verhindert, dass sich beliebige Nutzer selbst anlegen. Nutzer legt der Admin an.
• RAG statt Full Context: Mit RAG_FULL_CONTEXT: "false" werden hochgeladene Dokumente über Retrieval verarbeitet. Den ganzen Dokument-Inhalt in den Kontext zu laden, ist nur für einzelne, kleine Dateien sinnvoll, sonst sprengt es schnell das Kontextfenster.
• CORS und URL: Sobald die Oberfläche über einen festen Hostnamen oder später über HTTPS erreichbar ist, müssen WEBUI_URL und CORS_ALLOW_ORIGIN auf genau diese Adressen gesetzt werden, sonst brechen WebSocket-Verbindungen und Streaming.

Sicherheit und Betrieb

Ein lauffähiges Setup ist nicht dasselbe wie ein produktionsreifes. Drei Themen gehören vor dem Rollout geklärt:

Netzwerk und Zugriff. Der vLLM-Endpunkt auf Port 8000 darf nicht offen im Netz stehen. Er sollte nur für das Frontend und berechtigte Admin-Netze erreichbar sein. OpenWebUI auf Port 3000 gehört hinter VPN oder zumindest in ein abgegrenztes Netz. Firewall und Netzsegmentierung sind dabei eine bewusste Aufgabe, kein Nebeneffekt der Installation.

Reverse Proxy und TLS. Im ersten Schritt läuft der Zugriff oft direkt auf Port 3000 ohne Verschlüsselung. Für den produktiven Betrieb gehört ein Reverse Proxy mit TLS davor. Wichtig dabei: WebSocket-Forwarding aktivieren und Proxy-Buffering für Streaming abschalten, sonst stockt die Ausgabe.

Backup und Updates. Die Nutzer, Chats und Einstellungen von OpenWebUI liegen in einem Docker-Volume. Dieses Volume gehört in eine regelmäßige, getestete Backup-Strategie, ein Backup ohne Restore-Test ist kein Backup. Genauso wichtig: ein Plan für Updates und ein laufendes CVE-Monitoring für die eingesetzten Container.

Unser Vorgehen bei WZ-IT

Ein Setup wie dieses haben wir in der Praxis aufgesetzt, und der Weg von "läuft auf dem Tisch" zu "läuft sauber im Betrieb" ist der eigentliche Aufwand. So gehen wir vor:

1. Architektur und Sizing. Modellwahl, Quantisierung, Kontextlänge, GPU-Topologie und realistische Nutzerzahl klären, bevor irgendetwas installiert wird. Das verhindert die meisten späteren Überraschungen.

2. Setup auf Ihrer oder unserer Hardware. Wir richten vLLM und OpenWebUI sauber ein, ob auf Ihren bestehenden GPU-Servern (Bring Your Own Infrastructure) oder auf einem von uns betriebenen GPU-Server bzw. AI Cube. Tensor-Parallelität, FP8, Cache-Pfade und API-Anbindung inklusive.

3. Härtung und Übergabe. Zugriffskonzept, Reverse Proxy, Backup, Monitoring und eine vollständige Betriebsdokumentation. Damit das System auch ohne uns betreibbar bleibt.

4. Managed-Betrieb auf Wunsch. Updates, Modellwechsel, CVE-Tracking und Support über unseren Managed-KI-Service, wenn Sie sich nicht selbst um den laufenden Betrieb kümmern wollen.

Der Wert steckt nicht in einer Lizenz, sondern in sauberem Design und zuverlässigem Betrieb. Genau das ist bei großen, self-hosted Modellen der Unterschied zwischen einem Demo und einer Plattform, auf die sich Mitarbeiter verlassen.

Weiterführende Guides

• Ollama vs. vLLM: Vergleich für Self-Hosted LLMs - wann welche Engine
• GPT-OSS 120B auf dem AI Cube Pro - ein großes Modell auf einer einzelnen Karte
• Langfuse self-hosted: LLM-Observability und KI-Logging - Nachvollziehbarkeit für produktive KI
• vLLM-Expertise bei WZ-IT - Setup, Konfiguration und Betrieb
• LLM-Hosting bei WZ-IT - souveräne KI-Infrastruktur

Eigene GPU-Hardware, aber kein Team für LLM-Betrieb? Wir setzen vLLM und OpenWebUI produktionsreif auf, dokumentieren das Setup und übernehmen auf Wunsch den Betrieb - DSGVO-konform und ohne Datenabfluss. Erstgespräch vereinbaren

Stand: Juni 2026. Versions- und Hardware-Angaben beziehen sich auf den genannten Stand. Open-Source-Projekte und Modelle entwickeln sich schnell - für die jeweils aktuellen Details lohnt der Blick in die offizielle vLLM- und Modell-Dokumentation.

Quellen

• Qwen3.5-122B-A10B-FP8 auf HuggingFace
• vLLM: OpenAI-kompatibler Server
• vLLM: Parallelität und Skalierung (Tensor-Parallelität)
• vLLM: Qwen3.5 Recipe
• vLLM: Hybrid-Modelle als First-Class Citizens (PyTorch Blog)
• NVIDIA RTX PRO 6000 Blackwell
• HuggingFace: Cache-Verwaltung
• OpenWebUI Dokumentation