Alte Version Nicht mehr aktuell

Diese EXO-Cluster-Zielarchitektur bleibt nur als historische Referenz erhalten. Die aktuelle Kundenarchitektur ist Version 2: kein EXO-Produktionspfad, sondern Mac mini Control Plane mit zwei unabhängigen Mac Studio Replicas.

Siehe Version 2

LokaleKI Exo-Cluster Zielarchitektur

Zielbild: Mac mini als Control Plane, zwei Mac Studios als Exo-Inference-Cluster fuer grosse lokale Modelle und bis zu vier parallele Nutzer, nach Benchmark, Burn-in und Freigabe.

Exo Zielbetrieb nach Re-Check LM Studio expliziter Fallback Mac mini ohne Modelllast
Zielbild: Kundenaufbau
App -> Security/Login -> Mac mini Gateway -> RAG/Tools -> freigegebene Runtime-Lane -> Antwortprüfung.

Geräte-Ansicht

Endanwender-Gerät

MacBook / Client des Nutzers

  • LokaleKI.app als einzige Nutzeroberfläche.
  • Zugriff über FortiGate/ZTNA; Cisco Duo nur falls als MFA/Device-Trust-Pfad freigegeben, sonst Fortinet-native Device-Posture.
  • Login-Session über FortiAuthenticator/OIDC, keine lokalen Admin-Secrets.
  • Chat, Quellenanzeige, Status, Knowledge Map und Records-Ansicht.
  • Keine Modelle, keine Vektordatenbank, keine Exo- oder LM-Studio-Ports.
  • Verbindung nur zum Mac mini Gateway über FortiGate/ZTNA/VPN.

Mac mini

Control Plane / Gateway / Policy-Schicht

  • LokaleKI Backend und API Gateway für die App.
  • FortiAuthenticator als IdP/Identity-Quelle; OIDC fürs LokaleKI Backend, ZTNA-Protokoll nach Kundenstandard festlegen.
  • RAG-Orchestrierung ohne großen lokalen Index: der Mac mini fragt die zentrale RAG-Datenebene auf den Studios ab.
  • Runtime Router zur Exo API, Healthchecks und Failover-Entscheidungen.
  • Tool-Broker für PRTG, FortiGate, FortiAnalyzer, FileWave und Jira Assets produktiv read-only mit minimal berechtigten Service-Accounts; Tokens in Vault/Secret-Store mit Rotation.
  • Optionales Admin-/Status-WebUI, aber nicht das Nutzerfrontend.
  • Audit mit Nutzer-ID, Rollenclaims, Daten-/Tool-Scope, Quellenrefs, Policy-Entscheidung, Modell-/Pipeline-Version und Admin-Aktion; zentral auswertbar, optional via FortiAnalyzer/SIEM.
  • Prompt-/Response-Logs werden minimiert, klassifiziert, rollenbasiert geschützt und nach definierter Frist gelöscht.
  • Keine LLM-Inferenz und keine unkontrollierte Qdrant-/Embedding-Last auf dem 16-GB-Gerät.
  • Keine Prompt-, Modell- oder Betriebsdaten an externe LLM-/Telemetry-Dienste; produktiver Pfad bleibt on-prem mit On-Premise-Souveränität.

Mac Studio Cluster

2x Mac Studio als Exo-Compute-Pool plus bewusst dimensionierte RAG-Dienste

  • Exo Worker auf Mac Studio A und Mac Studio B.
  • Exo API/Gateway auf einem definierten Cluster-Knoten oder davor per Reverse Proxy.
  • MLX/Exo Runtime, Modellgewichte und experimentell zu validierende Sharding-Konfiguration.
  • Dedizierte Thunderbolt-5-Direktverbindung zwischen kompatiblen Mac Studios; RDMA/JACCL erst nach Hardware-, Kabel-, macOS- und Burn-in-Freigabe.
  • Externe PCIe/NVMe-SSDs nicht als alleinige Wahrheit: Verschlüsselung, Snapshots, SMART, Backupziel und Restore-Test dokumentieren.
  • RAG-Datenebene: Qdrant, bge-m3 Embeddings, bge-reranker-v2-m3, KG-lite und LLM Wiki mit eigenem RAM-/I/O-Budget.
  • Quellen-Import aus Confluence, Jira Assets, Fortinet Manuals, M365-Dokumenten und internen SOPs.
  • Primärer Zielkandidat Qwen3.5-35B-A3B für Multi-Agent-RAG und lange Kontexte; Qwen3.6-27B als Coding-/Agentic-Coding-Profil evaluieren.
  • Optional LM Studio als expliziter Fallback, Vergleich oder Entwicklungsruntime; sichtbar in Status, Doctor und Report.

