Lokale Modelle im eigenen Stack

In diesem Level ging es bisher um Portabilität. Dasselbe Gedächtnis in Claude, Cursor und Codex, dieselben Werkzeuge über ein offenes Protokoll. Diese Lektion zieht die Linie zu Ende, denn Portabilität hört nicht beim Anbieter auf. Sie hört bei der Frage auf, ob überhaupt ein Anbieter beteiligt sein muss.

Warum das der eigentliche Test des Standards ist

Ein Protokoll ist offen, wenn man es gegen etwas laufen lassen kann, das der Erfinder nicht vorgesehen hat. MCP kommt von Anthropic. Wenn dieselben Server gegen ein Modell arbeiten, das auf Deinem Schreibtisch liegt und mit Anthropic nichts zu tun hat, ist die Offenheit bewiesen und nicht nur behauptet.

Genau das geht. Es ist dieselbe Server-Software, dasselbe Gedächtnis-Werkzeug, nur ein anderes Modell dahinter. Was sich ändert, ist die Fähigkeit des Modells, die Werkzeuge klug zu benutzen, und darum geht es im Rest dieser Lektion. Dass Du dieselben Server benutzen KANNST, heißt übrigens nicht, dass Du sie überall eintragen solltest. Dazu am Ende mehr.

Die Rollen sauber trennen

Bei Claude Desktop verschwimmen zwei Dinge in einer Anwendung, und das führt zu Verwirrung, sobald man sie trennt.

Das Protokoll kennt Host, Client und Server. Der Host ist die Anwendung, in der Du sitzt; er startet pro Verbindung einen Client, und jeder Client spricht mit einem Server, der die Werkzeuge bereitstellt. Das Modell ist kein Teilnehmer am Protokoll: der Host legt ihm die Werkzeugliste vor und führt aus, was es aufrufen will.

Genau diese Trennung ist der Grund, warum dieselbe Server-Software hinter beliebigen Modellen funktioniert. Bei einem lokalen Aufbau liegt das Modell in einer Laufzeitumgebung wie Ollama, und der Host ist ein separates Programm, etwa eine Weboberfläche. Du tauschst eine Schicht, nicht den Aufbau. Das heißt allerdings nur, dass Du dieselben Server benutzen KÖNNTEST. Welche Du in welcher Umgebung tatsächlich einträgst, ist eine Sicherheitsentscheidung, dazu weiter unten mehr. Was Du dabei prüfen musst, ist der Transport: eine als lokaler Prozess konfigurierte Server-Eintragung lässt sich nicht unverändert in eine Weboberfläche kopieren.

Wo die Grenze liegt

Hier ist der Unterschied, der in der Praxis zählt. Prüf zuerst die Einrichtung: Chat-Template, Werkzeug-Beschreibungen, Quantisierung, ob die Oberfläche Aufrufe überhaupt durchreicht. Bleibt das Verhalten danach, liegt es am Modell, und das ist der Teil, den Du nicht wegkonfigurierst.

Ein großes Modell entscheidet zuverlässig, ob eine Frage ein Werkzeug braucht. Ein kleines lokales Modell tut das nicht immer. Es antwortet gelegentlich aus dem eigenen Wissen, obwohl das passende Werkzeug bereitsteht. Es greift manchmal zum falschen. Und wenn eine Aufgabe drei Werkzeuge in der richtigen Reihenfolge braucht, verliert es öfter den Faden.

Werkzeuge auswählen ist eine Denkaufgabe, aber anders als beim Textverstehen entscheidet hier nicht in erster Linie die Größe. Unterhalb von etwa sieben Milliarden Parametern fehlt die Fähigkeit weitgehend. Darüber zählt vor allem, ob das Modell ausdrücklich auf Tool-Calling trainiert wurde: in Vergleichstests liegen 8B- und 14B-Modelle mit diesem Training dicht beieinander, und ein deutlich größeres Modell ohne das Training kann schlechter abschneiden als ein kleines mit. Wer nur nach Parameterzahl aussucht, greift hier also regelmäßig daneben.

Was daraus für Deinen Aufbau folgt

Drei Konsequenzen, die alle in dieselbe Richtung zeigen.

Weniger Werkzeuge gleichzeitig. Drei gut beschriebene schlagen zwanzig. Bei großen Modellen ist eine lange Liste unproblematisch, bei kleinen sinkt die Trefferquote mit jedem zusätzlichen Eintrag.

Beschreibungen, die das Wann erklären. "Sucht in der Datenbank" reicht einem starken Modell. Ein lokales braucht "benutze das, wenn nach einem Kunden, einer Rechnung oder einem Vorgang gefragt wird". Die Beschreibung ist bei lokalen Modellen kein Beiwerk, sondern der wichtigste Hebel.

So wenig Zugriff wie möglich, auf beiden Seiten. Dass ein Modell, das gelegentlich danebengreift, löschen oder senden darf, ist die offensichtliche schlechte Kombination, dagegen hilft eine Bestätigungspflicht. Der unterschätzte Teil ist das Lesen: ein zu weit gefasstes Lesewerkzeug holt Schlüssel und Kundendaten in Kontext und Protokolle, und spätestens wenn dieselbe Oberfläche einmal gegen ein Cloud-Modell läuft, ist das der Weg nach draußen. Also einzelnes Verzeichnis statt Benutzerordner, und Bestätigung für alles Schreibende.

