Tempo de leitura: 5 minutos
Olá, é um prazer inenarrável estar mais uma vez escrevendo este post. Dividir uma GPU entre diferentes tarefas nem sempre significa que todas elas avançarão de maneira previsível. Um processamento pesado pode ocupar os recursos disponíveis justamente quando uma tarefa pequena e sensível à latência precisa ser executada. É nesse cenário que entram os green contexts, recurso apresentado pela NVIDIA para permitir um controle mais explícito sobre a distribuição do trabalho no CUDA 13.1.
A proposta parece simples: escolher quais recursos da GPU cada fluxo pode utilizar. Mas o detalhe importante está em como essa separação muda o comportamento de aplicações que executam múltiplas cargas simultaneamente. Em um teste descrito pela NVIDIA, uma tarefa crítica teve sua latência reduzida de 0,140 ms para 0,007 ms em uma GPU Blackwell com 148 SMs. A diferença não veio apenas de dar prioridade ao fluxo, mas de reservar recursos próprios para ele.
O que são green contexts no CUDA
Os green contexts permitem que uma aplicação selecione explicitamente um subconjunto dos recursos de execução da GPU e direcione trabalho para esse conjunto. Entre as possibilidades estão a divisão dos streaming multiprocessors (SMs) e o provisionamento de recursos de filas de trabalho, conhecidas como workqueues.
Isso é útil porque aplicações modernas frequentemente executam componentes independentes dentro do mesmo processo. Um kernel voltado para throughput pode rodar ao mesmo tempo que uma operação que precisa responder rapidamente. Também é possível ter uma etapa de pré-processamento concorrendo com a inferência de um modelo ou diferentes fases de um pipeline compartilhando a mesma GPU.
No modelo tradicional, esses componentes podem disputar os mesmos recursos de maneira difícil de prever. Mesmo quando há capacidade computacional disponível, diferentes trabalhos podem acabar associados às mesmas filas e sofrer uma serialização não intencional. Os green contexts foram projetados para tornar essa divisão mais explícita.
Como os green contexts controlam o trabalho da GPU
Uma aplicação pode criar um green context associado a uma determinada partição de recursos e, em seguida, criar streams vinculados a esse contexto. O trabalho enviado por esses streams passa a ser direcionado aos recursos selecionados, em vez de depender apenas do estado implícito do dispositivo ou do contexto da thread.
Na prática, a mudança preserva boa parte do modelo de programação baseado em streams do CUDA. A diferença é que o stream deixa de herdar silenciosamente o alvo a partir do dispositivo atual e passa a ser criado a partir de um identificador explícito, representado no Runtime API pelo tipo cudaExecutionContext_t.
A NVIDIA destaca que os green contexts são leves para criar e destruir e que essas operações não sincronizam implicitamente trabalhos não relacionados na GPU. Isso facilita a adoção em aplicações que precisam controlar apenas alguns fluxos, sem obrigar todo o programa a abandonar o modelo tradicional.
Green contexts e prioridades de streams
As prioridades de streams continuam sendo úteis, mas têm uma limitação importante: elas não interrompem blocos que já estão em execução em um SM. Se um kernel pesado ocupar todos os SMs, uma tarefa prioritária ainda pode precisar esperar até que algum recurso seja liberado.
Os green contexts atacam esse problema de outra forma. Ao reservar, por exemplo, oito SMs para uma carga crítica e deixar os 140 restantes para um processamento de fundo, a tarefa prioritária já tem um espaço definido para executar. A prioridade e a partição podem ser usadas juntas, mas cumprem funções diferentes.
O teste da NVIDIA com green contexts
Para demonstrar o efeito da técnica, a NVIDIA comparou três situações: uma partição criada com green contexts e stream de alta prioridade; um contexto padrão com stream de alta prioridade; e um contexto padrão com streams de prioridade igual.
O teste usou uma pequena carga inteira como tarefa crítica e um kernel de maior volume, executado em 20 lançamentos consecutivos, para saturar a GPU. Na configuração com 148 SMs, oito foram reservados para a tarefa crítica e 140 ficaram disponíveis para o processamento pesado.
Os resultados apresentados foram:
- Green context: 0,007 ms de latência para o kernel crítico, usando oito SMs dedicados.
- Contexto padrão com stream de alta prioridade: 0,140 ms.
- Contexto padrão com prioridades iguais: 3,727 ms.
Os números mostram que a prioridade de stream já reduz bastante a espera em relação à disputa sem prioridade. Ainda assim, ela não elimina o tempo necessário para que blocos do kernel pesado deixem os SMs. Com green contexts, a tarefa crítica pode começar nos recursos reservados, embora o processamento de fundo passe a contar com uma parcela menor da GPU.
Quando usar green contexts
Os green contexts fazem mais sentido quando uma aplicação executa múltiplas cargas independentes na mesma GPU e precisa de um comportamento mais previsível. Eles podem ser especialmente úteis em pipelines com várias etapas, sistemas de inferência, processamento de sensores e cenários de treinamento distribuído em que comunicação e operações matriciais precisam avançar simultaneamente.
Também vale considerar o recurso quando a aplicação sofre com pressão sobre workqueues ou quando o agendamento baseado apenas em streams não oferece controle suficiente. A técnica não é uma forma gratuita de aumentar a capacidade total da GPU: reservar SMs para uma tarefa reduz a quantidade disponível para outra. O benefício está em trocar uma disputa imprevisível por uma divisão de recursos mais controlada.
Essa é uma escolha parecida com separar faixas em uma estrada. O tráfego total não aumenta magicamente, mas um veículo que precisa passar rapidamente deixa de ficar preso atrás de uma fila que ocupa todas as faixas.
Como começar a usar green contexts no CUDA 13.1
Segundo a NVIDIA, o suporte aos green contexts está disponível no Driver API desde o CUDA 12.4 e passou a ser acessível também pelo Runtime API a partir do CUDA 13.1. Para começar, o desenvolvedor precisa consultar os recursos do dispositivo, definir a partição desejada, gerar um descritor e criar o contexto correspondente.
Depois disso, os streams devem ser criados a partir do green context, e os kernels podem continuar sendo lançados usando o fluxo de programação baseado em streams. Aplicações que desejam continuar direcionando trabalho para o dispositivo inteiro também podem manter o modelo tradicional. Quando uma API exigir um identificador explícito de contexto para atingir toda a GPU, a documentação indica o uso de cudaDeviceGetExecutionCtx().
Como o recurso é opcional e aditivo, a migração pode ser gradual. Uma aplicação não precisa reorganizar todos os seus componentes de uma vez: pode começar pela carga cuja latência ou previsibilidade seja mais importante e avaliar o impacto sobre os demais trabalhos.
Conclusão: o que os green contexts mudam
Os green contexts dão às aplicações CUDA uma maneira mais explícita de dividir os recursos de uma GPU entre cargas concorrentes. Em vez de depender apenas de prioridades e do agendamento padrão, o desenvolvedor pode reservar SMs e configurar workqueues para reduzir interferências entre componentes.
O resultado não é necessariamente mais desempenho agregado em qualquer cenário. A principal vantagem é a previsibilidade: uma tarefa crítica pode ter recursos próprios, enquanto uma carga de throughput continua executando na parte restante da GPU. No teste divulgado pela NVIDIA, essa mudança reduziu de forma expressiva a latência do kernel sensível ao tempo.
Para aplicações que estão evoluindo de um único fluxo dominante para pipelines com várias etapas e workloads simultâneos, os green contexts representam uma nova camada de controle. A pergunta deixa de ser apenas “qual tarefa tem prioridade?” e passa a incluir outra, mais decisiva: “quais recursos estão realmente reservados para ela?”.
