PyTorch 2.15 torna novo NCCL padrão e amplia suporte a GPUs e Apple Silicon

O PyTorch 2.15 muda a base técnica de treinamento e inferência distribuídos: a nova versão torna padrão um backend reescrito de comunicação NCCL, amplia o suporte a GPUs NVIDIA, AMD e Intel, adiciona recursos relevantes para Apple Silicon e encerra o suporte oficial ao Python 3.10. Publicada em 28 de outubro de 2026, a atualização interessa tanto a equipes que treinam modelos grandes em clusters quanto a quem mantém pipelines de inferência e extensões C++.

O ponto central não é uma nova API isolada. O PyTorch 2.15 consolida mudanças no caminho crítico entre computação e comunicação: como GPUs trocam gradientes, como o framework registra travamentos, como kernels são escolhidos em hardware diferente e como versões de CUDA, ROCm e Python entram na matriz suportada. Para organizações brasileiras que operam infraestrutura própria ou contratam capacidade em nuvem, esses detalhes influenciam tempo de diagnóstico, custo de GPU e risco de atualização.

Em resumo: o que muda no PyTorch 2.15

• NCCL reescrito como padrão: o backend usado para comunicação entre GPUs NVIDIA passa a ser o caminho padrão para grupos nccl.
• Depuração de travamentos: um flight recorder grava informações pós-morte quando uma operação coletiva trava, reduzindo a dependência de reproduzir manualmente falhas de cluster.
• Inferência mais rápida: há melhorias para decodificação NVFP4 em GPUs NVIDIA Blackwell e para cargas de decode e MoE em Apple Silicon.
• Mais plataformas: a versão cobre CUDA 13.2 como wheel padrão, wheels CUDA 13.4, ROCm 10.0, novos caminhos para AMD e Intel XPU, além de Python 3.11 a 3.15.
• Mudanças de compatibilidade: Python 3.10 deixa de ser suportado e macOS 14 deixa de ter suporte para aceleração MPS.

O backend NCCL reescrito deixa de ser opt-in

Em treinamento distribuído, os processos em GPUs diferentes precisam sincronizar tensores, gradientes e estados. Em máquinas NVIDIA, esse tráfego normalmente passa pelo NCCL, biblioteca de comunicação coletiva da NVIDIA. No PyTorch 2.14, o backend reescrito havia aparecido como prévia e exigia adoção explícita. No 2.15, ele passa a atender por padrão todos os grupos de processo que usam nccl.

A mudança importa porque comunicação é um dos pontos mais difíceis de diagnosticar em treinamento multi-GPU. Um único processo lento, uma falha de rede ou um comportamento inesperado em um rank pode parar todo o job. Segundo o anúncio, o novo backend cria comunicadores de forma antecipada com o grupo de processo e pode usar um caminho rápido de reconfiguração para reduzir a reinicialização quando há tolerância a falhas compatível com versões recentes de NCCL.

Há duas rotas de retorno caso uma equipe encontre regressão: definir TORCH_DIST_USE_NCCL2=0 ou usar o nome de backend nccl-legacy. Isso não elimina a necessidade de testes, mas oferece uma saída operacional para quem atualizar bibliotecas de produção e precisar comparar comportamento antes de uma reversão completa do ambiente.

Flight recorder: evidência quando um coletivo trava

O recurso mais prático da atualização é o flight recorder independente de backend. Quando uma operação coletiva entra em hang, o mecanismo grava no disco um retrato do que cada rank fazia. O watchdog também publica o estado de saúde em um servidor de depuração; um timeout em um rank pode disparar dumps nos demais.

Na prática, isso não “conserta” deadlocks. O ganho é transformar uma falha que antes podia exigir repetição cara de um job em dados para análise: qual operação estava pendente, quais processos avançaram e em que ponto o grupo deixou de progredir. Em clusters caros, onde horas de GPU podem ser perdidas até identificar um gargalo, uma trilha de diagnóstico é uma melhoria de confiabilidade, não apenas de conveniência.

Controle mais fino para FSDP2 e pipeline parallelism

O PyTorch 2.15 também amplia controles em FSDP2 e paralelismo de pipeline. O FSDP fragmenta parâmetros entre processos para viabilizar modelos que não caberiam inteiros em uma única GPU. A nova versão permite manter parâmetros sensíveis à precisão, como gates de roteadores em modelos mixture-of-experts e pesos de normalização, em fp32 enquanto outras partes permanecem em bf16.

Além disso, a acumulação de gradientes pode ser capturada em uma única CUDA Graph, e o tipo de gradiente pode ser definido por parâmetro. No paralelismo de pipeline, buffers de recebimento passam a ser alocados pouco antes do uso e saídas de forward podem ser liberadas após o envio. A intenção é diminuir pressão de memória e expor melhor o custo de comunicação em etapas de treinamento.

Esses controles são classificados como APIs instáveis no anúncio. Portanto, são candidatos para benchmarking e experimentação controlada, não uma justificativa para alterar de imediato o código de produção sem validação de convergência, uso de memória e recuperação de falhas.

Inferência: Blackwell, Apple Silicon e modelos MoE

Na inferência de modelos generativos, a fase de decode gera um token por vez e costuma ter perfil diferente do prefill. O PyTorch 2.15 ajusta o NVGEMM para decode em NVFP4, formato de baixa precisão associado a GPUs NVIDIA Blackwell. A versão reduz lançamentos adicionais de kernels e tenta sobrepor melhor operações dependentes, um tipo de otimização que pode elevar a utilização de GPU em servidores de LLM.

