Lokale KI · Strategie · Praxis

Why local: Die Lernschleife gehört ins eigene Unternehmen

Tom Jansen · 14.07.2026 · 10 Min. Lesezeit

Am 12. Juli 2026 hat Microsoft-CEO Satya Nadella einen Artikel auf X veröffentlicht, der ein Problem beschreibt, das auch hinter meiner Arbeit mit lokalen Modellen steht: Unternehmen müssen ihre Daten schützen und zusätzlich die Lernschleife aus Prompts, Korrekturen, wiederholbaren Qualitätsprüfungen (Evals), Traces und Memory unter eigener Kontrolle halten. Genau deshalb wird auf meinem Schreibtisch gerade auf einem MacBook Pro mit 128 GB RAM stundenlang lokale Modellinferenz durchgeführt, und genau deshalb beschäftige ich mich mit DwarfStar, pi-ds4, einem eigenen Benchmark-Harness und einem zu klein dimensionierten KV-Disk-Cache. Dabei entsteht Wissen über die eigene Arbeit, das erst im Umgang mit dem Modell sichtbar wird und weder in einer Akte noch im CRM oder Data Warehouse bereits fertig vorliegt.

Nadella nennt das den „Reverse Information Paradox“. Der Ökonom Kenneth Arrow hat 1962 beschrieben, dass der Verkäufer einer Information genug davon offenlegen muss, damit ein Käufer ihren Wert beurteilen kann, und damit riskiert, die Information schon vor dem Verkauf aus der Hand zu geben. Nadella dreht dieses Informationsparadox für KI um: Heute bezahlt der Käufer ein Modell und muss zusätzlich eigenes Wissen hineinreichen, damit das gekaufte Modell für die konkrete Arbeit überhaupt nützlich wird.

Unternehmen bezahlen mit Geld und mit eigenem Wissen

Für eine allgemeine Frage braucht ein Modell wenig über das Unternehmen zu wissen. Sobald daraus echte Arbeit werden soll, kommen aber interne Dokumente, frühere Entscheidungen, Kundenkontext, Werkzeugzugriffe, Qualitätsmaßstäbe und Korrekturen dazu, und je besser das Ergebnis werden soll, desto genauer muss erklärt werden, wie in diesem Unternehmen eigentlich gearbeitet und entschieden wird. Bezahlt wird damit einmal in Euro oder Dollar und ein zweites Mal mit dem Kontext, der aus einem allgemeinen Modell ein für die eigene Organisation brauchbares System macht.

Die Eigentumsfrage an der Lernschleife hängt nicht daran, ob ein Anbieter die Eingaben zum Training verwendet. OpenAI sagt für Business-Produkte und die API, dass Ein- und Ausgaben standardmäßig nicht zum Training verwendet werden, und Microsoft gibt für die in Azure über Microsoft Foundry verkauften Modelle vergleichbare Zusagen, wobei zustandsbehaftete Funktionen und das Abuse Monitoring gesondert betrachtet werden müssen. Produkt, Vertrag, Aufbewahrung, Region und Konfiguration machen also einen erheblichen Unterschied, und eine sauber konfigurierte sowie vertraglich geprüfte Cloud- oder Tenant-Grenze kann für viele Fälle angemessen sein.

Nadellas Punkt reicht trotzdem weiter, denn selbst wenn kein Anbieter mit den Eingaben trainiert, muss ein Unternehmen entscheiden, wo seine Prompts, Evals, Traces, Korrekturen, Memory-Einträge und Orchestrierungsregeln entstehen, wem sie gehören und ob sie mitgenommen werden können, wenn morgen ein anderes Modell besser, günstiger oder überhaupt noch verfügbar ist.

Gute Vertragsbedingungen sind wichtig. Sie sind aber keine eigene technische Fähigkeit.

Aus einem One-Line-Install ist ein eigener Benchmark-Harness geworden

Den minimalen, modellunabhängigen Agent-Harness Pi habe ich etwa im März 2026 installiert und seine Entwicklung seitdem verfolgt, aber lokal ist der Stack erst geworden, nachdem Salvatore Sanfilippo, als antirez bekannt und ursprünglicher Entwickler von Redis, die Inferenz-Runtime DwarfStar für DeepSeek-V4-Flash veröffentlicht, Armin Ronacher, Schöpfer von Flask und Jinja, die Verbindung zu Pi mit pi-ds4 gebaut und die Civic Hackerin und Taiwans erste Digitalministerin Audrey Tang daraus eine Installation in einer Zeile gemacht hat. Ihr Post hat mich schließlich überzeugt, das Setup auf dem vorhandenen M5 Max auszuprobieren, und aus „mal schauen, ob das läuft“ ist ziemlich schnell die Frage geworden, wie weit ein lokales Modell bei einer vollständigen Rechercheaufgabe wirklich hinter einem Frontier-Modell liegt. Die ganze Entstehungsgeschichte und die Rollen der einzelnen Teile stehen im Vergleich von DeepSeek-V4-Flash mit GPT-5.5 xhigh.

