Research · Juni 2026 · Lokale KI · Teil 2 Glossar ↗

Wie eine lokale KI wirklich aufgebaut ist

Im ersten Teil habe ich durchgerechnet, was lokale KI kostet, und damit, welche Hardware man dafür braucht. Sagen wir, die Entscheidung ist gefallen: in meinem Fall ein DGX Spark, und der steht jetzt bei mir. Wie geht es weiter? Genau das ist dieser Teil: das Wissen, das du brauchst, um zu verstehen, wie so ein lokaler KI-Stack zusammensteckt. Was ist das Modell, was eine Serving-Engine, was ein Agent, was ein Workspace wie Odysseus, und wie reden diese Teile miteinander?

Das ist weniger graue Theorie als Anleitung: erst die einzelnen Ebenen und wie sie zusammenarbeiten, dann nehme ich dich am Ende einmal mit vom Gerät-im-Karton bis zum ersten laufenden Modell, headless gedacht, denn die Box rechnet, gesteuert wird sie vom Laptop.

Worauf das hier hinausläuft

1 · Die Bauteile: was ist eigentlich was?

Zuerst die Teile auseinanderhalten, ich habe sie selbst lange durcheinandergeworfen. Vier Bauteile, und ich gehe sie in der Reihenfolge durch, in der man sie auch denkt: von dem, was du öffnest, bis zu dem, was am Ende rechnet.

Die häufigste Verwechslung, aufgelöst: Odysseus ist nicht dasselbe wie Ollama. Odysseus ist das Cockpit (Bauteil 1), Ollama der Motor (Bauteil 3). Odysseus benutzt eine Serving-Engine wie Ollama, um das Modell zum Laufen zu bringen, baut sie aber nicht selbst. Cockpit oben, Motor darunter.

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 der Kern meines eigenen Projekts.

2 · Wie die Teile miteinander reden

Jetzt das Bild, das mir lange gefehlt hat. Oben öffnest du das Cockpit und lässt darin den Agenten arbeiten; den Verstand, den er befragt, lädt unten die Box, und dort passiert auch die eigentliche Rechenarbeit. Das Verbindende ist überall dieselbe Standard-Schnittstelle, ein genormter Stecker, der jedes Teil einzeln austauschbar macht.

Architektur · vom Cockpit zum Verstand

Oben steuerst du, unten wird gerechnet, dazwischen ein genormter Stecker.

Dein Laptop (Cockpit) Die Box / Spark (rechnet)

Kurz: Cockpit und Agent auf deinem Laptop, Motor und Verstand auf der Box, verbunden über einen genormten Stecker. Du sitzt oben, der Spark rechnet unten.

Eine Frage wandert also so: Du tippst ins Cockpit. Das setzt einen Agenten in Gang, der die Aufgabe in 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 den geladenen Verstand rechnen lässt und die Antwort zurückgibt. Weil überall dieselbe Schnittstelle sitzt, ist es dem Cockpit egal, ob die Engine auf demselben Laptop läuft oder auf dem Spark im Nebenzimmer.

3 · Headless: wo das Modell wirklich läuft

Damit zur Kernfrage. Der genormte Stecker erlaubt zwei Aufbauten:

Variante B ist der Plan, und die Box ist der Spark (welche Hardware, und warum, steht in Teil 1). Der Grund für headless ist einfach: Dein Arbeitslaptop ist ein gutes Arbeitsgerät, aber kein KI-Kraftwerk, und das soll er bleiben. Kein Modell soll dir den Laptop lahmlegen, während du arbeitest. Stattdessen steht die Box daneben, rechnet headless, und du greifst vom Laptop darauf zu. So liegt die Trennlinie: oben auf dem Laptop Cockpit und Agent, unten auf der Box nur Engine und Modell. Das Wichtigste: Die Architektur ist für beide Varianten dieselbe. Der Wechsel von „alles auf einem Gerät" auf den Spark ist kein Umbau, sondern eine Adresse in einer Einstellung.

