Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.5 · SDK 2.6.9. Source anglaise

Mesures d'inférence locale : 19 septembre 2026

Statut : actif

Portée : instantané de diagnostic mesuré

Dernière revue : 2026-09-19

Responsable : runtime AX Code

Pour la matrice complète de six combinaisons de clients après le correctif de préfixe local, voir le nouveau test AX Code/OpenCode. Les vitesses client ci-dessous restent des observations historiques, dans leurs conditions d’origine.

Ces mesures examinent la latence de réponse locale et la vitesse de décodage sur un Apple M3 Max avec 128 GiB de mémoire unifiée. Ce n’est ni une qualification matérielle, ni une évaluation de qualité de modèle, ni une promesse de 30–40 jetons/s à des longueurs de contexte arbitraires. Les instructions de connexion MTPLX et oMLX sont dans le guide du runtime local.

Conditions et chronométrage

• Sources AX Code fondées sur v7.19.3 ; OpenCode 1.18.31 ; AX Engine 7.4.0 ; MTPLX 2.11.3 ; oMLX 0.6.4 (1d7826185c5b5b69b38b27cbe57d7597b7551fd7, installation de sources isolée).
• Un seul backend d’inférence à la fois. Contrôle des ventilateurs par défaut ; aucune affirmation de ventilateur au maximum. Les fichiers de modèle étaient sur un stockage SMB. L’exécution d’artefact exact de MTPLX n’a mis en scène que le sidecar MTP sur SSD, avec son SHA-256 vérifié.
• Les rejeux d’artefact exact ont utilisé AutomatosX/AX-Qwen3.8-27B-MLX-AXQ-6bit-MTP, révision 4d36d652c21590f6813495351c3baf5fca5b3831. Les exécutions client séparées MTPLX Optimized-Speed ont utilisé Youssofal/Qwen3.8-27B-MTPLX-Optimized-Speed. Ce sont des paquets de modèles différents, même si leurs tailles de fichiers totales sont proches ; leurs débits ne peuvent pas isoler un gain de vitesse dû au seul runtime.
• Réglages de rejeu communs : température 0.55, top-p 1, top-k 0, graine 0, jusqu’à 256 jetons générés. AX Engine et MTPLX ont utilisé un MTP actif de profondeur 3. Les noyaux de runtime et les échantillonneurs spéculatifs diffèrent. Les métadonnées de l’artefact déclarent la profondeur 1 ; la profondeur 3 ici est une expérience de runtime explicite, pas une extension de la certification de l’artefact ni une nouvelle recommandation par défaut. AX Engine a ignoré EOS pour son rejeu natif à sortie fixe ; MTPLX et oMLX suivent leurs propres règles d’arrêt.
• Le débit de décodage natif utilise les compteurs de décodage du backend. Le débit livré est (reported completion tokens - 1) / (last output payload time - first output payload time) ; les événements vides et les signaux de maintien ne comptent pas comme sortie. Ces frontières ne sont pas identiques.
• La latence du premier contenu inclut la préparation de la requête sur le serveur, la restauration ou le préremplissage du cache, et toute mise en tampon avant la sortie. Le total des jetons divisé par la requête entière est une autre mesure de débit. Les rafales d’appels d’outils ne conviennent pas aux estimations de décodage du premier au dernier contenu.

Par exemple, le même rejeu MTPLX à entrée de 30k a mesuré 13.99 jetons/s de décodage natif, mais seulement 1.13 jetons/s sur la requête complète, parce que le préremplissage à froid a consommé environ 209 secondes. Un nombre bas sur la requête entière, seul, n’établit pas une défaillance du moteur de décodage.

Rejeu à poids exacts d'AX Engine et de MTPLX

Chaque paire a reçu la même séquence entière de jetons d’entrée et a émis 256 jetons. Les valeurs ci-dessous sont des observations uniques ; les identités des jetons générés peuvent différer malgré une graine commune.

