3 GB de RAM bastam para um modelo de 35B?

Se você viu '35B em 3 GB de RAM' e pensou em rodar um modelo grande no seu laptop antigo, o Edge0 tem uma pegadinha. Ele não diminui os pesos: deixa 18,1 GB no SSD e usa cache de página do sistema para acelerar.

O que o Edge0 realmente faz com 3 GB de RAM?

O Edge0 roda o MoE Qwen3.6-35B-A3B com 2,9 GiB de pico no alocador MLX, mas essa métrica mede apenas o que o alocador enxerga, não o que a máquina gasta. O checkpoint pesa 19,5 GB e 18,1 GB são pesos de experts que permanecem no SSD, lidos sob demanda conforme os tokens avançam. O projeto é Apache 2.0 e foi liberado em setembro de 2026.

A arquitetura MoE (mixture of experts, ou mistura de especialistas) corta o bloco feed-forward de cada camada em 256 especialistas. Quatro deles disparam por token e um único compartilhado por camada fica sempre em memória, com 47 MB no total. Todo o resto precisa chegar quando o token pede, e é aí que o design fica interessante.

Quem chama atenção para a diferença entre pico do alocador e consumo real é o próprio README do repositório. Ele define 'warm run' como o momento em que as páginas do checkpoint estão residentes no cache de página do sistema. É essa memória que o número de 2,9 GiB deixa de fora.

O nome Qwen3.6-35B-A3B identifica o modelo que o Edge0 serve: uma variante do Qwen com 35 bilhões de parâmetros totais e cerca de 3 bilhões ativos por token. O endpoint de chat único e a ausência de suporte fora do Apple Silicon são limitações documentadas pelo próprio projeto.

Como o streaming de pesos do SSD funciona sem travar

O streaming de pesos do SSD funciona porque o Edge0 lê só os experts que o token pede, e não o checkpoint inteiro. Cada especialista ocupa 1,77 MB, quatro disparam por camada e o total em 40 camadas dá 283 MB de leitura por token. A 15 a 18 tokens por segundo, isso exige de 4 GB a 5 GB por segundo em leituras espalhadas.

O bloqueio de projeto é este: o roteamento depende da saída da camada anterior, então você só sabe quais quatro especialistas usar no momento exato em que precisa deles. Em memória, isso não é problema. Em disco, cada camada abriria uma leitura de peso e travaria a multiplicação de matrizes atrás dela.

A solução do Edge0 é a rede pré-roteadora, um pequeno modelo treinado por camada. Cada cabeça tem uma camada oculta de 512 dimensões e envia seus próprios pesos junto ao checkpoint. A cabeça da camada N não prevê os experts dela: prevê o que a camada N+1 vai querer, com um token inteiro de antecedência.

A documentação de tier do projeto afirma que o roteamento é fornecido pelas cabeças pré-roteadoras treinadas. O número que o próprio projeto associa a essa arquitetura é de até 59% mais throughput de decodificação, ganho que cresce com armazenamento mais lento e modelos maiores.

A pré-seleção não é um palpite: ela decide o roteamento

A cabeça pré-roteadora não é um palpite conferido depois: ela decide o roteamento. Em tempo de decodificação, a previsão nunca é comparada ao roteador real, e o conjunto carregado é exatamente o conjunto que dispara. Por isso o projeto descreve o comportamento como 'zero descarte por construção'.

Essa diferença importa para interpretar o resultado. Um erro de previsão não gera travamento nem leitura perdida: ele troca quais especialistas calcularam o seu token. O sistema foi treinado justamente porque a alternativa heurística erra e o efeito aparece no texto gerado, não apenas na latência.

Há um flag para desligar a pré-seleção. Um relato no rastreador de bugs do projeto descreve saídas colapsando em pontos de exclamação, comportamento que não ocorreu com o pré-roteador desligado. A causa foi um overflow em 16 bits, corrigido no dia seguinte.

Trate esse caso como evidência de primeira mão de um usuário, não como falha estrutural do projeto. Ele mostra o limite da abordagem: sem conferência do roteador real, um erro numérico na previsão afeta diretamente o conteúdo gerado.

Por que o cache de experts do Edge0 mede zero acertos

O cache compartilhado de experts do Edge0 mede exatamente zero acertos porque oferece apenas 64 slots para o modelo inteiro. Um passo de decodificação toca 160 especialistas, o que dá menos de três slots por camada. O próprio comentário no código-fonte registra 184 bundles reconstruídos a cada passo.

Isso significa que o cache que o projeto entrega não é o que torna o sistema rápido. O que sustenta a velocidade é a combinação do pool de threads de pré-busca com a união dos conjuntos de experts usados recentemente, além do tier superior que desliga os experts fixados em memória.

Quem realmente segura os pesos é o cache de página do macOS. O Edge0 lê os experts por intervalos mapeados em memória, e é o kernel que mantém essas páginas residentes. Em uma máquina com RAM sobrando, um checkpoint de 19 GB cabe no cache de arquivos, então depois da primeira passada o SSD quase não é tocado.

Os números de partida a frio e a quente confirmam esse desenho. A primeira requisição após iniciar o processo processa o prompt a 113 tokens por segundo; as seguintes chegam a 140. A diferença, de cerca de um quinto, desaparece assim que as páginas ficam residentes.

