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

Erneuter Clienttest von AX Code und OpenCode: 19. September 2026

Status: Aktiv

Umfang: gemessener Diagnoseschnappschuss

Zuletzt geprüft: 2026-09-19

Verantwortlich: AX-Code-Laufzeit

Dieser erneute Test verwendet die AX-Code-Quelle 62895cf40a39e0ebd4afec0afa21044e9871aa0b, nach der lokalen Präfixkorrektur (42908b46a) und den Anbieterergänzungen MTPLX/oMLX. Alle sechs Kombinationen aus Client und Backend verwenden dasselbe Artefakt Qwen3.8 27B AXQ 6-bit mit aktiviertem MTP auf einem Apple M3 Max, 128 GiB. Die früheren Messungen bleiben historischer Nachweis. Ihre Modellpakete, Prompts, Tokengrenzen und Cachebedingungen unterscheiden sich. Das ist keine kontrollierte Vorher-nachher-Schätzung der Beschleunigung durch die Präfixkorrektur.

Gelieferte Ausgabegeschwindigkeit

Jede Zelle ist erste Aufgabe / wiederholte Aufgabe, in Token/s. Das sind einzelne Beobachtungen, keine Mediane. Die wiederholte Aufgabe startet eine neue CLI-Sitzung gegen denselben Backend-Prozess. Es wird nicht angenommen, dass sie einen Cache trifft. Laden und Warten auf die erste Ausgabe sind von dieser Rate ausgeschlossen.

Die Schätzung ist (completion tokens - 1) / (last output payload time - first output payload time). Spekulative Dekodierung kann mehrere Token in einer Nutzlast ausgeben, daher ist das eine Schätzung der Clientlieferung, nicht der native Decode-Zähler des Backends, und auch nicht der Durchsatz der vollständigen Anfrage.

Anfragezeit, Arbeitslast und Annahme

NR bedeutet, dass der Server keine Nutzung zwischengespeicherter Token gemeldet hat. Es behauptet nicht null. Die Zeit der ersten Nutzlast beginnt, wenn der lokale Aufzeichnungsproxy die Modellanfrage empfängt. Die CLI-Wandzeit umfasst außerdem Start und Abschluss des Clients. Die Aufgabe verlangt einen eigenständigen allgemeinen TypeScript-LRU-Cache mit get, set, delete und clear, ohne Toolausführung oder Dateibearbeitungen.

Die Annahmeprüfungen des Codes decken fehlende Schlüssel, Wertsuche, LRU-Verdrängung, behaltene Einträge, Aktualisierung der Aktualität, Löschen vorhandener und fehlender Schlüssel, Leeren, Identität von Objektschlüsseln und falsy Werte ab. Erzeugte Dateien erhalten außerdem eine strenge TypeScript-Prüfung. Diese begrenzten Prüfungen belegen keine breite Coding-Qualität. Alle Messzeilen behalten ihre erzeugte Ausgabe und das Validierungsergebnis. Fehlschläge werden nicht still durch schnellere Wiederholungen ersetzt.

MTP und Laufzeitbedingungen