MTPLX a utilisé son profil Sustained pour cet artefact. La requête AX Engine de 30k était déjà chaude, tandis que MTPLX était à froid, donc leurs temps jusqu’au premier jeton ne peuvent pas établir un rapport de vitesse de préremplissage. L’entrée de 30k inclut une instruction historique de limite d’étapes et produit une prose de diagnostic ; ce n’est pas une acceptation de tâche de programmation. Le rejeu MTPLX de 18,643 jetons a rapporté stop après 256 jetons, plutôt que length.

L’invite courte montre des débits de décodage proches. Ces exécutions ne démontrent pas qu’un backend est universellement plus rapide, ni que passer AX Code à un autre backend garantit un gain de vitesse fixe.

AX Code et OpenCode sur MTPLX Optimized-Speed

Les deux clients ont reçu la même tâche utilisateur, les instructions complètes du projet et quatre schémas d’outils permis. La tâche demandait un cache LRU TypeScript, sans exécuter d’outils. Les invites propres à chaque client ont été conservées ; un proxy d’enregistrement a aligné l’échantillonnage, désactivé la réflexion et utilisé un plafond requête/serveur de 1024 jetons. Les réponses suivantes se sont terminées normalement :

Ces mesures précèdent le correctif de préfixe local d’AX Code (42908b46a). AX Code a envoyé plus de contexte et a produit un code différent. Ce n’est ni une comparaison de surcoût client à jetons égaux, ni un résultat avant/après. Retirer seulement la carte de répertoires parcourue automatiquement, dans un rejeu séparé, a réduit l’entrée à 30,717, mais n’a amélioré le décodage observé que d’environ 2 % ; le retrait de la carte de répertoires n’a pas été adopté.

Une matrice séparée d’adaptateur AX Engine a observé AX Code à 9.44–11.56 t/s livrés avec 33,225 jetons d’entrée, et OpenCode à 12.82–13.00 avec 17,290. Les longueurs d’invite, le contenu de sortie, l’état du cache et le plafond de sortie de 256 jetons diffèrent du tableau de réponses complètes ci-dessus ; ne les combinez pas en un seul rapport de gain de vitesse de backend.

oMLX

Le test oMLX utilise l’artefact AXQ exact et une installation isolée avec MLX 0.32.0. Les cinq contrôles d’import de noyau natif, y compris qwen35_prefill et decode_fast, ont réussi. Le chargement texte seul est choisi explicitement, la fenêtre de contexte est de 65,536 et la concurrence est de un.

La première tentative Lightning MTP a renvoyé HTTP 409, parce que le test a sauté l’étape exigée par oMLX, Importer le side-car MTP. C’était une erreur de préparation, pas une absence de prise en charge AXQuant. AXQuant fournissait déjà le contrat canonique qwen3-next-mtp ; la révision Hub actuelle b0784088d4026ca569c5653e6e6243c501ef5fa9 inclut aussi la liste axquant_omlx_compat.json de 15 tenseurs MTP. L’instantané de rejeu d’origine est antérieur à cette annotation.

La base sans MTP s’est terminée avec l’artefact d’origine :

Ce sont des résultats sans MTP, et ils ne doivent pas être comparés à des runtimes avec MTP comme preuve d’une différence de vitesse inhérente au backend. Les allers-retours de l’analyseur de jetons et les comptes d’invite du serveur correspondaient aux entrées entières utilisées par les autres backends de rejeu.

L’exécution MTP corrigée utilise l’importateur propre d’oMLX sur une copie séparée, accessible en écriture. Les fragments du squelette sont inchangés. L’importateur ajoute language_model. aux 15 noms de tenseurs du sidecar ; le dtype, la forme et le hachage de charge de chaque tenseur ont été vérifiés égaux avant et après l’import. Le hachage du fichier importé diffère donc, parce que son en-tête a changé. Les métadonnées d’origine et l’instantané de modèle partagé restent intacts. La profondeur MTP 3 est choisie explicitement, et les compteurs de brouillon et d’acceptation par profondeur confirment l’exécution réelle.

