Qwen local s’arrête avant la fenêtre prévue : isoler le KV cache, le backend et les GPU

Vous avez réglé un Qwen local sur 128K de contexte, mais il peut échouer vers 72K, devenir beaucoup trop lent ou terminer sa réponse en oubliant des consignes placées au début. Il existe rarement un réglage magique : quantification des poids, KV cache, backend d’inférence et placement matériel déterminent ensemble la limite réelle.

Ce guide propose un diagnostic reproductible. Vous séparerez d’abord capacité, vitesse et mémoire effective, puis vous ne changerez qu’une variable à la fois pour choisir entre un autre KV cache, un autre backend, un rééquilibrage multi-GPU ou une cible de contexte plus basse.

Réponse directe : la fenêtre configurée est un plafond, pas une garantie

Choisir 128K demande seulement au backend de préparer une entrée de cette taille. La configuration reste viable tant que ce budget tient :

poids du modèle + KV cache + espace de travail du runtime + marge de sécurité ≤ mémoire réellement utilisable par le backend

Les poids occupent généralement une grande part presque fixe au chargement. Le KV cache grandit avec le nombre de tokens conservés, tandis que les buffers temporaires varient selon le backend, le batch et les kernels. Même si l’allocation réussit, la latence ou le rappel d’informations lointaines peuvent devenir inacceptables avant la limite physique.

Vous devez donc répondre à trois questions différentes : est-ce que cela tient, est-ce que cela finit assez vite et le modèle utilise-t-il encore le début du contexte ? La valeur maximale affichée dans une interface ne suffit pas.

Identifiez le symptôme avant de remplacer toute la pile

« Ne pas atteindre 128K » peut désigner plusieurs pannes. Classez d’abord votre cas pour ne pas optimiser le mauvais composant.

Symptôme	Piste la plus probable	Première vérification
OOM au chargement ou à la réservation d’un long contexte	Les poids et le KV cache se disputent la mémoire, ou un GPU ne peut pas réserver sa part	Relevez le pic et la mémoire libre de chaque GPU
Le backend échoue presque toujours au même nombre de tokens	Format du cache, implémentation du backend ou limite d’allocation	Gardez modèle et matériel ; changez uniquement cache ou backend
L’entrée est acceptée, mais le prefill ou la génération deviennent inutilisables	Bande passante, trafic entre GPU, kernels ou longueur excessive	Mesurez séparément le traitement du prompt et la génération
La réponse se termine, mais oublie les contraintes du début	Qualité du contexte effectif plutôt que capacité brute	Placez des faits de contrôle tout au long du prompt
Le même essai passe parfois et échoue parfois	Marge insuffisante, charge concurrente ou runtime instable	Supprimez les autres charges et répétez trois fois

Si tout tient mais devient trop lent, réduire le KV cache n’est pas forcément la meilleure réponse. Si tout tient mais que le début est oublié, ajouter de la VRAM ne garantit pas non plus une amélioration.

Ce qu’un passage rapporté de 72K à 128K prouve — et ne prouve pas

Dans un retour de configuration daté du 23 septembre 2026, Nigel Hungerford-Symes décrit Qwen3.8-27B (Unsloth UD-Q5_K_M) sur une RTX 5060 Ti 16GB et une RTX 3070 8GB. La pile 128K indiquée utilise beellama.cpp + kvarn5 KV + MTP n=2, avec environ 36 tok/s en contexte court et 18 tok/s à 126K ; la configuration précédente avec le llama.cpp principal et un KV q8_0 s’arrêtait, selon l’auteur, vers 72K.

Ce retour est utile : sur une machine précise, la limite utilisable a changé avec la pile d’inférence. Mais il n’isole pas la cause, puisque le backend, le schéma de KV cache et d’autres réglages ont changé ensemble. Il ne prouve donc pas qu’un seul format explique tout l’écart, ni que les mêmes vitesses seront obtenues ailleurs.

