@@ -0,0 +1,427 @@
# Deep Dive — GPU-Auswahl, Inference-Backend & Anbindung der SMB-Wissensbasis
Date: 2026-07-07
Status: Entscheidungsgrundlage für Kundengespräch
Basiert auf: `20260706-hardware-assessment.md` , `20260706-software-assessment.md`
---
## 0. Executive Summary
| Entscheidung | Empfehlung | Konfidenz |
|---|---|---|
| GPU | **RTX PRO 6000 Blackwell Server Edition (96 GB) ** statt H100 NVL | Hoch — durch mehrere unabhängige Benchmarks gedeckt |
| LM Studio als Server | **Nein ** — Desktop-Tool, kein Mehrbenutzer-Server | Hoch |
| Inference-Backend | **vLLM ** (ggf. Ollama zusätzlich für Power-User-Experimente) | Hoch |
| Frontend | **Open WebUI ** (LDAP/AD, Gruppen, Knowledge Bases) | Hoch |
| SMB-Anbindung | **Phase 1: Open WebUI Knowledge + offizielles Sync-Tool `oikb` ** ; Phase 2: Onyx nur falls Skalierung/Berechtigungen es erzwingen | Mittel — hängt von offenen Fragen ab (§6) |
---
## 1. GPU: RTX PRO 6000 Blackwell SE vs. H100 NVL
Der Kunde hat die H100 genannt. Das ist verständlich („die KI-GPU"), aber die
H100 ist eine **Hopper-Karte von 2022/23 ** und für verteiltes Training bzw.
Multi-GPU-Inference gebaut. Die RTX PRO 6000 Blackwell Server Edition (2025)
ist **zwei Architektur-Generationen neuer ** und von NVIDIA explizit als
Enterprise-Inference-Karte positioniert.
### 1.1 Daten im Vergleich
| | RTX PRO 6000 Blackwell SE | H100 NVL |
|---|---|---|
| Architektur | Blackwell (2025) | Hopper (2022/23) |
| VRAM | **96 GB GDDR7, ECC ** | 94 GB HBM3, ECC |
| Speicherbandbreite | 1,79 TB/s | **3,9 TB/s ** |
| FP8 / FP4 (NVFP4) | ✅ / * * ✅** | ✅ / ❌ |
| MIG (GPU-Partitionierung) | ✅ bis 4 Instanzen ([NVIDIA ](https://www.nvidia.com/en-us/data-center/rtx-pro-6000-blackwell-server-edition/ )) | ✅ bis 7 Instanzen |
| vGPU-Support | ✅ (vGPU 19.0, [NVIDIA Blog ](https://developer.nvidia.com/blog/nvidia-vgpu-19-0-enables-graphics-and-ai-virtualization-on-nvidia-blackwell-gpus/ )) | ✅ |
| NVLink | ❌ (nur PCIe Gen5) | ✅ (Paarweise) |
| Leistungsaufnahme | 600 W (passiv, Server-Kühlung) | ~400 W |
| Formfaktor | PCIe FHFL Dual-Slot, OEM-qualifiziert (u. a. [Lenovo ](https://lenovopress.lenovo.com/lp2263-thinksystem-nvidia-rtx-pro-6000-blackwell-server-edition-pcie-gen5-gpu ), HPE) | PCIe Dual-Slot |
| Straßenpreis | * * ~9–
### 1.2 Benchmark-Evidenz (der Kern der Argumentation)
Mehrere **unabhängige ** Quellen, alle mit vLLM als Serving-Stack:
1. **Single-GPU-Durchsatz: ** RTX PRO 6000 schlägt sogar die H100 SXM
(3.140 vs. 2.987 tok/s) bei **28 % niedrigeren Kosten pro Token **
([cloudrift.ai ](https://www.cloudrift.ai/blog/benchmarking-rtx6000-vs-datacenter-gpus )).
2. **Unter Parallellast ** (unser Szenario!): stärkste Skalierung aller
getesteten Karten; auf Qwen-32B vor A100 **und ** H100
([databasemart vLLM-Benchmark ](https://www.databasemart.com/blog/vllm-gpu-benchmark-pro6000 )).
3. **Bei 100 gleichzeitigen Requests ** : bis zu **1,63×
die H100** ([Akamai-Benchmark ](https://www.akamai.com/blog/cloud/benchmarking-nvidia-rtx-pro-6000-blackwell-akamai-cloud )).
4. Kostenanalyse pro Million Token: [Spheron ](https://www.spheron.network/blog/rent-nvidia-rtx-pro-6000/ ),
unabhängige Tests: [HOSTKEY ](https://huggingface.co/blog/HOSTKEY/nvidia-rtx-6000-blackwell-server-edition-tests-ben ),
Vergleich: [OpenMetal ](https://openmetal.io/resources/blog/comparing-the-nvidia-rtx-pro-6000-vs-h100-for-ai-inference/ ).
Warum schlägt GDDR7 hier HBM3? Die H100 spielt ihre Bandbreite erst bei
Multi-GPU-Tensor-Parallelität über NVLink aus. Bei **einer ** Karte limitiert
meist Compute/KV-Cache-Management — und da ist Blackwell schlicht neuer
(mehr FP8/FP4-Durchsatz, größere L2-Caches, besserer Scheduler).
### 1.3 Wann wäre die H100 trotzdem richtig? (Ehrlichkeit fürs Gespräch)
- **Multi-GPU-Modelle**: Modelle > 96 GB über 2+ GPUs gespannt → NVLink
gewinnt deutlich (8× × ×
- **Training/Fine-Tuning im Dauerbetrieb** über mehrere Karten.
- **Extreme Kontextlängen + sehr hohe Batchgrößen** (Bandbreiten-limitiert).
**Keiner dieser Punkte trifft hier zu ** : 1 GPU, reine Inference, ≤ 20
gleichzeitige Anfragen, Modelle ≤ 96 GB. Selbst der Wachstumspfad (zweite
RTX PRO 6000, zwei unabhängige vLLM-Replikate) braucht kein NVLink.
### 1.4 Argumentationslinie für den Kunden (Kurzform)
1. „Die H100 ist eine 2022er-Architektur am Ende ihres Zyklus; die RTX PRO
6000 ist NVIDIAs aktuelle Enterprise-Inference-Karte (Blackwell, 2025)."
2. „Für genau unser Szenario — eine Karte, viele gleichzeitige Chat-Anfragen —
ist sie in unabhängigen Benchmarks **gleich schnell bis 1,6× ** ."
3. „Mehr Speicher (96 vs. 94 GB), ECC, MIG, vGPU — alle Enterprise-Merkmale
vorhanden, OEM-qualifiziert (HPE/Lenovo/Dell)."
4. „**Ein Drittel des Preises.** Die Differenz (~21 k€) finanziert die
eigentliche Wertschöpfung — die Such-Pipeline — oder eine zweite GPU."
5. Einziger technischer Trade-off: kein NVLink und höhere Leistungsaufnahme
(600 W) — beides für diesen Use Case irrelevant bzw. vom Chassis abgedeckt.
⚠️ Vor Angebot prüfen: HPE-Qualifizierung der Karte für das konkrete Chassis
(DL380 Gen12 / DL380a) und vBIOS-Stand für MIG.
### 1.5 Alternativen — vollständig geprüft (Stand Juli 2026)
Re-Evaluation gegen das gesamte Feld, nicht nur gegen die H100:
| Kandidat | VRAM | Preis (ca.) | Bewertung für unseren Fall |
|---|---|---|---|
| **RTX PRO 6000 Blackwell SE ** | 96 GB | * * ~9–
| H100 NVL | 94 GB | ~26– × **Der risikoärmste, teuerste Weg. ** |
| H200 NVL | 141 GB | ~30– IntuitionLabs ](https://intuitionlabs.ai/articles/nvidia-ai-gpu-pricing-guide ), [JarvisLabs ](https://jarvislabs.ai/blog/h200-price )) | 45 GB mehr VRAM als nötig; Preis wie H100+15–
| L40S | 48 GB | ~8 k€ | Halber Speicher, weniger als halber Durchsatz (864 GB/s, Ada 2022, kein FP4), kaum billiger. Von der RTX PRO 6000 obsolet gemacht. |
| 2× ×
| RTX 5090 (Consumer) | 32 GB | ~2,5 k€ | Kein ECC, keine OEM-/Server-Qualifizierung, EULA-Grauzone im Rechenzentrum, 32 GB zu klein. Nein. |
| AMD MI300X | 192 GB | ~15– gpucost ](https://gpucost.org/gpu/mi300x )) | Auf dem Papier attraktiv (192 GB!), ROCm/vLLM inzwischen First-Class ([AMD ](https://rocm.blogs.amd.com/software-tools-optimization/vllm-omni/README.html )). Aber: **OAM-Modul, keine PCIe-Einzelkarte ** — existiert praktisch nur in 8-GPU-Plattformen, nicht im ProLiant-2U. Dazu ROCm-Betriebsrisiko ohne AMD-Erfahrung im Team. Scheidet formfaktorbedingt aus. |
Fazit der Re-Evaluation: Die Empfehlung **hält ** . Die einzige echte
Alternative ist die H100 NVL als „konservative Versicherung" zum 3-fachen
Preis — alle anderen Kandidaten scheitern an Formfaktor, Speicher oder
Preis-Leistung.
### 1.6 Risiken der RTX PRO 6000 SE — ehrlich benannt (wichtig!)
Die Karte ist neue Architektur (Blackwell/SM120), und 2025 bis Anfang 2026
gab es dokumentierte Kinderkrankheiten:
- **Kernel-Kompatibilität**: SM120 ist nicht abwärtskompatibel zu
Hopper-Kerneln; exotische Modellarchitekturen liefen anfangs nicht
(z. B. [DeepSeek-Serie ](https://github.com/vllm-project/vllm/issues/26211 ),
[NVFP4-Kernel ](https://github.com/vllm-project/vllm/issues/23497 )).
Mainstream-Modelle (Llama, Qwen, Mistral, gpt-oss) sind davon nicht
betroffen.
- **Reset-Bug bei Virtualisierung** (VM-Passthrough): GPU nach VM-Shutdown
in unrecoverable state; ab Treiber 580+ weitgehend behoben. → **Bare-Metal
betreiben** (ohnehin empfohlen).
- Vereinzelte Berichte über GPU-Resets unter Dauerlast und ein
[offenes vLLM-Issue (03/2026) ](https://github.com/vllm-project/vllm/issues/36327 ) —
letzteres betrifft `--tensor-parallel-size 4` , also **Multi-GPU, nicht
unsere Single-GPU-Konfiguration**.
**Warum das Risiko tragbar ist (Stand Juli 2026): **
1. NVIDIA führt die Karte offiziell in den
[vLLM-Release-Notes ](https://docs.nvidia.com/deeplearning/frameworks/vllm-release-notes/rel-25-09.html )
(funktionaler Support, CUDA 13.0) und stellt einen eigenen
[vLLM-Container für RTX ](https://build.nvidia.com/rtx/vllm ) bereit.
2. Systemhäuser liefern inzwischen **vLLM-vorvalidierte Server mit genau
dieser Karte** aus ([VRLA Tech ](https://vrlatech.com/running-vllm-on-your-own-hardware-the-production-guide-for-2026/ )).
3. HPE-qualifizierte Karte + Support-Vertrag = Hardware-Risiko abgedeckt.
**Absicherung im Projekt: ** aktueller Treiber (≥ 580/581), NVIDIA-vLLM-
Container statt Eigenbau, Bare-Metal, Mainstream-Modell, und die Pilotphase
(§4.7) als **Burn-in-Test ** nutzen — 2 Wochen Dauerlast vor Produktivsetzung.
Falls der Kunde maximale Risikoaversion über Preis stellt: H100 NVL als
dokumentierte Alternative anbieten und die Differenz transparent machen
(~20 k€ „Versicherungsprämie" für ausgereiftere Software-Basis).
---
## 2. Warum LM Studio (llmster) kein Server ist — Argumentation
LM Studio ist bei den Mitarbeitern bekannt und beliebt — das Argument muss
also respektvoll sein: **das Tool ist gut, aber es löst eine andere Aufgabe. **
| Server-Anforderung | LM Studio / llmster | Server-Stack (vLLM + Open WebUI) |
|---|---|---|
| Benutzerkonten & Login | ❌ keine Benutzerverwaltung | ✅ LDAP/AD, Rollen, Gruppen |
| Wer darf was (Modelle, Daten)? | ❌ ein API-Key für alle | ✅ RBAC pro Gruppe/Ressource |
| 10–
| Zentrale Wissensbasis (SMB) | ❌ nur lokale Datei-Anhänge pro Chat | ✅ zentrale, gepflegte Indizes |
| Audit/Protokollierung | ❌ | ✅ |
| Betrieb (Updates, Monitoring, HA) | ⚠️ Desktop-App-Zyklus | ✅ Container, Standard-Ops |
Kernsatz fürs Gespräch: *„llmster macht aus LM Studio einen Dienst ohne
Bildschirm — aber nicht ohne die Einzelnutzer-Architektur. Es fehlt alles,
was aus einem laufenden Modell einen Firmendienst macht: Anmeldung,
Berechtigungen, Parallelität, zentrale Datenanbindung."*
Wichtig: Die Mitarbeiter **verlieren nichts ** — Open WebUI fühlt sich wie
ChatGPT an (einfacher als LM Studio), und Power-User können LM Studio lokal
weiterverwenden oder per API-Key direkt gegen den Server arbeiten.
---
## 3. Inference-Backend: vLLM vs. Ollama
Beide sprechen die OpenAI-API und funktionieren mit Open WebUI. Der
Unterschied liegt in Architektur und Zielgruppe.
### 3.1 Ist vLLM wirklich effizienter? Ja — deutlich, sobald parallel
Aktuelle Benchmarks (2025/26):
- Bei **50 gleichzeitigen Nutzern ** : vLLM ~920 tok/s gesamt, Ollama
plateauiert bei ~155 tok/s; je nach Test **20– × ** und
8– × runaihome ](https://runaihome.com/blog/vllm-vs-ollama-when-each-wins-2026/ ),
[tech-insider ](https://tech-insider.org/vllm-vs-ollama-2026/ )).
- Peer-reviewte Studie: Ollama erreicht **Engpass bei ~10 gleichzeitigen
Nutzern**, 13–
([MDPI Applied Sciences ](https://doi.org/10.3390/app16115435 )).
- Bei **einem einzelnen Nutzer ** ist Ollama minimal schneller beim ersten
Token (~45 vs. ~82 ms TTFT) — irrelevant für einen Firmenserver
([Red Hat Benchmark ](https://developers.redhat.com/articles/2025/08/08/ollama-vs-vllm-deep-dive-performance-benchmarking ),
[SitePoint ](https://www.sitepoint.com/ollama-vs-vllm-performance-benchmark-2026/ )).
### 3.2 Der Modellwechsel-Trade-off, korrekt dargestellt
| | Ollama | vLLM |
|---|---|---|
| Modellwechsel | ✅ automatisch, lädt/entlädt on-the-fly | ⚠️ 1 Modell pro Instanz, Wechsel = Neustart (1–
| Mehrere Modelle parallel | ⚠️ ja, aber teilen sich GPU unkontrolliert | ✅ mehrere Instanzen mit fester VRAM-Zuteilung |
| Durchsatz unter Last | ❌ s. o. | ✅ |
Die Flexibilität von Ollama ist im Firmenbetrieb **weniger wert, als sie
klingt**: Nicht-Power-User wollen kein Modell wählen — sie wollen, dass es
funktioniert. Ein ungeplanter Modellwechsel entlädt zudem das Modell der
anderen 15 aktiven Nutzer (Kaltstart-Latenz für alle).
**Empfehlung — kein Entweder-oder: **
```
GPU (96 GB, via MIG oder VRAM-Quoten aufteilbar)
├── vLLM #1: Haupt-Chatmodell (fest, z. B. Qwen3-32B FP8) ~40 GB
├── vLLM #2: Embedding-Modell für die Suche ~4 GB
└── optional Ollama: Spielwiese für Power-User Rest
```
Open WebUI kann mehrere Backends gleichzeitig einbinden — die Normalnutzer
sehen nur „Firmen-Assistent", Power-User sehen zusätzlich die
Ollama-Modelle. Damit ist die Kundenfrage („Flexibilität vs. Effizienz")
keine Entscheidung mehr, sondern eine Konfiguration.
### 3.3 Lastabschätzung (100 Mitarbeiter)
Erfahrungswerte für interne Chat-Assistenten: ~30–
davon ~10– **5– ** .
Das bedient eine RTX PRO 6000 mit einem 32B-FP8-Modell unter vLLM komfortabel
(vgl. Benchmarks oben: brauchbare Latenz noch bei 50–
mit kleineren Modellen).
---
## 4. Anbindung der Wissensbasis (SMB-Shares) — der Deep Dive
### 4.1 Was technisch passieren muss (unabhängig vom Produkt)
Ein LLM kann nicht „auf den Share schauen". Die Pipeline ist immer:
```
SMB-Share ──mount──► Server (read-only, Service-Account)
│
▼
Extraktion (PDF, Office, E-Mail…; OCR für Scans)
▼
Chunking + Embedding (Embedding-Modell auf der GPU)
▼
Vektor-Datenbank (Index) ← periodischer Sync (cron)
▼
Retrieval zur Laufzeit: Frage → relevante Chunks → LLM antwortet mit Quellen
```
Die Produktfrage ist nur: **wer betreibt diese Pipeline und wie gut? **
### 4.2 Option A — LM Studio: scheidet aus
Kein zentraler Index möglich. Jeder Nutzer müsste Dateien manuell in seinen
Chat ziehen (RAG pro Sitzung, wenige Dateien). Für „Suchmaschine über die
Firmendaten" schlicht das falsche Werkzeug — unabhängig von der Serverfrage.
### 4.3 Option B — Open WebUI Knowledge + offizielles Sync-Tool `oikb` ⭐
Seit **v0.9.6 ** hat Open WebUI eine offizielle Lösung genau für unseren Fall
([Docs ](https://docs.openwebui.com/features/knowledge-base-sync/ ),
[GitHub open-webui/oikb ](https://github.com/open-webui/oikb )):
- **`oikb` ** (CLI, [PyPI ](https://pypi.org/project/oikb/ )) synchronisiert ein
Verzeichnis — also einen **auf dem Server gemounteten SMB-Share ** — in eine
Knowledge Base: inkrementell per SHA-256-Diff, nur neue/geänderte Dateien
werden neu embedded, Löschungen werden nachgezogen, Ordnerstruktur wird
gespiegelt. Ein unveränderter 10.000-Dateien-Bestand re-synct in Sekunden.
- Läuft als **Cron/systemd-Timer pro Share ** → vollautomatisch, kein
Nutzer-Zutun.
- **Berechtigungen**: Knowledge Bases sind per Gruppe zugreifbar; Open WebUI
synchronisiert **Gruppen direkt aus LDAP/AD **
([LDAP-Doku ](https://docs.openwebui.com/features/authentication-access/auth/ldap/ )).
Damit lässt sich die Share-Struktur abbilden:
```
\\fs01\konstruktion ──oikb──► KB "Konstruktion" ──► AD-Gruppe Konstruktion
\\fs01\vertrieb ──oikb──► KB "Vertrieb" ──► AD-Gruppe Vertrieb
\\fs01\allgemein ──oikb──► KB "Allgemein" ──► alle
` ``
- **Nutzererlebnis Normies**: Vorkonfigurierte „Modelle" in Open WebUI
(z. B. „Konstruktions-Assistent" = Chatmodell + KB Konstruktion fest
verdrahtet). Der Nutzer wählt den Assistenten und fragt auf Deutsch —
kein RAG-Wissen nötig, Antworten mit Quellenangabe (Datei + Passage).
- **Power-User**: können eigene Knowledge Bases anlegen, per ` #` gezielt
Kollektionen in den Chat holen, oder per API-Key direkt gegen vLLM arbeiten
(IDE-Integration, Skripte).
**Grenzen (ehrlich einplanen):**
1. **Berechtigungsgranularität = Share/Ordner-Ebene**, nicht NTFS-Datei-ACL.
Wer Zugriff auf die KB „Konstruktion" hat, kann alles darin erfragen.
2. **Skala**: praktikabel bis in den Bereich von einigen zehntausend
Dokumenten pro Kollektion; bei sehr großen Shares selektiv syncen
(Unterordner, Dateitypen-Filter). Für den DB-Unterbau bei Wachstum
**pgvector statt Default** einplanen ([Scaling-Doku](https://docs.openwebui.com/getting-started/advanced-topics/scaling/)).
3. **Extraktionsqualität** hängt von den Dateitypen ab: Office/PDF gut;
**gescannte PDFs brauchen OCR** (Tika/Docling als Extraktions-Engine
konfigurieren); CAD/proprietäre Formate bleiben außen vor.
### 4.4 Option C — Onyx (ehem. Danswer) als dedizierte Such-Anwendung
[Onyx](https://github.com/onyx-dot-app/onyx) ist ein spezialisiertes
Enterprise-Search-Produkt mit 50+ Konnektoren, darunter ein **File Connector
für lokale/Netzlaufwerke** ([Connector-Doku](https://docs.onyx.app/overview/core_features/connectors)) —
SMB-Anbindung also wie bei Option B über einen Mount, aber mit produktisierter
Crawling-/Index-Pipeline.
- **Stärken**: bessere Such-Ergonomie (hybride Suche, Reranking), skaliert
auf große Bestände, Konnektoren für spätere Quellen (SharePoint, Wiki,
E-Mail…), eigenes Berechtigungsmodell.
- **Schwächen für unseren Fall**:
- **Document-Level Permission Sync ist Enterprise Edition** (kostenpflichtig)
und primär für Cloud-Quellen (SharePoint, Google Drive) gebaut — für
SMB-NTFS-ACLs gibt es auch hier **keine fertige Lösung**.
- **Zweite Anwendung** mit eigener UI, eigener Nutzerverwaltung, eigenem
Betrieb (mehrere Container, Vespa-Index, Worker) — spürbar mehr
Betriebsaufwand als Option B.
- Zwei UIs für die Nutzer (Chat in Open WebUI, Suche in Onyx) oder man
ersetzt Open WebUI ganz durch Onyx' Chat — dann verliert man dessen
Flexibilität (Multi-Backend, Power-User-Features).
### 4.5 Option D — Eigenbau-Pipeline (Qdrant/pgvector + eigener Indexer)
Maximale Kontrolle (eigenes ACL-Modell, beliebige Formate/OCR, Anbindung an
Open WebUI über dessen Pipelines/Tools-API) — aber man betreibt und wartet
eine Individualsoftware. Nur gerechtfertigt, wenn **Datei-genaue
NTFS-Berechtigungen** harte Anforderung sind; dann als Projekt kalkulieren
(mehrere Wochen Entwicklung + laufende Pflege).
### 4.6 Entscheidungsmatrix
| Kriterium | B: Open WebUI + oikb | C: Onyx | D: Eigenbau |
|---|---|---|---|
| Aufwand Einführung | **niedrig** (Tage) | mittel (Wochen) | hoch |
| Betriebsaufwand | **niedrig** (1 Stack) | mittel (2 Stacks) | hoch |
| Berechtigungen | Share/Ordner-Ebene via AD-Gruppen | ähnlich; Datei-Ebene nur EE + nicht für SMB | frei gestaltbar |
| Suchqualität große Bestände | gut bis ~10⁴–10⁵ Docs | **sehr gut, skaliert** | je nach Bau |
| Normie-Tauglichkeit | **sehr gut** (ein UI, Assistenten) | gut | je nach Bau |
| Power-User | **sehr gut** (API, eigene KBs, Ollama) | mittel | gut |
| Kosten | Open Source | OSS; Permissions = EE-Lizenz | Entwicklungszeit |
### 4.7 Empfehlung: Phasenmodell
- **Phase 1 (Pilot, ~4– oikb` auf
1–
Suchqualität und die tatsächliche Parallellast — mit minimalem Invest.
- **Phase 2 (Entscheid nach Pilot):** Bleiben = Ausbau Option B (mehr Shares,
pgvector, OCR). Nur bei nachgewiesenem Bedarf (sehr große Bestände, harte
Berechtigungsanforderungen) → Onyx bzw. Eigenbau ergänzen. Die
Investition aus Phase 1 (Server, vLLM, LDAP, Mounts) bleibt vollständig
erhalten — Onyx würde denselben vLLM-Endpunkt nutzen.
Das Phasenmodell ist auch das Verkaufsargument: kein Big-Bang, Budget bleibt
unter Kontrolle, und die GPU-Ersparnis aus §1 finanziert die Pilotphase.
---
## 5. Gesamtbild (Zielarchitektur Phase 1)
` ``
┌────────────────────────────────────────────┐
Mitarbeiter ────────►│ Open WebUI (LDAP/AD-Login, Gruppen) │
(Browser) │ ├─ „Firmen-Assistent" + KB je Abteilung │
│ └─ Power-User: API-Keys, eigene KBs │
└───────┬────────────────────────┬───────────┘
Power-User ─────────────────►│ OpenAI-API │ Retrieval
(Skripte, IDE, LM Studio ▼ ▼
lokal als Client) vLLM #1 Chat 32B FP8 Vektor-DB (pgvector)
vLLM #2 Embeddings ▲
┌──────────────────────┐ │ oikb-Sync (cron)
│ RTX PRO 6000 96 GB │ SMB-Mounts (ro)
└──────────────────────┘ ▲
\\fs01\... Shares
` ``
## 6. Offene Fragen an den Kunden (vor Angebotslegung)
1. **Berechtigungen ** (kritischster Punkt): Genügt Zugriffssteuerung auf
Share-/Ordner-Ebene via AD-Gruppen — oder müssen Datei-genaue NTFS-ACLs
durchgesetzt werden? (Letzteres = Eigenbau-Anteil, deutlich teurer.)
2. **Datenbestand ** : Wie viele Shares, wie viel Volumen, welche Dateitypen?
Anteil gescannter Dokumente (OCR-Bedarf)? CAD-Daten relevant?
3. **Nutzerkreis ** : Wie viele der ~100 Mitarbeiter sollen initial angebunden
werden? Gibt es Abteilungen mit Priorität?
4. **H100-Motivation ** : Steht hinter dem H100-Wunsch eine konkrete Anforderung
(Training? Zukunftspläne?) oder Markenwahrnehmung? → bestimmt, wie viel
der Argumentation aus §1.4 nötig ist.
5. **Virtualisierung ** : Soll die GPU ggf. in eine VM-Umgebung (vGPU/MIG,
Lizenzthema) oder Bare-Metal-Betrieb (empfohlen, einfacher)?
6. **Sprache ** : Dokumente überwiegend Deutsch? (Modellwahl: Qwen3/Mistral/
Llama sind mehrsprachig solide; Embedding-Modell muss multilingual sein,
z. B. bge-m3.)
## 7. Quellen
**GPU: **
[NVIDIA RTX PRO 6000 Blackwell SE ](https://www.nvidia.com/en-us/data-center/rtx-pro-6000-blackwell-server-edition/ ) ·
[cloudrift.ai Benchmark ](https://www.cloudrift.ai/blog/benchmarking-rtx6000-vs-datacenter-gpus ) ·
[Akamai Benchmark ](https://www.akamai.com/blog/cloud/benchmarking-nvidia-rtx-pro-6000-blackwell-akamai-cloud ) ·
[databasemart vLLM-Benchmark ](https://www.databasemart.com/blog/vllm-gpu-benchmark-pro6000 ) ·
[HOSTKEY Tests ](https://huggingface.co/blog/HOSTKEY/nvidia-rtx-6000-blackwell-server-edition-tests-ben ) ·
[OpenMetal RTX PRO 6000 vs H100 ](https://openmetal.io/resources/blog/comparing-the-nvidia-rtx-pro-6000-vs-h100-for-ai-inference/ ) ·
[Spheron Cost/Mtok ](https://www.spheron.network/blog/rent-nvidia-rtx-pro-6000/ ) ·
[Lenovo Product Guide ](https://lenovopress.lenovo.com/lp2263-thinksystem-nvidia-rtx-pro-6000-blackwell-server-edition-pcie-gen5-gpu ) ·
[NVIDIA vGPU 19.0 ](https://developer.nvidia.com/blog/nvidia-vgpu-19-0-enables-graphics-and-ai-virtualization-on-nvidia-blackwell-gpus/ ) ·
[MIG auf RTX PRO 6000 (Medium) ](https://medium.com/@sangjinn/maximize-your-gpu-efficiency-configuring-4-nvidia-mig-instances-on-the-rtx-pro-6000-blackwell-1c9b3714af61 )
**vLLM vs Ollama: **
[Red Hat Benchmark ](https://developers.redhat.com/articles/2025/08/08/ollama-vs-vllm-deep-dive-performance-benchmarking ) ·
[MDPI-Studie ](https://doi.org/10.3390/app16115435 ) ·
[runaihome Konkurrenz-Zahlen ](https://runaihome.com/blog/vllm-vs-ollama-when-each-wins-2026/ ) ·
[tech-insider ](https://tech-insider.org/vllm-vs-ollama-2026/ ) ·
[SitePoint ](https://www.sitepoint.com/ollama-vs-vllm-performance-benchmark-2026/ )
**Open WebUI / RAG: **
[Knowledge-Doku ](https://docs.openwebui.com/features/workspace/knowledge/ ) ·
[Knowledge Base Sync / oikb ](https://docs.openwebui.com/features/knowledge-base-sync/ ) ·
[oikb GitHub ](https://github.com/open-webui/oikb ) ·
[LDAP-Doku ](https://docs.openwebui.com/features/authentication-access/auth/ldap/ ) ·
[Scaling-Doku ](https://docs.openwebui.com/getting-started/advanced-topics/scaling/ )
**Onyx: **
[Onyx GitHub ](https://github.com/onyx-dot-app/onyx ) ·
[Connector-Übersicht ](https://docs.onyx.app/overview/core_features/connectors )
