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

Einleitung

Ist die Lokale KI langsam, obwohl die Hardware stimmt: Ein 27-Milliarden-Modell auf der eigenen Grafikkarte, und die Antwort tröpfelt mit drei Token pro Sekunde. Die Ursache ist fast nie ein einzelner Fehler. Sie ist eine Kette von Entscheidungen, die alle dieselbe Größe bewegen: wie viel Speicher pro Token gelesen wird.

Auf Ihrem Schreibtisch liegt ein Stapel, der nicht in die Cloud darf. Verträge mit Kundendaten, ein Auditbericht, die Gehaltsübersicht für das Personalgespräch nächste Woche. Genau die Dokumente, bei denen KI am meisten Zeit sparen würde, sind die, die Sie keinem amerikanischen Server anvertrauen wollen. Also der naheliegende Schritt: ein Modell auf dem eigenen Rechner, die Daten bleiben im Haus.

Die Datei ist heruntergeladen, 19 Gigabyte, Qwen3.8-27B in einer Q4-Variante. Die Grafikkarte hat 24 Gigabyte, 19 GB ist kleiner als 24 GB, also wird es passen… Sie laden das Modell, stellen die erste Frage, und dann warten Sie. Das erste Wort kommt nach acht Sekunden. Danach erscheinen die Token einzeln, mit deutlichen Pausen, als würde jemand am anderen Ende mit zwei Fingern tippen. Sie kennen dieses Modell aus der Cloud, dort fließt der Text. Hier stockt er.

Der erste Reflex ist meistens, das Modell zu wechseln. Der zweite, die Software zu wechseln. Beides kann helfen, beides geht am Kern vorbei. Denn die Geschwindigkeit eines lokalen Sprachmodells hängt nicht an einem Schalter, sondern an einer Rechnung, die bei jedem einzelnen Token neu aufgeht. Wer diese Rechnung versteht, weiß in zehn Minuten, woran es bei ihm hängt. Wer sie nicht versteht, tauscht Hardware, Modelle und Programme, bis zufällig etwas schneller wird, und weiß hinterher nicht, warum.

Dieser Artikel geht die Rechnung durch. Die Grafiken hier sind eigene Nachzeichnungen der Mechanik, die helfen sollen das komplexe Thema besser zu verstehen. Für alle die die Theorie auch mal testen wollen, für die PErsoinen gibt es ein Tokenrechner die das verständnis nachhlating macht.

Dieser Artikel geht die Rechnung durch, mit Zahlen, Rechenbeispielen und den Stellen, an denen die Sache schwieriger ist, als sie klingt. Die Grafiken sind Nachzeichnungen der Mechanik und sollen das komplexe Thema greifbar machen. Und wer die Theorie nicht nur lesen, sondern ausprobieren will, findet auch einen interaktiven Token Rechner. Hier wird die Möglichkeit gegeben eigene Hardware und Modell einzustellen und zusehen, wo die Geschwindigkeit bleibt.

Die eine Gleichung, die alles bestimmt

Ein Sprachmodell erzeugt Text Token für Token. Für jedes neue Token muss es alle seine Gewichte einmal durchlaufen, und zwar vollständig, vom ersten bis zum letzten Layer. Die Gewichte liegen im Speicher. Das Modell liest sie also für jedes Token komplett aus. Nicht einen Teil, nicht einen Ausschnitt, sondern alles.

Diese Eigenschaft ist der Schlüssel zu allem, was folgt. Die Zeit pro Token ist im Wesentlichen die Zeit, die der Speicher braucht, um die gesamte Modelldatei einmal an die Recheneinheiten zu liefern. Die Recheneinheiten selbst sind dabei selten der Engpass. Eine moderne Grafikkarte kann die Multiplikationen für ein Token in einem Bruchteil der Zeit erledigen, die sie braucht, um die Zahlen dafür aus dem Speicher zu holen. Man spricht von einem speichergebundenen Problem. Der Chip wartet auf den Speicher, nicht umgekehrt.

