Ist die lokale KI langsam? Warum die KI stockt und was hilft

Einleitung

Ist die Lokale KI langsam, obwohl die Hardware eigentlich ausreicht? Sie laden ein 27-Milliarden-Modell auf die Grafikkarte, und die Antwort tröpfelt mit drei Token pro Sekunde. Meistens liegt es nicht an einem kaputten Treiber oder einem falschen Klick. Es ist eine Kette von kleinen Entscheidungen, die alle auf dieselbe Größe einzahlen: Wie viel Speicher muss pro Token gelesen werden?

Auf Ihrem Schreibtisch liegt ein Stapel, der nicht in die Cloud darf. Verträge, Auditberichte, die Gehaltsübersicht für das Personalgespräch nächste Woche. Ausgerechnet bei diesen Dokumenten würde KI am meisten Zeit sparen und ausgerechnet die wollen Sie keinem externen Server anvertrauen. Also der naheliegende Schritt: Modell auf den eigenen Rechner, Daten bleiben im Haus.

Die KI ist auf der Platte. 19 Gigabyte, Qwen3.8-27B in Q4. Die Grafikkarte hat 24 Gigabyte. 19 ist weniger als 24, also sollte das passen. Sie laden das Modell, tippen die erste Frage und dann geht das warten los. Das erste Wort kommt nach acht Sekunden. Danach trudeln die Token einzeln ein, mit deutlichen Pausen. Als tippt da jemand am anderen Ende mit zwei Fingern. Sie kennen das Modell aus der Cloud, da fließt der Text. Hier stockt er.

Der erste Reflex: Modell wechseln. Der zweite: Software tauschen. Beides kann helfen, aber meistens schießen Sie am Ziel vorbei. Die Geschwindigkeit hängt nicht an einem Schalter in den Einstellungen. Sie hängt an einer simplen Rechnung, die bei jedem einzelnen Token neu aufgemacht wird. Wer die versteht, weiß in zehn Minuten, woran es hakt. Wer sie ignoriert, tauscht Hardware und Programme, bis zufällig mal was schneller wird und weiß hinterher immer noch nicht, warum.

In diesem Artikel gehen wir diese Rechnung Schritt für Schritt durch. Mit Zahlen, mit Beispielen und mit den Fallstricken, die in der Praxis lauern. Am Ende des Artikels finden Sie einen interaktiven Token-Rechner. Damit können Sie Ihre eigene Hardware sofort gegenchecken.

Die eine Gleichung, die alles bestimmt

Ein Sprachmodell spuckt ein Text Token für Token aus. Für jedes neue Token muss es einmal komplett durch seine Gewichte wandern. Vom ersten bis zum letzten Layer. Die Gewichte liegen im Speicher, also muss das Modell sie für jedes Token komplett auslesen. Nicht nur einen Teil. Nicht einen Ausschnitt, sondern alles.

Das ist der Schlüssel zu allem. Die Zeit pro Token ist im Grunde nur die Zeit, die der Speicher braucht, um die Modelldatei einmal an die Recheneinheiten zu schieben. Die Recheneinheiten selbst sind dabei fast nie das Problem. Eine moderne Grafikkarte könnte die nötigen Multiplikationen in einem Bruchteil der Zeit schaffen, die sie braucht, um die Zahlen überhaupt erst aus dem Speicher zu holen. Fachleute nennen das ein speichergebundenes Problem. Der Chip wartet auf den Speicher. Nicht umgekehrt. Daraus folgt eine einfache Faustformel:

Token pro Sekunde ≈ Speicherbandbreite ÷ Größe des gelesenen Modells

Haben Sie ein 19-Gigabyte-Modell und einen Speicher, der 1.000 Gigabyte pro Sekunde liefert, kommen Sie auf etwa 50 Token pro Sekunde. Schieben Sie dieselben 19 Gigabyte über einen Speicher, der nur 80 Gigabyte pro Sekunde schafft, landen Sie bei vier. Das ist der komplette Unterschied zwischen „Text fließt“ und „Text tröpfelt“. Und er steht in einer einzigen Zeile.

