Das Rematch kam 1 Tag früh. Der gestrige M1 Ultra tuning article schloss mit einer Vorhersage: wenn ein MLX‑Release kompiliert Decodierungsgraphen landet, würde das Rematch gegen die 20.3 tok/s Lane einen Nachmittag und 1 Download dauern. Heute Morgen entdeckte ich einen neuen Laufzeit namens MTPLX und versprach, dass Zukunft als fertiges Produkt — native Multi‑Token‑Prediction spekulatives Decodieren auf Apple Silicon, ein Autotuner, der dein spezifisches Gerät misst, ein OpenAI‑ und Anthropic‑kompatibler Server, 1‑Klick‑Start für die Agent‑Harnesses, die wir tatsächlich nutzen, und Qwen3.8-27B als sein Flaggschiff‑Coding‑Modell. Ihre Seite sagt „deine Lieblingswerkzeuge, doppelt so schnell.“. Ich brachte es zu Kimi K3, meinem Kollaborateur bei der Tuning‑Abenteuer am Vortag, und wir setzten die Bedingungen gemeinsam: installiere es sauber auf dem Studio, lasse seinen eigenen Tuner sein Bestes geben, dann messe, was der Server tatsächlich serviert. Kimi führte die Remote‑Arbeit und die Zähler aus; ich hielt die Hausregeln und traf die Entscheidungen. So verlief der Tag tatsächlich.

MTPLX ist die Produktversion der Lane, die wir gemeinsam gebaut haben

Die Architektur verdient von vornherein Anerkennung, weil sie die richtige Idee ernsthaft umgesetzt hat. MTPLX entwirft mit den eigenen MTP-Köpfen des Modells – dem gleichen Mechanismus, den unsere Lane verwendet – und akzeptiert Entwürfe durch exakte Ablehnungsstichprobe, sodass die Stichprobe bei Temperatur 0.6 die gleiche Verteilung wie die gewöhnliche Decodierung erzeugt, nur schneller. Es gibt kein separates Entwurfsmodell, das Speicher verbraucht, die Entwurfsstärke wird pro Maschine gegen eine autoregressive Basislinie abgestimmt, und das Projekt weigert sich, unverifizierte MTP-Sidecars an beliebige Gewichte anzuhängen. Diese letzte Richtlinie war eine Disziplin, die Kimi und ich am Tag zuvor manuell anwenden mussten, als wir die abgeworfenen MTP-Tensoren von Qwen3.8 mit ihrem Stamm neu gepaart haben. Die Lane aus Teil eins war der offensichtliche Messstab: gleiches Studio, gleiche Modellfamilie, gemessen auf die gleiche Weise.

Die Installation bestand die 2-Quarantäneprüfungen, bevor sie ein Gewicht berührte

Die erste Prüfung war meine. Im März, in meinem autonomen Verfeinerungslabor, hatten wir einen Stolperstein erreicht, bei dem eine isolierte Python-Umgebung stillschweigend den Zugriff auf Apple's beschleunigte Bibliotheken verlor, und die Zahlen kamen erst langsam zurück. Bevor Kimi weiterging, bat ich um Beweis, dass der Stolperstein nicht zutraf. Ein 3-Linienprobe klärte es – nativer arm64-Interpreter, Metal verfügbar, GPU als Standardgerät. Apple's Metal-Pfad wird innerhalb des mlx-metal-Rads selbst ausgeliefert, sodass die Herkunft des Interpreters für den GPU-Zugriff irrelevant ist, und die Strecke aus Teil eins hatte bereits GPU-native Durchsatz durch die gleiche Isolationsform bewiesen. MTPLX's eigener Inspektor stimmte zu, bewertete beide seiner Qwen3.8-27B-Versionen als verifiziert-native mit allen 15 MTP-Tensoren vorhanden.
Die zweite Prüfung war Kimis, während des Downloads. MTPLX's pull-Befehl ignoriert die üblichen Hugging Face-Cache-Umgebungsvariablen, und der erste Versuch schrieb 20 GB Modell in das Home-Verzeichnis des Studios statt in das Datenvolumen, das die Hausregeln schützen. Kimi stoppte den Pull, entfernte nur das, was er erstellt hatte, und startete mit einem expliziten Cache-Verzeichnis. Fans blieben die ganze Zeit auf Apple's Kurve, was bei einer Maschine wichtig ist, die als Flugzeug-Simulator arbeitet.

Die lauteste Maschine an diesem Morgen war nicht die, die das Experiment ausführte

