菜单
Profile and benchmark qwen3-tts-rs inference using e2e_bench with chrome tracing, flamegraph, or Nsight Systems inside a CUDA Docker container. Use when profiling, benchmarking, checking performance, finding bottlenecks, or running flamegraphs.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| name | profiling-qwen3-tts |
| description | Profile and benchmark qwen3-tts-rs inference using e2e_bench with chrome tracing, flamegraph, or Nsight Systems inside a CUDA Docker container. Use when profiling, benchmarking, checking performance, finding bottlenecks, or running flamegraphs. |
Run performance profiling and benchmarks for the qwen3-tts Rust TTS engine.
--gpus all supportqwen3-tts:latest Docker image (has Rust toolchain + CUDA)test_data/models/ (1.7B-CustomVoice is the default)tokenizer.json must be in the model directoryThe CUDA toolchain lives inside the Docker container. All cargo commands must
run there. The workspace is bind-mounted at /workspace:
docker run --rm --gpus all --entrypoint /bin/bash \
-v "$(pwd):/workspace" -w /workspace \
qwen3-tts:latest \
-c 'export PATH=/root/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/bin:$PATH && <COMMAND>'
Produces trace.json for viewing in chrome://tracing or https://ui.perfetto.dev.
docker run --rm --gpus all --entrypoint /bin/bash \
-v "$(pwd):/workspace" -w /workspace \
qwen3-tts:latest \
-c 'export PATH=/root/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/bin:$PATH && \
cargo run --profile=profiling --features=profiling,cuda,cli --bin e2e_bench -- \
--model-dir test_data/models/1.7B-CustomVoice --iterations 1 --warmup 1'
Output: trace.json (~12MB for 3 sentences). Contains spans:
generate_frames — full generation loopcode_predictor / code_predictor_inner — per-frame acoustic code generationtalker_step — per-frame transformer forward passsampling / top_k / top_p — per-frame token samplinggpu_sync trace events — marks every to_vec1() GPU→CPU syncThe e2e_bench binary reports stage breakdowns (prefill / generation / decode)
even without the profiling feature:
docker run --rm --gpus all --entrypoint /bin/bash \
-v "$(pwd):/workspace" -w /workspace \
qwen3-tts:latest \
-c 'export PATH=/root/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/bin:$PATH && \
cargo run --release --features=cuda,cli --bin e2e_bench -- \
--model-dir test_data/models/1.7B-CustomVoice --iterations 3 --warmup 1'
# Add --streaming flag
... --bin e2e_bench -- --model-dir test_data/models/1.7B-CustomVoice \
--iterations 3 --warmup 1 --streaming
... --bin e2e_bench -- --model-dir test_data/models/1.7B-CustomVoice \
--json-output results.json --iterations 3
List all to_vec1() GPU→CPU synchronization points:
bash scripts/audit-gpu-syncs.sh
Label Words Wall (ms) Audio (s) RTF Tok/s Mem (MB) Prefill Generate Decode
short 13 5235.2 3.68 1.423 8.8 858 21ms (1%) 2724ms (71%) 1109ms (29%)
medium 53 23786.3 34.00 0.700 17.9 859 20ms (0%) 22694ms (95%) 1057ms (4%)
long 115 43797.4 60.96 0.718 17.4 864 19ms (0%) 41861ms (96%) 1886ms (4%)
Key metrics:
In Perfetto/chrome://tracing:
talker_step and code_predictor — that's CPU overheadsampling (top_k + top_p) is significant vs model forward passesgpu_sync events mark where GPU stalls waiting for CPUThe ~18 to_vec1() calls per frame are the main bottleneck:
Batch these to reduce GPU→CPU round-trips.
| Model | Dir | Notes |
|---|---|---|
| 1.7B-CustomVoice | test_data/models/1.7B-CustomVoice | Default benchmark target |
| 1.7B-Base | test_data/models/1.7B-Base | Voice cloning (needs ref audio) |
| 1.7B-VoiceDesign | test_data/models/1.7B-VoiceDesign | Text-described voices |
From January 2025 on DGX (A100):
Sync this Claude Code config against new release notes — find config features added since the pinned baseline that this config should adopt. Use when Claude Code has been updated, when the user asks what's new / what changed / whether to adopt new settings or hooks, after a version bump, or when checking config currency against the latest release. Reports adoptable settings/hooks/env-vars/permissions as a risk-tiered proposal, then bumps the baseline. Do NOT use for auditing existing config quality, debugging hooks, or organizing rules — that is `maintaining-claude-code`.
Monitor and watch GitHub Actions CI/CD pipeline runs in real time. Use when the user has pushed code and wants to watch the build, check CI status, see if tests passed, monitor a pipeline, or wait for a workflow run to complete. Also use after any `jj git push` or `git push` command. Reports pass/fail with failed job logs. Do NOT use for writing or editing CI workflow YAML files, optimizing CI config, or debugging CI configuration — only for monitoring active runs.
Reorganize and clean up messy commit history on a feature branch into logical, reviewable commits. Use when cleaning up commits, preparing a branch for review, separating formatting from logic changes, fixing broken intermediate states, or squashing WIP commits.
Audit and improve Claude Code hooks, rules, and settings.json. Use when adding/debugging a hook, organizing rules, auditing settings.json (permissions, env vars, stale flags), or deciding between hook vs skill vs rule vs CLAUDE.md. For SKILL.md authoring use the skill-creator plugin; for CLAUDE.md audits use the claude-md-improver plugin.
Execute a structured test plan and emit a concise results document (JSON + Markdown). Use when running test plans, executing QA workflows, verifying acceptance criteria systematically, or producing test results documentation.
Search past Claude Code sessions to recall prior solutions, commands, fixes, and decisions. Use when the user references earlier work ("how did I fix", "last time we", "pick up where we left off", "a few months ago", "what was that … I set up", "didn't I once").