executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
Skills 둘러보기
생산성 및 협업 · SKILL.md
performance-backends
performance-backendsHelps agents choose and troubleshoot LTX-2 performance backends for CUDA readiness, FP8/NVFP4, block streaming, torch.compile, DiffVAE backends, ltx-kernels, and multi-GPU execution.
Independent GitHub snapshot · Automated classification · Original documentation governs
Skill 문서
GitHubname: performance-backends description: "Helps agents choose and troubleshoot LTX-2 performance backends for CUDA readiness, FP8/NVFP4, block streaming, torch.compile, DiffVAE backends, ltx-kernels, and multi-GPU execution." disable-model-invocation: true metadata: disco-role: operating license: NOASSERTION
Performance Backends
Use this sub-skill when the request is about making LTX-2 faster, smaller, or more parallel: CUDA readiness, FP8 / NVFP4 tradeoffs, offload, block streaming, torch.compile, DiffVAE backend selection, ltx-kernels, or multi-GPU latency paths.
It is for choosing and troubleshooting backend options, not for composing a generation command or training launch.
Route away
- Command construction for inference pipelines →
../inference-pipelines/SKILL.md - Training launch/configuration →
../training-workflows/SKILL.md - Low-level builders, model objects, or decoder internals →
../core-components/SKILL.md
Fast workflow
- Read backend-matrix.md to separate the verified CUDA baseline from optional accelerator paths.
- Run scripts/check_backend_readiness.py to inspect the current Python/CUDA/device stack without building or downloading anything.
- If the question touches compiled kernels, read kernels-and-accelerators.md.
- If it involves SP, TDP, distributed decode, Gemma sharding, or MGPU controllers, read multigpu.md.
- If something fails or a backend is missing, use troubleshooting.md to map the symptom to a safe fallback.
What this sub-skill covers
- CUDA parser/runtime readiness versus optional accelerator readiness.
- Memory-relief choices:
--offload,--quantization, block streaming, andPYTORCH_CUDA_ALLOC_CONF=expandable_segments:True. torch.compiletradeoffs, resident-weight requirements, and dynamic-shape caveats.- Optional accelerator readiness:
ltx-kernels, NATTEN, FlashAttention, and Blackwell-only paths. - DiffVAE backend selection:
DiffVAEMode, NATTEN, Triton, eager, and Blackwell DSL. ltx-kernelssurfaces: all2all, blockwise FP8/FP6, NVFP4, and VAE CuTe DSL.- Multi-GPU latency paths: SP, TDP, distributed decoder, distributed Gemma, and the MGPU controller.
What it does not own
- It does not build kernels, install packages, download checkpoints, or run generation/training.
- It does not decide the exact CLI flag order for a pipeline; that belongs to the inference-pipelines sub-skill.
- It does not author low-level API objects or patch model internals; route those questions to core-components.
- It does not install packages or compile kernels; it only explains the backend choice and the safe fallback.
Verified baseline
A CUDA smoke check passed with torch 2.13.0+cu132 on an A100 host. The verification did not build ltx-kernels, so optional accelerator claims should be treated as unverified until the local host checks them.