llama.cpp, Qwen3.8-Flash-Next, Kimi K3.1 : le local se joue au token près

llama.cpp : la fusion gate/up dans le noyau MMQ

Le noyau MMQ est au cœur de la vitesse d'inférence de llama.cpp sur GPU. La pull request #29948, signée anujj, y fusionne les matmuls gate/up du FFN et la GLU, avec des lignes gate/up entrelacées : un seul passage dans le noyau plutôt que des allers-retours séparés.

Les chiffres, mesurés avec llama-bench (`-fa on`, p 16384, b/ub 2048, r 5), vont de +1,9 % à +10,7 % selon le modèle et la quantification. Le banc d'essai ne se limite pas à une machine : les tests tournent sur DGX Spark (GB10) comme sur RTX 5090, deux plateformes aux architectures très différentes.

Le panel couvre Qwen3.8-27B, Qwen3.6-27B et Llama-3.1-8B, en Q4_K_M, Q5_K_M, Q6_K, Q8_0 et IQ4_XS. Du grand public quantifié et du plus exotique. Quelques pourcents peuvent sembler modestes ; sur des générations de plusieurs milliers de tokens, ça se cumule.

Qwen3.8-Flash-Next : le SSD comme mémoire

Même subreddit, deux fils qui racontent la même débrouille. Un membre adapte l'approche de glm-flash-lite — qui faisait tourner GLM-5.3 avec une empreinte mémoire étonnamment faible — à Qwen3.8-Flash-Next, 125 milliards de paramètres. Au lieu d'épingler les 24k experts en RAM système (~48–64 Go), comme le font les setups type Strata, il déporte directement sur le SSD NVMe.

Résultat sur une RTX 4090 avec 16 Go de VRAM et 8 Go de RAM seulement : 28–33 tok/s en prose, 19–22 tok/s en code sur contexte court, et 20,8 tok/s en décodage à 100k de contexte.

Un autre fil vise le débit : Qwen3.8-Flash-Next en IQ3_S sur le moteur Basalt, avec une RTX 5080 16 Go, un Core Ultra 9 285K et 62 Go de DDR5, en 262K de contexte et KV cache int8. Sur une session de codage agentique (103 requêtes, jusqu'à 130K de contexte) : 5 011 t/s en traitement de prompt en moyenne, 5 118 en pic, 153 t/s en génération en moyenne pour 262 en pic, et 5,2 Go de RAM encore libres. Deux recettes, deux profils : l'une privilégie la RAM minimale, l'autre le débit.

32 Go de VRAM : la facture en l'espace de « 24 heures »

Pendant que le logiciel grignote, le matériel repart à la hausse. Sur r/LocalLLaMA, un utilisateur qui préparait l'achat d'un GPU 32 Go pour ses deux PC a vu les tarifs s'envoler : la B70 est passée de 1,3–1,4 K à 2 K, la R9700 de 1,7–1,8 K à 2,3 K, en l'espace de « 24 heures » selon lui.

Son plan initial : relier ses deux machines via RPC/Ethernet pour les faire tourner ensemble et additionner la VRAM. À ces niveaux de prix, la mutualisation par le réseau ne coûte rien en matériel — ce qui rend les contournements mémoire des deux fils précédents d'autant plus lisibles.

Kimi K3.1 Pro : poids ouverts le 4 novembre

Autre calendrier : Kimi K3.1 Pro. Un billet technique consacré à l'avancée d'une intelligence ouverte annonce la publication des poids le 4 novembre. Il s'agit d'une version post-entraînée de K3, ce qui devrait lui valoir un support dès le jour J sur toutes les plateformes.

Pour qui fait tourner des modèles en local, le détail compte : un support jour J signifie des quantifications et des chemins d'exécution prêts à la sortie, plutôt qu'une semaine d'attente. Les tailles de poids ne sont pas précisées.

Et maintenant ?

Le logiciel grignote des pourcents là où le matériel en réclame des milliers. Fusion de noyaux dans llama.cpp, experts déportés sur NVMe, quantification IQ3_S à 262K de contexte : trois réponses à des goulots différents, mais une même logique d'optimisation. Le prix des cartes 32 Go, lui, ne dépend d'aucun de ces patches. Ce qui tourne en local se décide autant dans une pull request que dans un panier d'achat.