Obtenir AX Code · GratuitDocumentation

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

Sélection de modèles AX Engine

Statut : Actif Portée : état actuel Dernière revue : 2026-09-20 Responsable : runtime ax-code

AX Code n’offre que ces deux paquets de développement via AX Engine (local) sur les Mac Apple Silicon éligibles. Tiel Coder est le défaut ; Cyber-Tiel Coder est l’alternative.

Modèle Dépôt Hugging Face Sélection AX Code
Tiel Coder 35B A3B MXFP4 MTP dépôt AutomatosX/AX-Tiel-Coder-35B-A3B-MLX-AXQ-MXFP4-MTP tiel-coder-35b-axq-mxfp4 (défaut)
Cyber-Tiel Coder 35B A3B MXFP4 MTP dépôt AutomatosX/AX-Cyber-Tiel-Coder-35B-A3B-MLX-AXQ-MXFP4-MTP cyber-tiel-coder-35b-axq-mxfp4

Les alias épinglent respectivement les révisions 5ab39b24bfd7f65203be9b7823b1840486f58b6d et fe05e871ec69ad9ae8eac01fd285555514ac7daf. Les deux utilisent le sélecteur mlx, en préservant le paquet MXFP4 de l’éditeur. Les fiches de modèle décrivent des requantifications de développement, sans affirmation certifiée de parité de qualité ni de vitesse MTP ; les sélectionner n’établit ni une exécution native ni une amélioration de vitesse.

AX Code embarque la publication AX Engine 7.5.7 signée, qui inclut le correctif du chargeur d’espace de noms sidecar de Tiel issu du commit 51137c71a6794964d52c32c95e275c0923ed8d0b. Les binaires Homebrew 7.4.0 plus anciens n’ont pas ce correctif et rejettent ces paquets avec MlxMtpRequiredButUnavailable. Gardez MTP exigé ; les forçages d’exécution explicites doivent aussi contenir le correctif. Les mesures natives de préremplissage et de décodage conservent l’identité de construction testée d’origine et ne certifient pas les performances de la publication plus récente.

Qwen3.8 27B, Ornith, Qwen3-Coder-Next et tous les autres dépôts sont exclus de la nouvelle sélection gérée et des téléchargements. Chaque dépôt sélectionné n’apparaît qu’une fois. Les alias configurés et les révisions plus anciennes en cache n’ajoutent pas de choix après la découverte. Les autres fournisseurs et l’interface de rattachement en boucle locale configurée séparément conservent leur comportement. Pour exécuter le défaut dense propre d’AX Engine, démarrez ax-engine serve qwen3.8-27b:axq et rattachez ce point de terminaison local ; le MTP mesuré sur le chemin produit est un décodage de 31.05 tok/s sur Mac mini M4 Pro 64 GB et un décodage de 76.90 tok/s / un préremplissage de 795.3 tok/s sur M5 Max 128 GB. Ces chiffres ne sont pas des tok/s d’achèvement Tiel ni la vitesse de session d’AX Code. Voir synthèse des pairs Tiel.

Inspecter les modèles disponibles

ax-code providers ax-engine models --json
ax-code providers ax-engine models --refresh --json

Le rafraîchissement lit les métadonnées Hugging Face sans télécharger les poids ni démarrer un modèle. Les métadonnées embarquées fonctionnent hors ligne et complètent le dépôt sélectionné s’il manque dans un cache plus ancien. Les révisions présentes ne sont pas remplacées en silence par une autre révision embarquée. La sélection exige encore des métadonnées de source valides ; la restriction de dépôt n’établit pas une capacité native.

GET /provider/ax-engine/models renvoie le catalogue du CLI en cours, y compris l’identifiant exact de chaque modèle, le dépôt, la quantification, l’état local, les estimations de mémoire et de disque, et l’état de vérification. Une interface externe utilise cette API d’exécution. Si elle montre une liste plus ancienne, vérifiez le CLI qu’elle lance et sa version. Le développement d’AX Coder peut sélectionner un runtime source avec AX_CODE_BINARY ou settings.axCodeBinary.

Préparer le modèle sélectionné

Copiez l’identifiant exact du modèle depuis le catalogue. L’alias Tiel par défaut utilise mlx :

ax-code providers ax-engine prepare \
  --model tiel-coder-35b-axq-mxfp4 --quantization mlx --download --start

