Recursive Flint 40B-A2.5B: Ein Coding-Modell, das zuallererst auf Geschwindigkeit ausgelegt ist

Die Zahl, die entscheidet, ob Recursive Flint 40B-A2.5B Ihren Speicherplatz wert ist, ist nicht 54,9 %. Sie ist 2,5. Recursives erstes Coding-Modell mit offenen Gewichten umfasst 39,8 Milliarden Parameter und aktiviert für jedes Token, das es schreibt, ungefähr 2,5 Milliarden davon, und nahezu jede andere Entscheidung in der Veröffentlichung – das Attention-Layout, das Quantisierungsrezept, der maßgeschneiderte Metal-Kernel, die Inferenz-Engine – folgt aus diesem einen Verhältnis. Flint wurde am 21. Oktober 2026 unter Apache 2.0 veröffentlicht, womit es zum Zeitpunkt des Schreibens einen Tag alt ist und sich in dem Fenster befindet, in dem ein Launch noch Nachricht statt Geschichte ist. Da eine einen Tag alte Benchmark-Tabelle ein Versprechen statt einer Messung ist, führen wir die Produktionsbilanz getrennt: das AI Incident Archive protokolliert, wie sich Behauptungen von Modellen und Anbietern bewährt haben, sobald sie echten Traffic bedienen.

Die Kurzfassung für alle, die sich gerade jetzt entscheiden: Es ist ein Sparse-Mixture-of-Experts-Modell, das darauf ausgelegt ist, das schnellste Modell seiner Gewichtsklasse auf einem Laptop zu sein; es veröffentlicht drei agentische Coding-Ergebnisse, die alle vom Anbieter stammen und nicht reproduziert wurden; und es ist das erste Modell eines Unternehmens, dessen erklärtes Ziel es ist, die Forschung zu automatisieren, die Modelle hervorbringt. Alle drei dieser Fakten sind wichtig, und der dritte ist derjenige, der auch in einem Jahr noch interessant sein wird.

Was tatsächlich ausgeliefert wurde

Vier Repositories, nicht nur eines. Das Haupt-Repository RecursiveSI/flint enthält den BF16-Checkpoint, die Konfiguration, den Tokenizer, das Chat-Template und ein SGLang-Serving-Kit, und es wurde am 21. Oktober 2026 um 14:20 UTC erstellt. Daneben liegen drei quantisierte Varianten, alle am selben Nachmittag datiert: ein int4-Safetensors-Build, ein int4-GGUF und ein NVFP4-GGUF. Jede unten angegebene Größe wurde aus den Dateilisten der Repositories selbst ermittelt und nicht aus der Ankündigung übernommen.

• BF16-Referenz — 79,59 GB verteilt auf 37 Dateien, in 15 Safetensors-Shards von jeweils etwa 5,37 GB. Dies ist das Fine-Tuning-Artefakt – und genau das, was man für die Inferenz nicht herunterladen möchte.

• NVFP4 GGUF — 22,86 GB in einer einzigen Datei, der kleinste veröffentlichte vollständige Inferenz-Build.

• Int4 GGUF — 25.99GB, eine q4_1-Quantisierung, die größer als die NVFP4-Datei ist, was genau umgekehrt zur Namensreihenfolge ist und was man wissen sollte, bevor man nach Dateinamen auswählt.

• Int4-Safetensors — 22,58 GB, für Laufzeitumgebungen, die aufgeteilte Gewichte einem einzelnen GGUF vorziehen.

Die Lizenz ist Apache 2.0, wobei die Modellkarte die Unterscheidung ergänzt, dass Bedingungen für die gehostete API und Datenpraktiken getrennt von der Gewichte-Lizenz sind – die übliche Trennung, klar benannt statt verborgen.

Die Architektur ist ein Argument in Bezug auf die Speicherbandbreite.

Auf einem Laptop ist das Dekodieren eines Tokens größtenteils kein Rechenproblem. Es ist ein Problem, Gewichte schnell genug vom Speicher zu den Recheneinheiten zu bewegen, weshalb ein dichtes Modell mit 40 Milliarden Parametern langsam ist, egal wie gut der Chip ist: Jedes Token liest jedes Gewicht. Flints Antwort darauf ist, fast keines davon zu lesen.

• Sparsität – 256 geroutete Experten pro MoE-Schicht, von denen pro Token 6 ausgewählt werden, plus ein stets aktiver gemeinsam genutzter Experte. Von den 49 Schichten sind 2 dicht und 47 MoE, sodass alle außer den ersten beiden bedingte Arbeit verrichten.