Daraus folgt eine einfache Faustformel:

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

Wer 19 Gigabyte Modell hat und einen Speicher, der 1.000 Gigabyte pro Sekunde liefert, bekommt im theoretischen Optimum etwa 50 Token pro Sekunde. Wer dieselben 19 Gigabyte über einen Speicher schiebt, der nur 80 Gigabyte pro Sekunde schafft, landet bei etwa vier. Das ist der ganze Unterschied zwischen “fließt” und “tröpfelt”, und er steht in einer Zeile. Die häufigste Antwort auf die Frage, warum lokale KI langsam läuft, ist damit schon gegeben: Es wird mehr gelesen, als der Speicher liefern kann.

Die Praxis liegt immer unter dem Optimum, weil Cache-Verwaltung, Sampling und Software-Overhead Zeit kosten. Aber die Größenordnung stimmt, und sie erklärt, warum alle Stellschrauben, die im Folgenden kommen, auf eine von zwei Seiten der Gleichung wirken. Entweder Sie verringern, was gelesen wird. Oder Sie erhöhen, wie schnell gelesen werden kann. Ein Drittes gibt es nicht.

Erste Frage: Passt das Modell in den Grafikspeicher?

Der Grafikspeicher, das VRAM auf der Karte, ist der schnellste Speicher, den ein normaler Rechner hat. Der Arbeitsspeicher auf dem Mainboard ist um ein Vielfaches langsamer, und die Verbindung zwischen beiden, der PCIe-Bus, ist noch einmal langsamer als der Arbeitsspeicher selbst. Solange das ganze Modell im VRAM liegt, gibt es einen Speicher und eine Geschwindigkeit. Sobald es nicht mehr passt, liegt der Rest im Arbeitsspeicher, und die Rechnung ändert sich grundlegend.

Was dann passiert, heißt Offloading. Ein Teil der Layer bleibt auf der Grafikkarte, ein Teil wird in den Arbeitsspeicher ausgelagert und dort von der CPU verarbeitet oder über den Bus nachgeladen. Und weil jedes Token alle Gewichte liest, wandert bei jedem Token derselbe Teil über denselben langsamen Bus. Nicht einmal beim Laden, sondern jedes Mal.

Die Folge ist keine lineare Verlangsamung. Wenn zehn Prozent des Modells im Arbeitsspeicher liegen, wird es nicht zehn Prozent langsamer, sondern der langsame Teil bestimmt das Tempo. Ein Modell, das zu 90 Prozent im VRAM liegt, kann auf einen Bruchteil der Geschwindigkeit fallen, die es ganz im VRAM hätte. Die Grenze zwischen “passt” und “passt knapp nicht” ist die wichtigste Grenze in diesem ganzen Thema. Sie zu kennen, ist wichtiger als jedes andere Detail.

Für das Beispiel aus dem Einstieg sehen die Zahlen so aus. Qwen3.8-27B ist Mitte August 2026 erschienen, die Rohdatei in BF16 hat rund 54 Gigabyte. Die gängigen GGUF-Dateien liegen als Q4_K_M bei rund 19 Gigabyte und als Q8_0 bei rund 28,6 Gigabyte. Auf einer Karte mit 24 Gigabyte passt Q4 hinein, Q8 nicht. Und selbst bei Q4 bleiben nur rund fünf Gigabyte übrig, die sich Betriebssystem, Bildschirmausgabe und der noch zu besprechende KV-Cache teilen müssen. Wer hier großzügig eine lange Kontextlänge einstellt, hat sein Modell wieder aus dem VRAM gedrängt, ohne es zu merken.

“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 Gewichten. Jede dieser Zahlen belegt eine bestimmte Anzahl Bits im Speicher. Im Training sind das üblicherweise 16 Bit pro Gewicht. Für den Betrieb auf einer normalen Grafikkarte werden die Gewichte auf weniger Bits reduziert. Das nennt sich Quantisierung, und es ist der Grund, warum aus 54 Gigabyte 19 werden.