Les modèles exclus font échouer les nouvelles requêtes de préparation, de téléchargement et d’activation gérée avant de commencer le travail. Les enregistrements de modèles existants restent disponibles pour l’état et le nettoyage ; les identifiants retirés de Qwen3.8, Ornith et Qwen3-Coder-Next ne sont jamais redirigés vers l’un ou l’autre artefact Tiel. Retirer une option ne supprime pas ses poids et n’arrête pas un serveur existant.

Mémoire et vérification d'exécution

Les deux alias sélectionnés utilisent un contexte de 65,536 jetons, une limite de sortie de 8,192 jetons, une exigence de mémoire estimée de 64 GiB et un budget disque de téléchargement de 32 GiB. Ce sont des limites de service d’AX Code, pas le contexte maximal en amont. (Relevé depuis un contexte initial de 32,768 jetons : cela ne laissait que 24,576 jetons d’entrée utilisables après la réserve de sortie, moins que ce qu’exigent l’invite système fixe de l’agent AX Code et les schémas d’outils, de sorte qu’une session toute neuve ne pouvait jamais envoyer un premier tour.)

Chaque estimation de mémoire inclut les poids, les sidecars, le cache KV, les tampons et la réserve de l’hôte. Utilisez le résultat d’ajustement du catalogue en direct pour la machine courante. Ces estimations ne sont pas une certification de matériel ni de qualité de modèle.

Le chiffre de 64 GiB est un budget de planification conservateur pour le contexte complet (64K), pas un plancher dur. Pour une machine d’inférence locale gérée confortable, nous recommandons un Apple Silicon M4 Pro avec 48 GB de mémoire unifiée ou plus (par exemple un Mac Mini M4 Pro 48 GB) ; les Mac Apple Silicon plus petits peuvent encore exécuter AX Code lui-même à partir de 8 GB avec des modèles cloud ou API, ou des runtimes locaux plus légers.

Avant l’activation gérée, AX Code vérifie le contrat d’outils texte et structurés du modèle AX Engine actif. Un état verification-required signifie que la préparation est achevée mais que ce contrat en direct n’a pas été établi. Les noms de dépôt ou les sidecars MTP seuls ne prouvent ni le raisonnement, ni la vision, ni l’accélération MTP, ni la qualité de codage multi-tours.

Le compactage de session utilise les budgets de contexte et de sortie du modèle actif et réserve une marge d’entrée. La variante sélectionnée conserve son propre budget de catalogue ; le contexte maximal du modèle source n’est pas une garantie de mémoire gérée.

Voir Architecture du moteur local pour les détails de cycle de vie et de transport.

Politique MTP gérée

AX Engine géré utilise par défaut required, en accord avec l’artefact MTP sélectionné. Un rédacteur indisponible fait échouer le démarrage au lieu de revenir en silence au décodage direct. Les poids MTP et le réglage d’empilement pur n’établissent pas une accélération active. Le paquet Tiel Coder par défaut utilise le profil de spéculation auto afin qu’AX Engine sélectionne la porte de brouillon du modèle au lieu du forçage 0.80 du profil générique agentic. C’est distinct de la politique d’activation MTP : le réglage auto utilise encore MTP required. L’ancien environnement expérimental propre au Qwen3.8 dense n’est pas appliqué à ces paquets MoE. Voir la comparaison de profils pour les gains mesurés. Cyber-Tiel conserve agentic ; les sondes de tâches de lecture gérées ont échoué avec les deux profils, donc sa fiabilité de tâche reste non résolue. La politique d’activation reste required ; le moteur doit admettre le rédacteur réel. Pour sélectionner explicitement une politique, définissez provider.ax-engine.options.mtpPolicy dans ax-code.json :

{
  "provider": {
    "ax-engine": {
      "options": {
        "mtpPolicy": "required"
      }
    }
  }
}
Politique Comportement
disabled Utiliser le décodage direct ; ne pas demander de rédacteur de modèle.
auto Laisser AX Engine décider si le modèle et la route admettent MTP. Cela ne garantit pas l’activation.
required (défaut) Exiger un rédacteur MTP admis ; AX Engine rejette un rédacteur indisponible au lieu de revenir en silence au décodage direct.

