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

Messungen der lokalen Inferenz: 19. September 2026

Status: Aktiv

Geltungsbereich: gemessener Diagnose-Snapshot

Zuletzt geprüft: 2026-09-19

Verantwortlich: ax-code runtime

Die vollständige Client-Matrix mit sechs Kombinationen nach der Korrektur des lokalen Präfixes steht in der neuen erneuten Prüfung von AX Code und OpenCode. Die Client-Geschwindigkeiten unten bleiben historische Beobachtungen unter ihren ursprünglichen Bedingungen.

Diese Messungen untersuchen die lokale Antwortlatenz und die Decode-Geschwindigkeit auf einem Apple M3 Max mit 128 GiB einheitlichem Speicher. Sie sind keine Hardware-Qualifikation, keine Bewertung der Modellqualität und kein Versprechen von 30–40 tokens/s bei beliebigen Kontextlängen. Die Verbindungsanleitung für MTPLX und oMLX steht im Leitfaden zur lokalen Laufzeit.

Bedingungen und Zeitmessung

• Quelle von AX Code auf Basis von v7.19.3; OpenCode 1.18.31; AX Engine 7.4.0; MTPLX 2.11.3; oMLX 0.6.4 (1d7826185c5b5b69b38b27cbe57d7597b7551fd7, isolierte Quellinstallation).
• Jeweils ein Inferenz-Backend. Voreingestellte Lüftersteuerung; keine Aussage zu maximaler Lüfterdrehzahl. Modelldateien lagen auf SMB-Speicher. Der Lauf von MTPLX mit exaktem Artefakt legte nur den MTP-Sidecar auf SSD, mit geprüftem SHA-256.
• Wiedergaben mit exaktem Artefakt verwendeten AutomatosX/AX-Qwen3.8-27B-MLX-AXQ-6bit-MTP, Revision 4d36d652c21590f6813495351c3baf5fca5b3831. Die getrennten Client-Läufe MTPLX Optimized-Speed verwendeten Youssofal/Qwen3.8-27B-MTPLX-Optimized-Speed. Das sind unterschiedliche Modellpakete, auch wenn ihre Dateigrößen insgesamt ähnlich sind; ihre Raten können eine Beschleunigung allein der Laufzeit nicht isolieren.
• Gemeinsame Wiedergabeeinstellungen: temperature 0.55, top-p 1, top-k 0, seed 0, bis zu 256 erzeugte Tokens. AX Engine und MTPLX verwendeten die aktive MTP-Tiefe 3. Laufzeitkerne und spekulative Sampler unterscheiden sich. Die Metadaten des Artefakts erklären Tiefe 1; Tiefe 3 ist hier ein ausdrückliches Laufzeitexperiment, keine Erweiterung der Zertifizierung des Artefakts und keine neue Voreinstellungsempfehlung. AX Engine ignorierte EOS für seine native Wiedergabe mit fester Ausgabe; MTPLX und oMLX folgen ihren eigenen Stoppregeln.
• Die native Decode-Rate verwendet die Decode-Zähler des Backends. Die gelieferte Rate ist (reported completion tokens - 1) / (last output payload time - first output payload time); leere Ereignisse und Keepalives zählen nicht als Ausgabe. Diese Grenzen sind nicht identisch.
• Die Latenz bis zur ersten Nutzlast umfasst die Anfragevorbereitung auf dem Server, Cache-Wiederherstellung oder Prefill und jede Pufferung vor der Ausgabe. Die Gesamtzahl der Tokens geteilt durch die gesamte Anfrage ist ein anderes Durchsatzmaß. Stöße von Werkzeugaufrufen eignen sich nicht für Decode-Schätzungen von der ersten bis zur letzten Nutzlast.

Zum Beispiel maß dieselbe Wiedergabe von MTPLX mit 30k Eingabe 13.99 native Decode-tokens/s, aber nur 1.13 tokens/s über die vollständige Anfrage, weil kaltes Prefill etwa 209 Sekunden verbrauchte. Eine niedrige Zahl für die gesamte Anfrage allein belegt keinen Ausfall der Decode-Engine.

Wiedergabe mit exakten Gewichten für AX Engine und MTPLX

Jedes Paar erhielt dieselbe ganzzahlige Folge von Eingabe-Tokens und gab 256 Tokens aus. Die Werte unten sind einzelne Beobachtungen; die Identitäten der erzeugten Tokens können sich trotz gemeinsamem Seed unterscheiden.