Weniger Bits pro Gewicht bedeutet weniger Speicherplatz und, nach der Gleichung von oben, weniger zu lesen pro Token. Ein Q4-Modell ist nicht nur halb so groß wie ein Q8-Modell, es liest auch halb so viel und ist bei voller GPU-Auslastung annähernd doppelt so schnell. Das ist keine Optimierung am Rand, sondern der größte Hebel, den Sie ohne neue Hardware haben.

Die Quantisierung erkennen Sie am Dateinamen. GGUF-Dateien, das verbreitete Format für llama.cpp, Ollama und LM Studio, tragen den Quantisierungstyp direkt im Namen: Qwen3.8-27B-Q4_K_M.gguf oder Qwen3.8-27B-Q8_0.gguf. Die Zahl nach dem Q ist die ungefähre Bitzahl pro Gewicht. Die Buchstaben dahinter beschreiben das Verfahren. K steht für eine Methode, die verschiedene Teile des Modells unterschiedlich fein quantisiert, M für eine mittlere Genauigkeitsstufe innerhalb dieser Methode. Q4_K_M hat sich als Standardempfehlung etabliert, weil es den größten Teil der Qualität bei etwa einem Viertel der Originalgröße behält.

Hier ist die Stelle, an der ich die Sache nicht einfacher machen will, als sie ist. Quantisierung kostet Qualität. Wie viel, hängt vom Modell, vom Verfahren und von der Aufgabe ab. Bei vielen Modellen ist der Unterschied zwischen Q8 und Q4_K_M im Alltag kaum spürbar, bei Q3 und Q2 wird er deutlich. Bei Qwen3.8 kommt eine Besonderheit dazu: Die Architektur verwendet neben klassischen Attention-Layern sogenannte Gated-DeltaNet-Schichten, und deren interner Zustand reagiert nach Angaben eines Quantisierungsanbieters empfindlicher auf niedrige Bitzahlen als der Rest des Modells. 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, was im VRAM liegt. Während der Verarbeitung merkt sich das Modell für jedes bisherige Token bestimmte Zwischenergebnisse, die sogenannten Keys und Values der Attention-Layer. Ohne sie müsste es bei jedem neuen Token den gesamten bisherigen Text erneut durchrechnen. Dieser Zwischenspeicher heißt KV-Cache, und er liegt neben dem Modell auf derselben Karte.

Zwei Eigenschaften des KV-Cache sind für die Geschwindigkeit entscheidend. Erstens wird er bei jedem Token mitgelesen. Je länger das Gespräch, desto mehr Cache liegt vor, desto mehr wird pro Token gelesen, desto langsamer wird das Modell im Laufe einer langen Antwort. Das ist der Grund, warum viele lokale Modelle am Ende einer langen Ausgabe spürbar träger sind als am Anfang. Zweitens wird sein Platz vorab reserviert. Ollama legt beim Start des Modells fest, wie viel Speicher für den Cache vorgesehen ist, und diese Größe richtet sich nach der eingestellten Kontextlänge.

Das ist die Falle, in die das Beispiel aus dem Einstieg vermutlich getappt ist. Qwen3.8-27B unterstützt nativ 262.144 Token Kontext. Wer diese Zahl in den Einstellungen sieht und denkt, mehr sei besser, reserviert bei einem 27-Milliarden-Modell viele Gigabyte für einen Cache, den er in einem normalen Gespräch nie füllt. Bei 24 Gigabyte VRAM und einem 19-Gigabyte-Modell bleibt dafür kein Platz. Die Software löst den Konflikt, indem sie Teile des Modells in den Arbeitsspeicher verschiebt. Aus einem Modell, das gepasst hätte, wird eines, das offloadet. Die Ausgabe in ollama ps zeigt dann eine CPU/GPU-Aufteilung, obwohl die Modelldatei kleiner ist als der Grafikspeicher.

