Auf Hacker News ist mir ein Repo aufgefallen, das ich für unsere Zwecke interessanter finde als die Modellankündigungen dieser Woche: GVS5H von slee-persis, https://github.com/slee-persis/GVS5H Der Ansatz heißt im Paper "ledger-based zero-shot self-orchestration" und ist trainingsfrei. Frische Instanzen desselben Modells zerlegen eine Aufgabe und koordinieren sich über ein gemeinsames Dateisystem, in dem ein Plan, Notizen und die aktuelle Lösung liegen. Kein Finetuning, kein spezielles Agenten-Framework. Die Zahlen beziehen sich auf die 100 neuesten harten LiveCodeBench-Probleme, über elf offene und geschlossene Modelle hinweg: bis zu 25,6 Prozentpunkte Gewinn auf gepinnten Backends. Lokal serviertes, offenes Qwen3.8-27B steigt von 66,8 % auf 92,4 % pass@1. Orchestriertes Qwen3.8 Flash Next erreicht 93,0 % gegen 90,4 % von Fable 5, bei 9 % der Kosten. Die Autoren schreiben die Einschränkung selbst dazu: Die Gewinne sind nicht universell, manche Modelle bleiben gleich, manche werden schlechter. Die Transkriptanalyse führt den Effekt auf Dekomposition und persistenten Kontext zurück. Was das für eigene Hardware heißt, kann sich jeder selbst überschlagen. 27 Mrd. Parameter in 4-bit landen grob bei 15 GB, plus KV-Cache und plus das, was macOS selbst braucht. Ein einzelnes Modell dieser Größe ist auf Apple Silicon über MLX unkritisch. Fünf gleichzeitig geladene Instanzen sind es bei 32 oder 64 GB nicht mehr – da lohnt es sich, einmal nachzurechnen, statt es zu probieren. Die Frage, die ich dabei spannend finde: Braucht das Verfahren überhaupt echte Parallelität? Der beschriebene Kern ist der geteilte Zustand auf der Platte, nicht die Gleichzeitigkeit. Wenn mehrere sequenzielle Durchläufe über denselben Endpunkt denselben Plan und dieselben Notizen lesen und schreiben, tauscht man RAM gegen Zeit. Ob das denselben Effekt erzeugt, steht so nicht im Paper – aber es ist die Hypothese, die man lokal am günstigsten prüfen kann. Für n8n ist die Botschaft ähnlich: Der entscheidende Baustein ist ein Plan, Notizen und eine aktuelle Lösung an einem Ort, den alle Durchläufe sehen. Das sind Dateien oder eine Tabelle, keine zusätzliche Abstraktionsschicht.

NVIDIA hat am Freitag Nemotron-3.5-Bolt-E4B veröffentlicht, ein nachtrainiertes Gemma 4 E4B (8B, 4B effektiv) für Tool-Use auf kleinen Geräten. Ich habe es auf dem M2 Max durch denselben Agententest geschickt wie Flint. Aufsetzen geht schnell, weil es technisch ein Gemma 4 ist und mlx-vlm 0.7.10 das schon kann: 1. Das offizielle BF16 laden (nvidia/NVIDIA-Nemotron-3.5-Bolt-E4B-BF16, 16 GB). 2. python -m mlx_vlm convert --hf-path --mlx-path -q --q-bits 4 --q-group-size 64. Das dauerte 7 Sekunden, ergibt 4,8 GB (8-Bit: 8,3 GB). 3. Achtung: Im Chat-Template steht enable_thinking standardmäßig auf false, obwohl die Modellkarte „an“ nennt. Also in jeder Anfrage ausdrücklich setzen. Und mlx-vlm gibt das Denken bei Gemma 4 nur mit Tools zurück; ohne Tools wird gedacht, der Text aber verworfen. Zahlen (4-Bit): 86 Token pro Sekunde, Einlesen rund 1.130 Token pro Sekunde, 6 GB im Leerlauf, 12 GB Spitze. 8-Bit: 57 Token pro Sekunde, 10 bis 16 GB, inhaltlich nicht besser. Der Agententest: 24 verkettete Belege, rund 30 Runden, unterwegs meldet ein Werkzeug „Datei gesperrt“. Alle 168 Tool-Calls waren gültig, nichts erfunden, keine Schleifen. Aber in 8 von 10 Läufen hört Bolt vor dem Ende auf, in 6 davon genau an der Sperre: Es schreibt das Teilergebnis aus 9 von 24 Belegen und meldet Erfolg. Viermal ohne den Fehler zu erwähnen („Alle Belege wurden verarbeitet“), nur einmal ehrlich. Keine einzige Summe stimmte, mit und ohne Reasoning. Im 105-Punkte-Test 69 (4-Bit) bzw. 70 (8-Bit) mit Reasoning, 62 ohne. Die erste Code-Aufgabe stürzt in allen Läufen ab. Meine Lesart: Für kurze, einstufige Tool-Aufrufe (Sprachassistent, Gerätesteuerung) kann es passen. Für Agenten über viele Schritte nicht, weil die Erfolgsmeldung nach dem Abbruch nicht stimmt. Wer so etwas einsetzt, sollte das Ergebnis gegen die Eingaben prüfen und sich nicht auf die Meldung verlassen. Einschränkungen: ein Mock-Test, ein bis zwei Läufe je Einstellung, die Basis Gemma 4 E4B nicht im selben Test. NVIDIAs Benchmarks (z. B. Tau2-Bench 55,1) habe ich nicht nachgemessen; offizielle Laufzeit ist vLLM.

