LLM local no Mac M5: MLX agora supera de longe o llama.cpp (números 2026)

#Por que o M5 muda a dinâmica para um LLM local no Mac

O chip M5 traz duas coisas que realmente importam para a inferência: núcleos de GPU com unidades de multiplicação matricial (Neural Accelerators) integradas a cada núcleo e uma largura de banda de memória maior. A inferência de um LLM é, antes de tudo, um problema de largura de banda de memória — cada token gerado relê todos os pesos do modelo. Quanto mais rápida for a memória unificada, mais rápido os tokens são gerados.

É precisamente aí que o framework MLX da Apple leva vantagem sobre o llama.cpp. O MLX foi desenvolvido para aproveitar diretamente essas novas unidades matriciais da GPU M5, enquanto a implementação Metal do llama.cpp continua mais genérica. Resultado concreto: na mesma máquina, com o mesmo modelo e a mesma quantização, o MLX gera significativamente mais tokens por segundo. A diferença, marginal no M3, torna-se clara no M5.

#Benchmarks M5 e M5 Max: os números de 2026

Aqui estão ordens de grandeza medidas durante a geração (decode) com MLX, em modelos comuns com quantização de 4 bits. Como sempre na inferência local, essas taxas variam conforme o comprimento do contexto, a versão exata do modelo e a temperatura da máquina: considere-as referências, não garantias precisas ao token.

• MacBook Pro M5 Max 128 GB: as verdadeiras medições em IA local (benchmark 2026)

M5 (GPU de 10 núcleos) — 8B Q4

~55-70 tokens/s na geração. Um modelo de 8B (Qwen 3.5, Granite 4.2, Gemma 4) continua rodando com bastante folga no chip básico.

M5 Max — 8B Q4

~230 tokens/s. A maior largura de banda de memória do Max faz a diferença nos modelos pequenos, onde a GPU nunca é o gargalo.

M5 Max — 32B Q4

~55-65 tokens/s. Um modelo de 32B (Qwen 3.8 27B, Devstral) roda a uma velocidade confortável para leitura e é perfeitamente utilizável de forma interativa.

M5 Max — 70B Q4

~28 tokens/s. Um modelo de 70B em Q4 cabe na memória a partir de 48 a 64 GB de RAM unificada e continua fluido para conversas e geração de código.

O ponto marcante é o modelo de 70B a ~28 tokens/s em uma máquina sem placa de vídeo dedicada, silenciosa e que cabe em uma bolsa. Para comparação, é necessária uma RTX 4090 de 24 GB (com parte do modelo transferida para execução na CPU, pois um 70B Q4 ocupa ~40 GB e não cabe em 24 GB de VRAM) para rivalizar no PC — com muito mais ruído e consumo.

#MLX versus llama.cpp: onde se acentua a diferença

A diferença de 30 a 40% a favor do MLX não é uniforme: depende do perfil da carga. Entender onde ela aumenta ajuda a saber quando mudar para o MLX vale realmente a pena.

Geração (decodificação)

É aqui que o MLX domina de forma mais clara no M5, graças ao uso direto das unidades matriciais da GPU. Para conversas interativas, é essa diferença que você sente.

Processamento do prompt (prefill)

MLX mantém a vantagem, mas a diferença é um pouco menor. Em contextos muito longos, os dois mecanismos de inferência passam a ser limitados pela memória.

Suporte a modelos

O llama.cpp permanece mais universal por meio do formato GGUF; o MLX exige uma versão convertida para o formato MLX. Nos modelos populares, a conversão existe quase sempre (hub mlx-community no Hugging Face).

Integração Python

MLX é nativo do Python, o que o torna a escolha evidente para prototipagem, fine-tuning leve ou um pipeline personalizado. O llama.cpp usa bindings.

#Requisitos e RAM recomendada por modelo

Antes de instalar, ajuste o tamanho do modelo de acordo com sua memória unificada. Aqui estão os níveis realistas para M5 e M5 Max, em Q4.

16 GB (M5)

Modelos de 3B a 8B em Q4 rodam com folga. Um modelo de 14B cabe, mas deixa pouca margem para um contexto grande.

24-32 GB (M5 / M5 Pro)

Um 14B roda com folga; um 32B Q4 é viável no limite superior da faixa. O ponto ideal para um uso diário versátil.

48 GB (M5 Max)

Um 32B Q4 roda com muita folga; um 70B Q4 cabe por pouco — é melhor optar por 64 GB para um 70B com contexto.

64-128 GB (M5 Max)

Um 70B Q4 rodando com fluidez e contexto amplo, ou vários modelos carregados em paralelo. Território de usuários avançados.

Do lado do software, você precisa de macOS atualizado e uma das duas opções de acesso ao MLX: LM Studio (que muda automaticamente para MLX quando uma versão MLX do modelo estiver disponível) ou Ollama a partir da atualização de junho de 2026, detalhada logo após.

#O motor MLX do Ollama (junho de 2026)

Historicamente, o Ollama se apoiava em seu próprio motor e no llama.cpp, usando, portanto, Metal no Mac. Desde sua atualização de junho de 2026, o Ollama consegue executar modelos via MLX em Macs com Apple Silicon quando uma versão MLX está disponível — o que finalmente coloca a ferramenta mais usada para IA local no mesmo patamar de desempenho que o LM Studio já oferecia via MLX.

