Flint, un modèle de code entraîné de zéro, fait tourner sa boucle d'agent sur une seule RTX 4090

Modèle et fichiers

• RecursiveSI/flint : FlintForCausalLM, 39.8B au total, environ 2.5B actifs par token en comptant la tête de sortie (environ 2.2B pour le corps seul). 49 couches : 2 denses (mlp_only_layers [0,1]) et 47 MoE avec 256 experts routés, 6 par token, plus un expert partagé (shared_expert_intermediate_size 1024). 35 couches à fenêtre glissante (fenêtre de 513) et 14 couches à attention complète. 32 têtes de requête, 4 têtes KV, head_dim 128, hidden 2048, vocabulaire de 150 144, max_position_embeddings 262 144. Routeur sigmoïde, RMSNorm QK par tête, attention sinks appris par tête (softmax_type "learnable"), RoPE uniquement sur les couches à fenêtre glissante. Entraîné de zéro en passant par le préentraînement, le mid-training, le SFT et le RL. Connaissances jusqu'à juin 2026. Nombre de tokens d'entraînement non indiqué. Code de modélisation Transformers pas encore inclus. Checkpoint BF16 d'environ 80 GB.
• Évaluations de l'éditeur (déclarées par lui, non vérifiées par nous) : Terminal-Bench 2.1 54,9 % (Terminus 2), SWE-bench Verified 74,2 % et SWE-bench Pro v2 89,7 % (mini-swe-agent). Pass@1 moyen sur au moins cinq tentatives, température 1,0, top-p 0,95, top-k 20. Les solutions de Terminal-Bench récupérées sur le web sont comptées comme des échecs. Les scores des concurrents ne figurent que dans une image de graphique, donc nous ne les avons pas extraits.
• flint-nvfp4-gguf : flint-nvfp4.gguf, 22 863 084 160 octets, poids, tokenizer et chat template dans un seul fichier, pour llama.cpp sur CUDA. Les auteurs listent B300, RTX PRO 6000 Blackwell, RTX Spark et DGX Spark comme testés, et recommandent au moins 48 GB de mémoire GPU (ou de mémoire unifiée sur Spark). Leur commande d'exemple utilise -c 262144 ; nous sommes restés en dessous de cette recommandation. llama-bench le rapporte comme 21.29 GiB, 39.79 B params.
• flint-int4-gguf : flint-int4-q4_1.gguf, 25 992 966 976 octets, Q4_1, pensé pour Apple Silicon avec Metal et 48 GB de mémoire unifiée. Nous ne l'avons fait tourner que dans llama-bench, sur la machine lente.
• flint-int4 : MLX INT4 (affine par groupes de 64, embeddings INT8), environ 22,6 GB, pour mlx-lm.
• Kit SGLang (sglang/ dans le dépôt principal, SGLang 0.5.16) : un GPU avec au moins 141 GB par réplique (B300, B200 ou H200), "80 GB GPUs are not supported", pilote 580 ou plus récent. Les scripts de service utilisent --context-length 262144 --tool-call-parser flint --reasoning-parser flint. Poids et KV quantifiés, TP/EP et décodage spéculatif non validés par les auteurs.
• recursive-oss/rec : moteur Apache-2.0 pour Flint sur Apple Silicon (M4 Pro, M5 Pro, M5 Max, 48 GB ou plus), API compatible OpenAI, annonce un décodage 1,4 à 2,6 fois plus rapide que llama.cpp sur M4 Pro (leur chiffre).

Support dans llama.cpp

• PR #30928 "models: Add Flint model (FlintForCausalLM)" par alexey-rsi, fusionnée le 2026-10-21T21:26:22Z, commit de fusion a37cc46104eb50900d5ab4a9ba02a0abdac039db, +319/-7 dans 18 fichiers, approuvée par CISC et ggerganov. Elle utilise la mise à l'échelle adaptative de l'activation des experts de #30861 comme contournement, et la PR signale un ralentissement de 10 à 30 % dû à cette mise à l'échelle automatique, à traiter dans des PR ultérieures (non mesuré par nous). La PR indique que Codex a largement aidé à l'implémentation.
• PR #30929 "jinja: support hexadecimal string escapes" (alexey-rsi, fusionnée le 2026-10-21T16:04:37Z, approuvée par CISC et danbev) est nécessaire au chat template.
• La release b11803 (publiée le 2026-10-21T22:30:59Z) est identique à a37cc461. b11804 et les suivantes la contiennent aussi. v0.7.0 a 134 commits de retard.

Notre configuration

