Recursive Flint 40B-A2.5B : un modèle de codage conçu pour privilégier la vitesse avant tout

Le nombre qui détermine siRecursive Flint 40B-A2.5Bmérite votre espace disque n’est pas 54,9 %. C’est 2,5. Le premier modèle de codage à poids ouverts de Recursive compte 39,8 milliards de paramètres et en active environ 2,5 milliards pour chaque token qu’il écrit, et presque toutes les autres décisions de la sortie — l’agencement de l’attention, la recette de quantification, le noyau Metal personnalisé, le moteur d’inférence — découlent de ce seul ratio. Flint est sorti le21 octobre 2026sous Apache 2.0, ce qui lui donne un jour d’existence au moment de la rédaction et le place dans la fenêtre où un lancement est encore une nouvelle plutôt qu’un fait historique. Comme un tableau de référence vieux d’un jour est une promesse plutôt qu’une mesure, nous conservons séparément le bilan de production :l’AI Incident Archiveconsigne comment les affirmations des modèles et des fournisseurs ont tenu une fois qu’ils servent du trafic réel.

La version courte pour quiconque doit décider maintenant : c'est un modèle à mélange d'experts creux (sparse mixture-of-experts), conçu pour être ce qui se fait de plus rapide dans sa catégorie de poids sur un ordinateur portable ; il publie trois scores de codage agentique, tous rapportés par le fournisseur et non reproduits ; et c'est le premier modèle d'une entreprise dont la raison d'être déclarée est d'automatiser la recherche qui construit les modèles. Ces trois faits comptent, et c'est le troisième qui restera intéressant dans un an.

Ce qui a réellement été livré

Quatre dépôts, et non un seul. Le dépôt principal RecursiveSI/flint contient le checkpoint BF16, la configuration, le tokenizer, le template de chat et un kit de service SGLang, et il a été créé le 21 octobre 2026 à 14:20 UTC. Trois variantes quantifiées se trouvent à côté, toutes estampillées le même après-midi : une version int4 safetensors, un GGUF int4 et un GGUF NVFP4. Toutes les tailles ci-dessous ont été mesurées à partir des listes de fichiers propres aux dépôts plutôt que citées depuis l’annonce.

• Référence BF16 — 79,59 Go répartis sur 37 fichiers, en 15 fragments safetensors d'environ 5,37 Go chacun. C'est l'artefact de fine-tuning, et celui que vous ne voulez pas télécharger pour l'inférence.

• NVFP4 GGUF — 22,86 Go dans un seul fichier, la plus petite version complète d’inférence publiée.

• Int4 GGUF — 25,99 Go, une quantification q4_1 plus volumineuse que le fichier NVFP4, soit l'inverse de l'ordre suggéré par les noms, ce qu'il vaut la peine de savoir avant de choisir d'après le nom de fichier.

• safetensors Int4 — 22,58 Go, pour les environnements d’exécution qui préfèrent des poids fragmentés à un seul GGUF.

La licence est Apache 2.0, la fiche du modèle ajoutant la distinction selon laquelle les conditions de l’API hébergée et les pratiques en matière de données sont distinctes de la licence des poids — la séparation habituelle, énoncée clairement plutôt qu’enterrée.

L’architecture est un argument sur la bande passante mémoire

Sur un ordinateur portable, décoder un token n’est pas principalement un problème de calcul. C’est un problème de déplacement des poids depuis la mémoire vers les unités arithmétiques assez rapidement, ce qui explique pourquoi un modèle dense de 40 milliards de paramètres est lent, quelle que soit la qualité de la puce : chaque token lit chaque poids. La réponse de Flint consiste à n’en lire presque aucun.

• Parcimonie — 256 experts routés par couche MoE, avec 6 sélectionnés par token, plus un expert partagé toujours actif. Sur 49 couches, 2 sont denses et 47 sont MoE, donc toutes sauf les deux premières effectuent un travail conditionnel.

