CubelaPetar/infra-phytron
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
43054f32b830fe6b026b1d70eb0349f38db18ed5
infra-phytron/server/phy-z-srv-gpu01/notes/20260710-projektplan.md
T
CubelaPetarandClaude Fable 5 43054f32b8 Add base plays for all hosts, nvidia_gpu role, GPU pre-work items 
- 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>
2026-07-14 10:30:43 +02:00

9.4 KiB
Raw Blame History

Projektplan — Setup phy-z-srv-gpu01 (LLM-Server mit SMB-Wissensbasis)

Date: 2026-07-10 Status: Plan — Server-Lieferung in einigen Monaten erwartet Basiert auf: 20260706-hardware-assessment.md, 20260706-software-assessment.md, 20260707-deep-dive.md

0. Rahmenbedingungen (fixiert)

Punkt Entscheidung
Hardware HPE DL380 Gen12, 2× Xeon 6714P, 128 GB RAM, RTX PRO 6000 96 GB, 2× 960 GB NVMe — s. HW.md
Betrieb Bare Metal, keine Virtualisierung des LLM-Stacks
Nutzer ~25, gemischt (technisch versiert + Nicht-Techniker)
Auth AD/LDAP (Details Service-Account/Basis-DN als Pre-Work klären)
Berechtigungen Einfach: alle Nutzer sehen den gesamten indizierten Bestand (Kunde bestätigt; Shares ohne HR-/Personal-Inhalte halten)
Sprache Dokumente & Nutzer überwiegend Deutsch → Modell- und Embedding-Wahl daran ausrichten
Inference vLLM mit fester GPU-Auslastung (kein Ollama als Basis)
Wissensbasis SMB-Shares (einige TB, PDF/Office), Sync ist die Kernanforderung
Später Jira-Anbindung u. a. Workloads; dafür ggf. MIG
Vorgehen Setup vollständig über Ansible (dieses Repo), PoC vorab: nein — reine Planung

1. Produktentscheidung: Open WebUI statt Onyx

Empfehlung: Open WebUI (bestätigt und verschärft die Empfehlung aus dem Deep Dive §4.7). Ausschlaggebend, Stand 2026-07-10 verifiziert:

  1. Onyx' File-Connector ist reiner manueller Upload — kein Verzeichnis-Watching, kein periodischer Re-Sync eines gemounteten Shares (Doku). Die Kernanforderung „Shares synchron halten" hieße bei Onyx: Eigenbau gegen deren API. Open WebUI hat dafür das offizielle Sync-Tool oikb (inkrementell, Löschungen, Cron-fähig — Deep Dive §4.3).
  2. Onyx: SSO (OIDC/SAML), User Groups, RBAC, Permission-Sync = Enterprise Edition (kostenpflichtig) (Doku). Open WebUI: LDAP/AD-Anbindung und Gruppen sind frei.
  3. Onyx bringt einen zweiten schweren Stack mit (Vespa-Index, Postgres, Worker) — auf 128 GB RAM neben vLLM spürbar; widerspricht „it just works".
  4. Bedienung: ein UI im ChatGPT-Stil, vorkonfigurierte Assistenten mit fester Knowledge Base → passt für den gemischten Nutzerkreis.

Wann die Entscheidung zu revidieren ist (Trigger, nach der Share-Analyse §2.1):

  • Der relevante Bestand liegt deutlich über ~10⁵ Dokumenten und lässt sich nicht sinnvoll filtern → Suchqualität/Skalierung von Open WebUI prüfen, Onyx (mit Eigenbau-Sync) oder Eigenbau-Pipeline (Deep Dive §4.5) neu bewerten.
  • Datei-genaue NTFS-ACLs werden doch Anforderung → Neubewertung (Deep Dive §4.4/4.5).

Jira später: für Indizierung von Jira-Inhalten hat Onyx zwar native Konnektoren, Open WebUI deckt das aber über Tools/MCP (Atlassian-MCP) bzw. API-Workloads direkt gegen vLLM ab — kein Entscheidungskriterium für heute.

2. Phase 0 — Pre-Work (jetzt, ohne Server)

2.1 Share-Analyse (wichtigster Punkt — ja, unbedingt vorab)

