AutoDeploy Config Checker

Vérifiez que les configurations YAML d'AutoDeploy ont été appliquées à l'exécution en établissant une correspondance croisée avec les logs du serveur et optionnellement les dumps de graphe.

Entrées

Répertoire source TensorRT-LLM (obligatoire) — chemin vers la racine du repo TensorRT-LLM. Utilisé pour lire le dernier default.yaml et le code source afin d'obtenir les derniers motifs de log (le document de référence fourni peut être obsolète).
Chemin(s) du fichier de configuration YAML (obligatoire) — une ou plusieurs configurations YAML d'AutoDeploy. Quand plusieurs fichiers sont fournis, ils sont fusionnés en profondeur de gauche à droite (les fichiers ultérieurs remplacent les antérieurs pour les clés qui se chevauchent).
Chemin du fichier log du serveur (obligatoire) — sortie log de l'exécution du serveur AutoDeploy.
Répertoire de dump de graphe (optionnel) — répertoire de sortie AD_DUMP_GRAPHS_DIR contenant des snapshots de graphe par transformation (NNN_stage_transform.txt). Fournit des preuves supplémentaires pour résoudre les résultats UNKNOWN.
Fichier trace Nsys (optionnel) — profil Nsight Systems (.nsys-rep ou .sqlite) de l'exécution du serveur. Utile pour vérifier les configurations au niveau executor qui ne produisent aucune sortie log (p. ex., enable_chunked_prefill, concurrence multi-flux, capture/replay de graphe CUDA).
Chemin du fichier de sortie table (optionnel) — chemin pour écrire les résultats du tableau lisible par l'homme.
Chemin du fichier de sortie JSON (optionnel) — chemin pour écrire les résultats lisibles par machine au format JSON.

Sorties

Table lisible par l'homme (toujours présentée à l'utilisateur)

Tableau de vérification — une ligne par clé de configuration avec colonnes : Config (clé=valeur), Résultat (APPLIED / FAILED / SKIPPED / DISABLED / UNKNOWN), Preuve (ligne de log ou analyse de graphe prouvant le résultat).
Ligne de résumé — comptages totaux par statut (p. ex., Total configs checked: 29 | APPLIED: 23 | UNKNOWN: 4 | ...).
Détails FAILED/WARNING — informations étendues pour toute configuration qui a échoué ou avait des avertissements.

JSON lisible par machine (quand le chemin de sortie JSON est fourni)

Fichier JSON avec deux clés de niveau supérieur :

results — tableau d'objets, chacun avec config, value, status, evidence.
summary — objet avec total (int) et counts (objet mappant le statut au comptage, seuls les statuts non-nuls inclus).

Flux de travail

[Collect Inputs] Demandez à l'utilisateur les entrées suivantes :
- Répertoire source TensorRT-LLM (obligatoire) — chemin vers la racine du repo TensorRT-LLM. Utilisé pour vérifier default.yaml et le code source afin d'obtenir les derniers motifs de log.
- Chemin(s) du fichier de configuration YAML (obligatoire) — une ou plusieurs configurations AutoDeploy utilisées pour l'exécution. Quand plusieurs YAML sont fournis, ils sont fusionnés en profondeur de gauche à droite : les fichiers ultérieurs remplacent les antérieurs pour les clés qui se chevauchent. Dites à l'utilisateur : "Si vous avez plusieurs configurations (p. ex., une configuration par défaut et un remplacement utilisateur), listez-les dans l'ordre de priorité — priorité la plus faible d'abord, priorité la plus élevée en dernier."
- Chemin du fichier log du serveur (obligatoire) — la sortie log du serveur
- Répertoire de dump de graphe (optionnel mais recommandé) — le répertoire de sortie AD_DUMP_GRAPHS_DIR contenant des snapshots de graphe par transformation. Les fichiers sont nommés NNN_stage_transform.txt et montrent le graphe APRÈS chaque transformation. Quand fourni, l'analyse de graphe fournit des preuves supplémentaires (p. ex., vérifier les poids fragmentés, les ops collectives, les ops fusionnées). C'est particulièrement utile pour résoudre les résultats UNKNOWN.
- Fichier trace Nsys (optionnel) — profil Nsight Systems (.nsys-rep ou .sqlite) de l'exécution du serveur. Utile pour vérifier les configurations au niveau executor qui ne produisent aucune sortie log (p. ex., enable_chunked_prefill, concurrence multi-flux, capture/replay de graphe CUDA).
- Chemins de référence source TensorRT-LLM :
  - Configs d'exemple : <trtllm_src>/examples/auto_deploy/model_registry/configs/*.yaml
  - Config de transformation par défaut (toutes les transformations disponibles et leurs valeurs par défaut) : <trtllm_src>/tensorrt_llm/_torch/auto_deploy/config/default.yaml
