A NVIDIA disponibilizou o CUDA Toolkit 13.5, marcando a transição do suporte à arquitetura de GPUs Vera Rubin para o status de disponibilidade geral (GA). A atualização vai muito além do suporte a um novo hardware, introduzindo alterações estruturais profundas na forma como os sistemas operacionais gerenciam os recursos da GPU.
Para ambientes de produção, o lançamento resolve gargalos históricos de compartilhamento de carga, integra subsistemas nativos do kernel Linux para roteamento de processos e altera os modelos de driver suportados no ecossistema Windows, aposentando tecnologias antigas.
Fim do TCC no Windows e expansão no ecossistema Arm
A chegada da arquitetura Rubin consolida uma mudança no modelo de drivers da NVIDIA para sistemas operacionais da Microsoft. A partir desta geração, o suporte ao modo Tesla Compute Cluster (TCC) foi totalmente descontinuado.
Aplicações e ferramentas de implantação que assumiam o uso do TCC precisam migrar obrigatoriamente para o Windows Driver Display Model (WDDM) ou para o Microsoft Compute Driver Model (MCDM). O modelo MCDM atua como um driver focado exclusivamente em computação, sendo a alternativa direta para servidores e estações de trabalho que não necessitam de saída de vídeo.
No campo da arquitetura Arm, o suporte ao Windows on Arm (que atingiu o status GA na versão 13.4) foi expandido. O CUDA 13.5 habilita o funcionamento do NVIDIA DGX Station for Windows nesta arquitetura. Além disso, a biblioteca matemática cuBLAS recebeu suporte funcional para rodar GPUs Blackwell (incluindo as estações de trabalho da série GB300) nativamente no Windows on Arm, permitindo que os desenvolvedores executem cargas de trabalho aceleradas sem precisarem trocar de plataforma.
Otimização profunda para Linux no Multi-Process Service (MPS v3)

