Show HN: Fazendo o GLM 5.2 rodar no meu computador lento

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.