200K de contexte sur une 4070 Ti Super : comment le même fichier Qwen 27B a décodé 4x plus vite avec le streaming KV adaptatif

Une fenêtre de contexte plus grande punit généralement le matériel local, mais ce test affirme qu'un changement de moteur inverse ce compromis : le même fichier Qwen 3.8 27B IQ4XS a atteint un contexte configuré de 200 000 tokens sur une machine Ryzen 7 avec RTX 4070 Ti Super, tout en restant réactif. La chaîne à l'origine de ce test est Token Race, et la configuration cible les documents longs, les dépôts de code et les sessions d'agents plutôt qu'une courte conversation. L'affirmation centrale est que la conception de la gestion du contexte, et non la mémoire vidéo brute, détermine si cette fenêtre reste productive.

Le tableau des scores est sans ambiguïté pour les deux tailles. À 100 000 tokens, le streaming KV adaptatif a produit en moyenne 34,53 tokens générés par seconde contre 12,58 pour le llama.cpp d'origine, soit un avantage moyen de 2,83x sur prompts identiques. À 200 000 tokens, l'adaptatif a tenu 33,68 contre 8,04 pour l'original, soit un avantage de 4,24x. L'auteur précise que la configuration adaptative a remporté toutes les comparaisons sur prompts identiques aux deux tailles : le titre repose donc sur la matrice complète de 11 prompts et non sur une entrée favorable.

Le tout est présenté comme un résultat de moteur d'inférence plutôt qu'une revue d'intelligence, et les contrôles soutiennent ce cadrage. Chaque exécution a utilisé le même fichier de modèle IQ4XS avec des paramètres de contexte identiques, un seul slot parallèle, le flash attention, un cache de clés Q8_0 avec un cache de valeurs Q4_0, des tailles de batch et de micro-batch identiques, et aucun offload de projecteur multimodal. Chacun des 11 prompts a généré 256 tokens par complétion, ce qui maintient la comparaison sur le comportement de décodage dans des conditions de service identiques.

Le détail à 100 000 tokens montre que l'écart n'est pas un artefact des prompts courts. Les entrées courtes se regroupaient autour de 36 à 37 tokens par seconde en adaptatif contre environ 14 en version d'origine. À environ 17 000 tokens d'entrée, le duo affichait 33,55 contre 11,17, et à environ 25 000 entrées, 32,44 contre 10,28. L'entrée de 77 000 tokens a ralenti les deux moteurs comme prévu, mais l'adaptatif a quand même produit 20,09 contre 5,06, ce qui compte car la charge reportée en avant est le cas réaliste du long contexte.

Le graphique à 200 000 tokens transforme l'histoire de moteur en histoire de capacité. Six entrées de moins de 1 000 tokens ont donné en moyenne 36,77 pour l'adaptatif contre 9,06 pour l'original ; deux entrées entre 1 000 et 10 000 ont donné 36,45 contre 8,83 ; deux entrées entre 10 000 et 50 000 ont atteint 31,42 contre 6,68. La preuve, c'est le prompt de 77 418 tokens : 14,09 tokens par seconde en adaptatif contre 3,07 en original, soit un avantage de 4,59x précisément sur le type de long document ou de base de code qui casse les configurations locales naïves.

Les instantanés mémoire sont restés proches alors que le placement du calcul divergeait, et c'est le détail le plus révélateur. L'adaptatif signalait 14 606 Mo à 100 000 de contexte et 14 510 Mo à 200 000 ; l'original signalait 13 774 Mo et 14 008 Mo. La différence visible portait sur le placement du calcul : les exécutions adaptatives gardaient l'intégralité de leur pile de 66 couches sur la carte dans les deux configurations, tandis que les exécutions d'origine descendaient à 54 couches puis à 43. Ce schéma confirme la conception revendiquée du fork : déplacer la pression du grand contexte hors de la résidence GPU permanente plutôt que d'accaparer toujours plus de mémoire vidéo.

Le mécanisme comporte trois parties : les tenseurs de clés et de valeurs faisant autorité résident dans la RAM système épinglée, le GPU conserve un pool borné de pages résidentes plus un anneau de transfert, et le moteur repartitionne ce pool à mesure que le contexte grandit. Pendant le décodage, il précharge les couches suivantes pendant que la couche courante calcule encore, si bien que la couche suivante trouve sa page prête. En termes simples, le GPU reste sur le calcul du modèle pendant que la RAM système porte le contexte croissant et que l'ensemble de travail transite par la mémoire vidéo.

Les commandes correspondent à cette conception adossée à la mémoire : le poids d'embedding des tokens se trouve sur le CPU, avec une scène de streaming de 1024 Mo à 100 000 de contexte et de 512 Mo à 200 000. Les exécutions d'origine laissaient le placement au remplissage automatique et abandonnaient des couches GPU à mesure que le contexte configuré grandissait. La documentation du fork décrit la même approche autrement : streaming CUDA page par page des clés et valeurs en cache, avec le partage résident-plus-transfert rééquilibré à la volée et des lots de transfert ajustés à chaque machine. La mise en garde honnête boucle la boucle : le grand contexte n'est pas gratuit, les transferts font toujours un vrai travail, et les valeurs de 1024 et 512 Mo sont des points de départ à revalider par machine.