ad-conf-check

Verify applied AutoDeploy YAML config keys against TensorRT-LLM server logs.

Updated May 23, 2026
One-click install
npx skills add https://github.com/yo-steven/skills-exploration-20260522 --skill ad-conf-check
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ad-conf-check
Source: https://github.com/yo-steven/skills-exploration-20260522/tree/main/skills/TensorRT-LLM/ad-conf-check
Command: npx skills add https://github.com/yo-steven/skills-exploration-20260522 --skill ad-conf-check

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires pyyaml, and includes scripts (resource) and references (resource) components.

What problem does it solve?

This Skill helps you confirm whether AutoDeploy YAML configuration settings were actually applied at runtime, or whether the system skipped, disabled, or fell back due to compatibility and transformation constraints.

Core Features & Use Cases

  • Log-based config verification: Cross-references flattened YAML config keys against server log patterns to classify each setting as APPLIED, FAILED, SKIPPED, DISABLED, or UNKNOWN.
  • Optional graph dump evidence: Uses per-transform FX graph snapshots from AD_DUMP_GRAPHS_DIR to validate transformations when logs are inconclusive.
  • Optional nsys trace evidence: Uses Nsight Systems traces to detect executor/runtime-level behaviors that may not produce explicit log lines (e.g., chunked prefill and concurrency effects).

Quick Start

Run ad-conf-check by providing the TensorRT-LLM repo root path, the AutoDeploy YAML config path(s) (highest priority last), and the server log file path, optionally adding AD_DUMP_GRAPHS_DIR and/or an .nsys-rep trace for stronger evidence.

Frequently Asked Questions about ad-conf-check

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify TensorRT-LLM AutoDeploy YAML configs were applied at runtime?

Verify TensorRT-LLM AutoDeploy configs by correlating flattened YAML keys with server log patterns, classifying each setting as APPLIED, FAILED, SKIPPED, DISABLED, or UNKNOWN. This requires the TensorRT-LLM source for default.yaml and log patterns, merging and flattening YAML layers for comparison.

Why does TensorRT-LLM AutoDeploy skip or disable my configured transforms?

AutoDeploy skips or disables transforms due to compatibility and transformation constraints. Detecting these unexpected fallbacks requires cross-referencing flattened YAML config keys against server runtime logs to identify whether settings like piecewise CUDA graphs or fusion took effect.

How to debug piecewise CUDA graphs and sharding behaviors in TensorRT-LLM?

Debug piecewise CUDA graphs, sharding, and fusion behaviors by validating whether these transforms took effect at runtime. This involves correlating AutoDeploy YAML configuration parameters with server log patterns and optional graph dumps to produce per-key status evidence.

Do I need the TensorRT-LLM source code to check AutoDeploy config application?

Yes, checking AutoDeploy config application requires the TensorRT-LLM source to access up-to-date default.yaml and log patterns. The Skill merges and flattens YAML layers from this source alongside your custom configs to verify runtime application accurately.

What is the best way to detect disabled AutoDeploy transforms in TensorRT-LLM?

The best way to detect disabled AutoDeploy transforms is correlating flattened config keys with server log patterns and optional nsys trace evidence. This produces per-key status with explicit evidence in both human-readable and JSON outputs, validating runtime behaviors.