AX_ENGINE_MTP_POLICY fournit les mêmes trois valeurs lorsqu’aucune option de fournisseur n’est définie. La sélection automatique du runtime exige AX Engine 7.5.7 ou plus récent pour appliquer ces politiques, y compris la politique par défaut required. Les réglages explicites disabled et auto remplacent encore le défaut. Les binaires plus anciens ou inconnus rejettent la sélection de politique avant de remplacer un moteur en cours ; mettez à niveau avant d’utiliser les contrôles de politique gérée. Les fichiers d’état historiques sans politique enregistrée signalent leur politique lancée comme inconnue et sont remplacés au prochain démarrage géré. Changer de politique prend effet au prochain démarrage géré ou à la prochaine requête de modèle, et remplace un processus existant qui a une politique différente. Cela ne change pas la sélection de modèle ni le stockage.

ax-code providers ax-engine start --mtp-policy disabled remplace la politique pour ce démarrage seulement. Définissez l’option de fournisseur persistante si les requêtes de codage suivantes doivent utiliser le même forçage. Les corps HTTP de préparation et de démarrage acceptent aussi mtpPolicy. Ces réglages gérés ne reconfigurent pas les points de terminaison attachés séparément. Après une mise à jour des sources, redémarrez pnpm run dev pour charger le nouveau défaut ; un moteur de développement déjà en cours conserve son code chargé jusqu’au redémarrage.

ax-code providers ax-engine status (ou --json) sépare la politique demandée, la politique lancée et l’état observé active/inactive/unknown. L’observation utilise la métrique de route de modèle la plus récente du moteur, pas les métadonnées du modèle ni les comptes de brouillon historiques. Les échantillons de modèle exact manquants restent inconnus, y compris avant la première étape de moteur observée ; les agrégats à l’échelle du serveur n’établissent pas l’activation. Un required configuré n’est pas affiché comme preuve d’activité. Les comptes de brouillon et d’acceptation, lorsqu’ils sont disponibles, sont cumulatifs pour le moteur résident. Un changement de politique en attente est signalé sans redémarrer pendant l’inspection de l’état. L’activation MTP n’est pas une promesse d’un débit de jetons particulier.

Interpréter la vitesse de réponse locale

AX Engine géré n’impose pas de plafond de jetons par seconde. Une mesure telle que 50 tok/s n’est ni une cible configurée ni une limite supérieure : un matériel plus rapide peut produire des jetons plus vite. La taille du contexte, les budgets de sortie et les limites de concurrence des requêtes contrôlent la capacité, pas un débit fixe de génération de jetons.

L’instantané public actuel de Tiel face à MTPLX est la campagne d’API native du 20 septembre 2026, résumée dans synthèse des pairs Tiel. Sur M5 Max 128 GiB, le paquet Tiel par défaut géré s’est achevé à 194.88 tok/s, TTFT inclus (décodage 217.85). Le pic de décodage Cyber-Tiel de 249.01 tok/s est le paquet alternatif, pas le défaut. Ces chiffres ne sont pas la vitesse de session d’AX Code.

Comparez les mesures à la même longueur d’entrée, au même budget de sortie, aux mêmes réglages d’échantillonnage et au même état de cache. Les mesures de décodage sur invite courte n’établissent pas un débit minimal pour une session de codage avec des dizaines de milliers de jetons de contexte. Réutiliser un préfixe réduit le traitement de l’invite ; le décodage suivant porte encore attention à ce contexte. L’activation MTP seule n’établit ni une acceptation de brouillon utile ni une accélération fixe.

Séparez le démarrage et la préparation, le temps jusqu’au premier contenu, et la génération soutenue lorsque vous enquêtez sur un tour lent. La métrique ax_runtime_decode_tok_per_sec du moteur est une moyenne pondérée exponentiellement à travers les requêtes, pas le débit de la réponse courante. Utilisez les chronométrages de requête et les comptes de jetons pour cette réponse, et les deltas de compteurs pour son acceptation MTP. Les fragments de flux peuvent contenir plusieurs jetons ; compter les fragments comme des jetons donne un débit incorrect.

AX Code réutilise les sondes réussies de version d’exécutable pendant jusqu’à cinq minutes. Il vérifie la disponibilité de l’exécutable à chaque résolution et invalide les versions en cache lorsque l’identité du fichier lanceur ou du serveur natif change. Les sondes échouées restent retentables. Cela réduit le travail de préparation répété ; cela ne change pas la vitesse de décodage du modèle. Un moteur de développement doit être redémarré pour charger les changements de source.