Diese Seite ist eine Übersetzung der englischen Dokumentation. Befehle, Bezeichner und Beispiele bleiben unverändert. Runtime 7.24.4 · SDK 2.6.7. Englische Fassung

Speicherverbrauch

Status: Aktuell

Umfang: aktueller Stand

Zuletzt geprüft: 2026-09-13

Verantwortlich: AX-Code-Laufzeit

AX Code teilt den Rechner mit Language-Servern, Repository-Builds, Browsern und jeder lokalen Modelllaufzeit. Ein TypeScript-Server oder Rust-Analyzer kann mehr Speicher nutzen als das AX-Code-Backend selbst. Diese Prozesse liefern Codeanalyse und sind keine Sprachdienste. Das Summieren von Prozess-RSS kann gemeinsame Seiten mehr als einmal zählen.

Profile

AX_CODE_MEMORY_PROFILE akzeptiert auto (Standard), low oder normal. In auto wählt ein Host, der höchstens 8 GiB physischen RAM meldet, low. Andere Hosts wählen normal. Ungültige Werte verwenden die automatische Erkennung. Die Erkennung nutzt den physischen Host-RAM, nicht freien RAM oder ein Container-Speicherlimit. Wählen Sie low in einer eingeschränkten VM oder einem Container ausdrücklich, wenn nötig. Setzen Sie die Variable, bevor Sie AX Code starten; ein bereits laufendes Backend wird dadurch nicht neu konfiguriert.

AX_CODE_MEMORY_PROFILE=low ax-code

PowerShell:

$env:AX_CODE_MEMORY_PROFILE = "low"
ax-code

Language-Server starten in beiden Profilen standardmäßig bei Bedarf. Start und gewöhnliche Dateilesevorgänge lösen kein spekulatives semantisches Vorwärmen aus. Ausdrückliche semantische Navigation, Diagnosen und Indizierung starten die nötige Analyse weiterhin, daher kann die erste semantische Anfrage länger dauern. Um spekulatives Vorwärmen bei Start und Lesen auf einem Host mit ausreichendem Spielraum wiederherzustellen, setzen Sie beide Variablen vor dem Start:

AX_CODE_MEMORY_PROFILE=normal AX_CODE_LSP_PREWARM=1 ax-code

Nur der genaue Wert 1 aktiviert spekulatives Vorwärmen. low unterdrückt es immer. Vorhandene Server werden durch diese Einstellung nicht beendet, und sie ist kein globales Verbot des LSP-Starts: Bearbeitungen, die Diagnosen verlangen, und ausdrückliche semantische oder indizierende Operationen verwenden Language-Server weiterhin. Die Rückforderung untätiger Prozesse im Niedrigmodus bleibt getrennt.

Der Quellcache hat außerdem eine Grenze von 1.000 Einträgen. Seine Abrechnung enthält einen vorsichtigen Aufschlag für Zeichenketten und Schlüssel und ist keine V8-Heap- oder RSS-Grenze. Eine Datei, die nicht hineinpasst, synchronisiert ihren vollständigen aktuellen Inhalt weiterhin mit dem Language-Server. Das Verdrängen aus dem Cache schließt ein Dokument nicht, solange eine Anfrage es brauchen kann.

Der Niedrigmodus reiht Arbeit ein, statt Analyse zu überspringen. Die erste Nutzung oder die Nutzung nach einem untätigen Herunterfahren kann länger dauern. Ausgewählte oder eingereihte Clients, ausstehende zugrunde liegende RPCs und Diagnosewartezeiten sind vor dem untätigen Herunterfahren geschützt. Eine zeitüberschrittene Anfrage kann serverseitige Arbeit weiterlaufen lassen: Zwei erwartete Operationen garantieren nicht nur zwei Berechnungen innerhalb der Language-Server. Das Diagnoseinventar wird nach der untätigen Rückforderung als eingeschränkt markiert, weil der Neustart einer Datei keine vollständige Abdeckung des früheren Workspace belegen kann.

Diese Grenzen gelten innerhalb jedes AX-Code-Prozesses und begrenzen nicht den gesamten RAM, koordinieren keine getrennten AX-Code-Instanzen, deckeln keine Heaps von Language-Servern und steuern keinen Compiler, Browser oder lokales Modell. Modellauswahl, erforderlicher Promptkontext und Prüfbefehle bleiben unverändert.

Aufbewahrung von Sitzung und Nachweisen

Die TUI behält schwere Transkriptereignisse für die betrachtete Sitzung. Inaktive Sitzungen behalten Zusammenfassungen, Status und ausstehende Genehmigungen oder Fragen. Beim Öffnen wird die gespeicherte Historie aus SQLite neu geladen. Das normale Anzeigefenster umfasst 100 Nachrichten mit einem Budget von 16 MiB serialisierter Nutzlast. Alte vollständige Nachrichten werden zuerst freigegeben. Die neueste unteilbare Nachricht und wiederhergestellte Undo-/Restore-Historie können das weiche Budget überschreiten. Die TUI zeigt einen Hinweis. Das sind Projektionsgrenzen, keine Grenzen der dauerhaften Sitzungshistorie oder des Modellkontexts.

