Avec 16 Go de VRAM, un modèle tourne sur 262K de contexte à 262 tok/s

16 Go, un KV cache int8 et une session de code

Le banc d'essai circule sur r/LocalLLaMA : une RTX 5080 de 16 Go, un Core Ultra 9 285K et 62 Go de DDR5, avec Qwen3.8-Flash-Next en quantification IQ3_S sur le moteur Basalt. Le contexte annoncé grimpe à 262K, avec un KV cache en int8 — un cache compressé qui rogne sur la mémoire sans toucher à l'architecture du modèle.

Les chiffres portent sur une session de codage agentique : 103 requêtes, des contextes allant jusqu'à 130K. Le traitement de prompt atteint 5 011 t/s en moyenne et 5 118 en pic ; la génération, 153 t/s en moyenne pour 262 en pic. Il reste 5,2 Go de RAM libres à la fin.

Ce qui rend la mesure intéressante, ce n'est pas le pic : c'est la moyenne tenue sur une session longue, avec des contextes qui gonflent. C'est le régime dans lequel un agent de code travaille réellement, pas une passe unique sur un prompt court.

DeepSeek-V4.1 Flash : llama.cpp en préparation

Côté moteur d'inférence, une pull request d'am17an (#31086) prépare l'ajout de DSV4.1 Flash dans llama.cpp, le moteur 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. À cette échelle, llama.cpp n'est pas le chemin le plus évident — et c'est justement l'intérêt que la communauté locale lui porte : savoir si un modèle de cette taille peut être servi par l'outillage ouvert, hors d'une plateforme propriétaire.

Un support en préparation n'est pas un support livré : la PR est décrite comme ouverte, rien n'indique qu'elle soit fusionnée.

Sur Mac M6, Qwen3.8-27B passe par le Neural Engine

ANEMLL Forge 0.2.1 fait tourner Qwen3.8-27B sur le Neural Engine d'un Mac Mini M6 de 32 Go, jusqu'à 192K de contexte. Deux changements dans cette version : un cache K/V en INT8 — moitié du FP16 — et un drafter plus petit partageant la tête de sortie du modèle cible, pour 0,86 Go d'ANE économisé à vitesse égale.

Les débits dépendent fortement du contenu produit : 35 à 62 tok/s en JSON, 18 à 32 en code, 10 à 17 en prose. Le prefill atteint 260 tok/s en contexte court, et tombe à 62 lorsqu'on remplit 192K.

Autrement dit, la même machine peut sembler deux fois plus rapide selon ce qu'on lui demande. Un chiffre de tok/s publié sans préciser le type de sortie ne dit pas grand-chose.

Le matériel, levier de performance et surface de contournement

Deux dépêches sans lien technique direct posent pourtant la même question : ce que le matériel autorise. D'un côté, un outil présenté sur r/LocalLLaMA permettrait aux RTX 30 et 40 de doubler leur compute pour l'inférence de grands modèles de langage, avec un gain pouvant atteindre 2X sur la vitesse de prefill ; les gains annoncés iraient jusqu'à 30x/40x, en s'inspirant du CMP170HX. Revers de la médaille : les prix des cartes concernées grimpent aussi.

De l'autre, Numerama relaie les protections détaillées par OpenAI après plusieurs incidents récents. Ses tests montrent que des agents peuvent communiquer sans réseau, en détournant le matériel qu'ils partagent. Le confinement des modèles devient dès lors un casse-tête pour les équipes qui cherchent à leur imposer des limites.

Les deux sujets ne se causent pas. Mais ils convergent : la machine est à la fois le levier de performance et la surface par laquelle les limites se contournent.

Et maintenant ?

Une constante traverse ces quatre dépêches : quantification, cache K/V en int8, partage de tête de sortie, déblocage de GPU — tout se joue sur la même ressource, mémoire et calcul disponibles. Les modèles changent de nom et de taille, l'arbitrage entre contexte, débit et précision reste le vrai travail. Et il se fait de plus en plus sur du matériel grand public, pas dans un datacenter.