Ablauf Einer Nutzerfrage

1. Nutzer startet LokaleKI.appDie App ist die einzige produktive Oberfläche für die vier Nutzer. Sie enthält keine Modellgewichte, keine Runtime-Tokens und keinen direkten Zugriff auf Exo, Qdrant, LM Studio oder die Mac Studios.
2. Netzwerkzugang wird geprüftFortiGate und VPN/ZTNA prüfen, ob Gerät, Standort und Verbindung erlaubt sind. Cisco Duo ist hier nur dann Teil des Designs, wenn der Kunde es bewusst für MFA, Device Trust oder optional Duo Network Gateway freigibt; alternativ läuft Device-Posture Fortinet-nativ. Das ist Security auf Netzwerk- und Geräteebene, noch keine fachliche Entscheidung darüber, welche Dokumente oder Systeme der Nutzer sehen darf.
3. Identität kommt über FortiAuthenticatorFortiAuthenticator liefert Identität, Gruppen und Rollenclaims, zum Beispiel per OIDC ans LokaleKI Backend. Diese Claims sind die Grundlage für die spätere LokaleKI-Policy, ersetzen aber noch nicht die RAG-Rechtefilter.
4. Request landet am Mac mini GatewayDer Mac mini validiert die App-Session und das OIDC-Token, startet Audit/Tracing und nimmt die Anfrage als zentrale Control Plane entgegen. Er ist damit der Eintrittspunkt in das KI-System, aber nicht der Rechner für Modellinferenz.
5. Mac mini macht Policy und Intent-RoutingDer Mac mini übersetzt Gruppenclaims in LokaleKI-Scopes und entscheidet, welche Pipeline gebraucht wird: Wissensfrage, Statusfrage, CMDB-/Asset-Frage, Tool-Abfrage oder reine Modellfrage. Er hält keinen großen RAG-Index und lädt kein großes Modell.
6. Retrieval läuft gegen die zentrale WissensdatenebeneBei Wissensfragen orchestriert der Mac mini das Retrieval gegen die zentrale Datenebene auf dem Mac-Studio-Cluster oder einem separaten Dienst/Server, falls die RAG-Last nicht auf den Studios laufen soll. Dort liegen Qdrant, bge-m3 Embeddings, bge-reranker-v2-m3, Quellen-Chunks, KG-lite und LLM Wiki. Rechtefilter laufen vor Retrieval über Principal, Tenant, Gruppen, Scopes und Chunk-Metadaten; Qdrant erhält nur erlaubte Filterbedingungen.
7. Quellen werden geprüft und geranktDie RAG-Pipeline nutzt lexikalische Suche, Vektorsuche, RRF und Reranking, um belastbare Quellen zu finden, z. B. dichte Treffer plus lexikalische Treffer, danach RRF, Reranker und finale Quellenliste. Ohne passende Quelle, bei fehlender Berechtigung oder bei scheiternder Retrieval-/Citation-Validation wird eine No-answer-Antwort ausgegeben, statt das Modell raten zu lassen.
8. LLM Wiki und KG-lite bleiben zentrale WissenssichtenAlle Nutzer profitieren von derselben geprüften Wissensbasis. LLM Wiki und KG-lite sind read-only, quellengebunden und keine zweite Wahrheit. Neue Ingestion-Läufe oder geprüfte Review-Kandidaten können sie verbessern; einzelne Chat-Antworten schreiben nicht automatisch Fakten in das Wiki.
9. Tool-Broker ergänzt BetriebsdatenWenn die Frage es braucht und die Rolle es erlaubt, ruft der Mac mini read-only Daten aus PRTG, FortiOS/FortiGate, FortiAnalyzer, FileWave oder Jira Assets ab. API-Tokens bleiben serverseitig und werden weder an die App noch an das Modell verteilt. Schreibende Aktionen bleiben im Zielbild deaktiviert; spätere Freigabe nur mit Vier-Augen-Prüfung, Change-Log und Rollback.
10. Kontrollierter Prompt wird gebautDer Mac mini baut aus Nutzerfrage, erlaubten Quellen, Wiki-/KG-Kontext und Tool-Ergebnissen einen begrenzten Prompt. Secrets, API-Tokens, private Keys, vollständige Rohdokumente, fremde Kundenscopes und nicht freigegebene Betriebsdaten werden vor Logging, Promptbau und Modellaufruf redigiert oder blockiert. Externe Telemetrie oder Cloud-LLM-Aufrufe sind im produktiven Pfad gesperrt.
11. Die freigegebene Runtime-Lane übernimmt die InferenzDer Mac mini sendet den Request an die freigegebene Runtime-Lane. Im Exo-Zielbetrieb geht er an die Exo API; Exo-Sharding über Mac Studio A und B wird erst nach reproduzierbarem 1-vs-2-Node-Benchmark, RDMA-/Topologie-Test, Ausfalltest und Burn-in freigegeben. LM Studio bleibt nur ein expliziter, sichtbarer Fallback oder Vergleichspfad.
12. Antwort wird validiertDie Antwort streamt zurück zum Mac mini. Dort prüft LokaleKI Quellenpflicht, bekannte Quellenrefs, No-answer-Regeln, Citation Validation, Tool-Ergebnisse und Audit-Metadaten. Unbekannte, fehlende oder nicht gestützte Zitate blockieren die Ausgabe oder führen zu No-answer.
13. Ergebnis und Wissenspflege werden getrenntDie App zeigt Antwort, Quellen, Status und ggf. Knowledge-Map-Bezug. Gemeinsame Artefakte wie LLM Wiki, KG-lite, Reports und RAG-Indizes bleiben zentral. Neue Chunks erhalten Hash, Quelle, Scope, Rechte-Metadaten und Review-Status. Verbesserungen aus Nutzerfragen laufen als Review- oder Ingestion-Kandidaten, nicht als ungeprüftes automatisches Lernen.