• AX Engine 7.4.0: --mlx-mtp-policy required, verwaltete Flags der lokalen Laufzeit, n-Gramm-Beschleunigung und n-Gramm-Stapeln deaktiviert. Live Prozessmetriken zeigen ax_engine_mlx_mtp_model_policy_active=1 mit Zählern für Draft- und angenommene Token ungleich null. Der AX-Code-Schnappschuss folgt dem Aufwärmen. Der OpenCode-Schnappschuss folgt der ersten Aufgabe. Beide schließen das Aufwärmen ein und sind keine Annahmesummen je Aufgabe. Draft-Zählungen je Aufgabe von AX Code wurden nicht behalten.
• MTPLX 2.11.3 / MLX 0.32.2: ausdrückliches --generation-mode mtp --depth 3. Live Gesundheit meldet generation_mode: mtp und runtime_mode: Sustained MTP. Agentenumschreibungen und der SSD-Sitzungscache sind aus. Die native Sitzungsbank im Speicher bleibt aktiv. Native Aufwärmvorgänge von Start und Kernel werden behalten und von der Zeitmessung ausgeschlossen. Das unabhängige Lade-Aufwärmen wurde abgeschlossen. Der Status des Hintergrund-Aufwärmens bei der Zulassung bleibt in den Daten, statt als abgeschlossen angenommen zu werden.
• oMLX 0.6.4 / MLX 0.32.0: Lightning MTP aktiv, Tiefe 3, nur Text beim Modellladen, Nebenläufigkeit eins. Protokolle je Generation zeichnen Draft-Annahme und Ausführung je Tiefe für das Aufwärmen und beide Aufgaben auf. Der Upstream-Sidecar-Importer benennt 15 Tensoren um. Ihr dtype, ihre Form und ihre Nutzlastbytes bleiben identisch mit dem ursprünglichen AXQuant-Sidecar. Backbone-Gewichte sind unverändert.
• Artefakt: AutomatosX/AX-Qwen3.8-27B-MLX-AXQ-6bit-MTP, Revision 4d36d652c21590f6813495351c3baf5fca5b3831. Die Artefaktmetadaten erklären MTP-Tiefe 1. Die wiederkehrende Tiefe 3 folgt hier der gewählten Laufzeitrichtlinie oder dem ausdrücklichen Experiment und erweitert die Artefaktzertifizierung nicht. Das Paket Optimized-Speed wird in diesem erneuten Test nicht verwendet.
• Die OpenCode-Version ist 1.18.31. Alle Backends und Clients laufen seriell. Jedes Paar aus Client und Backend startet einen frischen Prozess und einen isolierten Aufgabencache, gefolgt von einem unabhängigen Modelllade-Aufwärmen, gedeckelt auf 64 Ausgabetoken. Modellladen und dieses Aufwärmen sind von der Tabelle ausgeschlossen. Die erste Aufgabe zahlt weiterhin kaltes Prefill. Die Lüftersteuerung bleibt auf ihrer Vorgabe, und Backbone-Dateien liegen auf SMB-Speicher.

Was übereinstimmt und was verschieden bleibt

Beide Clients erhalten dieselben eingefrorenen vollständigen Projektanweisungen, die Benutzeraufgabe und vier erlaubte Tools (glob, grep, read, skill). Die Quell-CLI von AX Code verwendet die tatsächlichen Anbieter-IDs ax-engine, mtplx und omlx. AX Engine verwendet seinen geprüften Loopback-Anbindungsvertrag mit einem getrennt gestarteten Backend, das verwaltete Flags trägt. Das misst nicht die verwaltete Oberfläche für Download und Start. OpenCode verwendet seinen OpenAI-kompatiblen Anbieterpfad. Die Projektkonfiguration ist deaktiviert, und jeder Client hat isolierte Einstellungen und Zustand. Native Clientprompts, Tool-Schemata und Sitzungsheader bleiben intakt. Daher unterscheiden sich gerenderte Tokenzahlen und das Cacheverhalten.

Ein lokaler Aufzeichnungsproxy richtet Temperatur 0,55, top-p 1, top-k/min-p 0, Wiederholungsstrafe 1, Presence- und Frequency-Strafen 0, Seed 0, Denken aus und eine Ausgabeobergrenze von 1.024 Token aus. Er erzwingt tool_choice: none für diese Aufgabe ohne Tools. Beide Clients sind für einen Kontext von 65.536 Token konfiguriert. Jede Zeile wird auf den vollständigen Anweisungsschnappschuss, die vier Toolnamen, gemeinsames Sampling, eine Anfrage, erfolgreichen CLI-Exit, natürlichen Stopp und keine Toolausführung geprüft.

Die längeren Prompts von AX Code können sowohl Prefill als auch Aufmerksamkeitsarbeit während der Erzeugung erhöhen. Verschiedene Antwortlängen, Inhalte, Laufzeitvorlagen, Kernel und Cache-Richtlinien verhindern, diese Tabellen als Benchmark des Clientaufwands bei gleichen Token zu behandeln. Aktives MTP garantiert nicht 30–40 Token/s für einen vollen Coding-Kontext. Um Clientaufwand oder eine Wirkung der Präfixkorrektur zu isolieren, spielen Sie identische serialisierte Anfragen oder Token-IDs mit gesteuerter Ausgabe und Cachebedingungen getrennt erneut ab.

Dieser Bericht ändert kein Verhalten von Cloud, privater GPU, CLI-Anbieter oder AX Trust. Siehe die Einrichtungsanleitung für lokale Laufzeiten für Verbindungsanweisungen und die bereinigten Messdaten für genaue Zeiten, Zählungen, Hashes, Validierungsergebnisse und MTP-Nachweise. Private Projektanweisungen, Modellantworten, lokale Pfade und Sitzungsheader bleiben lokal und werden nicht veröffentlicht. Folglich ist die vollständige Arbeitslast mit privatem Kontext aus dem öffentlichen Bericht allein nicht unabhängig reproduzierbar.