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

Nouveau test client AX Code et OpenCode : 19 septembre 2026

Statut : Actif

Portée : instantané diagnostique mesuré

Dernière revue : 2026-09-19

Responsable : runtime ax-code

Ce nouveau test utilise la source AX Code 62895cf40a39e0ebd4afec0afa21044e9871aa0b, après le correctif de préfixe local (42908b46a) et les ajouts de fournisseurs MTPLX/oMLX. Les six combinaisons client/moteur utilisent le même artefact Qwen3.8 27B AXQ 6 bits avec MTP activé sur un Apple M3 Max, 128 GiB. Les mesures antérieures restent des preuves historiques ; leurs paquets de modèles, invites, limites de jetons et conditions de cache diffèrent. Ce n’est pas une estimation contrôlée avant/après de l’accélération du correctif de préfixe.

Débit de sortie livré

Chaque cellule est première tâche / tâche répétée, en tokens/s. Ce sont des observations uniques, pas des médianes. La tâche répétée démarre une nouvelle session CLI contre le même processus de moteur ; on ne suppose pas qu’elle touche un cache. Le chargement et l’attente de la première sortie sont exclus de ce débit.

L’estimation est (completion tokens - 1) / (last output payload time - first output payload time). Le décodage spéculatif peut émettre plusieurs jetons dans une seule charge, donc il s’agit d’une estimation de livraison client, pas du compteur de décodage natif du moteur. Elle ne mesure pas non plus le débit d’une requête complète.

Chronométrage des requêtes, charge et acceptation

NR signifie que le serveur n’a pas signalé l’usage de jetons en cache ; cela n’affirme pas zéro. Le temps de première charge commence lorsque le proxy d’enregistrement local reçoit la requête de modèle. Le temps mur CLI inclut aussi le démarrage et l’achèvement du client. La tâche demande un cache LRU TypeScript générique autonome avec get, set, delete et clear, sans exécution d’outil ni modification de fichier.

Les contrôles d’acceptation du code vérifient les clés manquantes, la recherche de valeur, l’éviction LRU, les entrées conservées, la récence de mise à jour, la suppression de clés existantes et absentes, le vidage, l’identité des clés objet et les valeurs fausses. Les fichiers générés reçoivent aussi une vérification TypeScript stricte. Ces contrôles bornés n’établissent pas une qualité de codage large. Toutes les lignes de mesure conservent leur sortie générée et leur résultat de validation ; les échecs ne sont pas remplacés en silence par des essais plus rapides.

Conditions MTP et d'exécution

• AX Engine 7.4.0 : --mlx-mtp-policy required, drapeaux de runtime local géré, accélération n-gram et empilement n-gram désactivés. Les métriques du processus en direct montrent ax_engine_mlx_mtp_model_policy_active=1 avec des compteurs de jetons de brouillon et acceptés non nuls. L’instantané AX Code suit l’échauffement ; l’instantané OpenCode suit la première tâche. Les deux incluent l’échauffement et ne sont pas des totaux d’acceptation par tâche. Les comptes de brouillon AX Code par tâche n’ont pas été conservés.
• MTPLX 2.11.3 / MLX 0.32.2 : --generation-mode mtp --depth 3 explicite ; la santé en direct signale generation_mode: mtp et runtime_mode: Sustained MTP. Les réécritures d’agent et le cache de session SSD sont désactivés ; la banque de session native en mémoire reste activée. Les échauffements natifs de démarrage et de noyau sont conservés et exclus du chronométrage. L’échauffement de charge sans lien s’est achevé ; l’état de l’échauffement d’arrière-plan à l’admission est conservé dans les données plutôt que supposé achevé.
• oMLX 0.6.4 / MLX 0.32.0 : Lightning MTP activé, profondeur 3, chargement de modèle texte seulement, concurrence un. Les journaux par génération enregistrent l’acceptation du brouillon et l’exécution par profondeur pour l’échauffement et les deux tâches. L’importateur sidecar amont renomme 15 tenseurs ; leur dtype, leur forme et leurs octets de charge restent identiques au sidecar AXQuant d’origine. Les poids du backbone sont inchangés.
• Artefact : AutomatosX/AX-Qwen3.8-27B-MLX-AXQ-6bit-MTP, révision 4d36d652c21590f6813495351c3baf5fca5b3831. Les métadonnées de l’artefact déclarent une profondeur MTP de 1 ; la profondeur récurrente 3 ici suit la politique d’exécution choisie ou l’expérience explicite et n’étend pas la certification de l’artefact. Le paquet de modèle Optimized-Speed n’est pas utilisé dans ce nouveau test.
• La version d’OpenCode est 1.18.31. Tous les moteurs et clients s’exécutent en série. Chaque paire client/moteur démarre un processus neuf et un cache de tâche isolé, suivi d’un échauffement de chargement de modèle sans lien, plafonné à 64 jetons de sortie. Le chargement du modèle et cet échauffement sont exclus du tableau ; la première tâche paie encore le préremplissage à froid. Le contrôle du ventilateur reste à sa valeur par défaut, et les fichiers du backbone résident sur un stockage SMB.

Ce qui est aligné, et ce qui reste différent

Les deux clients reçoivent les mêmes instructions de projet complètes figées, la même tâche utilisateur et quatre outils autorisés (glob, grep, read, skill). Le CLI source d’AX Code utilise les identifiants de fournisseur réels ax-engine, mtplx et omlx ; AX Engine utilise son contrat vérifié de rattachement en boucle locale avec un moteur démarré séparément et porteur de drapeaux gérés. Cela ne chronomètre pas l’interface de téléchargement et de démarrage gérée. OpenCode utilise son chemin de fournisseur compatible OpenAI. La configuration de projet est désactivée et chaque client a des réglages et un état isolés. Les invites natives du client, les schémas d’outils et les en-têtes de session restent intacts ; les comptes de jetons rendus et le comportement du cache diffèrent donc.

Un proxy d’enregistrement local aligne la température 0.55, top-p 1, top-k/min-p 0, la pénalité de répétition 1, les pénalités de présence et de fréquence 0, la graine 0, thinking désactivé, et un plafond de sortie de 1,024 jetons. Il force tool_choice: none pour cette tâche sans outil. Les deux clients sont configurés pour un contexte de 65,536 jetons. Chaque ligne est vérifiée pour l’instantané d’instructions complet, les quatre noms d’outils, l’échantillonnage commun, une seule requête, une sortie CLI réussie, un arrêt naturel et aucune exécution d’outil.

Les invites AX Code plus longues peuvent augmenter à la fois le préremplissage et le travail d’attention pendant la génération. Des longueurs de réponse, des contenus, des modèles d’exécution, des noyaux et des politiques de cache différents empêchent de traiter ces tableaux comme un banc de surcharge client à jetons égaux. Le fait que MTP soit actif ne garantit pas 30–40 tokens/s pour un contexte de codage complet. Pour isoler la surcharge client ou l’effet du correctif de préfixe, rejouez séparément des requêtes et des identifiants de jetons sérialisés identiques, avec une sortie et des conditions de cache contrôlées.

Ce rapport ne change aucun comportement cloud, GPU privé, fournisseur CLI ou AX Trust. Voir le guide de configuration du runtime local pour les instructions de connexion et les données de mesure assainies pour les chronométrages exacts, les comptes, les hachages, les résultats de validation et les preuves MTP. Les instructions de projet privées, les réponses du modèle, les chemins locaux et les en-têtes de session sont conservés localement et ne sont pas publiés. En conséquence, la charge de contexte privé complète n’est pas reproductible de façon indépendante à partir du seul rapport public.