Jeff Bruchado
Voltar para o Blog

Harbor da Apple em 2026: Como Rodar IA Local no Mac e Quanta Memória Seu Hardware Precisa

Olá HaWkers, em 10/11/2026 o 9to5Mac e o MacRumors noticiaram que a Claris, a subsidiária da Apple conhecida pelo FileMaker, está testando um app chamado Harbor. A proposta é transformar Macs com Apple Silicon em um servidor de IA local: você escolhe um modelo aberto, baixa, carrega e usa, sem mandar nada para a nuvem. E o detalhe que chamou a atenção de todo mundo: o Harbor conectaria vários Macs via Thunderbolt 5 para somar a memória deles e rodar modelos que não cabem em uma máquina só.

A notícia virou uma das mais comentadas da semana no Hacker News, com mais de 550 comentários. Só que, entre a empolgação e o produto real, tem muita coisa que ainda não foi confirmada. E existe uma pergunta que vale mais do que o próprio Harbor: o seu Mac aguenta rodar o modelo que você quer? Neste artigo eu separo o que se sabe do que é especulação, explico por que memória é o gargalo de verdade e mostro como rodar IA local no Mac hoje, com código, sem esperar a Apple.

O Que Já Se Sabe Sobre o Harbor

Vamos aos fatos que aparecem nas reportagens e na página de prévia da própria Claris:

  • Quem está fazendo: a Claris, subsidiária integral da Apple. Não é um app com a marca Apple direto, pelo menos por enquanto.
  • O que faz: encontra, baixa e carrega modelos de pesos abertos em Macs com Apple Silicon, sem configuração manual. O modelo roda na máquina, e os prompts e dados ficam no seu hardware.
  • Cluster: dois ou mais Macs ligados por Thunderbolt 5 passam a funcionar como um conjunto, somando a memória unificada para carregar modelos maiores.
  • Status: prévia fechada. Chegou a existir uma página na App Store, que foi removida. Não há preço nem data de lançamento anunciados.

A imagem que circulou mostra um MacBook Pro com M5 Max ligado a dois Mac mini com M4 Pro, com os dois Mac minis também conectados entre si.

O que ainda é especulação

Aqui é onde muita matéria exagerou. Até agora não foram publicados requisitos mínimos de chip ou de memória, tamanhos de modelo suportados nem números de desempenho. Também não está confirmado que o Harbor use o MLX, o framework de machine learning da Apple, embora isso seja o mais provável. E como o público da Claris é corporativo, ninguém sabe se o app vai ser gratuito.

Outro ponto: os Macs com M1, M2 e M3 base não têm Thunderbolt 5. Se o Harbor sair como descrito, essas máquinas ficam, no máximo, no modo de um Mac só.

Por Que Memória É o Gargalo de Verdade

Quem já tentou rodar um modelo grande em casa aprendeu do jeito difícil: o que decide se o modelo roda é a memória, não a velocidade do chip. Um chip rápido com pouca memória simplesmente não carrega o modelo. Um chip mais lento com muita memória carrega e responde, só que com menos tokens por segundo.

É aqui que o Apple Silicon tem uma vantagem estrutural. Nas GPUs dedicadas de PC, o modelo precisa caber na VRAM da placa, que normalmente fica entre 8 GB e 32 GB nas placas de consumo. No Mac, CPU e GPU compartilham a mesma memória unificada. Um Mac Studio com 128 GB entrega boa parte desses 128 GB para a GPU, algo que nenhuma placa de vídeo de consumo oferece.

A conta básica

O tamanho de um modelo na memória segue uma conta simples:

  • Pesos: número de parâmetros × bits por peso ÷ 8.
  • KV cache: a memória que guarda o contexto da conversa. Cresce com o tamanho do contexto.
  • Sobra para o sistema: o macOS não entrega 100% da memória unificada para a GPU. Por padrão, ele reserva uma fatia para o próprio sistema.