O gerenciamento de recursos compartilhados (NVIDIA MPS) recebeu atualizações significativas na versão 3, apoiando-se diretamente em recursos do kernel Linux para melhorar o isolamento e o roteamento de processos.
O grande destaque para ambientes Linux é o roteamento baseado em cgroup v2. Administradores agora podem mapear uma árvore cgroup v2 diretamente para um namespace do MPS. Quando os clientes se conectam por meio do soquete principal do daemon, eles são roteados de forma automática para esse namespace. Essa integração nativa elimina camadas extras de configuração manual para cargas de trabalho em contêineres e clusters gerenciados por orquestradores modernos.
A contabilidade de memória também ganhou um mecanismo de segurança voltado para falhas no sistema operacional. Caso as notificações de limite do cgroup falhem ou se mostrem não confiáveis, o MPS agora conta com um fallback baseado em pesquisa ativa (polling). Forçando a flag force_polling=true, o MPS lê diretamente o uso atual e os limites da memória durante as decisões de expulsão (eviction), garantindo que a estabilidade do compartilhamento não dependa exclusivamente da entrega perfeita de notificações do kernel.
O MPS v3 também introduziu:
- Balanceamento de carga em partições SM: Cargas de trabalho agora podem tomar recursos emprestados de outras partições ociosas usando a flag
--max-chunks, enquanto partições sem clientes podem emprestar seus recursos ativando--shareable=true. O sistema recupera os recursos emprestados automaticamente antes de reatribuí-los, mantendo a previsibilidade para a aplicação original. - Atribuição de SM por namespace: O uso da variável de ambiente
CUDA_MPS_SM_PARTITIONpor cliente não é mais necessário para definir partições. Agora, a seleção é feita uma vez por namespace e aplicada a todos os clientes roteados para ele. - Fatiamento de tempo ponderado: Administradores podem definir um tempo base de processamento (timeslice) e escaloná-lo por servidor MPS, dando turnos de computação mais longos para cargas de trabalho que exigem mais tempo ininterrupto de GPU.
Domínios de localidade e extração máxima dos multiprocessadores (SMs)
O CUDA 13.5 muda a forma como o hardware da GPU pode ser subdividido. Até então, as partições padronizadas de contexto verde utilizavam a mesma contagem de Streaming Multiprocessors (SMs) por domínio, o que garantia uniformidade, mas deixava SMs excedentes sem uso fora dessas partições.
A nova flag cudaDevSmResourceGroupLocalityDomainSupplementalSms, combinada à identificação do domínio, permite incorporar os SMs extras às partições selecionadas. A consequência prática é a utilização de 100% das unidades de processamento da GPU. Como o tamanho das partições pode ficar irregular, os desenvolvedores devem utilizar o modo de descoberta na API cudaDevSmResourceSplit() para consultar a quantidade exata de SMs em cada partição e distribuir a carga matemática adequadamente.
Evolução no CUDA Python e execução sobreposta
A biblioteca principal cuda.core atingiu a versão 1.2 no ecossistema Python, trazendo controles mais próximos do que é possível em C++. A API copy_batch() permite enviar múltiplas cópias de buffer por meio de uma única chamada de driver, com opções para controlar o comportamento de sobreposição e as dicas de localização de memória.
Para hardware mais recente (GPUs com capacidade de computação 9.0 ou superior), o Python agora suporta o Programmatic Dependent Launch (PDL). Quando ativado na configuração de lançamento (programmatic_stream_serialization=True), kernels que cooperam entre si podem sobrepor sua execução no mesmo stream CUDA. Um kernel dependente consegue iniciar processamentos independentes antes mesmo de o kernel anterior ser totalmente finalizado.
Os Grafos CUDA (CUDA Graphs) ganharam flexibilidade. Aplicações agora podem atualizar parâmetros de kernel, cópias de memória e callbacks em nós de execução sem precisarem instanciar o grafo novamente, facilitando a reutilização da estrutura gráfica conforme os parâmetros da aplicação mudam em tempo real. Cópias de memória em lote unidimensionais (cudaMemcpyBatchAsync) também passaram a ser suportadas nativamente na captura de streams de grafos.
Interoperabilidade e comunicação direta no CUDA Tile
O CUDA 13.5 expandiu as capacidades do CUDA Tile, permitindo comunicação multi-GPU diretamente dentro dos kernels. Utilizando ponteiros unicast, um kernel pode acessar a memória de outra GPU interligada via NVLink. Com ponteiros multicast e operações dedicadas de multimemória, é possível realizar reduções e armazenamentos em várias GPUs conectadas por malhas NVSwitch (com suporte ao protocolo NVIDIA NVLink SHARP).
O lançamento também traz uma prévia pública de interoperabilidade entre CUDA Tile e o modelo SIMT (Single Instruction, Multiple Threads). Kernels escritos em cuTile Python ou CUDA Tile C++ podem chamar diretamente funções de dispositivo de bibliotecas SIMT tradicionais (como NVSHMEM, CCCL Coop e MathDx) sem precisar sair do kernel e transitar os dados pela memória global. Os dados já presentes em registradores ou na memória compartilhada podem ser processados imediatamente pela função da biblioteca.
Otimizações matemáticas focadas em IA: CCCL, cuBLAS e cuSPARSE
O pacote CCCL 3.5 introduziu o cub::DeviceBatchedTopK, um algoritmo fundamental para a inteligência artificial, responsável por selecionar rapidamente os maiores ou menores itens de forma independente em vários segmentos. Ele é fortemente utilizado para seleção de tokens durante a geração de texto em LLMs e está integrado à biblioteca FlashInfer.
No cuBLAS, a implementação do esquema Ozaki-II foi expandida para suportar atualizações simétricas de rank-k em precisão dupla (FP64) nas GPUs NVIDIA Ampere e mais recentes. Essa mudança acelera rotinas como fatorações de Cholesky. Nas GPUs NVIDIA Blackwell (como a B200), as atualizações simétricas nativas em FP64 (SYR2K, HER2K) chegam a ser 1,5 vez mais rápidas sem exigir nenhuma alteração no código da aplicação.
Na manipulação de matrizes esparsas, o cuSPARSE introduziu suporte a índices mistos. A biblioteca permite o uso de offsets de 64 bits em conjunto com índices de 32 bits, possibilitando o cálculo de matrizes muito maiores enquanto mantém o uso de memória bem abaixo do que seria necessário com uma indexação puramente de 64 bits em todas as estruturas.
Compilação antecipada e legibilidade de diagnóstico
Na cadeia de ferramentas de desenvolvimento, o comando nvprune recebeu a flag --precompile. Ela permite compilar o código de dispositivo intermediário (PTX, TileIR) diretamente para binários nativos SASS/ELF durante a etapa de empacotamento. Isso elimina o tempo gasto com compilação Just-In-Time (JIT) no momento em que a aplicação é iniciada no cliente, beneficiando distribuidores de pacotes que têm provedores de nuvem ou arquiteturas de GPU específicas como alvo conhecido.
A ferramenta de diagnóstico cuobjdump também foi remodelada para melhorar a inspeção de arquivos binários CUDA. Atributos específicos e metadados que antes eram exibidos apenas como blocos hexadecimais agora aparecem em quatro colunas descritivas (Tipo, Vinculação, Visibilidade e Outros). O novo formato padroniza a leitura e espelha a experiência já conhecida pelos desenvolvedores Linux acostumados ao utilitário readelf -s.
Por fim, os próprios kernels ganharam poder de decisão sobre o gerenciamento de tensores. O CUDA 13.5 estendeu a instrução PTX tensormap.replace, permitindo que o kernel altere diretamente o modo de endereçamento fora dos limites do Tensor Memory Accelerator (TMA). Isso resolve exceções de endereço ilegal em computações onde parte de um bloco de dados cruza a fronteira física das dimensões reais do tensor, algo comum no treinamento da arquitetura de Mistura de Especialistas (MoE) e convoluções de IA.