MTPLX verwendete für dieses Artefakt sein Profil Sustained. Die Anfrage von AX Engine mit 30k war warm, während MTPLX kalt war, daher können ihre Zeiten bis zum ersten Token kein Verhältnis der Prefill-Geschwindigkeit belegen. Die Eingabe mit 30k enthält eine historische Anweisung zur Schrittgrenze und erzeugt Diagnoseprosa; sie ist keine Annahme einer Coding-Aufgabe. Die Wiedergabe von MTPLX mit 18,643 Tokens meldete nach 256 Tokens stop statt length.

Der kurze Prompt zeigt ähnliche Decode-Raten. Diese Läufe belegen nicht, dass eines der Backends allgemein schneller ist, oder dass ein Wechsel von AX Code zu einem anderen Backend eine feste Beschleunigung garantiert.

AX Code und OpenCode auf MTPLX Optimized-Speed

Beide Clients erhielten dieselbe Benutzeraufgabe, vollständige Projektanweisungen und vier erlaubte Werkzeugschemata. Die Aufgabe verlangte einen TypeScript-LRU-Cache, ohne Werkzeuge auszuführen. Clientspezifische Prompts blieben erhalten; ein aufzeichnender Proxy glich das Sampling ab, deaktivierte das Denken und verwendete eine Obergrenze von 1024 Tokens für Anfrage und Server. Die folgenden Antworten schlossen normal ab:

Diese Messungen liegen vor der Korrektur des lokalen Präfixes von AX Code (42908b46a). AX Code sandte mehr Kontext und erzeugte anderen Code. Das ist kein Vergleich des Client-Aufwands bei gleicher Tokenzahl und kein Vorher-nachher-Ergebnis. Nur die automatisch erfasste Verzeichniskarte in einer getrennten Wiedergabe zu entfernen senkte die Eingabe auf 30,717, verbesserte das beobachtete Decode aber nur um etwa 2 %; das Entfernen der Verzeichniskarte wurde nicht übernommen.

Eine getrennte Adaptermatrix von AX Engine beobachtete AX Code bei 9.44–11.56 gelieferten t/s mit 33,225 Eingabe- Tokens und OpenCode bei 12.82–13.00 mit 17,290. Promptlängen, Ausgabeinhalt, Cache-Zustand und die Ausgabeobergrenze von 256 Tokens unterscheiden sich von der Tabelle der vollständigen Antworten oben; fassen Sie das nicht zu einem Beschleunigungsverhältnis eines Backends zusammen.

oMLX

Der Test von oMLX verwendet das exakte AXQ-Artefakt und eine isolierte Installation mit MLX 0.32.0. Alle fünf Prüfungen des Imports nativer Kerne, einschließlich qwen35_prefill und decode_fast, bestanden. Nur Text zu laden ist ausdrücklich gewählt, das Kontextfenster ist 65,536, und die Nebenläufigkeit ist eins.

Der erste Versuch mit Lightning MTP lieferte HTTP 409, weil der Test den von oMLX verlangten Schritt MTP-Sidecar importieren übersprang. Das war ein Einrichtungsfehler, keine fehlende Unterstützung für AXQuant. AXQuant stellte den kanonischen Vertrag qwen3-next-mtp bereits bereit; die aktuelle Hub-Revision b0784088d4026ca569c5653e6e6243c501ef5fa9 enthält außerdem axquant_omlx_compat.json mit 15 MTP-Tensoren. Der ursprüngliche Wiedergabe-Snapshot liegt vor dieser Anmerkung.

Die Basis ohne MTP schloss mit dem ursprünglichen Artefakt ab:

Das sind Ergebnisse ohne MTP und dürfen nicht mit Laufzeiten mit MTP als Nachweis eines inhärenten Geschwindigkeitsunterschieds der Backends verglichen werden. Rundläufe des Tokenizers und die Prompt-Zählung des Servers entsprachen den ganzzahligen Eingaben der anderen Wiedergabe-Backends.

Der korrigierte MTP-Lauf verwendet den eigenen Importeur von oMLX auf einer getrennten beschreibbaren Kopie. Die Backbone-Shards sind unverändert. Der Importeur fügt language_model. zu den 15 Namen der Sidecar-Tensoren hinzu; dtype, Form und Nutzlast-Hash jedes Tensors wurden vor und nach dem Import als gleich geprüft. Der Hash der importierten Datei unterscheidet sich daher, weil sich der Kopf geändert hat. Die ursprünglichen Metadaten und der gemeinsame Modell-Snapshot bleiben unversehrt. Die MTP-Tiefe 3 ist ausdrücklich gewählt, und Zähler für Entwurf und Annahme je Tiefe bestätigen die tatsächliche Ausführung.

Das kurze Ergebnis bestätigt, dass dieses AXQuant-Paket nach dem Import mit oMLX Lightning MTP funktioniert. Decode bei langem Kontext bleibt trotz aktivem MTP langsamer. Unterschiedlicher erzeugter Text, Laufzeitversionen, Kerne und spekulative Richtlinien verhindern, alle Unterschiede zwischen Laufzeiten AX Code zuzuschreiben.