Le résultat court confirme que ce paquet AXQuant fonctionne avec oMLX Lightning MTP après l’import. Le décodage en contexte long reste plus lent malgré un MTP actif. Des textes générés différents, des versions de runtime, des noyaux et des politiques spéculatives empêchent d’attribuer toutes les différences entre runtimes à AX Code.

Acceptation du flux de programmation et exclusions

Après le correctif de préfixe local, AX Code a achevé une tâche isolée en lecture seule, sur AX Engine et sur MTPLX : lire un répertoire et deux fichiers TypeScript, expliquer l’exception de file pleine, identifier la capacité 7, et renvoyer un marqueur présent seulement dans le second fichier. Les deux se sont terminés avec succès et ont conservé les octets du jeu de test. Les appels AX Engine suivants ont réutilisé 11,264 jetons d’entrée ; MTPLX en a réutilisé 11,264–12,032. Les corps de la première requête étaient identiques, mais les modèles de runtime ont produit des comptes de jetons différents. Cela vérifie le flux d’outils et la réutilisation de cache observée, pas un gain de vitesse fixe dû au correctif.

Les nouveaux identifiants de fournisseurs ont aussi passé l’acceptation en direct depuis la CLI des sources : omlx avec le paquet AXQ importé et un tool_call: true explicite, et mtplx avec le paquet Optimized-Speed et aucune entrée de modèle configurée. MTPLX a découvert son modèle de conversation et sa capacité d’outils depuis la liste de modèles native. Les deux exécutions ont achevé deux lectures de fichiers réussies et ont renvoyé l’exception attendue, la capacité et le marqueur propre au fichier, sans changer les octets du jeu de test. Le préfixe système et utilisateur initial est resté identique sur les trois requêtes de chaque exécution. oMLX a réutilisé 8,192 jetons ; MTPLX en a réutilisé 11,829 et 12,047. Ce sont des contrôles fonctionnels, pas des exécutions de performance appariées ; aucun gain de temps mur entre runtimes n’est affirmé.

Des réponses AX Code antérieures, plafonnées à 256 jetons, ont été tronquées et sont entrées en reprise ; leurs débits de sortie répétée autour de 51–58 t/s sont exclus des affirmations de génération fraîche. Les exécutions initiales avec des instructions de projet ou des permissions d’outils inégales sont aussi exclues. Ollama et LM Studio n’ont été inspectés que pour la construction des requêtes ; aucun résultat de débit de génération n’est affirmé pour eux.

L’invite générique de 62 jetons est publique comme requête d’achèvement oMLX exacte. Depuis la racine du checkout, après avoir importé le sidecar, activé MTP et préchauffé le modèle, on peut l’envoyer avec :

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

Changez l’identifiant de modèle de la requête pour celui exposé par votre serveur. Le fichier inclut le modèle rendu ; utilisez le point de terminaison d’achèvement afin qu’un modèle de conversation ne soit pas appliqué une seconde fois. Confirmez 62 jetons d’invite et conservez l’événement d’usage final. Le chargement à froid du modèle et le préchauffage doivent être rapportés à part.

Les instructions de projet privées, les invites de session, les chemins locaux et les détails d’authentification ne sont pas publiés. Les données de mesure assainies contiennent des comptes, des temps, l’identité du runtime et des hachages d’entrée, plutôt que le texte des invites. Le rejeu complet en contexte privé n’est donc pas une charge de travail publiquement reproductible à elle seule. Pour une nouvelle comparaison, utilisez la même révision de modèle, le même analyseur et modèle, les mêmes identifiants d’entrée, les mêmes règles de sortie et d’arrêt, le même échantillonnage, le même mode MTP, le même état de cache, le même matériel et une exécution en série ; rapportez à part la réussite de la tâche complète.

Contrats amont : guide du serveur et des modèles MTPLX, oMLX 0.6.4. Leurs bancs publiés utilisent un autre matériel et d’autres charges, et ne se substituent pas aux mesures ici.