Toutes les données de l'après-midi du 14/11. Aucune compression.

Structure : 12 sections. ~3500 mots FR. Public : LocalLLaMA + devs curieux.

Titre

Spark-X2.6-4B sous la loupe : 184 tok/s sur RTX 5080, le piège du raisonnement 131K, et du code 2,9× plus vite en multi-stream

Meta description

Benchmarks dual-GPU complets (RTX 5080 vs 4060 Ti, ratio bande passante 1:1), Flash Attention +171 %, Q8 vs Q4 sur 16 Go, le thinking budget qui peut atteindre 45 000 tokens, et la génération parallèle multi-stream qui divise le temps d'écriture de code par 3.

Introduction

Quand l'équipe SparkLLM nous a écrit pour nous remercier de notre couverture du 1024 Developer Festival, ils nous ont proposé un hands-on avec leur aide technique. Nous avons pris cette invitation au sérieux : en une après-midi, nous avons téléchargé, configuré, mesuré et disséqué Spark-X2.6-4B sur notre rig de test — et ce que nous avons découvert va bien au-delà d'un simple benchmark de débit.

Ce n'est pas un modèle comme les autres. C'est un modèle de raisonnement natif dans un format 4B, conçu pour tourner sur du matériel grand public, avec un thinking budget qui peut dépasser 45 000 tokens par problème. L'évaluer comme un modèle classique (zéro-shot, temp 0, budget 2048 tokens) donne des résultats trompeurs. Nous allons vous montrer pourquoi — et comment le faire chanter.

1. Le banc de test

Notre rig est volontairement asymétrique pour isoler les variables hardware :

Les deux cartes ont exactement 16 Go de VRAM. Le modèle 4B en Q8_0 pèse 4,07 Go — il tient entièrement dans chaque carte avec son KV cache, sans offload ni swapping. Ça nous permet de mesurer l'impact pur de la bande passante mémoire sans aucun autre facteur.

2. Duel hardware : RTX 5080 vs RTX 4060 Ti

Nous avons isolé le modèle sur chaque carte (-dev cuda0 vs -dev cuda1), en Q4_K_M, avec un contexte de 32 768 tokens et Flash Attention activé.

La loi de la bande passante : le ratio de génération (184,5 vs 77,2 t/s = 2,39×) correspond quasi parfaitement au rapport de bande passante mémoire réelle entre la RTX 5080 (~1 000 Go/s GDDR7) et la RTX 4060 Ti (288 Go/s GDDR6), lissé par le cache L2. C'est la démonstration hardware la plus propre possible : pour un petit modèle entièrement résident, le decode est gouverné à 100 % par la mémoire.

À 184,5 tokens/seconde, la RTX 5080 génère une réponse de 500 mots en moins de 3 secondes. La 4060 Ti à 77,2 t/s reste parfaitement utilisable pour un agent local quotidien.

3. Flash Attention : le switch non négociable

Nous avons mesuré l'impact de Flash Attention (-fa on vs -fa off) sur la RTX 5080 :

Sans Flash Attention, le traitement des prompts longs est 6 fois plus lent et la latence au premier token explose. Si vous déployez Spark-X2.6-4B localement, -fa on est strictement obligatoire — il n'y a aucun trade-off.

4. Q4 ou Q8 ? Le débat tranché par les chiffres

La plupart des registres communautaires (y compris Ollama par défaut) tirent le Q4_K_M pour garantir la compatibilité avec les GPU de 6 Go. Sur une carte 16 Go, c'est un compromis inutile :

Le ratio de vitesse (184,5/147,5 = 1,25×) correspond exactement au ratio de poids mémoire (4,07/3,29 = 1,24×). Le decode est purement bandwidth-bound.

Pourquoi le Q8_0 gagne sur 16 Go : même à 65 536 tokens de contexte, il n'occupe que 7 Go de VRAM — il reste plus de 9 Go libres. À 147,5 t/s, on génère plus de 8 800 mots par minute. Et la quantification en 4 bits pénalise disproportionnellement les petits modèles : dans une architecture 4B, chaque paramètre porte une densité informationnelle élevée.

5. Sensibilité des paramètres

KV Cache — gardez le f16 : quantifier le KV en q8_0 fait passer le decode de 184,5 à 173,2 t/s (−6,5 %). Pour un 4B dont le KV cache ne pèse que ~1 Go à 32K, le f16 natif est plus rapide ET mathématiquement lossless. La quantification KV n'a d'intérêt que pour les 30B+ qui manquent de VRAM.