Um modelo de 8 bilhões de parâmetros em 16 bits ocupa cerca de 16 GB só de pesos. Quantizado em 4 bits, cai para algo perto de 4 GB. Um modelo de 70 bilhões em 4 bits fica perto de 35 GB, antes de contar o contexto. É por isso que quantização virou assunto obrigatório para quem quer IA local.

Eu escrevi um script que faz essa conta de forma aproximada, considerando o contexto e uma margem para o sistema:

# estimar_memoria.py
# Estimativa aproximada de memória para rodar um LLM localmente.
# Não substitui um teste real, mas evita baixar 40 GB à toa.

def estimar_memoria_gb(
    parametros_bilhoes: float,
    bits_por_peso: int = 4,
    camadas: int = 32,
    dim_kv: int = 1024,
    contexto_tokens: int = 8192,
    bytes_kv: int = 2,
) -> dict:
    # Pesos: parâmetros x bits / 8, convertido para GB
    pesos_gb = parametros_bilhoes * 1e9 * bits_por_peso / 8 / 1e9

    # KV cache: 2 (chave e valor) x camadas x dimensão KV x tokens x bytes
    kv_gb = 2 * camadas * dim_kv * contexto_tokens * bytes_kv / 1e9

    # Margem de 10% para ativações e buffers do runtime
    total_gb = (pesos_gb + kv_gb) * 1.10

    return {
        "pesos_gb": round(pesos_gb, 1),
        "kv_cache_gb": round(kv_gb, 1),
        "total_gb": round(total_gb, 1),
    }


if __name__ == "__main__":
    # Exemplos: modelo pequeno, médio e grande, todos em 4 bits
    for nome, params, camadas in [("8B", 8, 32), ("32B", 32, 64), ("70B", 70, 80)]:
        r = estimar_memoria_gb(params, bits_por_peso=4, camadas=camadas)
        print(f"{nome}: pesos {r['pesos_gb']} GB | contexto {r['kv_cache_gb']} GB | total ~{r['total_gb']} GB")

Os valores de camadas e dim_kv mudam de modelo para modelo e estão no arquivo config.json de cada um no Hugging Face. Os números servem para decidir se vale a pena baixar, não para prometer desempenho.

Descubra o Que Seu Mac Tem

Antes de escolher modelo, confira o seu hardware. Estes comandos funcionam no Terminal de qualquer Mac com Apple Silicon:

# Chip do Mac (ex.: Apple M4 Pro)
sysctl -n machdep.cpu.brand_string

# Memória unificada total, convertida para GB
echo "$(( $(sysctl -n hw.memsize) / 1024 / 1024 / 1024 )) GB"

# Versão do macOS (o RDMA via Thunderbolt 5 exige Tahoe 26.2 ou superior)
sw_vers -productVersion

# Portas Thunderbolt e velocidade de cada uma
system_profiler SPThunderboltDataType | grep -iE "speed|velocidade"

Uma regra prática que eu uso: considere que cerca de dois terços a três quartos da memória unificada ficam disponíveis para o modelo. Num Mac de 16 GB, isso significa modelos de até uns 8B em 4 bits com folga. Com 36 GB ou 48 GB, você já roda modelos na faixa de 30B. Para modelos de 70B quantizados, o confortável começa em 64 GB.

Como o Cluster por Thunderbolt 5 Funciona

A ideia de juntar Macs não nasceu com o Harbor. O que mudou foi o hardware e o sistema permitirem isso com desempenho decente.

O macOS Tahoe 26.2 trouxe um driver de RDMA (acesso remoto direto à memória) sobre Thunderbolt 5. Na prática, um Mac consegue ler e escrever na memória de outro com latência muito menor do que passando pela pilha de rede comum. O time de pesquisa de machine learning da Apple publicou que o MLX, a partir da versão 0.30.1, usa esse driver com um backend de comunicação chamado jaccl, e demonstrou inferência distribuída entre Mac Studios.

O projeto open source exo já usa esse recurso para montar clusters de Macs. A documentação dele lista exigências bem concretas:

  • macOS Tahoe 26.2 ou superior em todas as máquinas, com a mesma versão exata, inclusive o número de beta.
  • Cabos Thunderbolt 5 ligando cada Mac a todos os outros.
  • RDMA habilitado com o comando rdma_ctl enable, seguido de reinicialização.
  • No Mac Studio, a porta Thunderbolt 5 ao lado da porta Ethernet não serve para isso.