In der Praxis liegen Sie immer ein Stück unter diesem Optimum, weil Cache-Verwaltung, Sampling und Software-Overhead ihre Zeit fordern. Aber die Größenordnung stimmt. Alle Stellschrauben, die wir uns gleich ansehen, drehen an genau einer von zwei Schrauben dieser Gleichung:

• Entweder Sie machen die Datenmenge kleiner, die gelesen werden muss.
• Oder Sie erhöhen die Geschwindigkeit, mit der gelesen wird. Ein Drittes gibt es nicht.

Erste Frage: Passt das Modell in den Grafikspeicher?

Der Grafikspeicher (VRAM) ist der mit Abstand schnellste Speicher in einem normalen Rechner. Der Arbeitsspeicher auf dem Mainboard ist um ein Vielfaches langsamer. Und die Verbindung zwischen beiden, der PCIe-Bus, bremst das Ganze noch einmal zusätzlich aus. Solange das komplette Modell im VRAM liegt, haben Sie einen schnellen Speicher und eine klare Geschwindigkeit. Sobald es nicht mehr ganz reinpasst, liegt der Rest im Arbeitsspeicher. Und dann ändert sich die Rechnung radikal.

Was dann passiert, nennt sich Offloading. Ein Teil der Layer bleibt auf der Grafikkarte, der Rest wird in den Arbeitsspeicher ausgelagert. Weil aber jedes Token alle Gewichte lesen muss, wandert bei jedem einzelnen Token derselbe Teil über denselben langsamen Bus. Nicht nur einmal beim Laden. Sondern jedes Mal.

Das bremst Sie nicht linear aus. Wenn zehn Prozent des Modells im Arbeitsspeicher liegen, wird es nicht einfach zehn Prozent langsamer. Der langsame Teil diktiert das Tempo. Die Grenze zwischen „passt“ und „passt knapp nicht“ ist die wichtigste Grenze in diesem ganzen Thema. Sie zu kennen, ist wichtiger als jedes andere technische Detail.

Für unser Beispiel aus dem Einstieg sieht das so aus: Qwen3.8-27B bringt als Rohdatei (BF16) rund 54 Gigabyte auf die Waage. Die gängigen GGUF-Dateien liegen als Q4_K_M bei etwa 19 Gigabyte, als Q8_0 bei 28,6 Gigabyte. Auf einer 24-GB-Karte passt Q4 rein, Q8 nicht. Und selbst bei Q4 bleiben nur rund fünf Gigabyte Luft. Die müssen sich Betriebssystem, Bildschirmausgabe und der KV-Cache (dazu kommen wir gleich) teilen.

“Passt” bedeutet hier: das Modell allein. Kontext und Betriebssystem kommen noch dazu. Die Werte stammen aus den Modellkarten der GGUF-Repositories auf Hugging Face, Stand Ende August 2026.

Die Programme zeigen Ihnen diese Aufteilung. In LM Studio heißt der Regler “GPU Offload” und steuert, wie viele Layer auf die Grafikkarte gehen. In Ollama passiert die Verteilung automatisch, und der Befehl ollama ps zeigt danach, wie viel Prozent des Modells auf der CPU und wie viel auf der GPU liegen. Steht dort etwas anderes als 100 Prozent GPU, haben Sie Ihre Antwort gefunden. Alles Weitere ist dann Feinschliff, bis dieser Wert stimmt.

Zweite Frage: Mit wie vielen Bits sind die Gewichte gespeichert?

Ein Modell besteht aus Milliarden von Zahlen, den sogenannten Gewichten. Jede dieser Zahlen belegt im Speicher eine bestimmte Anzahl Bits. Im Training sind das meist 16 Bit. Für den Betrieb auf einer normalen Grafikkarte werden diese Zahlen komprimiert. Das nennt sich Quantisierung. Und genau das ist der Grund, warum aus 54 Gigabyte plötzlich 19 werden.