Read-only-Skript auf einer beliebigen Maschine mit Share-Zugriff (kein GPU-Server nötig). Zu erheben:

  • Volumen & Dateianzahl pro Share und Dateityp (pdf/docx/xlsx/…)
  • Anteil gescannter PDFs (Stichprobe: PDFs ohne Textlayer) → OCR-Bedarf
  • Duplikate/Altversionen („Kopie von …", Versionsordner) → Filterregeln
  • Änderungsrate (mtime-Verteilung) → Sync-Frequenz
  • Anteil nicht extrahierbarer Formate (CAD, Bilder, Archive) → Erwartungsmanagement
  • Sonderzeichen/Pfadlängen, Encoding (Umlaute!)

Ergebnis bestimmt: Korpus-Umfang (→ §1-Trigger), OCR-Pipeline ja/nein, Index-Größe (→ Storage-Check §2.3), Erst-Indexierungsdauer.

2.2 Mit dem Kunden zu klären (Checkliste)

  • AD/LDAP: Bind-Service-Account, Basis-DN, Gruppe „LLM-Nutzer"
  • SMB-Service-Account read-only für die Mounts (kein Nutzer-Account)
  • Welche Shares/Unterordner genau in den Index? Ausschlussliste (HR o. ä.)
  • DNS-Name (z. B. ki.phytron.local) + TLS (internes CA-Zertifikat?)
  • Internetzugang des Servers (Modell-/Container-Downloads bei Installation; danach einschränkbar)
  • Protokollierung/Datenschutz: werden Chats gespeichert? Betriebsrat/DSGVO früh einbinden
  • Update-/Wartungsfenster und wer den Betrieb nach Übergabe verantwortet
  • „Andere Workloads" konkretisieren (Jira: Inhalte durchsuchen vs. Aktionen ausführen?) → bestimmt MIG-Layout später

2.3 Storage-Check (⚠️ vor Bestellung ggf. nachsteuern)

2× 960 GB NVMe, vermutlich RAID1 → ~960 GB nutzbar für OS + Docker + Modelle (~100 GB) + Vektor-DB + Extraktions-Cache. Strategie: kein lokaler Spiegel der Shares — nur Index (extrahierter Text + Embeddings, erfahrungsgemäß wenige % des Rohvolumens). Nach der Share-Analyse gegenrechnen; wenn eng: zwei weitere NVMe nachordern (Slots frei) — das ist vor Lieferung am billigsten zu ändern.

2.4 Ansible vorbereiten (im Repo, testbar ohne GPU)

  • run.yml: Play für phy_z_srv_gpu01 ergänzen
  • Rollen-Skelett unter ansible/roles/ (Details erst bei Umsetzung):
    • nvidia_gpu — Treiber (≥ 580), Container Toolkit, optional MIG, DCGM
    • cifs_mounts — ro-Mounts, Credentials aus group_vars/secrets.yml
    • llm_stack — Docker Compose: vLLM (feste --gpu-memory-utilization), Embedding-Server, Open WebUI + pgvector, Reverse Proxy (TLS), oikb-Timer
    • Bestehendes nachnutzen: geerlingguy.security (Basis-Härtung), geerlingguy.docker
  • group_vars/phy_z_srv_gpu01.yml: nur Overrides (Modellname, VRAM-Quote, Share-Liste, LDAP-Parameter)
  • Alles außer GPU-Rolle ist vorab in einer Wegwerf-VM testbar (just run-Pfad)

2.5 Modell-Shortlist (finale Wahl erst bei Installation!)

Kandidaten heute: Qwen3-32B FP8 (Favorit: Deutsch, Durchsatz), gpt-oss-120b (mehr Qualität, weniger Parallelität), Embeddings bge-m3 / multilingual-e5. Nicht jetzt festlegen — Modell-Landschaft und vLLM-Support in einigen Monaten neu sichten (§ Wiedereinstieg). Kleines deutsches Eval-Set (20–30 Fragen mit erwarteten Antworten aus dem Bestand) schon jetzt mit dem Kunden sammeln — das ist später das Abnahmekriterium.

3. Phasen ab Server-Lieferung

Phase Inhalt Ergebnis/Abnahme
1. Basis (Woche 1) Rack/Strom (600-W-GPU!), iLO, Firmware, RAID, Ubuntu 24.04 LTS, Eintrag in Ansible-Basis-Setup (Security, Pakete, Nutzer) just run phy_z_srv_gpu01 läuft grün
2. GPU-Stack (Woche 1–2) Rolle nvidia_gpu: Treiber, Container Toolkit, DCGM; Burn-in unter Dauerlast (SM120-Risiken, Deep Dive §1.6); MIG erst mal aus nvidia-smi ok, 48 h-Lasttest ohne Reset
3. Inference (Woche 2) vLLM-Container (NVIDIA-Build) mit gewähltem Modell, feste VRAM-Quote, Embedding-Server daneben; Benchmark mit Eval-Set deutsche Antworten ok, Ziel-Parallelität erreicht
4. UI + Auth (Woche 2–3) Open WebUI + pgvector, LDAP-Login, Reverse Proxy + TLS, vorkonfigurierter „Phytron-Assistent" Login mit AD-Konto, Chat läuft
5. Wissensbasis (Woche 3–5) CIFS-Mounts (ro), Extraktion inkl. OCR-Engine (Tika/Docling), oikb-Sync erst auf einen Teilbestand, Qualität prüfen, dann Vollindex (Dauer aus §2.1 abschätzen) Fragen aus dem Eval-Set werden mit korrekten Quellen beantwortet
6. Pilot → Rollout (Woche 5–7) 3–5 Pilotnutzer (gemischt), Feedback, dann alle 25; Onboarding-Einseiter (was kann es, was nicht — CAD/Scans!) Abnahme durch Kunden
7. Betrieb Monitoring (GPU/DCGM, Dienste), Backup (Konfig + DBs — Modelle nicht), Update-Runbook manuals/, Doku im README Runbooks vorhanden
später Jira & weitere Workloads; erst dann MIG-Layout festlegen (bis 4 Instanzen) statt jetzt raten —

4. Risiken

Risiko Umgang
Storage zu klein für Index (§2.3) Share-Analyse → ggf. NVMe nachordern vor Lieferung
Viele gescannte PDFs → OCR-Aufwand & -Qualität Analyse-Stichprobe; OCR-Phase einplanen; Erwartungen dämpfen
SM120/Treiber-Kinderkrankheiten (Deep Dive §1.6) Treiber ≥ 580, NVIDIA-vLLM-Container, Burn-in in Phase 2, HPE-Support
Software-Stand veraltet bis Lieferung Versionen erst bei Installation pinnen; Wiedereinstiegs-Checkliste
Erst-Indexierung dauert Tage Teilbestand zuerst; Sync nachts; Dauer vorab abschätzen
RAM-Konkurrenz Extraktion/OCR vs. vLLM vLLM hat feste VRAM-Quote; Indexer-Jobs drosseln (nice/cgroups); 128 GB reichen für OWUI-Stack
Datenschutz/Betriebsrat bei Chat-Logs Früh klären (§2.2), Logging-Policy dokumentieren
Kein HA — ein Server Erwartung managen: Wartungsfenster = Dienst weg; Backup-Restore-Runbook

5. Wiedereinstiegs-Checkliste (wenn der Server da ist)

  1. Dieses Dokument + Deep Dive lesen; offene Punkte aus §2.2 abhaken
  2. Ergebnis der Share-Analyse vorliegen? (sonst zuerst!)
  3. Neu sichten & dann erst pinnen: vLLM-Version (RTX-PRO-6000-Support), Open WebUI + oikb Release Notes, NVIDIA-Treiber, Modell-Shortlist §2.5
  4. Storage-Entscheidung §2.3 umgesetzt?
  5. Dann Phasenplan §3 von oben abarbeiten; jede Phase = Ansible-Commit + ggf. Runbook unter manuals/

6. Bewusst offen gelassen (kein Jetzt-Entscheid nötig)

  • Exaktes Modell & Quantisierung, vLLM-Flags, MIG-Layout, OCR-Engine-Wahl, Monitoring-Stack-Details, Reverse-Proxy-Produkt — alles bei Umsetzung mit aktuellem Stand entscheiden; Rahmen steht oben.
Reference in New Issue View Git Blame Copy Permalink