• Paramètres actifs — 39,8 B au total, environ 2,5 B actifs par jeton en comptant la tête de sortie, d’où provient la désignation « 40B-A2.5B ». Le corps actif seul représente environ 2,2 B.

Attention — 35 couches à fenêtre glissante avec une fenêtre de 513 jetons (le jeton courant plus 512 précédents), entrelacées avec 14 couches d’attention complète. Seulement 32 têtes de requête et 4 têtes clé-valeur, avec une dimension de tête de 128, afin que le cache KV reste suffisamment petit pour rendre pratiques les longues sessions d’agent.

• Encodage positionnel — des embeddings rotatifs sur les couches à fenêtre glissante et aucun du tout sur les couches d’attention complète, un choix que la fiche modèle énonce sans l’expliquer. Le RMSNorm QK par tête et les sinks d’attention appris par tête assurent le travail de stabilité que l’encodage positionnel partage normalement.

• Contexte — 262 144 jetons documentés, et la fiche du modèle précise explicitement que cela couvre ensemble le prompt et la sortie générée. L’annonce affiche « jusqu’à 512k », puis recommande de rester sous 256k pour le codage. Les deux affirmations proviennent du même fournisseur, à un paragraphe d’intervalle.

Le détail intéressant, c’est la manière dont la forme a été choisie. Recursive indique que son Eureka Machine — une boucle de recherche automatisée qui propose des idées, les implémente, les teste et combine ce qui fonctionne — est partie d’une base de référence de 35 milliards de paramètres avec 3 milliards actifs et a exploré diverses configurations d’experts et largeurs. La configuration 40B/2.5B qui en a résulté était, selon la formulation même de l’annonce, « projetée pour offrir la meilleure combinaison de vitesse et de performances de codage parmi les configurations testées par notre Eureka Machine ». Projetée, et non prouvée par un comparatif de modèles finalisés. C’est une façon normale de choisir une architecture lorsque les sessions d’entraînement coûtent cher, et c’est aussi une affirmation qu’un checkpoint ultérieur pourrait discrètement contredire.

Les trois scores, et les notes de bas de page qui les accompagnent

Flint obtient 54,9 % sur Terminal-Bench 2.1, 89,7 % sur SWE-bench Pro v2 et 74,2 % sur SWE-bench Verified. Ces chiffres figurent dans la fiche modèle en tant qu’évaluations de lancement, et aucun tiers n’a publié de mesure de ce modèle — l’indice de modèles d’Artificial Analysis, l’arbitre indépendant habituel pour un lancement de ce type, ne comporte aucune entrée Flint au 22 octobre. Tout ce qui suit est donc Recursive qui évalue Recursive.

Ce que le fournisseur révèle effectivement au sujet de sa propre méthodologie dépasse ce que la plupart des articles de lancement divulguent spontanément, et cela change la manière dont les chiffres doivent être lus :

• Terminal-Bench 2.1 — exécuté avec le harnais Terminus 2, avec l'accès à Internet activé, et les solutions obtenues par recherche web comptabilisées comme des échecs. Ce dernier ajustement est un handicap délibéré, et la fiche du modèle précise que les scores publiés par d'autres développeurs peuvent ne pas l'appliquer, ce qui rend une comparaison à périmètre égal avec les chiffres de tiers plus difficile plutôt que plus facile.

• SWE-bench Pro v2 et SWE-bench Verified — exécutés avec mini-swe-agent et sans aucun accès à Internet, une configuration plus difficile que celle d’agents pouvant consulter la documentation en cours de tâche.

• Tentatives et délais d’expiration — pass@1 moyen sur au moins cinq tentatives, avec des délais d’expiration de l’agent allant jusqu’à cinq heures. Une moyenne sur cinq tentatives est un protocole raisonnable ; des délais d’expiration de cinq heures signifient qu’il s’agit de scores pour un agent que vous êtes prêt à laisser tourner, et non pour une autocomplétion.