Threads CPU — 16 sur le 9800X3D : passer de 8 à 16 threads améliore le dispatch CUDA sur petits prompts (TTFT réduit de 92 à 81 ms, prefill court à 292 t/s).

Reasoning — le paramètre qui change tout : le chat template de Spark active enable_thinking = true avec thinking_effort = high par défaut. Sur des questions complexes, le modèle déroule jusqu'à 31 000 tokens de pensée à 170 t/s avant de produire sa réponse. Avec --reasoning off, il génère immédiatement à 190,4 t/s — mais la qualité s'effondre sur les tâches algorithmiques.

6. Le piège du Thinking Budget

C'est LA découverte de cet après-midi. Spark-X2.6-4B n'est pas un modèle de chat classique — c'est un modèle de raisonnement profond qui a besoin d'espace pour penser.

#### Piège 1 : l'amputation zéro-shot

Évaluer un modèle de raisonnement natif via un harness classique (temp 0, --reasoning off, budget 2048 tokens), c'est lui couper ses jambes. Les architectures 4B de raisonnement s'appuient sur leur canal de pensée interne pour planifier la logique — le priver de ce scratchpad les réduit à de la prédiction de tokens à l'aveugle. Pour débloquer Spark-X2.6-4B : suivez les recommandations officielles (temp 1.0, top_p 0.95), ouvrez le budget de tokens généreusement, et laissez le canal de raisonnement tourner sans contrainte.

#### Piège 2 : le clamp de tokens

Les données officielles d'iFlytek montrent que le modèle produit naturellement des chaînes de pensée massives :

Quand on bride max_tokens à 16 000 (une valeur standard), le modèle épuise tout son budget dans le bloc de pensée avant d'avoir pu fermer sa balise </think> et émettre le code. Le harness rapporte « no code block » — un échec total qui est en réalité une guillotination en plein vol.

Dans nos tests non contraints, le modèle a généré 45 000 tokens de raisonnement sur un seul exercice Exercism.

#### Piège 3 : le paradoxe de l'overthinking

Les données officielles révèlent un phénomène fascinant :

En Math, plus de réflexion = mieux. Mais en Code, c'est l'inverse ! À 58 700 tokens de pensée, un modèle 4B sur-architecte : il invente des cas limites inexistants, réécrit son code trois fois, et dévie des signatures attendues. Pour le code, le mode Low (~42 000 tokens) est le sweet spot.

7. La révolution multi-stream : 2,9× plus vite pour UN développeur

C'est la découverte la plus excitante de la journée.

#### Le problème : le goulot séquentiel

Un LLM standard écrit les fichiers de manière séquentielle : token 1, puis token 2, etc. À 147 t/s, un fichier de 2 000 tokens prend 14 secondes. Pendant ce temps, les Tensor Cores du GPU dorment à 70 % : ils ont fini de calculer bien avant que la VRAM n'envoie les poids du token suivant.

Des travaux récents sur TensorFold (ashhart/TensorFold) et le serving continu ont montré qu'un GPU Blackwell peut débiter plus de 700 tokens/s en servant 4 flux simultanés sans ralentir chaque flux. Nous nous sommes posé la question que tout développeur local devrait se poser : peut-on détourner cette capacité multi-stream pour qu'un SEUL utilisateur écrive un même fichier 3 fois plus vite ?

#### La solution : le Parallel AST Chunking

Au lieu de demander au modèle d'écrire 100 lignes d'un bloc, nous avons testé un pipeline en 3 étapes :

Le contrat d'interface (0,05 s) : un prompt ultra-court génère uniquement le squelette du module (imports et signatures de classes).
L'explosion parallèle : un ThreadPoolExecutor envoie 4 streams simultanés à llama-server (-np 4), chaque stream rédigeant une classe en même temps.
L'assemblage : les 4 blocs sont concaténés dans le fichier .py final.

#### Le test réel : fast_stats_engine.py (4 classes de maths/statistiques)

Temps d'attente du développeur : divisé par 2,91×.

Détail des 4 streams sur la RTX 5080 :

ExponentialMovingAverage : terminée en 1,06 s (92,3 t/s) — 13 lignes
HistogramAccumulator : terminée en 1,62 s (99,5 t/s) — 20 lignes
StatsPipeline : terminée en 1,97 s (90,7 t/s) — 22 lignes
OnlineVariance (Welford) : terminée en 2,34 s (99,7 t/s) — 28 lignes