NIS2 Kontrollsicht

Grundprinzip: Use Case zuerst, Kontrolle danachNIS2 wird nicht dadurch erfüllt, dass einzelne Security-Produkte vorhanden sind. Prüffähig wird das Setup, wenn pro Use Case klar ist: welches Risiko entsteht, welche technische und organisatorische Kontrolle greift, wer verantwortlich ist und welcher Nachweis im Audit gezeigt werden kann. Keine Rechtsberatung, sondern eine Kontrollsicht für Planung und Prüfung.
Use Case 1: Nutzer fragt internes Wissen abRisiko: falsche Antwort, Halluzination oder Zugriff auf fremde Dokumente. Gebaut: Login über FortiAuthenticator, Scopes am Mac mini, Rechtefilter vor Retrieval, Qdrant nur mit erlaubten Filtern, Quellenpflicht, Citation Validation und No-answer-Regel. Nachweis: Rollenmatrix, Chunk-Metadaten, RAG-Testfälle mit erlaubten und verbotenen Quellen.
Use Case 2: Nutzer fragt Live-Status aus Betriebssystemen abRisiko: zu breite API-Rechte oder versehentliche Änderungen an produktiven Systemen. Gebaut: Tool-Broker auf dem Mac mini, read-only Service-Accounts für PRTG, FortiGate, FortiAnalyzer, FileWave und Jira Assets, Tokens im Vault/Secret-Store, jeder Aufruf mit User-ID, Scope und Request-ID im Audit. Nachweis: API-Allowlist, Service-Account-Rechte, Token-Rotation und Broker-Logs.
Use Case 3: Security- oder NetzwerkfrageRisiko: sensible Konfigurationsdaten, Logs oder Security-Details landen im Prompt oder bei falschen Nutzern. Gebaut: FortiGate/ZTNA als Netzwerkgrenze, keine direkten Ports zu Exo, Qdrant, LM Studio oder Mac Studios, Rollen-/Scope-Prüfung am Mac mini, Redaction vor Promptbau und Logging. Nachweis: Firewall-Regeln, ZTNA-Policy, Log-Redaction-Test, Beispiel-Auditlog.
Use Case 4: RAG, LLM Wiki und WissenspflegeRisiko: ungeprüfte Chat-Antworten werden zur neuen Wahrheit. Gebaut: LLM Wiki und KG-lite bleiben read-only und quellengebunden. Neue Chunks brauchen Quelle, Hash, Scope, Rechte-Metadaten und Review-Status. Verbesserungen laufen als Review- oder Ingestion-Kandidaten, nicht als automatisches Lernen aus Chats. Nachweis: Ingestion-Protokoll, Quellenfreigabe, Review-Historie und Restore-Test.
Use Case 5: Exo-Inferenz und ModellbetriebRisiko: instabile Cluster-Inferenz, falsche Runtime-Umschaltung oder ungeprüfte Modelle. Gebaut: Exo erst nach Benchmark, RDMA-/Topologie-Test, Ausfalltest und Burn-in; LM Studio nur als sichtbarer Fallback; Qwen-Modellprofile mit Version, Quantisierung, Kontextlänge und Presets. Nachweis: 1-vs-2-Node-Test, 1/2/4-Nutzer-Test, TTFT, Tokens/sec, RAM/Swap, Fehlerverhalten, Modellherkunft und Lizenzprüfung.
Technische Kontrollen im SetupMFA/ZTNA, Netzsegmentierung, kein direkter Clientzugriff auf Backend-Nebenkomponenten, Secret-Store, Transportverschlüsselung, verschlüsselte Backups, Patch- und Vulnerability-Prozess für macOS, FortiOS, Exo/MLX, Qdrant und LokaleKI, zentrale Auditlogs und Monitoring über FortiAnalyzer/SIEM oder ein definiertes Logziel.
Organisatorische KontrollenRisikobewertung je Use Case, Datenklassifizierung, Freigabeprozess für Quellen und Modelle, Rollen- und Rechtematrix, Admin-Trennung, Vier-Augen-Prinzip für produktive Policy-Änderungen, Schulung für Nutzer/Admins/Management, Incident-Runbook, Lieferanten- und Modellbewertung, regelmäßige Wirksamkeitsprüfung.
Was ein Prüfer sehen willArchitektur- und Datenflussdiagramm, Assetliste, Risikoanalyse, Management-Freigabe, FortiGate-/ZTNA-Regeln, OIDC-Claims-Mapping, MFA-Nachweise, RAG-Testfälle, No-answer-/Citation-Validation-Tests, Tool-Broker-Logs, Vault-/Token-Rotation, Backup-/Restore-Protokolle, Exo-Burn-in, Failover-Test, Patchreports, Incident-Tabletop und Maßnahmenplan für offene Mängel.
Incident Response und MeldewegFür das KI-System braucht es klare Kriterien: Datenabfluss, unberechtigter Zugriff, Tool-Missbrauch, falsche Quellenfreigabe, Ausfall der Control Plane, kompromittierte Tokens oder externer Datenabfluss. Das Runbook muss Owner, Eskalation, technische Eindämmung, Forensik, Kommunikation und Fristen abdecken. In Österreich nennt NISG 2026 §34 u. a. 24-Stunden-Frühwarnung, 72-Stunden-Meldung und Abschlussbericht.
Offene KundenentscheidungenIst der Kunde wesentliche oder wichtige Einrichtung? Welche Dienste sind kritisch? Welche Datenklassen dürfen in RAG? Welche Rollen sehen welche Quellen und Tools? Welches Logziel ist führend? Wer genehmigt Modelle, Fallback und Restrisiko? Wer besitzt die Quellenfreigabe, die Incident-Rolle und die regelmäßige Kontrollprüfung?
Regulatorischer Anker, Stand 08.05.2026EU-NIS2 fordert risikobasierte technische, operative und organisatorische Maßnahmen sowie Governance und Meldepflichten. In Österreich nennt NISG 2026 insbesondere §32 Risikomanagementmaßnahmen, §33 Nachweis der Wirksamkeit, §34 Berichtspflichten und §35 erheblicher Cybersicherheitsvorfall; laut RIS treten diese Pflichten am 01.10.2026 in Kraft. Quellen: EU-Richtlinie 2022/2555, RIS §32, RIS §33, RIS §34, RIS §35.