Während des Downloads stieg meine eigene Arbeitsstation stark an — die durchschnittliche Last stieg über 50 — und wir stoppten das Experiment, um eine wichtigere Frage zu beantworten: war das unser Verschulden? Es war nicht. Unsere Arbeit lief im Studio über kurzlebige SSH-Sitzungen; der lokale Fußabdruck bestand aus ein paar abgeschlossenen curl- und ssh-Prozessen. Der Sturm war eine Apple-Daemon-Welle — ein blockiertes Asset-Download, Indexierung, und ein Ausbruch aus einem Virtualisierungsprozess, der verschwand, bevor wir seinen Besitzer benennen konnten — plus die Entdeckung, dass die "mysteriösen respawning node processes", die ich tötete, 3 Entwicklungsüberwacher waren, die genau ihre Arbeit verrichteten, indem sie ihre Server neu starteten. Wir schrieben die ganze Sache in den maschinellen Schutzübergang und kehrten mit sauberem Gewissen zum Experiment zurück. Die Pause gehört in diese Geschichte, weil die Disziplin dieselbe ist, die die Benchmarks ausführen: kenne deinen eigenen Fußabdruck, bevor du eine Maschine beschuldigst.

Der Autotuner registrierte einen 2.20x Ausbruch

Das Tuning-Ritual von MTPLX ist ehrliche Technik: es führt das echte Modell auf Ihrer Hardware bei jeder Entwurfsstufe aus, behält die autoregressive Dekodierung als Basis bei und speichert eine Tiefe nur, wenn sie diese Basis übertrifft. Auf dem M1 Ultra produzierte es AR 11.4, Tiefe 1 bei 9.2, Tiefe 2 bei 25.1, Tiefe 3 bei 20.7 tok/s – Tiefe 2 wurde zum Sieger gekrönt bei 2.20x, gespeichert für alle zukünftigen Starts.
Das 25.1 ist eine echte Messung eines echten Motors, 24% über unserer Spur's 20.3 Servierrate. Wenn der Server es reproduziert hätte, wäre dieser Artikel ein Migrationsleitfaden.

Der Server lieferte 16.5, und die Standardeinstellungen verbrachten Tokens aus dem Blickfeld

Der Servier-Bench verwendete dieselben Eingabeaufforderungen, Temperatur 0, und die Echtzeit-Abrechnung wie die Basislinie der Spur. Der erste Lauf kam bei 14.7 tok/s zurück, und die Antwort-Metadaten zeigten 2 Standardeinstellungen, die gegen die Messung arbeiten:
  • Der Modus „Reasoning“ ist standardmäßig aktiviert, und Qwen3.8 denkt, bevor es antwortet. Bei einer trivialen Zählung bis 10 wurden 44 der 64 generierten Tokens versteckt, weil der Client sie nie anzeigt. Reale Arbeitslasten zahlen für diese Tokens, daher ist die Wandrate bereits inklusive — aber die Eingabeaufforderungen des Tuners trugen keine solche Steuerung.
  • Das Turbo-Laufzeitprofil, mit seinen kompilierten Verify-Kernen, ist eine Startregel der nativen Mac-App. Ein Terminal mtplx serve löst stattdessen das Sustained-Profil auf, sodass der Befehlszeilenpfad die schnellen Kerne nie sieht, es sei denn, Sie fragen danach.
Das Festlegen von Turbo, Tiefe 2, und das Abschalten des Reasoning hob die FP16-Build auf 16.5 tok/s Wand — die beste MTPLX produzierte den ganzen Tag. Die 4-bit Optimized-Speed-Build, die das Projekt für das Codieren empfiehlt, lieferte 15.5. Beide Builds liegen bei 20.4 GB auf der Festplatte gegenüber unserer Spur's 15 GB, und auf einer bandbreitenbeschränkten Maschine zahlt jeder Token, um diese extra 5 GB zu streamen.
Serving rate on identical prompts (tok/s wall, M1 Ultra, Qwen3.8-27B)
Chart data
tokens per second
our lane (part one)20.3
MTPLX tune claim (D2)25.1
MTPLX FP16 turbo D216.5
MTPLX 4-bit turbo D215.5
MTPLX defaults14.7

Der Tuner und der Server messen 2 verschiedene Maschinen

Die nützlichste Erkenntnis des Tages erklärt die Lücke zwischen 25.1 und 16.5. MTPLX's eigener Server protokolliert bei Start ein Aufwärm-Ladder, und dieses Ladder meldet 20-24 tok/s vom Engine — innerhalb desselben Prozesses, der dann 16,5 über HTTP liefert. Der Engine ist schnell und der Transport wird belastet. Zwischen der Decode-Schleife und dem Client befindet sich die HTTP Schicht, die pro Anfrage Session-Bank-Buchhaltung (ein 160 MB Snapshot-Write erschien in den Statistiken der ersten Anfrage), und die Denkmaschine, und jeder Token überschreitet diese Grenze. Auf M4 und M5 Chips, wo die veröffentlichten 1.6-2.24x Zahlen gemessen wurden, absorbieren schnellere CPU und Fabric die Überschreitung. Der M1 Ultra Engine hält Schritt; sein Serving-Pfad tut es nicht.
Diagram source
graph LR
    subgraph Tuner-Pfad
        A[Echtmodell] --> B[Entwurfs-Tiefen D1-D3]
        B --> C[Nur-Dekodieren-Zeitgeber  
25.1 tok/s]
    end
    subgraph Serving-Pfad
        D[HTTP Anfrage] --> E[Session-Bank  
+ Denk-Voreinstellungen]
        E --> F[Derselbe Engine  
Ladder zeigt 20-24]
        F --> G[Pro-Token-Grenze  
16.5 tok/s Wand]
    end

    style C fill:transparent,stroke:#10B981,stroke-width:2px
    style G fill:transparent,stroke:#F59E0B,stroke-width:2px
