AI ohne Cloud — was wirklich geht, und was nicht

Ich betreibe lokale KI schon eine Weile — auf dem Raspberry Pi 4, dem Pi 5, und auf meinem MacBook Air M2. Mit Modellen von gemma2:2b bis hin zu deutlich größeren wie llama3:70b auf dem MBA. Und ich kann euch sagen: Erwartung und Realität liegen oft weit auseinander. Sowohl im positiven als auch im negativen Sinn.

Nicht weil lokale KI schlecht ist. Sondern weil die meisten Artikel dazu entweder komplett begeistert sind ("läuft auf dem Pi!") oder komplett ablehnend ("zu langsam, vergiss es"). Die Wahrheit liegt — wie so oft — in der Mitte. Und die Details und vor allem der konkrete Anwendungsfall machen den Unterschied.

Dieser Artikel ist kein Setup-Guide. Den habe ich bereits geschrieben. Das hier ist der Praxistest: was habe ich wirklich damit gemacht, was hat funktioniert, was nicht, und wo liegt die sinnvolle Grenze.

Die ehrliche Erwartung

Bevor wir anfangen, kurz die Ausgangslage klären. Wer mit lokaler KI auf einem Pi oder einem kleinen Mini-PC anfängt, bringt oft eine dieser zwei Erwartungen mit:

Erwartung A: "Ich will komplett unabhängig von Cloud-Diensten sein."
Erwartung B: "Ich will für einfache Aufgaben nicht immer eine Internetverbindung brauchen."

Erwartung B ist realistisch und wird erfüllt. Erwartung A ist eine Haltung — die ich respektiere und teile — aber sie kommt mit Kompromissen. Wer das akzeptiert, wird zufrieden sein. Wer erwartet, dass ein 2B-Modell auf einem Pi das gleiche leistet wie Claude, wird enttäuscht.

graph TD
    A[Erwartung A\nKomplete Cloud-Unabhängigkeit] --> B{Realistisch?}
    C[Erwartung B\nLokal für einfache Tasks] --> B
    B -->|Ja, mit Kompromissen| D[✅ Für bestimmte\nAnwendungsfälle]
    B -->|Nein, für komplexe Tasks| E[⚠️ Cloud bleibt\nnotwendig]

Mit dieser Grundlage gehen wir in den Praxistest.

Was gut funktioniert

Texte zusammenfassen und strukturieren

Das ist der Use Case, der mich am meisten überrascht hat — positiv. Lokale Modelle sind für Zusammenfassungen erstaunlich gut. Nicht perfekt, aber gut genug für den Alltag.

Konkretes Beispiel aus meiner Praxis: Ich lasse längere Logfiles oder Konfigurationsdokumente lokal zusammenfassen. Die Qualität ist für diese Aufgabe völlig ausreichend — und das Wichtige: die Daten verlassen mein Netzwerk nicht.

flowchart TD
    classDef success fill:#14532d,color:#86efac,stroke:#86efac,stroke-width:1.5px
    A[📄 Lokales Dokument\nLogfile / Notizen] --> B[Ollama\ngemma2:2b]
    B --> C[📝 Zusammenfassung\nlokal generiert]
    C --> D[✅ Daten bleiben\nim Netzwerk]
    class D success

Warum es funktioniert: Zusammenfassen ist ein verhältnismäßig einfaches Pattern — das Modell muss keine neuen Ideen entwickeln, sondern vorhandene Informationen verdichten. Das können auch kleine Modelle gut.

Wo es Grenzen hat: Sehr lange Dokumente die das Kontextfenster sprengen. Da muss man aufteilen — was machbar ist, aber den Workflow verkompliziert. Vor allem muss man dabei aufpassen, dass der Kontext aus anderen Abschnitten nicht verloren geht. Eine Zusammenfassung die nur einen Ausschnitt kennt, kann zu falschen Schlüssen führen — das ist ein Fehler der nicht immer sofort auffällt.

Klassifizierung und Kategorisierung

Ebenfalls eine positive Überraschung. Texte kategorisieren, Prioritäten vergeben, einfache Ja/Nein-Entscheidungen treffen — das funktioniert lokal sehr zuverlässig.

In meiner Praxis nutze ich das für:
- Logfile-Einträge nach Schweregrad klassifizieren
- E-Mail-Betreffzeilen vorsortieren (lokal, bevor sie irgendwo hochgeladen werden)
- Einfache Regelprüfungen auf Konfigurationsdateien

Code-Snippets für Standardaufgaben

Bash-Skripte, einfache Python-Funktionen, Regex-Muster — für überschaubare, gut definierte Aufgaben liefert phi3:mini brauchbare Ergebnisse. Nicht immer auf Anhieb korrekt, aber als Ausgangspunkt gut.

Der entscheidende Punkt: ich reviewe jeden generierten Code. Das tue ich bei Claude genauso — wie ich in Artikel 1 geschrieben habe. Die Herkunft des Codes ändert nichts an dieser Pflicht.

