infra-phytron/server/phy-z-srv-gpu01/notes/20260707-deep-dive.md

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)	✅ bis 7 Instanzen
vGPU-Support	✅ (vGPU 19.0, NVIDIA Blog)	✅
NVLink	❌ (nur PCIe Gen5)	✅ (Paarweise)
Leistungsaufnahme	600 W (passiv, Server-Kühlung)	~400 W
Formfaktor	PCIe FHFL Dual-Slot, OEM-qualifiziert (u. a. Lenovo, 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).
2. Unter Parallellast (unser Szenario!): stärkste Skalierung aller getesteten Karten; auf Qwen-32B vor A100 und H100 (databasemart vLLM-Benchmark).
3. Bei 100 gleichzeitigen Requests: bis zu 1,63× höherer Durchsatz als die H100 (Akamai-Benchmark).
4. Kostenanalyse pro Million Token: Spheron, unabhängige Tests: HOSTKEY, Vergleich: OpenMetal.

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, JarvisLabs)	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)	Auf dem Papier attraktiv (192 GB!), ROCm/vLLM inzwischen First-Class (AMD). 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, NVFP4-Kernel). 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) — 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 (funktionaler Support, CUDA 13.0) und stellt einen eigenen vLLM-Container für RTX bereit.
2. Systemhäuser liefern inzwischen vLLM-vorvalidierte Server mit genau dieser Karte aus (VRLA Tech).
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, tech-insider).
• Peer-reviewte Studie: Ollama erreicht Engpass bei ~10 gleichzeitigen Nutzern, 13–30 % Timeouts unter Last; vLLM 100 % Erfolgsquote (MDPI Applied Sciences).
• Bei einem einzelnen Nutzer ist Ollama minimal schneller beim ersten Token (~45 vs. ~82 ms TTFT) — irrelevant für einen Firmenserver (Red Hat Benchmark, SitePoint).

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, GitHub open-webui/oikb):

• oikb (CLI, PyPI) 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). 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).
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 ist ein spezialisiertes Enterprise-Search-Produkt mit 50+ Konnektoren, darunter ein File Connector für lokale/Netzlaufwerke (Connector-Doku) — 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 · cloudrift.ai Benchmark · Akamai Benchmark · databasemart vLLM-Benchmark · HOSTKEY Tests · OpenMetal RTX PRO 6000 vs H100 · Spheron Cost/Mtok · Lenovo Product Guide · NVIDIA vGPU 19.0 · MIG auf RTX PRO 6000 (Medium)

vLLM vs Ollama: Red Hat Benchmark · MDPI-Studie · runaihome Konkurrenz-Zahlen · tech-insider · SitePoint

Open WebUI / RAG: Knowledge-Doku · Knowledge Base Sync / oikb · oikb GitHub · LDAP-Doku · Scaling-Doku

Onyx: Onyx GitHub · Connector-Übersicht