Du schreibst eine Frage in eine KI-Anwendung.
Wenige Sekunden später erscheint die Antwort.
Was dazwischen passiert, bleibt für viele Nutzer unsichtbar.
Bei einem typischen Cloud-Dienst sieht der Weg ungefähr so aus:
Dein Computer
↓
Internet
↓
Server des KI-Anbieters
↓
KI-Modell
↓
Antwort
↓
Internet
↓
Dein Computer
Das eigentliche Sprachmodell läuft nicht auf deinem Gerät.
Dein Rechner zeigt lediglich die Benutzeroberfläche an und übermittelt die Anfrage.
Bei lokaler KI verschiebt sich dieser entscheidende Teil.
Dein Computer oder eigener Server
↓
KI-Modell
↓
Antwort
Das Modell wird auf Hardware ausgeführt, die du selbst kontrollierst oder zumindest selbst betreibst.
Das kann sein:
ein Notebook,
ein Desktop-PC,
eine Workstation,
ein Heimserver,
ein Server im eigenen Unternehmen.
Damit verändert sich nicht unbedingt die grundsätzliche Funktionsweise des Modells.
Es verändert sich vor allem:
Wo die Berechnung stattfindet und wer die Infrastruktur kontrolliert.
Lokal bedeutet zunächst nur: Die Inferenz läuft bei dir
Der wichtigste Begriff an dieser Stelle ist Inferenz.
Ein Sprachmodell wird zunächst trainiert.
Danach kann es verwendet werden, um auf Eingaben neue Ausgaben zu erzeugen.
Diese Nutzung nennt man Inferenz.
Vereinfacht:
Training
→ Modell wird erstellt
danach:
Inferenz
→ vorhandenes Modell beantwortet Anfragen
Wenn wir von lokaler KI sprechen, meinen wir normalerweise nicht:
Du trainierst ein großes Sprachmodell vollständig von Grund auf.
Das wäre ein völlig anderes Projekt.
Meist bedeutet lokale KI:
fertig trainiertes Modell
↓
auf eigener Hardware laden
↓
lokal für Inferenz verwenden
Lokal heißt nicht automatisch offline
Das wird häufig verwechselt.
Ein Modell kann lokal laufen, während die Anwendung trotzdem:
Webseiten abruft,
Cloudspeicher verwendet,
externe APIs anspricht,
Telemetrie sendet.
Beispiel:
lokales Sprachmodell
↓
Websuche über externe API
↓
Antwort
Das Modell selbst läuft lokal.
Der gesamte Workflow ist trotzdem nicht offline.
Vollständig offline ist eine strengere Anforderung
Ein wirklich offline arbeitendes System könnte so aussehen:
lokaler Rechner
├── Sprachmodell
├── Embeddingmodell
├── Dokumente
├── Vektordatenbank
└── Benutzeroberfläche
Keine Internetverbindung erforderlich.
Das kann bei besonders sensiblen Daten interessant sein.
Aber:
Lokale KI und Offline-KI sind nicht automatisch dasselbe.
Auch „privat“ und „lokal“ sind nicht dasselbe
Ein Modell läuft auf deinem eigenen Rechner.
Deine Benutzeroberfläche sendet aber gleichzeitig Nutzungsdaten an einen externen Dienst.
Dann ist die Verarbeitung nicht vollständig privat.
Oder ein lokaler KI-Agent besitzt Zugriff auf:
Cloudspeicher,
Websuche,
externe APIs.
Auch dann verlassen Daten möglicherweise die eigene Infrastruktur.
Deshalb sollte man drei Fragen getrennt betrachten:
Wo läuft das Modell?
Wo liegen die Daten?
Welche externen Dienste werden verwendet?
Erst zusammen ergibt sich die tatsächliche Datenschutzarchitektur.
Warum betreibt man KI überhaupt lokal?
Cloud-KI ist ausgesprochen bequem.
Kein leistungsfähiger Rechner notwendig.
Keine Modellinstallation.
Keine GPU-Treiber.
Keine Updates der Inference-Software.
Warum also den zusätzlichen Aufwand?
Dafür gibt es mehrere mögliche Gründe.
Zum Beispiel:
Datenschutz
Datenkontrolle
Offline-Nutzung
geringere Abhängigkeit von Anbietern
individuelle Modelle
vorhersehbare Infrastrukturkosten
Experimentierfreiheit
Integration in eigene Systeme
Welche davon tatsächlich relevant sind, hängt stark vom Anwendungsfall ab.
Datenschutz ist ein häufiger Grund
Angenommen, du möchtest tausende interne Dokumente analysieren.
Darunter befinden sich:
Geschäftsgeheimnisse,
Verträge,
Kundendaten,
interne Protokolle.
Eine mögliche Architektur lautet:
Dokument
↓
Cloud-KI
↓
Analyse
Dabei werden Daten an einen externen Dienst übertragen.
Ob das zulässig oder sinnvoll ist, hängt von:
Verträgen,
Anbieterbedingungen,
Datenkategorie,
rechtlichen Anforderungen,
Unternehmensrichtlinien
ab.
Eine lokale Architektur kann dagegen ermöglichen:
Dokument
↓
eigener Server
↓
lokales Modell
Die Inhalte müssen für die Modellinferenz nicht zwangsläufig die eigene Infrastruktur verlassen.
Lokal reduziert Datenweitergabe, löst Datenschutz aber nicht automatisch
Ein eigener KI-Server kann trotzdem schlecht abgesichert sein.
Zum Beispiel:
KI-Server
↓
öffentlich erreichbar
↓
keine Authentifizierung
Oder:
alle Mitarbeiter können sämtliche Dokumente abrufen.
Oder:
Prompts werden unbegrenzt geloggt.
Oder:
Backups sind unverschlüsselt.
Dann hat man zwar keinen externen KI-Anbieter.
Das Datenschutzproblem ist trotzdem nicht gelöst.
Lokale KI verschiebt Verantwortung
Cloud:
Anbieter
→ betreibt Modellserver
lokal:
du
→ betreibst Modellserver
Damit erhältst du mehr Kontrolle.
Aber auch mehr Verantwortung für:
Updates,
Zugriffsschutz,
Backups,
Netzwerksicherheit,
Monitoring,
Hardware.
Mehr Kontrolle und mehr Arbeit gehören zusammen.
Ein zweiter Grund ist Anbieterunabhängigkeit
Bei Cloud-KI hängt deine Anwendung möglicherweise von:
einem Modell,
einem Preis,
einem API-Format,
einem Anbieter
ab.
Dieser Anbieter kann:
Preise ändern,
Modelle einstellen,
Limits verändern,
Funktionen anpassen.
Bei lokalen Modellen besitzt du mehr Einfluss darauf, welche Modellversion verwendet wird.
Modellversion A
↓
bleibt lokal verfügbar
Auch wenn Monate später bereits Modell B existiert.
Das verbessert Reproduzierbarkeit
Ein automatisierter Prozess wurde mit Modellversion X getestet.
Dann möchtest du später nachvollziehen:
Warum kam damals dieses Ergebnis?
Wenn du dieselbe Modellversion weiterhin besitzt, ist das einfacher.
Natürlich bleibt generative Inferenz nicht in jedem Setup vollständig deterministisch.
Aber die Infrastruktur lässt sich stärker kontrollieren.
Lokale Modelle erlauben mehr Experimente
Vielleicht möchtest du:
verschiedene Quantisierungen testen,
Prompts vergleichen,
eigene RAG-Pipelines bauen,
Modelle fine-tunen,
Embeddings lokal erzeugen,
verschiedene Inference-Engines vergleichen.
Mit eigener Infrastruktur kannst du sehr frei experimentieren.
Du bist nicht ausschließlich auf die Funktionen einer fertigen Cloudoberfläche angewiesen.
Was ist ein lokales Sprachmodell?
Ein Sprachmodell besteht vereinfacht aus:
Modellarchitektur
+
trainierten Parametern
Diese Parameter werden in Modelldateien gespeichert.
Eine lokale Inference-Software lädt sie.
Modelldatei
↓
Inference Engine
↓
CPU / GPU
↓
Textgenerierung
Die Inference Engine ist also die Software, welche das Modell tatsächlich ausführt.
Das Modell und die Anwendung sind unterschiedliche Dinge
Das ist wichtig.
Du könntest dasselbe Modell verwenden über:
eine Kommandozeile,
eine Desktopanwendung,
einen Webserver,
eine API,
n8n.
Modell
↓
Inference Engine
↓
verschiedene Benutzeroberflächen
Das Modell selbst ist nicht automatisch:
Chatoberfläche,
API,
RAG-System
oder:
Agent.
Diese Funktionen entstehen darum herum.
Ein lokales KI-System besteht aus mehreren Schichten
Ein einfaches System:
Benutzer
↓
Chatoberfläche
↓
Inference Engine
↓
Sprachmodell
↓
GPU
Ein fortgeschrittenes System:
Benutzer
↓
Weboberfläche
↓
API
↓
Orchestrator
├── Sprachmodell
├── Embeddingmodell
├── RAG
├── Datenbank
└── Tools
↓
Hardware
Damit wird deutlich:
Das Modell ist nur ein Bestandteil eines vollständigen lokalen KI-Systems.
Was sind Open-Weight-Modelle?
Bei vielen kommerziellen Cloudmodellen erhältst du keinen direkten Zugriff auf die trainierten Gewichte.
Du verwendest das Modell über:
Website
oder:
API.
Bei sogenannten Open-Weight-Modellen werden die trainierten Modellgewichte dagegen zum Herunterladen bereitgestellt.
Dadurch kann eine geeignete Inference-Software sie lokal laden.
Modelldateien herunterladen
↓
lokal speichern
↓
lokal ausführen
Open Weight ist nicht automatisch Open Source
Das ist eine wichtige begriffliche Unterscheidung.
Bei klassischer Open-Source-Software erwartet man beispielsweise:
Quellcode,
Lizenz zur Veränderung,
Weitergabe nach festgelegten Bedingungen.
Bei einem KI-Modell können zwar Gewichte verfügbar sein, während:
Trainingsdaten,
vollständiger Trainingsprozess,
bestimmte Nutzungsmöglichkeiten
nicht offen sind.
Darum sollte man nicht automatisch jedes herunterladbare Modell als vollständig „Open Source“ bezeichnen.
Die Modelllizenz bleibt wichtig
Nur weil du eine Modelldatei herunterladen kannst, bedeutet das nicht:
Du darfst damit beliebig alles tun.
Lizenzen können beispielsweise unterscheiden zwischen:
privater Nutzung,
kommerzieller Nutzung,
Weitergabe,
bestimmten Einsatzbereichen.
Wer ein Modell produktiv einsetzen möchte, sollte deshalb die konkrete Modelllizenz prüfen.
Was bedeutet die Zahl bei Modellgrößen?
Du begegnet häufig Bezeichnungen wie:
3B
7B
8B
14B
32B
70B
Das B steht grob für:
billion, also Milliarden.
Ein:
8B-Modell
besitzt ungefähr acht Milliarden Parameter.
Ein:
70B-Modell
ungefähr siebzig Milliarden.
Mehr Parameter bedeuten nicht automatisch proportional mehr Qualität
Ein größeres Modell kann leistungsfähiger sein.
Aber Qualität hängt zusätzlich ab von:
Training,
Architektur,
Daten,
Fine-Tuning,
Aufgabe.
Ein modernes kleineres Modell kann bei bestimmten Aufgaben ein älteres größeres Modell schlagen.
Deshalb sollte man nicht ausschließlich kaufen beziehungsweise auswählen nach:
größte Parameterzahl
=
bestes Modell
Modellgröße ist allerdings entscheidend für Hardware
Parameter müssen gespeichert und während der Inferenz verarbeitet werden.
Ein vereinfachtes Beispiel:
Ein Modell besitzt:
8 Milliarden Parameter
und jeder Parameter benötigt:
2 Byte
Dann wären allein die Gewichte ungefähr:
8 Milliarden × 2 Byte
≈ 16 GB
Das ist nur eine grobe Rechnung.
Sie zeigt aber den Zusammenhang.
Deshalb ist die numerische Darstellung wichtig
Modelle können ihre Gewichte mit unterschiedlicher Präzision speichern.
Zum Beispiel vereinfacht:
32 Bit
16 Bit
8 Bit
4 Bit
Weniger Bits:
weniger Speicher
Das führt zu einem zentralen Thema lokaler KI:
Quantisierung.
Was ist Quantisierung?
Ein ursprünglich relativ präzise gespeichertes Modell wird in eine kompaktere numerische Darstellung überführt.
Vereinfacht:
größeres präziseres Zahlenformat
↓
kompaktere Darstellung
↓
weniger Speicherbedarf
Dadurch kann ein Modell auf Hardware laufen, auf der die ursprüngliche Variante nicht Platz hätte.
Ein stark vereinfachtes Beispiel
Ein Modell benötigt in höherer Präzision vielleicht:
16 GB
Die quantisierte Variante vielleicht:
5–6 GB
Die tatsächlichen Werte hängen stark ab von:
Modell,
Quantisierungsverfahren,
Format,
zusätzlichen Daten.
Das Grundprinzip bleibt:
Quantisierung
→ geringerer Speicherbedarf
Quantisierung ist nicht kostenlos
Weniger numerische Präzision kann die Modellqualität beeinflussen.
Extrem vereinfacht:
mehr Kompression
↓
weniger Speicher
↓
potenziell mehr Qualitätsverlust
Moderne Quantisierungsverfahren können allerdings erstaunlich gute Qualität bei deutlich reduziertem Speicherbedarf liefern.
Deshalb sind quantisierte Modelle für lokale KI so wichtig.
Der beste Quantisierungsgrad hängt vom Anwendungsfall ab
Vielleicht ist:
höchstmögliche Qualität
entscheidend.
Dann wird mehr Speicher akzeptiert.
Vielleicht geht es um:
einfache Textklassifikation.
Dann reicht möglicherweise eine deutlich kompaktere Variante.
Man sollte deshalb messen:
Qualität
Geschwindigkeit
Speicherbedarf
statt nur den kleinsten Download auszuwählen.
Quantisierung behandeln wir separat
Unter:
/wissen/quantisierung/
werden wir genauer erklären:
Bitbreite,
Speicherbedarf,
Qualitätsverlust,
verschiedene Quantisierungskonzepte
und warum:
4 Bit
nicht einfach bedeutet:
Das Modell besitzt exakt ein Viertel der Qualität.
Die Beziehung ist wesentlich komplexer.
Die wichtigste Hardwarefrage lautet häufig: Wie viel VRAM?
VRAM ist der Arbeitsspeicher einer Grafikkarte.
Beispielsweise:
GPU
├── Recheneinheiten
└── VRAM
Bei lokaler KI ist VRAM besonders wichtig, weil dort unter anderem große Teile beziehungsweise idealerweise das gesamte Modell für schnelle GPU-Inferenz liegen können.
Warum ist VRAM so wichtig?
Ein Modell benötigt beispielsweise:
12 GB
für Gewichte und weitere Laufzeitdaten.
Deine GPU besitzt:
8 GB VRAM
Dann passt nicht alles vollständig hinein.
Die Software muss vielleicht:
Teile im normalen RAM halten,
zwischen CPU und GPU aufteilen
oder:
eine kleinere beziehungsweise stärker quantisierte Variante verwenden.
Das kann die Geschwindigkeit deutlich beeinflussen.
VRAM entscheidet oft darüber, welches Modell komfortabel läuft
Sehr grob:
kleines Modell
→ wenig VRAM
großes Modell
→ viel VRAM
Allerdings hängt der tatsächliche Bedarf zusätzlich ab von:
Quantisierung,
Kontextlänge,
Batchgröße,
Inference Engine,
Architektur.
Darum werden wir VRAM als eigene Seite behandeln.
RAM ist trotzdem wichtig
Der normale Arbeitsspeicher des Computers wird häufig unterschätzt.
Ein lokaler KI-Server braucht RAM beispielsweise für:
Betriebssystem,
Inference Engine,
Modellanteile,
Caches,
RAG-Daten,
Datenbanken,
weitere Dienste.
Ein System mit:
viel GPU-VRAM
aber:
knappem System-RAM
kann ebenfalls eingeschränkt sein.
Ein Modell kann vollständig über CPU laufen
Eine GPU ist nicht zwingend erforderlich.
Prinzipiell:
Modell
↓
CPU
ist möglich.
Insbesondere kleinere quantisierte Modelle können auf modernen CPUs durchaus nutzbar sein.
Der Nachteil ist typischerweise:
geringere Geschwindigkeit.
Warum GPUs bei KI so stark sind
Neuronale Netze benötigen sehr viele mathematische Operationen, die sich gut parallelisieren lassen.
Grafikprozessoren besitzen sehr viele Recheneinheiten für genau solche parallelen Berechnungen.
Darum:
CPU
→ wenige sehr flexible Kerne
gegen:
GPU
→ sehr viele parallele Recheneinheiten
Vereinfacht gesagt passt die Rechenstruktur vieler KI-Operationen ausgesprochen gut zu GPUs.
Die CPU bleibt trotzdem relevant
Selbst bei GPU-Inferenz übernimmt die CPU beispielsweise:
Betriebssystem,
Datenvorbereitung,
Netzwerk,
Orchestrierung,
manche Inference-Schritte.
Ein KI-Rechner besteht deshalb nicht nur aus einer Grafikkarte.
Was bedeutet GPU-Offloading?
Angenommen, ein Modell passt nicht vollständig in den VRAM.
Dann können möglicherweise bestimmte Teile auf:
GPU
und andere auf:
CPU beziehungsweise RAM
verteilt werden.
Vereinfacht:
Modell
├── Teil → GPU
└── Teil → RAM / CPU
Das ermöglicht größere Modelle.
Allerdings häufig auf Kosten der Geschwindigkeit.
vollständig im VRAM ist oft angenehmer
Wenn ein Modell komplett in den Grafikspeicher passt:
Modell
↓
VRAM
↓
GPU
müssen während der Inferenz weniger Daten über langsamere Verbindungen zwischen RAM und GPU ausgetauscht werden.
Das kann einen erheblichen Geschwindigkeitsvorteil bringen.
Aber nicht nur die Modellgewichte brauchen Speicher
Während der Textgenerierung entstehen zusätzliche Daten.
Besonders wichtig ist der sogenannte:
KV-Cache.
Er speichert Informationen über bereits verarbeitete Tokens des aktuellen Kontexts.
Je länger der Kontext:
mehr Tokens
↓
größerer KV-Cache
Dadurch steigt der Speicherbedarf.
Kontextlänge kostet also Hardware
Ein Modell passt mit kurzem Prompt problemlos in den VRAM.
Nun gibst du ihm:
100.000 Tokens Kontext.
Plötzlich steigt der Speicherbedarf erheblich.
Deshalb bedeutet:
Modell passt in 12 GB
nicht automatisch:
Es passt mit jeder beliebigen Kontextlänge in 12 GB.
Unser Kontextfenster-Artikel wird hier praktisch
Unter Kontextfenster haben wir betrachtet, wie viele Tokens ein Modell gleichzeitig berücksichtigen kann.
Bei lokaler KI kommt nun eine weitere Dimension dazu:
großes Kontextfenster
→ mehr Speicher
→ mehr Rechenarbeit
Eine theoretisch unterstützte Kontextlänge muss nicht praktisch sinnvoll sein.
Sehr lange Kontexte kosten auch Geschwindigkeit
Mehr Tokens müssen verarbeitet werden.
Darum:
kurzer Prompt
→ schnelle erste Antwort
riesiger Dokumentstapel
→ längere Verarbeitung
RAG kann deshalb lokal besonders wertvoll sein.
RAG spart Kontext
Statt:
50.000 Seiten Dokumentation
↓
komplett in Prompt
nutzt RAG:
Frage
↓
relevante Passagen suchen
↓
nur relevante Abschnitte
↓
LLM
Dadurch reduziert man:
Kontextgröße,
Rechenzeit,
Speicherbedarf.
Lokales RAG ist besonders interessant
Ein vollständiges lokales Wissenssystem könnte aussehen wie:
interne Dokumente
↓
lokales Embeddingmodell
↓
lokale Vektordatenbank
↓
lokales Sprachmodell
↓
Antwort
Damit müssen weder:
Dokumente
noch:
Suchanfragen
noch:
Antwortgenerierung
zwingend einen externen KI-Dienst verwenden.
Embeddings sind häufig deutlich leichter als große LLMs
Ein Embeddingmodell erzeugt Vektoren.
Es muss keinen langen Text generieren.
Solche Modelle sind häufig deutlich kleiner und ressourcenschonender als große generative Sprachmodelle.
Dadurch kann man beispielsweise:
Embeddings
→ CPU oder kleine GPU
und:
Generation
→ große GPU
trennen.
Lokale KI muss nicht aus einem einzigen Modell bestehen
Eine Architektur kann beispielsweise verwenden:
kleines Modell
→ Klassifikation
Embeddingmodell
→ Suche
größeres Sprachmodell
→ Textgenerierung
Bildmodell
→ Bilder
Alle können lokal laufen.
Oder nur einzelne davon.
Hybrid ist häufig sinnvoller als „alles lokal oder alles Cloud“
Beispiel:
sensible interne Dokumente
→ lokales Modell
aber:
öffentliche Webrecherche
→ Cloud-Suchdienst
oder:
einfache Massenklassifikation
→ lokal
seltene komplizierte Analyse
→ leistungsfähiges Cloudmodell
Damit kann man Kosten, Datenschutz und Qualität gegeneinander abwägen.
Lokale KI muss nicht die Cloud vollständig ersetzen
Diese Schwarz-Weiß-Frage ist oft wenig hilfreich:
Lokal oder Cloud?
Sinnvoller:
Welche Aufgabe?
Welche Daten?
Welche Qualitätsanforderung?
Welche Geschwindigkeit?
Welche Kosten?
Dann kann pro Aufgabe entschieden werden.
Modellqualität bleibt ein entscheidender Faktor
Ein lokales Modell kann:
privater,
billiger pro zusätzlicher Anfrage
und:
vollständig kontrollierbar
sein.
Wenn es die Aufgabe aber deutlich schlechter löst, ist das möglicherweise kein guter Tausch.
Deshalb:
lokal
≠
automatisch besser
Cloudmodelle besitzen häufig einen Skalierungsvorteil
Ein Cloudanbieter betreibt sehr leistungsfähige Infrastruktur.
Du sendest:
eine Anfrage
oder:
zehntausende.
Der Anbieter skaliert einen großen Teil der Infrastruktur.
Lokal besitzt du beispielsweise:
1 GPU
Dann ist ihre Rechenleistung deine harte Grenze.
Lokale Skalierung muss selbst geplant werden
Eine Anfrage:
kein Problem.
Hundert gleichzeitige:
Queue.
Tausend:
möglicherweise mehrere GPUs oder Server.
Anfragen
↓
Queue
↓
GPU Worker
Damit kommen klassische Automatisierungs– und Serverkonzepte zurück.
Tokens pro Sekunde sind eine wichtige Leistungskennzahl
Ein Sprachmodell erzeugt Text Token für Token.
Die Geschwindigkeit wird häufig ungefähr beschrieben als:
Tokens pro Sekunde
Zum Beispiel:
10 Tokens/s
oder:
50 Tokens/s
Je höher:
desto schneller wächst die sichtbare Antwort.
Tokens pro Sekunde erzählen aber nicht die ganze Geschichte
Eine Anfrage besitzt zwei grobe Phasen:
Prompt verarbeiten
und:
Antwort erzeugen
Ein riesiger Prompt kann lange verarbeitet werden, bevor überhaupt das erste Antworttoken erscheint.
Deshalb sind zusätzlich relevant:
Zeit bis zum ersten Token
Prompt-Verarbeitungsgeschwindigkeit
Generierungsgeschwindigkeit
Ein interaktiver Chat braucht andere Performance als Batchverarbeitung
Chat:
Der Nutzer wartet.
niedrige Latenz
→ wichtig
Nächtlicher Klassifikationsjob:
100.000 Dokumente
→ Gesamtdurchsatz wichtiger
Die optimale Hardware kann deshalb unterschiedlich aussehen.
Batchverarbeitung kann GPUs effizienter auslasten
Statt immer:
eine Anfrage
können bestimmte Inference-Systeme mehrere Anfragen gemeinsam verarbeiten.
Das verbessert möglicherweise den Gesamtdurchsatz.
Aber:
höherer Batch
kann zusätzlichen Speicher benötigen.
Wieder entsteht ein Trade-off:
Durchsatz
↔
Speicher
↔
Latenz
Ein lokaler Server kann mehrere Nutzer bedienen
Lokale KI bedeutet nicht:
nur eine Person sitzt vor einem PC.
Man kann einen zentralen Server betreiben.
Mitarbeiter A ─┐
Mitarbeiter B ─┼→ lokaler KI-Server
Mitarbeiter C ─┘
Dieser stellt beispielsweise eine interne API bereit.
Das Modell kann über HTTP angesprochen werden
Architektur:
Anwendung
↓
HTTP API
↓
lokaler KI-Server
↓
Inference Engine
↓
Modell
Damit verhält sich lokale KI für andere Anwendungen ähnlich wie ein Cloud-Dienst.
Das ist für Automatisierung enorm praktisch
n8n muss nicht verstehen:
welche GPU,
welches Dateiformat,
welche Inference Engine
verwendet wird.
Es ruft einfach:
lokale KI-API
auf.
Beispiel:
n8n
↓
POST /generate
↓
lokaler KI-Server
↓
Antwort
Dadurch bleibt die Architektur modular
Heute läuft:
Modell A.
Morgen:
Modell B.
Wenn die interne API gleich bleibt:
n8n
→ unverändert
Das reduziert Abhängigkeiten.
Eine lokale API sollte nicht automatisch öffentlich erreichbar sein
Ein häufiger Fehler:
Inference-Server starten.
Er lauscht auf:
alle Netzwerkinterfaces
Firewall offen.
Keine Authentifizierung.
Nun kann möglicherweise jeder im erreichbaren Netzwerk:
Prompts senden,
GPU auslasten,
Daten abrufen.
Ein lokaler KI-Dienst braucht dieselben grundlegenden Sicherheitsüberlegungen wie andere APIs.
Ein interner KI-Server kann hinter einem Reverse Proxy liegen
Zum Beispiel:
Anwendungen
↓
Reverse Proxy
↓
Authentifizierung
↓
KI API
Der Reverse Proxy kann zusätzlich übernehmen:
TLS,
Zugriffsbeschränkung,
Rate Limits,
Logging.
Nicht jeder Nutzer sollte jedes Modell verwenden dürfen
Vielleicht existieren:
kleines allgemeines Modell
großes teures Modell
Modell mit Zugriff auf vertrauliche Dokumente
Dann können unterschiedliche Berechtigungen sinnvoll sein.
Lokale KI kann Multi-Tenant-Probleme haben
Mehrere Abteilungen verwenden denselben Server.
RAG-Daten:
Finanzabteilung.
Personal.
Marketing.
Das Modell selbst sollte nicht entscheiden:
Diese Person darf vermutlich auch Personaldokumente sehen.
Die Retrieval- und Datenbankschicht muss Zugriffe technisch begrenzen.
RAG-Berechtigungen bleiben auch lokal kritisch
Nutzer
↓
Authentifizierung
↓
erlaubte Dokumente filtern
↓
Retrieval
↓
LLM
Nicht:
alle Dokumente abrufen
↓
LLM bitten,
verbotene nicht zu erwähnen
Der Schutz muss vor der Modellgenerierung greifen.
Lokale Embeddings sind nicht automatisch anonym
Ein Vektor sieht ungefähr aus wie:
[0.18, -0.42, 0.73, ...]
Er ist nicht direkt lesbar wie der Originaltext.
Trotzdem stammt er aus den ursprünglichen Daten.
Man sollte ihn deshalb nicht pauschal behandeln als:
harmlos
oder
anonym
Auch lokale Vektordatenbanken brauchen Zugriffs- und Backupkonzepte.
Lokale KI und Agenten
Unser vorheriger Artikel über KI-Agenten lässt sich vollständig lokal denken.
n8n
↓
lokales Agentenmodell
↓
interne Tools
↓
interne Systeme
Das kann sehr interessant sein, wenn der Agent häufig auf interne Daten zugreift.
Lokaler Agent bedeutet trotzdem nicht unbegrenzte Rechte
Er läuft im eigenen Netzwerk.
Deshalb wäre es besonders gefährlich, ihm einfach zu geben:
Shell als root
sämtliche Datenbanken
alle Dateiserver
alle Credentials
Die gleichen Prinzipien gelten:
Least Privilege
Toolgrenzen
Human Approval
Logging
„Lokal“ macht Excessive Agency nicht ungefährlich.
Was ist eine Inference Engine?
Ein Modellfile allein tut nichts.
Es braucht Software, die:
Gewichte lädt,
Tokens verarbeitet,
GPU beziehungsweise CPU ansteuert,
Ausgaben erzeugt.
Diese Software kann man als Inference Engine bezeichnen.
Vereinfacht:
Modell
↓
Inference Engine
↓
Hardware
Unterschiedliche Engines verfolgen unterschiedliche Ziele
Einige sind besonders einfach für Desktopnutzer.
Andere für:
Serverbetrieb,
hohen Durchsatz,
mehrere GPUs,
bestimmte Modellformate.
Die Wahl der Engine hängt deshalb ab von:
einzelner Nutzer?
API-Server?
viele parallele Nutzer?
GPU-Typ?
Modellformat?
Ollama ist ein bekanntes Beispiel
Tools wie Ollama versuchen, das lokale Bereitstellen verschiedener Modelle vergleichsweise unkompliziert zu machen.
Konzeptionell:
Modell auswählen
↓
lokale Laufzeit
↓
lokale API / Anwendung
Für das Verständnis lokaler KI ist aber wichtiger:
Ollama ist nicht das Modell.
Es ist eine Laufzeit beziehungsweise Verwaltungsschicht um Modelle.
Dasselbe Modell kann in unterschiedlichen Umgebungen laufen
Ein Modell kann möglicherweise verwendet werden über:
Desktopsoftware,
Serverengine,
Kommandozeile,
Container.
Die Modellgewichte und die Inference-Software sollten deshalb begrifflich getrennt werden.
Ein lokales Chatprogramm ist wiederum eine weitere Ebene
Chatoberfläche
↓
Inference API
↓
Modell
Die Oberfläche kann Funktionen besitzen wie:
Chatverlauf,
Dateiupload,
RAG,
Benutzerverwaltung.
Diese Funktionen müssen nicht Bestandteil des Modells sein.
Ein Modell „kennt“ deine Dateien nicht automatisch
Du lädst ein Modell lokal herunter.
Es kennt dadurch noch nicht:
deine PDFs,
deine WordPress-Seiten,
deine Firmendokumentation.
Dafür brauchst du beispielsweise:
RAG
oder:
andere Toolanbindung.
Das lokale Modell besitzt nur das Wissen aus seinem Training plus den aktuellen Kontext.
Lokale KI hat dasselbe Aktualitätsproblem wie Cloudmodelle
Ein Modell wurde zu einem bestimmten Zeitpunkt trainiert.
Neuere Informationen kennt es möglicherweise nicht.
Lokalität ändert daran nichts.
Du kannst es aber mit:
RAG,
Websuche,
APIs
mit aktuellen Daten versorgen.
Das ergibt eine leistungsfähige Architektur
lokales Modell
├── internes RAG
├── Websuche
├── Datenbank
├── APIs
└── Tools
Das Modell muss nicht sämtliche Informationen selbst gespeichert haben.
Lokale KI und Fine-Tuning
Open-Weight-Modelle können je nach Lizenz und technischer Eignung zusätzlich angepasst werden.
Zum Beispiel über:
Dabei wird aus:
Basismodell
beispielsweise:
Basismodell
+
LoRA-Adapter
für eine bestimmte Aufgabe.
Fine-Tuning braucht allerdings mehr Hardware als reine Inferenz
Inferenz:
Modell verwenden
Training beziehungsweise Fine-Tuning:
Modellparameter anpassen
Beim Training müssen zusätzlich gespeichert beziehungsweise berechnet werden:
Gradienten,
Aktivierungen,
Optimierungszustände.
Deshalb kann ein Modell problemlos lokal laufen, aber auf derselben Hardware nicht sinnvoll vollständig trainiert werden.
LoRA reduziert diesen Aufwand
Statt alle Parameter zu trainieren:
großes Modell
↓
größtenteils eingefroren
werden kleinere zusätzliche Parameter gelernt.
Damit sinkt der Ressourcenbedarf erheblich.
Lokales Fine-Tuning wird dadurch auf deutlich zugänglicherer Hardware möglich.
QLoRA geht noch einen Schritt weiter
Dabei kann das Basismodell quantisiert gehalten werden, während kleine Adapter trainiert werden.
Vereinfacht:
quantisiertes Basismodell
+
LoRA
↓
ressourcenschonenderes Fine-Tuning
Das ändert trotzdem nichts an der Grundregel:
Vor Fine-Tuning zuerst prüfen, ob Prompting oder RAG das Problem einfacher lösen.
Lokale KI kann laufende API-Kosten reduzieren
Bei Cloud-KI entstehen häufig variable Kosten:
Anfrage
×
Tokens
×
Preis
Lokal:
Hardware
+
Strom
+
Betrieb
Danach kostet die zusätzliche Anfrage nicht unmittelbar einen separaten Anbieterpreis.
Aber lokal ist nicht kostenlos
Man bezahlt:
Grafikkarte,
Rechner,
Strom,
Speicher,
Kühlung,
Wartung,
Arbeitszeit.
Vielleicht auch:
Ersatzhardware.
Die richtige wirtschaftliche Rechnung lautet daher nicht:
Cloud kostet Geld.
Lokal kostenlos.
Sondern:
Cloudkosten
vs.
Gesamtkosten lokaler Infrastruktur
Nutzungsmenge verändert die Rechnung
Du stellst:
20 KI-Fragen im Monat.
Eigener GPU-Server nur dafür:
wirtschaftlich wahrscheinlich fragwürdig.
Du verarbeitest:
Millionen Tokens täglich.
Dann kann lokale Infrastruktur deutlich interessanter werden.
Hardware besitzt Fixkosten
Cloud:
wenig Nutzung
→ geringe Kosten
Lokal:
GPU gekauft
→ Kosten bereits entstanden
Darum lohnt sich lokale Hardware besonders, wenn sie tatsächlich verwendet wird.
Stromverbrauch spielt ebenfalls eine Rolle
Eine leistungsfähige GPU kann unter Last erheblich Strom verbrauchen.
Bei:
24 Stunden täglich
und:
mehreren GPUs
wird das Teil der Betriebskosten.
Andererseits muss ein Server nicht permanent maximale Leistung aufnehmen.
Verbrauch hängt von:
Hardware,
Auslastung,
Power Limits
ab.
Idle-Verbrauch ist ebenfalls relevant
Ein Server wartet 90 Prozent des Tages.
Dann ist nicht nur die maximale GPU-Leistung interessant.
Sondern:
Wie viel Strom braucht das System im Leerlauf?
Für einen Heim- oder Kleinunternehmensserver kann das wirtschaftlich wichtig sein.
Cloud besitzt dafür eine andere Stärke
Wenn nur gelegentlich viel Leistung benötigt wird:
Cloud
→ Ressourcen bei Bedarf
Eine lokale GPU:
steht auch herum,
wenn nichts zu tun ist
Deshalb kann ein hybrides Modell wirtschaftlich attraktiv sein.
Lokale KI besitzt keine automatisch unbegrenzte Nutzung
Die theoretische Zahl der Anfragen ist nicht tariflich begrenzt.
Aber Hardware ist begrenzt.
Wenn 20 Nutzer gleichzeitig ein großes Modell verwenden:
Warteschlange
entsteht.
Damit hat lokal statt eines:
API Rate Limits
ein:
Hardware Capacity Limit
Das Problem verschwindet nicht.
Es verändert seine Form.
Kapazität kann über Queues gesteuert werden
Anfrage 1
Anfrage 2
Anfrage 3
...
↓
KI-Queue
↓
GPU
n8n oder ein anderer Orchestrator kann dafür sorgen, dass nur eine kontrollierte Zahl paralleler Aufgaben auf den KI-Server trifft.
Interaktive Nutzer brauchen Priorisierung
Ein nächtlicher Batchjob verarbeitet:
50.000 Artikel.
Gleichzeitig möchte ein Mensch eine Chatfrage stellen.
Wenn der Batch alle GPU-Ressourcen blockiert:
schlechte Nutzererfahrung.
Daher können getrennte Queues sinnvoll sein:
interactive
→ hohe Priorität
batch
→ niedrige Priorität
Mehrere Modelle teilen sich denselben VRAM
Ein Server soll gleichzeitig laden:
Sprachmodell A.
Embeddingmodell.
Bildmodell.
Vielleicht passen nicht alle gleichzeitig in die GPU.
Dann entstehen Strategien:
Modelle bei Bedarf laden,
bestimmte Modelle auf CPU,
mehrere GPUs,
separate Server.
Modellwechsel kostet Zeit
Wenn ein großes Modell aus dem VRAM entfernt und ein anderes geladen werden muss:
Modell A raus
↓
Modell B laden
kann das Sekunden oder länger dauern.
Bei häufig wechselnden Aufgaben wird das relevant.
Ein Server kann Rollen auf verschiedene GPUs verteilen
Beispielsweise:
GPU 1
→ Textmodell
GPU 2
→ Bildmodell
oder:
GPU 1
→ interaktive Anfragen
GPU 2
→ Batchjobs
Je nach Software und Hardware sind unterschiedliche Konzepte möglich.
Mehrere GPUs ergeben nicht automatisch einen gemeinsamen großen VRAM-Pool
Das ist ein wichtiger Punkt.
Zwei Grafikkarten mit:
je 16 GB
bedeuten nicht zwangsläufig:
eine einfache 32-GB-GPU
Software kann Modelle je nach Engine über mehrere GPUs verteilen.
Aber:
Speicher,
Datenübertragung,
Modellarchitektur
müssen berücksichtigt werden.
Multi-GPU ist komplexer als:
16 + 16 = 32
Manchmal sind zwei GPUs trotzdem ausgesprochen nützlich
Sie können:
verschiedene Modelle parallel bedienen,
mehrere Worker ermöglichen,
ein Modell verteilen,
unterschiedliche Aufgaben trennen.
Welche Variante sinnvoll ist, behandeln wir ausführlicher unter:
/wissen/ki-hardware/
und:
/wissen/lokaler-ki-server/.
PCIe spielt bei Multi-GPU eine Rolle
Wenn Daten häufig zwischen:
CPU,
GPU 1,
GPU 2
übertragen werden, wird die Verbindung relevant.
Dafür dient unter anderem:
PCI Express.
Nicht jede Anwendung benötigt maximale PCIe-Bandbreite.
Bei bestimmten Offloading- und Multi-GPU-Szenarien kann sie aber wichtig werden.
Das Mainboard wird damit Teil der KI-Hardware
Eine zweite GPU benötigt:
Steckplatz,
ausreichend Platz,
PCIe-Lanes,
Strom,
Kühlung.
Darum ist ein lokaler KI-Server mehr als:
Ich kaufe eine starke Grafikkarte.
Das gesamte System muss zusammenpassen.
Netzteil nicht vergessen
Eine oder mehrere GPUs können große Lastspitzen erzeugen.
Das Netzteil muss ausreichend dimensioniert sein.
Relevant sind:
Gesamtleistung,
Anschlüsse,
Qualität,
Reserven.
Ein zu knapp dimensioniertes Netzteil kann Instabilität verursachen.
Kühlung wird unter Dauerlast wichtig
Gaming:
hohe Last für einige Stunden.
KI-Server:
möglicherweise stundenlange oder dauerhafte Auslastung.
Daher:
Luftstrom
ist wichtig.
Ebenso:
GPU-Temperatur,
CPU-Temperatur,
Gehäusegröße.
Lautstärke kann bei Heimservern relevant sein
Ein Rechenzentrum interessiert weniger, ob die GPU-Lüfter laut sind.
Ein Server neben dem Schreibtisch:
sehr wohl.
Darum kann lokale KI auch eine physische Frage sein:
Wo steht der Rechner?
Wie laut darf er sein?
Wie viel Wärme erzeugt er?
SSD-Speicher wird schnell knapp
Modelle können mehrere Gigabyte groß sein.
Du testest:
20 Modelle.
Dazu:
mehrere Quantisierungen.
Bildmodelle.
Embeddings.
Datenbanken.
Plötzlich sind:
1 TB
gar nicht mehr besonders viel.
Modellbibliotheken brauchen Speicherplanung
Beispiel:
Modell A
→ 5 GB
Modell B
→ 10 GB
Modell C
→ 40 GB
mehrere Varianten davon.
Dazu:
Dokumente,
Backups.
Ein KI-Server profitiert deshalb häufig von ausreichendem schnellen SSD-Speicher.
SSD-Geschwindigkeit beeinflusst Modellladezeiten
Das Modell wird vom Datenträger in:
RAM
beziehungsweise:
VRAM
geladen.
Schneller Speicher verkürzt insbesondere das Laden großer Modelle.
Während das Modell vollständig im Speicher liegt, wird der Datenträger für die eigentliche Tokenberechnung deutlich weniger wichtig.
Modelle gehören in ein Versionsmanagement-Konzept
Du hast:
model-a-q4
model-a-q6
model-b-q4
Welches davon läuft produktiv?
Welche Anwendung verwendet welche Version?
Ein lokaler KI-Betrieb sollte diese Informationen dokumentieren.
Modellnamen allein reichen irgendwann nicht
Besser:
Service:
support-classifier
Model:
model-a
Quantisierung:
Q4
Version:
2026-08
Prompt:
v12
Dann kann ein Ergebnis später nachvollzogen werden.
Lokale KI braucht Monitoring
Wichtige Messwerte können sein:
GPU-Auslastung
VRAM-Nutzung
RAM
CPU
Temperaturen
Anfragen pro Minute
Queue-Länge
Fehlerrate
Tokens pro Sekunde
Nur dann weiß man:
Ist die Hardware ausreichend?
Ohne Monitoring wird Hardwareplanung zur Vermutung
Nutzer beschweren sich:
KI ist manchmal langsam.
Warum?
GPU voll?
VRAM voll?
Queue lang?
Modellwechsel?
Riesige Prompts?
CPU-Offload?
Ohne Daten kann man nur raten.
Logs sind ebenfalls wichtig
Beispielsweise:
request_id
model
input_tokens
output_tokens
duration
status
Aber:
Nicht zwangsläufig vollständige Prompts dauerhaft speichern.
Sie können sensible Daten enthalten.
Lokale KI braucht ein Logging-Konzept
Mögliche Stufen:
Metadaten loggen
Inhalte nicht loggen
oder:
Inhalte nur für Debugging
mit kurzer Aufbewahrung
oder:
bestimmte sensible Workflows
überhaupt nicht inhaltlich loggen
Das sollte bewusst entschieden werden.
Backups bei lokalen Modellen
Modellgewichte lassen sich häufig erneut herunterladen.
Sie müssen also nicht zwingend genauso behandelt werden wie einmalige Geschäftsdaten.
Wichtiger können sein:
eigene Fine-Tunes,
LoRA-Adapter,
Konfiguration,
Prompts,
Workflowdaten,
RAG-Dokumente,
Vektordatenbank.
Wiederherstellbarkeit ist die entscheidende Frage
Frag:
Wenn dieser Server heute stirbt, was kann ich nicht einfach neu erzeugen?
Diese Daten müssen besonders zuverlässig gesichert werden.
Zum Beispiel:
eigene Trainingsdaten
eigene LoRA-Adapter
Workflowkonfiguration
Datenbank
Dokumente
Ein Vektorindex kann eventuell neu aufgebaut werden
Wenn vorhanden sind:
Originaldokumente,
Chunkinglogik,
Embeddingmodell,
Modellversion.
Dann kann man:
Dokumente
↓
neu embeddieren
↓
Vector Index neu erstellen
Das kostet Zeit.
Aber der Index ist möglicherweise reproduzierbar.
Das Modell selbst kann ebenfalls ersetzbar sein
Wenn öffentlich wieder downloadbar.
Trotzdem kann es sinnvoll sein:
Produktionsversionen lokal zu archivieren.
Denn Modelle können später:
verschoben,
ersetzt,
nicht mehr verfügbar
sein.
Lokale KI braucht Updates
Nicht nur Modelle.
Auch:
Inference Engine,
GPU-Treiber,
Container,
Betriebssystem,
Weboberfläche.
Updates können:
Sicherheitslücken schließen
aber auch:
Kompatibilität verändern.
Produktive Systeme sollten nicht jedes Update sofort blind übernehmen
Besser:
neue Version
↓
Test
↓
Benchmark
↓
Produktiv
Denn eine Änderung kann beeinflussen:
Geschwindigkeit,
Speicherbedarf,
Modelloutput,
API-Kompatibilität.
Container können lokale KI-Dienste trennen
Zum Beispiel:
Docker Host
│
├── n8n
├── AI API
├── Vector DB
├── PostgreSQL
└── Monitoring
Jeder Dienst besitzt:
eigene Abhängigkeiten.
Das vereinfacht Betrieb und Updates.
Die GPU muss allerdings an Container durchgereicht werden
Ein Container sieht eine GPU nicht automatisch in jeder Umgebung.
Die Hostkonfiguration muss:
Treiber
und:
GPU-Zugriff
bereitstellen.
Containerisierung abstrahiert Software.
Nicht die physische Hardware vollständig.
Ein KI-Service sollte eine klare API besitzen
Zum Beispiel:
POST /chat
POST /embedding
GET /health
Andere Systeme müssen nicht wissen:
welche Inference Engine
dahinter läuft.
Health Checks sind wichtig
Ein Orchestrator fragt:
GET /health
Antwort:
ready
oder:
not_ready
Damit kann ein Workflow vermeiden, Anfragen an einen noch ladenden oder defekten KI-Dienst zu schicken.
Readiness und Liveness sind unterschiedliche Konzepte
Ein Prozess kann:
laufen
aber:
noch kein Modell geladen haben.
Dann ist er:
alive
aber nicht:
ready
Diese Unterscheidung wird besonders bei containerisierten Serverdiensten nützlich.
Lokale KI sollte über Queues entkoppelt werden können
Direkt:
n8n
↓
KI
funktioniert bei kleinen Anwendungen gut.
Bei langen Batchjobs:
n8n
↓
Queue
↓
KI Worker
kann robuster sein.
Dann bleibt die Automatisierung nicht minutenlang an einer offenen HTTP-Verbindung hängen.
Das passt zu asynchronen Workflows
Job erstellen
↓
job_id
↓
Queue
↓
KI verarbeitet
↓
Ergebnis gespeichert
↓
Webhook / Event
↓
Workflow weiter
Besonders für:
lange Texte,
Bildgenerierung,
große Dokumentmengen
ist das interessant.
Ein lokaler KI-Server kann mehrere spezialisierte Dienste haben
Zum Beispiel:
ai-text
ai-embedding
ai-image
ai-reranker
Der Orchestrator ruft jeweils den passenden Dienst auf.
Das verhindert, dass ein einziger riesiger Prozess alles erledigen muss.
Oder ein Gateway kann davor liegen
Anwendung
↓
AI Gateway
↓
├── Textmodell
├── Embeddings
├── Reranker
└── Cloud-Fallback
Das Gateway entscheidet:
welcher Backenddienst verwendet wird.
Dadurch bleiben Anwendungen unabhängig vom konkreten Modell.
Ein Gateway kann auch Datenschutzregeln erzwingen
Beispiel:
data_classification = confidential
↓
nur lokales Modell
data_classification = public
↓
lokal oder Cloud
Das ist stärker als:
Das Sprachmodell soll selbst entscheiden, ob Daten vertraulich sind.
Kosten können ebenfalls geroutet werden
einfache Aufgabe
↓
kleines lokales Modell
komplizierte Aufgabe
↓
großes lokales Modell
Sonderfall
↓
Cloudmodell
Damit entsteht ein KI-Router.
Modellrouting sollte gemessen werden
Nicht:
Das kleine Modell wird schon reichen.
Sondern:
Testset.
Qualität.
Latenz.
Kosten.
Dann wird entschieden:
Welche Aufgaben gehen wohin?
Lokale KI kann für Massenaufgaben besonders attraktiv sein
Zum Beispiel:
Millionen Texte:
klassifizieren.
Embeddings erzeugen.
Metadaten extrahieren.
Wenn das Modell klein genug ist, kann eine lokale GPU kontinuierlich arbeiten.
Der Grenzkostenpreis pro weiterem Dokument kann dann attraktiv werden.
Generative Langtexte sind anspruchsvoller
Je mehr Output-Tokens erzeugt werden:
desto mehr Rechenzeit.
Ein Artikel mit:
3.000 Wörtern
belegt die GPU wesentlich länger als eine Klassifikation mit:
category = support
Darum sollten verschiedene Aufgaben wirtschaftlich getrennt betrachtet werden.
Kleine Modelle sind für Automatisierung oft unterschätzt
Eine Aufgabe lautet:
E-Mail
→ eine von 8 Kategorien
Dafür braucht man möglicherweise kein riesiges Modell.
Ein kleines spezialisiertes Modell kann:
schneller,
billiger,
speichersparender
sein.
Große Modelle können als Eskalationsstufe dienen
kleines Modell
↓
eindeutig?
├── ja → fertig
└── nein → großes Modell
Das ist eine starke Architektur für lokale Systeme.
Man kann sogar ohne generatives Modell beginnen
Für bestimmte Aufgaben reichen:
Embeddings,
klassische Regeln,
Datenbankabfragen.
Beispiel:
Artikel
↓
Embedding
↓
ähnliche Artikel
Dafür muss kein großes LLM Text generieren.
Lokale KI sollte nicht mit:
überall LLM
gleichgesetzt werden.
Klassische Machine-Learning-Modelle gehören ebenfalls zu lokaler KI
Bildklassifikation.
Spracherkennung.
Objekterkennung.
Textklassifikation.
Der Begriff lokale KI ist viel breiter als lokale Chatbots.
In unserem Cluster konzentrieren wir uns jedoch vor allem auf:
generative KI,
Embeddings,
Automatisierung.
Auch Bild-KI kann lokal laufen
Text-to-Image-Modelle besitzen eigene Hardwareanforderungen.
Dabei ist ebenfalls VRAM wichtig.
Aber Architektur und Speicherbedarf unterscheiden sich von Sprachmodellen.
Das behandeln wir später innerhalb unseres Bereichs:
Design & Medien beziehungsweise Bild-KI.
Lokale Spracherkennung ist ein weiterer spannender Fall
Audio:
lokal
↓
Speech-to-Text
↓
Transkript
danach:
lokales LLM
↓
Zusammenfassung
Damit könnten beispielsweise vertrauliche Besprechungen ohne externen KI-Dienst verarbeitet werden.
Lokale KI eignet sich hervorragend für Automatisierung im eigenen Netzwerk
Beispiel:
Dokumentordner
↓
Webhook / Watcher
↓
n8n
↓
lokale OCR / Textanalyse
↓
lokales LLM
↓
Datenbank
Die Daten müssen die eigene Umgebung nicht verlassen.
Aber ein eigener Server braucht Zugriffsschutz
Mitarbeiter A darf:
Projekt A.
Mitarbeiter B:
Projekt B.
Der zentrale KI-Server darf nicht einfach:
jeder Nutzer
→ alle Prompts und Dokumente
sehen lassen.
Benutzeridentität muss bis in:
RAG,
Tools,
Datenbank
weitergereicht werden.
Lokale KI ist daher auch IAM
IAM steht für:
Identity and Access Management.
Praktische Fragen:
Wer darf sich anmelden?
Welches Modell?
Welche Dokumente?
Welche Tools?
Welche Aktionen?
Lokale KI wird im produktiven Einsatz schnell zu klassischer IT-Infrastruktur.
Ein Heimserver kann einfacher sein
Eine Person.
Ein Netzwerk.
Keine fremden Nutzer.
Dann braucht man nicht sofort ein Enterprise-IAM-System.
Trotzdem sollten zumindest:
Firewall,
Updates,
starke Zugänge
vorhanden sein.
Architektur sollte zur tatsächlichen Risikolage passen.
Lokale KI über VPN
Ein interessanter Aufbau:
Notebook unterwegs
↓
VPN
↓
Heim- oder Firmenserver
↓
lokale KI
Damit kann ein leistungsfähiger Rechner an einem Ort stehen.
Andere Geräte greifen sicher darauf zu.
Das ist häufig sinnvoller als auf jedem Laptop ein großes Modell zu installieren.
Das Smartphone braucht dann keine starke KI-Hardware
Es sendet nur:
Prompt
an deinen Server.
Smartphone
↓
VPN / HTTPS
↓
KI-Server
↓
Antwort
Rechenarbeit findet zentral statt.
Ein zentraler Server vereinfacht Modellpflege
Statt:
fünf Rechner
mit fünf unterschiedlichen Modellversionen:
ein KI-Server
↓
eine kontrollierte Modellversion
Das erleichtert:
Updates,
Monitoring,
Backups.
Allerdings entsteht ein Single Point of Failure
Server aus:
alle Nutzer ohne lokale KI.
Bei geschäftskritischer Nutzung braucht es daher möglicherweise:
Redundanz
oder:
Fallback.
Cloud kann ein Fallback sein
lokaler Server verfügbar?
├── ja → lokal
└── nein → Cloud
Aber nur, wenn:
Daten die Cloud verlassen dürfen.
Ein automatischer Fallback darf Datenschutzregeln nicht umgehen.
Ein zweiter lokaler Server kann ebenfalls Fallback sein
KI Server A
↓
Fehler
↓
KI Server B
Das erhöht Zuverlässigkeit.
Aber verdoppelt einen Teil der Infrastrukturkosten.
Für Hobbybetrieb unnötig.
Für zentrale Unternehmensprozesse eventuell interessant.
Lokale KI ist besonders attraktiv für Entwicklungsumgebungen
Du kannst:
Modelle ausprobieren,
API testen,
Prompts optimieren,
RAG bauen
ohne für jeden Test einen externen API-Aufruf zu bezahlen.
Das lädt zum Experimentieren ein.
Aber Benchmarks sollten realistisch sein
Ein Modell beantwortet:
Was ist die Hauptstadt von Frankreich?
korrekt.
Das beweist wenig für deinen Anwendungsfall.
Test lieber:
deine echten Aufgaben.
Supportklassifikation
Dokumentenextraktion
deutsche Fachtexte
lange Kontexte
Lokale Modelle brauchen eigene Evals
Vergleiche zum Beispiel:
lokales Modell A
lokales Modell B
Cloudmodell C
auf demselben Testset.
Messen:
Qualität
Halluzinationen
Formatfehler
Geschwindigkeit
Speicher
Kosten
Erst dann weißt du, welches Modell geeignet ist.
Modellgröße alleine ist kein Benchmark
70B
sieht beeindruckender aus als:
8B
Aber wenn die konkrete Aufgabe:
strukturierte Klassifikation
ist, kann das 8B-Modell völlig ausreichen.
Dann wäre 70B nur:
langsamer,
teurer,
speicherhungriger.
Große Modelle besitzen trotzdem Vorteile
Komplexere:
Argumentation,
Schreibaufgaben,
mehrdeutige Anfragen
profitieren häufig von leistungsfähigeren Modellen.
Darum ist ein Modellportfolio oft sinnvoller als:
ein Modell für alles.
Ein lokales Modellportfolio
Zum Beispiel:
Embeddingmodell
→ Suche
kleines LLM
→ Klassifikation
mittleres LLM
→ Standardtexte
großes LLM
→ komplexe Analyse
Die Anwendungen wählen je nach Aufgabe.
n8n eignet sich hervorragend als Router
Aufgabe
↓
n8n
↓
Switch
├── Klassifikation → kleines Modell
├── Recherche → RAG
├── Text → großes Modell
└── Bild → Bildserver
So verbinden sich lokale KI und Automatisierung direkt.
Agenten können ebenfalls Modellrouting nutzen
Ein Agent könnte für manche Teilaufgaben andere Dienste aufrufen.
Aber:
Welches Modell aus Datenschutz- oder Kostengründen erlaubt ist, sollte möglichst durch die Orchestrierung kontrolliert werden.
Nicht nur durch Modellentscheidung.
Lokale KI kann auch Suchmaschinenfunktionen übernehmen
Beispiel Casiopeya:
Artikel
↓
lokale Embeddings
↓
Vektordatenbank
Besucher fragt:
Warum ist meine WordPress-Seite trotz Cache langsam?
System findet:
WordPress Performance
Caching
Bilder optimieren
CDN
Core Web Vitals
Das kann anschließend:
nur Suchergebnisse anzeigen
oder:
eine RAG-Antwort erzeugen.
Das LLM muss dafür nicht öffentlich im Internet laufen
Man könnte:
Frontend
und:
lokalen beziehungsweise eigenen Server
verbinden.
casiopeya.de
↓
eigene API
↓
KI-Server
Der eigentliche Modellserver kann hinter einer kontrollierten Schnittstelle liegen.
Öffentliche KI-Funktionen brauchen Missbrauchsschutz
Wenn jeder Besucher kostenlos dein lokales Modell aufrufen kann:
Bots könnten:
Millionen Requests
senden.
Deine GPU wäre ausgelastet.
Darum braucht eine öffentliche Schnittstelle:
Rate Limits
Request Limits
Authentifizierung oder Captcha je nach Anwendung
Kostenkontrolle
Auch wenn keine API-Tokens eines Cloudanbieters verbraucht werden.
Promptlänge sollte begrenzt werden
Ein Angreifer sendet:
riesige Eingabe.
Dein Modell verarbeitet:
hunderttausende Tokens.
GPU minutenlang blockiert.
Deshalb können Server definieren:
max_input_tokens
und:
max_output_tokens
Ressourcenschutz ist Teil der Sicherheit.
Outputlänge ebenfalls
Ein Nutzer verlangt:
Schreibe zehn Millionen Wörter.
Wenn keine Grenze besteht, läuft die Generierung sehr lange.
Das ist nicht sinnvoll.
Der Server braucht technische Limits.
Lokale Agenten brauchen zusätzliche Aktionslimits
max_steps
max_runtime
max_tool_calls
Sonst kann eine Agentenschleife lokale Ressourcen blockieren.
Die Grundprinzipien unseres Agentenartikels gelten unverändert.
Ein lokaler KI-Server kann containerisiert sein
Beispielsweise:
Docker Host
│
├── n8n
├── AI Gateway
├── LLM Server
├── Vector DB
├── PostgreSQL
└── Monitoring
Das ist eine sehr flexible Architektur.
Aber:
Nicht alles muss von Anfang an vorhanden sein.
Der einfachste Einstieg kann sehr klein sein
Desktop-PC
↓
Inference Software
↓
kleines quantisiertes Modell
Fertig.
Damit lernst du bereits:
Modell laden,
Prompt senden,
Geschwindigkeit vergleichen.
Dann kann man schrittweise erweitern
Stufe 1:
lokaler Chat
Stufe 2:
lokale API
Stufe 3:
n8n-Anbindung
Stufe 4:
lokales RAG
Stufe 5:
Agenten / mehrere Modelle
Das ist sinnvoller, als sofort eine komplette KI-Plattform aufzubauen.
Ein guter erster lokaler Test
Nimm eine klar definierte Aufgabe.
Zum Beispiel:
E-Mail
↓
Kategorie
Dann teste:
kleines lokales Modell.
Miss:
Qualität.
Geschwindigkeit.
RAM.
VRAM.
Nun hast du reale Daten.
Danach größere Modelle testen
Wenn das kleine Modell:
zu unzuverlässig
ist, probiere ein größeres.
Nicht andersherum:
größtes Modell kaufen
↓
später überlegen,
was man damit macht
Hardware sollte aus Anwendung entstehen.
Das gilt besonders bei GPUs
Die wichtigste Frage ist nicht:
Welche ist die schnellste Grafikkarte?
Sondern:
Welche Modelle sollen mit welcher Geschwindigkeit und welchem Kontext laufen?
Daraus ergibt sich der benötigte:
VRAM,
Durchsatz,
Strombedarf.
Der nächste Artikel wird genau diese Frage systematisch beantworten
Unter:
/wissen/ki-hardware/
schauen wir uns an:
CPU,
GPU,
RAM,
VRAM,
SSD,
PCIe,
Netzteil,
Kühlung
und mehrere GPUs.
Damit kann lokale KI-Hardware sinnvoll dimensioniert werden.
Ein lokaler KI-Server ist nicht automatisch ein Server im klassischen Rack
Er kann ein normaler Desktop-PC sein.
„Server“ beschreibt zunächst seine Funktion:
anderen Anwendungen
einen KI-Dienst bereitstellen
Nicht zwingend die Gehäuseform.
Ein alter Gaming-PC kann bereits ein KI-Server sein
Wenn:
ausreichend RAM,
brauchbare GPU,
genügend Speicher
vorhanden sind.
Vielleicht ist er nicht besonders energieeffizient.
Aber zum Experimentieren kann vorhandene Hardware hervorragend sein.
Ein Notebook kann lokale KI ausführen
Allerdings bestehen mögliche Grenzen:
weniger Kühlung,
weniger aufrüstbarer VRAM,
begrenzte Dauerlast.
Für gelegentliche Nutzung trotzdem völlig ausreichend.
Apple-Silicon-Systeme verfolgen eine andere Speicherarchitektur
Dort teilen CPU und GPU je nach Plattform einen gemeinsamen Speicherbereich.
Das unterscheidet sich von klassischen PCs mit:
System-RAM
plus:
separatem GPU-VRAM.
Dadurch können bestimmte größere Modelle trotz fehlender dedizierter Grafikkarte lokal interessant sein.
Das sollte aber nicht mit klassischer diskreter GPU-Hardware gleichgesetzt werden.
Unterschiedliche Hardwareplattformen brauchen unterschiedliche Software
Inference-Engines können optimiert sein für:
NVIDIA,
AMD,
Apple Silicon,
CPU.
Ein Modellformat kann auf einer Plattform hervorragend funktionieren und auf einer anderen weniger gut.
Deshalb gehört zur Hardwarewahl immer:
Softwarekompatibilität.
CUDA ist ein wichtiger Grund für die Dominanz bestimmter GPUs im KI-Bereich
Viele KI-Bibliotheken und Werkzeuge wurden stark auf NVIDIAs GPU-Softwareökosystem optimiert.
Das kann die Auswahl kompatibler Tools erleichtern.
Andere Plattformen werden ebenfalls unterstützt, aber nicht jede Software bietet überall denselben Funktionsumfang.
Für einen konkreten Kauf sollte deshalb immer geprüft werden:
Welche Software soll tatsächlich laufen?
Hardware zuerst kaufen und danach Software suchen kann teuer sein
Besser:
Anwendungsfall
↓
Modelle
↓
Inference Engine
↓
Hardwareanforderungen
↓
Hardware
statt:
GPU kaufen
↓
hoffen,
dass alles funktioniert
Dasselbe gilt für Multi-GPU
Ein bestimmtes Tool muss die gewünschte Multi-GPU-Konfiguration unterstützen.
Nur weil zwei Karten im Rechner stecken:
bedeutet das nicht, dass jedes Modell sie automatisch optimal nutzt.
Lokale KI kann extrem leistungsfähig werden
Eine Workstation mit mehreren GPUs kann:
große Sprachmodelle,
Bildmodelle,
Embeddingdienste,
Batchverarbeitung
lokal bereitstellen.
Aber:
Mit jeder zusätzlichen Komponente steigt:
Komplexität.
Deshalb ist ein modularer Aufbau wichtig
Inference Service
↓
klare API
RAG Service
↓
klare API
n8n
↓
Orchestrierung
Monitoring
↓
Messwerte
Dann lässt sich jede Komponente unabhängig weiterentwickeln.
Lokale KI kann Cloud-ähnliche interne Dienste bereitstellen
Ein Unternehmen könnte intern eine API anbieten:
POST /chat
POST /embeddings
POST /classify
Alle Anwendungen greifen darauf zu.
Damit entsteht eine eigene interne KI-Plattform.
Unterschiedliche Abteilungen müssen dann nicht selbst Modelle betreiben
Marketing.
Support.
IT.
Sie rufen dieselbe zentrale Plattform auf.
Das erleichtert:
Governance,
Monitoring,
Modellpflege.
Gleichzeitig muss die Plattform Mandantengrenzen kennen
Supportdaten dürfen vielleicht nicht:
Marketing
sehen.
Personalinformationen nicht:
andere Abteilungen.
Eine zentrale KI-Plattform braucht deshalb eine echte Berechtigungsarchitektur.
Lokal bedeutet volle Kontrolle über Modellversionen
Du kannst sagen:
Produktiv:
Modell A v3
Test:
Modell B v1
Dann A/B vergleichen.
Erst nach erfolgreicher Evaluation wird umgestellt.
Das ist für automatisierte Prozesse sehr wertvoll.
Shadow Testing kann ebenfalls lokal stattfinden
Neue Modellversion läuft parallel.
Produktivanfrage
↓
Modell A
→ echtes Ergebnis
gleichzeitig:
Kopie
↓
Modell B
→ nur Vergleich
Modell B darf nichts auslösen.
Nach genügend Tests wird entschieden.
Lokale Modelle machen solche Tests ohne zusätzliche externe Datenweitergabe möglich
Allerdings:
Sie verbrauchen eigene Rechenleistung.
Wieder ein klassischer Trade-off.
Modellupdates sollten nicht automatisch Qualität voraussetzen
Neuere Version:
vielleicht besser.
Aber:
nicht zwingend für deinen Spezialfall.
Ein Update kann beispielsweise:
anderen Schreibstil,
andere Toolauswahl,
andere Formatstabilität
haben.
Deshalb erneut testen.
Lokale KI eignet sich gut für reproduzierbare Forschung und Experimente
Du kannst exakt dokumentieren:
Modellfile.
Quantisierung.
Engine.
Prompt.
Parameter.
Hardware.
Das erleichtert Vergleichstests.
Temperatur bleibt auch lokal relevant
Ein Sprachmodell kann mit unterschiedlichen Samplingparametern betrieben werden.
Zum Beispiel:
niedrigere Temperatur
→ typischerweise konservativere Auswahl.
Höhere:
→ mehr Variation.
Die genaue Wirkung hängt vom Modell und Sampling-Setup ab.
Lokale KI gibt dir oft direkten Zugriff auf solche Parameter.
Mehr Einstellmöglichkeiten bedeuten nicht automatisch bessere Ergebnisse
Man kann:
Temperature,
Top-p,
Top-k,
Penalty-Werte
verändern.
Wer ohne Teststrategie an allem dreht, macht das System möglicherweise schlechter.
Auch lokal gilt:
Baseline
↓
eine Änderung
↓
messen
Prompt Caching kann bei lokalen Systemen interessant sein
Viele Anfragen besitzen denselben langen Systemprompt.
Bestimmte Inference-Systeme können Teile solcher Vorberechnung wiederverwenden.
Das kann Geschwindigkeit verbessern.
Die konkrete Umsetzung hängt von der Engine ab.
Kontextmanagement wird bei lokalen Agenten besonders wichtig
Ein Agent führt:
30 Toolschritte
aus.
Alle Ergebnisse landen im Kontext.
Irgendwann wird er:
groß,
langsam,
teuer an Rechenzeit.
Dann kann der Orchestrator:
alte Daten zusammenfassen,
irrelevante Ergebnisse entfernen,
wichtige Fakten strukturiert speichern.
Lokale Hardware macht ineffiziente Prompts sichtbar
Cloud:
lange Prompts kosten Geld.
Lokal:
lange Prompts kosten Zeit und GPU-Kapazität.
Beides belohnt effizientes Kontextdesign.
RAG ist damit nicht nur Wissensarchitektur, sondern Performancearchitektur
Weniger irrelevanter Kontext:
weniger Tokens
↓
weniger Rechenarbeit
↓
schnellere Antwort
Das ist lokal besonders spürbar.
Lokale KI braucht eine klare Trennung von Daten und Modell
Modell:
allgemeine trainierte Fähigkeiten
Datenbank:
aktuelle Geschäftsdata
RAG:
Dokumentwissen
API:
aktueller Systemzustand
Memory:
persistenter Agentenzustand
Diese Rollen sollten nicht vermischt werden.
Das verhindert falsche Erwartungen
Ein lokales Modell ist nicht automatisch:
CRM,
Dokumentenarchiv,
Suchmaschine,
Datenbank.
Es ist eine Modellkomponente.
Die übrigen Systeme machen daraus eine Anwendung.
Eine starke lokale Gesamtarchitektur
Nutzer / Anwendungen
↓
Authentifizierung
↓
AI Gateway
│
├── kleines LLM
├── großes LLM
├── Embeddings
├── Reranker
└── Bildmodell
↓
Tools / RAG
│
├── Vector DB
├── PostgreSQL
├── WordPress
└── interne APIs
↓
n8n / Orchestrierung
Nicht jede Installation braucht all das.
Aber das Diagramm zeigt, wie weit „lokale KI“ über einen Chat auf dem Desktop hinausgehen kann.
Was du dir über lokale KI merken solltest
Lokale KI bedeutet im Kern, dass die Inferenz eines KI-Modells auf Hardware stattfindet, die du selbst betreibst beziehungsweise kontrollierst.
Vereinfacht:
Cloud-KI
deine Anwendung
↓
Internet
↓
fremder Modellserver
gegen:
lokale KI
deine Anwendung
↓
eigener Modellserver
Dabei bedeutet lokal nicht automatisch:
offline
und auch nicht automatisch:
privat
Ein lokales System kann weiterhin externe:
APIs,
Websuche,
Cloudspeicher
verwenden.
Für tatsächliche Datenkontrolle muss deshalb die gesamte Architektur betrachtet werden.
Lokale KI wird besonders interessant bei Anforderungen wie:
sensible Daten
Offline-Nutzung
hohes Nutzungsvolumen
eigene Modelle
RAG auf internen Dokumenten
Automatisierung
Experimentierfreiheit
geringere Anbieterabhängigkeit
Dafür übernimmt der Betreiber allerdings zusätzliche Verantwortung für:
Hardware
Updates
Sicherheit
Backups
Monitoring
Strom
Skalierung
Ein lokales Sprachmodell ist normalerweise ein bereits trainiertes Modell, dessen Gewichte von einer Inference Engine geladen werden.
Modelldatei
↓
Inference Engine
↓
CPU / GPU
↓
Antwort
Viele lokal verwendbare Modelle werden als Open-Weight-Modelle bereitgestellt.
Das bedeutet nicht automatisch:
vollständig Open Source.
Die konkrete Lizenz bleibt relevant.
Modellgrößen werden häufig ungefähr über Milliarden Parameter beschrieben:
3B
8B
14B
32B
70B
Größere Modelle benötigen normalerweise mehr Speicher und Rechenleistung.
Der tatsächliche Speicherbedarf hängt jedoch stark von der numerischen Darstellung ab.
Deshalb ist Quantisierung so wichtig.
höhere Präzision
↓
mehr Speicher
stärkere Quantisierung
↓
weniger Speicher
möglicherweise verbunden mit einem Qualitätsverlust.
Für lokale Sprachmodelle wird die Hardware deshalb häufig durch eine Ressource bestimmt:
VRAM.
Modell
↓
GPU-Speicher
Passt das Modell vollständig in den VRAM, ist schnelle GPU-Inferenz oft einfacher.
Passt es nicht, können je nach Software Teile über:
RAM,
CPU
oder:
mehrere GPUs
verarbeitet werden.
Das kann funktionieren, aber die Geschwindigkeit verändern.
Auch Kontext kostet Speicher.
mehr Kontexttokens
↓
größerer KV-Cache
↓
mehr Speicherbedarf
Deshalb ist ein Modell, das ohne großen Kontext problemlos passt, nicht automatisch mit maximaler Kontextlänge genauso leicht betreibbar.
Lokale KI eignet sich besonders gut für RAG.
interne Dokumente
↓
lokale Embeddings
↓
Vektordatenbank
↓
lokales LLM
Damit kann eine komplette Wissensabfrage innerhalb der eigenen Infrastruktur stattfinden.
Auch n8n lässt sich mit lokalen Modellen verbinden.
Workflow
↓
lokale KI-API
↓
Modell
Für n8n unterscheidet sich ein gut gekapselter lokaler Dienst konzeptionell kaum von einer externen API.
Das ermöglicht hybride Systeme:
sensible Aufgaben
→ lokal
öffentliche oder besonders komplexe Aufgaben
→ gegebenenfalls Cloud
Ebenso können KI-Agenten lokal betrieben werden.
Aber:
lokal
≠
sicher
Auch ein lokaler Agent braucht:
Least Privilege
Berechtigungen
Toolgrenzen
Input Validation
Human Approval
Logging
Die Infrastruktur sollte deshalb schrittweise wachsen.
Ein sinnvoller Weg lautet:
1. lokales Modell ausprobieren
2. echte Aufgabe testen
3. Qualität und Geschwindigkeit messen
4. API bereitstellen
5. Automatisierung anbinden
6. RAG ergänzen
7. erst dann komplexere Agenten
Das verhindert, dass aus lokaler KI sofort ein unnötig kompliziertes Infrastrukturprojekt wird.
Und es führt direkt zur wichtigsten praktischen Frage:
Welche Hardware braucht man eigentlich dafür?