• Échantillonnage — température 1,0, top-p 0,95, top-k 20 pour chaque évaluation, et le kit de service applique ces valeurs par défaut lorsqu’une requête les omet.

Le tableau comparatif d'un fournisseur est aussi un propos sur les pairs qu'il a choisis. Le graphique de Recursive compare Flint à Qwen 3.5, Qwen 3.6, Qwen 3.8, Laguna XS 21, Muse Glimmer et Gemma 4 — des modèles locaux adaptés à un matériel similaire, ce qui constitue le groupe de pairs honnête pour un modèle destiné à un ordinateur portable, mais aussi un groupe sélectionné pour faire paraître l'argument de la parcimonie sous son meilleur jour. L'affirmation avancée est étroite et défendable : Flint devance les modèles MoE de moins de 50 milliards de paramètres au total sur le codage agentique, et rivalise avec des modèles denses de 25 à 40 milliards tout en tournant bien plus vite. Elle ne porte pas sur les modèles de codage de pointe, et Recursive n'en formule pas — l'annonce dit clairement que Flint « peut nécessiter davantage de guidage que les grands modèles de codage à code source fermé auxquels vous êtes habitués ».

Vitesse : par rapport à quoi le 2× est réellement mesuré

Recursive rapporte plus de 125 tokens par seconde sur un MacBook Pro M4 Pro et plus de 150 tokens par seconde sur un NVIDIA RTX Spark de 64 Go sur des contextes courts, en décrivant cela comme jusqu’à deux fois plus rapide que des modèles comparables et plus de cinq fois plus rapide que des modèles denses de 25 à 40 milliards de paramètres ayant des scores de codage similaires. La note méthodologique sous le graphique de vitesse est la partie qui vaut la peine d’être lue : nombre moyen de tokens par seconde sur toute une session de 128 000 tokens, préremplissage exclu, un concurrent ayant été mesuré à 124 k plutôt qu’à la longueur totale.

L’exclusion du prefill est une pratique standard pour le benchmarking du decode, et elle compte encore ici, car c’est précisément dans le prefill qu’un agent de codage passe son temps lorsqu’il déverse un dépôt dans la fenêtre de contexte. Une mesure qui ne couvre que la moitié decode d’une session de 128k flattera tout modèle à activation éparse, et toute la conception de Flint repose sur l’activation éparse. Rien de tout cela ne rend le chiffre faux. Cela en fait un chiffre de decode, et il devrait être comparé à d’autres chiffres de decode plutôt qu’au temps que met votre agent à terminer une tâche.

La recette de quantification est la partie la plus transférable

La plupart des articles sur la quantification portent sur la quantité de précision perdue. Celui-ci porte sur une décision qui va à rebours de la convention.

Recursive a quantifié la couche de sortie — le lm_head — en 4 bits. Cela va à l’encontre des pratiques courantes, et la raison est propre aux modèles clairsemés : avec seulement 2,5 milliards de paramètres actifs, la couche de sortie représente une part importante des poids lus pour chaque token, donc la laisser en 16 bits plafonne la vitesse maximale que le modèle peut atteindre. Récupérer la précision a nécessité une étape de distillation hors ligne dans laquelle le modèle quantifié s’entraîne sur ses propres réponses pré-échantillonnées issues d’un coreset qu’il a lui-même découvert, avec le modèle 16 bits comme enseignant — une configuration qui, selon Recursive, a presque réduit de moitié les étapes d’entraînement par rapport à sa référence d’entraînement conscient de la quantification.

Le résultat publié est que le modèle NVFP4 final obtient un score à moins de 0,7 point du modèle 16 bits sur l’ensemble des benchmarks. Il s’agit d’une affirmation du fournisseur, et c’est le genre d’affirmation qu’il est facile de vérifier plus tard et coûteux de falsifier, ce qui en fait une affirmation utile à laquelle il est bon de le tenir. La conséquence pratique, ce sont les tailles de fichier indiquées ci-dessus : un téléchargement de 22,86 Go qui fait tourner un modèle de 39,8 milliards de paramètres sur une machine dotée de 48 Go de mémoire unifiée.