Ich habe Recursive Flint (40B MoE, 2,5B aktiv, Apache 2.0) auf meinem M2 Max mit 96 GB getestet, mit Fokus auf eine Frage: Bleiben die Tool-Calls in einer Agentenschleife über viele Runden stabil? Der Test: fünf Werkzeuge, 24 verkettete Belege (jeder nennt den Pfad des nächsten), also rund 30 Runden nacheinander. Unterwegs meldet ein Werkzeug „Datei gesperrt“, ein Beleg ist storniert, am Ende sollen Summen je Kunde in eine Datei. Jeder Call wird geprüft: Werkzeugname, gültiges JSON, Pflichtfelder, keine erfundenen Parameter. Ergebnis mit Reasoning: 156 von 156 Calls gültig, stabil bis 70.000 Token, die Sperre jedes Mal erneut versucht. Fehler nur beim Kopfrechnen (2 von 5 Läufen mit falscher Summe). Ohne Reasoning (erzwungen, einen offiziellen Schalter gibt es nicht) liest Flint ab Runde 7 bis 14 dieselben Belege im Kreis und schreibt „path“ statt „filePath“. Für Agenten also Reasoning an lassen. Zahlen: 77 bis 87 Token pro Sekunde, Einlesen 868 Token pro Sekunde bei 7.000 und 336 bei 131.000 Token. Speicher 21 GB im Leerlauf, 26 bis 38 GB in der Schleife. Der KV-Cache bleibt klein, weil nur 14 von 49 Schichten volle Attention haben. Im 105-Punkte-Test 74 Punkte, gleichauf mit Kolibri. So läuft es bei mir, falls du es nachbauen willst: 1. mlx-vlm ab 0.7.10 in eine eigene venv (pip install "mlx-vlm==0.7.10"). mlx-lm kann Flint noch nicht. 2. RecursiveSI/flint-int4 lädt nicht direkt: Die Gewichte liegen als U8 statt uint32 vor, und in der config.json fehlt "model.embed_tokens": {"group_size": 64, "bits": 8}. Ein kleines Skript mit mx.load, .view(mx.uint32) und mx.save_safetensors behebt das, die Werte bleiben bitgleich. 3. Server mit APC_ENABLED=1 starten. Der Prefix-Cache ist in mlx-vlm standardmäßig aus, dann liest jede Runde den ganzen Verlauf neu (bei 28.000 Token 45 statt 1 Sekunde). 4. AGX_RELAX_CDM_CTXSTORE_TIMEOUT=1 setzen. Ohne bricht macOS das Einlesen ab etwa 70.000 Token mit „Impacting Interactivity“ ab. Kleinere Prefill-Schritte helfen nicht. 5. In jeder Anfrage "enable_thinking": true mitschicken, sonst landet das Denken im Antworttext.