Servez-vous-en comme piste. Si votre plafond revient toujours au même endroit, incluez KV cache et backend dans la comparaison au lieu de vous concentrer uniquement sur le fichier du modèle.

Fixez une référence avant de toucher à la configuration 72K

Conservez une base reproductible avant toute modification. Sinon, même si la nouvelle pile fonctionne, vous ne saurez pas quel changement a compté.

Domaine	Valeurs à noter
Modèle	Nom complet, fichier exact, quantification des poids, taille
Backend	Nom, version ou commit, méthode de lancement
Contexte	Fenêtre demandée, tokens réellement fournis, réserve de sortie
KV cache	Type ou schéma, placement GPU ou RAM, compression
Matériel	Modèle et VRAM de chaque GPU, RAM, topologie PCIe
Placement	Répartition GPU, offload, passages entre appareils
Runtime	Batch, concurrence, échantillonnage, sortie maximale
Résultat	Succès ou erreur, message exact, pics VRAM/RAM, prefill et génération

Ne considérez pas une carte de 16GB et une de 8GB comme un simple bloc de 24GB. Le backend décide où résident poids, cache et buffers ; une carte peut saturer la première et les échanges entre appareils peuvent dominer le coût d’un long contexte.

Testez quatre variables séparément

1. La quantification des poids modifie l’empreinte fixe

La quantification du modèle change surtout la mémoire nécessaire aux poids. Un fichier plus compact peut laisser de la place au KV cache, mais ne garantit pas une fenêtre plus longue et peut aussi modifier qualité ou vitesse.

Pour vérifier si les poids étouffent le cache, gardez backend, type de KV et prompt identiques. Ne changez que la quantification des poids, puis notez la mémoire libérée et le déplacement éventuel du point de rupture.

2. Le type de KV cache modifie le coût par token

Le KV cache conserve les états réutilisés pour les tokens suivants. Pour un modèle et une représentation fixes, son occupation augmente généralement à peu près avec le nombre de tokens conservés. C’est donc le levier mémoire le plus direct pour le contexte long.

Comparez trois résultats ensemble : pic mémoire, plus longue entrée stable et précision du rappel. « 128K tient » n’est pas une victoire utile si la précision baisse ou si le backend devient instable.

3. Le backend décide de l’implémentation réelle

Les backends peuvent différer par la disposition du cache, l’allocation, le placement multi-GPU et les kernels. La même valeur de contexte et le même fichier de modèle peuvent donc produire une autre courbe mémoire et une autre vitesse.

Si le backend candidat impose un autre format de KV, dites simplement que « cette pile passe ». N’attribuez pas tout le gain à un seul format. Pour isoler le backend, refaites si possible un A/B avec des réglages pris en charge des deux côtés.

4. Le placement matériel décide quelle ressource casse en premier

L’erreur classique en multi-GPU est de ne regarder que la VRAM totale. L’exécution peut échouer parce qu’une carte ne peut pas réserver un grand bloc, que le cache se concentre sur un appareil, que l’espace de travail manque de marge ou que le trafic PCIe rend la vitesse inutilisable.

Suivez chaque GPU séparément. Si l’un est presque plein alors que l’autre garde une marge nette, rééquilibrez le placement avant de sacrifier la qualité du modèle.

Exécutez une échelle d’acceptation du contexte long

Ne passez pas directement d’un prompt court à 128K. Une échelle fixe montre si l’échec est brutal ou si la configuration perd progressivement son intérêt.

Un bon départ est 8K → 32K → 64K → 72K → 96K → 126K. Le point 126K reste proche de 128K tout en réservant explicitement de la place à la sortie ; augmentez cette réserve si vos réponses sont longues.

Préparez un ensemble de prompts contrôlé