Annahme des Coding-Ablaufs und Ausschlüsse

Nach der Korrektur des lokalen Präfixes schloss AX Code eine isolierte nur lesende Aufgabe sowohl auf AX Engine als auch auf MTPLX ab: ein Verzeichnis und zwei TypeScript-Dateien lesen, die Ausnahme bei voller Warteschlange erklären, die Kapazität 7 erkennen und eine Markierung zurückgeben, die nur in der zweiten Datei verfügbar ist. Beide endeten erfolgreich und bewahrten die Bytes des Fixtures. Spätere Aufrufe von AX Engine verwendeten 11,264 Eingabe-Tokens wieder; MTPLX verwendete 11,264–12,032 wieder. Die ersten Anfragekörper waren identisch, aber Laufzeitvorlagen erzeugten unterschiedliche Tokenzahlen. Das prüft den Werkzeugablauf und die beobachtete Wiederverwendung des Cache, nicht eine feste Beschleunigung durch den Patch.

Die neuen Anbieterkennungen bestanden außerdem die Live-Annahme aus der Quell-CLI: omlx mit dem importierten AXQ- Paket und ausdrücklichem tool_call: true sowie mtplx mit dem Paket Optimized-Speed und ohne konfigurierte Modell- Einträge. MTPLX ermittelte sein Chat-Modell und die Werkzeugfähigkeit aus der nativen Modellliste. Beide Läufe schlossen zwei erfolgreiche Dateilesungen ab und lieferten die erwartete Ausnahme, die Kapazität und die nur in der Datei vorhandene Markierung, ohne die Bytes des Fixtures zu ändern. Das anfängliche Präfix aus System und Benutzer blieb über die drei Anfragen jedes Laufs identisch. oMLX verwendete 8,192 Tokens wieder; MTPLX verwendete 11,829 und 12,047 Tokens wieder. Das sind funktionale Prüfungen, keine angeglichenen Leistungsläufe; eine Beschleunigung der Wandzeit zwischen Laufzeiten wird nicht behauptet.

Frühere Antworten von AX Code mit Obergrenze 256 Tokens waren abgeschnitten und gingen in die Wiederherstellung; ihre Raten wiederholter Ausgabe um 51–58 t/s sind von Aussagen zur frischen Erzeugung ausgeschlossen. Erste Läufe mit ungleichen Projekt- anweisungen oder Werkzeugberechtigungen sind ebenfalls ausgeschlossen. Ollama und LM Studio wurden nur zur Konstruktion der Anfrage geprüft; für sie wird kein Ergebnis zur Erzeugungsrate behauptet.

Der allgemeine Prompt mit 62 Tokens ist öffentlich als genaue Completion-Anfrage an oMLX. Vom Stamm des Checkouts, nach dem Import des Sidecars, dem Aktivieren von MTP und dem Aufwärmen des Modells, kann er gesendet werden mit:

curl --no-buffer http://localhost:8000/v1/completions \
  -H 'Content-Type: application/json' \
  --data-binary @docs/data/local-inference-short-request.json

Ändern Sie die Modellkennung der Anfrage in die Kennung, die Ihr Server bereitstellt. Die Datei enthält die dargestellte Vorlage; verwenden Sie den Completions-Endpunkt, damit eine Chat-Vorlage nicht ein zweites Mal angewendet wird. Bestätigen Sie 62 Prompt-Tokens und behalten Sie das letzte Nutzungsereignis. Kaltes Laden des Modells und das Aufwärmen müssen getrennt berichtet werden.

Private Projektanweisungen, Sitzungsprompts, lokale Pfade und Authentifizierungsdetails werden nicht veröffentlicht. Die bereinigten Messdaten enthalten Zählungen, Zeiten, die Identität der Laufzeit und Eingabe-Hashes, nicht den Prompt-Text. Die vollständige Wiedergabe mit privatem Kontext ist daher keine eigenständig öffentlich reproduzierbare Arbeitslast. Für einen neuen Vergleich verwenden Sie dieselbe Modellrevision, denselben Tokenizer und dieselbe Vorlage, dieselben Eingabe-Kennungen, dieselben Ausgabe- und Stoppregeln, dasselbe Sampling, denselben MTP-Modus, denselben Cache-Zustand, dieselbe Hardware und serielle Ausführung; berichten Sie den Erfolg der vollständigen Aufgabe getrennt.

Verträge upstream: Leitfaden zu Server und Modell von MTPLX, oMLX 0.6.4. Deren veröffentlichte Benchmarks verwenden andere Hardware und Arbeitslasten und ersetzen die Messungen hier nicht.