• Aktive Parameter — insgesamt 39,8 Mrd., pro Token etwa 2,5 Mrd. aktiv, einschließlich des Output-Heads, woher die Bezeichnung „40B-A2.5B“ stammt. Der aktive Body allein umfasst etwa 2,2 Mrd.

• Attention — 35 Sliding-Window-Schichten mit einem Fenster von 513 Token (das aktuelle Token plus die 512 vorangehenden), verzahnt mit 14 Full-Attention-Schichten. Nur 32 Query-Heads und 4 Key-Value-Heads bei einer Head-Dimension von 128, sodass der KV-Cache klein genug bleibt, um lange Agent-Sessions praktikabel zu machen.

• Positionskodierung — Rotary Embeddings auf den Sliding-Window-Schichten und gar keine auf den Full-Attention-Schichten, eine Entscheidung, die die Model Card nennt, ohne sie zu erklären. Per-Head-QK-RMSNorm und gelernte Per-Head-Attention-Sinks übernehmen die Stabilitätsarbeit, die Positionskodierung normalerweise mitträgt.

• Kontext — 262.144 Tokens dokumentiert, und die Modellkarte stellt ausdrücklich klar, dass dies Prompt und generierte Ausgabe zusammen umfasst. Die Ankündigung bewirbt „bis zu 512k“ und empfiehlt dann, beim Coding innerhalb von 256k zu bleiben. Beide Aussagen stammen vom selben Anbieter und stehen nur einen Absatz auseinander.

Das interessante Detail ist, wie die Form gewählt wurde. Recursive sagt, seine Eureka Machine – eine automatisierte Forschungsloop, die Ideen vorschlägt, umsetzt, testet und kombiniert, was funktioniert – habe mit einer Baseline von 35 Milliarden Parametern und 3 Milliarden aktiven begonnen und Expertenkonfigurationen und -breiten durchsucht. Die resultierende 40B/2.5B-Konfiguration war – nach der eigenen Formulierung der Ankündigung – „prognostiziert, die beste Kombination aus Geschwindigkeit und Coding-Leistung unter den Konfigurationen zu bieten, die unsere Eureka Machine getestet hat“. Prognostiziert, nicht durch einen Vergleichstest fertiger Modelle bewiesen. Das ist eine normale Art, eine Architektur auszuwählen, wenn Trainingsläufe teuer sind, und es ist zugleich eine Behauptung, der ein späterer Checkpoint stillschweigend widersprechen könnte.

Die drei Partituren und die dazugehörigen Fußnoten

Flint erreicht 54,9 % bei Terminal-Bench 2.1, 89,7 % bei SWE-bench Pro v2 und 74,2 % bei SWE-bench Verified. Diese Zahlen erscheinen als Release-Evaluierungen in der Modellkarte, und kein Drittanbieter hat eine Messung dieses Modells veröffentlicht – der Artificial Analysis model index, die übliche unabhängige Instanz für einen Launch wie diesen, hat Stand 22. Oktober überhaupt keinen Flint-Eintrag. Alles Folgende ist also Recursive, das Recursive misst.

Was der Anbieter über seine eigene Methodik offenlegt, ist mehr, als die meisten Launch-Posts freiwillig preisgeben, und es verändert, wie die Zahlen gelesen werden sollten:

• Terminal-Bench 2.1 — ausgeführt mit dem Terminus-2-Harness, mit aktiviertem Internetzugang, wobei Lösungen, die durch Webabruf erlangt wurden, als Fehlschläge gewertet wurden. Diese letzte Anpassung ist eine bewusste Erschwernis, und die Modellkarte merkt an, dass veröffentlichte Punktzahlen anderer Entwickler sie möglicherweise nicht anwenden, wodurch ein direkter Vergleich mit Zahlen Dritter eher schwieriger als einfacher wird.

• SWE-bench Pro v2 und SWE-bench Verified – ausgeführt mit mini-swe-agent und ganz ohne Internetzugang, eine schwierigere Einstellung als bei Agenten, die während der Aufgabe in der Dokumentation suchen können.

• Versuche und Timeouts — durchschnittliches pass@1 über mindestens fünf Versuche, mit Agenten-Timeouts von bis zu fünf Stunden. Fünf gemittelte Versuche sind ein vernünftiges Protokoll; Timeouts von fünf Stunden bedeuten, dass dies Scores für einen Agenten sind, den man bereit ist, laufen zu lassen, nicht für eine Autovervollständigung.

