Adicione e teste kernels em uma biblioteca de kernels de GPU com compilação JIT

## Prepare uma instalação editável em que editar um kernel o recompile sozinho Use uma instalação editável que preserve as versões existentes do framework e do acelerador no ambiente. Desative a resolução isolada de dependências quando ela puder obter pacotes de runtime incompatíveis. Inicialize todos os submódulos de origem necessários antes de compilar ou testar. Trate a compilação just-in-time como o ciclo de desenvolvimento padrão. Edite os arquivos-fonte do kernel, execute um teste específico e deixe o hash do código-fonte acionar a recompilação. Não reinstale o pacote após cada edição do kernel, a menos que o próprio código de empacotamento tenha mudado. Limpe o cache JIT somente quando artefatos obsoletos fizerem parte do diagnóstico. Use pacotes de kernels pré-compilados somente quando um primeiro uso mais rápido ou a distribuição os exigirem. Mantenha os artefatos pré-compilados opcionais para o desenvolvimento normal. Defina explicitamente as arquiteturas de destino ao compilar para dispositivos diferentes da GPU local detectada. Limite os threads do compilador e as tarefas de compilação paralelas de acordo com a memória disponível. Estime a memória total de compilação multiplicando as tarefas pelos threads do compilador e pela demanda de cada thread. Não permita que os tamanhos dos parâmetros de teste causem esgotamento evitável da memória do dispositivo. Instale suporte a análise de desempenho somente quando forem necessárias medições precisas do hardware. Execute a formatação e os hooks do repositório antes da revisão. ## Grave arquivos gerados só em espaços de trabalho graváveis, nunca na instalação Represente cada cadeia de ferramentas de compilação por meio de uma interface de especificação comum. Dê a cada especificação um nome exclusivo, uma lista de fontes, opções do compilador, opções do vinculador e arquiteturas compatíveis. Use um modelo compartilhado de compilação e carregamento para coordenar busca no cache, bloqueio, compilação e carregamento. Mantenha explícito o ciclo de vida: tente carregar do cache, compile quando necessário e depois carregue o módulo compilado. Recuse a compilação JIT quando uma opção de desativação estiver definida e não existir um módulo válido em cache ou pré-compilado. Nunca grave arquivos gerados em diretórios de pacotes instalados, pois eles podem ser somente leitura. Mantenha os modelos de origem e os dados de pacotes pré-compilados como somente leitura. Grave o código-fonte renderizado e as unidades de compilação copiadas somente em um espaço de trabalho para fontes geradas. Grave arquivos de objeto, bibliotecas compartilhadas, metadados e arquivos de compilação somente no espaço de trabalho de artefatos JIT. Gere o manifesto de compilação com base na lista exata de fontes e nas opções de compilação. Permita substituir as localizações dos espaços de trabalho para ambientes compartilhados, temporários ou restritos. Use o contexto de arquitetura para combinar os dispositivos detectados com os destinos solicitados explicitamente. Limite um módulo às famílias de arquiteturas compatíveis antes do início da compilação. Falhe de modo claro quando nenhuma arquitetura solicitada for compatível. Não compile silenciosamente para uma família de dispositivos diferente. ## Adicione um kernel novo do código de dispositivo até a API pública Implemente código de dispositivo independente de framework usando ponteiros brutos e tipos de kernel portáveis. Mantenha os cabeçalhos do framework fora da camada reutilizável de inclusões do kernel. Adicione um iniciador na camada de vinculação para validar tensores e preparar os parâmetros de invocação. Exporte o iniciador por meio da FFI tipada entre linguagens do projeto. Calcule um URI de operação determinístico a partir dos parâmetros de especialização. Crie um diretório de geração por operação no espaço de trabalho gravável de fontes. Use um modelo somente quando for necessária uma especialização concreta de tipo ou parâmetro. Grave a configuração renderizada somente quando seu conteúdo for diferente. Copie as unidades de compilação necessárias para o diretório de geração. Retorne uma especificação de compilação contendo o URI, as fontes, as opções e os limites de arquitetura. Disponibilize uma API de alto nível com cache que reutilize os módulos carregados. Registre a operação para geração antecipada de pacotes quando a distribuição exigir. Exporte a API pública pelo ponto de entrada do pacote. Anexe um modelo de rastreamento que defina eixos, entradas, saídas e uma referência opcional. Para APIs de planejamento e execução, anexe o rastreamento ao método que realiza a execução. Adicione um exemplo realista de rastreamento, regenere os artefatos de definição de benchmark e confirme as saídas esperadas. Execute testes de consistência do rastreamento e de ponta a ponta após a regeneração. ## Pule GPUs não compatíveis nos testes e apoie a velocidade com checagem de resultados Execute a suíte completa de testes para validação ampla e testes específicos durante a iteração. Ignore deliberadamente o hardware incompatível por meio de funções auxiliares centrais de capacidade. Verifique tanto a capacidade computacional do dispositivo quanto o suporte do backend quando uma API expuser esses predicados. Mantenha explícitos os requisitos de arquitetura de cada funcionalidade. Não transforme uma arquitetura incompatível em falha de teste. Não ignore uma arquitetura compatível porque o dispositivo local é diferente. Escolha formatos de teste que exercitem o contrato sem causar omissões evitáveis por falta de memória. Cubra os caminhos de atenção, multiplicação de matrizes, mistura de especialistas, comunicação e utilitários afetados por uma alteração. Use ferramentas de inicialização para vários dispositivos em testes coletivos ou distribuídos. Execute benchmarks por meio de uma estrutura unificada que aceite backends comparáveis e configurações em lote. Prefira a medição de um analisador no nível do hardware e recorra a eventos do acelerador quando ela não estiver disponível. Registre qual mecanismo de medição produziu cada resultado de benchmark. Informe a mediana, a variação, a contagem de iterações, o formato da carga de trabalho, o tipo de dados, a arquitetura e o backend. Ative a verificação de referência ao comparar kernels. Não apresente alegações de velocidade sem verificações de correção e parâmetros reproduzíveis. Exija evidências de benchmarks e testes antes de aprovar um kernel sensível ao desempenho. ## Recompile os kernels em cache quando mudarem as fontes ou a GPU de destino Use um cache no processo para os módulos carregados e um cache em disco para os artefatos compilados. Invalide os módulos em cache quando mudarem as fontes, as opções, a arquitetura, os parâmetros ou a versão da biblioteca. Derive a identidade do cache do tipo de operação, dos parâmetros, dos hashes das fontes, das opções e da arquitetura de destino. Mantenha as chaves de cache exclusivas entre variantes de especialização e de cadeias de ferramentas. Armazene os metadados de compatibilidade junto aos artefatos e valide-os antes do carregamento. Proteja a compilação com bloqueios para que processos simultâneos não corrompam artefatos compartilhados. Para saídas DSL de arquitetura única, armazene um diretório de módulo com metadados e um objeto por especialização. Derive a arquitetura do destino de compilação DSL ou do dispositivo ativo. Invalide um módulo DSL quando mudar a versão do pacote do compilador ou o hash dos arquivos-fonte do kernel. Permita desativar o cache para diagnóstico, mantendo a reutilização ativada por padrão. Use macros de despacho ou código gerado para gerenciar espaços combinatórios de tipos de dados e tamanhos de bloco. Mantenha explícitas as opções de despacho e teste as combinações incompatíveis. Não adicione modelos onde o código-fonte direto for suficiente. Não permita que pacotes pré-compilados obsoletos contornem as verificações de compatibilidade de versão. Ignore as verificações de versão somente em um experimento intencional e diagnosticado com versões combinadas. ## Registre as entradas da API antes de rodar kernels para poder reproduzir falhas Registre as entradas da API antes da execução do kernel para que os parâmetros que provocam falhas sobrevivam a um erro do dispositivo. Mantenha o registro sem sobrecarga quando estiver desativado. Ofereça níveis graduais para nomes de chamadas, entradas e saídas e estatísticas custosas. Reserve as estatísticas e a busca por valores inválidos para diagnósticos explícitos de alto detalhamento. Ignore a coleta de estatísticas incompatíveis durante a captura de grafos. Limite os despejos de diagnóstico pela contagem de eventos e pelo tamanho total. Aceite filtros de inclusão e exclusão para que a captura custosa se concentre somente nas APIs relevantes. Escolha um formato de tensor portável quando os despejos precisarem ser movidos entre ambientes. Use um diretório dedicado e gravável para despejos. Ative a saída detalhada de compilação e os símbolos de depuração somente durante o diagnóstico de falhas. Examine em conjunto os arquivos-fonte gerados, os manifestos de compilação, os módulos compilados e os metadados de cache. Registre formatos, tipos de dados, arquitetura, opções e o backend selecionado ao reproduzir uma falha. Use informações de linha quando precisar mapear o código-fonte em um analisador ou depurador. Mantenha as configurações normais de otimização separadas das compilações de depuração. Trate as seleções forçadas de algoritmo ou backend como controles de diagnóstico, não como padrões de produção. Documente todo controle não padrão usado para reproduzir um resultado. ## Verifique os artefatos baixados e gere versões para uma lista explícita de GPUs Falhe de forma definitiva quando faltarem artefatos locais em ambientes offline ou bloqueados. Permita que um espelho confiável substitua o repositório de artefatos padrão. Verifique por padrão as somas de verificação dos artefatos baixados. Desative a validação das somas de verificação somente como auxílio temporário de depuração. Limite os downloads paralelos de artefatos. Prefira uma fonte local configurada antes de tentar um download. Mantenha explícitas e observáveis as opções de compilação e as substituições do iniciador. Mantenha separados os controles de registro do carregador de artefatos e os controles de registro de chamadas da API. Use uma medição estável no ajuste automático, incluindo um temporizador global de hardware quando a medição por eventos não for confiável. Permita substituir a detecção de computação confidencial para um diagnóstico controlado de integração contínua. Persista os resultados do ajuste automático somente com uma localização explícita de cache e um ambiente compatível. Carregue uma lista de bloqueio de táticas para evitar kernels que sabidamente travam ou falham na pilha atual. Mantenha as substituições experimentais de roteamento e seleção de kernels em seus padrões documentados. Compile antecipadamente os pacotes para uma lista explícita de arquiteturas. Gere os metadados de versão do pacote a partir de uma única fonte autoritativa de versões. Use incrementos de versão retrocompatíveis para kernels, suporte a dispositivos e correções de erros. Reserve alterações incompatíveis da API para um limite de versão arquitetural. ## Mantenha a API pública e a documentação alinhadas ao código dos kernels Use uma ABI tipada entre linguagens para que os mesmos kernels atendam a vários frameworks hospedeiros. Mantenha o tratamento de tensores específico do framework nas vinculações, e não nos cabeçalhos do dispositivo. Registre operações personalizadas no framework hospedeiro somente quando a compilação e a captura de grafos exigirem. Mantenha sincronizados a API do Python, o gerador JIT, a exportação das vinculações, o registro de compilação antecipada e as exportações do pacote. Comece pelo padrão de kernel funcional mais simples antes de adotar projetos avançados de espaços de trabalho ou de planejamento e execução. Atualize em conjunto as assinaturas de funções, os modelos, os iniciadores e os testes quando os parâmetros mudarem. Aprenda o estilo, a complexidade, a atitude defensiva e a eficiência estabelecidos com exemplos funcionais próximos. Documente desvios intencionais e escolhas de algoritmos críticas para o desempenho, junto às alternativas consideradas. Consulte a documentação autoritativa do conjunto de instruções e da cadeia de ferramentas para comportamentos específicos de arquitetura. Prefira o código-fonte das dependências incluído no projeto quando a documentação externa estiver obsoleta. Mantenha sincronizados com as APIs públicas os modelos de rastreamento e as definições geradas de benchmark. Atualize os exemplos e tutoriais de infraestrutura quando mudarem os padrões de registro, requisitos, FFI ou geração de código. Marque claramente as abordagens obsoletas ou retire-as das orientações atuais. Divulgue qualquer ajuda significativa de IA de acordo com a política de contribuições. Aprove somente quando fontes, artefatos gerados, caches, testes, benchmarks, exportações e documentação estiverem de acordo.