Ein Laptop mit 24 Gigabyte Speicher soll plötzlich über 200.000 Textbrocken im Kontext halten. Servus, ich bin Lissy, und heute geht es um eine ziemlich praktische Frage: Wie viel KI-Arbeit kann wieder auf die eigene Maschine zurückwandern, statt immer in die große Cloud zu müssen? Der rote Faden heute ist Kontrolle. Kontrolle über Speicher, über GPU-Code, über den Browser, über Office-Dokumente und über Agenten, die im Hintergrund arbeiten. Das klingt trocken, ist aber der Punkt, an dem aus Demo langsam Infrastruktur wird.
Der stärkste Kandidat heute kommt aus der Deep-Dive-Ecke und heißt JustFit. Das Paper beschreibt einen MLX-basierten Serving-Ansatz, der Qwen3.8 27B in einer MXFP4-Variante auf einem MacBook mit 24 Gigabyte Speicher laufen lässt und dabei bis zu 196.608 Eingabetextbrocken plus 16.384 Ausgabetextbrocken schafft. Zusammen sind das 212.992 Positionen. Gegenüber der mlx-vlm-Baseline mit 30.720 Positionen ist das laut Paper ein Faktor von 6,93.
Warum ist das interessant? Weil lange Kontexte nicht nur an den Modellgewichten scheitern. Viele reden bei lokaler KI sofort über Quantisierung, also kleinere Gewichte. Das ist wichtig, aber bei langen Sitzungen frisst auch der Ausführungszustand Speicher. Der KV-Cache, Zwischenergebnisse, Komponenten, die gerade resident bleiben müssen. JustFit geht genau an diese zweite Schicht. Die Autoren nennen KVExec, PhaseSwap und StateTrans. Einfacher gesagt: Der Runtime hält nicht stumpf den ganzen Zustand im Speicher, sondern holt und räumt Teile genau dann, wenn sie gebraucht werden.
Für Coding, Recherche und Agentenläufe ist das ein anderer Hebel als noch ein kleineres Modell. Wenn ein lokaler Rechner lange Projektkontexte tragen kann, wird lokale KI nicht mehr nur Spielerei für kurze Prompts. Dann kann ein Berater seine Kundendokumente länger im Kontext halten. Ein Entwickler kann eine größere Codebasis durchgehen. Ein Gründer kann ein Vertrags-, Support- oder Produktarchiv testen, ohne sofort jede Anfrage an einen Cloud-Dienst zu schicken.
Die Zahlen sind trotzdem kein Freifahrtschein. Der Test ist stark an MLX und ein M4-Pro-Setup gebunden. Außerdem heißt Kapazität nicht automatisch angenehme Geschwindigkeit. Im Paper wird für einen 32K-Input und 64 Output ein Wert von 19,11 Tokens pro Sekunde genannt. Mein Take hier: Lokale KI wird nicht nur durch billigere Gewichte besser. Sie wird besser, wenn die ganze Speicherverwaltung intelligenter wird.
Dazu passt Nvidias Meldung zu nativer GPU-Programmierung in Rust. Nvidia stellt zwei Wege vor, um GPU-Kernel in Rust zu schreiben. Das klingt erst mal nach Entwicklerdetail, aber es betrifft eine sehr echte Frage: Wer kann performante KI- und Datenverarbeitung bauen, ohne sich ständig an unsicheren Speicherfehlern zu schneiden?
CUDA ist seit Jahren die Sprache der GPU-Welt, aber große C- und C++-Codebasen haben ihren Preis. Rust verspricht mehr Sicherheit bei Speicherzugriffen und bessere Wartbarkeit. Natürlich verschwindet damit nicht die Komplexität von GPU-Programmierung. Wer Kernel schreibt, muss weiter über Speicherlayout, Parallelität und Datenbewegung nachdenken. Aber wenn Rust sich hier ernsthaft etabliert, können Teams, die ohnehin Rust im Backend oder in Systemkomponenten nutzen, näher an die GPU rücken.
Der Unternehmer-Check ist simpel: Wenn du ein KI-Produkt mit eigenen Inferenz- oder Datenpipelines baust, entscheidet auch die Ausnutzung teurer Rechenressourcen. Rust in CUDA kann ein Signal sein, dass GPU-Optimierung sauberer wird. Nicht für jeden Solo-Berater, klar. Aber für SaaS-Gründer mit zwei technischen Leuten kann so eine Toolchain irgendwann den Unterschied machen zwischen teuer gemietet und sauber optimiert.
Das zweite große Kontrollsignal kommt von Mistral und Mozilla. Die beiden wollen offene, private und mehrsprachige KI in Firefox Smart Window bringen. Der Browser ist einer der wenigen Orte, an denen KI direkt in den Arbeitsfluss kommt, dort, wo Recherche, Formulare, Texte, Mails und SaaS-Dashboards sowieso offen sind.
Der spannende Teil ist der europäische und offene Winkel. Mistral versucht, mit Mozilla einen Endnutzerkanal aufzubauen, der nicht automatisch Google, Microsoft oder OpenAI gehört. Für Nutzer kann das KI-Funktionen näher am Browser heißen, mit stärkerem Datenschutzversprechen und besserer Mehrsprachigkeit.
Ich mag an der Meldung, dass sie Kontrolle an ein konkretes Interface bindet. Browser-KI kann nützlich werden, wenn sie Seiten zusammenfasst, Formulare versteht oder mehrsprachige Arbeit vereinfacht. Aber ein Browser sieht sehr viel über uns. Deshalb wird die Frage, wer diesen Assistenten betreibt, wo Daten landen und welche Modelle genutzt werden, im Alltag wichtiger als zwei Prozentpunkte in einem Labortest.
Aus der Grassroots-Recherche passt OpenDocBot gut in denselben Bogen. Das Tool will KI in Word, Excel und PowerPoint bringen, aber mit eigenen Modellanbietern und eigenen Keys. Also nicht: Der Office-Anbieter gibt dir eine Blackbox und du nimmst sie halt. Sondern: Bestehendes Dokument öffnen, eigenen Anbieter nutzen, Analyse oder Bearbeitung starten und dabei besser kontrollieren, wohin Daten gehen.
Das ist noch kein riesiger Produktbeweis. Der geprüfte Launch-Post hatte nur wenige Punkte und keine harten Nutzungszahlen. Trotzdem ist das Signal wertvoll, weil Office-Dokumente in Firmen weiterhin Kernmaterial sind. Angebote, Tabellen, Präsentationen, interne Analysen. Wenn KI dort arbeitet, wird Modellwahl plötzlich eine Beschaffungs- und Datenschutzfrage.
Mein praktischer Test wäre klein: Nimm zehn echte, aber unkritische Office-Dateien. Lass dasselbe Set einmal durch den Standard-Assistenten und einmal durch einen Bring-your-own-Model-Ansatz laufen. Miss drei Dinge: Wie oft erkennt das System die richtige Aufgabe, wie oft muss ein Mensch fachlich korrigieren, und ob die Datenflüsse für deinen Betrieb akzeptabel sind. Wenn du diese Antworten nicht bekommst, ist das Tool noch Demo. Wenn du sie bekommst, hast du eine echte Make-or-Buy-Frage.
Zum Schluss noch Pizza Bot, weil es eine gute Ergänzung zur lokalen Kontrollfrage ist. Pizza Bot ist eine lokale oder selbst gehostete Inbox für langlaufende KI-Agenten. Tasks können gestartet oder geplant werden, Arbeit landet später in Unread, Entscheidungen in Action. Das klingt nach Nerd-Tool, aber die Produktidee ist wichtig. Viele Agenten scheitern nicht daran, dass sie keinen Text schreiben können. Sie scheitern daran, dass Arbeit asynchron wird. Ein Agent recherchiert, braucht später eine Entscheidung, produziert ein Zwischenergebnis, wartet auf eine Entscheidung, läuft vielleicht erneut. Wenn das alles in einem linearen Gespräch hängt, wird es unübersichtlich. Eine Inbox-Metapher ist dafür natürlicher: erledigt, ungelesen, Entscheidung nötig, erneut starten.
Für Unternehmer ist das kein Produktivitätsmärchen, sondern eine klare Prüffrage. Welche Aufgaben in deinem Betrieb dürfen im Hintergrund laufen, ohne dass sofort jemand daneben sitzt? Kandidaten wären Lieferantenrecherche, erste Angebotsentwürfe, Wettbewerbsbeobachtung oder Dokumentenvergleich. Der Minimaltest: eine wiederkehrende Aufgabe auswählen, maximal 30 Minuten Laufzeit erlauben, Ergebnis in eine Review-Queue legen, und nach zehn Durchläufen zählen, wie oft du wirklich nur prüfen statt neu machen musstest. Unter sieben von zehn brauchbaren Ergebnissen ist es zu früh. Ab sieben wird es interessant. Weil der Kontrollpunkt richtig gesetzt ist.
Was von den heutigen News wirklich zählt: Kontrolle kommt nicht aus einem einzigen Feature. Sie kommt aus vielen kleinen Schichten. Lokaler Kontext, bessere Speicherverwaltung, sicherere GPU-Toolchains, eigene Modellwahl in Dokumenten und saubere Review-Queues für Agenten. Für mich ist JustFit heute deshalb der stärkste Anker. Wenn Speicherzustand, Ausführung und Interface besser werden, rückt KI wieder näher an die Geräte und Workflows der Nutzer. Wenn euch die Folge geholfen hat, hinterlasst gerne eine Bewertung auf Spotify oder Apple Podcasts. Und wenn ihr mir schreiben wollt: Die Adresse steht in den Shownotes. Danke fürs Zuhören. Pfiat euch und bis morgen, eure Lissy.