Weniger Bits pro Gewicht bedeuten weniger Speicherplatz. Ein Q4-Modell ist nicht nur halb so groß wie ein Q8-Modell, es liest auch halb so viel. Bei voller GPU-Auslastung ist es damit annähernd doppelt so schnell. Das ist der größte Hebel, den Sie haben, ohne auch nur einen Cent für neue Hardware auszugeben.

Die Quantisierung erkennen Sie direkt am Dateinamen. GGUF-Dateien tragen den Typ im Namen: Qwen3.8-27B-Q4_K_M.gguf. Die Zahl nach dem Q ist die ungefähre Bitzahl pro Gewicht. Q4_K_M hat sich als der Standard etabliert, weil es den Großteil der Qualität rettet, während die Datei nur noch ein Viertel der Originalgröße hat.

Hier will ich die Sache nicht schöner reden, als sie ist: Quantisierung kostet Qualität. Wie viel, hängt stark vom Modell und Ihrer Aufgabe ab. Bei vielen Modellen ist der Unterschied zwischen Q8 und Q4_K_M im Alltag kaum spürbar. Bei Q3 oder Q2 fängt das Modell aber an zu stottern oder zu halluzinieren.

Ein wichtiger Hinweis am Rande: Bestimmte hybride Modellarchitekturen reagieren auf aggressive Quantisierung empfindlicher als klassische Transformer. Wenn Sie wirklich das letzte Prozent Qualität brauchen, schauen Sie in die Modellkarte (Model Card) auf Hugging Face. Verlassen Sie sich nicht blind auf den Dateinamen.

Deshalb gibt es für dieses Modell gemischte Quantisierungen, die diese Schichten in 8 Bit halten und nur den Rest stärker komprimieren. Der Dateiname allein sagt Ihnen das nicht. Wer die letzte Qualitätsstufe braucht, muss die Modellkarte lesen, nicht nur den Namen.

Es gibt darüber hinaus Quantisierungsformate, die auf bestimmte Hardware zugeschnitten sind. NVFP4 ist ein 4-Bit-Gleitkommaformat von NVIDIA, das auf Karten der Blackwell-Generation einen Vorteil hat, den GGUF-Quantisierungen nicht haben: Die Grafikkarte kann mit diesen Zahlen direkt rechnen, ohne sie vorher in ein anderes Format zurückzuwandeln. Für Qwen3.8-27B existiert eine offizielle NVFP4-Fassung.

Für alle anderen Karten ist das Format uninteressant. Es ist ein Beispiel dafür, wie eng Modelldatei und Hardware zusammenhängen, und warum die Frage “welche Quantisierung” nie ohne die Frage “auf welcher Karte” beantwortet werden kann.

Dritte Frage: Was liegt sonst noch im Speicher?

Das Modell ist nicht das Einzige, das sich im VRAM breit macht. Während der Verarbeitung merkt sich das Modell für jedes bisherige Token bestimmte Zwischenergebnisse (die sogenannten Keys und Values der Attention-Layer). Ohne diesen Zwischenspeicher, den KV-Cache, müsste es bei jedem neuen Token den gesamten bisherigen Text von vorne durchrechnen.

Zwei Dinge müssen Sie über den KV-Cache wissen.

• Erstens: Er wird bei jedem Token mitgelesen. Je länger das Gespräch, desto mehr Cache liegt im Speicher, desto langsamer wird das Modell am Ende einer langen Antwort.
• Zweitens: Sein Platz wird vorab reserviert. Ollama legt beim Start fest, wie viel Speicher für den Cache maximal gebraucht wird. Diese Größe richtet sich stur nach Ihrer eingestellten Kontextlänge.

