O Zagitta/gpu-unlock é um módulo de kernel Linux que devolve às GeForce RTX 20, 30 e 40 a metade da taxa dos tensor cores que a Nvidia reserva às placas profissionais. Ele age no boot, antes de o driver da Nvidia assumir a placa, e não pede driver modificado nem gravação de VBIOS. O número que explica o interesse: uma RTX 3090 sai de 75 para 125 TFLOPS em BF16 nas medições reunidas pelo projeto, e a RTX 4090 alcança 329 TFLOPS de pico em multiplicação de matrizes. O repositório somava 11.329 estrelas e 1.107 forks em 27 de outubro de 2026, dez dias depois de aparecer. O módulo e o empacotamento são GPL-2.0-only, mas o firmware extraído do pacote da Nvidia continua sob os termos da própria Nvidia, e o projeto não reivindica autorização para redistribuí-lo.
O que é o gpu-unlock
O projeto é de um desenvolvedor identificado como Zagitta, escrito em C, na versão 2.0.0, com um único release publicado, o pacote para Unraid de 27 de outubro de 2026. Não existe site oficial, e o README diz isso de forma direta: o repositório é a única fonte legítima do projeto. A mesma seção avisa que sites, instaladores e moedas que se apresentam como gpu-unlock não têm relação com o autor, um alerta necessário porque o repositório traz endereços de doação em cripto e atrai clones.
A ideia não nasceu aqui. O cmpunlocker abriu o caminho em 2026 ao liberar memória e capacidade de cálculo nas placas CMP 170HX, o que rendeu inclusive verificação de bancada da LTT Labs em setembro. O trabalho de elias-gaeros com a RTX 4090 mapeou os registradores usados nesta versão. Antes disso, projetos como o nvidia-patch, de 2016, e o vgpu_unlock, de 2021, atacavam outros limites do mesmo tipo, sessões de NVENC e virtualização. A diferença do gpu-unlock é o alvo: a taxa de emissão de instruções de matriz, que é o que sustenta treino e inferência em FP16 e BF16.
O suporte é desigual e o README não esconde. Ampere, a linha RTX 30, aparece como estável, com mais de cem relatos de usuários. Ada, a RTX 40, e Turing, a RTX 20, seguem como experimentais. Blackwell, a RTX 50, está fora e o autor considera improvável que entre. É Linux apenas. Para Windows existe um port de terceiro, que o próprio autor diz não manter e recomenda usar com cautela.
O alcance muda conforme a geração porque o hardware muda. A Turing, que é a linha RTX 20, tem tensor cores em FP16, INT8 e INT4, sem BF16 e sem TF32, formatos que a Nvidia só introduziu na Ampere. Nela o ganho fica no FP16 com acumulação FP32. Na Ada entra também o FP8 com acumulação FP32, que o whitepaper da 4090 lista a 330,3 TFLOPS contra 660,6 no FP8 com acumulação FP16.
Como o desbloqueio acontece
O caminho é um exploit de firmware, não um ajuste de software. Durante o boot, o processador de segurança SEC2 executa um firmware Booter que recebe, verifica, decifra e carrega o firmware do GSP. Esse Booter tem um estouro de buffer que escreve na pilha, o que permite encadear trechos de código existentes e desviar o fluxo de execução. Descobrir isso foi possível porque a Nvidia publicou por um período imagens de debug do Booter cifradas com um esquema de chave de teste público, o índice 37, o que abriu o firmware para desmontagem. O explicador do projeto conta essa história passo a passo.
Com uma escrita de quatro bytes conquistada, o payload libera o que faltava. Ele grava 0xFFFFFFFF no registro FEAT_OVR_PLM, que controla quem pode escrever nos registradores de velocidade, e em seguida grava 0x88888888 em SS0 e 0x8 em SS1, os seletores que dizem à placa para rodar em taxa cheia. Depois vem um reset funcional e o driver normal da Nvidia assume uma GPU que ele acredita ser comum. Nada disso sobrevive a um corte de energia, e por isso o módulo mora no initramfs: ele precisa rodar antes do driver em todo boot, e volta a rodar na saída da suspensão para RAM.
A ativação é opt-in. Sem a opção gpu_unlock.targets=all na linha de comando do kernel, ou endereços PCI específicos no lugar de all, o módulo não faz nada. A instalação compila o módulo e o empacota para Arch, Debian e Ubuntu, Fedora e RHEL. Carregar o módulo à mão depois do boot não desbloqueia uma placa que o driver já ligou.
O que a Nvidia documenta sobre a metade da taxa
O ponto central da história não depende da palavra do projeto. O whitepaper da arquitetura Ampere publica, na tabela 9, a RTX 3090 com 71 TFLOPS em BF16 com acumulação FP32 e 142 TFLOPS em FP16 com acumulação FP16. A RTX A6000, que usa o mesmo GA102, aparece com 154,8 TFLOPS nas duas configurações. No whitepaper da Ada a RTX 4090 repete o padrão: 165,2 TFLOPS em FP16 com acumulação FP32 contra 330,3 em FP16 com acumulação FP16.
Os documentos provam a diferença de taxa entre consumidor e profissional, e nada além disso. Eles não declaram motivação comercial. A explicação de que a Nvidia limita a GeForce para empurrar a compra de placas caras é do autor do projeto e da comunidade, não uma admissão da empresa, e a versão generalizada dela, de que toda placa profissional roda no dobro, não se sustenta em todos os modelos. Na tabela da L40, os 181 e 362 TFLOPS do mesmo documento também não são duas acumulações: são a taxa densa e a taxa com esparsidade estrutural 2:4, como a nota de rodapé do whitepaper explica, e a placa aparece com um único valor de BF16, de 181 TFLOPS densos, sem a divisão por acumulação que a página da GeForce traz. Vale também não confundir o número do whitepaper com o do benchmark: os 75 TFLOPS antes do desbloqueio, citados pelo projeto, não são os 71 TFLOPS oficiais.
O que a IA ganha
Os ganhos divulgados são do projeto e dos relatos que ele reúne. Em multiplicação densa de matrizes, a RTX 3090 vai de 75 para 125 TFLOPS em BF16, a RTX 3090 Ti de 88 para 157 e a RTX 4090 de 165 para 329, esta última como taxa de pico. Em carga real, o README estima de 25% a 55% em prefill de LLM, de 25% a 50% em fine-tuning em BF16, de 30% a 55% em geração de imagem e de 50% a 60% em kernels de atenção. O resultado é bit a bit idêntico ao de antes, só a velocidade muda.
Existe medição de terceiro. O canal Digital Spaceport testou quatro RTX 3090 com Qwen 3.8 27B em vLLM, concorrência 1, e publicou script e tabela: prefill de 1.157 para 1.840 tokens por segundo em contexto de 2 mil tokens, e de 1.114 para 1.769 em 128 mil. A ressalva metodológica é do próprio teste, que mede o tempo até a primeira linha de streaming, não o tempo exclusivo de kernel, e roda uma requisição por profundidade. É evidência concreta, não um estudo controlado.
A própria página do projeto explica por que a RTX 4090 rende menos do que a taxa de pico sugere: ela esbarra no limite de energia de 450 W antes de saturar os tensor cores em multiplicações de matriz grandes, então a taxa dobrada aparece no GEMM e não necessariamente na carga real.
Nem toda carga acompanha. Um relato no issue 157, com uma RTX 4090 a 450 W e o repositório derivado JustAResearcher/gpu-unlock-ada, mediu 17% de ganho em BF16 e 56% em TF32, mas apenas 2,6% em prefill e 7% de queda na geração de tokens, queda que o autor do relato não investigou. A cobertura do TechPowerUp e do Tom’s Hardware também compilou esses relatos, sem bancada própria. Nenhum dos dois veículos mediu o desbloqueio por conta própria.
Para jogos, não muda nada
Esta é a parte que costuma se perder no entusiasmo. O limite que o gpu-unlock remove é o da taxa de emissão em FP16, BF16 e TF32 com acumulação FP32. Jogo não roda nesses formatos: ele usa FP32 puro e as unidades de rasterização, que nunca foram capadas. O README é explícito ao classificar a linha de jogos e de CUDA em FP32 como sem alteração. Cuidado com a leitura apressada da outra linha, a que diz que modelos INT8, FP8 e INT4 não mudam: ela vale para o modelo que realmente calcula nessas precisões. Modelos com pesos quantizados em 4 bits, no formato AWQ ou GPTQ, e as variantes GGUF do llama.cpp desquantizam os pesos para FP16 ou BF16 e acumulam em FP32, então entram no ganho. O próprio README estima de 25% a 55% no prefill com AWQ e GPTQ e de 0% a 15% com GGUF, este mais visível em contexto longo.
Quem espera mais quadros por segundo vai se decepcionar, e o texto serve para os dois lados: o projeto não promete isso e a medição independente também não encontrou. O ganho aparece em quem roda modelo local, treina ou ajusta modelo, gera imagem e vídeo em meia precisão ou processa atenção em GPU. Se a sua rotina é jogar, o módulo não tem nada a oferecer além do risco de instalar código de terceiros no kernel.
Riscos, falhas relatadas e o silêncio da Nvidia
Instalar um módulo que roda no initramfs significa entregar a esse código privilégio de root antes de qualquer outra coisa carregar. O risco não fica na GPU, fica no host inteiro, e inclui confiar nos blobs de firmware que o build extrai do pacote 610.43.03 da Nvidia. A licença ajuda pouco aqui: o aviso de firmware do projeto afirma que a licença dos módulos abertos não licencia o firmware da Nvidia, que o alvo inicial é empacotamento pessoal e local e que não há autorização de redistribuição reivindicada.
Os relatos de falha existem e são de disponibilidade, não de destruição. Um dono de RTX 3070 registrou travamento total em um de cinco boots com o desbloqueio ativo. Um usuário de RTX 3060 ficou com a placa indisponível depois de uma validação que falhou, e recuperou tudo ao remover o parâmetro e reiniciar. Um notebook com RTX 3060 desbloqueou no boot e perdeu os seletores depois, porque a placa desliga quando ociosa. Para esse caso o README indica desligar o gerenciamento de energia em tempo de execução com options nvidia NVreg_DynamicPowerManagement=0x00 em /etc/modprobe.d/, com resultado misto entre modelos. Não há caso confirmado de dano físico permanente, o que não é prova de segurança: o projeto tem dez dias e nenhum ensaio de longevidade.
A Nvidia não se manifestou. Não encontrei nota oficial, notificação de remoção, mudança de driver para bloquear o desbloqueio nem CVE ligada a este exploit. O registro de CVE-2026-98875 que circula junto do assunto é outro defeito, um ponteiro nulo no driver Nouveau, e não deve ser associado ao estouro do Booter. A classe da falha, porém, já era conhecida: um artigo de Jon Pry publicado no Zenodo em 26 de junho de 2026 documenta o estouro no coprocessador seguro das placas CMP 170HX. O modelo de ameaça dele exige root e controle do kernel, ou seja, não descreve um ataque remoto a uma GeForce que só está rodando inferência.
Principais dúvidas sobre o projeto
Funciona no Windows? Não de forma oficial. Existe um port de terceiro, o impacifist/Windows-GPU-UNLOCK, que o autor do projeto não mantém. Instaladores não oficiais circulam e o próprio README recomenda cautela com eles.
Funciona na RTX 50? Não. Blackwell está fora do suporte e o autor considera improvável que mude.
Preciso refazer a cada driver novo? Não. O desbloqueio acontece antes do driver carregar e não altera o driver. A exceção é a suspensão para RAM, que desliga a placa e apaga os seletores, resolvida por um notificador que roda antes do driver retomar. O módulo acrescenta cerca de um segundo ao despertar, e hibernação, a suspensão para disco, não é suportada.
Estraga a placa? Não há dano permanente confirmado nos relatos públicos. Há travamentos e placas que não inicializam até reiniciar, e a taxa maior consome mais energia e esquenta mais, com o gerenciamento de potência original intacto.
O gpu-unlock é a prova de que uma decisão de produto da Nvidia, documentada nos próprios whitepapers, podia ser desfeita por software antes de o driver existir. Para quem roda modelo local em GeForce RTX 30 e entende o que está instalando, o ganho é real e mensurável. Para quem joga, ou para quem não quer código de terceiros com root no boot, o cálculo é outro, e a resposta é deixar como está.
Fonte: gpu-unlock
