Sprachmodelle auf dem eigenen Rechner ausführen: Apple Silicon, Quantisierung und was tatsächlich passt

Es gibt einen bestimmten Moment, in dem lokale Sprachmodelle aufhören, eine Spielerei zu sein, und wirklich nützlich werden. Er tritt ein, wenn Sie feststellen, dass ein Modell, das auf Ihrem Laptop läuft: ohne API-Schlüssel, ohne Ratenbegrenzung und ohne Kosten pro Token: für eine Aufgabe gut genug ist, die Sie zuvor an ein Frontier-Modell geschickt haben. Diese Schwelle hat sich deutlich verschoben. Dies ist der Begleitartikel zu Hardware und Dimensionierung für Lokale KI im Jahr 2026, der die Laufzeitumgebungen selbst behandelt hat. Ein großer Teil der Arbeit, die Entwickler tatsächlich mit Sprachmodellen erledigen: Zusammenfassen, Extrahieren, Klassifizieren, Umschreiben und Beantworten von Fragen zu einem vorliegenden Dokument: funktioniert inzwischen einwandfrei auf der Hardware, die Sie bereits besitzen.

Warum die Speicherbandbreite alles entscheidet

Um einen Token mit einem Transformer zu generieren, muss im Wesentlichen jedes Gewicht des Modells gelesen werden. Das ist die grundlegende Operation, die für jeden einzelnen erzeugten Token wiederholt wird. Wenn das Modell 8 GB im Speicher belegt und Ihre Hardware 400 GB pro Sekunde bewegen kann, liegt die rechnerische Obergrenze bei etwa 50 Token pro Sekunde: unabhängig davon, wie schnell der Prozessor ist, denn der Prozessor verbringt die meiste Zeit damit, auf das Eintreffen der Gewichte zu warten.

Diese eine Tatsache erklärt das meiste, was an der lokalen Inferenzleistung seltsam erscheint. Sie erklärt, warum Apple Silicon trotz bescheidener reiner Rechenwerte so gut abschneidet: Einheitlicher Speicher bietet hohe Bandbreite für einen großen Pool. Sie erklärt, warum eine Consumer-GPU mit schnellem, aber kleinem Speicher eine Workstation-Karte mit langsamerem Speicher überholt. Sie erklärt auch, warum Quantisierung so dramatische Geschwindigkeitsschübe bringt: Halbiert man die Bytes pro Gewicht, halbiert man die zu bewegenden Daten, und die Geschwindigkeit verdoppelt sich in etwa.

Wenn Sie Hardware für lokale Inferenz auswählen, sind Speicherbandbreite und Speicherkapazität die beiden zu vergleichenden Zahlen. Alles andere ist zweitrangig.

Was in Ihren Speicher passt

Die Größenbestimmung ist einfache Arithmetik. Nehmen Sie die Parameteranzahl in Milliarden, multiplizieren Sie sie mit den Bytes pro Parameter, die sich aus der Quantisierung ergeben, und addieren Sie etwa 20 Prozent für den Key-Value-Cache und den Laufzeit-Overhead. Bei 4 Bit sind das in der Praxis etwa 0,55 Bytes pro Parameter, wenn man die Metadaten berücksichtigt, die Quantisierungsformate mit sich bringen.

Beachten Sie, dass das Kontextfenster nicht kostenlos ist. Lange Kontexte lassen den Key-Value-Cache erheblich anwachsen, und ein 32k-Kontext bei einem mittelgroßen Modell kann allein mehrere Gigabyte hinzufügen. Wenn ein Modell einwandfrei lädt und dann mitten in einem langen Dokument versagt, ist fast immer der Cache die Ursache.

Wie viel Qualität kostet die Quantisierung?

Quantisierung reduziert die Genauigkeit der Gewichte. Sechzehn Bit ist die übliche volle Präzisionsbasis, und 8-, 5- und 4-Bit-Varianten tauschen Genauigkeit gegen Speicher und Geschwindigkeit. Der Grund, warum 4 Bit zum Standard wurde, ist, dass der Qualitätsverlust gering und ungleichmäßig verteilt ist: Er berührt einfache Sprachaufgaben kaum und zeigt sich hauptsächlich bei mehrschrittigem logischem Denken, Arithmetik und Codegenerierung.

