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.

Im neuen Ollama-Release ist ein Coding-Modell dabei, das zuerst auf macOS läuft und erst später auf anderen GPUs — das ist mir noch nicht oft begegnet: https://github.com/ollama/ollama/releases/tag/v0.40.8 Was im Release steht: Flint von Recursive ist ein Mixture-of-Experts-Modell mit 40B Parametern, davon rund 2,5B aktiv pro Token. Kontextfenster 262K Token, Apache 2.0, ausgelegt auf Reasoning und Multi-Turn Tool Use, also auf die Arbeit, die Coding-Agents über ein ganzes Repository machen: fremden Code verstehen, Bugs verfolgen, Features bauen, Tests ergänzen. Recursive nennt in den eigenen Release-Evaluationen 54,9 % auf Terminal-Bench 2.1 und 74,2 % auf SWE-bench Verified. Und dann dieser Satz: "Flint is supported on MacOS. Other GPU support will be enabled in a subsequent release." Interessanter als die Benchmarks finde ich das Architektur-Detail. 2,5B aktive Parameter pro Token sind das Profil, das auf Apple Silicon gut funktioniert, weil pro Token nur ein Bruchteil der Gewichte durch die Speicherbandbreite muss. Dichte Modelle in der Klasse 27B oder 32B tun sich hier deutlich schwerer — MoE-Modelle dieser Größenordnung laufen bei mir merklich schneller bei vergleichbarer Qualität. Als Rechenhilfe für die eigene Maschine: Grob kannst du bei 4-bit mit etwa einem halben Gigabyte pro Milliarde Gesamtparameter rechnen, bei 40B landest du also bei rund 22 GB nur für die Gewichte. Dazu kommt der KV-Cache, und der skaliert mit der Kontextlänge, nicht mit den aktiven Parametern. Das heißt: Die 262K Token sind der eigentliche Speicherfresser, nicht das Modell. Auf meinem M2 Max mit 96 GB ist das unkritisch, auf einem 32-GB-Büro-Mac wird es bei großem Kontext eng. Die Lizenz erlaubt dir alles, die Hardware nicht. Wenn du nicht über Ollama gehen willst: GGUF-Dateien gibt es schon, von Recursive selbst und von Unsloth. Eine MLX-Fassung bietet Recursive ebenfalls an, die läuft bisher aber nur über das eigene Tool „Rec“; in mlx-lm ist Flint noch nicht drin, der Pull Request dafür ist offen. Und spannend finde ich Flint weniger als Ersatz für Claude Code — ein riesiges Kontextfenster bringt wenig, wenn jede Anfrage schon mit einem großen Systemprompt startet — sondern als Tool-Use-Agent in n8n: Repository lesen, Issue klassifizieren, Tests ergänzen, alles on-premise. Die Zahlen kommen vom Anbieter; wie sich das in echten Multi-Turn-Schleifen hält, ist die offene Frage.

Der n8n-Blog hat eine Anleitung veröffentlicht, wie man den kompletten KI-Bedarf eines kleinen Unternehmens ohne Cloud-API bedient – auf einer einzigen Box von NVIDIA: https://blog.n8n.io/n8n-nvidia-dgx-spark/ Was drinsteht: Die typischen Jobs sind immer dieselben – E-Mails vorformulieren, Anrufe zusammenfassen, Rechnungen auslesen, eigene Dokumente durchsuchen, gelegentlich ein Bild. Viele Betriebe dürfen dafür keine Kundendaten in die Cloud geben, weil Vertrag, Aufsicht oder Berufsrecht es verbieten. Der Beitrag nennt Klinik, Anwaltskanzlei, Steuerbüro und das Argument, das ich daran am überzeugendsten finde: Nur auf eigener Hardware kannst du einem Prüfer zeigen, wo die Daten gelandet sind. Technisch: DGX Spark mit GB10 Grace Blackwell, 128 GB Unified Memory, 273 GB/s Speicherbandbreite. Darauf Qwen3.6-35B-A3B (35B gesamt, rund 3B aktiv) in NVFP4 über vLLM, gemessen 120 Tokens/s für einen Nutzer und 359 Tokens/s insgesamt über acht parallele Nutzer, Reasoning-Tokens eingerechnet. Davor ein OpenAI-kompatibler Endpunkt über LiteLLM mit Keys pro Team, und n8n hängt mit seinen bestehenden OpenAI-Nodes direkt dran. Der Satz, der für uns zählt, ist die Begründung der Modellauswahl: nach Bandbreite wählen, nicht nach Parameterzahl. Beim Generieren liest das Modell für jeden Token seine aktiven Gewichte aus dem Speicher – je weniger Bytes, desto schneller. Genau das ist der Grund, warum ein MoE mit wenigen aktiven Parametern ein dichtes Modell schlagen kann, obwohl es insgesamt größer ist. Für dein Setup heißt das: Rechne grob. Teile die Speicherbandbreite deines Macs durch die Bytes, die ein Token an aktiven Gewichten liest. Bei rund 3B aktiven Parametern in 4 Bit liegst du bei etwa 1,5 GB pro Token – bei 273 GB/s wären das theoretisch rund 180 Tokens/s, und die gemessenen 120 zeigen, wie viel Abstand zwischen Rechnung und Realität bleibt. Nimm die Bandbreite deiner eigenen Maschine und mach dasselbe Dreisatz-Spiel. Das Ergebnis ist keine Messung, aber es sagt dir, ob ein Modell in deinem Rahmen überhaupt sinnvoll sein kann, bevor du es lädst.