# 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–10 k€** | ~31 k€ (lt. Referenz-Angebot) | ### 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× höherer Durchsatz als 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× H100 SXM ≈ 3× Durchsatz von 8× RTX PRO 6000). - **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× schneller**." 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–10 k€** | ✅ Empfehlung — s. §1.2, aber Risiken in §1.6 beachten | | H100 NVL | 94 GB | ~26–30 k€ | Ausgereifteste Software-Basis (Hopper/SM90), sonst in allen Benchmarks unterlegen; 3× Preis. **Der risikoärmste, teuerste Weg.** | | H200 NVL | 141 GB | ~30–42 k€ ([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–20 %. Nur sinnvoll bei Modellen > 96 GB — nicht unser Fall. | | 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 PRO 5000 Blackwell | 2×48 GB | ~9 k€ | Gleicher Gesamt-VRAM, aber Tensor-Parallel über PCIe (Overhead), doppelte Komplexität, gleiche SM120-Risiken. Kein Vorteil. | | 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–18 k€ ([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–20 gleichzeitige Anfragen | ❌ llama.cpp-Engine, Anfragen stauen sich | ✅ Continuous Batching | | 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–29× mehr Durchsatz** und 8–19× niedrigere P95-Latenz ([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–30 % Timeouts unter Last; vLLM 100 % Erfolgsquote ([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–2 min) | | 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–60 % registrieren sich, davon ~10–20 % gleichzeitig aktiv in Spitzen → **5–15 parallele Anfragen**. Das bedient eine RTX PRO 6000 mit einem 32B-FP8-Modell unter vLLM komfortabel (vgl. Benchmarks oben: brauchbare Latenz noch bei 50–100 parallelen Requests 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–6 Wochen):** vLLM + Open WebUI + LDAP + `oikb` auf 1–2 ausgewählte Shares (read-only Service-Account). Misst reale Nutzung, 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)