Wenn sich der V8-Heap seiner harten Grenze nähert, verengt sich das Transkriptbudget automatisch (bis zu einem Boden von 2 MiB bei 90 Prozent Heap-Nutzung), damit die behaltene Menge abnimmt, bevor der Prozess FatalProcessOutOfMemory erreicht. Ab 80 Prozent zeigt die TUI außerdem eine Warnung, die /compact oder einen Neustart vorschlägt. Der Druck lässt nach einer vollen GC nach, aber bereits verdrängte Historie bleibt weg, bis sie neu geladen wird.

Teile, die vor ihrer Elternnachricht eintreffen, nutzen einen begrenzten Wartebereich (128 Nachrichten-IDs / 1 MiB). Wenn wartender Inhalt freigegeben werden muss, bietet die TUI ein Neuladen aus der gespeicherten Historie an. Späte Ereignisse für verdrängte Nachrichten können verwaiste Teile nicht dauerhaft neu erzeugen.

Der Nachweiscache verwendet standardmäßig begrenzten Speicher (128 Einträge / 4 MiB serialisierte Werte je Instanz). RocksDB bleibt optional. Allein das Wechseln des Cache-Backends verringert keine Modell-Toolaufrufe. Siehe Nachweiscache.

Ausgabe von Hintergrundbefehlen

Ungelesene Hintergrundausgabe verwendet private flüchtige Dateien, statt mehr-megabytegroße JavaScript-Zeichenketten für jede beendete Shell zu behalten. Jede Datei ist ein UTF-8-Ring von 2 MiB. Älteste ungelesene Ausgabe jenseits dieser Grenze wird verworfen und gekennzeichnet. Bis zu 32 Ringdateien reservieren höchstens 64 MiB je Prozess. Wenn die Plattenplätze voll sind, kann die älteste beendete Spule verfallen. Der Besitz einer aktiven Shell wird nicht verdrängt. Lesevorgänge liefern die behaltene ungelesene Ausgabe schrittweise und geben ihren Plattenplatz frei.

Die Registrierung erlaubt 16 aktive Shells je Sitzung und 32 je Prozess und behält höchstens 16 beendete Datensätze je Sitzung beziehungsweise 64 je Prozess. Beendete Ausgabe verfällt nach 30 Minuten (geprüft beim Zugriff und etwa einmal je Minute). Auflistungen von Befehl und Beschreibung sind Vorschauen, begrenzt auf 8 KiB / 1 KiB. Der ausgeführte Befehl bleibt unverändert. Die Beobachter-Wiedergabe hat eigene Grenzen von 64 KiB und 128 Datensätzen je Shell, mit einem prozessweiten Bytebudget von 2 MiB. Unvollständige Wiedergabe wird gekennzeichnet.

bash_output meldet die Integrität der Ausgabe getrennt vom echten Exitstatus des Prozesses. Verworfene, verfallene oder unlesbare Ausgabe ist unvollständiger Prüfnachweis, auch wenn der Befehl mit Code null endete. Diese Hinweise bleiben sichtbar, wenn ein Ausgabefilter verwendet wird. Ein fehlender Datensatz kann bedeuten, dass er bereits verbraucht oder verdrängt wurde. Nicht verfügbare Ausgabe ist kein Beweis, dass eine Prüfung bestanden wurde.

Dateien verwenden ein privates, dem Prozess gehörendes temporäres Verzeichnis (0700) und Dateien 0600 auf POSIX. Lesevorgänge, das Entfernen der Sitzung, die Aufräumung der Aufbewahrung und ein normales Prozessende geben eigene Dateien frei. Die Spule ist kein absturzfester Sitzungsspeicher. Erzwungenes Beenden oder ein Absturz kann ein privates temporäres Verzeichnis zurücklassen. Automatisches Aufräumen über Prozesse hinweg ist nicht umgesetzt, daher beschreibt die Grenze von 64 MiB den aktuellen Prozess, nicht angesammelte Absturzreste. Fehler beim Aufräumen des Dateisystems werden gemeldet und geben die Quotenreservierung der fehlgeschlagenen Datei nicht frei. Synchrone begrenzte Datei-E/A vermeidet unbegrenzte Schreibwarteschlangen, kann auf einem langsamen temporären Dateisystem aber Latenz hinzufügen.

Eine Arbeitslast wählen

Verwenden Sie auf eingeschränkten Hosts zuerst einen Cloud-Anbieter, eine aktive Coding-Sitzung und ein kleines Repository. Führen Sie große Builds und zusätzliche Agentensitzungen nur aus, wenn der Rechner Spielraum hat. Lokale Inferenz braucht ein eigenes Budget für Gewichte, KV-Cache und Kontext sowie Laufzeitaufwand. Hardwarehinweise eines Cloud-Anbieters gelten dafür nicht.

Verwenden Sie die gepackte CLI für den gewöhnlichen Gebrauch. pnpm run dev ist ein Quellablauf für Mitwirkende mit anderen Kosten für Start und Modulladen. Prüfen Sie AX Code zusammen mit seinen Language-Server- und Build-Kindern in der Aktivitätsanzeige oder im Prozessmonitor der Plattform. Eine verringerte Cache-Grenze belegt keine feste Verringerung des physischen Speichers.

Die Speicheränderungen haben deterministische Tests für Aufbewahrung und semantische Gleichwertigkeit. Ein Lasttest hat sie nicht auf einem physischen Mac mit 8 GB qualifiziert. Der Niedrigmodus garantiert nicht, dass ein beliebiges Projekt auf einen Rechner mit 8 GB passt.