A PyTorch Foundation lançou o PyTorch 2.12 na quarta-feira — 2.926 commits de 457 contribuidores desde o 2.11. A manchete de desempenho é uma troca de backend numa operação de nicho que se mostra importar muito: `linalg.eigh` em lote no CUDA é até 100× mais rápido após a depreciação do backend MAGMA legado em favor do cuSolver, com as heurísticas de dispatch atualizadas para usar `syevj_batched` incondicionalmente. Workloads que antes rodavam em minutos — comuns em computação científica e em qualquer passo de treino de ML que precisa de decomposições próprias de matrizes em lote — agora rodam em segundos, fechando finalmente uma lacuna de longa data com o CuPy. À parte, o Adagrad se junta ao Adam, AdamW e SGD com `fused=True`, executando o passo do otimizador num único kernel CUDA em vez de vários lançamentos separados. O lowering `addcdiv` baseado em FMA no XPU traz paridade numérica bit-a-bit entre `torch.compile` e modo eager em GPUs Intel — pequeno isoladamente mas carregado se você vinha perseguindo comportamentos de otimizador compilado irreproduzíveis.
A história estratégica é o pivô cross-backend. O PyTorch 2.12 introduz `torch.accelerator.Graph`, uma API device-agnóstica para captura e replay de grafos que unifica a abstração sobre implementações específicas do backend como `torch.xpu.XPUGraph`. Cada backend se registra via uma interface leve `GraphImplInterface`; `c10::Stream` e `torch.Stream` agora expõem `is_capturing()` como o substituto backend-agnóstico do `is_current_stream_capturing` específico do dispositivo. O suporte inicial cobre CUDA e XPU (Intel), com extensibilidade para backends fora da árvore via `PrivateUse1`. Essa é a contraparte em nível de framework da dinâmica do fosso CUDA coberta mais cedo esta semana: o PyTorch está explicitamente facilitando para aceleradores não-CUDA participarem do modelo de programação de captura de grafo, que é a camada onde o Indutor e a maior parte do trabalho de desempenho vive. Os usuários do ROCm ganham segmentos de memória expansíveis, coletivos de memória simétrica rocSHMEM, e pipelining do FlexAttention no mesmo release — o caminho da AMD recebeu um empurrão perceptível.
Mais duas mudanças para sinalizar para builders. Primeiro, `torch.export.save` e `torch.export.load` agora serializam corretamente o dtype `float8_e8m0fnu` usado como expoente de bloco compartilhado nos formatos de quantização Microscaling (MX) — MXFP4, MXFP6, MXFP8. Até agora, modelos usando essas técnicas de quantização agressivas não podiam ser exportados via o caminho padrão de implantação do PyTorch; times enviando LLMs para ambientes restritos em custo ou edge tinham que inventar serialização custom. Essa lacuna foi fechada. Segundo, o controle de fluxo `torch.cond` agora pode ser capturado e reproduzido dentro de CUDA Graphs via os nós IF condicionais do CUDA 12.4 — anteriormente, branching dependente de dados forçava fallback para CUDA graph trees porque a avaliação do branch acontecia na CPU. Com o 2.12, a avaliação do branch fica na GPU dentro de uma única captura de grafo (backends eager e cudagraphs; suporte Indutor planejado). Para workloads estilo agente ou RL com controle de fluxo dependente de dados, isso tira um penhasco real de desempenho.
Para builders: esse é um release de baixa fricção se você já está no track 2.x — a maioria dos ganhos é transparente (dispatch do eigh, Adagrad fundido, FMA addcdiv) e não exige mudanças de código. O fix de export Microscaling é aquele para levantar imediatamente se você entrega modelos quantizados; clone o exemplo na documentação e re-teste seu pipeline de export. A API torch.accelerator.Graph é majoritariamente relevante se você foca em Intel XPU ou constrói um acelerador custom — o significado de longo prazo é que o PyTorch agora está abstraindo explicitamente a captura de grafo entre backends, o que é a fundação que qualquer desafiante sério do CUDA precisa construir em cima. Times de treino distribuído deveriam olhar as adições ncclx + gloo do FlightRecorder e o novo `seq_num` do NCCL para correlação de coletivos entre ranks — os dois são melhorias concretas de qualidade-de-vida para debugging. As notas do release merecem leitura end-to-end se você mantém um pipeline de treino; os itens manchete acima são uma amostra, não a lista completa.