Offene Themen

Benchmark und Parameter-TuningQwen3.5-35B-A3B muss auf der echten Mac-Studio-Hardware mit echten Kundendaten-Use-Cases getestet werden. Offen sind Kontextlänge, Quantisierung, Sampling, Temperatur, Top-p, Max Tokens, parallele Nutzer, TTFT, Tokens/sec, RAM-Druck, Swap, Temperaturverhalten und stabile Presets pro Use Case.
RAG programmieren und einmessenOffen ist die konkrete RAG-Implementierung: Chunking-Regeln, Metadaten-Schema, Confluence-/Jira-/Fortinet-/M365-Import, bge-m3 Embeddings, bge-reranker-v2-m3, Rechtefilter, Quellenanzeige, Citation Validation und No-answer-Verhalten.
RAG-Schwellenwerte und GuardrailsZu definieren anhand echter Dokumente und Daten: minimale Retrieval-Scores, Reranker-Top-K, Quellenanzahl, Konfliktbehandlung, No-answer-Schwellen, Prompt-Injection-Filter, PII-/Secret-Filter und wann eine Rückfrage statt einer Antwort ausgelöst wird.
Docker-Betriebsmodell klärenOffen ist, welche Teile containerisiert werden sollen und welche bewusst nativ laufen. Zu klären sind Docker Compose, ARM64-Images, Service-Grenzen, Volumes für Vektordatenbanken und Logs, Secrets, interne Netze, Reverse Proxy, Healthchecks, Updates, Backups und Restore pro Container.
Multi-Modell-Modus ja oder neinOffen ist, ob der Kunde überhaupt mehrere Modelle möchte oder ob ein gut eingestelltes Qwen-Hauptmodell reicht. Zu besprechen: Qwen3.5-35B-A3B als Hauptmodell, optional Qwen3.6-27B für Coding, Modellwechsel, sichtbarer Status, Audit, Warm-Standby und ob der zusätzliche Betriebsaufwand den Nutzen rechtfertigt.
Multi-Agent-RAG konkret planenOffen ist, welche Agenten wirklich gebaut werden sollen: Router, Retrieval-Agent, KG-lite-Agent, LLM-Wiki-Agent, Tool-Agent, Verifier/Critic und Answer-Agent. Zu definieren sind Kontextbudget, Abbruchregeln, Quellenpflicht, Tool-Rechte, Parallelisierung und Audit pro Agent.
Fallback und Notbetrieb gewünscht?Offen ist, ob überhaupt ein Fallback eingebaut werden soll. Falls ja, wäre LM Studio der naheliegende lokale Fallback-/Vergleichspfad. Zu klären sind Auslöser für Fallback, sichtbare Nutzeranzeige, kein stiller Wechsel, Einzelknoten-Notbetrieb, SLOs, Recovery-Zeit und Audit.
Kundentechnik bestätigenZu bestätigen: genaue Mac-Studio-Ausstattung, RAM, macOS-Version, Thunderbolt-Generation, NVMe-Gehäuse, 10GbE/VLAN-Design, FortiGate/ZTNA-Pfad und die genaue Cisco-Duo-Rolle. Cisco Duo kann MFA, Device Trust oder optional Duo Network Gateway sein; es sollte nicht pauschal mit FortiGate/ZTNA gleichgesetzt werden.