• Sampling — Temperatur 1.0, top-p 0.95, top-k 20 bei jeder Evaluierung, und das Serving-Kit wendet diese Standardwerte an, wenn eine Anfrage sie nicht angibt.

Eine Benchmark-Tabelle eines Anbieters ist zugleich eine Aussage darüber, welche Peers er gewählt hat. Recursives eigene Grafik vergleicht Flint mit Qwen 3.5, Qwen 3.6, Qwen 3.8, Laguna XS 21, Muse Glimmer und Gemma 4 – lokale Modelle, die auf ähnliche Hardware passen, was die ehrliche Vergleichsgruppe für ein Laptop-Modell ist und zugleich eine Gruppe, die so ausgewählt wurde, dass das Sparsity-Argument gut aussieht. Die aufgestellte Behauptung ist eng und verteidigbar: Flint führt MoE-Modelle unter 50 Milliarden Gesamtparametern beim agentischen Coding an und konkurriert mit dichten Modellen mit 25 bis 40 Milliarden Parametern, während es deutlich schneller läuft. Es ist keine Behauptung über Frontier-Coding-Modelle, und Recursive stellt keine auf – die Ankündigung sagt unumwunden, dass Flint „möglicherweise mehr Anleitung braucht als die größeren Closed-Source-Coding-Modelle, die Sie gewohnt sind.“

Geschwindigkeit: woran die 2× tatsächlich gemessen wird

Recursive meldet mehr als 125 Token pro Sekunde auf einem M4 Pro MacBook Pro und mehr als 150 Token pro Sekunde auf einem 64GB NVIDIA RTX Spark bei kurzen Kontexten und beschreibt das als bis zu doppelt so schnell wie vergleichbare Modelle und mehr als fünfmal so schnell wie dichte Modelle mit 25 bis 40 Milliarden Parametern und ähnlichen Coding-Werten. Die Methodik-Fußnote zum Geschwindigkeitsdiagramm ist der Teil, den man lesen sollte: durchschnittliche Token pro Sekunde über eine Sitzung mit 128.000 Token, Prefill ausgeschlossen, wobei ein Wettbewerber bei 124k statt über die volle Länge gemessen wurde.

Dass Prefill ausgeschlossen wird, ist gängige Praxis beim Decode-Benchmarking und spielt auch hier eine Rolle, denn Prefill ist genau der Teil, in dem ein Coding-Agent seine Zeit verbringt, wenn er ein Repository in das Kontextfenster lädt. Eine Zahl, die nur die Decode-Hälfte einer 128k-Sitzung misst, wird jedes Modell mit sparsamer Aktivierung schmeicheln, und Flints gesamtes Design ist sparsame Aktivierung. Nichts davon macht die Zahl falsch. Es macht sie zu einer Decode-Zahl, und sie sollte mit anderen Decode-Zahlen verglichen werden statt damit, wie lange dein Agent braucht, um eine Aufgabe abzuschließen.

Das Quantisierungsrezept ist der am besten übertragbare Teil.

Die meisten Texte über Quantisierung handeln davon, wie viel Genauigkeit verloren ging. Dieser hier handelt von einer Entscheidung, die entgegen der Konvention ausfiel.

Recursive quantisierte die Ausgabeschicht – den lm_head – auf 4 Bit. Das widerspricht der üblichen Praxis, und der Grund ist spezifisch für Sparse-Modelle: Bei nur 2,5 Milliarden aktiven Parametern macht die Ausgabeschicht einen großen Anteil der Gewichte aus, die für jedes einzelne Token gelesen werden; sie bei 16 Bit zu belassen, begrenzt daher, wie schnell das Modell überhaupt laufen kann. Die Genauigkeit wiederherzustellen erforderte eine Offline-Distillationsphase, in der das quantisierte Modell auf seinen eigenen vorab gesampelten Antworten aus einem Coreset trainiert, das es selbst entdeckt hat, mit dem 16-Bit-Modell als Lehrer – ein Setup, das laut Recursive die Trainingsschritte gegenüber seiner Quantization-Aware-Training-Baseline nahezu halbierte.

Das veröffentlichte Ergebnis lautet, dass das finale NVFP4-Modell in der gesamten Benchmark-Suite um nicht mehr als 0,7 Punkte vom 16-Bit-Modell abweicht. Das ist eine Herstellerbehauptung, und zwar eine, die sich später leicht überprüfen lässt und teuer zu fälschen ist, was sie zu einer nützlichen Behauptung macht, an der man den Hersteller festhalten kann. Die praktische Konsequenz sind die oben genannten Dateigrößen: ein 22,86 GB großer Download, mit dem sich ein Modell mit 39,8 Milliarden Parametern auf einem Rechner mit 48 GB Unified Memory ausführen lässt.