Warum Gedächtnis lokal noch wichtiger ist

In diesem Level lief die These bisher so: ein Modell, das Deinen Kontext kennt, schlägt ein stärkeres, das raten muss. Bei lokalen Modellen ist das keine Optimierung mehr, sondern die Voraussetzung, dass der Aufbau überhaupt taugt.

Ein kleines Modell weiß wenig über die Welt und nichts über Dich. Was es nicht weiß, kann es nur erfinden. Gibst Du ihm Zugriff auf Deine Notizen, Entscheidungen und Projektstände, muss es nichts mehr raten, sondern nur noch nachschlagen und formulieren. Nachschlagen und formulieren ist genau die Disziplin, in der kleine Modelle gut sind.

Der Größennachteil verschiebt sich damit von "weiß es nicht" zu "muss es sich holen". Und das ist eine Aufgabe, die Werkzeuge lösen.

Der gemischte Aufbau

In der Praxis entscheidet sich fast niemand für nur eine Seite, und das ist auch nicht nötig.

Alles mit sensiblen Daten und alle Massenarbeit läuft gegen das lokale Modell. Alles Schwere geht in die Cloud. Weil es beide Male dieselbe Server-Software ist, kostet das Einrichten der zweiten Umgebung wenig.

Eine Grenze gehört dazu, sonst hebelt der gemischte Aufbau genau den Datenschutz aus, wegen dem er existiert: zwei getrennte Installationen, nicht zwei Fenster und auch nicht zwei Profile derselben Oberfläche. Dort sind Server und Modell-Zugänge meist global hinterlegt, ein zweites Profil ist damit keine Grenze. Wenn ein Lesewerkzeug Schlüssel oder Kundendaten in den Verlauf geholt hat und Du danach auf das Cloud-Modell umschaltest, wandert dieser Verlauf mit. Also: sensible Server nur in der lokalen Installation eintragen, den Cloud-Zugang nur in der anderen.

Damit das so bleibt, halt die Modellwahl innerhalb jeder der beiden Umgebungen an einer Stelle statt verstreut über Skripte. Dann ist ein Modellwechsel dort eine geänderte Zeile und kein Projekt. Es ist derselbe Grundsatz wie bei Modell-Migrationen innerhalb eines Anbieters, nur eine Ebene höher. Zwischen den beiden Umgebungen wird dagegen nicht per Zeile umgeschaltet, sondern gewechselt.

Was das für Deine Unabhängigkeit bedeutet

Der Nebeneffekt ist strategisch. Wer seinen Aufbau so hält, dass ein lokales Modell einspringen kann, ist gegen eine ganze Klasse von Störungen abgesichert: Preisänderungen, abgeschaltete Modelle, Sperren, Ausfälle beim Anbieter.

Das lokale Modell muss dafür nicht gleich gut sein. Es muss nur gut genug sein, damit die Arbeit weitergeht. Diese Denkweise ist dieselbe, die in Level 1 an der Fable-Episode gezeigt wurde: bau so, dass Dich der Wegfall eines einzelnen Modells nicht umwirft.

Praktischer Einstieg

Der technische Ablauf steht im Playbook MCP mit lokalen Modellen, von der Laufzeitumgebung über die Oberfläche bis zum ersten Werkzeug. Wenn noch gar kein Modell läuft, ist Dein erstes lokales KI-Modell in 30 Minuten der Startpunkt. Und bevor Du fremde Server an einen Aufbau hängst, der ausdrücklich wegen Datenschutz lokal ist, gehört Fremde MCP-Server sicher prüfen dazwischen.

Quiz

1. Was bleibt gleich, wenn Du von einem Cloud-Modell auf ein lokales wechselst?

• A) Die Server-Software und das Gedächtnis-Werkzeug
• B) Die Qualität bei schweren Denkaufgaben
• C) Die Zuverlässigkeit der Werkzeug-Auswahl

Richtig ist A. Genau das ist der Wert des offenen Protokolls: es ist dieselbe Software. Welche Server Du in einer Cloud-Umgebung dann tatsächlich einträgst, bleibt trotzdem eine eigene Entscheidung. B und C werden schlechter, das ist der Preis.

2. Warum sinkt bei lokalen Modellen die Trefferquote, je mehr Werkzeuge aktiv sind?

• A) Die Laufzeitumgebung wird langsamer
• B) Werkzeug-Auswahl ist eine Denkaufgabe, und darin sind kleine Modelle begrenzt
• C) MCP erlaubt nur eine begrenzte Anzahl Server

Richtig ist B. Es ist kein technisches Limit, sondern eine Fähigkeitsgrenze des Modells.

3. Warum ist ein Gedächtnis bei einem kleinen lokalen Modell besonders wertvoll?

• A) Es macht das Modell schneller
• B) Es ersetzt die Werkzeug-Beschreibungen
• C) Wissen muss nicht im Modell stecken, sondern wird nachgeschlagen

Richtig ist C. Nachschlagen und formulieren können kleine Modelle gut, Wissen mitbringen können sie schlecht.

Source

• Model Context Protocol, Spezifikation: modelcontextprotocol.io
• Ollama, Modelle mit Werkzeug-Unterstützung: ollama.com/search?c=tools
• Open WebUI, MCP-Anbindung: docs.openwebui.com