A memória que o número de 2,9 GiB não conta

O número de 2,9 GiB não conta a memória que o cache de página gasta para manter os pesos vivos. O critério de aceitação definido no próprio código do Edge0 é de 3,4 GB e 13 tokens por segundo, um par menos vistoso que a tabela do README. A métrica do alocador mede intenção, não consumo do sistema.

Quem tira a RAM disponível do caminho vê o custo real. Em um Mac M1 de 8 GB já em swap, um usuário mediu cerca de 0,7 token por segundo no tier menor, contra 24 tokens por segundo no cartão do modelo. O footprint ficou perto de 1 GB, ou seja, o offloading funcionou exatamente como projetado.

O controle desse relato é o que dá credibilidade ao número. Um modelo denso de 4B rodando no MLX comum, na mesma máquina e sessão, entregou 11,4 tokens por segundo. O laptop não estava quebrado, e o mantenedor confirmou na thread que, em máquina com memória restrita, a decodificação fica limitada por page fault, não por computação.

Um segundo relato descreve um MacBook Air de 16 GB fazendo streaming de um HD USB externo a cerca de 5 tokens por segundo. O requisito nunca foi 3 GB de memória: é 3 GB de alocador mais armazenamento rápido e RAM livre suficiente para cachear um arquivo de 20 GB.

O que a troca custa em qualidade

O custo de qualidade vem de três mudanças empilhadas: pesos em 4 bits, largura roteada reduzida e roteador previsto. O adaptador LoRA treinado por destilação a partir do professor em precisão total tenta recuperar o que a quantização perdeu. Os adaptadores nunca são mesclados, então uma base somente leitura pode servir vários deles.

Em uma suíte de benchmarks rodada pelo próprio projeto, com configurações idênticas nos dois lados, a média ficou em 79,2 contra 83,2 do modelo em precisão total. Isso dá cerca de quatro pontos de diferença. Na AIME, conjunto de problemas de matemática, a queda é maior: 86,6 contra 92,7.

A leitura desse número muda conforme o uso. Se você escreve código, a perda média tende a passar despercebida. Se depende de raciocínio matemático, a queda da AIME é o dado que importa.

O projeto rodou os dois lados da tabela, então trate os números como medição do fornecedor, não como verificação independente. Até outubro de 2026, não havia reprodução pública do throughput que eu tenha conseguido localizar.

Edge0, Kim K3 e MLX comum: onde cada um se encaixa

A escolha entre Edge0, o streaming ingênuo de um K3 e o MLX comum depende do que você prioriza. O Kim K3 em streaming de disco no M1 Max, demonstração de julho de 2026, produzia um token a cada 14 segundos com o mesmo princípio e nenhuma dessa maquinaria. O checkpoint é bem maior, mas o formato do resultado ingênuo é esse.

Compare as três abordagens pelos eixos que a evidência sustenta:

Abordagem	O que faz	Evidência de desempenho	Limite principal
Edge0	Pré-busca de experts do SSD com roteador treinado	15 a 18 tok/s relatados (máquina não especificada)	Só macOS/Apple Silicon; uma requisição por vez
Streaming ingênuo (Kim K3, M1 Max)	Lê pesos do disco sem pré-busca	1 token a cada 14 s	Cada camada trava na leitura
MLX denso 4B	Mantém todos os pesos em memória	11,4 tok/s medidos pelo usuário	Modelo pequeno, sem roteamento

A coluna de desempenho mistura medições de fontes diferentes, então não leia a tabela como comparação controlada. O valor real dela é mostrar que a pré-busca é o que separa o Edge0 do streaming ingênuo.

Duas limitações valem repetir. O Edge0 é exclusivo para macOS e Apple Silicon, e o KV cache cresce sobre o número de cabeçalho conforme o contexto aumenta. Em contextos longos, o pico de memória sobe junto.

FAQ

• O Edge0 roda um modelo de 35B em 3 GB de RAM de verdade? Não. O número de 2,9 GiB mede o pico do alocador MLX, enquanto 18,1 GB de pesos ficam no SSD e são lidos sob demanda. A RAM livre da sua máquina, usada como cache de página, é o que determina a velocidade real.

• Quantos GB por segundo o Edge0 exige do armazenamento? Cerca de 283 MB de experts precisam chegar por token, o que dá de 4 GB a 5 GB por segundo em leituras espalhadas a 15 a 18 tokens por segundo. O número sequencial da caixa do seu SSD não descreve esse tipo de carga.

• O Edge0 funciona em Mac com 8 GB de memória? Um relato no repositório mede cerca de 0,7 token por segundo em um Mac M1 de 8 GB já em swap, contra 24 tokens por segundo no cartão do modelo. O offloading funciona, mas o cache de página não tem espaço e a decodificação fica limitada por page fault.

• O que explica a queda de qualidade do Edge0? Três mudanças se somam: pesos em 4 bits, largura roteada reduzida de oito para quatro experts por token e roteador previsto. Na medição do próprio projeto, a média dos benchmarks fica em 79,2 contra 83,2 da base em precisão total.

• O roteador previsto pode gerar respostas erradas? Pode alterar quais experts calculam o token, porque a previsão não é conferida contra o roteador real. Um caso de overflow em 16 bits no rastreador de bugs fez as saídas colapsarem em pontos de exclamação, corrigido no dia seguinte.

Source video