Slotstream roda modelo de 104 GB em Mac de 48 GB fazendo streaming do SSD

Rodar um modelo de linguagem↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → que ocupa 104 GB em disco num Mac que tem só 48 GB de RAM sempre esbarrou na mesma parede: ou o peso cabe na memória, ou você desiste.

Nota da redação: não conseguimos confirmar o nome completo do autor do projeto. A fonte disponível (README e página do GitHub) identifica apenas o usuário 'carloslfu', sem revelar nome civil. Optamos por manter no texto apenas essa identificação verificável; isso não afeta os números e comportamentos técnicos do projeto, que foram checados linha a linha contra a documentação original.

O slotstream, projeto open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → do desenvolvedor identificado no GitHub como carloslfu, publicado no Hacker News, propõe um caminho diferente: manter o grosso do modelo no SSD e transmitir para a RAM só as partes que cada token precisa. O resultado medido pelo autor é o Qwen3.8-Flash-Next (125B de parâmetros, arquitetura MoE, 104 GB em 4-bit) rodando a cerca de 12 tokens/s num MacBook M5 Pro de 48 GB.

Para quem constrói software no Brasil e olha para IA local, o ponto não é o número em si, mas o que ele destrava: modelos que antes exigiam workstation com 128 GB (ou GPU dedicada cara) passam a ser viáveis em hardware que muita gente já tem na mesa.

Por que o mmap tradicional não resolve

O truque que quase todo mundo tentaria primeiro, mapear o arquivo em memória com mmap e deixar o sistema paginar, não funciona aqui, e o README explica por quê. O MLX (framework de machine learning da Apple para Apple Silicon) não consegue materializar só um pedaço de um tensor mapeado. Segundo o autor:

MLX cannot materialize part of a memory-mapped tensor: a top-10 expert gather evaluates all 512 experts of that layer, and a 16-row n-gram lookup evaluates the whole 250 MB shard, so an mmap path loads ~100 GB and dies.

README do slotstream

Na prática, a rota padrão mlx_lm.load() levou o Mac de 48 GB a 48 GB de swap sem gerar um único token. O mmap carrega tudo e morre.

Como o slotstream distribui os 104 GB

A sacada está em entender onde estão os bytes do modelo. Em um MoE (Mixture of Experts), a maior parte do peso não é usada a cada passo. A distribuição do Qwen3.8-Flash-Next, segundo o projeto:

Os experts são lidos com pread direto para um pool fixo de slots de cache compartilhado pelas 48 camadas, de modo que camadas "quentes" tomam emprestado slots das "frias". O tronco denso, que é minúsculo perto do resto, permanece na memória o tempo todo.

Um detalhe importante para quem se preocupa com reprodutibilidade: o tamanho do cache muda a velocidade, nunca a saída. O decode guloso (greedy) é byte a byte idêntico entre um cache de 4 GB e um de 24 GB, e isso é garantido por teste no projeto.

O que esperar por faixa de memória

O projeto se auto-dimensiona: sem flags, ele lê a máquina e escolhe um alvo. Só a linha de 48 GB foi medida em hardware real (o tal M5 Pro); as demais são derivadas da mesma curva e vêm com a ressalva de que Macs menores também têm SSD mais lento.

O número 33 GB não é gentileza, é o "joelho" da curva: o menor alvo em que o cache de experts vence o platô de decode e ainda sobra orçamento para o prefill rápido de 4.096 tokens. Segundo o autor, varrendo GB a GB nada entre 34 e 84 GB melhora a velocidade. Ou seja, um Mac de 64 ou 128 GB pede os mesmos 33 GB, o excedente não compra nada. O processo também é elástico: reavalia a cada 15 s e redimensiona o cache entre requisições.

Disco é o verdadeiro portão de entrada

Antes da RAM, o que trava é o SSD. São necessários ~110 GB livres, o que torna um Mac de 512 GB o mínimo realista, não importa quanta memória tenha. O download dos pesos é único: 103,8 GB em 24 arquivos, verificados contra hashes sha256 compilados no binário (download truncado ou corrompido não chega ao motor). Interromper é seguro, ele retoma no byte exato.

Uma constatação curiosa da fonte: o gargalo do download é o Hugging Face, não a sua conexão. Acima de ~400 Mbps, mais banda não ajuda, o próprio cliente rápido hf_xet estagnou na faixa de 36 a 57 MB/s enquanto o mesmo link fazia 134 MB/s para um host comum.

Instalação e API compatível com Ollama

A instalação é uma linha (Apple Silicon e macOS 14+):

curl -fsSL https://raw.githubusercontent.com/carloslfu/slotstream/main/install.sh | sh

Ou compilar do zero, sem precisar de Xcode (Command Line Tools bastam):

git clone https://github.com/carloslfu/slotstream && cd slotstream
make build

O ponto que mais interessa para quem já tem código apontando para modelos locais: o serve escuta na porta 11434 e implementa o subconjunto chat/generate usado por clientes Ollama e SDKs da OpenAI. Ou seja, dá para plugar sem reescrever a integração:

curl localhost:11434/api/chat -d '{
  "model": "qwen3.8-flash-next:4bit",
  "messages": [{"role": "user", "content": "hello"}]
}'

Streaming, CORS e as opções usuais de sampling (temperature, top_p, top_k, min_p, presence_penalty, seed, num_predict, stop) são suportados. O que não é (tools, imagens, saída em JSON-schema, logprobs) devolve um 400 claro em vez de ser ignorado em silêncio. Open WebUI, o CLI do Ollama e os SDKs da OpenAI foram testados para esse subconjunto.

Onde ainda dói

O projeto é honesto sobre os limites. Prompts longos são o eixo lento: tudo no prompt é processado antes do primeiro token. O prefill roda a ~50 tok/s num Mac de 16 GB e ~125 num de 48 GB, então um prompt de 8.000 tokens espera entre cerca de um e três minutos pelo primeiro token. Dentro de uma conversa isso se paga uma vez só, turnos seguintes reprocessam apenas o que é novo (medido: 6,0 s em vez de escalar para 25,8 s ao longo de oito turnos). O contexto total (prompt mais resposta) é limitado a 32.768 tokens.

Outro ponto: residência total dos experts (todos os 512 por camada, sem leituras de SSD) exigiria cerca de 88 GB e nunca foi medida. E o runtime só foi exercitado em uma máquina, o M5 Pro de 48 GB, as demais faixas são extrapolação de curva. Em macOS 14 e 15 só o instalador foi testado, não o runtime.

A licença é MIT (os pesos seguem a licença community do Qwen). O PLAN.md traz o design e o rastreador de milestones, e o MEASUREMENTS.md documenta cada número com o método, incluindo os experimentos que falharam, o que é um bom sinal de rigor para quem for avaliar se vale trazer para o próprio setup.

Fonte: Hacker News