Wo es aufhört zu funktionieren: Sobald die Aufgabe Kontext über mehrere Dateien braucht, oder das Modell Framework-spezifisches Wissen benötigt das über sein Training hinausgeht. Da ist der Qualitätsunterschied zu Claude erheblich.

Lokale Dokumentensuche mit RAG

Das ist der aufwändigste Use Case — aber wenn er einmal läuft, einer der nützlichsten. RAG steht für Retrieval-Augmented Generation: eigene Dokumente werden indexiert, und das LLM kann gezielt darin suchen und Fragen beantworten.

flowchart TD
    classDef success fill:#14532d,color:#86efac,stroke:#86efac,stroke-width:1.5px
    A[📚 Lokale Dokumente\nMarkdown, PDF, Text] --> B[Embedding-Modell\nlokal]
    B --> C[(Vektordatenbank\nlokal)]
    D[❓ Frage] --> E[Relevante Chunks\nabrufen]
    C --> E
    E --> F[Ollama LLM\nAntwort generieren]
    F --> G[✅ Antwort\nbasierend auf\neigenen Dokumenten]
    class G success

Ich nutze das für meine eigene Dokumentation — Homelab-Notizen, Konfigurationsreferenzen, Artikel-Entwürfe. Die Qualität hängt stark vom Embedding-Modell und der Chunk-Größe ab, aber der Ansatz funktioniert.

Ehrlicher Aufwand: Die initiale Einrichtung ist nicht trivial. Man sollte etwas Zeit dafür einplanen — hier kann übrigens auch Claude Code hervorragend unterstützen.

Wo lokale Modelle an ihre Grenzen stoßen

Komplexes Reasoning und mehrstufige Aufgaben

Das ist die erwartbare Schwäche kleiner Modelle — und sie zeigt sich deutlich in der Praxis. Wenn eine Aufgabe mehrere Denkschritte erfordert — "analysiere dieses Problem, leite daraus eine Lösung ab, und erkläre warum" — geraten kleine Modelle schnell ins Straucheln.

Das Muster das ich immer wieder sehe: das Modell beginnt vielversprechend, verliert dann den Faden, und landet bei einer Antwort die zwar flüssig klingt aber inhaltlich nicht stimmt. Das ist die "selbstbewusste Falschaussage" die ich in Artikel 1 beschrieben habe — und bei kleinen Modellen ist sie noch ausgeprägter.

graph TD
    classDef danger  fill:#7f1d1d,color:#fca5a5,stroke:#fca5a5,stroke-width:1.5px
    A[Komplexe Aufgabe\nmehrere Schritte] --> B{Modellgröße}
    B -->|Klein 1B-4B| C[⚠️ Verliert Faden\nnach 2-3 Schritten]
    B -->|Groß 70B+| D[✅ Hält Kontext\nüber viele Schritte]
    C --> E[Plausibel klingende\naber falsche Antwort]
    D --> F[Zuverlässige\nmehrstufige Antwort]
    class E danger

Meine Konsequenz: Komplexe Analysen, Architekturentscheidungen, Code-Reviews über mehrere Dateien — das bleibt bei Claude. Nicht weil ich es nicht lokal versucht habe, sondern weil ich die Ergebnisse verglichen habe und der Qualitätsunterschied zu erheblich ist.

Kreatives Schreiben und Stilanpassung

Erste Ideen strukturieren, einen groben Outline vorschlagen, einen Absatz umformulieren — für solche Hilfestellungen habe ich lokale Modelle getestet. Das Ergebnis: brauchbar für grobe Strukturvorschläge, aber sobald es um Stil, Ton oder Nuancen geht, merkt man die Grenzen deutlich. Die Texte klingen generisch und der Stil lässt sich kaum beeinflussen.

Das liegt an der Modellgröße. Stilistisches Feingefühl und sprachliche Nuancen brauchen einen großen Parameterraum — den haben 2-4B-Modelle schlicht nicht. Für alles was über einfache Strukturhilfe hinausgeht, bleibt Claude die bessere Wahl.

Mehrsprachige Aufgaben

Deutsch funktioniert mit phi3:mini und gemma2:2b deutlich schlechter als Englisch. Das ist keine Überraschung — die meisten dieser Modelle wurden primär auf englischsprachigen Daten trainiert. Für deutsche Texte merkt man den Qualitätsunterschied spürbar.

Für diesen Blog — der zweisprachig ist — bedeutet das: deutsche Texte entstehen mit Claude, nicht lokal.

Die graue Zone

Einige Aufgaben funktionieren lokal — aber mit Abstrichen die man kennen sollte.

Code erklären

Vorhandenen Code erklären lassen funktioniert überraschend gut, solange der Code überschaubar ist. Bei komplexeren Systemen oder unbekannten Frameworks wird die Erklärung ungenau. Gut als erste Orientierung, nicht als verlässliche Quelle.

Übersetzungen

Einfache Übersetzungen zwischen gängigen Sprachen funktionieren. Für Nuancen, Fachbegriffe oder stilistisch anspruchsvolle Texte — lieber Claude.

Daten strukturieren

