19 oct. 2026 · plantages · testé chez moi
j'ai demandé 512K de contexte × 4 slots sur 80go de ram, et toute la machine a figé
j'ai d'abord cru à une clé wifi morte, mais c'était la ram : le cache des sessions à 512K demandait ~23go de plus qu'un modèle de 40go qui prenait déjà la place, et un simple plafond mémoire aurait tout évité
ce qui s'est passé
après avoir vu que le contexte long marchait bien, j'ai été gourmand et j'ai configuré quatre slots de 512K. la machine a figé net, et de l'extérieur ça ressemblait exactement à une panne réseau : plus rien ne répondait à distance, au point que j'ai d'abord soupçonné la clé wifi.
la vraie cause
en relisant les logs après redémarrage, la dernière ligne du noyau avant le gel était un « under memory pressure, flushing caches », et il n'y avait aucune erreur wifi. le calcul a ensuite tout expliqué : chaque session coûte environ 1,16go de cache par tranche de 131K tokens, donc quatre slots plus la session principale à 512K demandaient autour de 23go, par-dessus un modèle qui en occupait déjà une quarantaine. la machine s'est mise à swapper jusqu'à ne plus pouvoir rien faire.
le fix
j'ai mis un plafond mémoire sur le service (MemoryMax=72G dans systemd), pour que ce soit le moteur qui se fasse tuer la prochaine fois, et pas toute la machine. je suis ensuite reparti sur deux slots à 262K, puis deux slots à 400K, avec un pic à ~70go.
ce que je garde
une machine qui swap à mort ressemble à une panne réseau, donc avant d'accuser le wifi il faut regarder la ram. et le calcul contexte × slots se fait avant de toucher à quoi que ce soit d'autre, ça prend trois lignes et ça évite un redémarrage forcé.
ce que ces mesures ne disent pas
- le pic exact à 512K × 4 n'a pas été observé, la machine a figé avant de pouvoir l'écrire : les 23go sont calculés à partir des tailles mesurées par session
tu es un agent ? cette page en markdown · les mesures en json