Recursive Flint im eigenen Rack: ein Coding-Agent mit 2,5 Milliarden aktiven Parametern

/01Was Recursive am 21. Oktober veröffentlicht hat

Recursive Flint ist ein offen lizenziertes Sprachmodell, das ausschließlich für die Arbeit von Coding-Agenten gebaut wurde: Code durchsuchen, Fehler finden, Funktionen umsetzen, Tests schreiben. Wer einen Coding-Assistenten im eigenen Netz betreiben will, ohne Quelltext an eine Cloud-API zu schicken, bekommt damit seit dem 21. Oktober 2026 einen neuen Kandidaten mit Apache-2.0-Lizenz und einer Rechenlast, die eher an ein 3B-Modell erinnert als an ein 40B-Modell.

Belegt ist die Veröffentlichung an drei Stellen, alle vom 21. Oktober:

• Hugging Face: Das Repository RecursiveSI/flint enthält den BF16-Checkpoint (79,59 GB), Konfiguration, Tokenizer, Chat-Template und ein Serving-Kit für SGLang. Drei Schwester-Repositories liefern die quantisierten Fassungen für Apple Silicon und NVIDIA.
• Hersteller-Blog: Recursive Superintelligence beschreibt Flint als Modell, das von einem kleinen Team und einem automatisierten Forschungssystem des Hauses („Eureka Machine") entwickelt wurde, und nennt die Laufzeitumgebungen llama.cpp, Ollama, LM Studio, vLLM und SGLang sowie eine eigene schlanke Engine namens rec für Apple Silicon.
• Ollama 0.40.8: Die Release-Notes führen Flint mit ollama run flint als 40B-MoE mit rund 2,5B aktiven Parametern und 262K Kontext — mit dem Zusatz, dass Flint vorerst nur unter macOS unterstützt wird und andere GPUs in einer späteren Version folgen.

Für ein Haus mit eigener Entwicklungsabteilung ist das die eigentliche Nachricht: Ein Coding-Modell mit Herstellerwerten in der Klasse deutlich größerer Modelle, das auf einem Entwickler-Mac mit 48 GB läuft und dessen Lizenz keine Nutzungsschwellen kennt. Was das für einen Server im Rack heißt, ist eine andere Frage — und die beantwortet die Modellkarte nur teilweise.

/02Architektur: warum 2,5 Milliarden aktive Parameter reichen sollen

Flint ist ein Mixture-of-Experts-Transformer mit 49 Schichten: zwei dichte Schichten, danach 47 MoE-Schichten mit je 256 Experten, von denen sechs je Token ausgewählt werden, plus ein immer aktiver geteilter Experte. Von den 39,8 Milliarden Parametern rechnen je Token rund 2,5 Milliarden — einschließlich des Ausgabekopfs; der aktive Modellkörper allein sind nach Karte rund 2,2 Milliarden.

Für den Betrieb wichtiger ist die Attention-Struktur. 35 der 49 Schichten arbeiten mit einem gleitenden Fenster von 513 Token (das aktuelle Token plus 512 vorangehende), nur 14 Schichten sehen den vollen Kontext. Dazu kommen 32 Query-Köpfe, aber nur 4 Key/Value-Köpfe mit je 128 Dimensionen. Beides zusammen hält den KV-Cache klein, und genau das macht ein Modell mit 262.144 Token dokumentiertem Kontextfenster auf moderater Hardware erst denkbar. Ein Coding-Agent liest ganze Dateibäume, Testausgaben und Diffs in den Prompt; ein Modell, dessen Cache mit jedem Token in allen Schichten wächst, stößt dabei früher an die Speichergrenze als an die Rechengrenze.

Zwei Angaben passen nicht zusammen, und das sollte man wissen, bevor man plant. Die Modellkarte nennt 262.144 Token als dokumentierte Kontextkonfiguration, einschließlich Prompt und Ausgabe. Der Hersteller-Blog spricht von einem Fenster „bis 512k", mit 256k als Empfehlung für die besten Ergebnisse. Für die Planung gilt die Karte: Alle Startbefehle des Herstellers setzen 262.144 Token, und die Karte ergänzt selbst, dass die Kontextlänge eine Kapazitätsgrenze ist, keine Zusage gleichbleibender Qualität über alle Längen.

Der Wissensstand des Modells endet laut Karte im Juni 2026. Ein- und Ausgabe sind reiner Text — Screenshots einer Oberfläche oder ein Foto vom Whiteboard verarbeitet Flint nicht. Die Karte nennt keine unterstützten natürlichen Sprachen; ob Flint deutsche Ticketbeschreibungen so gut versteht wie englische, ist nicht belegt und gehört in den eigenen Test.

/03Speicherrechnung: Gewichte und KV-Cache bis 262k Kontext

Die Gewichte sind der einfache Teil: Sie stehen als Dateigröße im Repository. Der Cache ist der Teil, den keine Karte in Gigabyte nennt. Aus den Architekturangaben lässt er sich aber ausrechnen — das ist unsere Rechnung, keine Herstellerangabe:

# KV-Cache je Token, nur Full-Attention-Schichten, BF16/F16 (2 Byte)
14 Schichten × 4 KV-Köpfe × 128 Dim × 2 (K und V) × 2 Byte = 28.672 Byte/Token

# Gleitendes Fenster, fest je Sequenz (35 Schichten × 513 Token)
35 × 513 × (4 × 128 × 2 × 2 Byte) = 36.771.840 Byte ≈ 37 MB

# Kontext       KV (Full-Attention)   + Fenster
#   8.192 Tok   ≈ 0,23 GB              + 0,04 GB
#  32.768 Tok   ≈ 0,94 GB              + 0,04 GB
# 131.072 Tok   ≈ 3,76 GB              + 0,04 GB
# 262.144 Tok   ≈ 7,52 GB              + 0,04 GB

Die F16-Annahme ist keine Wahl von uns: Die Startbefehle des Herstellers für llama.cpp setzen den Cache ausdrücklich auf -ctk f16 -ctv f16. Legt man die Gewichte daneben, ergibt sich die Tabelle, die über die Hardware entscheidet.

Die Tabelle erklärt die Herstellerempfehlung. Eine 24-GB-Karte stellt im Betrieb rund 23 GB bereit; die NVFP4-Datei allein belegt 22,9 GB. Selbst bei 8.192 Token Kontext bleibt kein Platz für den Laufzeitpuffer, den llama.cpp für Zwischenergebnisse anlegt. Die 48 GB, die Recursive nennt, sind deshalb keine Vorsicht, sondern das, was ein voller 262k-Kontext mit Puffer tatsächlich braucht. Wer die Methode an anderen Modellen nachrechnen will, findet sie in KV-Cache verstehen.

Die gute Nachricht steckt in der zweiten Spalte: Weil der Cache nur in 14 Schichten wächst, kostet jede weitere Sitzung mit 32k Kontext unter einem Gigabyte. Auf einer 96-GB-Karte bleiben neben den NVFP4-Gewichten rund 70 GB, rechnerisch genug für viele parallele Entwicklersitzungen. Ob die Karte die Rechenlast dieser Sitzungen trägt, sagt die Rechnung nicht — das ist eine Durchsatz-Frage, und die beantwortet nur eine Messung.

/04Startbefehle: llama.cpp, SGLang und Ollama

Recursive liefert für jede Fassung einen fertigen Startbefehl. Die beiden für NVIDIA-Hardware stehen hier wörtlich aus den Repositories; nur die Kommentare sind von uns:

# 1) NVFP4-GGUF mit llama.cpp (CUDA-Build mit Flint-Unterstützung)
#    getestet laut Karte: B300, RTX PRO 6000 Blackwell, RTX Spark, DGX Spark
hf download RecursiveSI/flint-nvfp4-gguf flint-nvfp4.gguf pi-models.json opencode.json \
  --local-dir flint-nvfp4-gguf
llama-server -m flint-nvfp4-gguf/flint-nvfp4.gguf \
  --alias flint -ngl all -c 262144 -np 1 \
  -fa on -ctk f16 -ctv f16 --jinja \
  --temp 1 --top-p 0.95 --top-k 20 --min-p 0 \
  --host 127.0.0.1 --port 8080

# 2) BF16 mit dem SGLang-Kit (SGLang 0.5.16), eine GPU mit >= 141 GB
hf download RecursiveSI/flint --local-dir flint && cd flint   # rund 80 GB
docker build -t flint-sglang sglang
docker run -d --name flint --gpus '"device=0"' --ipc=host -p 127.0.0.1:30000:30000 \
  -v "$PWD:/model" -e MODEL=/model flint-sglang bash /model/sglang/serve_b300.sh
#    auf H200: serve_h200.sh

# 3) Ollama 0.40.8 — vorerst nur macOS
ollama run flint

Fünf Hinweise aus den Karten, die man vor dem ersten Start kennen sollte:

• Fenster-Cache nicht vergrößern. Die Karte bittet ausdrücklich, --swa-full nicht zu setzen. Ohne den Schalter hält llama.cpp für die 35 Fensterschichten nur 513 Token vor; mit ihm würde der Cache in allen Schichten wachsen und die Rechnung aus /03 nicht mehr gelten.
• Client und Server gleich einstellen. Die mitgelieferten Konfigurationen für die Agent-Werkzeuge pi und OpenCode rechnen mit 262.144 Token Kontext und einem Ausgabebudget von 65.536 Token. Wer -c senkt, muss den Wert im Client mitziehen, sonst schickt der Agent Prompts, die der Server ablehnt.
• Ausgabebudget großzügig setzen. Flint denkt bei schweren Aufgaben lange nach. Die Karte empfiehlt für harte Probleme mindestens 32.768 Token Ausgabe einschließlich Reasoning und verlangt, das zurückgegebene reasoning_content im Verlauf zu behalten.
• 80-GB-Karten fallen beim BF16-Weg heraus. Das SGLang-Kit schreibt wörtlich, dass GPUs mit 80 GB nicht unterstützt werden, und verlangt einen Treiber ab Version 580 (CUDA 13). Validiert sind B300 und H200; B200 und GB200/GB300 nutzen dieselben Schalter, sind aber noch nicht validiert. Der erste Start dauert auf einer B300 laut Kit rund vier Minuten.
• Transformers-Code fehlt noch. Die Karte sagt, dass der Modellcode für Transformers noch nicht enthalten ist. Der Blog nennt vLLM als unterstützte Laufzeit; einen vLLM-Befehl liefert Recursive bislang nicht. Wer vLLM im Haus standardisiert hat, wartet auf eine Release-Note mit Flint-Eintrag.

Die NVFP4-Fassung ist für Blackwell gebaut; auf älteren Karten wie einer Ada- oder Ampere-Generation ist sie weder getestet noch dokumentiert. Für den Mac gibt es zwei Wege: Ollama mit einer Zeile oder llama.cpp mit Metal und der Q4_1-Datei, die auf Rechnern ab 48 GB Unified Memory laufen soll. Recursive nennt für ein M4-Pro-MacBook-Pro mehr als 125 Token je Sekunde und für ein RTX Spark mit 64 GB mehr als 150 — Herstellerangaben bei kurzem Kontext, deren Messbasis der Blog nicht eindeutig beschreibt.

/05Benchmarks: was 74,2 Prozent auf SWE-bench Verified sagen

Recursive nennt in der Modellkarte drei Benchmark-Werte: 54,9 Prozent auf Terminal-Bench 2.1, 74,2 Prozent auf SWE-bench Verified und 89,7 Prozent auf SWE-bench Pro v2. Alle drei sind Herstellerangaben aus den eigenen Release-Evaluationen. Der Messaufbau ist ungewöhnlich offen beschrieben: Temperatur 1,0, Top-p 0,95, Top-k 20; Terminal-Bench mit dem Harness Terminus 2, SWE-bench mit mini-swe-agent; gemittelt wird pass@1 über mindestens fünf Versuche. Recursive wertet außerdem Terminal-Bench-Lösungen, die über eine Websuche gefunden wurden, als Fehlschlag — und weist selbst darauf hin, dass andere Hersteller diese Korrektur nicht unbedingt anwenden.

Zur Einordnung zwei Werte aus anderen Modellkarten derselben Wochen, ebenfalls Herstellerangaben auf Terminal-Bench 2.1: NVIDIA gibt für Nemotron 3.5 Bolt, ein 74B-Modell mit 2-Bit-Quantisierung für 24 GB, 50,98 an; Meta für Muse Spark Open mit 816 Milliarden Parametern in der höchsten Reasoning-Stufe 76,4. Flint liegt dazwischen — mit einem Bruchteil der Rechenlast des einen und des Speichers des anderen. Das ist die eigentliche Aussage dieser Zahlen: nicht, welches Modell gewinnt, sondern dass die Leistungsklasse, für die vor einem Jahr ein Rack nötig war, auf einen Arbeitsplatzrechner rückt.

Was die Zahlen nicht sagen, ist mindestens so wichtig. Erstens gelten sie für den BF16-Checkpoint; für NVFP4 nennt der Blog einen Abstand von höchstens 0,7 Punkten zum 16-Bit-Modell über die eigenen Benchmarks, für die MLX- und Q4_1-Fassungen gibt es keine Zahl. Zweitens messen SWE-bench und Terminal-Bench öffentliche Python- und Shell-Aufgaben, nicht Ihr ERP-Customizing, Ihre ABAP-Reports oder Ihre zwanzig Jahre alte Delphi-Anwendung. Drittens schreibt Recursive selbst, dass Flint mehr Führung braucht als große geschlossene Coding-Modelle und komplexe Aufgaben in kleinere Teilaufgaben mit ausdrücklichen Anweisungen zerlegt werden sollten. Ehrlich: Das ist eine nützliche Einschränkung, weil sie sagt, wie man das Modell einsetzt — als Agent mit engem Auftrag, nicht als Architekt.

Den Unterschied zum Qwen3.8-27B, das wir im August auf einer 24-GB-Karte gemessen haben, entscheiden diese Zahlen nicht: Qwen veröffentlicht Werte auf anderen Benchmark-Versionen, und Prozentpunkte aus verschiedenen Harnesses lassen sich nicht subtrahieren. Unsere Messung steht in Qwen3.8-27B auf 24 GB; ein Vergleich der beiden auf demselben Repository ist der Test, den wir jedem Haus vor einer Entscheidung empfehlen.

/06Einen lokalen Coding-Agenten absichern

Ein Coding-Agent unterscheidet sich von einem Chat-Assistenten durch eine Eigenschaft: Er führt aus. Er liest Dateien, schreibt Patches, startet Tests und Shell-Befehle — über Werkzeugaufrufe, die Flint im OpenAI-kompatiblen Format beherrscht. Die Modellkarte sagt dazu einen Satz, der in jedes Betriebskonzept gehört: Die strukturierte Grammatik der Werkzeugaufrufe verhindert nicht, dass das Modell eine unsichere oder falsche Aktion wählt; Anwendungen mit Werkzeugen müssen eigene Rechte und Ausführungsgrenzen durchsetzen.

In der Praxis heißt das fünf Maßnahmen, bevor Flint an ein echtes Repository darf:

1. Endpunkt nicht ins Netz. Das SGLang-Kit warnt selbst: Die Server lauschen auf 0.0.0.0 ohne Authentifizierung. Ports nur auf 127.0.0.1 oder ein privates Netz veröffentlichen, oder --api-key setzen und den Schlüssel an die Clients verteilen. Der llama.cpp-Befehl des Herstellers bindet bereits an 127.0.0.1. Warum ein offener Inferenz-Port kein Kavaliersdelikt ist, steht in LLMjacking stoppen.
2. Agent in eine Sandbox. Der Agent arbeitet in einem Container oder einer MicroVM mit einer Arbeitskopie des Repositories — nicht auf dem Entwicklerrechner mit Zugriff auf SSH-Schlüssel und Cloud-Zugangsdaten. Welche Isolation für welchen Fall reicht, vergleicht Agenten-Sandboxing 2026.
3. Ausgehenden Verkehr sperren. Erlaubt sind der Paketspiegel und das interne Git, sonst nichts. Ein Agent, der Abhängigkeiten aus dem offenen Internet nachlädt, ist ein Einfallstor für Prompt Injection über präparierte README-Dateien und Paketbeschreibungen.
4. Keine Produktionsgeheimnisse im Arbeitsverzeichnis. .env-Dateien, Deploy-Schlüssel und Datenbankzugänge gehören nicht in den Kontext eines Modells, das sie in einem Testlauf ausgeben könnte.
5. Jeder Patch geht durch ein Review. Der Agent schreibt in einen Branch, ein Mensch merged. Die Karte empfiehlt ausdrücklich, generierten Code zu testen und folgenreiche Änderungen vor dem Übernehmen zu prüfen. Das ist Human-in-the-Loop als Arbeitsablauf, nicht als Formsache.

Diese Liste gilt für jedes lokale Coding-Modell, nicht nur für Flint. Bei Flint kommt hinzu, dass das Modell einen Tag alt war, als wir diesen Artikel geschrieben haben: Es gibt noch keine Erfahrung darüber, wie es sich in langen Agentensitzungen gegen manipulierte Eingaben verhält.

/07Wann Flint die falsche Wahl ist

Flint ist ein gutes Angebot für einen eng umrissenen Zweck. Falsch ist es in sechs Fällen:

• Sie haben nur eine 24-GB-Karte. Die Rechnung aus /03 lässt keinen Spielraum, der Hersteller empfiehlt 48 GB, und unter Linux unterstützt Ollama das Modell noch nicht. Auf 24 GB bleibt ein dichtes 27B- bis 31B-Modell in 4-Bit die belegte Wahl.
• Sie brauchen Bilder. Flint ist reines Textmodell. Wer dem Agenten Screenshots einer Fehlermeldung oder einer Oberfläche zeigen will, braucht ein Vision-Language-Modell.
• Die Aufgaben sind groß und vage. „Bau uns das Kundenportal neu" ist kein Auftrag für ein Modell, das laut Hersteller mehr Führung braucht als große geschlossene Modelle. Flint passt zu „Behebe den fehlschlagenden Test in diesem Modul".
• Sie standardisieren auf vLLM oder Transformers. Der dokumentierte Serverweg ist SGLang bzw. llama.cpp; Transformers-Code fehlt laut Karte noch. Wer heute einführt, betreibt eine zweite Inferenz-Engine neben der bestehenden.
• Niemand prüft den Code. Ein Coding-Agent ohne Review-Pflicht beschleunigt nicht die Entwicklung, sondern die Fehlerproduktion. Ohne einen Menschen, der Diffs liest, ist die Investition in Hardware verschenkt.
• Sie brauchen Nachweise über Herkunft und Trainingsdaten. Die Karte beschreibt die Trainingsdaten nur allgemein (öffentliche und gecrawlte Webdokumente, lizenzierte und synthetische Daten). Für eine Anwendung mit Audit-Anforderung an die Datenherkunft reicht das nicht.

Die meisten Mittelständler mit eigener Entwicklung fallen in keinen dieser Fälle vollständig. Dann ist Flint ein Kandidat für einen zweiwöchigen Test — nicht für eine Beschaffungsentscheidung am Erscheinungstag.

/08Entscheidung: welche Hardwareklasse für welchen Einsatz

Die Entscheidung hängt an zwei Fragen: Wie viele Entwickler arbeiten gleichzeitig mit dem Agenten, und welche Hardware steht schon da. Die Tabelle trennt, was der Hersteller belegt, von dem, was wir daraus ableiten.

Daraus folgt eine einfache Reihenfolge. Erprobung: ein Entwickler-Mac ab 48 GB mit Ollama, zwei Wochen, ein echtes internes Repository, ein Vergleichsmodell daneben. Teambetrieb: eine Blackwell-Karte mit 96 GB oder ein 192-GB-System im Serverraum, Endpunkt nur intern erreichbar, Agent in der Sandbox. Volle Präzision lohnt erst, wenn die Erprobung zeigt, dass die Abweichung der quantisierten Fassung bei Ihren Aufgaben spürbar ist — für die NVFP4-Fassung nennt der Hersteller unter einem Punkt.

Zum Maßstab, was ein Mehrkartensystem leistet: Wir haben auf einem 192-GB-System mit Qwen3 27B 3.900 Token je Sekunde gemessen, summiert über viele parallele Anfragen. Für Flint mit einem Zehntel der aktiven Parameter ist eine eigene Messung nötig; dass die Rechenlast je Token geringer ist, lässt höhere Werte erwarten, belegt sie aber nicht.

Wer noch klären muss, ob ein Coding-Agent für die eigene Entwicklung überhaupt der richtige Hebel ist, findet die Grundlagen in Vibe Coding 2026. Dieser Artikel setzt eine Stufe später an: bei der Frage, mit welchem Modell und auf welcher Hardware. Die Inferenz ist dabei der kleinere Teil der Arbeit — Repository-Anbindung, Rechte und die Leitplanken des Agenten machen den größeren aus, und sie bleiben, wenn das Modell in sechs Monaten gewechselt wird.