Na prática, isso significa que você obtém o ganho do MLX sem mudar seus hábitos: o mesmo daemon do Ollama na porta 11434 por padrão, os mesmos comandos, a mesma API compatível com a OpenAI. O motor escolhe o MLX quando é pertinente e recorre ao caminho tradicional caso contrário.

#Instalar e executar um modelo com MLX

Duas opções, dependendo de como você se sente usando o terminal. A mais direta para testar MLX sem configuração é o LM Studio; a mais fácil de integrar a uma stack é o Ollama.

1. 01
   1. Atualizar a ferramenta

   Instale a versão mais recente do Ollama (junho de 2026 ou posterior) ou do LM Studio. Esse é o pré-requisito para aproveitar a execução via MLX.
2. 02
   2. Escolher um modelo com versão MLX

   No LM Studio, a busca prioriza as variantes MLX no Apple Silicon. No Ollama, baixe um modelo comum: o mecanismo passa a usar MLX quando existe uma versão convertida.
3. 03
   3. Iniciar e verificar a taxa de geração

   Faça uma pergunta longa e observe os tokens/s exibidos. Se quiser, compare com o mesmo modelo em GGUF para medir a diferença real em sua máquina.
4. 04
   4. Ajustar a quantização, se necessário

   Se o modelo saturar sua memória unificada, reduza um nível (Q5 → Q4_K_M) em vez de mudar de ferramenta: é a memória que limita, não o motor.

# Vérifier la version d'Ollama (le support MLX date de juin 2026)
ollama --version

# Lancer un modèle : Ollama emprunte MLX quand une version MLX existe
ollama run qwen3:8b

# Le daemon expose l'API compatible OpenAI sur le port par défaut
curl http://localhost:11434/api/tags

Em Python, o MLX pode ser usado diretamente em scripts, o que é útil para realizar benchmarks ou integrar a inferência a um pipeline próprio:

# Installer les outils MLX pour LLM (framework Apple, natif Python)
pip install mlx-lm

# Générer avec un modèle converti au format MLX (hub mlx-community)
mlx_lm.generate --model mlx-community/Qwen3-8B-4bit \
  --prompt "Explique la mémoire unifiée du M5 en trois phrases"

#Clusters Thunderbolt 5 para modelos 120B+

Um único Mac, mesmo um M5 Max bem equipado, fica limitado à sua memória unificada. Para superar esse limite — rodar um modelo de 120B+ ou um grande MoE — a abordagem de 2026 consiste em conectar várias máquinas Apple Silicon via Thunderbolt 5 e distribuir o modelo entre elas. O Thunderbolt 5 oferece uma largura de banda significativamente superior à do Thunderbolt 4, o que torna a troca de ativações entre nós finalmente viável para inferência.

O princípio: o modelo é dividido em grupos de camadas, cada máquina hospeda parte dos pesos na memória, e as ativações passam de um nó ao seguinte a cada token. Assim, soma-se a memória unificada de vários Macs para carregar um modelo que não caberia em nenhum deles sozinho.

O que isso permite

Modelos de 120B+ em Q4, ou até modelos MoE muito grandes, combinando, por exemplo, dois M5 Max de 128 GB para se aproximar de 256 GB de memória endereçável.

A contrapartida

A latência entre nós reduz a taxa de tokens/s: um cluster é mais lento que uma única máquina na qual coubesse o mesmo modelo. Recorremos a um cluster porque nenhuma máquina sozinha é suficiente, não para ganhar velocidade.

A conexão de cabos

Thunderbolt 5 é a chave: sua largura de banda torna a transferência de ativações aceitável. Em Thunderbolt 4 ou em Ethernet, a interconexão volta a ser o gargalo.

#Dicas e solução de problemas

“O MLX não é mais rápido”

Verifique primeiro se você está realmente usando MLX (versão da ferramenta atualizada, variante MLX do modelo realmente carregada). Um GGUF carregado via Metal não se beneficia do MLX.

Velocidade que despenca após alguns minutos

É throttling térmico, principalmente no MacBook Air (sem ventilador). Sob carga prolongada, um MacBook Pro ou um Mac mini/Studio mantém uma taxa de geração mais estável.

Modelo que não carrega

A memória unificada está saturada. Escolha um modelo um tamanho menor ou uma quantização um nível abaixo; feche os aplicativos que consomem muita RAM.

Contexto longo com lentidão

O prefill de um prompt muito longo consome muita memória. Reduza a janela de contexto se não precisar dela, ou aceite uma espera maior pelo primeiro token.

#Para se aprofundar

Esses guias complementam naturalmente o que você acabou de ler, de uma comparação aprofundada à implementação prática:

MLX versus llama.cpp em detalhe

« MLX versus llama.cpp nos Macs da série M: quem vence em 2026? » aprofunda a comparação (suporte a modelos, quantização, integração com Python), indo além dos números do M5.

Instalar Ollama no macOS

« Instalar Ollama no macOS (Apple Silicon) » abrange o passo a passo da instalação e o uso da memória unificada, base indispensável antes de avançar para o MLX.

Escolher sua quantização

“Escolher a quantização (Q4, Q5, Q8, FP16)” explica o compromisso entre qualidade e memória — o verdadeiro recurso para fazer um modelo caber na sua RAM unificada.