Entre os Macs com Thunderbolt 5 citados pelo exo estão o Mac mini com M4 Pro, o Mac Studio com M4 Max, o MacBook Pro com M4 Max e o Mac Studio com M3 Ultra.

Somar memória não é somar velocidade

Esse ponto confunde muita gente. Um cluster resolve primeiro o problema de capacidade: o modelo que não cabe em um Mac passa a caber em três. A velocidade é outra história. Cada token gerado precisa passar por todas as máquinas, e a comunicação entre elas tem custo. Em testes publicados por Jeff Geerling e repercutidos pelo AppleInsider, o ganho de velocidade com mais nós dependeu muito do software usado: o exo melhorou com dois nós, enquanto outra ferramenta testada piorou.

Se o Harbor cumprir o que promete, o mérito vai ser esconder toda essa complexidade atrás de uma interface. A física por baixo continua a mesma.

Rodando IA Local no Mac Hoje, Sem Esperar o Harbor

Você não precisa esperar a Claris. Existem três caminhos maduros hoje, e cada um serve para um perfil:

  • LM Studio: interface gráfica, ótimo para quem quer clicar, baixar um modelo e conversar. Também sobe um servidor local compatível com a API da OpenAI.
  • Ollama: linha de comando simples e servidor local, muito usado em integração com outras ferramentas.
  • MLX (mlx-lm): a biblioteca da própria Apple, ideal para quem quer controle e o melhor aproveitamento do Apple Silicon.

O caminho mais direto com MLX:

# Ambiente isolado para não bagunçar o Python do sistema
python3 -m venv ~/.venvs/mlx && source ~/.venvs/mlx/bin/activate

# Instala a biblioteca de modelos de linguagem do MLX
pip install mlx-lm

# Baixa um modelo quantizado em 4 bits e gera uma resposta
mlx_lm.generate \
  --model mlx-community/Qwen2.5-7B-Instruct-4bit \
  --prompt "Explique memória unificada em três frases." \
  --max-tokens 200

Na primeira execução o modelo é baixado do Hugging Face. Ao final, o mlx_lm.generate mostra quantos tokens por segundo o seu Mac entregou, o que é o melhor teste real de desempenho que você pode fazer.

Integrando o Modelo Local na Sua Aplicação

O que torna IA local útil de verdade é poder chamá-la do seu código. Tanto o LM Studio quanto o Ollama expõem um endpoint compatível com a API de chat da OpenAI. Isso significa que o mesmo código funciona com os dois, mudando só a URL:

// cliente-ia-local.mjs
// Chama um modelo rodando no próprio Mac via API compatível com OpenAI.
// LM Studio: http://localhost:1234/v1 | Ollama: http://localhost:11434/v1

const BASE_URL = process.env.IA_LOCAL_URL ?? 'http://localhost:11434/v1';
const MODELO = process.env.IA_LOCAL_MODELO ?? 'qwen2.5:7b';

async function perguntar(pergunta, { timeoutMs = 60_000 } = {}) {
  // Cancela a requisição se o modelo demorar demais para responder
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), timeoutMs);

  try {
    const resposta = await fetch(`${BASE_URL}/chat/completions`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      signal: controller.signal,
      body: JSON.stringify({
        model: MODELO,
        messages: [
          { role: 'system', content: 'Responda em português, de forma direta.' },
          { role: 'user', content: pergunta },
        ],
        temperature: 0.2,
      }),
    });

    if (!resposta.ok) {
      throw new Error(`Servidor local respondeu ${resposta.status}`);
    }

    const dados = await resposta.json();
    return dados.choices[0].message.content;
  } finally {
    // Sempre limpa o timer, mesmo quando a resposta chega antes
    clearTimeout(timer);
  }
}

const texto = await perguntar('Resuma em uma linha o que é quantização de modelos.');
console.log(texto);