Das ist die klassische Falle, in die unser Beispiel aus dem Einstieg vermutlich tappt. Qwen3.8-27B unterstützt nativ 262.144 Token Kontext. Wer diese Zahl in den Einstellungen sieht und denkt „viel hilft viel“, reserviert im Hintergrund viele Gigabyte für einen Cache, den er in einem normalen Gespräch nie und nimmer füllt. Bei 24 GB VRAM und einem 19-GB-Modell bleibt dafür schlicht kein Platz.

Die Software löst das Problem, indem sie Teile des Modells in den Arbeitsspeicher schiebt. Aus einem Modell, das locker gepasst hätte, wird plötzlich eines, das offloadet. Der pragmatische Weg: Stellen Sie die Kontextlänge auf einen Wert, den Sie wirklich brauchen (für die meisten Aufgaben reichen 8.000 bis 32.000 Token). Und prüfen Sie danach, ob das Modell noch vollständig auf der GPU liegt.

Der praktische Weg: Kontextlänge auf einen Wert stellen, den Sie tatsächlich brauchen, meist 8.000 bis 32.000 Token, und danach prüfen, ob das Modell noch vollständig auf der GPU liegt.

Vierte Frage: Warum dauert das erste Token nach einer Pause so lange?

Es gibt noch eine dritte Art von Verzögerung, die nichts mit Bandbreite zu tun hat, aber trotzdem nervt. Ollama wirft ein Modell aus dem Speicher, wenn es eine Weile nicht genutzt wird. Standardmäßig nach fünf Minuten. Beim nächsten Aufruf müssen alle Gewichte wieder von der Festplatte geladen werden. Bei 19 Gigabyte kann das, je nach SSD, zwischen ein paar Sekunden und einer halben Minute dauern.

Die Einstellung dafür heißt Keep-Alive. Sie legt fest, wie lange ein Modell im Speicher gehalten wird, nachdem die letzte Anfrage vorbei ist. Sie können das auf 30 Minuten oder auf „unbegrenzt“ stellen. Der Preis dafür: Der Grafikspeicher ist dann dauerhaft blockiert. Auf einem Rechner, der ohnehin als lokaler KI-Server dient, ist „unbegrenzt“ aber genau die richtige Wahl. Warum dieser Punkt so wichtig ist? Weil Sie sonst Äpfel mit Birnen vergleichen:

• Wer das erste Token nach 20 Sekunden bekommt und der Rest dann mit 40 Token pro Sekunde durchrauscht, hat ein reines Ladeproblem.
• Wer das erste Token nach zwei Sekunden bekommt, der Rest dann aber nur mit drei pro Sekunde tröpfelt, hat ein Bandbreitenproblem. Beides fühlt sich für den Nutzer frustrierend ähnlich an. Die Ursachen haben aber absolut nichts miteinander zu tun.

Fünfte Frage: Ist das Ende der Fahnenstange erreicht?

Nehmen wir an, Sie haben alles richtig gemacht: Modell liegt komplett im VRAM, Quantisierung ist auf Q4, Kontextlänge ist vernünftig, Keep-Alive ist gesetzt. Und es ist trotzdem langsamer, als Sie es aus der Cloud gewohnt sind. Dann haben Sie das physikalische Limit erreicht. Ihr Modell liest bereits so schnell, wie es Ihr Speicher hergibt. Die Speicherbandbreite ist eine reine Hardware-Eigenschaft. Sie kaufen sie mit der Karte. Konfigurieren lässt sich daran nichts.

Die Unterschiede zwischen den Hardware-Klassen sind hier oft viel brutaler, als viele erwarten:

Rechnen Sie diese Werte in unsere Formel von oben ein, und die Realität erklärt sich von selbst. 19 GB bei 80 GB/s (Arbeitsspeicher) sind gut vier Token pro Sekunde. Dieselben 19 GB bei 1.000 GB/s (VRAM einer Oberklasse-Karte) sind gut 50 Token pro Sekunde.

