Matriz de benchmark PyTorch 2.13: o que testar antes das atualizações FlexAttention, CuTeDSL, torchcomms e FSDP2

PyTorch 2.13 é o tipo de lançamento que pode fazer uma equipe se sentir atrasada antes de executar um único trabalho. FlexAttention recebe mais atenção, Apple Silicon MPS é mais importante para o desenvolvimento local, CuTeDSL aponta para trabalho de kernel de nível inferior, torchcomms e FSDP2 alteram conversas de treinamento distribuído e o trabalho de memória continua em torno de camadas como nn.LinearCrossEntropyLoss.

Essa lista é útil. Não é um plano de atualização.

O blog oficial de lançamento do PyTorch e as notas de lançamento do GitHub são o mapa do que mudou. Eles não são prova de que sua carga de trabalho deve mudar esta semana. Trate cada valor atrativo de velocidade ou memória como um alvo de reprodução local. Se seus próprios scripts, hardware, fatias de dados, escolhas de precisão e caminho de reversão não suportarem a declaração, a declaração será apenas o resultado de outra pessoa.

A mesma disciplina se aplica a equipes que já pensam em atender mudanças, como em LLM servindo planos de migração. Isole a mudança, meça-a e torne a reversão chata. O hábito de evidências de document AI test benches também pertence aqui: cada resultado de benchmark precisa de uma fonte, ID de execução, ambiente, comando e decisão.

A questão não é se o 2.13 é mais rápido

Uma atualização de estrutura raramente falha porque o recurso do título é falso. Ele falha porque a equipe testa um caminho e envia para outro.

Um benchmark de atenção CUDA pode parecer bom, enquanto a exportação falha em um tempo de execução downstream. O MPS pode executar a demonstração, enquanto um padrão esparso real retrocede ou fica sem memória. Um trabalho distribuído pode mostrar uma etapa mais rápida, enquanto a recuperação do ponto de verificação se torna difícil de confiar. A CPU pode ser tratada como um substituto enfadonho e, em seguida, o CI bloqueia a liberação porque um pequeno caminho do operador foi alterado.

Aqui está a versão direta: um benchmark que não pode desencadear uma reversão é apenas um gráfico.

PyTorch 2.13 deve ser testado como uma mudança de plataforma. Isso significa a mesma carga de trabalho, e não uma carga de trabalho mais bonita, nos back-ends que a equipe realmente usa. Laptops Apple Silicon, servidores CUDA, trabalhadores ROCm, trabalhos de CPU CI e clusters distribuídos não falham da mesma maneira. Uma matriz de teste útil aceita isso antecipadamente.

A matriz de teste PyTorch 2.13 multiplataforma

{
  "matrix": "optijara-cross-platform-pytorch-2-13",
  "versions": ["current_baseline", "pytorch_2_13"],
  "backends": ["mps", "cuda", "rocm", "cpu", "distributed"],
  "gates": ["correctness", "latency", "throughput", "peak_memory", "determinism", "compile_export", "rollback"],
  "decisions": ["adopt", "isolate", "defer", "rollback"]
}

Comece com o controle

A execução de controle é onde muitos programas de benchmark quebram silenciosamente.

Congelar a versão atual do PyTorch, confirmação do modelo, fatia do conjunto de dados, tokenizer ou versão de pré-processamento, política de sementes, modo de precisão, formato do lote, comprimento da sequência e máscara de atenção. Registre o modelo de hardware, o back-end do acelerador, as versões do driver ou do tempo de execução, o inicializador distribuído, as configurações do compilador e as variáveis ​​de ambiente. Se a carga de trabalho tiver modos de treinamento e inferência, baseie ambos.

Em seguida, mantenha as partes chatas idênticas. Mesmos roteiros. Mesmas entradas. Mesma política de aquecimento. Mesma janela de medição. Não compare uma execução cuidadosamente ajustada do PyTorch 2.13 com uma linha de base obsoleta que ninguém toca há meses.