Repare no clearTimeout dentro do finally. Sem ele, o timer continua pendente mesmo depois da resposta chegar, e o processo do Node demora para encerrar. Parece detalhe, mas aparece rápido quando você roda isso em lote.

Medindo desempenho de forma honesta

Antes de colocar um modelo local em produção, meça. Este script usa a API Python do mlx-lm para comparar dois modelos com o mesmo prompt:

# comparar_modelos.py
# Compara tokens por segundo de modelos MLX no seu próprio Mac.
import time
from mlx_lm import load, generate

MODELOS = [
    "mlx-community/Qwen2.5-7B-Instruct-4bit",
    "mlx-community/Qwen2.5-14B-Instruct-4bit",
]
PROMPT = "Liste cinco cuidados ao rodar modelos de linguagem localmente."

for nome in MODELOS:
    modelo, tokenizer = load(nome)

    inicio = time.perf_counter()
    texto = generate(modelo, tokenizer, prompt=PROMPT, max_tokens=256)
    duracao = time.perf_counter() - inicio

    # Conta os tokens gerados para calcular a taxa real
    tokens = len(tokenizer.encode(texto))
    print(f"{nome}: {tokens} tokens em {duracao:.1f}s -> {tokens / duracao:.1f} tokens/s")

O tempo medido inclui o processamento do prompt, então o número fica um pouco abaixo do que o modelo entrega em geração pura. Para comparar modelos entre si no mesmo Mac, isso é exatamente o que você quer.

Vale Esperar o Harbor ou Comprar Hardware Agora?

Minha leitura honesta: não compre hardware por causa do Harbor. O app ainda não tem requisitos, preço nem data. Se você precisa de IA local hoje, a decisão de compra deve olhar para a memória, e o software que existe já resolve.

Algumas recomendações práticas:

  • Mac de 16 GB: ótimo para modelos de até uns 8B em 4 bits. Serve bem para autocompletar, resumir e classificar texto.
  • 36 GB a 64 GB: a faixa mais equilibrada para uso sério, com modelos de 14B a 32B rodando com folga.
  • 96 GB ou mais: território de modelos de 70B quantizados e de contextos longos.
  • Cluster: só faz sentido quando o modelo que você precisa não cabe na maior máquina que você pode comprar. Antes disso, um Mac com mais memória costuma sair mais simples e mais rápido.

Se você quer um exemplo do outro lado da moeda, com GPU dedicada em vez de memória unificada, eu mostrei em detalhes como rodar o Qwen3 localmente com o Strata em GPU. Comparar os dois cenários ajuda a entender por que o Mac virou opção para IA local.

Perspectivas

O Harbor ainda é uma prévia, e pode chegar bem diferente do que vazou. Mas o movimento é claro: a Apple está apostando que o Mac pode ser a máquina de IA local de quem não quer depender de nuvem, e o RDMA sobre Thunderbolt 5 no macOS Tahoe 26.2 mostra que essa aposta começou pelo sistema, não pelo app.

Para quem desenvolve, a lição prática é que IA local deixou de ser experimento. Com uma conta de memória bem feita, um modelo quantizado e uma API compatível com OpenAI, dá para integrar um modelo rodando no próprio Mac em qualquer aplicação hoje. Quando o Harbor sair, ele vai tornar isso mais fácil, mas quem já entende a conta vai saber tirar muito mais dele.

Bora pra cima! 🦅

📚 Quer Acompanhar o Que Vem Por Aí?

Este artigo cobriu o Harbor da Apple e como rodar IA local no Mac calculando a memória certa, mas o ecossistema muda toda semana e nem tudo vira artigo aqui.

No X eu compartilho o que estou testando, os bastidores dos projetos e as novidades que aparecem antes de virarem post.

Me Segue Lá

👉 Seguir @jeffbruchado no X

💡 Conteúdo diário sobre desenvolvimento, carreira e as ferramentas que eu realmente uso

Comentários (0)

Esse artigo ainda não possui comentários 😢. Seja o primeiro! 🚀🦅

Adicionar comentário