CubelaPetarandClaude Fable 5
43054f32b8
- run.yml: base plays (geerlingguy.security) for jira and git; gpu01 play with security + docker + nvidia_gpu - roles/nvidia_gpu: driver pinned >=580 (Blackwell), CUDA repo, container toolkit incl. the nvidia-ctk runtime configure step - manuals/20260714-nvidia-driver-install.md: dated per convention, corrected (pinned -server driver instead of autoinstall+cuda-drivers mix, toolkit optional, added missing nvidia-ctk/docker restart step) - gpu01 folder: planning docs under notes/, runbooks under manuals/, scripts/; convention documented in CLAUDE.md - scripts/share-analysis.ps1: read-only SMB share analysis for the Windows server (projektplan §2.1) - TODO.md: Phase-0 pre-work items from the projektplan Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
5.5 KiB
Software Assessment — GPU Server für LLM-Workloads
Date: 2026-07-06 Status: Draft for internal review
TL;DR
LM Studio ist als Server-Dienst für viele Benutzer nicht geeignet. Es ist ein Desktop-Tool für Einzelnutzer. Empfehlung: vLLM als Inference-Server + Open WebUI als Benutzeroberfläche (Multi-User, LDAP). Für die Datei-Suche über SMB-Shares wird zusätzlich eine RAG-/Enterprise-Search-Komponente benötigt — das ist der eigentlich anspruchsvolle Teil des Projekts, nicht das LLM-Hosting.
1. Ist LM Studio als Server-Dienst geeignet?
Kurz: Nein, nicht für den Multi-User-Betrieb.
Was LM Studio inzwischen kann:
- Headless-Betrieb ohne GUI über den
llmster-Daemon (offiziell dokumentiert: lmstudio.ai/docs/app/api/headless) - OpenAI-kompatible lokale API
- Seit 2025 auch für kommerzielle Nutzung kostenlos
Warum es trotzdem ungeeignet ist:
| Anforderung | LM Studio |
|---|---|
| Multi-User / Benutzerverwaltung | ❌ Keine — die API ist für einen lokalen Einzelnutzer gedacht, ohne Benutzerkonten |
| LDAP/AD-Anbindung | ❌ Nicht vorhanden |
| Gleichzeitige Anfragen vieler Nutzer | ❌ llama.cpp-Backend, kein Continuous Batching wie vLLM — Durchsatz bricht bei Parallelität ein |
| Modell-Verwaltung im Betrieb | ⚠️ Modell-Laden ist exklusiv; Wechsel unterbricht den Dienst |
| RAG / Suche über Netzlaufwerke | ❌ Nur lokale Datei-Anhänge im Chat, keine Index-Pipeline |
Fazit: LM Studio bleibt sinnvoll als lokales Tool für Power-User am Arbeitsplatz, aber der Server braucht einen echten Inference-Stack.
2. Empfohlener Software-Stack
[User-Browser] ──► Open WebUI (Auth via LDAP/AD, Chat-UI, RAG)
│ OpenAI-kompatible API
▼
vLLM (Inference-Server, Continuous Batching)
▼
1× GPU (96 GB VRAM)
[SMB-Shares] ──► Index-Pipeline (Embedding + Vektor-DB) ──► RAG-Abfragen
Inference: vLLM
- De-facto-Standard für Multi-User-LLM-Serving: Continuous Batching, PagedAttention, hoher Durchsatz bei vielen gleichzeitigen Nutzern
- OpenAI-kompatible API → jedes Frontend (auch LM Studio-Clients der Power-User) kann sich verbinden
- Läuft als Docker-Container, gut automatisierbar
Frontend: Open WebUI
- Multi-User mit Rollen/Gruppen, native LDAP-Anbindung (deckt die Anforderung "Alle User angebunden (LDAP?)" aus den Notizen ab)
- Chat-UI im ChatGPT-Stil — geeignet für Nicht-Power-User
- Eingebaute RAG-Funktion ("Knowledge Bases"): Dokumente hochladen und durchsuchen
Datei-Suche über SMB-Shares — der kritische Punkt
"Suchmaschine für eigene Daten" heißt: die Shares müssen indiziert werden (Embedding-Modell + Vektor-Datenbank), nicht nur per Chat angehängt. Optionen:
- Open WebUI Knowledge Bases — seit v0.9.6 mit offiziellem Sync-Tool
oikb: gemountete Verzeichnisse (→ SMB-Shares) werden inkrementell in Knowledge Bases gespiegelt. Details:20260707-deep-dive.md§4.3. - Onyx (ehem. Danswer) — dediziertes Enterprise-Search-Produkt, Konnektoren für Datei-Quellen, eigene Benutzer-/Rechteverwaltung, nutzt das lokale LLM via OpenAI-API. Passender für den Vollausbau.
- Eigene Pipeline (gemountete Shares + Embedding-Job + Qdrant/pgvector) — maximale Kontrolle, mehr Aufwand.
⚠️ Offener Punkt, vor Angebot klären: Müssen Suchergebnisse die NTFS-/Share-Berechtigungen respektieren (User A darf Dokumente von Abteilung B nicht sehen)? Permission-Trimming ist in keiner der Standard-Lösungen trivial und bestimmt maßgeblich Aufwand und Produktwahl. Wenn ja, ist Onyx oder eine kommerzielle Lösung fast zwingend; wenn die Shares ohnehin für alle lesbar sind, reicht der einfache Stack.
Modelle (bei 96 GB VRAM)
- Start: ein 20–32B-Instruct-Modell (z. B. Qwen3-32B oder gpt-oss-20b) in FP8 — schnell, viel KV-Cache-Headroom für viele parallele Nutzer, gutes Deutsch
- Option: 70B-Klasse in FP8 oder gpt-oss-120b (MXFP4, ~63 GB) passt auf die eine Karte, wenn mehr Qualität gewünscht ist — auf Kosten des Durchsatzes
- Zusätzlich ein Embedding-Modell für die Suche (z. B. multilingual-e5 oder bge-m3, klein, läuft nebenher auf derselben GPU)
Betrieb
- Ubuntu Server 24.04 LTS, NVIDIA-Treiber + Container Toolkit
- Alles als Docker Compose (vLLM, Open WebUI, Vektor-DB) → reproduzierbar, einfache Updates
- Backup nur für Konfiguration + Vektor-DB nötig; Modelle sind wiederbeschaffbar
3. Offene Fragen an den Kunden
- Wie viele Benutzer insgesamt / gleichzeitig? (bestimmt Modellgröße)
- Datenvolumen und Dateitypen auf den Shares? (Office, PDF, Scans/OCR?)
- Müssen Berechtigungen der Shares in der Suche durchgesetzt werden? (s. o.)
- Nur Chat + Suche, oder auch API-Zugriff für Anwendungen/Skripte?