• Cartes sur notre cloud : RTX 5090 32 GB (pilote 595.91.07, 575 W), RTX 4090 24 GB (23 028 MiB utilisables, pilote 595.91.07, 450 W), et une première RTX 5090 (pilote 580.178.04, limite de puissance à 400 W) qui s'est révélée être une machine lente.
• Un manager InferenceKey local depuis main à 5c08ab03, joint par les workers via des tunnels de développement. Production jamais touchée.
• Env du worker : INFERENCEKEY_LLAMACPP_TAG=flint-a37cc461, INFERENCEKEY_LLAMACPP_READY_TIMEOUT_SECS=3000, CMAKE_BUILD_PARALLEL_LEVEL, CUDACXX.
• llama.cpp compilé à la main à a37cc461 dans le chemin d'installation du worker /opt/inferencekey/llamacpp-cuda/flint-a37cc461-cuda<arch>/. Le worker y a trouvé build/bin/llama-server et l'a réutilisé. Son tag par défaut est b9748, et il clone avec git clone --branch <tag>, qui accepte un nom de tag ou de branche, pas un commit.

Déploiement pas à pas

1. Clonez le SDK et ouvrez examples/flint-coding-agent-llamacpp-private-nvidia (main.py, README.md, .env.example, requirements.txt, commit 1654d272).

