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

Configuration et diagnostics de performance

Statut : actif

Portée : état actuel

Dernière revue : 2026-09-13

Responsable : runtime AX Code

Choisir un profil d'outils

Pour les sessions de programmation qui n’ont pas besoin d’opérations d’infrastructure, de planification, de génération d’images ni d’analyse spécialisée, définissez toolProfile sur coding pour le fournisseur connecté dans votre configuration AX Code :

{
  "provider": {
    "your-provider-id": {
      "options": {
        "toolProfile": "coding"
      }
    }
  }
}

Remplacez your-provider-id par l’identifiant du fournisseur connecté. Cela conserve l’inspection et l’édition de fichiers, le travail shell et en arrière-plan, la délégation, les notebooks, les objectifs, les skills, la mémoire et la vérification de revue. Les outils Web et les outils facultatifs suivent toujours leurs règles d’activation et de permission existantes. Les outils personnalisés et MCP conservent leurs règles d’admission existantes et peuvent augmenter la taille de la requête.

Utilisez full lorsque vous avez besoin du conseil ou de l’arène, des opérations, de la planification, de la génération d’images ou d’outils d’analyse spécialisée. Les fournisseurs cloud ont full par défaut ; AX Engine conserve son défaut plus petit core. coding ne change ni l’effort de raisonnement, ni les permissions, ni la capture d’instantanés, ni les exigences de vérification. Son effet sur la vitesse et la réussite de la tâche dépend du modèle et de la charge. Voir Effort du modèle pour les contrôles explicites du raisonnement.

Séparer la préparation locale du temps de réponse du fournisseur

Activez le profilage local pour une exécution :

AX_CODE_PROFILE_NATIVE=1 ax-code run --model your-provider-id/your-model "Your task"
ax-code session replay YOUR_SESSION_ID --mode export

Le profil de sortie sur stderr inclut les intervalles session.insertReminders, session.preparePromptRequest, session.preflight, session.resolveTools et les intervalles d’instantané track/patch. Ce sont des mesures agrégées ; les intervalles imbriqués ou qui se chevauchent ne doivent pas être additionnés comme temps mur de la tâche. Le profilage lui-même ajoute un surcoût de mesure.

Les événements llm.response enregistrés gagnent un objet timing facultatif :

Les trames de métadonnées et de début de flux ne comptent pas comme du contenu. Les temps utilisent une horloge monotone et reflètent le moment où les fragments sont observés, y compris toute contre-pression du flux. Ce ne sont ni des temps réseau bruts, ni des temps d’inférence du serveur, ni des temps de rendu du TUI. Les adaptateurs CLI peuvent inclure le travail propre de la CLI enfant. Le latencyMs existant conserve son ancien chronométrage d’étape mixte et peut inclure l’exécution d’outils et le travail d’instantané. Les nouveaux champs de temps ne contiennent que des durées et l’identité de la tentative.

Sans AX_CODE_PROFILE_NATIVE=1, l’objet de chronométrage supplémentaire est omis. Le profilage utilise des diagnostics locaux et le journal d’événements de session existant ; il n’active pas d’exportateur de télémétrie externe.

Pour une comparaison utile, maintenez constantes la tâche, la révision du dépôt, le point de terminaison du fournisseur, le modèle exact, l’effort de raisonnement, les permissions d’outils et les conditions de cache. Notez le temps jusqu’à la première réponse visible et le temps jusqu’à un résultat vérifié, y compris les tests et les tentatives de réparation. Une requête plus petite ou un instantané local plus rapide, à eux seuls, n’établissent pas une fin de tâche cloud plus rapide.

Utilisez les contrôles du harnais et l’évaluation vérifiée pour essayer la reprise de contexte, la découverte MCP, des recettes en lecture seule et des comparaisons de fixtures appariées, avec une vérification indépendante.

Comprendre la taille de la requête

Les nouveaux événements llm.request dans ax-code session replay YOUR_SESSION_ID --mode export incluent requestBytes lorsque la provenance de la requête est disponible :

system est déjà représenté dans messages ; ne les additionnez pas. Le cadrage des tableaux est inclus. Les valeurs binaires utilisent la représentation par condensé existante, donc ces tailles ne sont ni des tailles de charge réseau ni des mesures de mémoire résidente. Ce ne sont pas des comptes de jetons : l’usage de jetons du fournisseur et les compteurs de cache restent la source pour la comptabilité d’entrée du modèle. Un résumé de paquet de contexte couvre une étape plus étroite et n’est pas l’entrée totale du modèle. Les événements hérités omettent ce champ ; une provenance échouée reste explicitement indisponible.

Ce diagnostic n’enregistre que les tailles et les hachages ou métadonnées existants. Aucun corps d’invite supplémentaire ni authentifiant n’est enregistré. Il réutilise la sérialisation canonique nécessaire à chaque hachage, au lieu d’analyser la requête en jetons. Comparez les tailles à des tours correspondants pour décider si les instructions système, les définitions d’outils ou un historique qui grossit demandent attention. Le profil de programmation ci-dessus peut réduire les définitions d’outils sans changer l’effort de raisonnement ; le profil complet reste disponible pour les capacités qu’il ajoute.

Éviter une exploration redondante

Pour une recherche de fichier connu ou un simple décompte, utilisez une recherche ciblée ou une seule commande d’agrégat. Résolvez les chemins par rapport au répertoire d’espace de travail courant ; une session démarrée dans un paquet a déjà ce paquet comme racine de recherche. Le grep intégré utilise la syntaxe d’expressions régulières par défaut de ripgrep, sans regard avant ou arrière ni rétro-références.

Utilisez un seul investigateur pour un seul chemin d’appel. Les tâches parallèles en lecture seule doivent avoir des livrables distincts et des chemins ou sous-systèmes dont elles sont responsables, avec les preuves existantes fournies dans leurs dossiers. Une revue indépendante peut revoir les preuves pour une question de vérification distincte. Répéter la découverte dans plusieurs contextes neufs coûte des tours de modèle, même lorsque le cache de preuves répond ; les succès de cache ne contournent ni la validation du contenu actuel ni les permissions.

Les serveurs de langage démarrent désormais à la demande par défaut. Voir Utilisation de la mémoire pour l’activation du préchauffage spéculatif et le compromis avec la latence de la première requête sémantique. Les consignes d’invite et les tests locaux n’établissent pas une réduction particulière des appels de modèle en direct ni de la RAM physique.