Der praktische Rat lautet, die größte Parameterzahl zu verwenden, die mit 4 Bit passt, anstatt ein kleineres Modell mit höherer Präzision. Ein 14B-Modell mit 4 Bit wird ein 8B-Modell mit 8 Bit im Allgemeinen übertreffen, obwohl es ähnlich viel Speicher belegt, denn mehr Parameter bringen im relevanten Bereich mehr Leistung als höhere Präzision.

Ohne Umschweife loslegen

Die Werkzeuge sind inzwischen ausgesprochen angenehm zu bedienen. Auf Apple Silicon bieten Metal-basierte Frameworks native GPU-Beschleunigung ohne Konfigurationsaufwand. Unter Linux und Windows mit einer NVIDIA-Karte arbeiten dieselben Laufzeitumgebungen über CUDA. In beiden Fällen können Sie innerhalb weniger Minuten Tokens generieren.

# Pull a quantised model and talk to it. Most local runtimes expose an
# OpenAI compatible endpoint, which means existing client code just works.

ollama pull llama3.1:8b-instruct-q4_K_M
ollama run llama3.1:8b-instruct-q4_K_M "Summarise this in three bullets: ..."

# Serve it on localhost with an OpenAI compatible API
ollama serve

# Point any existing client at it by changing the base URL
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.1:8b-instruct-q4_K_M",
    "messages": [{"role": "user", "content": "Extract every date from this text."}],
    "temperature": 0.2
  }'

Der OpenAI-kompatible Endpunkt ist das Detail, das lokale Modelle praxistauglich statt akademisch macht. Bestehender Code, der mit einer gehosteten API kommuniziert, benötigt meist nur eine Änderung der Basis-URL, um mit einem lokalen Modell zu arbeiten. So können Sie an einem Nachmittag ein lokales Modell gegen ein Frontier-Modell mit Ihrer echten Arbeitslast testen, statt eine Integration neu zu schreiben.

# Route by difficulty: local model for volume, frontier API for hard cases.
# The heuristic matters less than having one at all.

from openai import OpenAI

local    = OpenAI(base_url="http://localhost:11434/v1", api_key="not-needed")
frontier = OpenAI()   # reads the real key from the environment

def classify(text: str, hard: bool = False):
    client = frontier if hard else local
    model  = "gpt-5" if hard else "llama3.1:8b-instruct-q4_K_M"

    return client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": text}],
        temperature=0,
    )

# Escalate only when the local model is uncertain or the input is long
def needs_frontier(text: str, local_confidence: float) -> bool:
    return local_confidence < 0.7 or len(text) > 20_000

Wo lokale Modelle wirklich verlieren

Es wäre unehrlich, dies als direkten Ersatz darzustellen. Lokale Modelle sind deutlich schlechter bei langem, mehrschrittigem logischem Denken, beim kohärenten Halten sehr langer Kontexte, beim Generieren korrekten Codes für unbekannte Bibliotheken und beim Befolgen komplizierter Anweisungen mit vielen Bedingungen, ohne abzuschweifen. Wenn Ihre Aufgabe das logische Durchdringen von hundert Seiten umfasst oder Code erfordert, der auf Anhieb korrekt sein muss, ist der Unterschied real und Sie werden ihn spüren.

Sie verlieren auch beim dauerhaften Durchsatz. Eine einzelne Maschine, die einen Benutzer bedient, ist in Ordnung. Eine einzelne Maschine, die zweihundert gleichzeitige Benutzer bedient, ist ein anderes technisches Problem, und an diesem Punkt erscheinen die wirtschaftlichen Vorteile einer gehosteten API wieder vernünftig.

Die pragmatische Position

Lokale Inferenz ist keine Bastelübung mehr, aber auch kein vollständiger Ersatz für gehostete Modelle. Der nützliche Rahmen ist, dass Sie nun eine schnelle, kostenlose, private Stufe für das große Volumen einfacher Arbeiten zur Verfügung haben und eine kostenpflichtige Stufe für die wirklich schwierigen Anfragen. Die meisten Teams stellen fest, dass die Aufteilung stark zugunsten der kostenlosen Stufe ausfällt, sobald sie ehrlich gemessen wird. Verbringen Sie einen Nachmittag damit, Ihre echten Prompts gegen ein 8B-Modell auf der Maschine vor Ihnen laufen zu lassen, und lassen Sie die Ergebnisse statt des Marketings entscheiden, wohin jede Anfrage gehen soll.