1. Comptez les tokens avec le tokenizer réellement utilisé par le modèle ; n’estimez ni par caractères ni par taille de fichier.
2. Placez des « faits canaris » différents vers 10 %, 20 % et ainsi jusqu’à 90 %, par exemple ORBIT-17 = copper.
3. Ajoutez une contrainte de code au début, une au milieu et une à la fin ; demandez à la réponse de les rappeler et d’effectuer une petite modification.
4. Gardez l’ordre, l’échantillonnage et le budget de sortie identiques à toutes les longueurs.
5. Retirez les autres charges et répétez trois fois chaque longueur critique.

Les canaris mesurent le rappel, pas toute la capacité de programmation. Pour l’acceptation finale, ajoutez du code, des logs ou de la documentation proches de votre travail quotidien.

Relevez les mêmes métriques à chaque exécution

Métrique	Question traitée
Tokens réels en entrée	Le backend a-t-il accepté la longueur cible ?
Résultat d’allocation et erreur exacte	Où la capacité ou la compatibilité échoue-t-elle ?
Pic par GPU et pic RAM	Quel appareil est devenu le goulot ?
Temps ou débit de traitement du prompt	Le long prefill reste-t-il acceptable ?
Vitesse de génération	L’interaction après un long prompt est-elle pratique ?
Canaris retrouvés	Le modèle utilise-t-il les informations lointaines ?
Contraintes de code respectées	La grande fenêtre aide-t-elle la vraie tâche ?

Définissez le seuil avant le test. Exemple : trois exécutions consécutives à la longueur cible, aucune erreur mémoire ou backend, au moins 9 canaris corrects sur 10 et des temps compatibles avec votre flux. 9/10 n’est qu’un exemple ; l’essentiel est de ne pas abaisser le seuil après avoir vu un 128K qui démarre.

Choisissez la suite selon le résultat

OOM revient toujours à la même longueur

Trouvez d’abord quel appareil sature. Si la croissance du cache consomme la marge, comparez un schéma plus compact. Si les poids occupent déjà presque tout après chargement, essayez une quantification plus petite. Modifiez un seul élément et vérifiez si le plafond se déplace comme prévu.

Le nouveau backend atteint 128K et l’ancien s’arrête à 72K

Considérez la nouvelle pile comme candidate, reproduisez trois fois et terminez le test de rappel. Si backend et cache ont changé ensemble, la conclusion solide est que la pile fonctionne, pas qu’une cause unique a été isolée.

128K se termine, mais les performances sont inacceptables

C’est une limite d’exploitation, pas un échec de capacité. Utilisez une fenêtre plus petite par défaut et n’activez l’extrême longueur que pour certaines tâches, ou comparez un modèle plus petit, un autre backend ou un meilleur placement. « Peut fonctionner » et « mérite d’être utilisé chaque jour » sont deux décisions différentes.

128K se termine, mais perd les informations initiales

Traitez cela comme un problème de qualité du contexte effectif. Exécutez le même prompt à 64K, 72K et 96K pour tracer une courbe de rappel. Si les longueurs plus courtes sont nettement plus fiables, placez la limite de production là où la qualité passe, pas là où l’allocation réussit. Recherche, découpage ou résumé préalable peuvent aussi retirer le contenu inutile des très grands dépôts.

Optimisez une fenêtre vérifiée, pas le plus grand nombre du menu

Si 72K couvre déjà vos dépôts et logs habituels, ne remplacez pas en même temps quantification, KV cache, backend et répartition GPU juste pour afficher 128K. Gardez la référence stable et demandez à chaque changement de prouver un gain de capacité, de vitesse ou de rappel.

Si votre travail exige réellement plus de 100K en entrée, définissez d’abord l’échelle et les critères d’acceptation, puis comparez les combinaisons cache/backend. La conclusion utile est précise : « ce modèle, ce backend, ce cache et ce matériel ont passé 126K trois fois à notre vitesse et notre rappel minimums », et non simplement « la configuration prend en charge 128K ».