Le fichier final est 100 % valide (bytecode compilé), syntaxiquement propre, et le développeur a attendu 2,3 secondes au lieu de 7 secondes.

#### Pourquoi ça marche

Quand les 4 requêtes arrivent simultanément, le GPU charge les 4 Go de poids une seule fois mais les applique aux calculs des 4 utilisateurs en même temps (GEMM matrice-matrice au lieu de matrice-vecteur). Les Tensor Cores se réveillent enfin. Pour le même coût de lecture mémoire, le GPU sort 4 tokens au lieu d'un.

8. Ingénierie du contexte sur GPU 16 Go : le mythe du 1M

Spark-X2.6-4B annonce un contexte architectural de 1 048 576 tokens. Mais que peut-on réellement faire sur une carte grand public de 16 Go ?

Dans llama-server, le flag -c définit le contexte total partagé entre les slots -np. Nous avons testé physiquement les limites de la RTX 5080 en Q8_0 :

Vouloir charger 1M de contexte pour du code est un non-sens : 1M de tokens en FP16 KV pèse 43 Go. Mais sur une carte 16 Go, on peut faire tourner 2 slots de 131k tokens ou 4 slots de 65k tokens en restant 100 % en GDDR7. Avec 65k ou 131k tokens par slot, le thinking budget du modèle n'est plus jamais amputé.

9. Pourquoi Spark-X2.6 brille sur les Agents (et pas sur les tests synthétiques)

En regardant les benchmarks officiels d'iFlytek, on comprend immédiatement la vocation de ce modèle :

Spark-X2.6-4B n'est pas conçu pour résoudre des devinettes de formatage de chaînes déconnecté du monde : c'est un agent outillé pour le monde réel. Il excelle quand il a accès à des outils, un interpréteur Python, des serveurs MCP ou un navigateur.

10. La recette idéale pour faire tourner Spark-X2.6-4B chez soi

La commande llama-server optimisée (carte 16 Go) :

llama-server.exe -m Spark-X2.6-4B-Q8_0.gguf \ --host 127.0.0.1 --port 8650 \ -dev cuda0 -ngl 99 \ -c 262144 -np 4 -fa on -cb \ --batch-size 2048 --ubatch-size 512 \ --threads 16 --reasoning on

Les hyperparamètres d'inférence :

temperature : 0,7 à 1,0 — évitez impérativement temp 0 qui bloque le raisonnement
top_p : 0,95
max_tokens : donnez-lui au moins 32 000 à 65 000 tokens d'espace de sortie
En programmation pure : privilégiez le mode Low Reasoning pour éviter l'écueil de l'overthinking

Bloc llama-swap (config.yaml) :

Spark-X2.6-4B: aliases: [Spark-X2.6-4B, Spark-4B] cmd: | python run_model.py llama-server.exe -m Models/Spark-X2.6-4B-Q8_0.gguf --port ${PORT} --host 127.0.0.1 --threads 16 -np 4 -c 262144 -fa on --batch-size 2048 --ubatch-size 512 -ngl 99 -dev cuda0 --reasoning on ttl: 300

Conclusion : le petit modèle qui pense comme un grand

Spark-X2.6-4B marque un tournant dans l'écosystème open-weight. Il prouve qu'un modèle de 4 milliards de paramètres entraîné nativement pour le raisonnement peut rivaliser avec des architectures de 9B à 12B sur les tâches d'agents et d'outils. Sur une RTX 5080 grand public, il délivre 184 tok/s en solo et permet, grâce au multi-stream, de générer des modules entiers de code en 2,3 secondes.

Ce n'est pas juste un bon modèle 4B : bien configuré, c'est l'un des moteurs locaux les plus agiles, économiques et excitants que nous ayons testés cette année.

À l'équipe [SparkLLM](https://x.com/SparkLLM) / [XHToken](https://github.com/XHToken) : merci pour l'invitation. Ce fut un plaisir de découvrir la profondeur de votre travail.

Lien vers notre article initial : [Spark-X2.6-4B Release](https://chats-llm.com/en/blog/spark-x2-6-4b-release)

Modèle : [XHToken/Spark-X2.6-4B-GGUF](https://huggingface.co/XHToken/Spark-X2.6-4B-GGUF) · GitHub : [github.com/XHToken](https://github.com/XHToken) · X : [@SparkLLM](https://x.com/SparkLLM)

Remerciements à la communauté LocalLLaMA et à l'écosystème llama.cpp.