120 lines
5.5 KiB
Markdown
120 lines
5.5 KiB
Markdown
# 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](https://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:
|
||
|
||
1. **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.
|
||
2. **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.
|
||
3. 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
|
||
|
||
1. Wie viele Benutzer insgesamt / gleichzeitig? (bestimmt Modellgröße)
|
||
2. Datenvolumen und Dateitypen auf den Shares? (Office, PDF, Scans/OCR?)
|
||
3. Müssen Berechtigungen der Shares in der Suche durchgesetzt werden? (s. o.)
|
||
4. Nur Chat + Suche, oder auch API-Zugriff für Anwendungen/Skripte?
|
||
|
||
## Quellen
|
||
|
||
- [LM Studio Docs — Headless/llmster](https://lmstudio.ai/docs/app/api/headless)
|
||
- [Top 20 Tools to Run LLMs Locally in 2026 (iunera)](https://www.iunera.com/kraken/enterprise-ai/top-20-tools-to-run-llms-locally-in-2026-ollama-anythingllm-open-webui-lm-studio-vllm-and-every-real-alternative-compared/)
|
||
- [Open WebUI Overview (glukhov.org)](https://www.glukhov.org/llm-hosting/llm-frontends/open-webui-overview-quickstart-and-alternatives/)
|
||
- [LM Studio Complete Guide 2026 (codersera)](https://codersera.com/blog/lm-studio-complete-guide-2026/)
|
||
- [Open WebUI + LM Studio Integration (markaicode)](https://markaicode.com/integrate/open-webui-with-lm-studio/)
|