Separe o aquecimento de compilação da medição em estado estacionário. Capture latência p50 e p95 onde a latência é importante, tokens ou amostras por segundo onde a taxa de transferência é importante, pico de memória, desvio numérico, tempo de compilação, quebras de gráfico, custo de reinicialização e modo de falha. A mesma regra de congelamento de carga de trabalho aparece em testes de IA multimodal em tempo real: se o teste mudar durante a avaliação, o resultado se tornará difícil de confiar.

FlexAttention em MPS e CUDAFlexAttention merece testes construídos a partir dos padrões reais de atenção da equipe. A atenção densa não é suficiente se a migração for motivada por comportamento esparso ou de longo contexto. Inclui máscaras causais, padrões de janela deslizante, padrões de blocos esparsos, sequências longas, precisão mista e passagens para trás. Os documentos oficiais do FlexAttention definem a superfície da API. O guia de perfil Hugging Face ajuda as equipes a ler os rastreamentos de atenção em vez de confiar em um número de rendimento agregado.

No Apple Silicon, os testes de MPS devem ultrapassar o sucesso da importação. Execute o mesmo padrão esparso, máscara, formato de lote e comprimento de sequência planejados para o trabalho real. Compare com a linha de base anterior do MPS e, sempre que possível, com uma referência CUDA ou CPU para ver se está correto. Fique atento a operadores não suportados, fallback silencioso, picos de memória e desvios de precisão mista.

No CUDA, adicione verificações retroativas determinísticas. Repita as execuções semeadas. Compare gradientes com tolerâncias acordadas. Mantenha o antigo SDPA ou caminho de atenção personalizado ao lado do FlexAttention até que o novo caminho ganhe seu lugar. Se o comportamento determinístico fizer parte do requisito de liberação, o portão não terá velocidade média. O portão é exatidão repetível sob as mesmas configurações de seed, precisão e back-end.

Kernel, memória e portas do compilador

CuTeDSL deve ficar em uma pista de protótipo, a menos que a equipe já possua manutenção de kernel customizado. O teste não é apenas velocidade. É propriedade. Quem depura o código? Qual hardware é necessário? Como a equipe irá compará-lo com o comportamento padrão do PyTorch? Com que rapidez ele pode ser desativado quando um driver, forma ou modo de precisão é alterado?

nn.LinearCrossEntropyLoss pertence a uma pista de memória e correção. Compare pico de memória, tempo de passo, comportamento de logits, comportamento de precisão mista, sinais de convergência e compatibilidade com a pilha de treinamento. Um ganho de memória só será valioso se o caminho de perda ainda treinar o modelo pretendido e não criar novo trabalho de integração.

Para torch.compile e export, use portas em vez de otimismo. Contar quebras de gráfico. Registrar sobrecarga de compilação. Teste formas dinâmicas reais, não apenas uma demonstração limpa de formas fixas. Verifique a exportação quando o modelo sair do Python para outro runtime. A postagem de fusão de normalização de 10 de julho é um contexto arquitetônico útil porque a fusão pode alterar o tráfego de memória e a estrutura do kernel. Isso ainda não elimina a necessidade de provas específicas da carga de trabalho. Para uma lente de portabilidade mais ampla, compare isso com teste de portabilidade computacional de IA, onde a escolha de back-end deve ser comprovada sob restrições práticas.

Testes Distribuídos e Fallback

A sobreposição de torchcomms e FSDP2 precisa de testes de sistema distribuído, não de testes de caixa de seleção. Para torchcomms, meça o comportamento coletivo, a latência, a largura de banda, o tratamento de falhas, a disponibilidade de back-end e a compatibilidade com as ferramentas de lançamento existentes. Confirme se o monitoramento ainda explica o que acontece quando um trabalho fica lento.