4 · Das Orchestrierungs-Rad (der „KI-Rat")

Eine Sache zieht durch den ganzen Aufbau: Struktur drumherum schlägt rohe Modellgröße. Ein kleines Modell allein verläuft sich oft; gibt man ihm eine Schleife, in der es sein Ergebnis prüft und nachbessert, holt es spürbar auf. Diese Beobachtung führt zu der Idee, die mein eigentliches Vorhaben trägt, dem KI-Rat: Statt einer einzigen KI zu vertrauen, lasse ich mehrere Modelle dieselbe Frage beantworten und ihre Antworten gegeneinander prüfen, vom schlichten Vergleich bis hin zu Modellen in verteilten Rollen.

Das bringt gerade schwächere, lokale Modelle nah an die teure Cloud, und genau hier passt eine rechenstarke Box wie der Spark: Mehrere Modelle gleichzeitig laufen zu lassen ist Durchsatz-Arbeit, kein Wettlauf um die einzelne schnellste Antwort, und Durchsatz ist die Stärke des Sparks (zusammen mit der Engine vLLM, dazu gleich). Das ist der Grund, warum so eine Box für mein Vorhaben überhaupt Sinn ergibt. Wie der KI-Rat konkret gebaut wird, hebe ich mir für einen späteren Teil der Serie auf, wenn es ans eigene Bauen geht.

5 · Welche Engine? Und warum die Antwort von der Box abhängt

Jetzt zur Wahl des Motors (Bauteil 3). Wichtig vorweg: Die beste Engine hängt davon ab, auf welcher Maschine sie läuft. Auf Apple-Rechnern wäre MLX der schnellere Motor, aber: MLX gibt es nur auf Apple. Auf dem Spark, einer NVIDIA/CUDA-Box, fällt diese Option komplett weg. Dort heißt die relevante Hochleistungs-Alternative vLLM. Der bequeme Allrounder darunter, der überall läuft, ist Ollama.

Empfehlung zum Motor (Serving-Engine)

  1. Ollama als portabler Standard. Bequem (ein Befehl lädt ein Modell), spricht die Standard-Schnittstelle, wird von allen Agenten verstanden, räumt das Modell automatisch wieder aus dem Speicher, und läuft sowohl auf dem Mac als auch auf einem Spark. Damit fange ich überall an.
  2. Der Tempo-Motor hängt an der Box. Auf Apple wäre das MLX, auf dem Spark ist es vLLM, und das passt perfekt: vLLM glänzt beim Bündeln vieler paralleler Läufe, also genau bei meinem KI-Rat.
  3. Beide hinter derselben Schnittstelle. Dann ist der Wechsel reine Einstellungssache, kein Umbau. Genau diese Austauschbarkeit ist der Grund, warum ich das so baue.

Ehrlich dazu: Der vLLM-auf-Spark-Tipp ist aus der Architektur abgeleitet, nicht auf der eigenen Box nachgemessen, die echten Zahlen kommen, sobald ich sie eingerichtet habe. Weil der Motor hinter dem genormten Stecker sitzt, kostet ein späterer Wechsel ohnehin nichts am Rest. Genau so soll mein ganzes Projekt funktionieren.

Realitäts-Check: mein echter Verbrauch

Die Spark-Zahlen kommen noch, aber meine echten Cloud-Zahlen habe ich schon gemessen. 30 Tage Claude Code: 59 Mio. neue Tokens, dazu 9,4 Mrd recycelter Kontext, also rund 160 zu 1. Nicht die erzeugten Tokens fordern eine lokale Box, das schafft sie nebenbei. Es ist der Kontext, den sie halten und immer wieder lesen muss, mal eine lange Session, oft hunderte kleine parallel, und jeder Lauf reserviert seinen eigenen Zwischenspeicher in den 128 GB der Box.

Das Learning: Entscheidend ist nicht die rohe Hardware, sondern wie klug der Aufbau ist: Kontext schlank halten, das passende Modell pro Rolle, viele parallele Läufe sauber bündeln. Dieselbe Regel wie oben, eine Ebene höher: Struktur schlägt Modellgröße, und ein effizienter Aufbau schlägt rohe Hardware-Masse.

Mein Muster aus vielen kleinen Läufen nebeneinander ist dabei die Heimat so einer Box, nicht ihre Schwäche. Der begrenzende Hebel ist nicht das Tempo, sondern wie viele Kontexte gleichzeitig in den Speicher passen. Genau dort baue ich an.

→ Meine Zahlen live: Token-Dashboard

6 · Vom Karton zum ersten Modell

Jetzt die eigentliche Anleitung: Die Box steht im Karton, wie kommst du von dort zum ersten laufenden Modell? Hier der Weg in einfach, headless gedacht, entlang NVIDIAs offizieller Spark-Anleitung.

Brauchst du einen Bildschirm? Nein. Beim allerersten Einschalten macht der Spark selbst ein kleines WLAN auf. Du verbindest deinen Laptop mit diesem WLAN, der Browser öffnet automatisch eine Einrichtungs-Seite (ein Captive Portal), und dort klickst du dich durch. Alternativ steckst du gleich ein Netzwerkkabel rein und sprichst die Box direkt an. Ein Monitor am Spark ist nie nötig.

  1. Anstecken. Netzwerkkabel in die Box und in den Router, Netzteil dran. Achtung: Es gibt keinen Einschaltknopf, Strom dran heißt an (eine schaltbare Steckdose ist praktisch).
  2. Vom Laptop verbinden. Einmalig ins Spark-eigene WLAN (Name und Passwort stehen auf dem beiliegenden Zettel), Browser öffnet die Einrichtung. Konto anlegen, fertig.
  3. Updates laufen lassen. Die Box zieht beim ersten Mal Aktualisierungen (~10 Minuten) und startet neu. Nicht unterbrechen. Danach hängt sie ganz normal in deinem Heimnetz.
  4. Ab jetzt headless. Laptop zurück ins normale WLAN. Die Box erreichst du über ihren Netzwerknamen. Auf dem Mac gibt es dafür eine kleine App (NVIDIA Sync), die die Verbindung automatisch herstellt, sonst nutzt du von jedem Rechner klassisch SSH.
  5. Erstes Modell starten. Auf dem Spark ist Ollama schon vorinstalliert. ollama pull qwen2.5-coder lädt ein Modell herunter, ollama run qwen2.5-coder startet es; der Dienst lauscht dann auf der bekannten Standard-Schnittstelle (Port 11434).
  6. Vom Laptop aus nutzen. Dein Workspace auf dem Laptop zeigt einfach auf die Adresse der Box (etwa http://spark.local:11434), und du arbeitest, als liefe das Modell lokal, nur dass die Box die Arbeit macht.

Laut NVIDIA bist du so in einer guten halben Stunde vom Karton beim ersten Modell. Zwei ehrliche Hinweise: Ollama ist der bequeme Schnellstart, für volle Leistung auf dem Spark nimmt man später eher vLLM (das deckt sich mit der Engine-Empfehlung oben). Und für große Modelle ist das Netzwerkkabel dem WLAN klar überlegen. Die ganzen Praxis-Anleitungen sammelt NVIDIA unter build.nvidia.com/spark. Meine eigene Box, eine ASUS Ascent GX10 (NVIDIA GB10, 128 GB Speicher), ist gerade angekommen; die echten Schritte und Zahlen liefere ich im nächsten Teil nach.

Das nimmst du mit

Wenn du bis hier gelesen hast, weißt du jetzt das, worum es mir ging:

  1. Die vier Bauteile eines lokalen KI-Stacks und wer was tut: Modell (Verstand), Serving-Engine (Motor), Agent (Hände), Workspace (Cockpit).
  2. Odysseus ist nicht Ollama: das eine ist das Cockpit, das andere der Motor darunter.
  3. Wie eine Frage durch den Stack läuft und warum der genormte Stecker jedes Teil austauschbar macht, also kein Lock-in.
  4. Was „headless" heißt und wie dein Spark-Setup aussieht: die Box rechnet, der Laptop steuert nur. Der Wechsel dorthin ist kein Umbau, nur eine Adresse in einer Einstellung.
  5. Welche Engine auf welche Maschine gehört: Ollama überall als bequemer Standard; auf dem Spark wird vLLM wichtig (Durchsatz für viele parallele Modelle), MLX ist Apple-only.
  6. Das Kern-Prinzip: Struktur schlägt rohe Modellgröße. Ein Test-Loop oder ein KI-Rat holt aus kleinen Modellen mehr heraus, als ein größeres allein liefert, und der KI-Rat glänzt gerade auf einer rechenstarken Box wie dem Spark.
  7. Die ehrliche Grenze: lokal ist kein Eins-zu-eins-Ersatz für die Cloud bei den großen, verzweigten Aufgaben, für klar umrissene reicht es überraschend weit.

7 · Was das für mein Projekt heißt

Worum es mir am Ende geht, ist nicht die einzelne Box, sondern der Aufbau, den ich für mein eigentliches Vorhaben brauche. Den habe ich jetzt klar vor Augen:

  • Die vier Schichten und ihr genormter Stecker sind das Fundament. Mein Projekt baut genau dort an: eine schlanke Basis, auf der man sich Modell, Engine und Werkzeuge selbst zusammensteckt.
  • Headless ist gesetzt, die Box ist der Spark. Die rechnende Maschine bleibt getrennt von dem Gerät, an dem ich sitze, und dank des genormten Steckers spricht dieselbe Software sie an, egal ob klein angefangen oder voll auf dem Spark.
  • Der Motor ist entschieden: Ollama als bequemer Standard überall, auf dem Spark vLLM als Durchsatz-Motor für den KI-Rat, austauschbar gehalten.
  • Das erste echte Feature wird der KI-Rat, weil er gerade aus schwächeren lokalen Modellen am meisten herausholt und genau zur Rechenstärke des Sparks passt.

Der nächste Schritt für mich ist deshalb kein weiterer Test, 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. Das ist dann der Punkt, an dem aus Verstehen Bauen wird.