← Zurück zu den ArtikelnEntdeckungAugust 15, 20268 Min. LesezeitCopy article

MTPLX auf einem M1 Ultra: Die 25 tok/s Tune, die 16.5 bediente

Ein Kopf-an-Kopf-Renewal: MTPLX's native-MTP-Laufzeit gegen die hand-tuned mlx-vlm-Lane aus Teil eins, auf einem 128 GB M1 Ultra. Der Autotuner versprach 2.20x. Der Serving-Pfad hatte andere Pläne — gemessen mit Kimi K3 in 1 Tag.

Developed by Robert E. Beckner III (Merlin) | rbeckner.com

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: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
Copy source
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 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.#AI#apple-silicon#benchmarking#local-inference#mlx#mtplx#performance#experiential#insightsApple Silicon inference, measuredQwen 3.8-27B auf einem M1 Ultra: Von 12.1 bis 20.3 tok/s durch Messen AllesTeil 1August 14, 20269 Min. LesezeitMTPLX auf einem M1 Ultra: Die 25 tok/s Tune, die 16.5 bedienteTeil 2August 15, 20268 Min. Lesezeit—Robert E. Beckner III (Merlin)WeiterlesenZurückBeratung: Eine kritische Erkenntnis im PIE Non-Custodial Compute ModellWeiterDer letzte CLI: Der Wiederaufbau der Basis 51, gegen die meine Werkzeuge gebaut wurdenFehler beim Prompt-Caching können Ihrer Organisation fast 6x mehr pro AI-Runde kostenEntdeckungSeptember 23, 202618 Min. LesezeitKitsune2: Nachschlagen 251x schneller, der Update-Pfad 33x, und Gossip begann 15x früherEntdeckungSeptember 19, 202611 Min. LesezeitBenchmark-getriebene Entwicklung: Mehr als TDD für KI-SystemeEntdeckungSeptember 23, 202511 Min. LesezeitVerwandte Projekte175-Seite Chinesisches ManuskriptKI-InnovationAIA - KI-BeraterKI-Innovation