M medialine.app Architektur · 7-Layer-Stack Zurueck
Plattform-Architektur

Sieben Schichten fuer Datenhoheit

Vom Bare-Metal-GPU-Node bis zum Multi-Tenant-Chat. Jede Schicht ist isoliert, observable und fuer einen einzigen Zweck verantwortlich.

L7User-Interfaceschat.medialine.app · medialine.app/* · /enterprise L6Edge: Cloudflare-Tunnel68 Routes · Zero-Trust · SSL/TLS terminiert ausserhalb L5Application: 26 KI-Agenten OrchestratorFastAPI · Multi-Tenant · X-Tenant-Id Header · Postgres-Schema L4LLM-Gateway: LiteLLM37 Modelle · Lokal NIM/vLLM + Cloud (Opus 4.7, GPT-5) · Routing nach Use-Case L3Daten-Layer: Postgres + Qdrant + LangfuseTenants/Agent-Runs/Memory · bge-m3 Vectors · Audit-Tracing L2Runtime: Docker auf rmki-edge Network60+ Container · autoheal · Watchtower · gitops L1Hardware: NVIDIA DGX SparkGB10 GPU · 192.168.50.250 LAN · 100.69.246.74 Tailscale-Mesh
7
User-Interface

Chat-UIs, Marketing-Pages, Enterprise-SPAs

Die Plattform exponiert mehrere Eingangstueren: chat.medialine.app als Multi-Tenant-Chat mit Open WebUI, medialine.app/* als Editorial-Site mit 4 Pages, und /enterprise als Vite-SPA der 26-Agenten-Prozesslandschaft.

Open WebUI Vite-SPA nginx-Static 5 Custom-Models
4Pages live
6
Edge / Zero-Trust

Cloudflare-Tunnel mit 68 Routes

Kein offener Port nach aussen. Alle eingehenden Verbindungen kommen ueber den Cloudflare-Tunnel bf6c481e-ef21-..., der auf der Spark-Maschine als cloudflared-Container laeuft. SSL/TLS wird auf der CF-Edge terminiert, der Tunnel ist mTLS-authentisiert.

cloudflared 68 Routes Zero-Trust-Edge mTLS
68CF-Routes
5
Application

26-Agenten-Orchestrator als FastAPI

Der zentrale Application-Layer ist die FastAPI in agents-orchestrator. Sie nimmt POSTs auf /api/agents/{name} mit X-Tenant-Id Header entgegen, klassifiziert die Anfrage und routet sie an LiteLLM (L4) plus optional RAG (L3) plus Web-Search (SearxNG). Jeder Run wird in Postgres mit Status, Tokens und Cost protokolliert.

FastAPI 26 Agenten 5 Pilot-Tenants X-Tenant-Id
26Agenten
4
LLM-Gateway

LiteLLM mit 37 Modellen

LiteLLM ist die Modell-Routing-Schicht. Sie sieht 37 verschiedene LLMs als einheitliche OpenAI-kompatible Schnittstelle: lokal Qwen3.6-35B-A3B via vLLM und Gemma-4-31B-NIM, plus Cloud Claude Opus 4.7, GPT-5, OpenRouter-Modelle. Die Auswahl erfolgt pro Use-Case, mit automatischem Fallback bei Provider-Ausfall.

LiteLLM vLLM (Qwen) NIM (Gemma) Anthropic Direct Fallback-Chain
37LLM-Modelle
3
Daten-Layer

Postgres + Qdrant + Langfuse

Drei spezialisierte Datenbanken: Postgres fuer Tenants, Agent-Runs und Memory; Qdrant als Vector-Store mit bge-m3-Embeddings (1024-dim, Cosine) fuer RAG; Langfuse fuer Audit-Tracing jedes LLM-Calls (Input, Output, Tokens, Cost). Backup via Restic auf separaten Volume.

PostgreSQL 16 Qdrant + bge-m3 Langfuse Restic-Backup
3Stores
2
Runtime

Docker mit Self-Healing-Stack

60+ Container auf einem einzelnen Docker-Network rmki-edge. Self-Healing via autoheal-Labels (Container-Restart bei Health-Check-Failure), watchtower fuer Image-Updates, und gitops-Loop der Compose-Files aus Git zieht. Mount-Race-Schutz via Symlinks fuer kritische Bind-Mounts.

Docker Compose autoheal watchtower gitops rmki-edge
60+Container
1
Hardware

NVIDIA DGX Spark als Compute-Fundament

Ein einzelner DGX-Spark-Node mit NVIDIA GB10 GPU. Standort On-Premise, IP-Adressierung 192.168.50.250 intern und 100.69.246.74 via Tailscale-Mesh fuer Remote-Admin. SSH ausschliesslich via Ed25519-Key, kein Password-Auth. Disk: 4 TB NVMe, 90% verfuegbar.

DGX Spark GB10 GPU Tailscale-Mesh SSH Ed25519 Restic-Backup
1GPU-Node

Anfrage-Lebenszyklus · From Request to Response

Wie eine Nutzer-Anfrage durch alle 7 Schichten flutscht — und was an jeder Station passiert.

1. Request User-Frage via Chat-UI oder API mit X-Tenant-Id Header POST /api/agents/research
2. Edge Cloudflare-Tunnel routet zur Origin auf rmki-edge → tunnel
3. Orchestrator FastAPI klassifiziert + waehlt Agenten + RAG-Lookup research(tenant=rmgroup)
4. LLM LiteLLM routet zu Modell, Langfuse traced den Call gemma-4-31b-nim
5. Response Antwort + run_id zurueck, Audit in Postgres {"status":"ok"}

Self-Healing-Stack

Drei autonome Mechanismen halten die Plattform am Laufen ohne manuellen Eingriff. Container die fallen werden automatisch hochgezogen, Modelle automatisch aktualisiert, Backup-Verifikation laeuft taeglich.

# 1. autoheal: Container mit Label autoheal=true werden bei Health-Failure restartet docker run -d --name autoheal --restart=always \ -v /var/run/docker.sock:/var/run/docker.sock \ willfarrell/autoheal:latest # 2. watchtower: Container-Images werden bei neuem Tag aktualisiert docker run -d --name watchtower --restart=always \ -v /var/run/docker.sock:/var/run/docker.sock \ containrrr/watchtower --schedule "0 0 4 * * *" # 3. w33-auto-improver: laeuft alle 30 min, prueft hung-Runs + repariert sie docker ps --filter name=w33-auto-improver --format '{{.Status}}' # Up 18 hours # 4. Restic-Backup mit taeglicher Verify auf separate Disk restic -r /backup/restic-repo backup /opt/medialine-app /opt/rm-ki-appliance restic check --read-data-subset=10%

Compliance & Audit-Trail

Jeder LLM-Call wird in Langfuse mit vollem Input, Output, Token-Count und Cost protokolliert. Presidio-PII-Filter laeuft vor jedem Call. Bei High-Risk-Tenants (GHG, VWFS) wird die Disclosure-Banner-Logik in NemoClaw-v3 angewandt.

# Audit-Trail ueber Langfuse abfragen curl #/api/public/traces?tenant=goodhealthcare \ -H "Authorization: Basic ..." # Presidio-Filter testet PII-Erkennung lokal curl -X POST http://presidio:5001/analyze \ -d '{"text":"Sehr geehrte Frau Mueller","language":"de"}' # [{"entity_type":"PERSON","start":15,"end":29,"score":0.85}] # EU-AI-Act-Banner-Check im NemoClaw-v3 SYSTEM_PROMPT docker exec nemoclaw-v3 grep -c 'EU-AI-Act' /app/bot.py # 1 (= Banner aktiv)