[Update Reference Doc] Avant de vérifier les configurations, assurez-vous que le document de référence fourni est à jour avec la source TensorRT-LLM.

Lancez l'agent ad-conf-check-update avec :
- <trtllm_src> — le répertoire source TensorRT-LLM de l'étape 1
- <skill_dir> — le répertoire contenant ce fichier SKILL.md
L'agent compare <trtllm_src>/tensorrt_llm/_torch/auto_deploy/config/default.yaml et le code source AutoDeploy contre <skill_dir>/references/config_log_patterns.md. Si des configurations ont été ajoutées, supprimées, renommées, ou si les motifs de log ont changé, l'agent met à jour le document de référence sur place et rapporte ce qui a changé.

Après que l'agent soit terminé :
- Si le document de référence a été mis à jour, informez l'utilisateur : "Mise à jour de references/config_log_patterns.md pour correspondre à la dernière source TensorRT-LLM — voir le résumé des changements de l'agent ci-dessous." Puis montrez le résumé de l'agent.
- Si aucune modification n'était nécessaire, notez brièvement : "Le document de référence est à jour avec la source TensorRT-LLM."
[Parse Configs] Exécutez le script analyseur pour aplatir les configurations YAML (<skill_dir> est le répertoire contenant ce fichier SKILL.md) :

Entrée : Le default.yaml de TensorRT-LLM comme base, suivi par le(s) chemin(s) de fichier YAML utilisateur de l'étape 1. Incluez toujours default.yaml en premier afin que les configurations utilisateur remplacent les valeurs par défaut.
```
python3 <skill_dir>/scripts/parse_config.py <trtllm_src>/tensorrt_llm/_torch/auto_deploy/config/default.yaml <yaml_path1> [<yaml_path2> ...]
```
Cela fusionne en profondeur les fichiers YAML de gauche à droite (les fichiers ultérieurs remplacent les antérieurs) et aplatit les clés imbriquées en notation pointée (p. ex., kv_cache_config.enable_block_reuse). En incluant default.yaml en premier, chaque clé de configuration connue apparaît dans la sortie même si l'utilisateur n'a remplacé qu'un sous-ensemble.

Sortie : JSON aplati avec tous les paires de configuration {key, value}. Exemple :
```
{
  "yaml_files": ["default.yaml", "user_override.yaml"],
  "total_configs": 15,
  "configs": [
    {"key": "compile_backend", "value": "torch-cudagraph"},
    {"key": "kv_cache_config.free_gpu_memory_fraction", "value": "0.85"},
    {"key": "transforms.compile_model.piecewise_enabled", "value": "True"}
  ]
}
```

[Quick Scan] Vérifiez chaque configuration par rapport au log du serveur en utilisant des agents parallèles.

Entrée : Liste de configurations de l'étape 3, chemin du fichier log du serveur de l'étape 1, et references/config_log_patterns.md.

Divisez les configurations de l'étape 3 en 3 groupes par section et lancez 3 agents en parallèle, chacun vérifiant son groupe :