Para sobreposição de FSDP2, meça o tempo da etapa, a espera de comunicação, o pico de memória, o salvamento e o carregamento do ponto de verificação, o tratamento do estado do otimizador e o dimensionamento em contagens de nós controlados. Não aprove a sobreposição de uma etapa rápida. Um caminho melhor é aquele que treina, verifica, recupera e deixa evidências suficientes para que os operadores depurem a próxima falha.As verificações de ROCm e CPU mantêm os caminhos alternativos honestos. Uma equipe pode não treinar seu maior modelo em CPU, mas os trabalhos de CPU geralmente protegem CI, desenvolvimento local e testes de fumaça. O ROCm pode fazer parte de uma frota mista. Um sucesso apenas de CUDA não deveria aprovar uma frota que também depende de laptops Apple Silicon, trabalhadores ROCm ou substitutos de CPU.

Erros e advertências comuns

O erro mais comum é alterar a carga de trabalho ao mesmo tempo que altera a estrutura e, em seguida, dar crédito ao quadro pelo resultado. Mantenha a carga de trabalho fixa. Outro erro é testar o caminho feliz CUDA enquanto ignora laptops MPS, trabalhadores ROCm, trabalhos de exportação e CPU CI. Um terceiro é tratar o desvio numérico como uma reflexão tardia porque o rendimento melhorou.

Outras armadilhas são menos glamorosas. As equipes contam o aquecimento de compilação como velocidade de estado estacionário. Eles relatam rendimento médio, mas perdem o pico de memória. Eles testam comprimentos de sequência mais curtos do que os usos de produção. Eles repetem as afirmações das notas de lançamento como se essas afirmações fossem garantias. Eles ignoram a reversão porque o benchmark parecia limpo.

As advertências devem ser escritas antes do início da execução. O custo de implementação pode compensar um pequeno ganho de referência. Hardware, driver, precisão e formato da carga de trabalho podem mudar a resposta. Os dados de referência podem precisar de controles de privacidade se os prompts, rótulos ou amostras forem confidenciais. O comportamento do cache pode fazer com que execuções repetidas pareçam melhores do que a operação de primeira execução. A qualidade da avaliação determina se o desvio de precisão é visível. APIs de protótipo e caminhos de kernel personalizados podem adicionar trabalho de manutenção que o número de velocidade não mostra.

Adie a adoção do PyTorch 2.13 quando padrões esparsos críticos não forem testados, verificações reversas determinísticas falharem, caminhos de exportação não forem suportados, recuperação distribuída for frágil, orçamentos de memória forem excedidos ou a reversão depender de heroísmo manual. Isolamento não é fracasso. Muitas vezes é a resposta dos adultos.

Lista de verificação de implementação e plano de medição

Use uma janela de benchmark de duas semanas se a mudança afetar treinamento de produção, desenvolvimento de modelo ou dependências de atendimento. A primeira semana deve abranger revisão de origem, captura de linha de base, congelamento de ambiente e testes de nó único. A segunda semana deve cobrir testes distribuídos, portas de compilador e exportação, ensaio de rollback e uma decisão canário.

O plano de medição deve registrar latência p50 e p95, taxa de transferência, pico de memória, tempo de compilação, quebras de gráfico, desvio numérico, repetibilidade determinística, comportamento do ponto de verificação e duração da reversão. Armazene IDs de execução, detalhes de hardware, versões de software, comandos, identificadores de fatia de conjunto de dados, URLs de origem, portas de aprovação ou falha e notas de reprodução.Defina limites antes de executar os testes. Um caderno de pesquisa, um treinamento noturno, um serviço de inferência voltado para o cliente e um trabalho de ajuste fino distribuído não devem compartilhar o mesmo limite. Decida o que justificaria a adoção antes que os gráficos existam. Caso contrário, o benchmark torna-se uma negociação posterior ao fato.

Se uma equipe precisar de ajuda para transformar notas de lançamento em testes reproduzíveis de infraestrutura de IA, a Optijara pode ajudar a projetar a matriz, automatizar a captura de evidências e transformar atualizações de estrutura em planos de adoção medidos. PyTorch 2.13 deve ganhar carga de trabalho de adoção por carga de trabalho, backend por backend.