Correction du ralentissement d’OpenClaw lors de longues sessions : continuation-skip d’injection de contexte pour le cache de llama.cpp

Si votre OpenClaw auto-hébergé avec llama.cpp devient progressivement plus lent à mesure que les sessions dépassent les 90k tokens, le coupable pourrait être un seul paramètre OpenClaw qui invalide silencieusement le cache de prompt à chaque tour. Un utilisateur sur r/openclaw a tracé le problème et a trouvé une solution simple.

La configuration

• Qwen3.6-27B-Q8_0 sur deux RTX 3090 (parallélisme tensoriel)
• llama-server avec --cache-prompt, --ctx-size 400000, --parallel 2
• OpenClaw connecté en LAN

Les symptômes

Les logs de llama-server montraient à chaque tour :

forcing full prompt re-processing due to lack of cache data
erased invalidated context checkpoint (pos_min = 57172)
erased invalidated context checkpoint (pos_min = 60139)
erased invalidated context checkpoint (pos_min = 91076)
prompt eval time = 130511 ms / 91403 tokens

91k tokens retraités à zéro à chaque tour — 130 secondes. Le cache était activé, des checkpoints existaient, mais llama.cpp ne trouvait aucune correspondance et retombait sur un retraitement complet.

La cause racine

Le paramètre contextInjection d'OpenClaw, par défaut always, réinjecte tous les fichiers d'amorçage de l'espace de travail (AGENTS.md, SOUL.md, USER.md, TOOLS.md, MEMORY.md, HEARTBEAT.md, ~15kb) dans le prompt système à chaque tour — y compris les tours de continuation. Cela modifie la séquence de tokens, de sorte que le cache de prompt de llama.cpp (qui repose sur une correspondance exacte de préfixe) ne peut pas être réutilisé.

La correction

openclaw config set agents.defaults.contextInjection continuation-skip --merge

Redémarrez ensuite la passerelle. continuation-skip n'injecte les fichiers d'amorçage que sur les nouveaux messages utilisateur, pas sur les tours de continuation, ce qui maintient le prompt stable et le cache valide.

Les résultats

Avant : 91 403 tokens retraités par tour, 130s d'évaluation du prompt, 0% de réutilisation du cache, 2+ min par réponse.

Après : 513 nouveaux tokens par tour, 1,3s d'évaluation du prompt, 99,7% de réutilisation du cache, ~5 secondes par réponse. 100x plus rapide.

Comment diagnostiquer

ssh your-server "journalctl -u llama.service --no-pager -n 50 | grep -iE 'cache|re-process|checkpoint'"

Signes de cache cassé : forcing full prompt re-processing due to lack of cache data, erased invalidated context checkpoint répété, traitement du prompt de plus de 30 secondes. Signes de cache sain : restored context checkpoint, f_keep = 0.99+, graphs reused = grand nombre, traitement du prompt sous 5 secondes.

Réglez également --ctx-size à 400k (200k par session), contextTokens d'OpenClaw à 200k, et memoryFlush.softThresholdTokens de 30k à 10k pour des améliorations supplémentaires.