Wie groß der Cache wird, hängt von der Architektur ab. Die Faustregel lautet: Er wächst linear mit der Kontextlänge, und sein Umfang pro Token hängt von der Zahl der Layer und der Attention-Köpfe ab. Moderne Architekturen mit Grouped-Query-Attention oder hybriden Schichten brauchen deutlich weniger Cache pro Token als ältere. Ein konkreter Wert lässt sich für ein bestimmtes Modell ausrechnen oder in der Software ablesen. Pauschal lässt er sich nicht angeben, und ich werde hier keine Zahl erfinden, die für Ihr Modell nicht stimmt. 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 eine Verzögerung, die nichts mit Bandbreite zu tun hat und trotzdem als Langsamkeit wahrgenommen wird. Ollama entlädt ein Modell nach einer Zeit ohne Anfragen aus dem Speicher, 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 Laufwerk zwischen wenigen Sekunden und einer halben Minute dauern. Wer das Modell alle zehn Minuten einmal befragt, bezahlt diesen Kaltstart jedes Mal.

Die Einstellung heißt Keep-Alive. Sie legt fest, wie lange ein Modell nach der letzten Anfrage geladen bleibt, und lässt sich auf einen längeren Zeitraum oder auf unbegrenzt setzen. Der Preis ist, dass der Grafikspeicher dann dauerhaft belegt ist. Auf einem Rechner, der nebenbei noch etwas anderes tun soll, ist das eine bewusste Abwägung. Auf einem Rechner, der als lokaler KI-Server dient, ist unbegrenzt die richtige Wahl.

Dieser Punkt ist deshalb wichtig, weil er zeigt, wie leicht sich Ursachen verwechseln lassen. Wer das erste Token nach 20 Sekunden bekommt und die restlichen mit 40 Token pro Sekunde, hat kein Bandbreitenproblem, sondern ein Ladeproblem. Wer das erste Token nach zwei Sekunden bekommt und die restlichen mit drei pro Sekunde, hat ein Bandbreitenproblem. Die beiden Symptome fühlen sich ähnlich an. Sie haben nichts miteinander zu tun.

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

Angenommen, das Modell liegt vollständig im VRAM, die Quantisierung ist auf Q4, die Kontextlänge ist vernünftig, Keep-Alive ist gesetzt. Und es bleibt trotzdem langsamer, als Sie es erwarten. Dann liest Ihr Modell bereits so schnell, wie es Ihr Speicher hergibt. Das ist die Speicherbandbreite, und sie ist eine reine Hardware-Eigenschaft. Sie kaufen sie mit der Karte. Konfigurieren lässt sie sich nicht.

Die Unterschiede zwischen Hardware-Klassen sind hier größer, als viele erwarten. Die folgende Tabelle nennt typische Größenordnungen. Es sind Herstellerangaben und Richtwerte, keine Messungen, und je nach Konfiguration weichen reale Werte ab.

Setzen Sie die Werte in die Gleichung von oben ein, und die Größenordnungen aus dem Einstieg ergeben sich von selbst. 19 Gigabyte bei 80 GB/s sind gut vier Token pro Sekunde, und das ist genau die Situation, wenn ein Modell im Arbeitsspeicher liegt. Dieselben 19 Gigabyte bei 1.000 GB/s sind gut 50 Token pro Sekunde, und das ist die Situation, wenn es im VRAM einer Oberklasse-Karte liegt. Zwischen beiden liegt kein Faktor zwei, sondern ein Faktor zwölf. Das ist der Grund, warum die Frage “passt es ins VRAM” alle anderen Fragen dominiert.

Die Tabelle erklärt auch, warum Apple-Rechner mit viel Unified Memory in dieser Diskussion eine Sonderrolle spielen. Ihr Speicher ist langsamer als der einer Oberklasse-Grafikkarte, aber er ist groß, und es gibt keine Grenze zwischen VRAM und RAM. Ein 128-Gigabyte-Mac betreibt ein 70-Milliarden-Modell vollständig im schnellen Speicher, wo ein PC mit einer 24-Gigabyte-Karte längst offloaden müsste. Er ist dann nicht schneller als die Grafikkarte, aber er ist um ein Vielfaches schneller als die Grafikkarte im Offloading-Betrieb. Wer große Modelle will, wählt Speichergröße. Wer mittlere Modelle schnell will, wählt Bandbreite. Beides zugleich gibt es nur zu Rechenzentrumspreisen.

