llama.cpp, Qwen3.8-Flash-Next et DeepSeek-V4.1 : le local avance

llama.cpp : la chasse aux pourcents se joue dans le kernel

Une pull request signée anujj propose de fusionner les matmuls FFN gate/up et la GLU directement au sein du kernel MMQ du backend CUDA de llama.cpp, avec des lignes gate/up entrelacées. L'idée n'est pas de changer de moteur ni de quantification, mais de réduire le travail entre les étapes d'un même calcul.

Les mesures de l'auteur, réalisées via llama-bench avec cache K et V en f16, donnent de +4,6 % à +10,7 % de tokens par seconde sur un DGX Spark (GB10) selon le modèle et la quantification, et de +1,9 % à +4,1 % sur une RTX 5090. Ce sont des chiffres d'auteur, pas un benchmark indépendant, et la fourchette haute dépend visiblement du couple modèle/quantification.

Reste que l'ordre de grandeur est typique de ce qui fait progresser l'inférence locale : pas une rupture, mais des pourcents gagnés kernel par kernel, qui se cumulent au fil des PR.

Qwen3.8-Flash-Next : 125B, 16 Go de VRAM, deux stratégies

Deux posts de la même semaine abordent le même modèle, Qwen3.8-Flash-Next (125B de paramètres), avec des approches qui n'ont rien à voir.

La première, baptisée LeanQwenFlash, adapte l'approche de glm-flash-lite — qui faisait tourner GLM-5.3 avec une empreinte mémoire étonnamment faible — au modèle de Qwen. Plutôt que d'épingler les 24k experts en RAM système (~48–64 Go) comme le font des setups type Strata, le montage déporte directement sur le SSD NVMe. Résultat sur une RTX 4090 avec 16 Go de VRAM et seulement 8 Go de RAM alloués : 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.

La seconde part d'une RTX 5080 16 Go, d'un Core Ultra 9 285K et de 62 Go de DDR5. En quantification IQ3_S sur le moteur Basalt, avec un KV cache int8 et 262K de contexte, une session de codage agentique (103 requêtes, jusqu'à 130K de contexte) atteint 5 011 t/s en moyenne sur le traitement de prompt (5 118 en pic) et 153 t/s en génération (262 en pic), avec 5,2 Go de RAM encore libres. Deux métriques, deux machines, deux usages : les chiffres ne se comparent pas directement.

DeepSeek-V4.1 Flash : 763 milliards dans la file d'attente

Côté llama.cpp toujours, une pull request d'am17an (#31086) porte sur l'ajout du modèle DSV4.1 Flash au moteur d'inférence de ggml-org. Le modèle est publié par deepseek-ai sur Hugging Face sous le nom DeepSeek-V4.1-Flash, accompagné d'un rapport technique en PDF.

Le billet paru sur r/LocalLLaMA signale une taille de 763 milliards de paramètres et l'intérêt de la communauté locale pour son exécution via llama.cpp. À ce gabarit, la question n'est pas de savoir si le modèle tient sur une carte grand public, mais quel type de découpage et de quantification le support du moteur rendra possible.

Kimi K3.1 Pro : poids ouverts annoncés pour le 4 novembre

Un billet technique consacré à l'avancée d'une intelligence ouverte détaille Kimi K3.1 Pro. Les poids du modèle seront publiés 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 — l'information est présentée comme une anticipation, pas comme un fait acquis.

Le calendrier a son importance pour ceux qui font tourner des modèles en local : entre la publication des poids et les PR d'implémentation dans les moteurs, l'écart se compte souvent en jours ou en semaines. C'est précisément ce délai que les dépêches de cette semaine donnent à observer, entre DeepSeek-V4.1 Flash et Kimi K3.1 Pro.

Et maintenant ?

Ce qui ressort de ces cinq dépêches, ce n'est ni un modèle vedette ni une annonce spectaculaire, mais le travail de plomberie qui rend l'inférence locale utilisable : un kernel MMQ retouché pour quelques pourcents, un offload NVMe qui contourne les 48–64 Go de RAM système habituellement nécessaires aux experts, un KV cache int8 pour tenir du contexte long. Les poids de Kimi K3.1 Pro et le support de DeepSeek-V4.1 Flash dans llama.cpp avancent en parallèle, sans qu'on puisse dire lequel tirera l'autre. Les chiffres cités restent, pour l'essentiel, des mesures d'auteurs sur leurs propres machines.