Show HN: Haciendo que GLM 5.2 funcione en mi ordenador lento

Concepto del proyecto y espíritu hacker

• La herramienta ejecuta modelos MoE GLM 5.2 muy grandes en hardware “lento” / de consumo, transmitiendo agresivamente los pesos desde NVMe en lugar de mantenerlo todo en RAM.
• Muchos comentarios elogian la implementación minimalista, casi ofuscada, y el espíritu general de “hacer correr cosas donde no estaban destinadas a correr”.
• Varias personas mencionan experimentos similares (motores personalizados de streaming, ejecutores basados en mmap, Medusa/MTP, ports a Rust) y lo ven como parte de una tendencia más amplia.

Rendimiento y practicidad

• Las velocidades reportadas para hardware de gama baja (≈0.05–0.1 tok/s) parecen demasiado lentas para uso interactivo para algunos, aunque otros consideran aceptable incluso 1 tok/s para cargas nocturnas o por lotes.
• Hay interés en benchmarks en CPUs de gama alta, servidores con mucha RAM y GPUs; algunos esperan que, con suficiente RAM, una configuración estándar de llama.cpp supere al streaming desde SSD.
• Surgen comparaciones con otros proyectos (llama.cpp, flash-moe, hypura, fastllm), y una pregunta abierta es si este enfoque es realmente más rápido que motores maduros que ya usan mmap y cuantización.

Hardware, asequibilidad y alternativas

• Debate sobre si la “gente común” puede permitirse 24+ GB de RAM y grandes unidades NVMe, dadas las subidas de precio de la memoria.
• Las sugerencias incluyen servidores rackmount usados con 512 GB–1 TB de RAM, máquinas de clase Mac Studio o GLM 5.2 alojado en la nube, que a menudo resultan más prácticos.
• Varios usuarios exploran ideas como RAID0/SSDs en paralelo, configuraciones híbridas CPU/GPU y aprovechar la memoria unificada en Apple Silicon.

Desgaste del SSD, swapping y seguridad

• El README advierte sobre posible desgaste del SSD; esto genera preocupación en portátiles con SSD soldados y propuestas para usar unidades externas “de sacrificio”.
• Las explicaciones varían: algunos atribuyen el riesgo al swap y a la expulsión de la caché de páginas (“spilling”); otros subrayan que la app en sí solo realiza lecturas y que la advertencia es conservadora.
• Se comentan mitigaciones: desactivar swap, ajustar swappiness, particiones o imágenes de solo lectura. La magnitud exacta del desgaste por lecturas intensivas sigue siendo algo incierta.

Interfaces y flujos de trabajo para modelos lentos

• Varios comentaristas sostienen que las interfaces de chat son una mala opción para modelos locales muy lentos y proponen en su lugar sistemas de tickets/trabajos.
• Las ideas incluyen orquestadores que distribuyen tareas a agentes trabajadores, e integraciones simples por email y colas de tickets para tratar al modelo como un compañero de equipo lento pero fiable.

Cuestiones específicas de MoE y arquitectura

• Se plantean preguntas sobre distribuir expertos mediante MPI en un clúster; la respuesta: teóricamente posible, pero la latencia de red probablemente dominaría en clústeres pequeños.
• Desactivar todos los expertos salvo uno se considera posible, pero degradaría mucho la calidad; en su lugar se recomienda usar un modelo denso más pequeño.