Wie ich ein KI-Modell auf meinem MacBook schneller gemacht habe — und was dabei schiefging
LLM-Modelle sind riesig. Aber nicht jedes Neuron arbeitet bei jedem Wort. Ich habe versucht, die faulen Neuronen zu finden und rauszuwerfen — mit Custom Metal Kernels, Predictor-Netzwerken und einer Schere.
Ich habe in den letzten Tagen an einem Experiment gearbeitet: Kann man ein großes Sprachmodell direkt auf dem eigenen Rechner schneller machen — ohne Cloud, ohne spezielle GPU, nur mit dem was ein MacBook mitbringt?
Die kurze Antwort: Ja. Von 70 auf 88 Token pro Sekunde, bei 21% weniger Speicherverbrauch. Aber der Weg dahin war alles andere als geradlinig. Drei von vier Ansätzen sind gescheitert — und genau das macht die Geschichte interessant.
Was das Problem ist
Große Sprachmodelle wie GPT, Llama oder Qwen bestehen aus Milliarden von Parametern. Wenn man sie lokal laufen lässt, zum Beispiel auf einem MacBook mit M1-Chip, sind zwei Dinge knapp: Arbeitsspeicher und Rechenleistung.
Ein 7-Milliarden-Parameter-Modell in komprimierter Form (4-Bit-Quantisierung) belegt etwa 4,2 Gigabyte. Das passt in den Speicher eines M1 Max mit 64 GB — aber die Geschwindigkeit ist begrenzt. Standard sind etwa 70 Token pro Sekunde. Das ist brauchbar, aber nicht schnell.
Die Frage war: Geht da mehr raus?
Die Grundidee: Faule Neuronen finden
Um zu verstehen, was ich versucht habe, hilft eine Analogie. Man kann sich ein Sprachmodell vorstellen wie ein Großraumbüro mit Tausenden Mitarbeitern. Bei jeder Anfrage — also bei jedem Wort, das das Modell erzeugt — sind theoretisch alle am Schreibtisch. In der Praxis tragen aber nur ein Bruchteil wirklich etwas Sinnvolles bei. Die meisten sitzen da und produzieren Werte nahe Null.
Das Ziel: Die faulen Mitarbeiter identifizieren und entweder überspringen (Sparsity) oder gleich ganz entlassen (Pruning). Beides spart Rechenzeit.
Versuch 1: Neuronen zur Laufzeit überspringen
Der erste Ansatz klingt elegant: Während das Modell arbeitet, schauen wir bei jedem Schritt, welche Neuronen gerade inaktiv sind, und überspringen deren Berechnung.
Dafür habe ich eigene Rechenroutinen geschrieben — sogenannte Metal Kernels, die direkt auf dem GPU-Chip des Mac laufen. Die technische Umsetzung war aufwändig. Es gab einen kritischen Bug, bei dem der Code nur 14 von 3.584 Neuronen berechnete und der Rest stillschweigend Null war. Die Ergebnisse sahen plausibel aus, waren aber Müll. Solche Fehler sind tückisch, weil das Modell trotzdem Text erzeugt — nur schlechteren.
Nach dem Fix funktionierte es korrekt, aber das Ergebnis war ernüchternd: ~70 Token pro Sekunde — praktisch kein Speedup. Das Problem: Jede dieser Spar-Operationen muss einzeln an den GPU-Chip geschickt werden. Der Verwaltungsaufwand für das Überspringen war genauso groß wie das, was man spart.
Stellt euch vor, der Büromanager rennt durch das Großraumbüro und prüft jeden einzelnen Schreibtisch, ob der Mitarbeiter gerade etwas Sinnvolles tut. Die Prüfung dauert so lang wie die Arbeit selbst.
Versuch 2: Vorhersagen, wer faul sein wird
Wenn das Prüfen zur Laufzeit zu langsam ist — was wäre, wenn wir vorhersagen könnten, welche Neuronen inaktiv sein werden, bevor wir sie überhaupt berechnen?
Dafür habe ich pro Schicht im Modell ein kleines Hilfsnetzwerk trainiert. Diese Predictor-Netzwerke sind winzig — wenige hunderttausend Parameter gegenüber Milliarden im Hauptmodell. Sie schauen sich den aktuellen Zustand an und sagen: „In dieser Schicht werden Neuronengruppe 5, 12 und 47 aktiv sein, den Rest kannst du überspringen."
Die Predictor erreichten im Schnitt 89% Trefferquote. Das klingt gut. Aber das Ergebnis war wieder ernüchternd: 71,1 tok/s — kaum schneller als die 70 tok/s Baseline. Der gleiche Verwaltungsaufwand. Egal ob man die faulen Neuronen misst oder vorhersagt — das Hin-und-Her zwischen Steuerlogik und GPU-Chip frisst den Gewinn auf.
Versuch 3: Neuronen permanent entfernen
Nach zwei gescheiterten Ansätzen der Perspektivwechsel: Statt Neuronen zur Laufzeit zu überspringen, sie einfach dauerhaft aus dem Modell entfernen.
Das ist wie eine Restrukturierung im Großraumbüro: Statt jeden Tag zu prüfen, wer nichts tut, kündigt man den dauerhaft Inaktiven und hat danach ein kleineres, aber schnelleres Büro. Kein Verwaltungsaufwand mehr.
Die Umsetzung: Ich habe 20 verschiedene Texte durch das Modell geschickt — Englisch, Deutsch, Spanisch, Programmcode, Mathematik — und gemessen, welche Neuronengruppen dabei durchgehend wenig beitragen. Diese Gruppen werden dann permanent aus den Gewichtsmatrizen herausgeschnitten. Das Ergebnis ist ein kleineres Modell, das ganz normal mit den Standardroutinen läuft.
Und hier wurde es spannend:
| Variante | Größe | Geschwindigkeit | Speedup |
|---|---|---|---|
| Original | 4,2 GB | 69,8 tok/s | — |
| 20% entfernt | 3,6 GB | 79,9 tok/s | +16% |
| 30% entfernt | 3,3 GB | 87,9 tok/s | +28% |
30% der Neuronen raus — und das Modell wird 28% schneller bei 21% weniger Speicherverbrauch. Die Textqualität nimmt merkbar ab, aber für viele Aufgaben bleibt das Modell brauchbar.
Versuch 4: Noch kleiner durch aggressivere Kompression
Motiviert vom Pruning-Erfolg wollte ich noch weiter gehen: Die weniger wichtigen Neuronen nicht entfernen, sondern stärker komprimieren. Statt 4-Bit-Genauigkeit nur noch 2-Bit — das halbiert den Speicher nochmal.
Das Ergebnis: Totalausfall. Das Modell produzierte nur noch Wortmüll.
Der Grund ist im Nachhinein logisch: Das Modell war bereits von 16-Bit auf 4-Bit komprimiert. Von diesen bereits komprimierten 4-Bit-Werten nochmal auf 2-Bit herunterzugehen ist, als würde man ein JPEG-Bild nochmal als JPEG komprimieren — mit jeder Stufe geht überproportional viel Information verloren. Für sinnvolle 2-Bit-Quantisierung müsste man vom unkomprimierten Original ausgehen.
Was ich gelernt habe
1. Permanent kleiner schlägt dynamisch sparen. Auf Apple-Hardware mit dem MLX-Framework ist es effizienter, ein dauerhaft kleineres Modell zu verwenden, als zur Laufzeit clever Berechnungen zu überspringen. Der Verwaltungsaufwand für die Cleverness frisst den Gewinn auf.
2. Nicht alle Neuronen sind gleich wichtig — aber es ist kompliziert. Einfach zu messen, welche Neuronen große Werte produzieren, ist ein schwacher Indikator. In der Forschung gibt es bessere Methoden, die den tatsächlichen Einfluss auf das Ergebnis messen. Die habe ich noch nicht implementiert — das wäre der nächste Schritt.
3. Features sind über viele Neuronen verteilt. Das ist das sogenannte Superpositions-Problem: Ein einzelnes Konzept ist nicht in einem einzelnen Neuron gespeichert, sondern über viele verteilt. Wenn man Neuronen entfernt, kann das unvorhersehbare Auswirkungen haben — ein Neuron, das harmlos aussieht, könnte an zehn verschiedenen Fähigkeiten beteiligt sein.
4. Die Komprimierungskette hat Grenzen. Von 16-Bit auf 4-Bit funktioniert gut. Von 4-Bit auf 2-Bit ist eine Sackgasse. Jede Komprimierungsstufe muss vom bestmöglichen Ausgangsmaterial starten.
Wie es weitergehen könnte
Der größte Hebel wäre eine bessere Methode, um die Wichtigkeit von Neuronen zu messen. Statt nur zu schauen, wie groß ihre Aktivierung ist, könnte man messen, wie stark sich das Endergebnis verändert, wenn man sie entfernt. Dafür braucht man Gradienten — also eine Rückverfolgung, welches Neuron wie viel zum finalen Ergebnis beigetragen hat.
Außerdem: Nicht jede Schicht im Modell hat gleich viel Überfluss. Ein adaptives System, das pro Schicht die optimale Pruning-Rate findet, könnte die Qualität bei gleichem Speedup deutlich verbessern.
Und langfristig wäre die Kombination aus Pruning und Nachtraining (Knowledge Distillation) der vielversprechendste Weg: Erst beschneiden, dann das kleinere Modell vom Original-Modell als Lehrer nachtrainieren lassen. Damit könnte man die Qualitätsverluste des Prunings teilweise wieder aufholen.