Auf Apple Silicon gibt es dafür eine zweite Ebene. Recursive's Eureka Machine hat spezialisierte Kernel für Low-Bit-Projektionen, MoE-Operationen, Attention und Prompt-Verarbeitung erzeugt, einschließlich eines Metal-Megakernels, der den gesamten Decode-Forward-Pass auf M4- und M5-Chips in einem einzigen Dispatch zusammenfasst. Das Fusionieren des Decode-Passes ist die Art von Optimierung, die sich nur auszahlt, wenn man die Modellarchitektur, das Quantisierungsformat und den Kernel gemeinsam kontrolliert – was die eigentliche These dieses Releases ist, mehr als jede einzelne Benchmark-Zahl.

Wie Sie es ausführen und was jeder Weg Sie kostet

Es gibt zwei unterschiedliche Deployment-Storys, und sie sind nicht austauschbar.

• Server-GPUs – der BF16-Checkpoint wird mit einem SGLang-Serving-Kit ausgeliefert, das pro Replikat auf eine B300 oder eine H200 abzielt, einen OpenAI-kompatiblen Endpunkt auf Port 30000 mit dem Modellnamen flint bereitstellt und einen Beispielclient für Reasoning- und Tool-Aufrufe enthält. Dies ist der einzige unterstützte Weg für die Gewichte in voller Präzision; in der Modellkarte steht ausdrücklich, dass Transformers-Modellierungscode noch nicht enthalten ist.

• Lokale Maschinen — llama.cpp, Ollama, Unsloth, LM Studio, vLLM und SGLang werden allesamt als unterstützt genannt, was für ein Modell am Veröffentlichungstag ungewöhnlich breit gefächert ist und den Unterschied zwischen einem Checkpoint und einem nutzbaren Artefakt ausmacht.

• Die rec-Engine – die eigene Inferenz-Engine von Recursive, installiert unter ~/.local/bin, erfordert ein M4 Pro, M5 Pro oder M5 Max mit mindestens 48 GB Unified Memory und etwa 30 GB freiem Speicherplatz und stellt lokal eine OpenAI-kompatible API bereit. Ihr README beansprucht für ein M4 Pro mit 4-Bit-Gewichten einen Token-Durchsatz von 1,4× bis 2,6× im Vergleich zu llama.cpp, über Prompts mit 1.000 bis 252.000 Tokens bei 1.024 Ausgabe-Tokens, fünf Durchläufe pro Kontextlänge, Prefill ausgeschlossen. Sie ist ausdrücklich für den Einsatz in einer einzelnen Sitzung optimiert – führen Sie mehrere Agents gleichzeitig aus, und die Dokumentation verweist Sie woandershin.

Praktische Hinweise, die darüber entscheiden, ob eine Sitzung gut läuft: Das Kontextfenster wird zwischen Prompt und Ausgabe geteilt, bei schwierigen Problemen sollte das Ausgabebudget mindestens 32.768 Token betragen, einschließlich Reasoning, und zurückgegebener reasoning_content muss im Gesprächsverlauf erhalten bleiben, sonst verschlechtert sich die mehrstufige Tool-Nutzung. Recursives eigene Anleitung für komplexe Aufgaben besteht darin, die Arbeit in kleinere Teilaufgaben mit expliziten Anweisungen aufzuteilen – ein ehrlicher Ratschlag, der zugleich wie eine Beschreibung der Leistungsgrenze des Modells klingt.

Was wirklich unbewiesen ist

Drei Dinge, in absteigender Reihenfolge danach, wie stark sie eine Entscheidung beeinflussen sollten.

Das erste ist unabhängige Messung. Die gibt es nicht. Nicht eine niedrige Punktzahl auf einem Leaderboard, nicht eine umstrittene – es gibt noch keine Bewertung von Flint durch Dritte, und die einzigen Zahlen im Umlauf sind die des Anbieters, erzeugt mit den Harness-Entscheidungen des Anbieters und der Anpassung des Anbieters für Web-Retrieval. Die Methodik ist so weit offengelegt, dass sie sich auditieren lässt – mehr kann man am ersten Tag nicht verlangen –, aber offengelegt ist nicht verifiziert.

