Show HN: Haciendo que GLM 5.2 funcione en mi ordenador lento
Empujar un modelo lingüístico GLM 5.2 masivo sobre hardware modesto, mayoritariamente solo CPU, usando streaming desde NVMe está dando a los aficionados una forma de ejecutar IA a escala de frontera de forma local, aunque a velocidades de tokens muy bajas. Los comentaristas valoran los compromisos entre desgaste del SSD, límites de RAM y alternativas en red o GPU, y comparan este enfoque con motores basados en mmap como llama.cpp y otros proyectos de streaming desde SSD. Muchos lo ven como una prueba de concepto impresionante que podría influir en una inferencia más eficiente tanto en máquinas de gama baja como en configuraciones de gama alta con mucha RAM o memoria unificada.
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.