Ollama no Mac: a memória mente
Rodar modelo local no Mac é fácil. Saber quanta memória ele usa de verdade não é: em 4 de outubro o RSS dizia 15 GB e o footprint físico passava de 62 GB.
Em 4 de outubro, somei o RSS (memória residente, a parte que está na RAM) dos processos de modelo no meu Mac de 48 GB. O total foi cerca de 15 GB. Parecia confortável. Depois olhei o footprint físico (memória que o sistema atribui ao processo) dos mesmos processos. Passava de 62 GB, mais do que a RAM da máquina.
Eu usava o RSS para medir o peso da estrutura local. A consulta /api/ps do Ollama
também mostrava menos memória do que a máquina segurava. O resto deste texto explica o
que roda local, por que roda e como passei a medir.
O que roda local e por quê
Mantenho modelos no Mac só para os agentes do meu assistente: casa, pessoal, o broker de
segredos, embeddings (representações numéricas de textos) e rerank. Trabalho pesado com
texto vai para as tags :cloud do Ollama Cloud, que usa o mesmo daemon (servidor que
fica rodando em segundo plano). O resto não precisa ocupar a memória da minha máquina.
A medição de 4 de outubro mostra quanto essa memória custa.
Os embeddings são o exemplo mais claro. Desde 29 de junho, bge-m3 usa vetores (listas de números) com 1024 dimensões (posições numéricas). É o único modelo de embedding usado nas tabelas pgvector (recurso do PostgreSQL que guarda esses vetores): memórias de agentes, notas do vault e trechos de projeto. Aposentei nomic-embed-text. Vetores de modelos diferentes não se comparam. Manter dois modelos significava manter dois espaços de vetores. Agora há um só.
O modelo pequeno é granite4.1:8b, com cerca de 6 GB. Ele atende o agente do assistente
doméstico. O rerank escolhe quais trechos ajudam mais depois da busca. Ele roda em
PyTorch (biblioteca usada para cálculos de modelos) e usa MPS (recurso do Mac para
calcular usando o processador gráfico), configurado por device="mps". Antes de usar
a GPU do Mac, o código confere
torch.backends.mps.is_available().
Três números para a mesma pergunta
A pergunta era quanta memória os modelos usam. Duas medidas dos mesmos processos, mais o teto da máquina, todas de 4 de outubro:
Mesmos processos, duas medidas. O RSS somado ficou em cerca de 15 GB; o footprint físico passou de 62 GB. A RAM da máquina é 48 GB.
Ver dados
| RSS somado | ~15 GB |
|---|---|
| RAM da máquina | 48 GB |
| Footprint físico | >62 GB |
O /api/ps do Ollama também mostrava menos que o footprint. Os dois números que eu
tinha para responder "quanto está usando" eram menores que a memória ocupada na máquina.
Nos Macs com Apple Silicon (processadores da Apple), a memória é unificada. O processador principal e a GPU (processador gráfico) usam a mesma memória. Parte do que o modelo ocupa pode ficar fora do RSS. Pode ser memória wired da GPU (memória da GPU mantida na RAM) ligada ao Metal (tecnologia gráfica da Apple), partes da memória comprimidas ou swap (espaço no disco usado como memória). Não medi qual parte pesou mais. O sistema atribui o footprint físico ao processo. Se ele passa da RAM, parte pode estar comprimida ou no swap. Isso já mostra algo sobre o estado da máquina antes de comparar modelos.
Quando quero saber quanto cabe, olho o footprint, não o RSS.
Baixado não é aplicado
O segundo número otimista apareceu em 16 de outubro. O app do Ollama tinha baixado a atualização 0.40.5. Depois de reiniciar, o servidor (programa que entrega os modelos) continuava na versão 0.40.4. A atualização foi baixada, mas não aplicada.
O servidor entrega os modelos, então a versão dele é a que importa. Pela interface do app, você confere o que foi baixado. Para saber qual versão está respondendo, pergunte ao servidor.
O que ficou
Duas regras. Para memória, olho o footprint dos processos. Não uso RSS para calcular
quanto cabe. Para a versão, consulto /api/version no servidor em vez de confiar no
que o app mostra.
Só precisei dessas regras depois de ver 15 GB num dia em que a máquina segurava mais de 62.