No Apple Silicon, a atualização adiciona torch.float8_e4m3fn ao backend MPS, suporte a _scaled_mm e uma rota rápida para grouped_mm. O anúncio informa ganho de 1,32x a 1,34x em tokens por segundo no decode de MoE em um M3 Ultra para esse caminho específico. Esse número não deve ser generalizado para todos os modelos, tamanhos de lote ou Macs: é uma medição de um cenário delimitado pelo próprio projeto.

O backend MPS também recebe APIs públicas de streams, como torch.mps.Stream, current_stream e o contexto torch.mps.stream. Para desenvolvedores que testam localmente em Macs antes de enviar uma carga para a nuvem, isso aproxima o modelo de controle de execução já conhecido em CUDA.

Compatibilidade: CUDA, ROCm, Intel XPU e Python

O wheel padrão passa a usar CUDA 13.2, e a equipe disponibiliza wheels CUDA 13.4 para Linux x86_64, Linux aarch64 e Windows. As wheels de CUDA 13.4 trazem suporte experimental a GPUs NVIDIA Rubin. No ecossistema AMD, o PyTorch 2.15 acrescenta wheels ROCm 10.0 e passa a construir as wheels ROCm sobre os pacotes TheRock; em vez de embutir bibliotecas ROCm, a instalação passa a trazê-las como dependência pip correspondente.

Para AMD, a versão cita FlyDSL em gfx950 e Tensor Data Mover em gfx1250 (MI450) em caminhos de compilação e atenção. Para Intel XPU, entram kernels SYCL de função livre, melhorias de IPC e de pool de memória, além de mais visibilidade de profiling em cenários multi-GPU. O efeito mais amplo é reduzir a concentração de novidades em uma única pilha de hardware, embora maturidade, disponibilidade de drivers e desempenho variem muito por plataforma.

Na linguagem, o PyTorch 2.15 suporta Python 3.11 a 3.15, incluindo builds free-threaded 3.14t e 3.15t; torch.compile passa a incluir Python 3.15. A contrapartida é objetiva: Python 3.10 não recebe mais wheels nem testes de CI. Ambientes que ainda dependem dessa versão devem planejar a atualização do interpretador antes de adotar o PyTorch 2.15.

Checklist antes de atualizar um ambiente de produção

1. Congele o ambiente atual. Registre versões de Python, PyTorch, CUDA ou ROCm, drivers, NCCL/RCCL e dependências de extensões nativas.
2. Teste comunicação distribuída separadamente. Rode um job pequeno que exercite inicialização, all-reduce, checkpoint e encerramento; não use apenas um teste de importação.
3. Valide memória e precisão. Para FSDP2, compare pico de VRAM, estabilidade da perda e tipo dos gradientes com a configuração anterior.
4. Reproduza a carga de inferência. Meça prefill, decode, latência de cauda e throughput no mesmo modelo, quantização, lote e sequência usados pela aplicação.
5. Prepare rollback. Documente o uso de TORCH_DIST_USE_NCCL2=0 ou nccl-legacy para investigar uma regressão do novo backend sem improvisar durante incidente.

Limitações e pontos que exigem cautela

• Muitas novidades de distribuição, kernels e profiling continuam marcadas como instáveis; a interface ou o comportamento podem mudar.
• Gains publicados para NVFP4, MoE ou Apple Silicon são específicos de hardware e carga. Não são promessa de aceleração uniforme.
• Atualizar PyTorch sem alinhar driver, runtime CUDA/ROCm, extensões compiladas e imagem de contêiner pode introduzir incompatibilidades difíceis de identificar.
• macOS 14 perde suporte para aceleração MPS. Usuários podem até executar partes do framework, mas deixam de ter uma configuração testada e corrigida pelo projeto.

Análise do NoticIA

O sinal mais relevante do PyTorch 2.15 é que o framework está tratando comunicação, observabilidade e diversidade de aceleradores como parte do produto principal. Durante anos, muitos times associaram otimização de IA quase exclusivamente a trocar o modelo ou comprar GPUs mais rápidas. A versão mostra que, em cargas distribuídas, a eficiência depende igualmente de como processos se coordenam, de como falhas são investigadas e de como o runtime explora cada arquitetura.

Para o mercado brasileiro, isso reforça uma prioridade prática: equipes que investem em treinamento próprio ou inferência de alto volume devem medir sua pilha inteira, não apenas comparar preço por hora de GPU. Uma atualização que reduz tempo de diagnóstico de um hang, evita desperdício de VRAM ou melhora decode em hardware já disponível pode ter efeito financeiro maior que uma pequena troca de modelo. A adoção, porém, deve ser gradual: a presença de rotas de rollback no NCCL é um convite a testar com método, não a atualizar às cegas.

Conclusão

O PyTorch 2.15 não é uma versão focada em marketing de modelos, mas em tornar a infraestrutura de IA mais previsível e mais abrangente. O novo NCCL padrão, o flight recorder, os avanços para FSDP2, Blackwell, AMD, Intel e Apple Silicon e a atualização da matriz de compatibilidade dão motivos concretos para avaliação técnica. A decisão correta para produção é executar benchmarks representativos e validar o plano de rollback; para novos ambientes, a versão passa a ser uma referência mais moderna para hardware e Python atuais.