Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.4 · SDK 2.6.7. Source anglaise

Utilisation de la mémoire

Statut : Actuel

Portée : état actuel

Dernière revue : 2026-09-13

Responsable : runtime ax-code

AX Code partage la machine avec les serveurs de langage, les constructions de dépôt, les navigateurs et tout runtime de modèle local. Un serveur TypeScript ou un analyseur Rust peut utiliser plus de mémoire que le moteur AX Code lui-même. Ces processus fournissent l’analyse de code ; ce ne sont pas des services vocaux. Additionner le RSS des processus peut compter les pages partagées plus d’une fois.

Profils

AX_CODE_MEMORY_PROFILE accepte auto (défaut), low ou normal. Dans auto, un hôte qui signale au plus 8 GiB de RAM physique sélectionne low ; les autres hôtes sélectionnent normal. Les valeurs invalides utilisent la détection automatique. La détection utilise la RAM physique de l’hôte, pas la RAM libre ni une limite de mémoire de conteneur ; sélectionnez low explicitement dans une machine virtuelle ou un conteneur contraint lorsque c’est nécessaire. Définissez la variable avant de démarrer AX Code ; elle ne reconfigure pas un moteur déjà en cours.

AX_CODE_MEMORY_PROFILE=low ax-code

PowerShell :

$env:AX_CODE_MEMORY_PROFILE = "low"
ax-code

Les serveurs de langage démarrent à la demande par défaut dans les deux profils. Le démarrage et les lectures de fichiers ordinaires ne déclenchent pas de préchauffage sémantique spéculatif. La navigation sémantique explicite, les diagnostics et l’indexation démarrent encore l’analyse nécessaire, donc la première requête sémantique peut prendre plus de temps. Pour rétablir le préchauffage spéculatif de démarrage et de lecture sur un hôte qui a une marge suffisante, définissez les deux variables avant le démarrage :

AX_CODE_MEMORY_PROFILE=normal AX_CODE_LSP_PREWARM=1 ax-code

Seule la valeur exacte 1 active le préchauffage spéculatif ; low le supprime toujours. Les serveurs existants ne sont pas terminés par ce réglage, et ce n’est pas une interdiction globale du démarrage LSP : les modifications qui exigent des diagnostics et les opérations sémantiques ou d’indexation explicites utilisent encore les serveurs de langage. La récupération d’inactivité en mode bas reste distincte.

Le cache de source a aussi une limite de 1,000 entrées. Sa comptabilité inclut une marge conservatrice de chaînes et de clés ; ce n’est pas une limite de tas V8 ni de RSS. Un fichier qui ne peut pas tenir synchronise encore son contenu courant complet avec le serveur de langage. L’éviction du cache ne ferme pas un document tant qu’une requête peut en avoir besoin.

Le mode bas met le travail en file plutôt que d’ignorer l’analyse. Le premier usage, ou l’usage après un arrêt d’inactivité, peut prendre plus de temps. Les clients sélectionnés ou en file, les RPC sous-jacents en attente et les attentes de diagnostic sont protégés de l’arrêt d’inactivité. Une requête expirée peut laisser du travail côté serveur en cours : deux opérations attendues ne garantissent pas seulement deux calculs dans les serveurs de langage. L’inventaire de diagnostic est marqué dégradé après une récupération d’inactivité, parce que redémarrer un fichier ne peut pas prouver la couverture complète de l’ancien espace de travail.

Ces limites s’appliquent dans chaque processus AX Code. Elles ne limitent pas la RAM totale, ne coordonnent pas des instances AX Code distinctes, ne plafonnent pas les tas des serveurs de langage et ne contrôlent pas un compilateur, un navigateur ou un modèle local. La sélection de modèle, le contexte d’invite exigé et les commandes de vérification restent inchangés.

Rétention des sessions et des preuves

Le TUI conserve les événements de transcription lourds pour la session affichée. Les sessions inactives conservent les résumés, l’état et les approbations ou questions en attente ; les ouvrir recharge l’historique enregistré depuis SQLite. La fenêtre d’affichage normale est de 100 messages avec un budget de charge sérialisée de 16 MiB. Les anciens messages complets sont libérés en premier. Le message indivisible le plus récent et l’historique Annuler/Restaurer récupéré peuvent dépasser le budget souple ; le TUI affiche un indicateur. Ce sont des limites de projection, pas des limites sur l’historique de session durable ni sur le contexte du modèle.

