Lokale KI realistisch betreiben: Performance, Hardware & Grenzen

Warum lokale KI keine Cloud ist – und genau deshalb planbar sein muss

Spätestens nach den ersten produktiven Tests kommt der Realitätscheck: Antworten dauern länger als erwartet, der RAM läuft voll, parallele Anfragen brechen ein. Das ist kein Versagen – das ist Physik.

Dieser Teil sorgt für realistische Erwartungen und zeigt, wie du mit Ollama ein stabiles Setup baust, statt dich in Hardware-Experimenten zu verlieren.

CPU vs. GPU: Der grundlegende Unterschied

CPU-Betrieb

Vorteile

• läuft auf fast jedem System
• keine Spezialhardware nötig
• einfach zu betreiben

Nachteile

• deutlich langsamer
• hohe RAM-Last
• begrenzte Parallelität

Einsatzbereich

• Tests
• Batch-Jobs
• Automatisierungen
• kleine Modelle (7B)

👉 CPU ist robust, aber nicht schnell.

GPU-Betrieb

Vorteile

• massive Beschleunigung
• geringere Latenz
• bessere Parallelverarbeitung

Nachteile

• VRAM ist hart limitiert
• Setup aufwendiger
• Fehler sind gnadenlos (OOM)

Einsatzbereich

• interaktive Systeme
• RAG mit Nutzeranfragen
• produktive APIs

👉 GPU ist Performance, aber keine Wunderwaffe.

RAM-Fallen: Der häufigste Grund für Frust

Lokale LLMs sind RAM-getrieben. Punkt.

Typische Richtwerte (CPU, grob)

• 7B → 8–10 GB RAM
• 13B → 16–20 GB RAM
• 34B → 32 GB+ RAM

Was viele unterschätzen:

• das Betriebssystem braucht RAM
• andere Dienste laufen parallel
• Kontext + Chunks kosten zusätzlich Speicher

❌ „Ich habe 16 GB, das reicht für 13B“ → meistens nicht stabil.

👉 Reserve einplanen, sonst wird geswappt – und dann ist alles langsam.

VRAM ist kein RAM (und verzeiht nichts)

Bei GPU-Setups gilt:

• VRAM ist fix
• kein Swap
• kein Ausweichen

Ein Modell, das nicht reinpasst:

• startet nicht
• oder crasht sofort

Faustregel:

Modell + Kontext + Overhead müssen komplett in den VRAM passen.

👉 Ein stabiles 7B im VRAM schlägt ein wackeliges 13B jedes Mal.

Parallelität: Warum „mehr Anfragen“ nicht linear skaliert

Ein häufiger Denkfehler:

„Ich starte einfach mehrere Requests gleichzeitig.“

Lokale Realität:

• Modelle sind zustandsbehaftet
• jede Anfrage kostet Speicher
• Kontext wird repliziert

Ergebnis:

• Latenz steigt
• Speicher explodiert
• Antworten werden inkonsistent

Bewährte Praxis

• begrenzte Worker-Zahl
• Queue statt Parallel-Feuer
• kleine Modelle für Automationen
• größere Modelle nur gezielt

👉 Kontrollierte Parallelität schlägt rohe Masse.

Antwortzeiten realistisch einschätzen

Cloud-KI hat:

• riesige GPU-Cluster
• aggressive Optimierungen
• verteilte Last

Lokale KI hat:

• deinen Rechner
• deine Limits
• volle Transparenz

Realistische Erwartungen (CPU, 7B):

• erste Tokens: 1–3 Sekunden
• längere Antworten: mehrere Sekunden
• Batch-Jobs: Minuten statt Sekunden

GPU (7B–13B):

• interaktiv nutzbar
• akzeptable Chat-Latenz
• gute UX mit Streaming

👉 Streaming kaschiert Latenz, ersetzt aber keine Rechenleistung.

Typische Fehler, die du vermeiden solltest

❌ „Ich nehme das größte Modell“ ❌ „Parallel = schneller“ ❌ „RAM ist RAM“ ❌ „Cloud-Erwartungen lokal reproduzieren“

✅ passendes Modell ✅ saubere Limits ✅ realistische UX ✅ klare Architektur

Fazit: Stabilität schlägt rohe Leistung

Lokale KI ist kein Benchmark-Wettbewerb. Sie ist Infrastruktur.

Wenn dein Setup:

• reproduzierbar läuft
• unter Last stabil bleibt
• verständliche Latenzen hat
• nicht zufällig crasht

dann hast du alles richtig gemacht.

Ein stabiles 7B-System ist produktiver als ein instabiles 34B-Experiment.