Verwendete Software und Versionen
Diese Erklärung bezieht sich auf:
- Konzepte: Lokale vs. Cloud-Modelle, Speicherung, RAM-Anforderungen, Quantisierung
- Kontext: Tool-unabhängige lokale KI-Grundlagen
Lokale Modelle laufen auf eigener Hardware ohne Cloud-Abhängigkeit
Wie ein Sprachmodell funktioniert erklärt neuronale Netze und Parameter als mathematische Gewichte. Lokale Modelle speichern diese Parameter-Dateien auf dem eigenen System und führen Inferenz komplett lokal aus. Keine Daten verlassen das System - jede Anfrage wird durch lokale Berechnungen beantwortet.
Cloud-basierte KI-APIs senden Prompts an externe Server und empfangen generierte Antworten über Internet-Verbindungen. Der Anbieter sieht alle Eingaben und Ausgaben. Lokale Modelle eliminieren diese Abhängigkeit vollständig - Inferenz funktioniert ohne Internet-Verbindung, sobald das Modell einmal heruntergeladen wurde.
Die Wahl zwischen lokal und Cloud balanciert Kontrolle gegen Convenience. Cloud-APIs bieten sofortigen Zugriff ohne Hardware-Investition, schaffen aber Abhängigkeit von Anbieter-Verfügbarkeit. Lokale Modelle erfordern geeignete Hardware, gewährleisten aber vollständige Daten-Souveränität.
Wo ein lokales Modell tatsächlich läuft
“Lokal” bedeutet nicht zwingend “auf dem eigenen Notebook”. Drei Setups sind üblich:
Einzelsystem-Setup lädt das Modell direkt auf der Arbeitsstation oder dem Laptop. Einfachste Konfiguration ohne Netzwerk-Komplexität - jede Session lädt das Modell frisch in den RAM, nicht persistent zwischen Sessions. Geeignet für persönliche Nutzung auf dediziertem System.
Server-basiertes Setup betreibt das Modell auf einem dedizierten Server-System. Client-Anwendungen verbinden über eine Netzwerk-API zu einem persistenten Modell-Server. Das Modell bleibt zwischen Sessions geladen, was Antwortzeiten verkürzt - mehrere Nutzer teilen sich zentral dieselben Modell-Ressourcen.
Hybrid-Setup kombiniert lokale Light-Modelle mit Remote-Heavy-Modellen: schnelle kleine Modelle lokal für interaktive Aufgaben, größere Modelle auf einem Server für komplexe Analysen.
Server-Setups verschieben die Frage der Datenkontrolle nur - Authentifizierung und Zugriffskontrolle für Modell-APIs bleiben notwendig. Ein ungeschützter Endpoint im eigenen Netz ist genauso ein Risiko wie eine Cloud-API, nur ohne deren Betreiber-Verantwortung.
Modell-Dateien enthalten trainierte Parameter als Binär-Daten
Ein Modell besteht aus mehreren Dateien, die zusammen die trainierten neuronalen Netz-Gewichte repräsentieren. Die Haupt-Datei enthält Milliarden Parameter als numerische Werte - ein 2B-Modell speichert 2,5 Milliarden Zahlen. Zusätzliche Dateien definieren Modell-Architektur, Tokenizer-Konfiguration und Metadaten.
Modell-Dateien verwenden binäre Formate für effiziente Speicherung und schnelles Laden. GGUF ist heute ein verbreitetes Dateiformat für lokale Modelle, das Gewichte, Architektur-Information und Metadaten in einer Datei kombiniert.
Die Dateigröße eines Modells korreliert mit Parameter-Anzahl und Quantisierungs-Level. Ein 2B-Modell mit 4-Bit-Quantisierung belegt etwa 1,7 GB Festplatte, ein 8B-Modell mit identischer Quantisierung etwa 4,7 GB. Höhere Quantisierungs-Präzision verdoppelt oder vervierfacht diese Größen.
RAM-Anforderungen zur Laufzeit übersteigen Dateigrößen
Modell-Dateien müssen vollständig in den Arbeitsspeicher geladen werden, um Inferenz durchzuführen. Die RAM-Anforderung liegt spürbar über der Dateigröße.
Warum die Datei allein nicht reicht
Die Datei enthält nur die trainierten Gewichte - den statischen Zustand des Modells. Während der Generierung entstehen zusätzlich Aktivierungen: Zwischenergebnisse jeder Netzschicht, die für den nächsten Berechnungsschritt gebraucht werden. Dazu kommt der Kontext-Puffer, der die bereits verarbeiteten Token speichert, damit Self-Attention auf sie zugreifen kann. Beides entsteht erst zur Laufzeit und wird nirgends auf der Festplatte mitgeliefert - deshalb liegt der RAM-Bedarf typischerweise 30 bis 70 Prozent über der Dateigröße.
Ein 2B-Modell mit 1,7 GB Dateigröße benötigt typischerweise 2-3 GB RAM zur Laufzeit. Ein 8B-Modell mit 4,7 GB Dateigröße erfordert 6-8 GB freien RAM. Architektur-spezifische Unterschiede können diese Faustregeln verschieben - manche Modelle sind effizienter, andere verschwenderischer.
Beispiel RAM-Anforderungen (4-Bit-Quantisierung):
┌──────────────┬──────────────┬────────────────┬─────────────┐
│ Modell-Größe │ Dateigröße │ RAM zur Laufzeit│ Empfehlung │
├──────────────┼──────────────┼────────────────┼─────────────┤
│ 1B (tiny) │ ~600 MB │ 1-1,5 GB │ 4 GB System │
│ 2B │ ~1,7 GB │ 2-3 GB │ 8 GB System │
│ 3-4B │ ~2,2 GB │ 3-5 GB │ 8 GB System │
│ 7B │ ~3,8 GB │ 5-7 GB │ 16 GB System│
│ 8B │ ~4,7 GB │ 6-8 GB │ 16 GB System│
│ 13B │ ~7,3 GB │ 9-12 GB │ 32 GB System│
└──────────────┴──────────────┴────────────────┴─────────────┘
Verfügbarer RAM schwankt je nach laufenden Prozessen. Ein System mit 8 GB Gesamt-RAM kann typischerweise 2B-Modelle zuverlässig ausführen. Größere Modelle (8B+) erfordern Systeme mit möglichst wenigen parallel laufenden Diensten - auf einem 8 GB System bedeutet ein 8B-Modell in der Praxis, nahezu alles andere zu schließen.
Quantisierung reduziert Speicherbedarf durch Präzisions-Reduktion
Training verwendet 32-Bit- oder 16-Bit-Fließkommazahlen für maximale Präzision. Quantisierung konvertiert diese hochpräzisen Werte nach Trainingsabschluss zu einer niedrigeren Bit-Darstellung. Ein 7B-Modell belegt 28 GB bei 32-Bit-Vollpräzision, aber nur 3,8 GB bei 4-Bit-Quantisierung.
Quantisierungs-Level Vergleich (7B-Modell):
┌─────────────┬──────────────┬─────────────┬──────────────┐
│ Bit-Level │ Dateigröße │ Qualität │ Anwendung │
├─────────────┼──────────────┼─────────────┼──────────────┤
│ Q2 (2-Bit) │ ~1,8 GB │ Niedrig │ Tests │
│ Q4 (4-Bit) │ ~3,8 GB │ Gut │ Standard │
│ Q5 (5-Bit) │ ~4,7 GB │ Sehr gut │ Balance │
│ Q8 (8-Bit) │ ~7,2 GB │ Exzellent │ Präzision │
│ F16 (16-Bit)│ ~14 GB │ Training-Nähe│ Forschung │
│ F32 (32-Bit)│ ~28 GB │ Training │ Entwicklung │
└─────────────┴──────────────┴─────────────┴──────────────┘
Warum ein Achtel des Speichers kaum Qualität kostet
Ein Parameter muss nicht auf die letzte Nachkommastelle genau sein, um seine Funktion zu erfüllen. Entscheidend ist nicht der exakte Zahlenwert eines einzelnen Gewichts, sondern das Verhältnis vieler Gewichte zueinander - welches Token wahrscheinlicher ist als ein anderes. Rundet man alle Werte gleichmäßig auf eine gröbere Skala, bleiben diese Verhältnisse zwischen den meisten Gewichten weitgehend erhalten, auch wenn die einzelne Zahl ungenauer wird.
Bei sehr niedriger Präzision (2-Bit) wird die Skala so grob, dass unterschiedliche ursprüngliche Werte auf denselben gerundeten Wert fallen - genau dort brechen Verhältnisse zusammen, und Qualität geht spürbar verloren. 4-Bit liegt für die meisten Modelle knapp oberhalb dieser Schwelle: fein genug, um die relevanten Verhältnisse zu erhalten, grob genug, um Speicher drastisch zu sparen.
4-Bit-Quantisierung (Q4) bietet für Consumer-Hardware den besten Kompromiss. Die meisten Chat- und Code-Aufgaben zeigen keine merkbaren Qualitätsunterschiede zwischen Q4 und höheren Präzisions-Leveln. Aufgaben mit langen Rechenketten oder exakten numerischen Anforderungen profitieren stärker von Q8 oder F16, weil sich kleine Rundungsfehler dort über viele Schritte aufsummieren können.
Kontext-Fenster bestimmen die verarbeitbare Eingabe-Länge
Jedes Modell definiert eine maximale Kontext-Länge als Anzahl verarbeitbarer Token. Ein 4K-Kontext-Fenster verarbeitet etwa 3000 Wörter gleichzeitig - längere Eingaben werden abgeschnitten oder erfordern Chunking-Strategien.
Kontext-Fenster Größen:
┌──────────────┬─────────────┬────────────────┬──────────────┐
│ Token-Limit │ ~Wörter │ RAM-Overhead │ Use-Case │
├──────────────┼─────────────┼────────────────┼──────────────┤
│ 2K │ 1.500 │ Minimal │ Kurze Chats │
│ 4K │ 3.000 │ Niedrig │ Standard │
│ 8K │ 6.000 │ Moderat │ Dokumente │
│ 32K │ 24.000 │ Hoch │ Lange Texte │
│ 128K │ 96.000 │ Sehr hoch │ Bücher │
└──────────────┴─────────────┴────────────────┴──────────────┘
Größere Kontext-Fenster benötigen quadratisch mehr Rechenleistung durch Self-Attention - ein 8K-Fenster ist nicht doppelt, sondern etwa vier Mal so rechenintensiv wie 4K bei gleicher Hardware. Die Wahl des Kontext-Fensters ist deshalb dieselbe Abwägung wie die Wahl der Modellgröße: mehr Kapazität gegen mehr Rechenaufwand.
CPU und GPU verarbeiten dieselbe Berechnung unterschiedlich schnell
CPU-basierte Inferenz funktioniert auf jeder Hardware ohne spezielle Anforderungen - typischerweise 5-15 Token pro Sekunde bei 2B-Modellen auf modernen Desktop-CPUs. GPU-Beschleunigung erhöht die Token-Generierung dramatisch: 50-100+ Token pro Sekunde bei identischen Modellen.
Warum GPUs für neuronale Netze so viel schneller sind
Eine CPU ist auf wenige, komplexe Berechnungen nacheinander optimiert - stark bei verzweigter Logik, schwach bei stumpfer Wiederholung. Inferenz besteht dagegen fast ausschließlich aus derselben Operation, millionenfach gleichzeitig ausgeführt: Matrix-Multiplikationen zwischen Eingabewerten und Parametern. Eine GPU besitzt tausende einfache Recheneinheiten, die genau diese eine Operation parallel statt nacheinander ausführen. Für neuronale Netze ist das kein Nebeneffekt, sondern der Grund, warum GPUs überhaupt für diesen Zweck entwickelt wurden.
Das setzt der Modellgröße auf der GPU eine eigene Grenze: GPU-RAM limitiert, wie viel eines Modells parallel verarbeitet werden kann - eine 8 GB GPU kann maximal ein 7B-Modell mit 4-Bit-Quantisierung laden. Apple Silicon (M1/M2/M3) umgeht diese strikte Trennung teilweise durch Unified Memory, das CPU und Neural Engine denselben Speicher teilen lässt - Systeme mit 16 GB können dadurch 8B-Modelle effizient ausführen. AMD-GPUs funktionieren über das ROCm-Framework mit wachsender, aber noch uneinheitlicher Kompatibilität.
Wovon die Geschwindigkeit tatsächlich abhängt
Fünf Faktoren bestimmen gemeinsam, wie schnell ein lokales Modell antwortet - keiner davon wirkt isoliert:
- Modellgröße: Mehr Parameter bedeuten mehr Berechnungen pro Token, siehe Wie ein Sprachmodell funktioniert.
- Quantisierung: Niedrigere Bit-Präzision reduziert die Berechnungs-Komplexität pro Token - ein Q4-Modell generiert schneller als dasselbe Modell in Q8.
- RAM- und GPU-Speicher: Passen die Gewichte nicht in den schnellen Speicher, muss langsamer nachgeladen werden - DDR5-RAM bietet hier mehr Bandbreite als DDR4.
- Kontext-Länge: Wächst quadratisch mit, siehe oben - lange Konversationen verlangsamen die Generierung progressiv.
- Hardware-Architektur: Moderne Multi-Core-CPUs mit AVX2/AVX-512-Instruktionen parallelisieren Matrix-Operationen effizienter als ältere Designs.
Ein einzelner Faktor allein erklärt selten, warum ein Modell auf einem System schnell und auf einem anderen langsam läuft - meist ist es das Zusammenspiel: ein großes Modell in hoher Präzision mit langem Kontext auf einer CPU ohne moderne Instruktionssätze summiert alle fünf Faktoren zum ungünstigsten Fall.
Tool-Landschaft für lokale Modell-Verwaltung
Verschiedene Tools verwalten lokale Modelle mit unterschiedlichen Philosophien - manche priorisieren Einfachheit, andere maximale Kontrolle. Diese Serie bleibt werkzeugunabhängig; die folgende Übersicht ordnet nur ein, wofür die verbreitetsten Ansätze stehen.
Ollama abstrahiert Komplexität durch einheitliche Befehle für verschiedene Modell-Architekturen. Ein Hintergrunddienst verwaltet Modell-Downloads und Lebenszyklus, eine HTTP-API ermöglicht Integration in externe Anwendungen. Fokus auf Benutzerfreundlichkeit statt granulare Kontrolle.
llama.cpp bietet direkte Modell-Ausführung ohne Hintergrunddienst. Kommandozeilen-basiert mit maximaler Konfigurierbarkeit - jeder Parameter ist anpassbar. Fokus auf Effizienz und Kontrolle für technisch versierte Nutzer.
LM Studio verwendet eine grafische Oberfläche für Modell-Management, mit eingebauter Modell-Suche und automatischer Hardware-Optimierung. Fokus auf Zugänglichkeit für nicht-technische Nutzer.
Konkrete Installations- und Nutzungsanleitungen für einzelne Tools folgen separat im Werkzeug-Bereich der Wissensplattform, sobald diese verfügbar sind.
Offline-Betrieb nach initialem Download
Lokale Modelle benötigen Internet nur für den initialen Download der Modell-Dateien. Nach erfolgreichem Download läuft die Inferenz komplett offline, weil während der Token-Generierung keine externe Kommunikation stattfindet - dadurch ist eine vollständige Netzwerk-Isolation möglich.
Modell-Updates erfordern einen erneuten, expliziten Download - kein automatisches Update im Hintergrund. Das verhindert unerwartete Verhaltens-Änderungen: Ein System mit funktionierendem Modell bleibt stabil, bis eine bewusste Update-Entscheidung getroffen wird.
Offline-Fähigkeit ermöglicht KI-Nutzung in netzwerk-isolierten Umgebungen: Entwicklungs-Systeme ohne Internet-Zugang oder Air-Gapped-Setups profitieren von lokaler Inferenz, weil sie dadurch unabhängig von Provider-Verfügbarkeit oder API-Rate-Limits bleiben.
Datenschutz und Souveränität bei lokalen Modellen
Lokale Inferenz eliminiert Datenschutz-Risiken durch externe Datenübertragung. Sensitive Dokumente, persönliche Informationen oder proprietärer Code bleiben vollständig lokal - keine Logs auf externen Servern, keine Drittpartei-Zugriffe.
Das bedeutet nicht “lokal ist automatisch besser” - es bedeutet Kontrolle: Wer ein lokales Modell betreibt, entscheidet selbst, was geloggt wird, wie lange Daten aufbewahrt werden und wer Zugriff hat. Diese Verantwortung liegt dann aber auch vollständig beim Betreiber, nicht mehr bei einem Cloud-Anbieter mit eigenen Compliance-Prozessen.
Limitierungen lokaler Modelle
Lokale Modelle sind kein Ersatz für jede Cloud-KI - sie verschieben den Kompromiss zugunsten von Kontrolle und Datenschutz, verlangen dafür aber passende Hardware und mehr Eigenverantwortung. Vier Grenzen zeigen das konkret:
Hardware-Constraints limitieren verfügbare Modellgrößen fundamental. Ein 8 GB RAM-System kann kein 13B-Modell ausführen, unabhängig von Optimierungen.
Qualitäts-Grenzen bestehen im Vergleich zu großen Cloud-Modellen. Modelle mit 100 Milliarden Parametern und mehr übertreffen 8B-Modelle bei komplexen Reasoning-Aufgaben deutlich - lokale Modelle sind ein Kompromiss, kein vollwertiger Ersatz für jeden Anwendungsfall.
Fehlende Aktualität durch statische Modell-Gewichte ohne kontinuierliches Training. Lokale Modelle kennen keine Ereignisse nach ihrem Trainings-Stichtag, während Cloud-APIs kontinuierlich aktualisiert werden.
Wartungsaufwand für Modell-Updates und Hardware-Verwaltung bleibt beim Betreiber. Cloud-APIs abstrahieren diese Infrastruktur-Komplexität vollständig weg.
Der Zusammenhang im Überblick
Dateigröße, RAM-Bedarf, Quantisierung, Kontext-Fenster und Hardware hängen nicht unabhängig voneinander ab - sie verschieben gemeinsam, welches Modell auf welchem System praktikabel läuft. Ein kleineres, stärker quantisiertes Modell mit kurzem Kontext läuft auf bescheidener Hardware; jede Erhöhung an einer Stelle - mehr Parameter, höhere Präzision, längerer Kontext - erhöht den Ressourcenbedarf an anderer Stelle mit.
Diese Konzepte gelten unabhängig vom verwendeten Werkzeug. Der nächste Artikel der Serie behandelt Prompts: wie Temperatur und Instruktionen die Ausgabe eines bereits laufenden Modells steuern.
