L’éviction du cache KV peut masquer les défaillances des LLM en production

Oui. L’éviction du cache KV peut masquer les défaillances des LLM, car une politique de service peut supprimer un état d’attention important, puis ne pas disposer de suffisamment d’informations pour estimer les dommages à partir du seul cache conservé.

Un article soumis le 23 juillet 2026 établit une limite précise à ce problème : l’éviction top-k déterministe et indépendante des valeurs ne peut pas estimer de manière cohérente l’erreur de sortie d’attention qu’elle induit à partir du seul état conservé. L’alternative proposée conserve un échantillon probabiliste de la partie supprimée et construit un certificat statistique autour de l’erreur estimée. La méthode a amélioré l’attribution des défaillances dans les expériences rapportées, mais le prototype est plus lent, les expériences s’arrêtent à un contexte de 16K et à 8B paramètres, et l’article ne prouve pas l’exactitude des réponses de bout en bout.

Avant le déploiement, comparez chaque traitement candidat du cache à un contrôle avec cache complet sur les mêmes requêtes figées. Comptez les cas où le cache complet réussit et où le candidat échoue. Testez séparément l’éviction, la quantification, le déport et la réutilisation afin que chaque comparaison isole une seule source d’erreur.

Niveau du lecteur : Avancé. Ce guide suppose que vous comprenez l’inférence des transformers, l’attention et l’évaluation de base des modèles.

Sommaire

Pourquoi l’éviction du cache KV peut masquer les défaillances

La sortie de l’attention dépend des entrées conservées et de celles que la politique supprime. Après qu’une politique déterministe a supprimé la partie finale, un moniteur qui ne voit que l’ensemble sélectionné ne peut pas examiner les valeurs manquantes.

ArXiv:2607.21475 étudie ce problème d’observabilité. Son résultat négatif s’applique à l’éviction top-k déterministe et indépendante des valeurs : l’état conservé seul ne permet pas d’estimer de manière cohérente l’erreur de sortie d’attention causée par l’éviction. Le résultat ne dit pas que toute politique déterministe produit de mauvaises sorties. Il dit que cette classe de politiques ne peut pas certifier de manière fiable l’erreur qu’elle induit en utilisant uniquement ce qu’elle a conservé.

La méthode proposée préserve des éléments attestant l’existence de la partie supprimée. Elle échantillonne selon une loi de Poisson les entrées qui disparaîtraient autrement, applique une correction de Hájek et combine cette estimation avec un certificat de variance de l’ensemble conservé.

Mesuré : Le certificat d’erreur a enregistré une couverture de 0,97 sur 12 096 cellules de rejeu de l’attention. Une étude distincte sur des charges de travail réelles a utilisé environ 74 000 générations pour tester l’attribution des défaillances. Dans cette étude, le certificat a atteint une AUC de 0,73–0,75 pour distinguer les défaillances induites par le cache des défaillances inhérentes au modèle. La confiance de sortie a atteint 0,47–0,54 pour la même tâche d’attribution.

Mesuré : La confiance de sortie prédisait mieux les défaillances globales. Les deux signaux répondent à des questions différentes :

Inféré : Une faible confiance de sortie ne peut pas servir seule d’alarme de régression du cache. Elle peut signaler une réponse faible sans en identifier la cause, tandis qu’une réponse confiante peut tout de même changer après que la politique du cache a supprimé un état utile.

L’article rapporte également des résultats négatifs et opérationnels. Trois des sept affirmations préenregistrées ont échoué. Son prototype a pris 0,043 seconde par token, contre 0,023 pour l’éviction déterministe et 0,015 pour le cache complet. Les expériences couvraient des contextes allant jusqu’à 16K, des modèles allant jusqu’à 8B et un proxy à un seul tour. Les auteurs ne fournissent aucun théorème reliant le certificat à l’exactitude des tâches de bout en bout.

Interprétation pratique : Traitez le certificat comme un signal d’attribution dans les conditions étudiées. Il ne certifie pas l’aptitude à la production.

Quatre traitements du cache, quatre questions de fiabilité

Les équipes regroupent souvent plusieurs interventions sous le terme « optimisation du cache KV ». Chaque intervention modifie une partie différente de l’inférence.