Zwei Auswege, die nicht am Speicher hängen

Bis hierhin lautete die Logik: weniger lesen oder schneller lesen. Es gibt zwei Techniken, die diese Logik unterlaufen, indem sie die Zahl der Lesevorgänge pro erzeugtem Token senken. Beide sind Eigenschaften des Modells oder der Software, nicht der Hardware, und beide gelten nicht überall.

Die erste ist die Mixture-of-Experts-Architektur. Ein solches Modell besteht aus vielen Teilmodellen, den Experten, und einem Verteiler, der für jedes Token entscheidet, welche davon zuständig sind. Pro Token rechnen dann nur wenige Experten, etwa zwei von acht oder acht von 128. Gelesen werden also nur die Gewichte der aktiven Experten, nicht das ganze Modell. Ein MoE-Modell mit 100 Milliarden Parametern, von denen pro Token zehn Milliarden aktiv sind, liest pro Token so viel wie ein dichtes 10-Milliarden-Modell und ist entsprechend schnell.

Der Haken liegt im Speicherbedarf. Das ganze Modell muss trotzdem geladen sein, weil vorher niemand weiß, welche Experten das nächste Token braucht. Ein MoE-Modell ist also schnell im Lesen, aber groß im Speicher. Es passt seltener ins VRAM als ein dichtes Modell gleicher Leistung. Wer wenig Grafikspeicher, aber viel Arbeitsspeicher hat, kann davon profitieren, weil die Offloading-Strafe bei MoE-Modellen kleiner ausfällt: Es wandern pro Token nur die aktiven Experten über den Bus. Wer eine Karte mit 24 Gigabyte und 32 Gigabyte Arbeitsspeicher hat, ist mit einem dichten 27-Milliarden-Modell meist besser bedient. Die Rechnung muss jeder für seine Konfiguration selbst aufstellen.

Die zweite Technik heißt Speculative Decoding. Dabei rät ein kleines, schnelles Entwurfsmodell mehrere Token im Voraus, und das große Modell prüft diese Vorschläge in einem einzigen Durchlauf statt in mehreren. Stimmen die Vorschläge, hat das große Modell für vier Token nur einmal seine Gewichte gelesen. Stimmen sie nicht, wird die Sequenz ab dem ersten Fehler verworfen, und es hat nichts verloren außer der Zeit des Entwurfsmodells. Die Ausgabe ist mathematisch identisch mit der des großen Modells allein. Es wird nur schneller erreicht.

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. Qwen3.8-27B bringt einen eigenen Multi-Token-Prediction-Kopf mit, der genau diese Aufgabe übernimmt, ohne dass ein zweites Modell geladen werden muss. Je nach Anbieter liegt er in der GGUF-Datei selbst oder als eigene kleine Datei daneben. Ob Ihre Software ihn nutzt, steht in deren Dokumentation, nicht im Modellnamen. Auch hier gilt: Es ist eine Option, kein Standard, und sie trifft nicht auf jede Konfiguration zu.

Das Gesamtbild

Die fünf Fragen bauen aufeinander auf, und ihre Reihenfolge ist keine Willkür. Sie beginnt bei der Frage mit dem größten Effekt und endet bei der, die sich nicht mehr ändern lässt.

Dass im Eingangsbeispiel die lokale KI langsam war, hatte vermutlich keine einzelne Ursache. Er hatte drei, die sich addierten: eine Kontextlänge, die den Cache zu groß gemacht hat, ein Modell, das dadurch teilweise im Arbeitsspeicher lag, und ein Keep-Alive-Standard, der es nach jeder Pause wieder entladen hat. Jede der drei allein wäre ärgerlich gewesen. Zusammen ergaben sie einen Rechner, der aussah, als sei er für die Aufgabe zu schwach. Das war er nicht. Er wurde nur falsch befragt.