Agent	Groupe de configuration	Clés commençant par	Section de référence
Agent 1	Configurations de niveau supérieur	`runtime`, `compile_backend`, `attn_backend`, `max_seq_len`, `max_num_tokens`, `max_batch_size`, `cuda_graph_batch_sizes`, `enable_chunked_prefill`, `model_factory`, `dtype`, etc.	"Top-Level Config Parameters"
Agent 2	Configurations de cache KV	`kv_cache_config.*`	"kv_cache_config Parameters"
Agent 3	Configurations de transformation	`transforms.` (ou toute clé correspondant à un nom de transformation comme `compile_model`, `detect_sharding`, `multi_stream_`, `fuse_`, `gather_logits_`, etc.)	"Transform Parameters"

Chaque agent reçoit :

Son sous-ensemble de paires {key, value}
Le chemin du fichier log du serveur
Le document de référence references/config_log_patterns.md (incluant les balises source de vérification : [log], [graph], [nsys])
Le chemin du fichier trace nsys (s'il est fourni)

Chaque agent, pour chaque configuration dans son groupe :

Lit le document de référence pour trouver les mots-clés et motifs pertinents pour cette clé de configuration.
Fait un grep du log du serveur pour ces motifs. Stratégies de recherche clés :
- Pour les configurations de transformation : grep pour [stage=..., transform=<name>] et vérifiez la ligne [SUMMARY] (matches=N → APPLIED si N>0, SKIPPED si N=0).
- Pour les configurations avec indicateurs de succès/échec : grep pour ces chaînes spécifiques.
- Pour les configurations sans motif de log connu : grep pour clé=valeur ou le nom de clé près de la valeur.
- Pour les configurations avec enabled: false : marquez comme DISABLED sans recherche de log.
Assigne un statut en fonction de ce qui a été trouvé :
- APPLIED — le log confirme que la configuration a pris effet
- FAILED — le log montre que la configuration a été tentée mais a revenu en arrière ou a une erreur
- SKIPPED — la transformation a été exécutée mais n'a rien trouvé (0 correspondances)
- DISABLED — la configuration définit explicitement enabled: false
- UNKNOWN — aucune preuve de log trouvée (la configuration peut toujours être active mais sans log)
Enregistre la preuve (la ligne de log correspondante ou l'absence de celle-ci).

Sortie : Chaque agent retourne une liste d'entrées {config, value, status, evidence} pour son groupe. Fusionnez les 3 listes dans le résultat combiné.

[Double Check] Pour toutes les entrées UNKNOWN de l'étape 4, enquêtez davantage avant de présenter les résultats à l'utilisateur (les entrées FAILED ont déjà des preuves de log concrètes et n'ont pas besoin de vérification supplémentaire) :

Entrée : Liste des entrées de configuration UNKNOWN de la sortie de l'étape 4, le fichier log du serveur, et references/config_log_patterns.md.
- Relisez references/config_log_patterns.md pour les motifs alternatifs
- Faites un grep plus large du log pour le nom de transformation : [stage=..., transform=<name>]
- Recherchez les lignes prefixées par [APPLY] et les lignes [SUMMARY] pour cette transformation
- Vérifiez les mentions "Falling back", "Skipping", ou "failed" près des logs de transformation
- Si le répertoire de dump de graphe a été fourni :
  - Les fichiers de graphe sont nommés NNN_stage_transform.txt — chacun contient le graphe FX APRÈS cette transformation. Comparez avant/après en lisant les fichiers consécutifs.
  - Les preuves de graphe peuvent mettre à jour UNKNOWN vers APPLIED (p. ex., les ops collectives après lm_head confirment le fragmentation, les ops personnalisées fusionnées confirment les transformations de fusion).
  - L'analyse de graphe vérifie : fragmentation (ops collectives, changements de forme de poids), backend d'attention (types d'op), fusion MoE (présence d'op fusionnée), fusion GEMM (changements du nombre d'ops linéaires), correspondance de motif RMSNorm/SwiGLU/RoPE (présence d'op personnalisée).
  - Voir references/graph_verification_patterns.md pour la liste complète des vérifications basées sur le graphe.
- Si la trace nsys a été fournie, vérifiez les configurations au niveau executor balisées [nsys] dans le document de référence (p. ex., enable_chunked_prefill, enable_block_reuse, concurrence multi-flux, capture/replay de graphe CUDA)
Sortie : Pour chaque entrée UNKNOWN enquêtée, soit des preuves supplémentaires trouvées (avec mise à jour de statut) soit confirmation que la configuration n'est véritablement pas loggée.
[Report] Présentez les résultats finaux à l'utilisateur.

MONTREZ TOUJOURS le tableau détaillé complet. NE PAS résumer ou condenser. Présentez une ligne par configuration avec colonnes :
- Config — la clé de configuration et sa valeur (p. ex., compile_backend = torch-cudagraph)
- Résultat — l'un de : APPLIED, FAILED, SKIPPED, DISABLED, UNKNOWN
- Preuve — la ligne de log ou le motif qui prouve le résultat
Après le tableau, montrez la ligne de résumé (p. ex., Total configs checked: 29 | APPLIED: 23 | ...) et tous les détails FAILED/WARNING. Incluez tous les résultats supplémentaires de l'étape de vérification supplémentaire (étape 5).

Si l'utilisateur a demandé des fichiers de sortie, écrivez :
- Sortie table — le tableau lisible par l'homme en texte brut
- Sortie JSON — JSON lisible par machine avec tableau results et objet summary

Motifs clés à connaître

Chaque transformation logue : [stage=<stage>, transform=<name>] [SUMMARY] matches=N | time: ...
Chaîne de succès piecewise : dual-mode enabled -> prepared with N submodules -> captured graphs
Échec piecewise : "model is not a GraphModule...Falling back to eager execution"
Fragmentation : "Using allreduce strategy: SYMM_MEM", "Applied N TP shards from config"

Pièges

Chaque clé YAML doit apparaître dans la sortie. Vérifiez toutes les configurations du YAML, pas seulement celles avec des motifs connus. Si une clé de configuration n'a pas d'entrée dans le document de référence, faites un grep du log pour le nom de clé et la valeur. Les configurations nouvelles/inconnues doivent toujours être rapportées — ne les ignorez jamais silencieusement.
UNKNOWN ne signifie pas que la configuration a été ignorée. Certaines configurations (p. ex., enable_chunked_prefill, enable_block_reuse) sont consommées au niveau executor/runtime et ne produisent aucune sortie log. UNKNOWN signifie « aucune preuve de log trouvée », pas « la configuration n'a pas été appliquée ».
Les noms de configuration dépréciés peuvent causer FAILED. Par exemple, torch_dtype est déprécié au profit de dtype, et cuda_graph_batch_sizes (niveau supérieur) est remplacé par cuda_graph_config.batch_sizes. Recherchez les messages d'avertissement de dépréciation dans le log. Les anciennes clés peuvent être silencieusement ignorées.
Le runtime peut ajuster les valeurs configurées. Par exemple, max_seq_len peut être configuré à 262144 mais ajusté à 16384 au runtime en raison des contraintes de mémoire. Rapportez cela comme APPLIED avec une annotation WARNING.
Codes de couleur ANSI dans les logs. AutoDeploy utilise une sortie log colorée. Supprimez ou ignorez les séquences d'échappement ANSI lors de la correspondance de motifs.
Le document de référence est mis à jour automatiquement. L'étape 2 exécute l'agent ad-conf-check-update pour synchroniser references/config_log_patterns.md avec la dernière source TensorRT-LLM avant que la vérification de configuration ne commence. Si l'agent rapporte des changements, consultez son résumé pour comprendre ce qui a changé.