L’étude systémique présentée dans arXiv:2607.08057 classe le domaine selon l’ordonnancement temporel, le placement et la migration spatiaux, ainsi que la représentation et la conservation structurelles. Cette taxonomie constitue également une limite d’évaluation. Comparer un contrôle BF16 avec cache complet à un candidat FP8 avec éviction modifie simultanément deux variables structurelles. Un échec du candidat ne permet pas de déterminer si la régression vient de l’éviction, de la quantification ou de leur interaction.

Interprétation pratique : Testez chaque intervention sur le cache comme une expérience distincte. Ne les combinez qu’après la réussite des traitements individuels.

Les politiques qui préservent davantage d’état utile

Deux autres articles montrent que la conception de la politique peut préserver davantage de qualité avec le même budget mémoire. Aucun ne fournit de seuil de production universel.

VaSE, arXiv:2606.03928 protège les états de valeur à forte magnitude tout en conservant une diversité stochastique. Sur Qwen3-4B et Qwen3-14B, pour six tâches de raisonnement, il a atteint environ 4× de compression du cache et amélioré les résultats de 4,4 et 4,9 points par rapport à la meilleure référence d’éviction. Une configuration à 16K sur un seul A100 a atteint 3,1× tokens par seconde.

Ces mesures couvrent uniquement le décodage, les modèles Qwen3 et aucune mise en lots de production. Elles n’établissent pas le même gain pour une autre famille de modèles, un autre moteur de service, un autre niveau de concurrence ou une autre charge de travail.

K-VEC, arXiv:2606.29563 coordonne la couverture de conservation entre les têtes et les couches d’attention. Sur Llama 3.1 8B et 16 sous-ensembles de LongBench, il a amélioré les scores jusqu’à 10,35 points et de 1,61 point en moyenne avec un budget de `B=128`. L’évaluation utilise une seule famille de modèles et une seule suite de benchmarks, et la méthode ajoute du travail de prefill.

Interprétation pratique : Les politiques sensibles aux valeurs, stochastiques et sensibles à la couverture méritent des places parmi les candidats évalués. Votre exécution avec cache complet reste la source locale de vérité.

Pourquoi la quantification nécessite un contrôle distinct

La quantification FP8 du cache KV réduit la précision au lieu de supprimer des tokens. Ses erreurs peuvent tout de même atteindre l’application sans erreur du moteur.

Une étude officielle de vLLM sur FP8, publiée le 22 avril 2026, a rapporté une baisse de la précision du test needle en contexte long, de 91 % avec un cache BF16 à 13 % avec FP8, avant une correction de l’accumulation à deux niveaux. La correction a rétabli la précision à 89 %. Dans la meilleure configuration FP8 rapportée, la pente de décodage représentait 54 % de celle du BF16.

Mesuré : Un chemin numérique a produit une régression sévère, et une correction au niveau du kernel a récupéré la majeure partie de la précision perdue.

Non établi : Le cache FP8 ne provoque pas universellement cette régression et ne fournit pas universellement cette accélération. Le résultat dépend de l’implémentation, du modèle, du matériel, du chemin d’attention et du benchmark.

vLLM issue #37554 ajoute un avertissement limité : un rapporteur a constaté une mise à l’échelle FP8 du KV silencieusement corrompue sur un modèle hybride. Ce rapport de bug ne permet pas d’étayer une affirmation générale sur FP8 ou les architectures hybrides.

Une discussion LocalLLaMA du 7 avril contient des témoignages contradictoires de praticiens sur les formats de cache et la qualité. Ces témoignages peuvent suggérer des cas de test, mais une évaluation contrôlée doit décider du déploiement.

La version v0.26.0 de vLLM, datée du 25 juillet, contient 411 commits de 212 contributeurs et améliore la visibilité sur la hiérarchisation KV, les métriques de déport et la réutilisation du cache. L’activité de publication et les nouvelles fonctionnalités d’observabilité ne prouvent ni une adoption large en production ni l’exactitude.

Un workflow de validation appariée avec cache complet

Définissez le « cache complet » comme le comportement natif de l’attention du modèle, sans éviction ajoutée ni quantification du cache. Dans chaque paire, gardez fixes les poids du modèle, le tokenizer, la version du runtime, le backend d’attention, les paramètres d’échantillonnage, les tokens du prompt et le validateur de sortie.

1. Exécuter une matrice d’ablation

Utilisez au moins quatre traitements :

Comparer uniquement A à D peut révéler une régression combinée, mais ne permet pas d’en attribuer la cause. Les exécutions B et C fournissent les contrôles manquants.

