oMLX contre MTPLX sur la même machine : verdict partagé, et l'interrupteur caché qu'il faut connaître

Les deux moteurs d'inférence les plus rapides sur Apple Silicon, mesurés sur le même M5 Max, cellules isolées, n=5. Le plus rapide dépend de l'architecture du modèle.

Chiffre le plus rapide jamais produit par cette machine

179,4tok/s±0,4

oMLX 0.5.2 sur le mélange d'experts Qwen3.6-35B-A3B

La version 0.5.2 d’oMLX est sortie fin juillet avec une promesse forte : Lightning MTP, et des chiffres impressionnants publiés sur M3 Ultra (55,1 tok/s sur Qwen3.6-27B, 140,4 sur le 35B-A3B). Je mesure l’inférence locale sur Apple Silicon pour asiai, l’outil open source que je construis, alors j’ai mis les deux moteurs sur la même machine : M5 Max 128 Go, un serveur résident par cellule, n=5 par prompt, 3 minutes de refroidissement entre les runs, High Power Mode, médiane et intervalle de confiance à 95 %.

Chaque moteur tournait sur le checkpoint 4-bit officiel de son auteur : *-MTPLX-Optimized-Speed de Youssofal pour MTPLX, *-oQ4-mtp de Jundot pour oMLX.

Modèle	MTPLX 2.3.0	oMLX 0.5.2
Qwen3.6-27B (dense)	67,7 tok/s ±0,9	59,4 ±1,4
Qwen3.6-35B-A3B (MoE)	151,5 ±6,5	179,4 ±0,4

Verdict partagé. MTPLX gagne le modèle dense de 14 %, oMLX gagne le MoE de 18 % (intervalles de confiance disjoints dans les deux cas), et 179 tok/s est le chiffre le plus rapide jamais produit par cette machine. Les deux moteurs battent sur M5 Max les chiffres M3 Ultra publiés par leurs auteurs. Efficacité énergétique sur le MoE : oMLX 2,67 tok/s/W contre 2,46 pour MTPLX.

Débit médian sur les deux modèles, échelle commune. Le trait pointillé est le chiffre M3 Ultra publié par l'auteur d'oMLX ; les moustaches sont les IC 95 %, écrasés par l'échelle.

Efficacité énergétique sur le MoE, échelle complète depuis zéro : l'écart est réel et modeste. Le +8,5 % est dérivé des deux valeurs affichées, pas mesuré séparément. Non mesuré sur le dense.

Deux notes de transparence

Les cartes de mesure affichent les drapeaux, autant les expliquer moi-même.

Le drapeau thermique. Les deux cellules 27B l’ont déclenché (3 runs sur 20 côté MTPLX, 4 sur 20 côté oMLX ont touché un événement de throttle sérieux ; les cellules 35B sont restées nominales). En excluant les runs throttlés, les médianes passent à 68,8 contre 59,8 : les chiffres publiés sous-estiment donc la victoire de MTPLX sur le dense (14,0 % devient 15,1 % à froid). Découverte annexe intéressante : sous contrainte thermique, MTPLX perd 18 % quand oMLX ne bouge presque pas (2,7 %). Sur une machine chaude ou mal ventilée, le classement du dense pourrait se resserrer, voire s’inverser.

Le croisement sous contrainte thermique, Qwen3.6-27B dense. Les valeurs d'arrivée sont dérivées : pertes mesurées (−18 % et −2,7 %) appliquées aux médianes hors throttle. Aucune valeur absolue sous contrainte n'a été publiée telle quelle.

Le badge « 1,5 GB VRAM » des cartes oMLX. C’est la valeur que le moteur déclare lui-même (champ size_vram), et sa sémantique n’est clairement pas « mémoire du modèle » : le processus pesait 16,6 Go au pic. MTPLX ne déclare rien du tout, donc ses cartes n’affichent aucun badge. Un champ non comparable entre moteurs ne devrait pas s’afficher comme s’il l’était ; ce rendu sera corrigé dans asiai.

Les pièges de reproduction (ils m’ont coûté une heure)

Lightning MTP reste silencieusement désactivé si le checkpoint n’embarque pas les tenseurs mtp.*. Les conversions MLX standard n’en ont pas (le log dit « checkpoint ships no mtp.* weights; MTPModule attachment skipped »), et certaines conversions tierces estampillées « -MTP » utilisent un model_type qu’oMLX rejette. Utilisez les dépôts oQ4-mtp de Jundot.
Même avec le bon checkpoint, mtp_enabled est un réglage par modèle, à false par défaut. À activer dans l’interface d’admin ou dans ~/.omlx/model_settings.json, puis redémarrer. Cherchez « MTP path activated » dans le log du serveur ; sans cette ligne, vous mesurez l’auto-régressif nu à ~29 tok/s et vous conclurez à tort que la release est lente.
Le processus serveur s’appelle omlx-server, pas omlx, si vous scriptez autour.

La chose que j’ai préférée

Le README d’oMLX crédite MTPLX pour les kernels Metal de vérification de Lightning MTP. Les deux moteurs les plus rapides d’Apple Silicon se nourrissent l’un l’autre, et ce sont les utilisateurs qui gagnent.

Les chiffres sortent d’une campagne isolée et versionnée du 22 juillet ; la version anglaise et les données brutes vivent sur asiai.dev.

Conditions de mesure : M5 Max 128 Go · High Power Mode · n = 5 par prompt · médiane · IC 95 % · un serveur résident par cellule · 3 min de refroidissement entre les runs · checkpoint 4-bit officiel de l'auteur de chaque moteur · campagne 2026-07-22, relevée le 22 juil. 2026. Données brutes.

Ce que je n'ai pas vérifié

Ces chiffres décrivent oMLX 0.5.2 et MTPLX 2.3.0, mesurés le 22 juillet 2026. Les moteurs sont depuis passés à 0.6.0.dev1 et 2.6.0, et chacun a cassé la comparabilité en route : oMLX a changé ses prompts de référence et active le priming Lightning MTP par défaut, MTPLX a corrigé son comportement thermique. Les mesures restent valides pour ces versions-là, à cette date-là. Comparer les moteurs courants serait une nouvelle campagne, pas une mise à jour de celle-ci.