Zunächst ist ein Coding-Vergleich vorgesehen gewesen. Weil Cognition die Aufgaben des FrontierCode-Benchmarks zum Schutz vor Kontamination nicht öffentlich freigibt, ist ein unabhängiger Lauf damit nicht möglich gewesen, und der Schwerpunkt ist auf Deep Research verlagert worden. Dafür ist DRACO herangezogen worden, ein Benchmark mit 100 Deep-Research-Aufgaben aus zehn Domänen. Für den lokalen Arm ist ein auf 87 GB komprimierter Quant von DeepSeek-V4-Flash über DwarfStar und pi-ds4 mit Pi verbunden worden, und als Frontier-Referenz ist das gehostete GPT-5.5 xhigh verwendet worden. Nach dem Retry liegt der lokale Wert bei 48,18 %, die Frontier-Referenz bei 49,37 %, allerdings unter nicht identischen Retry- und Judge-Protokollen, weshalb daraus kein Gleichwertigkeitsnachweis wird. Aber der Abstand ist klein genug, dass die lokale Variante für diese Art von Arbeit ernsthaft untersucht werden muss.

Und dort hat die Arbeit am Harness angefangen. Im Lauf sind nicht nur Modellgrenzen sichtbar geworden, sondern eine einzelne Tool-Ausgabe mit 15,7 MB, Kontextüberläufe, leere Antworten, ein zu kleiner KV-Disk-Cache und ein Harness, der teilweise die falsche Nachricht als Ergebnis gespeichert hat. In den folgenden drei Wochen sind diese Stellen untersucht, repariert und in mehreren Entwicklungs- und Vergleichsläufen gemessen worden, wobei sich nicht jede Änderung isolieren ließ; daraus sind unter anderem ein öffentliches Bug-Ticket bei Pi und eine übernommene Änderung am RAM-abhängigen Standard für das KV-Disk-Budget von pi-ds4 entstanden. Die vollständige Optimierung des lokalen DRACO-Stacks zeigt deshalb besser als jeder Modellvergleich, was „lokal“ praktisch bedeutet.

Man bekommt Kontrolle, aber man übernimmt auch den Betrieb.

Bei der Modellgenerierung sind lokal 0 $ API-Kosten angefallen, während die direkte Generierung mit GPT-5.5 im Vergleich 612,60 $ gekostet hat. Das ist noch kein TCO-Vergleich, denn das MacBook, Strom, Laufzeit und die Arbeit am Harness sind natürlich nicht kostenlos, aber die Kosten werden von einer verbrauchsabhängigen Rechnung in eine eigene Infrastruktur und eine Fähigkeit verschoben, die beim nächsten Lauf noch vorhanden ist.

Modelle wechseln, der Harness bleibt

Nadella fasst seine Forderung in fünf Begriffe: Control, Capability, Choice, Cost und Compound. Für mich hängt fast alles davon an der Trennung zwischen Modell und Harness. In dieser Architektur soll ein Modell ein austauschbarer Reasoning-Kern sein, während der Harness den Kontext einspeist, Werkzeuge bereitstellt, Regeln durchsetzt, Ergebnisse speichert und die Feedbackschleife organisiert. In meinem Ontologie-Versuch für KI-Agenten ist die versionierte Kombination aus Modell, Konfiguration, Harness, Rolle, Skills und Memory-Verweis die Spec, während jede einzelne Ausführung ein Run ist. Ein Modellwechsel erzeugt damit eine neue Spec-Version, ohne dass die Arbeitsweise, das Memory und die Definition von „gut“ verschwinden müssen.

Das ist auch die Idee hinter pi-fusion. Eine Frage kann in mehrere getrennte Modellkontexte gehen, danach bewertet ein Judge die Ergebnisse und eine weitere Stufe führt sie zusammen. Ob dabei ein lokales Ollama-Modell, DeepSeek über DwarfStar oder ein gehostetes Modell eingesetzt wird, ist eine Entscheidung der Konfiguration und nicht die Identität des Systems. So bleibt Choice tatsächlich eine Wahl, und die Arbeit an Prompts, Evals, Werkzeugen und Guardrails verbessert den eigenen Stack statt nur die Bindung an einen Anbieter.

So entsteht für mich „Compound“. Modelle sind viel zu kurzlebig, um über Jahre das dauerhafte Asset zu werden, und wertvoller werden stattdessen die eigenen Evals, die Fehlerklassen, die bekannten guten und schlechten Workflows, die Tool-Grenzen und die Fähigkeit, eine Aufgabe mit einem anderen Modell erneut auszuführen.

Wer diese Schicht besitzt, kann neue Modelle testen. Wer sie nicht besitzt, fängt mit jedem Wechsel wieder ziemlich weit vorne an.

Ein lokales Modell macht noch keine lokale Pipeline

Der bisherige DRACO-Lauf macht diese Grenze messbar. Die Modellinferenz ist auf dem Mac erfolgt, aber Websuche, Seitenabrufe und Judge sind im Lauf über Cloudservices ausgeführt worden, und im aktuellen Stack sind diese Teile weiterhin cloudbasiert. Dadurch haben Suchbegriffe, URLs, Aufgabeninhalte und Antworten die lokale Umgebung verlassen können. Für öffentliche Benchmarkfragen ist das okay. Für eine Mandatsakte oder ein psychologisches Gesprächstranskript wäre es genau die Lücke, die mit dem lokalen Modell eigentlich geschlossen werden soll.