Testez séparément chaque modèle, runtime, kernel et chemin matériel pris en charge. Le résultat FP8 de vLLM montre pourquoi une étiquette telle que « FP8 activé » ne contient pas suffisamment de détails pour prendre une décision de fiabilité.

*Légende : La validation appariée avec cache complet isole les échecs propres au candidat avant que l’éviction ou la quantification n’atteigne la production.*

2. Figer une matrice de charges de travail

Construisez la matrice à partir des formes réelles de requêtes et incluez les cas limites :

Les charges de travail en contexte long nécessitent davantage qu’un test needle synthétique. Si le produit exécute des agents de code ou des workflows étendus, incluez des traces représentatives. Le volume de tokens et la forme du workflow influencent l’économie décrite dans More Tokens, Better AI — and the Compute Bill et Code Agents, 21 Billion Activity Tokens, and the Fable of GPT-5.6.

3. Apparier les requêtes et isoler l’état du cache

Utilisez cette logique d’évaluation :

text for each frozen_case: full = run(frozen_case, treatment=A, isolated_cache=true) candidate = run(frozen_case, treatment=candidate, isolated_cache=true)

full_pass = validate(full, frozen_case.expected_behavior) candidate_pass = validate(candidate, frozen_case.expected_behavior)

record(full_pass, candidate_pass, context_length, task_type, model, runtime, hardware, treatment)

Ce bloc est du pseudocode, pas une API propre à un moteur. Utilisez un validateur de tâche plutôt qu’une égalité textuelle lorsque plusieurs réponses peuvent être correctes. Les validateurs adaptés comprennent les tests unitaires pour le code généré, les vérifications de schéma pour les sorties structurées, les vérifications exactes de l’outil et de ses arguments, les assertions de récupération ou une grille préenregistrée.

Gardez les espaces de noms du cache isolés. Un état de préfixe réutilisé entre les traitements peut contaminer la comparaison.

4. Mesurer les échecs propres au candidat

Utilisez cette métrique principale :

text cache_induced_failure_rate = count(full passes and candidate fails) / count(full passes)

Le dénominateur conditionne le taux sur la réussite avec cache complet. Une paire où les deux exécutions échouent ne montre pas que la compression du cache a causé l’échec.

Rapportez le numérateur et le dénominateur bruts pour chaque segment critique. Un agrégat unique peut masquer une régression au contexte maximal, sur un modèle ou avec un backend d’attention donné. Suivez le taux d’échec total à côté de la métrique appariée, car les signaux de confiance de sortie et d’attribution au cache couvrent des modes d’échec différents.

5. Déclarer la règle de décision à l’avance

Choisissez le taux maximal acceptable, `τ`, avant d’examiner les résultats du candidat. Établissez des règles plus strictes pour les tâches critiques. Un échec propre au candidat reproductible peut justifier un rejet sur un chemin d’outil, de sécurité ou de transaction, même si l’agrégat reste inférieur à `τ`.

La configuration du cache fait partie de la politique d’exécution. Enregistrez-la et imposez-la avec la même rigueur que celle utilisée pour les permissions déterministes des agents AI : configuration explicite, décisions observables et voie de réparation lorsque l’application échoue.

Décisions de déploiement

L’activité des notes de version, les témoignages anecdotiques et les gains moyens aux benchmarks ne peuvent pas remplacer une barrière de déploiement appariée.

Limites des éléments probants actuels

Le résultat le plus solide du certificat couvre l’erreur de sortie de l’attention dans un proxy à un seul tour, et non l’exactitude applicative de bout en bout. Ses expériences s’arrêtent à 16K et 8B, alors que les systèmes de production peuvent exécuter des modèles plus grands, des contextes plus longs, plusieurs tours, des outils et des lots. Le prototype mesuré coûte également davantage de temps par token que l’éviction déterministe et le cache complet dans la configuration rapportée.

VaSE et K-VEC restent liés à des modèles, tâches, budgets et configurations de service spécifiques. Les éléments probants de vLLM montrent que les détails d’implémentation peuvent dominer un résultat lié au format du cache. Aucune de ces sources ne fournit de ratio universel de compression sûr.

Interprétation pratique : Utilisez la recherche pour choisir les politiques candidates et les signaux de surveillance. Utilisez la validation appariée avec cache complet pour décider si votre implémentation respecte les limites de fiabilité de votre charge de travail.

Vérification des affirmations

Sources