Im ersten Teil habe ich durchgerechnet, was lokale KI kostet. Diesmal wollte ich verstehen, wie so ein lokaler KI-Stack überhaupt zusammensteckt: Was ist das Modell, was eine Serving-Engine, was ein Agent, was ein Workspace wie Odysseus, und wie reden diese Teile miteinander?
Damit das nicht graue Theorie bleibt, habe ich es auf meinem MacBook wirklich aufgesetzt und gemessen. Zwei ehrliche Vorbemerkungen: Dieses MacBook ist nicht mein Ziel-Setup, es ist nur das Testlabor. Und der erste Anlauf ist spektakulär schiefgegangen.
Ich habe das Aufsetzen meiner KI überlassen, dem Modell, das mir beim Programmieren hilft. Und die hat sich gleich zu Beginn vergriffen: Sie hat auf den freien Festplatten-Platz geschaut, dort waren noch reichlich Gigabyte frei, und daraus geschlossen, dass ein riesiges Modell problemlos läuft. Sie hat es geladen, und kurz darauf war der ganze Rechner eingefroren.
Der Denkfehler in einem Satz: Festplatte ist nicht Arbeitsspeicher. Die Festplatte ist das Lager, da liegt das Modell als Datei. Aber zum Rechnen muss das Modell komplett in den Arbeitsspeicher, und der ist viel kleiner und meistens schon halb von anderen Programmen belegt. Ein 18-Gigabyte-Modell in einen Arbeitsspeicher zu zwingen, in dem nur ein paar Gigabyte frei sind, kann nicht gutgehen.
Mir war von vornherein klar, dass das nicht läuft, das hätte ich nie selbst probiert. Trotzdem ist es am Ende meine Verantwortung. Genau das passiert, wenn man der KI das komplette Denken überlässt und sich nicht vorher einen ganzen Plan geben lässt, den man dann in Ruhe gegencheckt. Die Maschine ist schnell und fleißig, aber sie übersieht das Offensichtliche, wenn niemand drüberschaut. Für mich die wichtigste Lehre dieses Tages, und sie hat mit lokaler KI im Grunde gar nichts zu tun.
Bevor irgendetwas läuft, muss man die Teile auseinanderhalten. Ich habe sie selbst lange durcheinandergeworfen. Vier Schichten, von unten (am nächsten an der Hardware) nach oben (am nächsten an dir):
Dazu kommt eine fünfte Sache, quer zu allem: die Integrationen. Wenn der Agent in deine Dateien schauen, im Web suchen oder eine Datenbank abfragen soll, dockt er solche Werkzeuge als eigene kleine Programme an, oft über einen Standard namens MCP. Das Schöne daran: Sie laufen abgetrennt, können also nichts kaputt machen, und genau dieses saubere Andocken ist später das Rückgrat meines eigenen Projekts.
Jetzt das Bild, das mir lange gefehlt hat. Du tippst oben ins Cockpit, und die Frage wandert Schicht für Schicht nach unten zum Modell und die Antwort wieder hoch. Das Entscheidende: Zwischen den Schichten sitzt überall dieselbe Standard-Schnittstelle, eine Art genormter Stecker. Deshalb kann man jedes Teil einzeln austauschen, ohne den Rest umzubauen.
Diagramm 1 · Oben das Cockpit auf deinem MacBook, unten Motor und Modell. Dazwischen ein genormter Stecker, der beides verbindet, egal ob alles auf einem Gerät läuft oder die untere Hälfte auf einer eigenen Box.
Eine Frage wandert also so: Du tippst ins Cockpit. Das gibt sie an den Agenten, der die Aufgabe in viele kleine Schritte zerlegt und bei Bedarf Integrationen dazuholt (etwa deine Dateien). Für jeden Schritt schickt er eine Anfrage durch den genormten Stecker an die Serving-Engine, die das Modell rechnen lässt und die Antwort zurückgibt. Genau dieselbe Schnittstelle bedeutet: Es ist dem Cockpit egal, ob die Engine nebenan auf demselben Mac läuft oder auf einer Maschine im Nebenzimmer.
Damit zur Frage, die mich eigentlich umtreibt. Der genormte Stecker erlaubt zwei Aufbauten:
Variante B ist mein Ziel, und zwar aus einem einfachen Grund: Mein MacBook ist ein gutes Arbeitsgerät, aber für KI ist es unterdimensioniert, und das soll es auch bleiben. Ich will nicht, dass mir ein Modell den Laptop lahmlegt, während ich arbeite. Stattdessen soll eine dedizierte Box stehen, die nichts anderes tut als rechnen, headless, und ich greife vom MacBook darauf zu. Welche Box (das schnelle Mac Studio oder der rechenstarke, koppelbare Spark) ist eine spätere, eigene Geld-Entscheidung, die habe ich in Teil 1 schon abgewogen. Wichtig ist hier nur: Die Architektur ist für beide dieselbe, und der Wechsel vom Test-Laptop auf die Box ist später kein Umbau, sondern eine Adresse in einer Einstellung.
Damit es nicht bei der Theorie bleibt, habe ich Variante A auf dem MacBook (M4 Pro, 24 GB Speicher) wirklich laufen lassen. Zwei Engines, Ollama und MLX, ein paar kleine Modelle, und als Härtetest ein echter kleiner Programmierfehler aus meinem Buchungs-Projekt. Die Zahlen sind nicht der Kern dieses Texts, aber sie erden ihn.
| Modell (klein, freie Lizenz) | Größe | Tempo* | Passt in den Speicher? |
|---|---|---|---|
| Qwen-Coder 1,5B | 1 GB | sehr schnell | ja, locker |
| Qwen-Coder 3B | 1,9 GB | schnell | ja, locker |
| Phi-4-mini | 2,5 GB | schnell | ja, locker |
| Qwen-Coder 7B | 4,7 GB | okay | nur wenn genug frei ist |
| Qwen-Coder 30B | 18 GB | — | nein → genau hier kam der Crash |
*Gemessen wurde getrennt das Einlesen (Prefill) und das Tippen (Decode). Kurz: kleiner = schneller. Die ausführliche Tabelle mit echten Tokens pro Sekunde steht in den Notizen zum Projekt.
Der lehrreichste Teil war aber nicht das Tempo, sondern ob die Modelle den Fehler überhaupt finden. Hier muss ich eine missverständliche Formulierung von vorhin klarstellen: „verfehlt" heißt nicht, dass das Modell den Fehler nicht reparieren konnte, sondern dass es ihn gar nicht erst gefunden hat. Es zeigte auf die falsche Datei und gab den fehlerhaften Code unverändert zurück.
| So habe ich gefragt | Ergebnis |
|---|---|
| Einzelne Frage („finde den Fehler") | Kein kleines Modell fand die Ursache (falsche Datei). |
| In der Schleife (mit Test-Rückmeldung) | Jedes Modell, sogar das winzige, fand und behob die Ursache in einer Runde. |
Tabelle 2 · Gleicher Fehler, gleiches Modell, zwei Arbeitsweisen. Den Unterschied macht nicht die Modellgröße, sondern das Drumherum.
Im Loop bekommt das Modell nämlich die fehlschlagende Test-Meldung zurück, und die nennt das Symptom beim Namen. Diese halbe Arbeit, das Eingrenzen, liefert der Test, nicht das Modell. Daraus nehme ich das Wichtigste für mein Projekt mit: Ein gutes Drumherum hebt ein kleines Modell auf ein Niveau, das es allein nicht erreicht. Genau da setzt der nächste Abschnitt an.
Wenn ein Test-Loop ein kleines Modell schon so aufwertet, was kann man dann mit dem Aufbau noch herausholen? Hier kommt die Idee, die das Herz meines Zukunftsprojekts ist. Ich nenne sie den KI-Rat: Statt einer einzigen KI zu vertrauen, lasse ich mehrere Modelle dieselbe Frage beantworten und ihre Antworten gegeneinander prüfen.
In Stufen gedacht: Auf der einfachsten Ebene fragt man zwei, drei verschiedene Modelle und vergleicht. Sind sie sich einig, ist das ein starkes Signal. Widersprechen sie sich, ist genau das die heikle Stelle, die man genauer anschaut. Eine Stufe weiter lässt man sie regelrecht debattieren und abstimmen. Ganz oben gibt man ihnen Rollen: einer schlägt vor, einer spielt den Skeptiker, einer entscheidet als Schiedsrichter.
Warum mich das so reizt: Dieses Muster verkleinert gerade bei schwächeren, lokalen Modellen den Abstand zur teuren Cloud am stärksten, ähnlich wie der Test-Loop oben. Mehrere mittelmäßige Perspektiven plus eine ehrliche Prüfung schlagen oft eine einzelne, selbstbewusste Fehleinschätzung. Der ehrliche Preis: Mehrere Modelle brauchen mehr Speicher oder laufen nacheinander, kosten also Zeit. Für eine simple Aufgabe ist das übertrieben, für eine knifflige verdient es sich seinen Aufwand. Dieser KI-Rat ist nicht der Kern meiner Software, sondern das erste richtige Werkzeug, das ich auf sie aufsetzen will, der Beweis, dass der Aufbau trägt.
Eine handfeste Entscheidung fällt jetzt schon, und sie betrifft Schicht 2, den Motor. Ich habe dasselbe Modell einmal über Ollama und einmal über MLX laufen lassen. MLX tippt rund ein Viertel bis ein Drittel schneller. Trotzdem ist meine Empfehlung nicht „nimm das Schnellere".
Das ist bewusst keine in Stein gemeißelte Wahl. Weil der Motor hinter dem genormten Stecker sitzt, kann ich ihn jederzeit tauschen, ohne den Rest anzufassen. Genau so soll mein ganzes Projekt funktionieren.
Der Tag hat mir weniger über mein MacBook beigebracht (dass ein 24-GB-Laptop kein KI-Kraftwerk ist, war klar) als über den Aufbau, den ich für mein eigentliches Vorhaben brauche. Ich weiß jetzt aus erster Hand:
Der nächste Schritt für mich ist deshalb kein weiterer Benchmark, sondern ein gründlicher Blick in einen fertigen Workspace wie Odysseus: nicht um ihn nachzubauen, sondern um an einem echten Beispiel zu sehen, wie diese vier Schichten sauber zusammenspielen, bevor ich meine eigene, schlanke Version davon baue. Wenn du die Serie verfolgst, ist das der Punkt, an dem aus Verstehen endlich Bauen wird.