Das erklärt auch, warum Apple-Rechner mit viel Unified Memory in dieser Nische eine Sonderrolle spielen. Ihr Speicher ist zwar langsamer als der einer RTX 4090, aber es gibt keine künstliche Grenze zwischen VRAM und RAM. Ein Mac mit 128 GB RAM betreibt ein 70-Milliarden-Modell komplett im schnellen Speicher. Ein PC mit einer 24-GB-Grafikkarte müsste bei dieser Modellgröße längst offloaden. Die Regel ist simpel: Wer große Modelle will, kauft Speichergröße. Wer mittlere Modelle schnell will, kauft Bandbreite. Beides zugleich gibt es nur zu Rechenzentrumspreisen.

Zwei Auswege, die nicht am Speicher hängen

Bis hierhin war die Logik immer: Entweder weniger Daten lesen oder schneller lesen. Es gibt aber zwei Tricks, die diese Logik aushebeln, indem sie die Anzahl der Lesevorgänge pro Token reduzieren.

• Mixture-of-Experts (MoE): So ein Modell besteht aus vielen kleinen Teilmodellen, den sogenannten Experten. Pro Token rechnen aber nur wenige davon (zum Beispiel zwei von acht). Das bedeutet: Es werden auch nur die Gewichte der aktiven Experten gelesen, nicht das ganze Modell. Ein MoE-Modell mit 100 Milliarden Parametern kann pro Token also so schnell sein wie ein normales 10-Milliarden-Modell. Der Haken an der Sache: Das gesamte Modell muss trotzdem im Speicher liegen, weil vorher niemand weiß, welche Experten gleich gebraucht werden. Es ist also extrem schnell im Lesen, aber riesig im Speicher.

• Speculative Decoding: Hier rät ein kleines, flottes Entwurfsmodell mehrere Token im Voraus. Das große Modell prüft diese Vorschläge dann in einem einzigen Rutsch. Wenn das kleine Modell richtig lag, hat das große Modell für vier Token nur einmal seine Gewichte lesen müssen. Ob das in der Praxis hilft, hängt stark davon ab, wie oft das kleine Modell ins Schwarze trifft (bei Code oft hoch, bei kreativem Schreiben eher niedrig).

Ob das hilft, hängt davon ab, wie oft das kleine Modell richtig liegt. Bei Code, bei formelhaftem Text und bei Wiederholungen ist die Trefferquote hoch. Bei kreativem Schreiben mit vielen möglichen Fortsetzungen ist sie niedrig, und dann kann Speculative Decoding sogar bremsen, weil das Entwurfsmodell ebenfalls Speicher und Zeit kostet.

Das Gesamtbild

Wenn wir uns das Beispiel aus dem Einstieg noch mal ansehen: Dass die KI da so gequält getropft hat, hatte vermutlich nicht eine Ursache. Es waren drei, die sich gegenseitig hochgeschaukelt haben: Eine viel zu hohe Kontextlänge, die den Cache aufgebläht hat. Ein Modell, das dadurch teilweise im langsamen Arbeitsspeicher landete. Und ein Keep-Alive-Standard, der es nach jeder kleinen Pause wieder komplett aus dem Speicher geworfen hat.

ür die Cloud. Beides ist teuer, und beides ist vermeidbar. Die Analyse dauert eine Viertelstunde und kostet nichts.

Handlungsschritte

Prüfen Sie die Punkte in dieser Reihenfolge. Jeder Schritt setzt voraus, dass der vorherige stimmt.