Eine belastbare lokale Pipeline umfasst deshalb mehr als Gewichte auf einer SSD. Auch Tools, Logs, Telemetrie, Memory, Zwischenergebnisse, Backups und Bewertung brauchen eine klare Grenze, und jede externe Verbindung muss entweder technisch ausgeschlossen oder bewusst und vertraglich kontrolliert sein. Lokale Inferenz ist häufig ein großer einzelner Schritt, weil bei einer cloudbasierten Modellgenerierung der für den jeweiligen Aufruf benötigte Kontext die kontrollierte Umgebung verlässt, aber wie viel davon sensibel ist, hängt von Aufgabe und Architektur ab, und lokale Inferenz bleibt deshalb nur ein Schritt.

Diese Sicht ist bei mir auch nicht erst mit DeepSeek entstanden. Diese Website ist bewusst statisch gebaut, Schriften liegen lokal und das cookielose Analytics läuft selbst gehostet; OpenClaw habe ich zuerst auf einem alten Android-Handy statt auf dem Hauptrechner eingerichtet, weil ein neuer Agent mit weitreichenden Tools einen begrenzten Testraum braucht. In beiden Fällen geht es um dasselbe Prinzip: Die Abhängigkeiten und der mögliche Schaden sollen sichtbar und begrenzt sein, bevor ein System mehr Zugriff bekommt.

Für hochsensible Arbeit wird die Grenze praktisch

Bei Kanzleien, Steuerberatern, Arztpraxen und Psychologen ist „local“ keine technische Geschmacksfrage. Mandatsakten, Steuerunterlagen, Patientendaten oder Gesprächstranskripte aus psychologischen Sitzungen enthalten genau den Kontext, den ein Modell für die konkrete Arbeit braucht, und gleichzeitig genau die Informationen, bei denen eine externe Verarbeitung nur nach konkreter Prüfung von Produkt, Vertrag, Datenschutz, Berufsrecht und technischen Schutzmaßnahmen infrage kommt. Ein lokaler Stack kann die Zahl der beteiligten Anbieter und notwendigen Vertrauenszusagen deutlich reduzieren, ersetzt aber weder Datenschutzprüfung noch Berufsrecht, Zugriffskontrollen, Löschkonzepte und einen vernünftigen Betrieb.

Für diese Berufsgruppen möchte ich deshalb keine pauschale „KI im Unternehmen“-Lösung verkaufen, sondern zuerst den tatsächlichen Informationsfluss sortieren: Welche Daten werden gebraucht, welche Werkzeuge greifen darauf zu, wo entstehen Logs und Memory, wer bewertet Ergebnisse und an welcher Stelle verlässt etwas die kontrollierte Umgebung? Erst danach lässt sich entscheiden, ob ein privater Cloud-Tenant ausreicht, eine hybride Architektur sinnvoll ist oder die komplette Kette lokal laufen muss.

Cloud bleibt, aber sie entscheidet nicht mehr über jede Aufgabe

Ich nutze Frontier-Modelle jeden Tag und GPT-5.5 xhigh ist auch in diesem Projekt die Referenz und der Judge gewesen. Bei vielen öffentlichen Aufgaben ist zusätzliche Modellleistung wichtiger als maximale lokale Kontrolle, und manchmal ist eine sauber vertraglich geregelte Cloudlösung wirtschaftlich und technisch die bessere Entscheidung. „Why local“ beantwortet deshalb nicht die Frage, ob Cloud schlecht ist, sondern ob die eigene Organisation eine Aufgabe noch bearbeiten kann, wenn Daten, Kosten, Verfügbarkeit oder Anbieterbedingungen gegen einen Cloudaufruf sprechen.

Seit dem 9. Juli 2026 ist für die weitere Arbeit ein 91-GB-Quant mit 400.000 Token Kontextfenster, 64 GB KV-Budget, gedeckelten Tool-Ausgaben, Salvage und einem stabileren Harness im Einsatz. Als Nächstes stehen der vollständige 100-Aufgaben-Lauf und der Re-Judge der auffälligen Medizin-Aufgabe an, und parallel bleibt die größere Aufgabe bestehen, auch Webzugriffe, Logging, Memory und Bewertung hinter dieselbe kontrollierte Grenze zu ziehen. Ob am Ende jede Stufe physisch auf demselben Rechner läuft, ist weniger wichtig als eine Architektur, in der diese Entscheidung tatsächlich selbst getroffen werden kann.

Der getestete lokale DS4-Stack ist in dieser internen DRACO-Auswertung trotz nicht identischer Protokolle nah genug an die gehostete Referenz herangekommen, um einen kontrollierten Vergleich unter gleichen Regeln und die weitere Arbeit am eigenen Stack zu rechtfertigen.

Ich will nicht ohne Cloud arbeiten. Ich will arbeiten können, wenn die Cloud für die Aufgabe nicht infrage kommt.