JSON aus unstrukturiertem Text extrahieren, Tabellen bereinigen, Felder umbenennen — das klappt gut für einfache Fälle. Komplexe Transformationen produzieren manchmal subtile Fehler die man leicht übersieht.

Hybride Workflows: Das Beste aus beiden Welten

Nach einigen Wochen Praxiserfahrung hat sich bei mir ein Workflow etabliert der lokal und Cloud kombiniert — nicht als Kompromiss, sondern als bewusste Architekturentscheidung.

flowchart TD
    classDef cloud   fill:#1e3a5f,color:#93c5fd,stroke:#93c5fd,stroke-width:1.5px
    classDef success fill:#14532d,color:#86efac,stroke:#86efac,stroke-width:1.5px
    classDef warning fill:#d97706,color:#ffffff,stroke:#92400e,stroke-width:1.5px
    A[Aufgabe] --> B{Datensensitivität?}
    B -->|Hoch\nprivate/interne Daten| C{Aufgabenkomplexität?}
    B -->|Niedrig\nöffentliche Daten| D{Qualitätsanspruch?}

    C -->|Einfach| E[✅ Lokal\nOllama]
    C -->|Komplex| F[⚠️ Abwägen:\nLokal mit Review\nvs. Cloud mit ZDR]

    D -->|Standard| G[✅ Lokal\nOllama]
    D -->|Hoch| H[✅ Cloud\nClaude]

    class E success
    class G success
    class H cloud
    class F warning

Die Entscheidungslogik in der Praxis:

Sensible Daten, einfache Aufgabe → lokal, fertig.

Sensible Daten, komplexe Aufgabe → das ist der schwierige Fall. Hier wäge ich ab: kann ich die Aufgabe so vereinfachen dass lokal ausreicht? Oder gibt es eine ZDR-konforme Cloud-Option? Das ist keine pauschale Antwort — das ist eine Einzelfallentscheidung.

Nicht-sensible Daten → Cloud, wenn die Qualität es rechtfertigt. Kein Grund für lokale Einschränkungen wenn die Daten ohnehin öffentlich zugänglich wären.

Was ich nach dieser Erfahrung anders machen würde

Drei Dinge die ich rückblickend früher gewusst haben möchte:

1. Use Case zuerst — dann die Architekturentscheidung.
Was sich in der Theorie nach einem Grundprinzip anhört, hat sich in der Praxis bestätigt: erst verstehen was man wirklich braucht, dann die passenden Mittel wählen. Ich bin den Weg vom MBA M2 mit 24GB über den Pi 5 mit 16GB bis zum Pi 4 mit 4GB gegangen — jede Stufe hat andere Stärken und Grenzen, und die Wahl hängt direkt vom Anwendungsfall ab. Wer das umdreht und erst die Hardware kauft, stellt oft fest dass sie für den eigentlichen Use Case entweder überdimensioniert oder zu limitiert ist. Das klingt selbstverständlich — ist es in der Praxis aber oft nicht.

2. Kleine Modelle haben einen eigenen Charakter — und man muss ihn kennen.
phi3:mini ist stärker im Reasoning, gemma2:2b schneller und stabiler. Das merkt man erst nach einigen Stunden echtem Einsatz. Benchmarks helfen, aber ersetzen die eigene Erfahrung nicht.

3. Hybrid ist keine Niederlage.
Ich habe eine Weile versucht, möglichst viel lokal zu halten — aus Überzeugung und aus Spieltrieb. Irgendwann habe ich akzeptiert dass ein sinnvoller hybrider Ansatz pragmatischer ist als dogmatische Cloud-Vermeidung. Kontrolle durch Architektur da wo es zählt, und Cloud da wo es sinnvoll ist.

Fazit

Lokale KI ohne Cloud funktioniert. Für die richtigen Aufgaben, mit den richtigen Erwartungen.

Was mich am meisten überrascht hat: wie gut es für Zusammenfassungen und Klassifizierung funktioniert. Und wie deutlich die Grenzen bei komplexem Reasoning sind.

Was ich für mich mitgenommen habe: der hybride Ansatz ist nicht der Weg des geringsten Widerstands — er ist der pragmatisch richtige Weg. Lokal wo Datensouveränität wichtig ist und die Aufgabe es erlaubt. Cloud wo Qualität, Komplexität, regulatorische Anforderungen oder gesetzliche Vorgaben es rechtfertigen.

Und wer das einmal selbst ausprobiert hat — ein Modell lokal zum Laufen gebracht, den Traffic-Monitor beobachtet, die Grenzen getastet — versteht die Technologie auf eine Art die kein Artikel vermitteln kann.

Alle Angaben basieren auf eigenen Tests mit Ollama auf MacBook Air M2 (24GB RAM), Raspberry Pi 5 (16GB RAM) und Raspberry Pi 4 (4GB RAM), mit verschiedenen Modellen von gemma2:2b bis llama3:70b. Stand: Juni 2026.

Dieser Artikel gibt ausschließlich meine persönliche Meinung wieder und steht in keinem Zusammenhang mit beruflichen Tätigkeiten.