Welches lokale Modell zu Deiner Hardware passt
Von acht Gigabyte bis zum Server mit zwei Grafikkarten. Wie Du in zehn Schritten von Deiner tatsächlichen Ausstattung auf die richtige Modellgröße kommst, statt zu raten und dann beim Absturz zu lernen.
Die häufigste Enttäuschung bei lokaler KI ist nicht, dass es nicht funktioniert. Sie ist, dass jemand das größte Modell lädt, das er irgendwo empfohlen gesehen hat, und der Rechner dann entweder abstürzt oder ein Wort pro Sekunde ausspuckt. Danach heißt es "lokal taugt nichts", dabei war nur die Größe falsch.
Dieses Playbook dreht die Reihenfolge um. Erst Deine Hardware ansehen, daraus die Größenklasse ableiten, und innerhalb dieser Klasse dann nach Aufgabe wählen. Am Ende hast Du zwei Kandidaten und ein Verfahren, sie an Deiner eigenen Arbeit zu vergleichen.
1. Stell fest, wie viel Speicher wirklich zur Verfügung steht
Es zählt nicht der Speicher, der im Rechner steckt, sondern der, den das Modell tatsächlich bekommt.
Bei einem Mac mit Apple Silicon teilen sich Prozessor und Grafikeinheit denselben Speicher, und nur ein Teil davon steht dem Modell zur Verfügung. Als Überschlag kannst Du mit rund zwei Dritteln bis drei Vierteln rechnen: aus 32 GB werden grob 22 GB nutzbar, aus 64 GB etwa 45. Den genauen Anteil setzt Deine Laufzeitumgebung, und er hat sich zwischen Versionen schon geändert, also nimm die Zahl als Richtwert und nicht als Zusage.
Bei einer dedizierten Grafikkarte zählt allein deren Speicher, und zwar unabhängig davon, wie viel Arbeitsspeicher im Rechner steckt. Ganz vollständig steht er Dir allerdings auch dort nicht zur Verfügung: Bildschirmausgabe und Treiber belegen einen halben bis ganzen Gigabyte. Von einer 12-GB-Karte bleiben also grob 11 GB. Passt das Modell nicht hinein, wird ein Teil auf den Hauptprozessor ausgelagert, und dann bricht die Geschwindigkeit ein.
Tipp: Wenn Du nur eine Zahl behalten willst, behalte diese: nutzbarer Speicher, nicht verbauter Speicher.
2. Rechne die Größe eines Modells überschlägig aus
Eine Faustformel für den Überschlag, ohne eine Tabelle zu suchen. Bei der üblichen Kompression Q4 braucht ein Modell ungefähr halb so viele Gigabyte, wie es Milliarden Parameter hat. Ein 8B-Modell landet also bei etwa 4 bis 5 GB, ein 32B-Modell bei ungefähr 18 bis 20 GB. Das ist eine Schätzung der Gewichte, nicht der ganze Bedarf, und die exakte Downloadgröße steht ohnehin an jedem Modell dran. Nimm die Formel zum Vorsortieren und die echte Zahl zum Entscheiden.
Dazu kommt Platz für den Kontext, also für das was Du hineinschreibst und was das Modell sich merkt. Für kurze Gespräche reicht ungefähr ein Gigabyte extra, bei langen Dokumenten wird es deutlich mehr.
Tipp: Plan immer zwei bis drei Gigabyte Luft ein. Ein Modell, das exakt in den Speicher passt, hat keinen Platz mehr für Deine Texte und wird beim ersten längeren Dokument langsam.
3. Ordne Dich einer von vier Klassen zu
Stand August 2026, bei der üblichen Q4-Kompression:
Die Zahlen unten sind nutzbarer Speicher, also bei einer Grafikkarte deren VRAM und bei Apple Silicon der Anteil aus Schritt 1, nicht die Zahl auf dem Karton.
Mit 8 GB nutzbar läuft ein Modell der 7- bis 9-Milliarden-Klasse. Es geht, aber ohne Reserve für lange Texte. Für Zusammenfassungen und kurze Aufgaben reicht es.
Mit 16 GB nutzbar wird es angenehm. Dieselbe Klasse läuft flüssig mit ordentlichem Kontext, oder Du gehst hoch auf 14 Milliarden.
Mit 24 bis 32 GB nutzbar kommst Du an die 32-Milliarden-Klasse. Hier fängt lokal an, inhaltlich ernsthaft zu werden.
Ab 44 GB nutzbar sind Modelle der 70-Milliarden-Klasse möglich, die bei Q4 je nach Modell grob 38 bis 42 GB belegen. Bei Apple Silicon heißt das 64 GB verbauter Speicher als absolute Untergrenze, und die ist knapp: bei zwei Dritteln nutzbarem Anteil sind das rund 43 GB, also gerade so das Modell und kaum Kontext. Komfortabel wird diese Klasse dort erst mit mehr. Das ist die Klasse, bei der man anfängt, den Unterschied zur Cloud nicht mehr bei jeder Antwort zu spüren.
Tipp: Diese Grenzen verschieben sich. Sie verschieben sich in Deine Richtung, weil die Modelle effizienter werden. Ein 30B-Modell von heute schlägt ein 70B-Modell von vor anderthalb Jahren.
4. Wähl innerhalb Deiner Klasse nach Aufgabe
Innerhalb einer Größenklasse gibt es Familien mit unterschiedlichen Stärken. Die Landschaft ändert sich schnell, deshalb hier das Muster statt einer Rangliste, die in drei Monaten falsch ist.
Für allgemeine Textarbeit und Mehrsprachigkeit ist die Qwen-Familie von Alibaba 2026 der solide Standard, unter anderem weil viele ihrer Modelle unter Apache 2.0 stehen und es sie in vielen Größen gibt. Die Lizenz gilt aber pro Modell und pro Fassung, nicht pauschal für eine Familie, also steht der Blick auf die Modellkarte trotzdem an. Fürs Programmieren gibt es innerhalb der Familien eigene Coder-Varianten, die bei gleicher Größe deutlich besser sind als das Allgemeinmodell. Für kleine Geräte und knappen Speicher ist Googles Gemma-Reihe auf Sparsamkeit gebaut. Wer Modelle mit offengelegtem Denkweg will, findet sie bei den Reasoning-Varianten, etwa der gpt-oss-Reihe von OpenAI.
Tipp: Nimm nie ein Allgemeinmodell für Code, wenn eine Coder-Variante derselben Familie existiert. Der Unterschied ist bei gleichem Speicherbedarf größer als der zwischen zwei Familien.
5. Achte auf die Lizenz, bevor es geschäftlich wird
Offene Gewichte heißt nicht automatisch freie Verwendung. Apache 2.0 und MIT sind unkompliziert, damit darfst Du auch kommerziell arbeiten. Andere Lizenzen enthalten Einschränkungen, etwa zur Nutzerzahl oder zur Namensnennung.
Auch privat gelten die Lizenzbedingungen, sie fallen dort nur seltener auf. Sobald ein Kunde im Spiel ist oder das Modell in einem Produkt steckt, wird aus der Formalie ein Risiko.
Tipp: Die Lizenz steht auf der Modellkarte bei Hugging Face. Ein Blick, dreißig Sekunden, erspart eine unangenehme Frage im Vertrieb.
6. Lad zwei Kandidaten statt einen
Der Fehler ist, sich vorher zu entscheiden. Lad zwei Modelle aus Deiner Klasse herunter, die von verschiedenen Familien kommen. Der Platz kostet Dich nichts Dauerhaftes, und der Vergleich an der eigenen Arbeit ist mehr wert als jede Bestenliste.
Tipp: Nimm nicht zwei Größen derselben Familie. Da gewinnt vorhersehbar die größere. Nimm zwei verschiedene Familien in derselben Größe, das ist die Frage, die Du wirklich hast.
7. Bau Dir zehn eigene Testfälle
Sammel zehn Aufgaben aus Deinem Alltag, bei denen Du beurteilen kannst, ob das Ergebnis taugt. Eine Mail umformulieren, ein Protokoll zusammenfassen, eine Tabelle interpretieren, was auch immer Du wirklich tust.
Schreib sie in eine Datei und schick jede an beide Modelle. Nicht bewerten, während Du sie liest. Erst alle zwanzig Antworten einsammeln, dann durchgehen.
Tipp: Nimm Aufgaben mit, die Dir bei den Cloud-Modellen schwerfallen. Genau dort trennt sich, ob lokal für Dich reicht.
8. Miss die Geschwindigkeit, aber die richtige
Zwei Zahlen zählen unterschiedlich viel. Die Zeit bis zum ersten Wort merkst Du im Gespräch sofort. Die Wörter pro Sekunde danach merkst Du nur, wenn sie unter Deine Lesegeschwindigkeit fallen.
Ein Modell, das nach einer Sekunde loslegt und dann zügig weiterschreibt, fühlt sich besser an als eines, das drei Sekunden nachdenkt und dann schneller tippt. Für Massenverarbeitung im Hintergrund ist es genau andersherum, da zählt nur der Durchsatz.
Tipp: Meine persönliche Grenze liegt bei etwa zehn Wörtern pro Sekunde, das ist ungefähr Lesegeschwindigkeit. Wer darunter liegt, empfindet die Arbeit als zäh. Das ist keine gemessene Norm, sondern eine Faustregel; Laufzeitumgebungen melden ohnehin Tokens statt Wörter, und Deutsch braucht pro Wort mehr Tokens als Englisch. Wenn es sich zäh anfühlt, geh eine Klasse runter, das Ergebnis wird insgesamt besser.
9. Entscheide Dich, und schreib die Begründung auf
Wähl das Modell, das bei Deinen zehn Testfällen öfter überzeugt hat. Nicht das mit den besseren Benchmark-Werten, nicht das, das im Forum empfohlen wurde.
Notier in zwei Sätzen, warum. Diese Notiz brauchst Du in drei Monaten, wenn die nächste Generation da ist und Du wieder von vorn vergleichst. Dann hast Du sowohl die Testfälle als auch den Maßstab schon fertig.
Tipp: Bewahr die zehn Testfälle auf. Sie sind Dein persönlicher Benchmark und wertvoller als jede öffentliche Bestenliste, weil sie Deine Arbeit messen und nicht die von jemand anderem.
10. Plan den Wechsel von vornherein ein
Das Modell, das Du heute wählst, ist in einem halben Jahr nicht mehr das beste. Das ist kein Problem, solange Du es nicht fest verdrahtest.
Halt den Modellnamen an einer Stelle in Deiner Konfiguration, nicht verstreut in zehn Skripten. Dann ist der Wechsel eine Zeile. Wer den Namen überall hineinschreibt, wechselt aus Bequemlichkeit nicht mehr und arbeitet zwei Generationen hinterher.
Tipp: Dasselbe Prinzip gilt für Cloud-Modelle. Wie man Modell-Releases überhaupt mitbekommt, statt sie zufällig zu entdecken, steht in Modell-Verfügbarkeit tracken.
Was als nächstes
Wenn Du noch gar kein Modell laufen hast, fang mit Dein erstes lokales KI-Modell in 30 Minuten an. Wenn die Hardware-Frage geklärt ist und es jetzt um den Einsatz im Unternehmen geht, klärt Lokale KI und die DSGVO den rechtlichen Teil. Und wenn Du wissen willst, ob sich der eigene Rechner gegenüber der Cloud überhaupt rechnet, steht die Rechnung in Lokal oder Cloud, die ehrliche Rechnung.
Source
Speicherangaben sind Näherungen bei Q4-Kompression, Stand August 2026, und variieren je nach Modellarchitektur und Kontextlänge. Prüf den konkreten Wert an der Modellkarte.
- Ollama, Modell-Bibliothek mit Größenangaben: https://ollama.com/library
- Hugging Face, Modellkarten mit Lizenz und Gewichten: https://huggingface.co/models
- llama.cpp, Dokumentation zu Quantisierungs-Stufen: https://github.com/ggml-org/llama.cpp