Contexte long sur une carte de 16 Go : KVMem, et notre version

Niveau AvancéTemps estimé une soiréeÀ lire avant Lent sans raison ? Il relit : le piège du cache KV, Un modèle de 177 milliards de paramètres sur deux cartes grand public : l'emplacement compte plus que le débitUn mot inconnu ? Lexique

La conversation d'un agent de code grimpe à 100 000 jetons et plus. Un serveur normal garde le cache d'attention de toute cette conversation sur la carte, et ralentit à mesure qu'elle grandit. KVMem, une extension libre de llama.cpp, garde l'historique en RAM système et ne ramène sur la carte que les blocs utiles à l'étape en cours. Nous l'avons mesuré face à llama.cpp seul sur nos propres cartes, puis construit notre propre version pour notre machine.

Comment ces chiffres ont été obtenus. Mesurés sur nos propres machines (voir le protocole), en général en un seul passage, vitesses relevées par le serveur lui-même ; nous ne publions pas les journaux bruts. Ce sont des ordres de grandeur sur ce matériel, pas des garanties sur le vôtre. Les chiffres extérieurs sont accompagnés de leur source.

Ce que vous y gagnez. Mesuré ici : 48 rappels sur 48 à 44k et 130k jetons ; à 103k jetons, 150,9 jetons par seconde contre 132,1 pour llama.cpp seul ; 4,9 Go de VRAM libérés. Et un modèle à mélange d'experts de 177B servi depuis une seule carte de 16 Go.

1. L'idée

Les blocs terminés du cache d'attention partent en RAM système. À chaque étape, KVMem choisit les blocs qui comptent pour la question en cours et les place, dans l'ordre, dans une fenêtre de travail bornée sur la carte. L'article de recherche qui le fonde montre qu'une fenêtre résidente de 32k est quasiment sans perte face à l'historique complet de 256k.

llama-kvmem-server -m modele.gguf -c 262144 --kvmem-budget 8192 \
  --kvmem-gen-reserve 16384 --spec-type draft-mtp

Une génération ne peut pas dépasser --kvmem-gen-reserve jetons, réflexion comprise. Dimensionnez-le pour votre plus longue réponse.

2. Mesurer avant de basculer

Rappel : 48/48 pour llama.cpp, KVMem non borné et KVMem borné à 8 192, avec des questions sur le début et sur la fin de la conversation.
Vitesse : llama.cpp seul est plus rapide sur les contextes courts (178,9 contre 151,0 à 39k) ; KVMem reste plat et le dépasse vers 70k jetons sur notre carte la plus rapide, 53k sur l'autre.
Basculer de moteur en pleine conversation a coûté 17,9 s, surtout de relecture du contexte : le point de croisement n'est pas le bon point de bascule.

Notre règle : KVMem pour les agents (contextes longs), llama.cpp seul pour le chat et les appels courts. Deux préréglages, pas de bascule automatique.

3. Ce que change notre version, et pourquoi

Un binaire pour deux générations de cartes. L'original compile pour la seule architecture la plus récente ; un hôte avec une seconde carte plus ancienne charge le modèle et échoue sur elle, sans bruit. Nous compilons pour les deux (89-real;120a-real), pour comparer les cartes sans rien changer d'autre.
Les experts en mémoire hôte : --cpu-moe, --n-cpu-moe, -ot et --no-repack dans le serveur KVMem, pour que les experts d'un énorme modèle MoE restent en cache de pages évictable au lieu de 21 Go de mémoire épinglée.
Un plantage corrigé pour l'architecture de Flash-Next : le contexte mémoire remis au graphe n'était pas du bon type, et le serveur s'arrêtait sur une assertion au démarrage.
Les probabilités par jeton (logprobs, top_logprobs) sur le point d'accès de chat : l'hésitation du modèle, jeton par jeton, pour un agent qui décide quand demander de l'aide.
Un cache d'experts sur la carte, en se rebasant sur un fork de llama.cpp qui en a un : les experts sollicités restent sur la carte. La pointe la plus récente de ce fork décodait à 28,6 jetons par seconde, le commit que nous avons épinglé à 36,9 : nous avons gardé le plus rapide.

Pièges

Oubliez scripts/apply-patches.sh après la mise à jour du sous-module, et la compilation échoue loin dedans, sur des membres manquants, ce qui ressemble à une mauvaise version du sous-module. Ce n'en est pas une. Le lancer deux fois ne casse rien.

Un commentaire placé entre deux lignes d'une continuation \ coupe la commande en silence : notre appel à CMake a perdu ses options CUDA, et bash -n trouvait le fichier correct. Seule l'exécution du script l'a révélé ; le test vérifie désormais les arguments que CMake reçoit vraiment.

Certaines familles de modèles ne sont pas prises en charge (l'attention à fenêtre glissante, par exemple) : elles restent sur llama.cpp seul.

Sources

Utile ? Dites-nous ce qu'il faut mesurer ensuite.