Modelo de 72B em um MacBook M2 Pro rendeu 1–2 tokens por segundo e superaqueceu o notebook

Uma história típica: você lê alguns artigos, digita ollama pull no terminal e pronto, tem "seu próprio agente de IA que conhece todo o código". O engenheiro de QA Egor Laptev, da SENSE, testou esse cenário em um MacBook Pro M2 Pro com 32 GB de memória e recebeu uma lição de manual sobre o que os tutoriais não contam.

O que deu errado

Ele pegou o Qwen Coder 72B e o comprimiu para Q2_K, cerca de 26 GB. Tecnicamente, o modelo coube em 32 GB. Na prática, o Ollama tomou quase toda a memória, o macOS entrou em swap intenso, o SSD passou a zumbir e o processador e a GPU ficaram em 100%. Como o Apple Silicon tem memória unificada, a carga recai sobre todo o sistema de uma vez. O navegador travava, a IDE congelava e, após alguns minutos, o thermal throttling foi acionado.

Limitar a memória não resolveu. Os conselhos padrão sobre 4 GB não funcionam: 26 GB não cabem neles, e o Ollama simplesmente retorna um erro. Foi preciso elevar o limite para 28 GB. O modelo funcionou, mas a 1–2 tokens por segundo. Uma consulta simples como "escreva um parser de JSON" leva um ou dois minutos. A temperatura caiu de mais de 95 °C para 85–90 °C; o notebook ficou utilizável para trabalho, mas não confortável.

Há também um custo oculto. O swap constante desgasta o SSD, então esse tipo de experimento não deve ser mantido por horas. O próprio autor, porém, informa que o notebook está intacto: o throttling foi uma reação de proteção, não uma falha.

O desktop ajudou, mas não de graça

Em um PC com RTX 4070 Ti Super (16 GB de VRAM), 32 GB de DDR5 e i5-13600KF, o mesmo modelo entregava 5–8 tokens por segundo. A resposta a uma consulta simples levava 10–20 segundos. Parte dos pesos ainda ficava na RAM do sistema, e isso era perceptível. A principal desvantagem é que, enquanto o agente trabalha, a placa de vídeo fica 80–90% ocupada. Só é possível jogar ou editar vídeo depois de parar o agente.

RAG: é aqui que a conta cresce

Um modelo sem contexto ainda não é um agente. Para que ele conheça o código, a documentação e os tickets, é preciso RAG: banco de dados vetorial, embeddings, busca. O autor estimou os volumes. Um projeto pessoal de 14 mil chunks ocupa cerca de 200 MB. A documentação interna de 1,4 milhão de chunks resulta em cerca de 20 GB. Um domínio completo de 14 milhões de chunks chega a 200 GB. O índice HNSW acrescenta de 30–50% de overhead. E se ainda houver fine-tuning do modelo, os estados do otimizador multiplicam a memória em cerca de 3–4 vezes.

Balanço de hardware: uma estação de trabalho com RTX 4090 ou A5000, 64 GB de RAM e 4 TB de SSD custará cerca de $6500. A eletricidade acrescenta $100–180 por ano. O mais caro, porém, é que um dispositivo pessoal se transforma em servidor.

O que fazer

A conclusão do autor é bastante sensata. Localmente vale manter modelos de 7B–14B em Q4_K_M ou Q8: pela estimativa dele, isso dá cerca de 90% da qualidade com um terço dos recursos. Servem para tarefas rápidas e para código privado. Raciocínio pesado, RAG de centenas de gigabytes e fine-tuning é melhor enviar para a nuvem ou para um cluster de GPUs.

As limitações também devem ser citadas. Trata-se de uma experiência isolada em um hardware específico, não de um benchmark. O Q2_K foi escolhido deliberadamente como teste de estresse, e o próprio autor admite que a qualidade desse modelo é baixa. Os números de armazenamento e custo são aproximados.

A lição prática é simples: antes de levar um 72B para um notebook, calcule a memória para os pesos, o contexto e o índice. Se faltar em pelo menos um desses itens, use um modelo menor ou a nuvem. E não confie em tutoriais que prometem que "é tudo simples".