1. Wo liegt das Modell? Führen Sie ollama ps aus, während das Modell läuft. Steht dort nicht 100 % GPU, haben Sie Ihren Hauptverdächtigen.
2. Platz nachrechnen. Dateigröße des Modells + KV-Cache + 2 bis 3 GB Puffer für das System. Liegt die Summe über Ihrem VRAM, passt es nicht.
3. Dateinamen checken. Q8 ist doppelt so groß wie Q4 und liest auch doppelt so viel. Q4_K_M ist Ihr Default-Startpunkt.
4. Kontextlänge deckeln. Für normale Gespräche und Dokumente reichen 8.000 bis 16.000 Token. Die Maximalwerte in den Modellen sind technische Obergrenzen, keine Empfehlungen.
5. Keep-Alive prüfen. Wenn das erste Token ewig dauert, der Rest dann aber schnell kommt, stellen Sie Keep-Alive auf 30 Minuten oder unbegrenzt.
6. Realitätscheck Bandbreite. Teilen Sie die Bandbreite Ihres Speichers durch die Modellgröße. Liegen Sie in der Praxis bei etwa 60 % dieses theoretischen Werts, haben Sie das Maximum herausgeholt. Mehr geht mit dieser Hardware physikalisch nicht.
7. Spezialtricks testen. Erst wenn Punkt 1 bis 6 sitzen, testen Sie MoE-Modelle oder Speculative Decoding. Messen Sie vorher und nachher mit exakt demselben Prompt, sonst wissen Sie nicht, ob es geholfen hat.

Prüffragen für den eigenen Rechner

• Welchen Wert zeigt ollama ps in der Spalte für die Prozessorverteilung?
• Wie groß ist die Modelldatei in Gigabyte, und wie viel VRAM hat die Karte?
• Welche Kontextlänge ist eingestellt, und wie viel davon wird in einer typischen Anfrage tatsächlich genutzt?
• Wie lange dauert das erste Token, und wie schnell kommen die folgenden?
• Welche Speicherbandbreite hat die Hardware, und wie weit liegt die gemessene Geschwindigkeit darunter?

Ist die lokale KI langsam? Wo es schwierig bleibt

Zwei Dinge kann ich Ihnen mit diesem Artikel nicht abnehmen: Erstens: Wie viel Qualität eine Quantisierung konkret kostet, ist von Modell zu Modell verschieden. Das müssen Sie für Ihre ganz konkrete Aufgabe einfach mal ausprobieren. Zweitens: Die Zahlen in diesem Text gelten für den Stand Ende August 2026. In der lokalen KI-Szene ändern sich Modelle, Formate und Software im Wochentakt.

Was bleibt, ist die eine Gleichung. Wer die im Kopf hat, kann jedes neue Modell und jedes neue Datenblatt in Sekunden auf die einzige Frage reduzieren, die wirklich zählt: Wie viel muss pro Token gelesen werden, und wie schnell kann mein Speicher das liefern?

Lokale KI wird genau dort langsam, wo sie mehr lesen muss, als der Speicher hergibt. Wo das bei Ihnen im System passiert, steht in keinem Handbuch. Es steht in Ihrem ollama ps.

Tokenrechner

FAQ

Quellen und Anmerkungen

• Dateigrößen für Qwen3.8-27B (Q4_K_M rund 19 GB, Q8_0 rund 28,6 GB, BF16 rund 54 GB): Modellkarte ggml-org/Qwen3.8-27B-GGUF, Hugging Face, Stand August 2026.
• Architektur von Qwen3.8 (hybride Gated-DeltaNet- und Attention-Layer, 262K nativer Kontext, Multi-Token-Prediction-Kopf): Modellkarte Qwen/Qwen3.8-27B. Die NVFP4-Fassung ist in der Unsloth-Dokumentation zu Qwen3.8 verzeichnet.
• Quantisierungsempfindlichkeit der Gated-DeltaNet-Schichten: Modellkarte empero-ai/Qwen3.8-27B-Ridge-GGUF, Angabe eines einzelnen Anbieters, nicht unabhängig bestätigt.
• Keep-Alive-Standard von fünf Minuten und die Anzeige von ollama ps: Ollama-FAQ.
• Speicherbandbreiten: RTX 5090 mit 1.792 GB/s und RTX 4090 mit 1.008 GB/s laut KitGuru-Test der RTX 5090; Apple M4 Max mit 546 GB/s laut Notebookcheck-Datenvergleich. Übrige Werte sind gerundete Herstellerangaben der jeweiligen Speichergenerationen.