A config do M5 Max
As sete lições anteriores derivaram os princípios; esta os transforma numa máquina concreta. Você tem 128 GB de memória unificada e dois workloads: um cérebro de coding/agente (o DeepSeek-V4-Flash q2, 81 GB) e visão ocasional (o Qwen3-VL, ~20 GB). No fim, você vai saber exatamente o que cabe, por que os dois não moram juntos na GPU, e como religar o funil do Alembic para o cérebro local.
Esta lição destila o raciocínio do Ahmad sobre memória unificada + nós independentes e cruza com medições reais neste M5 Max. Por que importa pra missão: é a planta da máquina que serve o cérebro local do Alembic — o que carregar, quanto ocupa, e como não estourar a RAM.
- Fazer o orçamento de memória desta máquina de cabeça (pesos + KV + visão + SO ≤ 128 GB) e saber quando estoura.
- Explicar por que a memória unificada (CPU+GPU+ANE no mesmo pool) torna um modelo de 81 GB viável num laptop — e por que isso é uma faca de dois gumes.
- Decidir entre passes sequenciais, co-residência e segundo Mac quando cérebro e visão competem pelos 128 GB.
- Religar o funil do Alembic ao DS4 local com uma única variável de ambiente.
00 · O que vamos resolver
Antes de mergulhar nos números, o mapa da lição. Há uma máquina (128 GB de memória unificada) e dois workloads que a disputam — o cérebro de coding e a visão ocasional. As cinco seções seguintes são, na verdade, uma única pergunta vista de cinco ângulos: como caber tudo sem estourar a RAM? O diagrama abaixo é o fio condutor — cada caixa vira uma seção.
Cada caixa cinza/sky/clay é uma seção desta lição. Guarde o fio: tudo desemboca em cérebro local servindo a custo zero.
01a · Memória unificada — CPU, GPU e ANE no mesmo pool
Para entender por que a soma da próxima seção é tão implacável, primeiro entenda a peça de hardware que muda tudo: no Apple Silicon, CPU, GPU e ANE (Apple Neural Engine) não têm cada um a sua memória — eles compartilham um único pool de 128 GB. É o oposto de um PC com GPU discreta, onde a placa tem a sua própria VRAM separada da RAM do sistema. Esse desenho é o que permite carregar um modelo de 81 GB num laptop; é também por que tudo divide o mesmo teto.
mmap os mapeou. O preço é que o KV cache, as ativações, o macOS e os pesos competem pelo mesmíssimo pool — o orçamento da §01 não é uma metáfora, é aritmética de endereços. [uncertain]: a participação exata da ANE na inferência de LLM via MLX varia por build; o MLX hoje roda majoritariamente na GPU.As setas pulsam de cada processador para o mesmo pool. Numa GPU discreta haveria uma cópia PCIe entre dois pools separados — é exatamente o que a próxima figura compara.
Unificada vs. discreta — por que isso importa
A diferença não é acadêmica: ela decide se um modelo grande é viável. Veja os dois desenhos lado a lado — repare na cópia que existe num e não existe no outro:
À esquerda, a GPU lê os 81 GB onde já estão. À direita, os pesos teriam de caber numa VRAM pequena (24 GB num exemplo típico) e ainda pagar a cópia PCIe. É por isso que este modelo, neste laptop, é possível.
01 · O orçamento de memória é uma soma
Tudo nesta config é decidido por uma conta de adição. Diferente de uma GPU dedicada, no Apple Silicon a CPU e a GPU dividem a mesma memória unificada — então pesos do modelo, KV cache, buffers de ativação e o macOS inteiro disputam os mesmos 128 GB. O DeepSeek q2 são 81 GB de pesos residentes; o KV cache cresce com o contexto (poucos GB a 100k tokens, ~26 GB no extremo de 1M); o sistema reserva ~18 GB; e a Lição 02 já gravou a regra: deixe 10–20% de folga.
Deixe 10 a 20 por cento de folga. Rodar a 99% da VRAM é implorar por out-of-memory e falhas de fragmentação.— Ahmad Osman, "LLMs 101 (2026)"
Monte o orçamento você mesmo
Arraste os quatro controles e veja a soma cruzar (ou não) o teto. A barra fica verde abaixo da linha de folga de 80% (~102 GB) e vermelha acima — exatamente como o medidor da Lição 02, mas agora com cada componente real desta máquina:
Laranja = pesos · oliva = KV · âmbar = visão · cinza = macOS. Repare: com a visão em 0, sobra folga confortável; ligue os 20 GB de visão e a soma encosta no teto — o nó da seção 03.
01b · Faça o orçamento passo-a-passo
O slider acima dá a intuição; agora a conta explícita, do jeito que você faria de cabeça antes de carregar qualquer coisa. Cada passo soma uma fatia; o objetivo é terminar abaixo dos ~102 GB (teto seguro de 80%).
--kv-disk-dir).02 · A pilha de memória, peça por peça
O orçamento da seção 01 é a soma; esta seção abre a caixa e mostra onde cada byte vive. A memória unificada não é um bloco amorfo — ela hospeda camadas com papéis distintos, e abaixo dela está o SSD, que serve de rede de segurança (mmap e KV em disco). O diagrama anima de baixo para cima conforme entra em foco:
02b · M5 Max vs M4 Max vs caixa de GPU discreta
Você não escolhe esta máquina no vácuo — escolhe contra as alternativas. Três caminhos rodam LLM local: o M5 Max (128 GB) desta config, o M4 Max (36 GB) que serve de segundo nó (seção 05), e uma caixa de PC com GPU discreta (ex.: uma RTX de 24 GB). A diferença decisiva não é "qual é mais rápido" — é quanto modelo cada um consegue segurar, porque o que não cabe não roda. Primeiro a tabela, depois dois diagramas que tornam o trade-off visível.
| Eixo | M5 Max (esta config) | M4 Max (2º nó) | PC + GPU discreta 24 GB |
|---|---|---|---|
| Memória p/ o modelo | 128 GB unificada | 36 GB unificada | 24 GB VRAM (+ RAM separada) |
| Banda | 460–614 GB/s | menor (M4 Max) | ~1 TB/s na VRAM, mas só p/ o que cabe nela |
| Cabe o DS4 q2 (81 GB)? | Sim ✓ | Não — grande demais | Não — 81 ≫ 24 |
| Cópia host→device? | Nenhuma (unificada) | Nenhuma (unificada) | Sim — PCIe RAM→VRAM |
| Energia | Laptop · dezenas de W | Laptop · dezenas de W | Workstation · centenas de W |
| Papel nesta config | o cérebro (DS4) | nó de visão (Qwen3-VL) | fora — não segura o cérebro |
Bandas e papéis: docs/local-models-macbook.md. A banda de ~1 TB/s da VRAM discreta é real, mas só vale para o modelo que couber nos 24 GB — e o DS4 não cabe. [uncertain]: a banda exata do M4 Max e a da RTX citada não foram medidas nesta sessão; trate como ordem de grandeza.
Quanto modelo cada um segura
O eixo que decide tudo é a memória disponível para os pesos. Veja as três capacidades na mesma escala, com a linha do DS4 (81 GB) cruzando por cima — só uma barra ultrapassa:
O trade-off em três eixos
Capacidade não é tudo: banda e energia também contam. Este diagrama de barrinhas relativas resume os três eixos de uma vez — cada coluna é uma máquina, cada linha um eixo (barra mais cheia = melhor naquele eixo):
03 · Cérebro e visão não cabem juntos na GPU
Aqui está a decisão central da config. O instinto é deixar os dois modelos carregados o tempo todo — cérebro pronto, visão pronta. Mas faça a soma: 81 (DS4) + 8 (KV) + 20 (Qwen3-VL) + 18 (macOS) ≈ 127 GB. Isso não só cruza a linha de folga de 80% (102 GB) — encosta no teto absoluto. Na prática, tentar manter os dois residentes na GPU ao mesmo tempo provoca page fault: o sistema começa a paginar pesos pro SSD no meio da geração, e a velocidade despenca (ou o processo morre por OOM).
Clique no botão para ligar a co-residência e veja a soma estourar — depois compare com a alternativa que sempre funciona: passes sequenciais (rode um, descarregue, rode o outro):
03b · Fluxograma: chegou uma imagem — o que fazer?
A regra de não-co-residência não é dogma: é o resultado de uma decisão que você pode seguir como um fluxograma. Toda vez que uma imagem chega enquanto o cérebro serve, o sistema (ou você) percorre estas perguntas. Acompanhe os losangos de decisão — cada "sim/não" leva a um caminho diferente, e só um deles arrisca o OOM:
Repare: o caminho verde (sequencial / 2º Mac) é o que o sistema toma quase sempre. Co-residir (clay tracejado) só aparece quando a soma cabe de verdade — e por isso é a exceção, não a regra.
04 · Religando o funil do Alembic ao DS4
Carregar o cérebro é metade do trabalho; a outra metade é fazer o Alembic falar com ele. Por padrão o funil aponta para o gateway cliproxyapi. Para redirecioná-lo ao DeepSeek local, basta uma variável de ambiente: ALEMBIC_CLIPROXY_URL=http://127.0.0.1:8000. O DS4 expõe um endpoint OpenAI+Anthropic-compatível nessa porta, então nada mais no pipeline precisa mudar — as mesmas chamadas, agora servidas localmente, a custo zero.
Acompanhe o fluxo de uma requisição. Clique em Local para ver a flecha religar do gateway remoto para o DS4 na porta 8000:
ALEMBIC_CLIPROXY_URL=http://127.0.0.1:8000 alembic distill <corpus> — o funil agora roteia tudo pro DeepSeek local. Combine com --offline quando quiser o caminho hermético de $0 sem nem tocar a rede. (Troubleshooting: fetch failed = a porta 8000 não está servindo — suba o ds4-server antes.)04b · Por dentro do gateway (Simples / Técnico)
A variável de ambiente da seção 04 é só a ponta visível. Vale entender o que ela realmente faz — primeiro a versão simples, depois o ciclo de vida técnico de uma requisição. Use as abas:
cliproxyapi); a variável de ambiente só troca o número que ele disca para 127.0.0.1:8000 — o seu próprio Mac. Como o DS4 atende nesse mesmo "idioma", nenhum outro pedaço do código percebe a diferença. Mesma chamada, agora local e a custo zero.ALEMBIC_CLIPROXY_URL e resolve o base URL → POST /v1/chat/completions (ou o endpoint Anthropic) chega ao ds4-server em :8000 → o servidor enfileira, roda a inferência na GPU (pesos já residentes via mmap) e faz stream dos tokens de volta → o funil agrega a resposta e segue o pipeline. O contrato de I/O é idêntico ao remoto; só o host/porta mudam. Falha comum: fetch failed = nada escutando em :8000 (suba o servidor antes).05 · O segundo Mac como nó de visão (TB5)
Se a visão for frequente o bastante para que recarregar o DS4 a cada imagem incomode, a saída não é a co-residência arriscada — é dar à visão a sua própria máquina. O M4 Max de 36 GB, ligado por Thunderbolt 5, roda o Qwen3-VL com folga (~20 GB em 36) num endpoint independente. O cérebro fica com o M5 Max inteiro; a visão fica sempre pronta no segundo nó; zero swap, zero contenção. É a leitura do Ahmad — "use os dois como nós independentes" — em vez de tentar fatiar um modelo entre eles.
05b · TB5 explorada — quão "perto" o segundo Mac fica?
"Thunderbolt 5, 80 Gb/s" é abstrato. O que importa na prática é: quando você manda uma imagem para o nó de visão, quanto tempo os bytes levam para atravessar o cabo? Spoiler: para uma imagem, é desprezível — o gargalo é a inferência, não o link. Arraste o tamanho do payload e veja o tempo de transferência (a fração de tempo que o cabo cobra) recalcular em número e na barra:
Conta: tempo ≈ tamanho ÷ banda. A 80 Gb/s (= 10 GB/s = 10 MB/ms), 2 MB ≈ 0,2 ms. Por isso "dois nós independentes" funciona: o link é largo o bastante para nunca ser o gargalo de uma imagem. [uncertain]: 80 Gb/s é o pico nominal do TB5; throughput efetivo é menor, mas a ordem de grandeza (sub-ms para MBs) se mantém.
Fixe os conceitos (flashcards)
Clique pra virar. Tente lembrar a resposta antes de virar — recuperação ativa fixa mais que reler.
ALEMBIC_CLIPROXY_URL=http://127.0.0.1:8000. O DS4 atende no mesmo contrato OpenAI+Anthropic; nada mais muda. Some --offline para $0 sem rede.Revisão cumulativa — recupere de memória
Antes de clicar: responda de cabeça. Recuperar (não reler) é o que fixa. As opções têm o mesmo tamanho de propósito — sem pista pela forma.
--offline para $0. a é trabalho desnecessário e frágil: a URL já é configurável por env var. b é falso — o ponto inteiro da seção 04 é que dá. d vai na direção oposta (aponta para a nuvem) e não muda o host do gateway.ds4-server na porta 8000?", "Vale a pena o q2-q4 em vez do q2 puro?". É só dizer.