Zweitens stellt sich die Frage, ob ein Modell mit 2,5 Milliarden aktiven Parametern bei der langfristigen Arbeit besteht, für die Coding-Agenten eigentlich gedacht sind. Das Benchmark-Protokoll erlaubt fünf Versuche und Zeitlimits von fünf Stunden – ein großzügiger Rahmen; ein Modell, das mehrere Anläufe und eine lange Leine braucht, kann einen guten pass@1-Wert erzielen und sich im Editor trotzdem unzuverlässig anfühlen. Recursives eigener Vorbehalt, dass es mehr Anleitung braucht als größere geschlossene Modelle, deutet auf dasselbe hin.

Der dritte Punkt ist die Architektursuche selbst. Eine Konfiguration, die voraussichtlich die beste derjenigen ist, die ein automatisiertes System getestet hat, ist eine Hypothese über einen Trainingslauf, kein Ergebnis über ein fertiges Modell. Wenn die Prognose der Eureka Machine richtig war, ist dies eine Vorlage, die andere kleine Teams kopieren werden. Wenn sie ungefähr richtig war, verschiebt sich der nächste Checkpoint und das Verhältnis ändert sich.

Wo das hineinpasst, wenn dein Agent-Stack nur halb lokal ist

Der Grund, warum ein Modell wie Flint wichtig ist, liegt darin, dass es eine Position von einer Rechnung streicht – nicht alle. Lokale Inferenz übernimmt die Arbeit, die auf dem eigenen Rechner laufen kann, und leistet nichts für die Arbeit, die dort nicht laufen kann: der Long-Context-Job, der nicht hineinpasst, die Lastspitze, die ein einzelnes Notebook überfordert, die Aufgabe, für die ein größeres Modell einfach besser ist. Das führt dazu, dass die meisten Teams zwei Systeme betreiben.

OrcaRouter ist die gehostete Hälfte dieser Aufteilung, und um die Grenze klar zu ziehen: Wir hosten Flint nicht, und nichts in diesem Beitrag ist eine Werbung für einen Checkpoint, den wir hosten. Flint ist ein Download von Recursive, kein Endpunkt von uns. Was wir tun, ist, eine einzige API vor über 200 gehostete Modelle zum Listenpreis des jeweiligen Anbieters zu setzen, ohne Aufschlag, Anfragen mit einer konfigurationsbasierten Fallback-Kette über sie zu routen und automatisch ein Failover durchzuführen, wenn ein Anbieter mitten in einer Anfrage ausfällt. Wenn du vergleichen willst, was ein lokaler Flint-Lauf im Vergleich zu einem gehosteten Mixture-of-Experts-Modell ähnlicher Größe wert ist — Qwen3.6-35B-A3B und Gemma 4 26B-A4B sind beide über diesen einen Schlüssel aufrufbar —, kostet der Vergleich eine Anfrage statt einer Bereitstellung.

Die vernünftige Lesart

Flint ist ein echtes Release mit einem spezifischen und ungewöhnlichen Schwerpunkt. Recursive hat nicht das stärkste Coding-Modell ausgeliefert, das es hätte bauen können; es hat das schnellste ausgeliefert, das es in einer Größe bauen konnte, die auf einen Laptop passt, und dann einen Quantisierungs- und Kernel-Stack veröffentlicht, der dafür ausgelegt ist, diesen Vorteil im Kontakt mit 4-Bit-Gewichten zu erhalten. Die 54,9 % auf Terminal-Bench 2.1 und 89,7 % auf SWE-bench Pro v2 sind starke Zahlen für ein 40-Milliarden-Parameter-Sparse-Modell und sie sind vorerst allein die Zahlen des Anbieters.

Was es lohnenswert macht, es zu beobachten, statt es nur herunterzuladen, ist die Methode dahinter. Ein Team, das sagt, ein automatisierter Research-Loop habe die Architektur, das Quantisierungsrezept und die Kernel ausgewählt, macht eine Aussage über einen Prozess, nicht über ein Modell, und Prozesse sind auf eine Weise testbar, wie es Launch-Benchmarks nicht sind: Die nächste Version kommt entweder schneller und besser oder nicht. Flint ist der erste Datenpunkt in diesem Argument und wurde unter einer Lizenz veröffentlicht, die permissiv genug ist, dass jeder die Gewichte selbst prüfen kann.

Wenn Sie einen Apple-Silicon-Rechner mit 48 GB Unified Memory haben, kostet es Sie einen Download von 22,86 GB und einen Nachmittag, um es herauszufinden. Wenn nicht, ist die ehrliche Haltung, auf die erste unabhängige Bewertung zu warten, denn eine einen Tag alte Benchmark-Tabelle ist ein Versprechen und keine Messung.