Sur Apple Silicon, il y a un second niveau. L’Eureka Machine de Recursive a produit des noyaux spécialisés pour les projections à faible nombre de bits, les opérations MoE, l’attention et le traitement des prompts, y compris un mégakernel Metal qui fusionne toute la passe avant de décodage en un seul dispatch sur les puces M4 et M5. La fusion de la passe de décodage est le type d’optimisation qui ne porte ses fruits que lorsque l’on maîtrise ensemble l’architecture du modèle, le format de quantification et le noyau — ce qui constitue la véritable thèse de cette version, davantage que n’importe quel chiffre de benchmark pris isolément.

Comment vous l’exécutez, et ce que chaque chemin vous coûte

Il existe deux scénarios de déploiement distincts, et ils ne sont pas interchangeables.

• GPU serveur — le checkpoint BF16 est fourni avec un kit de service SGLang qui cible un B300 ou un H200 par réplique, expose un point de terminaison compatible OpenAI sur le port 30000 avec le nom de modèle flint, et inclut un exemple de client pour le raisonnement et les appels d’outils. C’est la seule voie prise en charge pour les poids en pleine précision ; la fiche du modèle indique clairement que le code de modélisation Transformers n’est pas encore inclus.

• Machines locales — llama.cpp, Ollama, Unsloth, LM Studio, vLLM et SGLang sont tous annoncés comme pris en charge, ce qui est inhabituellement large pour un modèle disponible dès son lancement et fait la différence entre un checkpoint et un artefact utilisable.

• Le rec moteur — le moteur d’inférence propre à Recursive, installé dans ~/.local/bin, nécessite un M4 Pro, M5 Pro ou M5 Max avec au moins 48 Go de mémoire unifiée et environ 30 Go d’espace disque libre, et expose localement une API compatible OpenAI. Son README revendique un débit de tokens de 1,4× à 2,6× celui de llama.cpp sur un M4 Pro avec des poids 4 bits, pour des prompts de 1 000 à 252 000 tokens avec 1 024 tokens de sortie, cinq exécutions par longueur de contexte, préremplissage exclu. Il est explicitement optimisé pour une utilisation en session unique — lancez plusieurs agents à la fois et la documentation vous oriente ailleurs.

Notes pratiques qui déterminent si une session se passe bien : la fenêtre de contexte est partagée entre le prompt et la sortie, les problèmes difficiles exigent un budget de sortie d’au moins 32 768 jetons, raisonnement compris, et le reasoning_content renvoyé doit être conservé dans l’historique de la conversation, faute de quoi l’utilisation d’outils sur plusieurs tours se dégrade. Les propres recommandations de Recursive pour les tâches complexes consistent à découper le travail en sous-tâches plus petites avec des instructions explicites, un conseil honnête qui se lit aussi comme une description du plafond du modèle.

Qu’est-ce qui est véritablement non prouvé ?

Trois choses, par ordre décroissant de l’influence qu’elles devraient avoir sur une décision.

La première est la mesure indépendante. Il n’y en a aucune. Pas une note faible dans un classement, ni même une note contestée — aucune évaluation de Flint par un tiers n’existe encore, et les seuls chiffres en circulation sont ceux du fournisseur, produits avec les choix de banc d’essai du fournisseur et l’ajustement du fournisseur pour la récupération web. La méthodologie est divulguée suffisamment pour être auditée, ce qui est le maximum qu’on puisse demander dès le premier jour, mais divulguée ne signifie pas vérifiée.