2. Copiez .env.example vers .env, remplissez-le et exportez les variables dans votre shell (main.py les lit dans l'environnement et ne charge pas .env lui-même) :

   INFERENCEKEY_SDK_TOKEN=...
   INFERENCEKEY_API_KEY=...
   INFERENCEKEY_PROJECT=...
   IK_WORKER_ID=...            # private NVIDIA worker, 32 GB or more for the 64K default
   # optional
   INFERENCEKEY_BASE_URL=...
   IK_KEEP_ALIVE=1             # keep the deployment after the run
   

3. Sur le worker, configurez une version de llama.cpp qui contient Flint, et laissez du temps à la première compilation :

   INFERENCEKEY_LLAMACPP_TAG=b11803          # or newer; we used a hand build at a37cc461
   INFERENCEKEY_LLAMACPP_READY_TIMEOUT_SECS=3000
   CMAKE_BUILD_PARALLEL_LEVEL=<cores>
   # Blackwell needs the CUDA toolkit with nvcc 12.8 or newer
   

   Le README de l'exemple demande un tag qui contient a37cc461, ou master. Sa note selon laquelle aucun tag de release ne contenait la PR au moment de notre test est dépassée : b11803 correspond au commit de fusion. Nous n'avons pas fait tourner le worker avec b11803 lui-même.

4. Installez et lancez. Le SDK n'est pas encore sur PyPI (la ligne inferencekey de requirements.txt est commentée), donc compilez-le d'abord en local, comme le décrivent le README de l'exemple et ../CONTRIBUTING.md :

   python -m venv .venv && . .venv/bin/activate
   pip install maturin
   ( cd ../../bindings/python && maturin develop --release )
   pip install -r requirements.txt
   set -a; . ./.env; set +a
   python main.py
   

   main.py appelle ensure() avec Backend.LLAMACPP, attend jusqu'à 3 600 s que le déploiement soit prêt, demande une fonction merge_intervals, lance la boucle d'agent de code avec list_files, read_file, write_file et run_tests confinés à un répertoire temporaire, écrit outputs/answers.json, et supprime le déploiement sauf si IK_KEEP_ALIVE=1.

5. La commande qu'il déploie :

   llama-server -hf RecursiveSI/flint-nvfp4-gguf --hf-file flint-nvfp4.gguf --alias flint \
     -ngl all -c 65536 -np 1 -fa on -ctk f16 -ctv f16 --jinja \
     --temp 1 --top-p 0.95 --top-k 20 --min-p 0
   

   La commande est codée en dur dans main.py (ligne 58), et aucune variable d'environnement ni aucun flag ne la modifie. Pour un worker de 24 GB, remplacez-y -c 65536 par -c 16384. Laissez --swa-full non défini, comme le dit la fiche du modèle.

Temps jusqu'à prêt

Vitesse

Le CMake de llama.cpp choisit de lui-même CMAKE_CUDA_ARCHITECTURES=120a sur Blackwell, et la build native était environ 11 % plus rapide que le JIT PTX. NVFP4 a aussi tourné sur Ada (sm_89, la 4090). Sur la 5090, une réponse de code de 374 tokens a pris 3,0 s.

Estimation du KV : 14 couches à attention complète x 4 têtes KV x 128 x 2 (K et V) x 2 octets = 28 672 octets par token, environ 0,9 GiB à 32K et 1,75 GiB à 64K.

Échelle VRAM complète

L'échec de la 4090 à 32K :

ggml_backend_cuda_buffer_type_alloc_buffer: allocating 87.50 MiB on device 0: cudaMalloc failed: out of memory
failed to allocate buffer for kv cache

Le SDK a ensuite levé failed to become ready: bootstrap step failed.

Non essayé : cartes de 12 GB, RTX 3090 (pas de stock au moment de l'essai), la 5090 au-delà de 64K, toute carte de 48 GB, le contexte complet de 262K, une concurrence supérieure à -np 1.

Qualité (nos prompts, pas un benchmark)

• Boucle d'agent de code : 7 essais sur 7 sur 3 machines ont corrigé le bug, toujours en 5 tours, de 559 à 654 tokens, sans jamais toucher aux tests.
• JSON des appels d'outils valide à chaque fois, avec des appels parallèles. Dans un banc d'outils séparé, notre read_file factice renvoyait le même texte pour chaque chemin (notre bug). Le modèle l'a remarqué ("suspiciously identical") et a continué à chercher pendant 6 tours au lieu de répondre.
• merge_intervals : correct avec trois asserts dans 5 essais.
• Un décalage d'une unité glissé exprès dans une fonction chunks : trouvé 3 fois sur 3.
• Chaîne cachée FLINT-4471-NVFP4 : trouvée 3 fois sur 3 à 8,8K et 17,5K tokens. Question annexe d'arithmétique juste 2 fois sur 3 (helper_175(2) a répondu 171, la bonne réponse est 113).

Vidéo de démo

72,9 s, 1080p, narrée, enregistrée sur la 5090 saine : le workload dans le panneau, le module bogué, la boucle d'agent (5 tours, 654 tokens, 5,9 s, 3 tests au vert). Une prise antérieure sur la 5090 lente a été remplacée.

Problèmes restants et statut

1. Version de llama.cpp. Flint a besoin de b11803 ou plus récent, et le worker prend un tag, pas un commit. Statut : résolu en amont, ouvert de notre côté (valeur par défaut du worker b9748 et README pas encore mis à jour), non testé par nous avec le tag. Le README de notre SDK demande un tag contenant a37cc461 ou master ; sa note selon laquelle aucun tag de release n'existait est dépassée, et y nommer b11803 reste à faire.
2. Machine lente. Une RTX 5090 décodait à 27 à 29 tok/s avec le même fichier et le même commit, et aussi avec Q4_1. nvidia-smi dmon montrait SM 100 %, mémoire de 0 à 6 %, 399 W pour sa limite de 400 W. Une seconde 5090 tournait 8,3 fois plus vite dans llama-bench (tg128 239,8 contre 28,8). Cause racine non isolée (la limite de puissance et le pilote 580.178 sont les différences visibles). La plateforme la signalait comme saine, et rien ne vérifie les performances du GPU au bootstrap. Statut : ouvert.
3. Mémoire utilisable de 24 GB. La 4090 expose 23 028 MiB. À 16K, llama-server utilisait 22 316 MiB ; passer de 16K à 32K a ajouté 464 MiB sur la 5090 lente (de 22 458 à 22 922), et le pilote garde de la mémoire hors du processus (une 5090 au repos affichait 1 039 MiB utilisés), donc NVFP4 avec 32K de contexte ne tient pas. Statut : une limite, utilisez 16K.
4. Timeout synchrone. Le timeout synchrone de 120 s de l'endpoint renvoie 503 pour les configurations lentes comme le déchargement des experts sur CPU. Statut : ouvert.
5. Compilation à la main. La cible llama-server échoue à llama-ui-assets si les 8 fichiers stub de l'UI n'existent pas tous (le worker les crée). Statut : n'affecte que les compilations à la main.
6. Raisonnement dans content. Avec cette build et ce template via notre endpoint, le texte de raisonnement arrive dans content et reasoning_content est absent. Les tokens de raisonnement comptent dans usage.completion_tokens et dans max_tokens (l'exemple utilise 16 384). Les configurations client de Recursive utilisent un budget de génération de 65 536 tokens et demandent de conserver reasoning_content lorsqu'on rejoue l'historique. Statut : ouvert.

Limites

Une requête à la fois, sept essais d'agent, nos propres prompts. Échantillonnage à température 1,0, top-p 0,95, top-k 20, comme le recommande Recursive. Les benchmarks sont ceux annoncés par l'éditeur. Les paliers émulés ont tourné sur la machine lente. Aucune vraie carte de 16 GB ou de 12 GB n'a été testée.

Crédits

Recursive (modèle, fichiers NVFP4 et INT4, kit SGLang, rec). alexey-rsi (PR llama.cpp #30928 et #30929). CISC et ggerganov (ont approuvé #30928). CISC et danbev (ont approuvé #30929). ggerganov (#30861, la mise à l'échelle MoE par expert qu'utilise le support de Flint). Notre part : le déploiement sur InferenceKey, l'exemple du SDK, les mesures et la vidéo.

Sources

• Fiche du modèle RecursiveSI/flint, avec son config.json et son sglang/README.md
• RecursiveSI/flint-nvfp4-gguf
• RecursiveSI/flint-int4-gguf
• RecursiveSI/flint-int4
• llama.cpp PR #30928
• llama.cpp PR #30929
• recursive-oss/rec
• Exemple du SDK InferenceKey
• Où nous l'avons repéré : fil r/LocalLLaMA