Show HN: Fazendo o GLM 5.2 rodar no meu computador lento
Colocar um enorme modelo de linguagem GLM 5.2 em hardware modesto, majoritariamente só com CPU, usando streaming via NVMe dá aos entusiastas uma forma de executar IA em escala de ponta localmente, embora com velocidades de tokens muito baixas. Os comentaristas ponderam os compromissos entre desgaste do SSD, limites de RAM e alternativas em rede ou com GPU, e comparam essa abordagem a motores baseados em mmap como o llama.cpp e outros projetos de streaming via SSD. Muitos veem isso como uma prova de conceito impressionante que pode influenciar uma inferência mais eficiente tanto em máquinas de baixo custo quanto em configurações de ponta com bastante RAM ou memória unificada.
Conceito do projeto e espírito hacker
- A ferramenta executa modelos MoE GLM 5.2 muito grandes em hardware “lento” / de consumo ao fazer streaming agressivo dos pesos a partir de NVMe, em vez de manter tudo na RAM.
- Muitos comentários elogiam a implementação minimalista, quase ofuscada, e o espírito geral de “fazer as coisas rodarem onde não foram feitas para rodar”.
- Várias pessoas mencionam fazer experimentos semelhantes (motores de streaming personalizados, runners baseados em mmap, Medusa/MTP, ports em Rust) e veem isso como parte de uma tendência mais ampla.
Desempenho e praticidade
- As velocidades relatadas para hardware de baixo custo (≈0.05–0.1 tok/s) são vistas por alguns como lentas demais para uso interativo, embora outros considerem até 1 tok/s aceitável para cargas noturnas ou em lote.
- Há interesse em benchmarks em CPUs de ponta, servidores com muita RAM e GPUs; alguns esperam que, com RAM suficiente, uma configuração padrão do llama.cpp possa superar o streaming via SSD.
- Surgem comparações com outros projetos (llama.cpp, flash-moe, hypura, fastllm), e uma questão em aberto é se essa abordagem é de fato mais rápida do que motores maduros que já usam mmap e quantização.
Hardware, custo e alternativas
- Há debate sobre se “pessoas comuns” conseguem pagar por 24+ GB de RAM e grandes SSDs NVMe, dado o aumento dos preços de memória.
- As sugestões incluem servidores rackmount usados com 512GB–1TB de RAM, máquinas no estilo Mac Studio ou GLM 5.2 hospedado na nuvem, muitas vezes como opções mais práticas.
- Vários usuários exploram ideias como RAID0/SSDs paralelos, configurações híbridas CPU/GPU e o uso de memória unificada no Apple Silicon.
Desgaste de SSD, swap e segurança
- O README alerta sobre possível desgaste do SSD; isso gera preocupação para laptops com SSD soldado e propostas de usar drives externos “descartáveis”.
- As explicações variam: alguns atribuem o risco ao swap e à expulsão do cache de páginas (“spilling”); outros enfatizam que o app em si faz apenas leituras e que o aviso é conservador.
- Mitigações discutidas: desativar swap, ajustar swappiness, partições ou imagens somente leitura. A magnitude exata do desgaste causada por leituras intensas ainda é um pouco incerta.
Interfaces e fluxos de trabalho para modelos lentos
- Vários comentaristas argumentam que interfaces de chat são uma má escolha para modelos locais muito lentos e propõem sistemas de tickets/filas em vez disso.
- As ideias incluem orquestradores que distribuem tarefas para agentes trabalhadores e integrações simples via e-mail e filas de tickets para tratar o modelo como um colega de equipe lento, mas confiável.
Questões específicas de MoE e arquitetura
- Surgem perguntas sobre distribuir experts via MPI em um cluster; a resposta é que isso é teoricamente possível, mas a latência de rede provavelmente domina em clusters pequenos.
- Desativar todos, exceto um expert, é considerado possível, mas degradaria drasticamente a qualidade; é recomendável usar um modelo denso menor em vez disso.