Wer diese Kette nicht kennt, hat zwei Möglichkeiten. Er kann neue Hardware kaufen und stellt dann fest, dass sich das Problem mit derselben Konfiguration an anderer Stelle wiederholt. Oder er gibt lokale Modelle auf und zahlt fü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. Stellen Sie fest, wo das Modell liegt. In Ollama: ollama ps ausführen, während das Modell geladen ist. Steht dort nicht 100 Prozent GPU, liegt hier die Ursache. In LM Studio: den GPU-Offload-Regler prüfen und beim Laden auf die Meldung achten, ob alle Layer auf die Grafikkarte passen.
2. Rechnen Sie den Platz nach. Dateigröße des Modells plus Cache plus zwei bis drei Gigabyte für das System. Liegt die Summe über dem VRAM, passt es nicht. Verringern Sie zuerst die Kontextlänge, dann die Quantisierung, dann die Modellgröße.
3. Lesen Sie den Dateinamen. Q8 ist doppelt so groß und liest doppelt so viel wie Q4. Wer Q8 auf einer Karte betreibt, in die nur Q4 passt, hat kein Hardware-Problem, sondern ein Auswahlproblem. Q4_K_M ist der Ausgangspunkt, von dem aus Sie in beide Richtungen probieren.
4. Setzen Sie die Kontextlänge auf den tatsächlichen Bedarf. Für Gespräche und kurze Dokumente reichen 8.000 bis 16.000 Token. 32.000 sind für die meisten Aufgaben viel. Die Maximalwerte moderner Modelle sind Obergrenzen, keine Empfehlungen.
5. Prüfen Sie Keep-Alive. Wenn das erste Token lange dauert und die folgenden schnell kommen, ist die Ladezeit das Problem. Setzen Sie Keep-Alive auf 30 Minuten oder unbegrenzt, wenn der Rechner sonst nichts anderes braucht.
6. Vergleichen Sie mit der Bandbreite. Teilen Sie die Bandbreite Ihres Speichers durch die Modellgröße. Liegen Sie nach den Schritten eins bis fünf bei etwa der Hälfte dieses Werts, ist alles in Ordnung. Mehr geht mit dieser Hardware nicht. Was Sie dann noch gewinnen, gewinnen Sie durch ein anderes Modell, nicht durch eine andere Einstellung.
7. Testen Sie MoE-Modelle und Speculative Decoding gezielt. Beides sind Wetten auf Ihre Aufgabe und Ihre Speicheraufteilung, keine Pauschalgewinne. Messen Sie Token pro Sekunde vorher und nachher mit derselben Anfrage, sonst wissen Sie hinterher 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 lassen sich mit diesem Artikel nicht erledigen. Erstens: Wie viel Qualität eine Quantisierung kostet, ist von Modell zu Modell verschieden und für Ihre Aufgabe nur durch Ausprobieren zu klären. Es gibt Vergleichstabellen, aber sie messen Aufgaben, die nicht Ihre sind. Zweitens: Die Zahlen in diesem Text gelten für den Stand Ende August 2026. Modelle, Formate und Software ändern sich in diesem Bereich monatlich. Was bleibt, ist die Gleichung. Wer sie im Kopf hat, kann jede neue Modellkarte und jedes neue Datenblatt in Sekunden auf die eine Frage zurückführen, die zählt: Wie viel muss pro Token gelesen werden, und wie schnell kann Ihr Speicher das liefern.

Lokale KI wird langsam genau dort, wo sie mehr lesen muss. Wo das bei Ihnen liegt, steht in keiner Anleitung. 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.

Dieser Artikel folgt meiner Vorarbeit und meinem Konzept. Sie spiegelt meine Haltung wider. Der Artikel ist von mir geprüft und wird von mir verantwortet. KI-Unterstützung gab es bei der Vorformulierung der Texte, bei Grafiken und bei der Recherche.