Controle de ventoinha no Mac para desenvolvedores
Resposta rápida: em um Mac moderno, desenvolvedores não conseguem definir uma curva de ventoinha personalizada — o firmware da Apple é quem controla o RPM da ventoinha, e no Apple Silicon até os workarounds que ferramentas antigas usavam são retomados em segundos pelo próprio daemon térmico do macOS. O que você consegue controlar é visibilidade e timing: ver o calor chegando e agir (ou deixar algo agir por você) antes que um build longo, uma stack de containers ou a execução de um modelo local seja limitada por throttle ou o Mac precise se proteger sozinho. Este guia mostra o que o controle de ventoinha no Mac realmente significa hoje, comparando Intel e Apple Silicon, os comandos nativos e gratuitos que mostram o que está acontecendo agora mesmo, onde o caminho DIY (faça você mesmo) chega ao limite, e o workflow consciente da temperatura que o LidRun usa em vez disso.
Por que cargas de trabalho de desenvolvimento esquentam o Mac
Compilar um projeto grande, rodar uma stack de containers Docker ou servir um modelo local mantém a CPU — e no Apple Silicon, muitas vezes a GPU e o Neural Engine também — perto do limite máximo por minutos ou horas, não por segundos. É esse consumo sustentado, e não um pico rápido, que realmente eleva a temperatura do chip.
Quando o SoC esquenta o suficiente, o macOS aplica throttle para se proteger: os clocks caem, e aquele build que estava voando dez minutos atrás desacelera no meio da execução. Você pode ver isso acontecer com os próprios olhos, de graça, no Terminal: rode pmset -g therm e olhe a linha CPU_Speed_Limit. Em 100 você está a toda velocidade; qualquer valor abaixo disso significa que você está em throttle agora mesmo, ao vivo, sem precisar de nenhum app de terceiros.
Nesse momento, o instinto é querer acelerar as ventoinhas no talo e forçar a barra. Em um Mac moderno, esse instinto esbarra direto em quão travado o hardware está — e é justamente essa parte que a maioria dos conselhos sobre controle de ventoinha ignora.
O que o macOS realmente deixa você controlar (e o que não deixa)
Duas coisas diferentes recebem o nome de "controle de ventoinha", e é aí que a maior parte da confusão começa. Ler as ventoinhas — RPM atual, faixa mínima/máxima, temperatura do chip — é permitido em qualquer Mac, Intel ou Apple Silicon. Escrever um novo RPM-alvo, ou seja, mandar de fato uma ventoinha girar mais rápido do que o firmware quer, é uma operação privilegiada de hardware, e no Apple Silicon isso praticamente não fica disponível para nenhum app, não importa como ele foi construído.
Por baixo do capô, acionar uma ventoinha no Intel é uma escrita SMC (System Management Controller) em duas etapas: virar uma chave de modo para "manual" e depois escrever um RPM-alvo. Macs Intel anteriores ao T2 geralmente aceitam essa escrita sem drama. Os Macs com chip T2 (a geração de MacBook Pro/Air por volta de 2018–2020, iMac Pro, Mac Pro) são uma armadilha específica: eles aceitam a troca para modo manual, mas depois rejeitam silenciosamente a escrita real do RPM-alvo — então uma ferramenta que só checa a primeira etapa reporta "controle de ventoinha ativado" em um hardware que nunca chega a girar diferente. No Apple Silicon, a ventoinha fica dentro do próprio "system mode" do firmware, e uma escrita direta em modo manual é rejeitada de cara. Algumas ferramentas contornam isso com uma chave de unlock não documentada, mas mesmo assim o daemon thermalmonitord do macOS retoma o controle para a curva do firmware em questão de segundos, a menos que esse unlock seja mantido ativamente — um caminho frágil e não suportado, que a Apple pode fechar em qualquer atualização do sistema, não uma API de verdade.
Vale dizer isso sem rodeios, porque boa parte do marketing de controle de ventoinha não diz: qualquer ferramenta que promete controle manual de ventoinha completo e confiável em um Mac da série M está exagerando o que a plataforma realmente permite hoje. O LidRun não promete controle de RPM de ventoinha no Apple Silicon, e seria desonesto insinuar o contrário — a própria checagem de capacidade do LidRun nunca assume que uma escrita funcionou, e em hardware M1 até M4/M5 o resultado volta como "somente monitoramento" na grande maioria das vezes.
Guia relacionadoUma alternativa ao Macs Fan Control para desenvolvedoresA forma gratuita e nativa de checar o que está acontecendo
Antes de sair atrás de qualquer app, vale saber que o macOS já vem com duas formas gratuitas de ver o estado térmico real, sem precisar instalar nada. O pmset -g therm no Terminal imprime CPU_Speed_Limit e CPU_Scheduler_Limit — quando qualquer um dos dois cai abaixo de 100, você está em throttle. Funciona igual em Intel e Apple Silicon e não exige nenhuma permissão especial.
O sudo powermetrics --samplers smc -i1000 -n1 vai um nível mais fundo e imprime a temperatura real do die da CPU, e, na maioria dos Macs Intel, o RPM da ventoinha em tempo real. Ele precisa de sudo porque está lendo dados brutos de sensor. No Apple Silicon, a parte do RPM da ventoinha nessa saída tem se mostrado inconsistente de uma versão do sistema para outra; a leitura de temperatura é a parte que se mantém confiável ali.
O que o macOS não traz é nenhuma interface gráfica para isso — o Monitor de Atividade mostra porcentagem de CPU e uma pontuação de Energia, nunca temperatura ou velocidade de ventoinha, e é exatamente essa lacuna que as ferramentas de menu bar de terceiros existem para preencher. Opções gratuitas como Stats (um monitor de menu bar open-source bastante popular) leem temperatura e RPM de ventoinha sem escrever nada; o Macs Fan Control lê sensores de graça em qualquer Mac e adiciona presets de RPM e controle manual no hardware Intel mais antigo que ainda aceita a escrita. Nenhum dos dois muda o teto do Apple Silicon descrito acima — eles estão lendo a mesma porta trancada, só com uma janela melhor para enxergar dentro dela.
Onde o caminho DIY chega ao limite
Ficar de olho em uma janela do Terminal ou em uma leitura de menu bar funciona bem para um build de cinco minutos que você está acompanhando ao vivo. Isso para de funcionar no momento em que a execução é longa ou sem supervisão — um build longo no Xcode, um fine-tune rodando a noite toda, uma stack do Docker Compose que você inicia e sai de perto. Ninguém fica de fato rodando pmset -g therm a cada trinta segundos durante uma hora.
Nos Macs Intel onde as escritas de RPM realmente pegam, forçar as ventoinhas por conta própria carrega um risco menor, mas real: se o processo que está escrevendo trava ou é morto sem devolver a ventoinha para o modo "auto", ele pode deixar uma ventoinha travada numa velocidade fixa — irritantemente barulhenta parada, ou presa baixa se o processo morreu no meio de uma rampa enquanto o Mac ainda estava trabalhando. Esse é um modo de falha conhecido de escritas SMC feitas de improviso, não uma hipótese, e é por isso que qualquer ferramenta que faça isso deveria sempre restaurar a curva automática do firmware ao sair ou travar, não só num encerramento limpo.
Especificamente nos Macs Intel com T2, a armadilha funciona ao contrário: uma ferramenta pode reportar "controle de ventoinha ativado" porque a escrita de modo deu certo, enquanto a escrita real de RPM é rejeitada silenciosamente por baixo — então você acredita que tem controle e não tem. Fechar essa brecha significa confirmar que a escrita do RPM-alvo realmente pegou antes de chamar um Mac de controlável, não só checar que a troca de modo não deu erro.
Um workflow consciente da temperatura em vez de perseguir RPM
Se você não consegue comandar as ventoinhas de forma confiável — o que, na maior parte da frota atual, você não consegue —, o objetivo prático deixa de ser controle e passa a ser consciência mais timing: saber quando uma execução está esquentando e agir antes que ela sofra throttle ou o Mac precise se proteger.
O LidRun lê temperatura e estado das ventoinhas continuamente e mostra isso na menu bar, então um build quente fica visível em vez de ser uma surpresa. Nos Macs onde a escrita de RPM de ventoinha é de fato confirmada como possível — principalmente hardware Intel mais antigo e T2 — ele acelera as ventoinhas numa curva proporcional: silencioso abaixo de aproximadamente 62°C (56°C com a tampa fechada, quando o calor tem menos para onde escapar), subindo suavemente conforme o chip esquenta, e empurrado para o máximo quando a temperatura passa de cerca de 90°C ou o próprio limite de velocidade da CPU despenca para 60% ou menos, partindo do raciocínio de que, nesse ponto, um build travado importa mais do que uma ventoinha silenciosa. Os presets Quiet, Balanced, AI Workload e Emergency Max ficam por cima dessa curva para quando você quer inclinar o comportamento na mão.
Essa aceleração de ventoinha é deliberadamente não apresentada como um mecanismo de segurança — as ventoinhas são um recurso de conforto e recuperação de throttle, não o que impede um Mac de superaquecer. Uma checagem separada e independente, baseada na temperatura do SMC somada ao próprio sinal de pressão térmica do macOS, trata calor sustentado em torno de 98–100°C, ou um limite de velocidade da CPU despencando abaixo de aproximadamente 30–50%, como sério o suficiente para agir independentemente do que as ventoinhas estejam fazendo. E se uma escrita de ventoinha ficar pendurada no meio do caminho — um crash, um processo morto —, um lease de 90 segundos faz com que ela reverta automaticamente para a curva do próprio firmware em vez de ficar travada.
Onde o LidRun se encaixa — e onde, honestamente, não se encaixa
No Apple Silicon, o LidRun não aciona suas ventoinhas. Ele observa o estado térmico — temperatura do SMC onde é possível ler, throttle da CPU e o próprio sinal de pressão térmica do macOS — e recua em vez de forçar: uma configuração chamada "Não segurar quando o Mac está quente" (ativada por padrão) impede que uma nova execução monitorada comece enquanto o Mac já está rodando quente, e, se você estiver usando o Closed-Lid, uma segunda configuração, "Encerrar Closed-Lid se o Mac esquentar demais" (também ativada por padrão), encerra esse override em calor genuinamente crítico, para que o Mac possa aplicar throttle e dormir do jeito que foi projetado, em vez de ficar quente e sem supervisão embaixo da tela fechada.
Nos Macs Intel e T2 onde as escritas de ventoinha são confirmadas como funcionais de verdade, essa mesma leitura térmica também aciona a rampa proporcional de ventoinha descrita acima — um único quadro térmico, duas alavancas diferentes, dependendo do que o hardware realmente permite.
A promessa por trás de qualquer um dos dois caminhos é a mesma: agente rodando, mantém o Mac acordado; agente terminou ou o Mac não está seguro, libera e deixa dormir. Essa é uma régua diferente de uma simples leitura de temperatura — o objetivo não é uma ventoinha mais silenciosa, é não perder um build sem supervisão ou uma execução de agente por causa de um calor que você não viu chegando, sem fingir que o LidRun consegue forçar uma ventoinha que não vai se mexer. Se você roda builds longos, containers ou modelos locais sem supervisão, vale a pena testar o LidRun na sua própria máquina para ver o que o seu Mac está realmente fazendo enquanto você não está olhando.
O LidRun mantém seu trabalho rodando com a tampa fechada, com proteção de bateria e temperatura embutida.
Já tem o LidRun? Leia o guia de configuração →
Novo no LidRun? Veja os preços →
Perguntas frequentes
Nos Macs Intel e T2 onde a escrita de RPM de ventoinha é de fato confirmada como funcional, sim — o LidRun acelera as ventoinhas numa curva proporcional e oferece os presets Quiet, Balanced, AI Workload e Emergency Max. No Apple Silicon, não: o LidRun não promete controle de RPM de ventoinha ali. Em vez disso, ele lê temperatura e estado de throttle continuamente e usa isso para condicionar sua sessão de keep-awake.
No Apple Silicon, a ventoinha fica sob o próprio "system mode" do firmware. Uma escrita direta para forçar controle manual é rejeitada de cara, e até o unlock não documentado que algumas ferramentas usam é retomado pelo daemon térmico do macOS em questão de segundos, a menos que seja mantido ativamente — um caminho frágil e não suportado, não uma API de verdade. Ler temperatura e RPM de ventoinha funciona bem em qualquer lugar; escrever um novo RPM-alvo é o que fica bloqueado.
Sim. Rode pmset -g therm no Terminal — se CPU_Speed_Limit marcar abaixo de 100, você está em throttle agora mesmo. O sudo powermetrics --samplers smc -i1000 -n1 vai além e imprime a temperatura real do die da CPU, além do RPM da ventoinha na maioria dos Macs Intel. Os dois já vêm junto com o macOS; nenhum dos dois exige um app de terceiros.
Ele lê temperatura e throttle continuamente e mostra isso na menu bar, então uma execução quente fica visível em vez de ser uma surpresa. "Não segurar quando o Mac está quente" (ativada por padrão) bloqueia o início de uma nova execução monitorada enquanto o Mac já está rodando quente, e, se o calor cruzar um limite crítico, o LidRun pode encerrar um override de Closed-Lid para que o Mac durma em vez de ser empurrado ainda mais longe.
O LidRun é compatível com macOS 13 Ventura ou posterior em ambos. O monitoramento térmico — leituras de temperatura e throttle — funciona do mesmo jeito nos dois. O controle de RPM de ventoinha fica limitado aos Macs Intel e T2 que de fato confirmam a escrita; no Apple Silicon, o LidRun permanece apenas no modo de monitoramento.