Sie können derzeit ein leistungsfähiges Sprachmodell auf Ihrem Laptop ausführen. Kein Spielzeugmodell – ein echtes. Llama 3.1 8B läuft mit 16GB RAM. Mistral 7B läuft mit weniger. Das Setup dauert eine Stunde. Der Performance-Unterschied zwischen lokalen und Cloud-API-Aufrufen ist kleiner, als Sie denken.
Die meisten Entwickler gehen davon aus, dass lokale LLMs entweder langsam, begrenzt oder eine GPU erfordern, die sie nicht haben. Diese Annahme kostet Sie jeden Monat Geld. Sie kostet auch Latenz, Datenschutzbedenken und die Möglichkeit, das Verhalten anzupassen, ohne auf die Genehmigung eines API-Anbieters warten zu müssen.
Hier erfahren Sie, was tatsächlich funktioniert und was nicht.
Das richtige Modell für Ihre Hardware auswählen
Modellgröße und Ihr verfügbarer RAM sind keine unabhängigen Variablen. Ebenso wenig der GPU-Speicher, falls Sie eine haben.
Eine Faustregel, die sich in der Praxis bewährt: Ein Modell benötigt etwa 2 Bytes VRAM pro Parameter bei voller Präzision und etwa 0,5 Bytes pro Parameter bei 4-Bit-Quantisierung. Das bedeutet, Llama 3.1 8B (8 Milliarden Parameter) benötigt etwa 4 GB VRAM in 4-Bit-Form oder 16 GB in voller Präzision.
Für insgesamt 16 GB RAM (keine dedizierte GPU): Mistral 7B oder Llama 3.1 8B funktionieren zuverlässig. Beide laufen mit Quantisierung bei nutzbaren Geschwindigkeiten. Phi-3 5B ist in Bezug auf die Leistungsfähigkeit übertrieben – es ist gut, wenn Sie einen Speicherbedarf von unter 4 GB benötigen.
Für 32 GB+ RAM oder jede GPU mit 8 GB+ VRAM: Llama 3.1 70B wird machbar. Hier sehen Sie deutliche Qualitätsverbesserungen gegenüber den kleineren Modellen.
Für reine CPU-Maschinen: Erwarten Sie langsamere Inferenz, keine unbrauchbare Inferenz. Eine moderne 8-Kern-CPU, die Mistral 7B in 4-Bit-Quantisierung ausführt, generiert Text mit etwa 5–10 Tokens pro Sekunde. Das ist langsam genug, um es zu bemerken, aber nicht so langsam, dass man den Ansatz ganz aufgeben muss.
Installation und Ausführung mit Ollama
Ollama ist der schnellste Weg von Null zum laufenden Modell. Laden Sie es herunter, führen Sie drei Befehle aus, fertig.
# Ollama von ollama.ai installieren, dann:
ollama pull mistral:7b
ollama run mistral:7bDas war’s. Sie haben jetzt ein Modell, das auf localhost:11434 läuft. Der erste pull lädt etwa 4–5 GB herunter (für Mistral in quantisierter Form). Nachfolgende Ausführungen werden sofort von der Festplatte geladen.
Wenn Sie es programmatisch von Python oder Node aus aufrufen möchten:
import requests
import json
prompt = "Erkläre, wie Transformer-Attention in einem Absatz funktioniert."
response = requests.post(
"http://localhost:11434/api/generate",
json={
"model": "mistral:7b",
"prompt": prompt,
"stream": False
}
)
result = json.loads(response.text)
print(result["response"])
Dies ist strukturell funktional identisch mit einem OpenAI API-Aufruf – Sie senden Text, Sie erhalten Text zurück. Der Unterschied ist, dass das Modell auf Ihrem Rechner läuft und pro Token nichts kostet.
Ollama kümmert sich automatisch um die Modellquantisierung. Standardmäßig verwendet es 4-Bit-Quantisierung, was den Speicherbedarf bei minimalem Qualitätsverlust um etwa 75 % reduziert. Sie können volle Präzision mit ollama pull mistral:fp16 erzwingen, wenn Sie über den benötigten VRAM verfügen, aber das ist normalerweise nicht notwendig.
Wenn lokale Modelle unterperformen (und wie man es erkennt)
Lokale Modelle sind gut. Sie sind nicht in jeder Aufgabe ein direkter Ersatz für Claude oder GPT-4o.
Mistral 7B eignet sich gut für: Code-Generierung, Zusammenfassung, Klassifizierung, Extraktion strukturierter Daten. Es versagt sichtbar bei: Lang-Kontext-Argumentation (alles, was kohärentes Denken über 20+ Absätze erfordert), mehrstufige Logik, bei der frühere Schritte sich aufbauen, und Aufgaben, die explizites Weltwissen erfordern, das nach dem Trainingsdatum des Modells veröffentlicht wurde.
Die praktische Lösung: Benchmarking für Ihren spezifischen Anwendungsfall. Gehen Sie nicht von einem Scheitern aus. Ich habe Mistral 7B bei einer Kundenklassifizierungsaufgabe getestet und es erreichte die Genauigkeit von GPT-3.5 zu 1/100 der Kosten. Bei einer anderen Aufgabe – Extraktion nuancierter Stimmungen aus Finanzdokumenten – erzielte es 15 % weniger Punkte. Kontext ist entscheidend.
Sie erkennen, wann ein Modell Schwierigkeiten hat: inkohärenter Output, wiederholte Phrasen, plötzliche Themenwechsel oder korrekte Schlussfolgerungen, die einer früheren Aussage widersprechen. Diese sind nicht immer subtil. Wenn Sie sie sehen, wechseln Sie zur 70B-Variante oder fügen Sie mehr Kontext über RAG hinzu.
Quantisierungs-Kompromisse: Geschwindigkeit vs. Genauigkeit
Quantisierung komprimiert ein Modell, indem Zahlen mit weniger Bits dargestellt werden. 4-Bit-Quantisierung verwendet 4 Bits pro Parameter anstelle von 32 und schrumpft das Modell um etwa das 8-fache.
Der Qualitätsverlust ist real, aber für die meisten Aufgaben nicht katastrophal. Llama 3.1 8B in 4-Bit-Quantisierung erreicht auf Standard-Benchmarks (MMLU, HumanEval) etwa 95–98 % der Leistung bei voller Präzision. Diese Lücke vergrößert sich bei nuancierten Sprachaufgaben leicht.
Der Geschwindigkeitsgewinn ist beträchtlich: 4-Bit-Quantisierung führt auf CPUs oft zu 20–30 % schnellerer Inferenz, da die Speicherbandbreite weniger zum Engpass wird. Auf GPUs ist der Unterschied kleiner, aber immer noch messbar.
Beginnen Sie mit 4-Bit (Ollama-Standard). Wenn die Ausgabequalität enttäuscht, können Sie jederzeit eine Variante mit höherer Präzision herunterladen und es erneut versuchen – Modelle werden nach dem Herunterladen in Sekunden geladen.
Erstellen eines lokalen LLM-Workflows: Praktisches Beispiel
Nehmen wir an, Sie verarbeiten Support-Tickets und extrahieren strukturierte Daten (Priorität, Kategorie, Dringlichkeit).
import requests
import json
def classify_ticket(ticket_text):
prompt = f"""Klassifiziere dieses Support-Ticket und antworte NUR mit JSON.
Ticket: {ticket_text}
Antworte mit diesem Format:
{{
"priority": "high" | "medium" | "low",
"category": "billing" | "technical" | "account",
"urgency_minutes": number,
"summary": "ein-satz-zusammenfassung"
}}"""
response = requests.post(
"http://localhost:11434/api/generate",
json={"model": "mistral:7b", "prompt": prompt, "stream": False}
)
result = json.loads(response.text)["response"]
return json.loads(result) # JSON aus der Modellausgabe parsen
ticket = "Kunde sagt, dass der Login nach dem Zurücksetzen des Passworts nicht mehr funktioniert. Benötigt Zugriff bis heute Abend."
print(classify_ticket(ticket))
Das funktioniert. Mistral 7B liefert bei strukturierten Extraktionsaufgaben zuverlässig gültiges JSON – besser, als man von einem 7B-Modell erwarten würde. Die Latenz auf einer modernen CPU beträgt 2–4 Sekunden Ende-zu-Ende. Das ist langsamer als ein Cloud-API-Aufruf (der vielleicht 0,5–1 Sekunde dauert), aber Sie führen es offline aus und zahlen null pro Inferenz.
Eine Sache, die Sie heute tun sollten: Testen Sie Ihre Hardware-Grenzen
Laden Sie Ollama herunter. Führen Sie ollama pull mistral:7b aus. Führen Sie das Modell aus. Überprüfen Sie die System-RAM- und CPU-Auslastung, während es läuft – top auf Mac/Linux oder Task-Manager unter Windows.
Sie sehen genau, wie viel Spielraum Sie haben, bevor Sie an Ihre Grenzen stoßen. Diese Zahl sagt Ihnen, ob Sie 7B-Modelle bequem ausführen können, ob Sie auf kleinere Modelle zurückgreifen müssen oder ob ein 70B-Modell in Reichweite ist. Keine Annahmen erforderlich. Nur Daten.