Lorsque le tas V8 approche sa limite dure, le budget de transcription se resserre automatiquement (jusqu’à un plancher de 2 MiB à 90 % d’usage du tas) afin que l’ensemble retenu se déleste avant que le processus atteigne FatalProcessOutOfMemory ; au-delà de 80 %, le TUI affiche aussi un avertissement qui suggère /compact ou un redémarrage. La pression se résorbe après un GC complet, mais l’historique déjà évincé reste absent jusqu’au rechargement.

Les parties qui arrivent avant leur message parent utilisent une zone d’attente bornée (128 identifiants de message / 1 MiB). Si le contenu en attente doit être libéré, le TUI propose un rechargement depuis l’historique enregistré. Les événements tardifs pour des messages évincés ne peuvent pas recréer durablement des parties orphelines.

Le cache de preuves utilise par défaut une mémoire bornée (128 entrées / 4 MiB de valeurs sérialisées par instance). RocksDB reste une activation explicite ; changer seulement le moteur de cache ne réduit pas les appels d’outils du modèle. Voir Cache de preuves.

Sortie des commandes en arrière-plan

La sortie d’arrière-plan non lue utilise des fichiers transitoires privés au lieu de retenir des chaînes JavaScript de plusieurs mégaoctets pour chaque shell terminé. Chaque fichier est un anneau UTF-8 de 2 MiB ; la sortie non lue la plus ancienne au-delà de cette limite est abandonnée et étiquetée. Jusqu’à 32 fichiers d’anneau réservent au plus 64 MiB par processus. Lorsque les emplacements disque sont pleins, la bobine terminée la plus ancienne peut expirer ; la propriété d’un shell actif n’est pas évincée. Les lectures renvoient la sortie non lue retenue de façon incrémentale et libèrent son emplacement disque.

Le registre autorise 16 shells actifs par session et 32 par processus, et conserve au plus 16 enregistrements terminés par session / 64 par processus. La sortie terminée expire après 30 minutes (contrôlée à l’accès et environ une fois par minute). Les listes de commande et de description sont des aperçus plafonnés à 8 KiB / 1 KiB ; la commande exécutée est inchangée. Le rejeu d’observateur a des limites distinctes de 64 KiB et 128 enregistrements par shell, avec un budget d’octets de 2 MiB pour tout le processus ; un rejeu incomplet est étiqueté.

bash_output signale l’intégrité de la sortie séparément de l’état de sortie réel du processus. Une sortie abandonnée, expirée ou illisible est une preuve de vérification incomplète, même lorsque la commande s’est terminée avec le code zéro. Ces avis restent visibles lorsqu’un filtre de sortie est utilisé. Un enregistrement manquant peut signifier qu’il a déjà été consommé ou évincé ; une sortie indisponible n’est pas la preuve qu’un contrôle a réussi.

Les fichiers utilisent un répertoire temporaire privé possédé par le processus (0700) et des fichiers 0600 sur POSIX. Les lectures, le retrait de session, le nettoyage de rétention et la sortie normale du processus libèrent les fichiers possédés. La bobine n’est pas un stockage de session durable en cas de plantage. Une terminaison forcée ou un plantage peut laisser un répertoire temporaire privé ; le ramassage automatique entre processus n’est pas mis en œuvre, donc la limite de 64 MiB décrit le processus courant, pas les restes de plantage accumulés. Les erreurs de nettoyage du système de fichiers sont signalées et ne libèrent pas la réservation de quota du fichier en échec. Les entrées-sorties de fichiers synchrones et bornées évitent des files d’écriture non bornées, mais peuvent ajouter de la latence sur un système de fichiers temporaire lent.

Choisir une charge

Pour les hôtes contraints, utilisez d’abord un fournisseur cloud, une session de codage active et un petit dépôt. N’exécutez de grandes constructions et des sessions d’agent supplémentaires que lorsque la machine a de la marge. L’inférence locale a besoin d’un budget distinct pour les poids, le cache KV et le contexte, et le surcoût du runtime ; les conseils matériels d’un fournisseur cloud ne s’y appliquent pas.

Utilisez le CLI empaqueté pour l’usage ordinaire ; pnpm run dev est un flux de contribution depuis les sources, avec un coût de démarrage et de chargement de modules différent. Inspectez AX Code avec ses enfants serveurs de langage et de construction dans Activity Monitor ou le moniteur de processus de la plateforme. Une borne de cache réduite n’établit pas une réduction fixe de la mémoire physique.

Les changements de mémoire ont des tests déterministes de rétention et d’équivalence sémantique. Ils n’ont pas été qualifiés par un test de charge sur un Mac physique de 8 GB. Le mode bas ne garantit pas qu’un projet arbitraire tiendra sur une machine de 8 GB.