Dies ist die Lektion von Teil eins, die einen neuen Kostüm trägt. llama.cpp's Community-Aussagen von 25-32 tok/s überlebten den Kontakt mit diesem Chip nicht, und MTPLX's Tuner 25.1 überlebte seinen eigenen Server. Die dauerhafte Regel schärft sich: eine Servierrate wird am HTTP-Grenzwert gemessen, wobei die Produktionsstandards sichtbar sind, niemals im Tuner. Das ist benchmark-driven development angewendet, eine Ebene höher im Stack.

Der Herausforderer verließ 38 GB leichter, und der Wächter blieb zurück

Ich gab Kimi 1 nicht verhandelbar, bevor das Experiment begann: alles, was in diesem Studio läuft, muss sich selbst stoppen, wenn es untätig ist, weil der abendliche Job der Maschine ein Flugsimulator ist. MTPLX liefert keinen Idle-Timeout für seinen Chat-Server, also baute Kimi den Wächter in ein kleines Wrapper-Skript ein — nur Loopback-Bindung, Lüfter nach Apple's Richtlinie, und ein Verbindungswächter, der den Server nach 10 Minuten ohne Clients stoppt. Es bestand seinen Live-Feuer-Übung, zerschlug eine Testinstanz am 60-Sekunden-Marker und ließ den Port sauber freigeben. Der Wrapper und die virtuelle Umgebung bleiben auf der Maschine, sodass der Retest 1 Download entfernt ist, wenn ein MTPLX-Release den M1-Generation-Bedienpfad nutzt oder ein passendes MTP-Artifact näher an 15 GB liefert.
Die Gewichte selbst blieben nicht. Sobald das Urteil klar war, gingen wir sorgfältig die Aufräumarbeiten durch — sowohl MTPLX-Modellverzeichnisse, 38 GB über die FP16 und 4-Bit-Builds, gelöscht nach Bestätigung, dass kein Prozess sie hielt, und gaben das Volumen exakt wieder auf seinen vor-Experiment-Freiraum zurück. Die Löschung bleibt Teil des Workflows: jeder Herausforderer, der verliert, lässt den Datenträger am selben Tag, was das nächste Experiment ehrlich hält.

Was die Rematch zur Checkliste hinzufügte

Die Spur aus Teil eins hat sich nie bewegt. Sie bediente den Morgen bei 20.3 tok/s, sie bediente den Abend bei 20.3 tok/s, und sie hält jetzt ihren Slot gegen 3 Herausforderer statt gegen 2 – immer noch eine experimentelle Spur, 1 Download entfernt von ihrer nächsten Rematch. Die Checkliste aus Teil eins gewinnt 3 Einträge:
  • Die Nummer eines Tuners ist die Decke des Motors, und der Servicepfad entscheidet, wie viel davon du behältst. Messe an der Grenze, die deine Clients tatsächlich überschreiten.
  • Standardwerte sind Teil des Benchmarks. Denkmodi, Laufzeitprofile und Sitzungs-Caches verbrauchen alle Tokens oder Zeit, und ein faires Spiel bindet sie explizit auf beiden Seiten.
  • Der Datenträger ist ein Hypothesenbudget. 2 Herausforderer baut bei 20.4 GB jedes gekaufte 1 Nachmittag der Gewissheit, und Gewissheit ist günstiger, wenn die Bytes planmäßig verlassen.
Die befriedigende Symmetrie des Paares ist, dass Teil eins damit endete, dieses genaue Experiment zu queueen, und das Experiment kam als Produkt mit echter Handwerkskunst – exakte Stichprobe, pro-Maschine-Tuning, ehrliche Verifizierung. Das Handwerk war echt und der Verlust war echt, und beide Erkenntnisse kamen aus dem gleichen Messtag, CPU-Sturm und allem. Ein Abenteuer mit einem Scoreboard ist die beste Art, und dieses hatte Kimi K3, der jeden Zähler neben mir las – die gleiche zusammengesetzte Rendite, die ich erhalte, wenn ich lokale KI-Gewinne als Infrastruktur behandle. Die Spur behält ihren Slot, der Datenträger ist schlank, die Checkliste ist länger, und der nächste Herausforderer ist bereits willkommen, es zu versuchen.