Kimi K2 vai ter que esperar
Ontem queria baixar o último modelo da Moonshot, o Kimi K2 Instruct. Um modelo bem promissor que há dias queria testar.
Vou fazer espaço, olho o disco, e me deparo com isso:
Disco: 927GB
Usado: 644GB
Livre: 283GB
Hmm. 283GB livres não está mal, mas que diabos está ocupando 644GB? Tenho o Mac bem limpo, não guardo filmes localmente, e uso a nuvem para quase tudo.
Começo a investigar. E então me lembro.
Os 45GB de águas-vivas
Já sabia que a Apple, em sua infinita sabedoria, havia decidido incluir 45GB de papéis de parede animados no macOS Sonoma. Vídeos em 4K a 240fps de águas-vivas flutuando, ondas quebrando, auroras boreais, e paisagens variadas.
Não pedi. Não quero. Mas lá estavam.
O que NÃO sabia é o que veio depois.
Plot twist: estão duplicados
Acontece que o macOS armazena esses vídeos em dois lugares diferentes:
| |
Oitenta e quatro gigabytes. Dos mesmos vídeos. Duplicados.
Porque aparentemente à Apple pareceu boa ideia ter uma cópia do sistema (propriedade do root) e outra do usuário (propriedade do fernando). Os mesmos 89 arquivos .mov. Os mesmos UUIDs. O mesmo conteúdo.
Não são hardlinks, são cópias reais
Pensei: “Beleza, talvez sejam hardlinks ou clones APFS. Mesmos arquivos, mesmo espaço em disco, tudo certo”.
Que nada.
| |
Cópias. Reais. Oitenta e quatro gigas de águas-vivas ocupando espaço real no meu SSD.
Um SSD de 256GB custa R$ 1.000 a mais
O que mais me irrita é o contexto. A Apple vende os Macs com SSDs ridiculamente pequenos pelo preço que cobram:
| Modelo | SSD Base | Upgrade para 512GB |
|---|---|---|
| MacBook Air M3 | 256GB | +R$ 1.200 |
| MacBook Pro 14" M3 | 512GB | +R$ 1.200 |
| Mac Mini M4 | 256GB | +R$ 1.200 |
E aí vão e instalam 84GB de papéis de parede duplicados.
Isso é um terço do SSD base de um MacBook Air. Um terço do disco para vídeos de águas-vivas que ninguém pediu.
O daemon que não para
O responsável por essa atrocidade é um processo chamado idleassetsd. É o daemon que gerencia o download e atualização desses papéis de parede.
E aqui vem o melhor: mesmo que você mude para um papel de parede estático, se em algum momento previsualizou os papéis animados, o idleassetsd baixa todos. E os duplica. E se você os apagar mas a proteção de tela continuar configurada com aerials, ele baixa de novo.
Tem gente nos fóruns da Apple relatando que o processo enchia o disco deles em loop infinito. Um reinício parava temporariamente, mas começava tudo de novo.
A Apple, claro, não fornece nenhuma forma de gerenciar isso pela interface. Você pode escolher quais papéis de parede quer, mas não pode apagá-los do mesmo lugar.
A solução
Passo 1: Certifique-se de que não tem um aerial como papel de parede atual. Eu uso uma imagem estática, então estou tranquilo.
| |
Passo 2: Pare o daemon e apague tudo.
| |
Passo 3: Prevenir que aconteça novamente. Isso é opcional mas recomendado se você é rancoroso como eu:
| |
A flag schg (system immutable) e uchg (user immutable) fazem com que nem mesmo o root consiga escrever nesses diretórios sem remover a flag primeiro. O idleassetsd tentará escrever, falhará silenciosamente, e seguirá sua vida.
84GB recuperados
Depois da limpeza:
Antes: 283GB livres
Depois: 367GB livres
Oitenta e quatro gigas. Um terço de um MacBook Air base. Recuperados.
Agora sim tenho espaço para o Kimi K2. E para o Llama 3.3. E para o Qwen 2.5. E para todos os modelos que quiser testar.
Há modelos demais para testar
E esse é o ponto. Estamos em 2026. Toda semana sai um modelo novo que precisa ser avaliado. DeepSeek, Kimi, Qwen, Llama, Mistral, Gemma… todos competindo por espaço nos nossos discos.
Não tenho tempo nem espaço no SSD para vídeos de águas-vivas em 4K a 240fps.
Desculpa Apple, mas entre suas águas-vivas e um modelo de 70B parâmetros que me ajuda a programar, a escolha é óbvia.
As águas-vivas vão embora.
A única água-viva boa é a salada de água-viva. Se você já provou 凉拌海蜇 num restaurante chinês decente, sabe do que estou falando. Crocante, fresquinha, com seu toque de vinagre e gergelim. Isso sim é um bom uso das águas-vivas.
Vídeos de 4K ocupando 84GB do meu SSD, nem tanto.