DiT-AutoResearch A5500

DiT AutoResearch A5500 Skill

Utiliza este skill al optimizar la inferencia de Diffusion Transformer en hardware RTX A5500/Ampere.

Reglas no negociables

• Lee program.md antes de actuar.
• Trata knowledge/handbook/00_foundations/04_target_hardware_and_quality_contract.md como la sobreescritura del proyecto para consejos genéricos de hardware/precisión.
• La calidad es una restricción dura, no un objetivo ponderado.
• La cuantización solo puede probarse si el suite de benchmarks fijo muestra ninguna regresión de calidad/precisión requerida. Nunca conserves un candidato cuantizado con una puntuación de benchmark requerida inferior.
• No modifiques el corpus de benchmarks, el evaluador de calidad, el harness de rendimiento ni otros fixed_paths durante una sesión.
• Solo edita rutas listadas en mutable_paths.
• Establece primero la línea base sin modificar.
• Compara la calidad del candidato con la línea base original, no con el candidato anterior.
• Compara el rendimiento con el mejor candidato actual en el carril objetivo del branch.
• Una hipótesis causal por commit.
• Prefiere optimizaciones exactas de implementación antes que aproximaciones numéricas o algorítmicas.
• Mide en A5500. No importes números de aceleración de H100/B200 como resultados esperados en A5500.
• FlashAttention-2/SDPA son rutas de atención relevantes para Ampere; FA3/FA4 y características específicas de Hopper/Blackwell son referencias de investigación, no rutas nativas del objetivo.

Inicio obligatorio

1. Lee program.md por completo.
2. Lee los siguientes archivos del 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. Ejecuta dit-ar --config config/autoresearch.json doctor.
4. Asegúrate de que el branch de investigación sea autoresearch/<tag> y el árbol de trabajo esté limpio.
5. Ejecuta dit-ar ... init si es una sesión nueva.
6. Ejecuta dit-ar ... baseline antes de modificar código optimizado.

Recuperación de conocimiento

Antes de un experimento no trivial, busca en el handbook:

dit-ar --config config/autoresearch.json search "<mecanismo + cuello_de_botella + términos_modelo/hardware>"

Lee los archivos Markdown más relevantes. Usa el handbook como la memoria de investigación local principal. Cuando no respalde una hipótesis, etiqueta la idea como una hipótesis de investigación externa/nueva en lugar de fingir que el handbook la recomienda.

Clasificación de experimentos

Usa una de:

• exact: cambios de implementación/layout/planificación/memoria destinados a preservar el algoritmo;
• numerical: cambios en el modo aritmético, como comportamiento FP16↔BF16 o TF32;
• approximate: cómputo del modelo modificado/saltado, como menos pasos, cachés aproximadas, corte de guía, aproximación dispersa;
• quantization: cualquier ruta de pesos/activaciones/atención/almacenamiento de baja precisión.

La cuantización recibe automáticamente una puerta de calidad estricta de regresión cero.

Bucle de mantener/descartar

Para cada hipótesis:

1. Inspecciona las métricas actuales mejores y los fracasos recientes.
2. Busca/lee material relevante del handbook.
3. Indica la hipótesis y el cambio esperado en el cuello de botella.
4. Edita solo rutas mutables.
5. Ejecuta una comprobación rápida de sintaxis/smoke si es útil.
6. Realiza el commit del candidato.
7. Ejecuta:

dit-ar --config config/autoresearch.json experiment \
  --classification <clase> \
  --description "<hipótesis causal breve>"

8. Si MANTENER, permanece en el commit y continúa.
9. Si DESCARTAR, conserva los logs de .autoresearch/, luego git reset --hard HEAD^ para volver al mejor anterior.
10. Si CRASH, corrige solo si la implementación es trivialmente incorrecta; de lo contrario, descarta y sigue adelante.
11. Continúa hasta que se detenga manualmente.

Prioridades de investigación en A5500

Favorece, aproximadamente en este orden:

• perfilado de extremo a extremo y atribución de fases;
• selección del backend de atención para formas exactas;
• compilación/compilación regional y eliminación de roturas de grafo;
• fusión de normas/modulación/operaciones punto a punto;
• CUDA Graphs para buckets de formas estables;
• ajuste de algoritmo/layout de GEMM;
• eliminación de transferencias y planificación del ciclo de vida de componentes;
• ingeniería de 24 GB de VRAM con offload/evicción/tiling;
• estrategias de dos A5500 con conocimiento de topología si están disponibles;
• Triton/CUDA/CUTLASS personalizados solo después de evidencia del perfilador;
• aproximaciones y cuantización solo detrás del cortafuegos de calidad completo.

Nunca optimices una métrica que no importe al producto objetivo solo porque sea fácil de mejorar.