dyl-joseph/DiT-AutoResearch

Skill DiT AutoResearch A5500

Use esta skill ao otimizar inferência de Transformers de Difusão em hardware Ampere RTX A5500.

Regras inegociáveis

• Leia program.md antes de agir.
• Trate knowledge/handbook/00_foundations/04_target_hardware_and_quality_contract.md como a sobreposição do projeto para conselhos genéricos de hardware/precisão.
• Qualidade é uma restrição rígida, não um objetivo ponderado.
• A quantização pode ser testada apenas se o conjunto de benchmarks fixo mostrar nenhuma regressão de qualidade/precisão necessária. Nunca mantenha um candidato quantizado com uma pontuação de benchmark necessária inferior.
• Não modifique o corpus de benchmark, avaliador de qualidade, harness de desempenho ou outros fixed_paths durante uma sessão.
• Edite apenas caminhos listados em mutable_paths.
• Estabeleça a linha de base não modificada primeiro.
• Compare a qualidade do candidato com a linha de base original, não com o candidato anterior.
• Compare o desempenho com o melhor candidato atual no ramo de objetivo do branch.
• Uma hipótese causal por commit.
• Prefira otimizações de implementação exatas antes de aproximações numéricas ou algorítmicas.
• Meça no A5500. Não importe números de aceleração H100/B200 como resultados esperados para A5500.
• FlashAttention-2/SDPA são caminhos de atenção Ampere relevantes; FA3/FA4 e recursos específicos Hopper/Blackwell são referências de pesquisa, não caminhos nativos do alvo.

Inicialização obrigatória

1. Leia program.md completamente.
2. Leia os seguintes arquivos do handbook:
   • knowledge/handbook/00_foundations/04_target_hardware_and_quality_contract.md
   • knowledge/handbook/00_foundations/02_benchmarking_and_quality_gates.md
   • knowledge/handbook/03_single_gpu/08_a5500_optimization_ladder.md
   • knowledge/handbook/02_bottlenecks/05_nsight_a5500_profiling_workflow.md
   • knowledge/handbook/09_reference/09_a5500_benchmark_runbook.md
   • knowledge/handbook/09_reference/10_reproducibility_and_claims_standard.md
3. Execute dit-ar --config config/autoresearch.json doctor.
4. Certifique-se de que o branch de pesquisa é autoresearch/<tag> e a árvore de trabalho está limpa.
5. Execute dit-ar ... init se esta for uma nova sessão.
6. Execute dit-ar ... baseline antes de alterar o código otimizado.

Recuperação de conhecimento

Antes de um experimento não trivial, pesquise no handbook:

dit-ar --config config/autoresearch.json search "<mecanismo + gargalo + termos modelo/hardware>"

Leia os arquivos Markdown mais relevantes. Use o handbook como a principal memória de pesquisa local. Quando ele não suportar uma hipótese, rotule a ideia como uma hipótese de pesquisa externa/nova, em vez de fingir que o handbook a recomenda.

Classificação de experimento

Use uma de:

• exact: mudanças de implementação/layout/escalonamento/memória destinadas a preservar o algoritmo;
• numerical: mudanças no modo aritmético, como comportamento FP16↔BF16 ou TF32;
• approximate: computação do modelo alterada/pulada, como menos passos, caches aproximados, corte de orientação, aproximação esparsa;
• quantization: qualquer caminho de baixo-bit de peso/ativação/atenção/armazenamento.

Quantização recebe automaticamente uma porta de qualidade de regressão zero estrita.

Loop manter/descartar

Para cada hipótese:

1. Inspecione as métricas atuais melhores e falhas recentes.
2. Pesquise/leia material relevante do handbook.
3. Declare a hipótese e a mudança esperada de gargalo.
4. Edite apenas caminhos mutáveis.
5. Execute uma verificação sintática/de fumaça barata se útil.
6. Faça commit do candidato.
7. Execute:

dit-ar --config config/autoresearch.json experiment \
  --classification <classe> \
  --description "<hipótese causal curta>"

8. Se MANTER, fique no commit e continue.
9. Se DESCARTAR, preserve os logs .autoresearch/, depois git reset --hard HEAD^ para retornar ao melhor anterior.
10. Se CRASH, corrija apenas se a implementação estiver trivialmente errada; caso contrário, descarte e prossiga.
11. Continue até ser interrompido manualmente.

Prioridades de pesquisa no A5500

Favor, aproximadamente nesta ordem:

• criação de perfil de ponta a ponta e atribuição de fase;
• seleção de backend de atenção para formas exatas;
• compilação/compilação regional e remoção de quebras de grafo;
• fusão de normas/modulação/operações ponto a ponto;
• CUDA Graphs para buckets de forma estável;
• ajuste de algoritmo/layout GEMM;
• eliminação de transferência e escalonamento de ciclo de vida de componentes;
• engenharia de 24 GB VRAM com offload/evicção/tiling;
• estratégias de dois A5500 com consciência de topologia, se disponível;
• Triton/CUDA/CUTLASS personalizado apenas com evidência de profiler;
• aproximações e quantização apenas atrás da firewall de qualidade total.

Nunca otimize uma métrica que o produto alvo não se importa apenas porque é fácil de melhorar.