Ein Sprachmodell auf dem eigenen Rechner zu starten, ist heute vergleichsweise einfach.
Modell herunterladen.
Inference-Software installieren.
Prompt eingeben.
Antwort erhalten.
Damit besitzt du lokale KI.
Einen lokalen KI-Server hast du damit aber noch nicht unbedingt.
Ein Server soll dauerhaft eine Fähigkeit bereitstellen, die von anderen Anwendungen genutzt werden kann.
Statt:
Mensch
↓
lokale Chatoberfläche
↓
Modell
entsteht beispielsweise:
WordPress ──────┐
│
n8n ────────────┼→ KI-Server
│
interne App ────┤
│
RAG-System ─────┘
Der Rechner wird damit vom persönlichen KI-Arbeitsplatz zu einem zentralen Dienst.
Genau dieser Schritt verändert die Anforderungen erheblich.
Ein KI-Server ist mehr als eine GPU mit Modell
Ein produktiver KI-Server besteht aus mehreren Schichten.
Vereinfacht:
Anwendung
↓
API
↓
KI-Dienst
↓
Inference Engine
↓
Modell
↓
GPU
Schon diese Darstellung zeigt eine wichtige Trennung.
Die Anwendung muss nicht wissen:
welches Modellformat verwendet wird,
wie viel VRAM vorhanden ist,
auf welcher GPU gerechnet wird
oder:
wie die Inference Engine intern arbeitet.
Sie benötigt lediglich eine definierte Schnittstelle.
Der wichtigste Architekturgedanke lautet: Komponenten trennen
Ein häufiger Einstieg sieht ungefähr so aus:
n8n
+
LLM
+
Vektordatenbank
+
Weboberfläche
+
WordPress
+
Monitoring
+
eigener Code
alles irgendwie auf demselben Rechner installiert.
Das kann funktionieren.
Mit jeder zusätzlichen Komponente wird das System jedoch schwerer zu warten.
Besser ist eine logische Trennung.
Orchestrierung
→ n8n
Textgenerierung
→ LLM-Service
Embeddings
→ Embedding-Service
Wissenssuche
→ Vektordatenbank
Geschäftsdaten
→ PostgreSQL
Zugriff
→ Reverse Proxy / internes Netzwerk
Ob diese Komponenten anschließend auf einem oder auf fünf physischen Servern laufen, ist zunächst zweitrangig.
Die logische Trennung ist wichtiger als die Zahl der Maschinen.
Ein kleiner KI-Server darf trotzdem sehr einfach sein
Für einen einzelnen Nutzer reicht möglicherweise:
Linux
↓
Docker
↓
Inference Server
↓
lokales Modell
Dazu eine API.
Fertig.
Man muss nicht sofort:
Cluster,
Load Balancer,
Message Broker,
Kubernetes
und:
zehn Datenbanken
installieren.
Eine gute Infrastruktur wächst mit den Anforderungen.
Die erste Frage lautet deshalb nicht: Welche Software brauche ich?
Sondern:
Was soll der Server leisten?
Zum Beispiel:
lokaler Chat
ist eine andere Aufgabe als:
100.000 Texte nachts klassifizieren
und wieder eine andere als:
20 Mitarbeiter gleichzeitig bedienen
oder:
RAG über interne Dokumente
oder:
mehrere KI-Agenten mit Tools versorgen
Diese Anforderungen bestimmen die Architektur.
Ein Einzelplatzsystem
Der einfachste Fall:
1 Nutzer
↓
1 Modell
↓
1 GPU
Der Rechner steht beispielsweise im Arbeitszimmer.
Eine Chatoberfläche greift direkt auf die lokale Inference Engine zu.
Das reicht hervorragend zum:
Experimentieren,
Prompten,
Testen von Modellen,
lokalen Schreiben.
Ein zentraler KI-Server
Etwas interessanter:
Notebook ───┐
│
Desktop ────┼→ KI-Server
│
Smartphone ─┘
Nun läuft das Modell nur noch auf einem leistungsfähigen Rechner.
Andere Geräte brauchen keine eigene starke GPU.
Sie senden lediglich Anfragen über das Netzwerk.
Ein interner KI-Dienst
Der nächste Schritt:
n8n ───────────┐
│
WordPress ─────┼→ AI API
│
Support-App ───┤
│
RAG ───────────┘
Nun ist der KI-Server Teil einer Infrastruktur.
Das ist häufig der interessanteste Aufbau für Automatisierung.
Die API ist die wichtigste Grenze
Angenommen, n8n soll einen Text klassifizieren.
n8n sollte nicht wissen:
GPU 1
Modellformat
Quantisierung
CUDA
Modellpfad
Es sollte lediglich sagen:
POST /classify
und beispielsweise senden:
{
"text": "Meine Rechnung wurde doppelt abgebucht."
}
Die Antwort:
{
"category": "billing",
"reason": "duplicate_payment"
}
Damit wird die KI zu einem normalen internen Dienst.
Das Modell darf austauschbar sein
Heute:
Modell A
Morgen:
Modell B
Wenn beide hinter derselben internen API liegen:
n8n
→ unverändert
Das ist eine ausgesprochen wertvolle Abstraktion.
Ohne diese Trennung verteilt sich Modellwissen überall
Workflow A verwendet:
Modell X.
Workflow B:
Modell X mit anderer URL.
Workflow C:
Modell Y.
Workflow D:
direkten GPU-Service.
Nach einem Jahr wird ein Modellwechsel mühsam.
Besser:
Anwendungen
↓
AI Gateway
↓
Modelle
Was ist ein AI Gateway?
Ein AI Gateway ist eine Zwischenschicht zwischen Anwendungen und Modellen.
Es kann beispielsweise entscheiden:
Aufgabe
↓
welches Modell?
oder:
welcher Server ist frei?
oder:
darf diese Anfrage die Cloud verwenden?
Konzeptionell:
n8n
↓
AI Gateway
├── lokales kleines Modell
├── lokales großes Modell
└── optional Cloudmodell
Das Gateway muss kein großes eigenes Softwareprojekt sein.
Schon eine kleine interne API kann diese Rolle erfüllen.
Das Gateway kann ein stabiles Datenformat definieren
Beispiel:
{
"task": "classify",
"input": "Meine Rechnung wurde doppelt bezahlt."
}
Antwort:
{
"result": {
"category": "billing"
},
"model": "local-classifier-v2"
}
Die Anwendung muss nicht wissen, wie das Modell intern angesprochen wird.
Das erleichtert auch Modellvergleiche
Zum Beispiel:
10 % der Anfragen
→ Modell B
aber:
90 %
→ Modell A
Dann kann gemessen werden:
Qualität,
Latenz,
Fehlerrate.
Das Gateway wird damit auch zum Punkt für A/B-Tests.
Welche Software braucht ein lokaler KI-Server?
Eine mögliche Grundarchitektur lautet:
Linux
↓
Container Runtime
↓
Inference Server
↓
Modelle
Dazu je nach Anwendung:
Reverse Proxy
PostgreSQL
n8n
Vector DB
Monitoring
AI Gateway
Aber nicht jede Komponente ist zwingend.
Linux eignet sich hervorragend als Serverbasis
Ein KI-Server braucht normalerweise keine grafische Desktopoberfläche.
Ein schlankes Serversystem bietet:
geringeren Ressourcenverbrauch,
weniger unnötige Dienste,
einfache Remoteverwaltung.
Damit bleibt mehr:
RAM,
CPU,
VRAM
für die eigentliche Arbeit.
Ein Desktopbetriebssystem kann trotzdem funktionieren
Zum Experimentieren ist:
Windows
oder:
Desktop-Linux
völlig ausreichend.
Der Wechsel auf einen dedizierten Server wird erst interessanter, wenn:
der Rechner dauerhaft laufen soll,
mehrere Anwendungen zugreifen,
Automatisierungen davon abhängen.
Ein Server sollte möglichst reproduzierbar aufgebaut sein
Schlecht:
Vor sechs Monaten
irgendwelche Pakete installiert
drei Treiberversionen ausprobiert
Python-Bibliotheken manuell verändert
niemand weiß mehr,
warum es funktioniert
Besser:
Betriebssystem
↓
definierte Treiber
↓
Container
↓
versionierte Konfiguration
Das erleichtert Wiederherstellung und Updates.
Docker passt deshalb gut zu KI-Infrastruktur
Mit Docker kann jeder Dienst relativ sauber gekapselt werden.
Zum Beispiel:
Docker Host
│
├── ai-gateway
├── llm-server
├── n8n
├── postgres
├── vector-db
└── monitoring
Jeder Dienst besitzt:
eine definierte Version,
eigene Umgebungsvariablen,
eigene persistente Daten.
Docker trennt Software, nicht Hardware
Alle Container laufen weiterhin auf demselben physischen Rechner.
Container A ─┐
Container B ─┼→ gleiche CPU
Container C ─┤
Container D ─┘
Dasselbe gilt für:
RAM,
Festplatten,
Netzwerk.
Die GPU kann bestimmten Containern gezielt zur Verfügung gestellt werden.
Nicht jeder Container braucht GPU-Zugriff
Zum Beispiel:
PostgreSQL
→ keine GPU nötig
n8n
→ normalerweise keine GPU nötig
Reverse Proxy
→ keine GPU nötig
LLM Server
→ GPU
Damit bleibt die Hardwarezuordnung klar.
Der Modellserver ist die zentrale KI-Komponente
Er lädt:
Modelldatei
↓
VRAM
und stellt eine Schnittstelle bereit.
Zum Beispiel konzeptionell:
POST /chat
POST /generate
Anwendungen senden Anfragen.
Der Server erzeugt Antworten.
Eine Inference Engine übernimmt die eigentliche Arbeit
Wie unter lokale KI erklärt:
Modell
↓
Inference Engine
↓
CPU / GPU
Die Engine übernimmt unter anderem:
Tokenisierung,
Modellberechnung,
Sampling,
KV-Cache,
Batching.
Unterschiedliche Engines eignen sich für unterschiedliche Ziele
Einfacher Einzelplatz:
komfortable lokale Runtime
Server mit vielen Nutzern:
hoher Durchsatz
+
Batching
CPU/GPU-Mischbetrieb:
flexibles Offloading
Mehrere GPUs:
Modellparallelität
Die konkrete Software sollte deshalb erst nach dem Einsatzzweck gewählt werden.
Ollama ist ein mögliches Beispiel für einen einfachen Einstieg
Das grundlegende Modell lautet:
Anwendung
↓
Ollama API
↓
lokales Modell
Damit kann beispielsweise n8n eine lokale KI ähnlich ansprechen wie einen externen Modellanbieter.
Für kleine und mittlere lokale Installationen kann dieser einfache Ansatz sehr praktisch sein.
llama.cpp verfolgt einen anderen Schwerpunkt
llama.cpp ist besonders interessant für:
GGUF-Modelle,
CPU-Inferenz,
GPU-Offloading,
verschiedene Hardwareplattformen.
Auch daraus lässt sich ein lokaler HTTP-Server aufbauen.
Damit kann dieselbe Grundarchitektur entstehen:
n8n
↓
HTTP
↓
llama.cpp Server
↓
GGUF
Für hohe Parallelität existieren andere Serving-Ansätze
Wenn viele Nutzer gleichzeitig bedient werden sollen, werden Themen wichtig wie:
Continuous Batching,
KV-Cache-Management,
hohe GPU-Auslastung.
Dann kann eine stärker auf Serving optimierte Engine sinnvoller sein als eine einfache Desktoplösung.
Der zentrale Architekturgedanke bleibt jedoch identisch:
Anwendung
↓
API
↓
Inference Server
↓
Modell
Ein AI Gateway kann verschiedene Engines vereinheitlichen
Beispiel:
AI Gateway
├── llama.cpp
├── anderer LLM-Server
├── Embeddingserver
└── Cloud-Fallback
Die Anwendungen verwenden weiterhin nur:
AI Gateway
Damit kann die Infrastruktur im Hintergrund verändert werden.
Welche Modelle sollten dauerhaft geladen sein?
Das hängt von der Nutzung ab.
Beispielsweise:
kleines Modell
→ oft gebraucht
→ dauerhaft im VRAM
großes Modell
→ selten gebraucht
→ bei Bedarf laden
Das spart Ressourcen.
Modellladen kostet allerdings Zeit
Ein großes Modell liegt auf SSD.
SSD
↓
RAM
↓
VRAM
Dieser Vorgang kann einige Zeit benötigen.
Wenn Nutzer interaktiv arbeiten sollen, möchte man nicht vor jeder Anfrage zuerst das Modell laden.
Häufig verwendete Modelle sollten daher resident bleiben
Beispiel:
GPU 1
→ Standardmodell
→ permanent
und:
GPU 2
→ Spezialmodelle
→ dynamisch
Das ist ein möglicher Multi-GPU-Aufbau.
Mehrere GPUs können unterschiedliche Rollen übernehmen
Unter KI-Hardware und VRAM haben wir gesehen, dass zwei GPUs nicht automatisch zu einer einzigen großen GPU werden.
Sie können aber sehr flexibel eingesetzt werden.
Zum Beispiel:
GPU 1
→ Textmodell
GPU 2
→ Bildmodell
Oder:
GPU 1
→ interaktive Nutzer
GPU 2
→ Batchverarbeitung
Das ist häufig einfacher als ein Modell über beide GPUs zu verteilen
Wenn das Standardmodell vollständig auf GPU 1 passt:
Modell
↓
GPU 1
kann GPU 2 unabhängig arbeiten.
Keine Kommunikation zwischen beiden nötig.
Ein größeres Modell kann dagegen beide Karten benötigen
Modell
↓
├── GPU 1
└── GPU 2
Dann wird die Inference Engine für die Verteilung verantwortlich.
Das erhöht:
Komplexität,
Kommunikation,
Fehlersuche.
Multi-GPU sollte deshalb einen konkreten Zweck haben.
Wie organisiert man mehrere Modelle?
Ein einfacher Ansatz:
/models
├── small/
├── medium/
├── large/
└── embeddings/
Die tatsächliche Verzeichnisstruktur ist weniger wichtig als:
Versionierung
und:
Nachvollziehbarkeit.
Modelle brauchen eindeutige Namen
Schlecht:
new-model-final-v2-real-final
Besser beispielsweise:
support-classifier
version: 3
quantization: q5
oder in einer Registry:
{
"service": "support-classifier",
"model": "model-x",
"version": "3",
"quantization": "q5"
}
Ein produktiver Workflow sollte nicht auf irgendeine Datei zeigen
Besser:
support-classifier
↓
aktuelle freigegebene Modellversion
So kann im Hintergrund:
v3
zu:
v4
wechseln.
Modellversionierung ist genauso wichtig wie Softwareversionierung
Ein neues Modell kann:
bessere Antworten,
andere Antworten,
schlechtere strukturierte Ausgaben
erzeugen.
Darum:
neue Modellversion
↓
Test
↓
Freigabe
↓
Produktiv
Nicht einfach:
„Neu ist besser.“
Dasselbe gilt für Quantisierung
Modell A Q5
und:
Modell A Q4
sollten als unterschiedliche Produktionsartefakte betrachtet werden.
Wie unter Quantisierung erklärt, kann der Unterschied:
Qualität,
Speicherbedarf,
Geschwindigkeit
beeinflussen.
Der KI-Server braucht ein internes Netzwerk
Die einfachste Architektur:
LAN
↓
KI-Server
Andere Rechner greifen über eine interne IP beziehungsweise einen internen DNS-Namen darauf zu.
Das Modell muss nicht direkt im öffentlichen Internet erreichbar sein.
Interne Dienste sollten möglichst intern bleiben
Zum Beispiel:
llm.internal
oder:
ai.home
statt:
öffentliches Internet
↓
offener LLM-Port
Ein Modellserver besitzt keinen guten Grund, völlig ungeschützt weltweit erreichbar zu sein.
Warum ein offener KI-Server gefährlich ist
Ein Angreifer könnte:
GPU auslasten,
riesige Prompts senden,
sehr lange Antworten erzeugen,
interne Modelle missbrauchen.
Falls der Server Tools oder RAG besitzt, könnten sogar interne Daten betroffen sein.
Mindestens Authentifizierung gehört davor
Zum Beispiel:
Client
↓
API Key / Benutzeridentität
↓
AI Gateway
↓
Modell
Nicht:
Internet
↓
Modell
Ein Reverse Proxy kann die Zugriffsschicht übernehmen
Konzeptionell:
Client
↓
HTTPS
↓
Reverse Proxy
↓
AI Gateway
↓
Inference Server
Der Proxy kann beispielsweise:
TLS,
Routing,
Requestgrößen,
Rate Limits
übernehmen.
Modellserver selbst kann nur intern lauschen
Zum Beispiel:
127.0.0.1
oder:
internes Docker-Netzwerk.
Dann ist er von außen gar nicht direkt erreichbar.
Nur das Gateway kommuniziert mit ihm.
Das reduziert die Angriffsfläche
Internet
↓
ein kontrollierter Einstiegspunkt
↓
interne Dienste
ist besser als:
Internet
↓
n8n
Internet
↓
LLM Server
Internet
↓
Vector DB
Internet
↓
PostgreSQL
Nicht jeder technische Dienst braucht eine öffentliche Adresse.
VPN ist für privaten Zugriff besonders attraktiv
Du bist unterwegs.
Notebook
↓
VPN
↓
Heimnetz
↓
KI-Server
Damit muss die KI-API nicht allgemein ins Internet veröffentlicht werden.
Für persönliche beziehungsweise interne Systeme kann das ausgesprochen elegant sein.
VPN und Reverse Proxy schließen einander nicht aus
Zum Beispiel:
Internet
↓
VPN
↓
internes HTTPS
↓
AI Gateway
Der Proxy übernimmt trotzdem:
Routing,
TLS,
Authentifizierung.
VPN bestimmt zusätzlich:
wer das Netzwerk überhaupt erreichen darf.
Eine Firewall bleibt ebenfalls wichtig
Wenn nur bestimmte Dienste gebraucht werden:
nur diese Ports erlauben.
Beispiel:
SSH
→ nur internes Netz / VPN
AI API
→ nur internes Netz
Datenbank
→ nur Docker-Netz
Das ist klassische Serverhärtung.
Der KI-Server ist kein Sonderfall
Er braucht dieselben Grundlagen wie jeder andere wichtige Server:
Updates,
Firewall,
starke Zugänge,
Backups,
Monitoring.
KI macht klassische IT-Sicherheit nicht überflüssig.
Der SSH-Zugang sollte ebenfalls abgesichert sein
Ein Serveradmin benötigt Remotezugriff.
Dafür kann SSH genutzt werden.
Sinnvoll ist generell eine restriktive Administration:
Admin
↓
VPN / internes Netz
↓
SSH
statt unnötig breit zugänglicher Administrationsschnittstellen.
Anwendungen sollten keine Root-Rechte bekommen
n8n braucht nicht:
Root.
Der LLM-Container braucht nicht:
Root-Zugriff auf alle Hostdateien.
Eine Vektordatenbank braucht nicht:
Zugriff auf WordPress-Konfigurationen.
Jeder Dienst sollte nur das sehen, was er braucht.
Das gilt auch für Docker-Volumes
Schlecht:
LLM Container
↓
/ komplett gemountet
Besser:
LLM Container
↓
/models
wenn nur Modelle benötigt werden.
Secrets gehören nicht in Workflowcode
Zum Beispiel:
API-Schlüssel,
Datenbankpasswörter,
Tokens.
Nicht:
docker-compose.yml
→ Klartext im öffentlichen Git-Repository
sondern:
Secret- beziehungsweise Environment-Management.
Besonders n8n besitzt häufig viele sensible Zugänge
n8n kann vielleicht zugreifen auf:
WordPress,
Mail,
Datenbank,
Cloud,
KI,
CRM.
Damit wird n8n selbst zu besonders schützenswerter Infrastruktur.
KI und n8n sollten über eine interne API verbunden werden
Zum Beispiel:
n8n
↓
http://ai-gateway.internal/classify
n8n muss nicht direkt GPU-Software steuern.
Das Gateway übernimmt:
Modellauswahl,
Validierung,
Limits.
Ein einfacher Textworkflow
WordPress
↓
Webhook
↓
n8n
↓
AI Gateway
↓
lokales Modell
↓
Structured Output
↓
n8n
↓
WordPress-Draft
Damit sind die Verantwortungen sauber verteilt.
KI erzeugt Interpretation
Zum Beispiel:
{
"category": "web-wordpress",
"content_type": "grundlagenartikel"
}
n8n übernimmt danach:
IF / Switch
↓
deterministische Logik
Das verbindet lokale KI mit strukturierten Ausgaben.
Ein lokaler KI-Server kann mehrere spezialisierte Endpoints besitzen
Beispiel:
POST /classify
POST /summarize
POST /generate
POST /embed
Damit muss nicht jeder Workflow selbst Prompts und Modelle auswählen.
Das macht KI zu einer internen Plattform
Statt:
100 Workflows
→ 100 unterschiedliche Promptimplementierungen
entsteht:
100 Workflows
↓
gemeinsame KI-Dienste
Beispielsweise:
classify-content
generate-metadata
search-knowledge
Das vereinfacht Updates
Der Klassifikationsprompt verbessert sich.
Nur:
classify-content
ändert sich.
Die 20 Workflows, die ihn benutzen, bleiben unverändert.
Promptversionierung gehört in den KI-Service
Beispiel:
Service:
article-classifier
Prompt:
v7
Model:
v3
Dann kann jedes Ergebnis später nachvollzogen werden.
Ein KI-Gateway kann Antwortmetadaten zurückgeben
Zum Beispiel:
{
"result": {
"category": "ai-automation"
},
"model": "local-14b-q5",
"prompt_version": 7,
"duration_ms": 812
}
Das verbessert Debugging und Evaluation.
Strukturierte KI-Dienste sind besser als ein universeller „Prompt-Endpunkt“
Unsicher beziehungsweise schwer wartbar:
{
"prompt": "Mach irgendwas..."
}
Besser:
{
"task": "classify_article",
"article_id": 4711
}
Die serverseitige Anwendung weiß:
welcher Prompt,
welches Modell,
welches Schema
verwendet werden soll.
Dadurch können Nutzer keine internen Systemprompts beliebig überschreiben
Das ist nicht nur Komfort.
Es verbessert die Kontrolle.
Ein allgemeiner Chat-Endpunkt kann trotzdem existieren
Zum Beispiel:
/chat
für Menschen.
Automatisierungen sollten dagegen bevorzugt klar definierte Funktionen verwenden.
/classify
/extract
/embed
Das macht sie stabiler.
RAG ist eine der wichtigsten Erweiterungen
Ein reines Sprachmodell kennt nur:
Training
plus:
aktuellen Kontext.
Interne Dokumente kann es nicht automatisch durchsuchen.
Dafür benötigen wir RAG.
Dokumente
↓
Text extrahieren
↓
Chunks
↓
Embeddings
↓
Vektordatenbank
Bei einer Frage:
Frage
↓
Embedding
↓
semantische Suche
↓
relevante Chunks
↓
LLM
Ein lokaler KI-Server kann die gesamte RAG-Kette lokal halten
Dokumente
↓
lokales Embeddingmodell
↓
lokale Vector DB
↓
lokales LLM
Damit müssen die Dokumentinhalte nicht zwingend externe KI-Anbieter erreichen.
Die Vektordatenbank muss nicht auf der GPU laufen
Wie unter Vektordatenbank beschrieben, handelt es sich primär um ein Such- und Datenspeichersystem.
Es kann beispielsweise auf:
CPU,
RAM,
SSD
arbeiten.
Die wertvolle GPU bleibt für Modellinferenz frei.
PostgreSQL kann ebenfalls eine Rolle übernehmen
Wenn bereits PostgreSQL verwendet wird, kann eine Vektorerweiterung für viele kleinere und mittlere RAG-Systeme attraktiv sein.
Dann existieren:
Geschäftsdaten
+
Vektoren
im selben Datenbanksystem.
Ob eine spezialisierte Vector Database benötigt wird, hängt von Größe und Anforderungen ab.
Der Embedding-Service kann getrennt sein
n8n
↓
Embedding API
↓
kleines Modell
Das Modell kann auf:
CPU,
kleiner GPU,
zweiter GPU
laufen.
Das große Textmodell muss dafür nicht blockiert werden.
Ein Reranker kann die dritte KI-Komponente sein
Vector Search
↓
20 Kandidaten
↓
Reranker
↓
5 beste
↓
LLM
Damit wird Retrievalqualität verbessert.
Wieder gilt:
Nicht alles muss auf derselben GPU laufen.
Ein modularer RAG-Server
RAG API
│
├── Embedding Service
├── Vector DB
├── Reranker
└── LLM Service
Die Anwendung sieht nur:
RAG API
Diese Abstraktion ist ausgesprochen praktisch.
Aktualisierungen der Wissensbasis können über Webhooks laufen
Ein WordPress-Artikel wird geändert.
WordPress
↓
post.updated
↓
Webhook
↓
n8n
↓
RAG-Ingestion
Dann:
alten Indexeintrag finden
↓
Text neu laden
↓
Chunks aktualisieren
↓
Embeddings berechnen
↓
Vector DB aktualisieren
So bleibt die lokale Wissensbasis automatisch aktuell.
Nicht jede Änderung muss sofort das LLM belasten
Für die Indexierung wird hauptsächlich:
Embeddingmodell
benötigt.
Das große Generationsmodell kann parallel andere Aufgaben erledigen.
RAG braucht Versionsinformationen
Zum Beispiel:
document_id
document_version
embedding_model
chunking_version
Wenn das Embeddingmodell geändert wird, kann ein kompletter Reindex erforderlich sein.
Das ist ein wichtiger Backupaspekt
Die Vektordatenbank kann möglicherweise neu erzeugt werden.
Wenn vorhanden sind:
Originaldokumente
Chunkinglogik
Embeddingmodell
Metadaten
Dann lautet die Frage:
Muss der Vektorindex unbedingt täglich gesichert werden?
Vielleicht.
Aber häufig ist er ein reproduzierbares Artefakt.
Nicht alle Daten eines KI-Servers sind gleich wertvoll
Kategorie A:
öffentlich herunterladbare Modelle
Diese lassen sich möglicherweise erneut herunterladen.
Kategorie B:
eigene Konfiguration
wichtig.
Kategorie C:
eigene LoRA-Adapter
sehr wichtig.
Kategorie D:
Geschäftsdokumente
kritisch.
Kategorie E:
reproduzierbare Vektorindizes
eventuell neu erzeugbar.
Backups sollten nach Wiederherstellbarkeit geplant werden
Frage:
Was wäre morgen unwiederbringlich verloren, wenn die SSD stirbt?
Diese Daten verdienen die höchste Priorität.
Beispiel einer Backupstrategie
Backup
├── PostgreSQL
├── n8n-Daten
├── Konfiguration
├── Prompts
├── LoRA-Adapter
└── eigene Dokumente
Modelldownloads können separat behandelt werden.
Ein Docker-Backup ist nicht einfach „den Container kopieren“
Container sind ersetzbar.
Relevant sind:
Volumes
Datenbanken
Konfigurationsdateien
Secrets
Der Container selbst kann aus einem Image neu erstellt werden.
Infrastructure as Code erleichtert Wiederherstellung
Angenommen, der komplette Server ist defekt.
Du installierst:
Linux.
Dann:
Docker Compose
↓
Dienste starten
↓
Backups einspielen
Wenn Konfiguration dokumentiert beziehungsweise versioniert ist, kann das System relativ reproduzierbar neu entstehen.
Das ist besser als Serverarchäologie
Was hatte ich damals
eigentlich installiert?
sollte keine Recoverystrategie sein.
Monitoring gehört von Anfang an dazu
Bei einem KI-Server sind besonders interessant:
GPU-Auslastung
VRAM
Temperatur
CPU
RAM
SSD
Queue
Anfragen
Fehler
Damit lässt sich erkennen:
Wo liegt der Engpass?
Die GPU sollte nicht isoliert beobachtet werden
Beispiel:
GPU:
20 %
CPU:
100 %
Dann ist die GPU vermutlich nicht das Problem.
Anders:
VRAM:
99 %
GPU Compute:
50 %
Nun kann Speicher die Grenze sein.
Ein lokaler KI-Server braucht Applikationsmetriken
Nicht nur Hardware.
Zum Beispiel:
requests_per_minute
time_to_first_token
tokens_per_second
queue_length
error_rate
Diese Daten erklären die Nutzererfahrung.
Modellmetriken sollten ebenfalls gespeichert werden
Zum Beispiel:
model
quantization
input_tokens
output_tokens
duration
Damit kann analysiert werden:
Welches Modell ist langsam?
Welche Workflows senden riesige Prompts?
Promptinhalte müssen dafür nicht vollständig gespeichert werden
Ein sinnvoller Datenschutzansatz kann lauten:
Metadaten
→ dauerhaft
kompletter Prompt
→ nicht loggen
oder nur kurzzeitig bei:
Debugging.
Logs können sensible Geschäftsdaten enthalten
Ein Supportagent verarbeitet:
Kundennamen,
E-Mail-Adressen,
Problembeschreibungen.
Wenn alle Prompts dauerhaft gespeichert werden, entsteht ein riesiger zusätzlicher Datenbestand.
Lokale Speicherung beseitigt diese Problematik nicht.
Datenminimierung gilt auch lokal
nur speichern,
was wirklich gebraucht wird
ist weiterhin ein gutes Prinzip.
Der Server braucht Health Checks
Zum Beispiel:
GET /health
Antwort:
{
"status": "ok"
}
Damit können andere Systeme prüfen:
Ist der Dienst erreichbar?
Zusätzlich ist Readiness interessant
Der Prozess läuft.
Aber das Modell wird gerade geladen.
alive
→ ja
ready
→ nein
Erst wenn das Modell verfügbar ist:
ready
→ ja
Docker kann Dienste erst nach Readiness freigeben
Damit verhindert man beispielsweise:
n8n sendet sofort nach Serverstart Anfragen,
während das LLM noch gar nicht geladen wurde.
KI-Jobs sollten nicht unbegrenzt gleichzeitig gestartet werden
Angenommen:
50 n8n-Workflows
↓
gleichzeitig
↓
eine GPU
Die GPU kann nicht beliebig viele Aufgaben gleichzeitig schnell bearbeiten.
Deshalb braucht man Concurrency Limits
Beispiel:
max_concurrent_jobs = 4
Weitere Jobs:
Queue
Dadurch bleibt das System stabil.
Eine Queue entkoppelt Workflow und GPU
Direkt:
n8n
↓
LLM
Der Workflow wartet auf die Antwort.
Für kurze Aufgaben hervorragend.
Für lange Batchjobs:
n8n
↓
Job Queue
↓
GPU Worker
kann sinnvoller sein.
Asynchrone Jobs benötigen eine ID
{
"job_id": "ai_4711",
"status": "queued"
}
Der Workflow kann später:
Status abfragen
oder:
auf ein Event warten.
Ein vollständiger asynchroner Ablauf
n8n
↓
Job erstellen
↓
job_id
↓
Queue
↓
GPU Worker
↓
Ergebnis speichern
↓
Webhook
↓
n8n fährt fort
Damit kann die KI-Verarbeitung Minuten dauern, ohne eine offene HTTP-Verbindung halten zu müssen.
Prioritätsqueues können sinnvoll sein
Interaktive Anfrage:
HIGH
nächtlicher Contentjob:
LOW
Dann wird der Chat nicht von zehntausenden Batchaufgaben blockiert.
Das ist besonders bei einer einzigen GPU wichtig
interaktiv
↓
schnell dran
Batch
↓
freie Kapazität nutzen
Der Server wird dadurch wesentlich angenehmer.
Mehrere GPUs erlauben getrennte Worker
Queue Interactive
↓
GPU 1
Queue Batch
↓
GPU 2
Das ist eine einfache und robuste Multi-GPU-Architektur.
Alternative: gemeinsamer Workerpool
Queue
↓
Scheduler
├── GPU 1
└── GPU 2
Der Scheduler weist freie Kapazität zu.
Das wird interessanter, sobald mehrere gleiche GPUs vorhanden sind.
Ein Scheduler muss VRAM berücksichtigen
Job A benötigt:
12 GB
GPU 1 hat frei:
4 GB
GPU 2:
16 GB
Dann sollte A zu GPU 2 gehen.
Ein wirklich flexibles KI-Serving-System wird dadurch zu Ressourcenmanagement.
Ein kleines Setup braucht das noch nicht
Eine GPU.
Ein Modell.
Ein Nutzer.
Dann:
API
↓
Modell
reicht.
Komplexität sollte erst entstehen, wenn ein reales Problem sie rechtfertigt.
Ein KI-Server kann Cloud-Fallback besitzen
Zum Beispiel:
lokales Modell
↓
verfügbar?
├── ja → lokal
└── nein → Cloud
Das erhöht Verfügbarkeit.
Aber nur, wenn die betroffenen Daten einen Cloudtransfer erlauben.
Datenschutzregeln müssen vor dem Routing greifen
Nicht:
lokales Modell kaputt
↓
alles automatisch in Cloud
sondern:
data_classification
↓
confidential?
├── ja → kein Cloud-Fallback
└── nein → Cloud erlaubt
Damit bleiben Datenregeln deterministisch.
Ein AI Gateway ist ideal für solche Regeln
Anfrage
↓
Klassifizierung der Daten
↓
Routing
├── lokal
├── anderes lokales Modell
└── erlaubte Cloud
Anwendungen müssen diese Logik nicht selbst implementieren.
Cloud kann auch Leistungsfallback sein
Lokale Queue:
2 Minuten
für eine zeitkritische öffentliche Aufgabe vielleicht zu lang.
Dann könnte eine erlaubte Cloudinstanz übernehmen.
Wieder gilt:
nur für freigegebene Daten.
Kostenrouting funktioniert genauso
kleine Standardaufgabe
→ lokales kleines Modell
schwierige Aufgabe
→ großes lokales Modell
sehr seltene Spezialaufgabe
→ Cloud
Damit kann eine hybride Infrastruktur wirtschaftlicher sein als entweder:
alles lokal
oder:
alles Cloud.
Ein lokaler KI-Server eignet sich hervorragend für Klassifikationsjobs
Beispiel:
Artikel
↓
lokales Modell
↓
Kategorie
Solche Ausgaben sind:
kurz,
strukturiert,
häufig.
Ein kleineres Modell kann große Mengen effizient verarbeiten.
Langformtexte belasten den Server wesentlich länger
Klassifikation:
20 Output-Tokens
Artikel:
5.000 Output-Tokens
Die zweite Aufgabe blockiert GPU-Kapazität erheblich länger.
Daher können verschiedene Jobklassen sinnvoll sein.
Verschiedene Modelle pro Aufgabe helfen
Klassifikation
→ kleines Modell
Zusammenfassung
→ mittleres Modell
Langtext
→ großes Modell
Das spart:
VRAM,
Strom,
Zeit.
Ein Modellrouter kann genau dies automatisieren
task_type
↓
├── classify → small
├── extract → small
├── summarize → medium
└── write → large
Der Router muss keine KI sein.
Eine einfache Tabelle kann ausreichen.
Harte Routingregeln sind oft besser
Wenn die Aufgabe eindeutig ist:
task = embedding
→ embedding server
Kein Agent muss darüber nachdenken.
Ein KI-Agent kann trotzdem lokale Dienste verwenden
Unter KI-Agenten haben wir Agenten als modellgesteuerte Entscheidungssysteme kennengelernt.
Lokal könnte das aussehen wie:
Agent
↓
lokales Modell
↓
Tools
├── RAG
├── Datenbank
├── WordPress
└── Monitoring
Tool-Server und Modellserver sollten getrennt sein
Das Modell braucht nicht selbst direkten Datenbankzugriff.
Besser:
Agent
↓
Tool:
get_article(id)
↓
Tool Service
↓
WordPress
Das schützt:
Credentials
und:
Berechtigungen.
Das Modell sollte nie Datenbankpasswörter kennen
Es braucht nur:
get_article
Die Toolimplementierung besitzt die Credentials.
Dieses Prinzip ist für lokale Agenten genauso wichtig wie für Cloud-Agenten.
Lokal verführt leicht zu übermäßigen Rechten
Gedanke:
Ist ja alles mein eigener Server.
Also erhält der Agent:
Shell,
Datenbank,
Dateisystem,
Root.
Genau das ist gefährlich.
Ein halluzinierender oder manipulierte Inhalte verarbeitender Agent kann dann erheblichen Schaden verursachen.
Ein read-only Agent ist ein guter Start
search_logs
read_metrics
read_wordpress
search_documents
aber nicht:
delete_database
oder:
execute_any_shell_command
Autonomie kann später gezielt erweitert werden.
Schreibende Tools brauchen starke Regeln
Beispiel:
create_wordpress_draft()
kann relativ harmlos sein.
publish_wordpress_article()
ist folgenreicher.
Noch kritischer:
delete_site()
Tools sollten deshalb nach Risiko kategorisiert werden.
Human Approval kann vor riskanten Aktionen liegen
Agent
↓
Vorschlag
↓
Mensch bestätigt
↓
Tool
Das lässt sich wiederum über n8n orchestrieren.
Ein lokaler Server braucht Ressourcenlimits
Ein Benutzer fragt:
Schreibe 500.000 Wörter.
Ohne Begrenzung kann das Modell sehr lange rechnen.
Darum:
max_input_tokens
max_output_tokens
max_runtime
max_concurrent_requests
Solche Limits schützen die Infrastruktur.
Agenten brauchen zusätzliche Grenzen
max_steps
max_tool_calls
max_runtime
Sonst kann eine Agentenschleife die GPU dauerhaft beschäftigen.
Öffentliche Nutzung braucht Rate Limits
Casiopeya bietet später vielleicht eine öffentliche KI-Suche.
Dann könnten Bots:
1.000 Requests / Sekunde
senden.
Die eigene GPU wäre sofort überlastet.
Deshalb:
Nutzer
↓
Rate Limit
↓
Queue
↓
KI
Rate Limits können nutzerbezogen sein
Zum Beispiel:
anonymer Nutzer
→ wenige Anfragen
angemeldeter Nutzer
→ mehr
interne Automatisierung
→ eigener Bereich
Dadurch konkurriert öffentlicher Traffic nicht ungefiltert mit internen Geschäftsprozessen.
Separate Queues können diese Trennung verstärken
public
→ begrenzte Queue
internal
→ höhere Priorität
batch
→ niedrige Priorität
Das ist eine robuste Serverarchitektur.
Speicherplatz sollte ebenfalls limitiert werden
Nutzer lädt:
50-GB-Datei.
Wenn deine Anwendung das ungeprüft annimmt:
SSD voll.
Darum:
max_upload_size
max_document_count
und:
Speicherquoten.
KI-Systeme sind ganz normale Webanwendungen und brauchen entsprechende Grenzen.
Modellverzeichnisse können ebenfalls enorm wachsen
Modell A Q4
Modell A Q5
Modell A Q8
Modell B Q4
Modell B Q6
...
Plötzlich:
mehrere Terabyte.
Darum sollte regelmäßig geprüft werden:
Welche Modelle werden tatsächlich verwendet?
Alte Modelle nicht sofort löschen
Ein Produktionsrollback kann wertvoll sein.
Beispiel:
current
→ model-v4
previous
→ model-v3
Mehrere uralte Testvarianten können dagegen archiviert werden.
Checksums helfen bei Modellen
Eine Modelldatei besitzt beispielsweise eine Prüfsumme.
Damit kann geprüft werden:
Ist es wirklich dieselbe Datei wie getestet?
Das verbessert Reproduzierbarkeit.
Provenienz ist ebenfalls wichtig
Dokumentieren:
Woher kam das Modell?
Welche Lizenz?
Welche Version?
Welche Quantisierung?
Wer hat es freigegeben?
Ein KI-Server sollte nicht aus einer zufälligen Sammlung unbekannter Dateien bestehen.
Modelle können Supply-Chain-Risiken darstellen
Modellrepositories, Bibliotheken und Containerimages sind externe Softwareartefakte.
Deshalb gelten dieselben Fragen wie bei anderen Dependencies:
Quelle vertrauenswürdig?
Image aktuell?
Signatur beziehungsweise Hash geprüft?
Bekannte Sicherheitsprobleme?
Lokales Hosting schützt nicht vor einer kompromittierten Softwarelieferkette.
Container sollten nicht blind mit „latest“ laufen
Schlecht:
image: something:latest
und automatisch aktualisieren.
Plötzlich ändert sich:
API,
Performance,
Verhalten.
Besser:
image: something:version
kontrolliert testen.
Updates brauchen einen Prozess
neue Version
↓
Testsystem
↓
KI-Benchmarks
↓
Workflowtests
↓
Produktiv
Denn selbst ein reines Inference-Update kann:
Geschwindigkeit,
VRAM-Bedarf,
Output
verändern.
Ein Staging-System muss nicht gleich ein zweiter teurer GPU-Server sein
Man kann beispielsweise:
kurzzeitig Produktionshardware verwenden,
ein kleineres Testmodell nutzen,
eine separate Testinstanz starten.
Wichtig ist eher:
Nicht jede Änderung ungeprüft in laufende Automatisierungen geben.
Produktionsworkflows brauchen Rollback
Neue Modellversion liefert schlechte Ergebnisse.
Dann:
model-v4
↓
deaktivieren
model-v3
↓
wieder aktiv
Ein AI Gateway macht solche Umschaltungen einfach.
Blue-Green-Deployment ist ebenfalls möglich
Blue
→ aktuelle KI-Version
Green
→ neue Version
Green wird getestet.
Dann Routing ändern.
Falls Probleme auftreten:
zurück auf Blue.
Für kleine Systeme oft unnötig, für wichtige Infrastruktur interessant.
Canary Releases reduzieren Risiko
95 %
→ Modell A
5 %
→ Modell B
Dann Ergebnisse vergleichen.
Bei guten Werten wird B schrittweise hochgefahren.
Shadow Mode ist noch sicherer
Produktiv:
Modell A
→ Ergebnis wird verwendet
parallel:
Modell B
→ Ergebnis nur gespeichert
Damit lässt sich B testen, ohne echte Entscheidungen zu beeinflussen.
Ein KI-Server braucht echte Evals
Nicht nur:
„Das neue Modell schreibt irgendwie schöner.“
Sondern:
Testfälle
↓
messbare Ergebnisse
Zum Beispiel für Klassifikation:
Accuracy
Precision
Recall
Für strukturierte Ausgaben:
Schema-Erfolgsrate
Für RAG:
korrekte Antworten
richtige Quellen
Performance gehört ebenfalls zum Eval
Time to First Token
Tokens pro Sekunde
VRAM
Latenz
Durchsatz
Eine neue Modellversion kann qualitativ besser, aber für den Server viel zu langsam sein.
Kosten lokal bedeuten Ressourcen
Es gibt vielleicht keine Rechnung pro Token.
Aber es existieren:
Strom,
Hardwarezeit,
Queuezeit.
Deshalb kann man trotzdem Kostenmodelle bauen.
Zum Beispiel:
GPU-Zeit pro Aufgabe
oder:
Wattstunden pro 1.000 Aufgaben
Strommessung ist besonders bei Dauerbetrieb sinnvoll
Ein Modell erzeugt:
10 Prozent bessere Qualität.
Verbraucht aber:
dreimal so viel Rechenzeit.
Ob das sinnvoll ist, hängt von der Aufgabe ab.
Idle-Verbrauch gehört ebenfalls zur Wirtschaftlichkeit
Der Server läuft:
24 Stunden.
Rechnet:
2 Stunden.
Dann kann der Leerlaufverbrauch den Gesamtstrom erheblich beeinflussen.
Vielleicht lohnt:
Sleep,
zeitgesteuertes Starten,
Wake-on-LAN.
Für Batchsysteme kann zeitgesteuertes Einschalten sinnvoll sein
Zum Beispiel:
02:00
↓
KI-Server startet
↓
Batchjobs
↓
Backups
↓
Server fährt herunter
Für einen jederzeit verfügbaren Chatserver dagegen nicht.
Ein zentraler Server kann ein Single Point of Failure sein
Wenn:
KI-Server down
dann vielleicht:
Contentworkflow down.
Supportautomation down.
RAG down.
Agent down.
Je wichtiger das System wird, desto wichtiger wird ein Fallback.
Der einfachste Fallback ist manuell
KI nicht verfügbar
↓
Workflow in Review-Queue
Das kann vollkommen ausreichend sein.
Nicht jede Anwendung braucht Hochverfügbarkeit.
Cloud-Fallback ist eine weitere Option
Nur für erlaubte Daten.
Wie bereits beschrieben:
lokal down
↓
Cloud erlaubt?
├── ja → Cloud
└── nein → warten / manuell
Ein zweiter lokaler Worker erhöht Verfügbarkeit
AI Gateway
├── Server A
└── Server B
Fällt A aus:
B übernimmt.
Das wird erst interessant, wenn Ausfallzeiten tatsächlich geschäftlich teuer werden.
Skalierung sollte schrittweise erfolgen
Stufe 1:
1 Rechner
1 GPU
1 Modell
Stufe 2:
1 Rechner
2 GPUs
Stufe 3:
1 Rechner
mehrere Services
+
Queues
Stufe 4:
mehrere GPU-Worker
Stufe 5:
AI Gateway
+
Scheduler
+
mehrere Nodes
Man sollte nicht mit Stufe 5 anfangen, wenn Stufe 1 den Bedarf vollständig erfüllt.
Ein zweiter Server kann später ein Worker werden
Gateway
↓
├── Worker A
└── Worker B
Damit lässt sich horizontal erweitern.
Der ursprüngliche Server bleibt bestehen.
Anwendungen müssen davon nichts wissen
Sie sprechen weiterhin:
AI Gateway
Das Gateway entscheidet:
welcher Worker.
Genau deshalb lohnt die API-Abstraktion von Anfang an.
Unterschiedliche Worker können unterschiedliche Hardware besitzen
Worker A
→ viel VRAM
→ großes Modell
Worker B
→ schnelle kleinere GPU
→ Klassifikation
Worker C
→ CPU
→ Embeddings
Das System muss nicht homogen sein.
Ein Scheduler kann Fähigkeiten statt Hardwareadressen kennen
Job:
{
"capability": "longform-writing"
}
Scheduler:
welcher Worker kann das?
Nicht:
sende zu 192.168.1.27
Das macht Infrastruktur austauschbar.
Kubernetes ist dafür nicht automatisch nötig
Containerorchestrierung kann bei sehr großen Umgebungen sinnvoll sein.
Für:
einen oder wenige Server
ist Docker Compose häufig wesentlich einfacher.
Technische Eleganz besteht nicht darin, die komplexeste Lösung zu benutzen.
Ein einfaches System ist leichter zu sichern und wiederherzustellen
1 Host
5 Container
1 Konfigurationsdatei
ist überschaubar.
Bei:
50 Microservices
steigen:
Fehlerquellen,
Updates,
Monitoringaufwand.
Microservices sollte man nicht aus Modegründen bauen
Ein einzelner AI-Gateway-Service kann mehrere Funktionen enthalten:
classify
summarize
generate
Das ist völlig in Ordnung.
Erst wenn:
Skalierung,
Teams,
unterschiedliche Laufzeiten
es verlangen, kann weiter getrennt werden.
Ein lokaler KI-Server ist im Kern eine gewöhnliche Serviceplattform
Der grundlegende Aufbau unterscheidet sich kaum von anderen modernen Serversystemen.
Clients
↓
API
↓
Business Logic
↓
Backend Services
↓
Daten
Nur einer der Backenddienste enthält:
ein Sprachmodell auf einer GPU.
Das hilft, den vermeintlichen KI-Zauber zu entmystifizieren.
Was ein sinnvoller kleiner Aufbau enthalten könnte
Konzeptionell:
Internet / LAN
↓
Reverse Proxy
↓
├── n8n
└── AI Gateway
↓
LLM Server
↓
GPU
Dazu:
PostgreSQL
für dauerhafte Daten.
Das reicht bereits für sehr viele KI-Automatisierungen.
RAG kommt als weitere Schicht dazu
AI Gateway
↓
RAG Service
├── Embeddingmodell
├── Vector DB
└── LLM
Jetzt kann der Server eigenes Wissen nutzen.
Agenten kommen erst danach
Agent Service
↓
LLM
↓
Tools
├── RAG
├── n8n
├── WordPress
└── interne APIs
Damit wächst die Architektur nachvollziehbar.
Nicht mit dem Agenten beginnen
Ein sinnvoller Aufbaupfad lautet:
1. Modell läuft stabil
↓
2. API funktioniert
↓
3. strukturierte Ausgaben funktionieren
↓
4. n8n funktioniert
↓
5. RAG funktioniert
↓
6. erst dann Agenten
Sonst entstehen zu viele Fehlerquellen gleichzeitig.
Ein Fehler sollte einer Schicht zugeordnet werden können
Antwort schlecht.
Warum?
Modell?
Prompt?
Retrieval?
Tool?
Workflow?
API?
Modulare Architektur erleichtert diese Diagnose.
Ein monolithischer Mega-Agent erschwert Fehlersuche
Agent
↓
irgendetwas passiert
↓
falsches Ergebnis
Das ist schlecht debuggbar.
Besser:
Input
↓
Retrieval
↓
LLM
↓
Schema
↓
Business Rule
↓
Action
Jede Ebene kann geprüft werden.
Health Monitoring sollte automatisiert alarmieren
Beispielsweise:
GPU-Temperatur zu hoch
SSD fast voll
AI API nicht erreichbar
Queue > 1.000 Jobs
Dann entsteht ein Alarm.
Nicht erst:
Nutzer bemerken, dass nichts mehr funktioniert.
n8n kann sogar Teile dieses Monitorings übernehmen
Zum Beispiel:
alle 5 Minuten
↓
Health API
↓
Status != ok?
↓
Benachrichtigung
Für große Systeme ist spezialisierte Monitoringsoftware sinnvoller.
Für kleine Installationen kann eine einfache Überwachung zunächst genügen.
Monitoring darf nicht auf demselben Fehlerpfad vollständig verschwinden
Wenn der ganze Server ausgeht:
ein Monitoringprozess auf demselben Server kann ebenfalls nichts mehr melden.
Für wichtige Systeme ist deshalb ein externer Health Check sinnvoll.
Backups ebenfalls nicht ausschließlich auf derselben Maschine
Server
↓
Backup
↓
gleiche SSD
ist kein echtes Schutzkonzept gegen einen SSD-Defekt.
Mindestens eine Backupkopie sollte auf einem anderen Speichermedium beziehungsweise System liegen.
Ein lokaler KI-Server braucht nicht jedes Modell im Backup
Große öffentlich verfügbare Modelldateien könnten neu heruntergeladen werden.
Statt Terabytes davon täglich zu sichern, kann eine Model Registry dokumentieren:
Name
Version
Quelle
Checksum
Quantisierung
Dann lassen sie sich reproduzieren.
Eigene Fine-Tunes müssen dagegen unbedingt gesichert werden
Ein selbst trainierter LoRA-Adapter lässt sich möglicherweise nur mit erheblichem Aufwand neu erzeugen.
Also:
LoRA
→ Backup
Ebenso:
Trainingsdatensätze
und:
Evaluationsdaten.
Prompts sind ebenfalls wertvolle Produktdaten
Ein über Monate optimierter Prompt kann für eine Automatisierung genauso wichtig sein wie Quellcode.
Deshalb:
Prompt
→ Versionierung
→ Backup
Nicht nur irgendwo in einem n8n-Node speichern.
Workflowdefinitionen ebenfalls
Wenn n8n zentrale Geschäftsprozesse enthält:
n8n-Daten
→ Backup
Der Wert der Maschine liegt oft weniger in der GPU als in der Automatisierungslogik, die darauf aufgebaut wurde.
Ein Disaster-Recovery-Test ist wertvoll
Nicht nur:
Wir haben Backups.
Sondern:
Können wir daraus tatsächlich einen neuen Server herstellen?
Ein guter Test:
neuer Host
↓
Konfiguration
↓
Backup
↓
Dienste starten
↓
Testworkflow
Wenn das funktioniert, ist das Backup wirklich brauchbar.
Dokumentation sollte zum Server gehören
Mindestens:
Architektur
Dienste
Ports
Modelle
Volumes
Backups
Credentials-Struktur
Updateprozess
Recoveryprozess
Nicht jedes Detail muss ein hundertseitiges Handbuch werden.
Aber ein zukünftiger Administrator sollte das System verstehen können.
Ein Architekturdiagramm ist ausgesprochen hilfreich
Zum Beispiel:
┌──────────────┐
│ Benutzer │
└──────┬───────┘
↓
┌──────────────┐
│ Reverse Proxy│
└──────┬───────┘
↓
┌────────────────────┐
│ AI Gateway │
└─────┬────────┬─────┘
│ │
┌────────┘ └─────────┐
↓ ↓
┌─────────────┐ ┌─────────────┐
│ LLM Service │ │ RAG Service │
└──────┬──────┘ └──────┬──────┘
↓ │
GPU ┌──────┴───────┐
↓ ↓
Embeddings Vector DB
Daneben:
n8n
↓
AI Gateway
Damit versteht man die Plattform auf einen Blick.
Eine größere Architektur könnte so aussehen
Clients
↓
Reverse Proxy
↓
AI Gateway
↓
┌─────────┴─────────┐
↓ ↓
Request Queue RAG Service
↓ ↓
GPU Scheduler Vector Database
┌─────┴─────┐
↓ ↓
GPU 1 GPU 2
↓ ↓
LLM A LLM B
Dazu:
PostgreSQL
n8n
Monitoring
Backup
Auch hier gilt:
Nur bauen, wenn tatsächlich benötigt.
Ein lokaler KI-Server sollte mit einem einfachen Ziel starten
Zum Beispiel:
Dieser Server soll eingehende Texte klassifizieren.
Dann:
API
↓
Modell
↓
Structured Output
Das lässt sich testen und messen.
Danach zweiter Anwendungsfall
Zusätzlich soll er Texte generieren.
Dann:
zweites Modell
oder:
gleicher Modelldienst mit anderer Konfiguration.
Danach RAG
Nun soll er unsere Dokumente kennen.
Erst jetzt:
Embeddingmodell,
Vector DB.
Danach Agenten
Nun soll er selbstständig verschiedene Informationsquellen auswählen.
Erst dann:
Tool Calling
und:
agentische Schleifen.
So bleibt die Infrastruktur verständlich
Jede neue Schicht löst ein konkretes Problem.
Nicht:
Wir haben gelesen,
dass man eine Vektordatenbank,
Agenten,
Redis und Kubernetes braucht.
Sondern:
Problem
↓
passende Komponente
Was du dir über einen lokalen KI-Server merken solltest
Ein lokaler KI-Server ist nicht einfach ein PC, auf dem ein Sprachmodell läuft.
Er stellt KI-Funktionen dauerhaft für andere Anwendungen bereit.
Das einfachste Modell lautet:
Anwendung
↓
API
↓
Inference Server
↓
lokales Modell
↓
GPU
Der wichtigste Architekturgedanke ist dabei die Trennung der Komponenten.
n8n
→ orchestriert
AI Gateway
→ routet und kontrolliert
Inference Engine
→ führt das Modell aus
GPU
→ rechnet
Vector DB
→ speichert semantisch durchsuchbares Wissen
PostgreSQL
→ speichert Geschäftsdaten und Zustände
Dadurch können einzelne Teile unabhängig geändert werden.
Das Modell kann beispielsweise ersetzt werden:
Modell A
↓
Modell B
ohne alle Workflows umzubauen, solange die API stabil bleibt.
Container wie Docker eignen sich gut, um diese Dienste sauber voneinander zu trennen.
Docker Host
│
├── Reverse Proxy
├── n8n
├── AI Gateway
├── LLM Server
├── PostgreSQL
└── Vector DB
Nicht jeder Dienst benötigt GPU-Zugriff.
Die GPU sollte möglichst nur den Komponenten zur Verfügung stehen, die sie tatsächlich benötigen.
Die Infrastruktur sollte außerdem nicht unnötig öffentlich erreichbar sein.
Ein gutes Grundmodell lautet:
Client
↓
VPN / internes Netz / kontrolliertes HTTPS
↓
Reverse Proxy
↓
AI Gateway
↓
interne KI-Dienste
Nicht:
Internet
↓
offener Modellserver
Zu einem produktiven Server gehören genauso wie bei anderer IT:
Authentifizierung
Firewall
Least Privilege
Secrets Management
Updates
Monitoring
Backups
Lokales Hosting bedeutet:
mehr Kontrolle.
Aber auch:
mehr Verantwortung.
Für Automatisierung bietet sich n8n als Orchestrator an.
Trigger
↓
n8n
↓
lokale KI
↓
Structured Output
↓
deterministische Logik
↓
Aktion
Damit bleibt das Sprachmodell eine klar begrenzte Komponente.
Für eigene Dokumente kann RAG ergänzt werden.
Dokumente
↓
Embeddings
↓
Vektordatenbank
↓
Retrieval
↓
lokales LLM
Damit kann eine komplette Wissensverarbeitung innerhalb der eigenen Infrastruktur stattfinden.
Mehrere GPUs können unterschiedlich eingesetzt werden.
GPU 1
→ interaktives Sprachmodell
GPU 2
→ Batchjobs
oder:
GPU 1 + GPU 2
→ gemeinsames größeres Modell
Die erste Variante ist häufig einfacher.
Die zweite wird interessant, wenn ein gewünschtes Modell nicht in den VRAM einer einzelnen GPU passt.
Quantisierung kann diesen Speicherbedarf zusätzlich stark reduzieren.
Damit sollte vor dem Kauf zusätzlicher Hardware immer geprüft werden:
kleineres Modell?
stärkere Quantisierung?
weniger Kontext?
besseres RAG?
Erst danach:
mehr VRAM
oder
weitere GPU
Für größere Lasten kommen Queues hinzu.
Anwendungen
↓
Queue
↓
GPU Worker
Damit können:
interaktive Anfragen,
Batchjobs
und:
Agenten
kontrolliert dieselbe Infrastruktur nutzen.
Ein Server sollte außerdem beobachtbar sein.
GPU
VRAM
CPU
RAM
Temperatur
Queue
Latenz
Tokens pro Sekunde
Fehlerrate
Nur dann lässt sich entscheiden, welches Upgrade tatsächlich benötigt wird.
Der sinnvollste Aufbaupfad lautet deshalb:
1. Modell lokal stabil betreiben
↓
2. API bereitstellen
↓
3. Anwendungen anbinden
↓
4. Monitoring und Backups
↓
5. strukturierte KI-Dienste
↓
6. RAG
↓
7. Queues und mehrere Modelle
↓
8. Agenten
↓
9. bei echtem Bedarf mehrere Worker
Damit entsteht kein künstlich kompliziertes „KI-Rechenzentrum“.
Sondern eine Infrastruktur, die mit den tatsächlichen Anforderungen wachsen kann.
Und genau darin liegt der große Vorteil eigener KI-Hardware:
Man muss nicht von Anfang an wissen, wie das endgültige System aussehen wird.
Man braucht lediglich eine saubere Trennung zwischen:
Anwendung
↓
Schnittstelle
↓
KI-Dienst
↓
Hardware
Dann kann jede dieser Schichten später unabhängig weiterentwickelt werden.