MTPLX su un M1 Ultra: Il 25 tok/s Tune Che Ha Servito 16.5
Una rivincita testa a testa: runtime nativo MTP di MTPLX contro la corsia mlx-vlm a mano di parte uno, su un 128 GB M1 Ultra. L'autotuner ha promesso 2.20x. Il percorso di serving aveva altri piani — misurato con Kimi K3 in 1 day.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
La rivincita è arrivata 1 day early. L'articolo di tuning di ieri su M1 Ultra tuning article si è chiuso con una previsione: quando una release MLX compila grafici di decodifica, la rivincita contro la corsia a 20.3 tok/s richiederà un pomeriggio e 1 download. Questa mattina ho notato un nuovo runtime chiamato MTPLX che promette quel futuro come prodotto finito — decodifica speculativa multi-token nativa su Apple Silicon, un autotuner che misura la tua macchina specifica, un server compatibile con OpenAI e Anthropic, avviamenti con un click per le harness degli agenti che usiamo davvero, e Qwen3.8-27B come modello di codifica di punta. Il loro sito dice "i tuoi strumenti preferiti, al doppio della velocità." L'ho portato a Kimi K3, il mio collaboratore nell'avventura di tuning il giorno prima, e abbiamo fissato i termini insieme: installalo pulito sul Studio, lascia che il suo tuner faccia il suo miglior caso, poi misura ciò che il server serve effettivamente. Kimi ha gestito il lavoro remoto e i contatori; io ho mantenuto le regole della casa e fatto le chiamate. Ecco come è andata davvero la giornata.
MTPLX è la versione prodotto della corsa che abbiamo costruito insieme#
L'architettura merita credito fin dall'inizio, perché è l'idea giusta eseguita seriamente. MTPLX redige con le proprie teste MTP del modello — lo stesso meccanismo che utilizziamo nella nostra corsa — e accetta bozze tramite campionamento di rigetto esatto, così il campionamento a temperatura 0.6 produce la stessa distribuzione della decodifica ordinaria, solo più veloce. Non c'è un modello di bozza separato che consuma memoria, la profondità della bozza è regolata per macchina contro una baseline autoregressiva, e il progetto si rifiuta di allegare sidecar MTP non verificati a pesi arbitrari. Quei l'ultima politica è una disciplina che Kimi e io abbiamo dovuto applicare manualmente il giorno prima, quando abbiamo riparato i tensori MTP di Qwen3.8's scartati con il loro tronco. La corsa dalla parte uno era il bastone di misura ovvio: stesso Studio, stessa famiglia di modelli, misurata allo stesso modo.
L'installazione ha superato i controlli di quarantena 2 prima di toccare un peso#
Il primo controllo era mio. A marzo, nel mio laboratorio di raffinazione autonoma, avevamo incontrato un trappola dove un ambiente Python isolato ha perso silenziosamente l'accesso alle librerie accelerate di Apple, e i numeri tornavano solo lentamente. Prima che Kimi andasse oltre, ho chiesto prova che la trappola non si applicasse. Una sonda a riga 3 lo ha risolto — interprete arm nativo64, Metal disponibile, GPU come dispositivo predefinito. Il percorso Metal di Apple è incluso nella ruota stessa mlx-metal, quindi l'origine dell'interprete è irrilevante per l'accesso alla GPU, e la corsia della parte uno aveva già dimostrato il throughput nativo GPU tramite la stessa forma di isolamento. L'ispettore di MTPLX ha confermato, valutando entrambe le sue versioni Qwen3.8-27B verificate-native con tutti i tensori MTP presenti15.
Il secondo controllo era quello di Kimi, a metà download. Il comando pull di MTPLX ignora le variabili d'ambiente della cache di Hugging Face, e il primo tentativo scriveva 20 GB di modello nella directory home dello Studio invece del volume dati le cui regole proteggono la casa. Kimi ha annullato il pull, ha rimosso solo ciò che aveva creato, e ha riavviato con una directory cache esplicita. I fan sono rimasti sulla curva di Apple per tutto il giorno, il che conta su una macchina che fa da simulatore di volo.
La macchina più rumorosa quella mattina non era quella che eseguiva l'esperimento#
A metà download, il mio stesso workstation ha iniziato a picchiare duramente — media di carico superando 50 — e abbiamo interrotto l'esperimento per rispondere a una domanda più importante: era questo nostro lavoro? Non lo era. Il nostro lavoro è girato sul Studio in sessioni SSH a breve termine; l'impronta locale era pochi processi curl e ssh terminati. La tempesta era un'onda di demoni Apple — un download di asset bloccato, indicizzazione, e un'esplosione da un processo di virtualizzazione che scomparve prima che potessimo nominare il suo proprietario — più la scoperta che i "processi di nodo di respawn misteriosi" che avevo ucciso erano 3 supervisori di sviluppo che facevano esattamente il loro lavoro riavviando i loro server. Abbiamo scritto tutto nella consegna di protezione della macchina e siamo tornati all'esperimento con una coscienza pulita. La pausa appartiene a questa storia perché la disciplina è la stessa su cui girano i benchmark: conosci la tua impronta prima di incolpare una macchina.
Il rituale di tuning di MTPLX è un'ingegneria onesta: esegue il modello reale sul tuo hardware a ogni profondità di bozza, mantiene il decoding autoregressivo come baseline, e salva una profondità solo se supera quella baseline. Sul M1 Ultra ha prodotto AR 11.4, profondità 1 a 9.2, profondità 2 a 25.1, profondità 3 a 20.7 tok/s — profondità 2 ha coronato il vincitore a 2.20x, salvata per tutti i futuri lanci.
Quello 25.1 è una vera misurazione di un vero motore, 24% sopra il tasso di servizio del nostro lane 20.3. Se il server lo avesse riprodotto, questo articolo sarebbe una guida di migrazione.
Il server ha servito 16.5, e le impostazioni predefinite spendevano token fuori vista#
Il banco di servizio ha usato gli stessi prompt, temperatura 0, e contabilità in tempo reale come baseline del lane. La prima esecuzione è tornata a 14.7 tok/s, e i metadati della risposta hanno mostrato le impostazioni predefinite 2 che lavorano contro la misurazione:
La modalità di ragionamento è predefinita su, e Qwen3.8 pensa prima di rispondere. Su un prompt triviale di conteggio a 10, 44 dei token generati 64 erano ragionamento nascosto che il client non mostra mai. I carichi di lavoro reali pagano per quei token, quindi il tasso orario li include già — ma i prompt del tuner non avevano tale tassa.
Il profilo di runtime Turbo, con i suoi kernel di verifica compilati, è una regola di lancio dell'app Mac nativa. Un terminale mtplx serve si risolve al profilo Sustained invece, quindi il percorso da riga di comando non vede i kernel veloci a meno che non lo chiedi.
Bloccando Turbo, profondità 2, e ragionamento spento ha sollevato la build FP16 a 16.5 tok/s wall — il miglior MTPLX ha prodotto tutto il giorno. La build Optimized-Speed a 4 bit, quella che il progetto consiglia per la codifica, ha servito 15.5. Entrambe le build occupano 20.4 GB su disco contro i nostri lane 15 GB, e su una macchina limitata dalla larghezza di banda ogni token paga per trasmettere quei extra 5 GB.
Serving rate on identical prompts (tok/s wall, M1 Ultra, Qwen3.8-27B)Chart data
Il risultato più utile della giornata spiega il divario tra 25.1 e 16.5. I log del server di MTPLX registrano una scala di warmup all'avvio, e quella scala riporta 20-24 tok/s dal motore — all'interno dello stesso processo che poi serve 16.5 su HTTP. Il motore è veloce e il trasporto è tassato. Tra il ciclo di decodifica e il client si trovano lo strato HTTP, la contabilità di session-bank per richiesta (un snapshot di 160 MB è apparso nelle statistiche della prima richiesta), e la macchina di ragionamento, e ogni token attraversa quel confine. Su chip M4 e M5, dove le cifre pubblicate 1.6-2.24x del progetto sono state misurate, CPU più veloce e fabric assorbono l'attraversamento. Il motore del M1 Ultra mantiene il passo; il suo percorso di servizio no.
Diagram source
graph LR
subgraph Percorso del tuner
A[Modello reale] --> B[Profondità di bozza D1-D3]
B --> C[Timer solo decodifica
25.1 tok/s]
end
subgraph Percorso di servizio
D[Richiesta HTTP] --> E[Session bank
+ impostazioni predefinite di ragionamento]
E --> F[Stessa scala del motore
mostra 20-24]
F --> G[Confine per token
16.5 tok/s wall]
end
style C fill:transparent,stroke:#10B981,stroke-width:2px
style G fill:transparent,stroke:#F59E0B,stroke-width:2px
Questa è la lezione della parte uno che indossa un nuovo costume. Le affermazioni della community di llama.cpp di 25-32 tok/s non sono sopravvissute al contatto con questo chip, e il tuner di MTPLX 25.1 non è sopravvissuto al suo stesso server. La regola duratura si affina: un tasso di servizio è misurato al confine HTTP con i valori predefiniti di produzione visibili, mai all'interno del tuner. Ciò è sviluppo guidato da benchmark applicato a un livello più alto dello stack.
Il challenger è uscito con 38 GB più leggero, e il watchdog è rimasto indietro#
Ho dato a Kimi 1 non negoziabile prima che l’esperimento iniziasse: tutto ciò che gira su quel Studio deve fermarsi da solo quando è inattivo, perché il lavoro serale della macchina è un simulatore di volo. MTPLX non spedisce un timeout di inattività per il suo server chat, quindi Kimi ha inserito il watchdog in un piccolo script wrapper — binding solo loopback, ventole sulla politica di Apple, e un watcher di connessione che ferma il server dopo 10 minuti senza client. Ha superato il suo drill di fuoco live, abbattendo un’istanza di test al segno del secondo 60 e rilasciando la porta in modo pulito. Il wrapper e l’ambiente virtuale rimangono sulla macchina, quindi il retest è a 1 download di distanza quando una release MTPLX funziona il percorso di servizio M1‑generation o spedisce un artefatto MTP corrispondente più vicino a 15 GB.
I pesi stessi non sono rimasti. Una volta chiaro il verdetto, abbiamo passato la pulizia con cura — entrambi i directory del modello MTPLX, 38 GB attraverso FP16 e build a 4‑bit, cancellati dopo aver confermato che nessun processo li deteneva, restituendo il volume allo spazio libero pre‑esperimento esattamente. La cancellazione rimane parte del flusso di lavoro: ogni challenger che perde lascia il disco lo stesso giorno, il che mantiene l’esperimento successivo onesto.
La corsia della prima parte non si è mai spostata. Ha servito la mattina a 20.3 tok/s, ha servito la sera a 20.3 tok/s, e ora detiene il suo slot contro i contendenti 3 invece di 2 — ancora una corsia sperimentale, 1 download da lontano dal suo prossimo rematch. La checklist della prima parte guadagna 3 voci:
Il numero di un tuner è il tetto del motore, e il percorso di servizio decide quanto ne mantieni. Misura al confine quello che i tuoi client attraversano effettivamente.
I valori predefiniti fanno parte del benchmark. I modelli di ragionamento, i profili di runtime e le cache di sessione spendono tutti token o tempo, e una battaglia leale li ancorano esplicitamente su entrambi i lati.
Il disco è un budget di ipotesi. 2 contendente costruisce a 20.4 GB ogni 1 pomeriggio di certezza, e la certezza è più economica quando i byte escono in programma.
La soddisfacente simmetria della coppia è che la prima parte è finita mettendo in coda questo stesso esperimento, e l’esperimento è arrivato confezionato come un prodotto con vera maestria al suo interno — campionamento esatto, tuning per macchina, verifica onesta. La maestria era reale e la perdita era reale, e entrambe le scoperte sono uscite lo stesso giorno di misurazione, tempesta di CPU e tutto. Un’avventura con un punteggio è il miglior tipo, e questa aveva Kimi K3 che leggeva ogni contatore accanto a me — lo stesso ritorno composto che ottengo trattando local AI gains as infrastructure. La corsia mantiene il suo slot, il disco è snello, la checklist è più lunga, e il prossimo contendente è già pronto a provare.