Le second point est de savoir si un modèle à 2,5 milliards de paramètres actifs tient la route sur le travail à long horizon auquel les agents de codage sont réellement destinés. Le protocole d’évaluation autorise cinq tentatives et des délais d’expiration de cinq heures, ce qui constitue une enveloppe généreuse ; un modèle qui a besoin de plusieurs essais et d’une longue laisse peut afficher un bon pass@1 tout en semblant peu fiable dans un éditeur. La réserve de Recursive lui-même sur le fait d’avoir besoin de plus de guidage que les modèles fermés plus grands va dans le même sens.

Le troisième point est la recherche d’architecture elle-même. Une configuration estimée comme la meilleure parmi celles testées par un système automatisé est une hypothèse sur une session d’entraînement, pas un résultat concernant un modèle finalisé. Si la projection de l’Eureka Machine était juste, il s’agit d’un gabarit que d’autres petites équipes copieront. Si elle était approximativement juste, le prochain point de contrôle se déplace et le ratio change.

Où cela s'inscrit si votre stack d'agents n'est qu'à moitié local

Si un modèle comme Flint compte, c’est parce qu’il supprime une ligne d’une facture, pas toutes. L’inférence locale prend en charge le travail que vous pouvez exécuter sur votre propre machine et ne fait rien pour le travail que vous ne pouvez pas — la tâche à long contexte qui ne tient pas, le pic de charge qui dépasse les capacités d’un seul ordinateur portable, la tâche pour laquelle un modèle plus grand est tout simplement meilleur. La plupart des équipes se retrouvent donc à faire tourner deux systèmes.

OrcaRouter est la moitié hébergée de ce dispositif, et pour être clair sur la frontière : nous ne servons pas Flint, et rien dans cet article n'est un argumentaire pour un checkpoint que nous hébergerions. Flint est un téléchargement depuis Recursive, pas un point de terminaison de notre service. Ce que nous faisons, c'est placer une seule API devant plus de 200 modèles hébergés au prix catalogue du fournisseur, sans marge ajoutée, router entre eux avec une chaîne de repli basée sur la configuration, et basculer automatiquement en cas de défaillance lorsqu'un fournisseur défaille en cours de requête. Si vous voulez comparer ce que vaut une exécution locale de Flint face à un modèle hébergé de type mélange d'experts de taille similaire — Qwen3.6-35B-A3B et Gemma 4 26B-A4B sont tous deux appelables via cette même clé —, la comparaison coûte une requête plutôt qu'un déploiement.

La lecture raisonnable

Flint est une véritable version publiée, avec un centre de gravité précis et inhabituel. Recursive n’a pas livré le modèle de codage le plus puissant qu’il aurait pu produire ; il a livré le plus rapide qu’il pouvait construire dans une taille tenant sur un ordinateur portable, puis a publié une pile de quantification et de kernels conçue pour que cet avantage survive au contact de poids en 4 bits. Les 54,9 % sur Terminal-Bench 2.1 et 89,7 % sur SWE-bench Pro v2 sont de bons chiffres pour un modèle épars de 40 milliards de paramètres et, pour l’instant, ils ne sont que les chiffres du fournisseur.

Ce qui le rend digne d’être suivi plutôt que simplement téléchargé, c’est la méthode qui le sous-tend. Une équipe qui affirme qu’une boucle de recherche automatisée a choisi l’architecture, la recette de quantification et les noyaux avance une affirmation sur un processus, pas sur un modèle, et les processus sont testables d’une manière que les benchmarks de lancement ne sont pas : la version suivante arrive soit plus vite et meilleure, soit pas. Flint est le premier point de données de cet argument, publié sous une licence suffisamment permissive pour que chacun puisse vérifier les poids par lui-même.

Si vous disposez de 48 Go de mémoire unifiée et d’une machine Apple Silicon, le coût pour en avoir le cœur net est un téléchargement de 22,86 Go et un après-midi. Si ce n’est pas le cas, la position honnête est d’attendre la première évaluation indépendante, car un tableau de benchmarks vieux d’un jour est une promesse et non une mesure.