Ejecutar Kimi K3 usando 29 GB de RAM a 0.50 tok/s

Artículo original ↗ Discusión en Hacker News ↗

Un nuevo motor de código abierto afirma poder ejecutar localmente el modelo completo Kimi K3 de 2.78T parámetros en un portátil usando unos 29 GB de RAM, transmitiendo la mayoría de los pesos desde SSD y logrando alrededor de 0.5 tokens por segundo. Los comentaristas están divididos sobre su utilidad a esa velocidad y su coste energético, pero lo ven como una prueba interesante de lo que técnicamente es posible para inferencia local de LLM de alto nivel. Gran parte del debate se centra en el uso intensivo de código y documentación generados por IA, las concesiones de la cuantización frente a modelos “puros” y si estos proyectos priorizan la artesanía, la claridad y la utilidad a largo plazo.

Concepto del proyecto y rendimiento

  • La herramienta ejecuta el Kimi K3 completo de 2.78T parámetros en hardware de consumo transmitiendo la mayoría de los pesos desde SSD, usando solo ~29 GB de RAM para un contexto de 4k.
  • El rendimiento es de unos 0.5 tokens/segundo; algunos consideran que esto es sobre todo una prueba de concepto más que algo práctico hoy en día.
  • En macOS, se informó que ARM NEON era más rápido que Metal para este proyecto.

Usos prácticos de un K3 a 0.5 tok/s

  • Muchos consideran que 0.5 tok/s es inutilizable para trabajo interactivo, incluso para flujos de trabajo a nivel de correo electrónico.
  • Otros sugieren tareas por lotes durante la noche o de varias horas: revisión de código, análisis de proyectos, resúmenes de reuniones o de semanas de trabajo.
  • Hay debate sobre cuánta “reflexión” puede hacer un modelo a esta velocidad; un comentarista señala que los modelos pueden usar decenas de miles de tokens internos para producir respuestas breves.

Almacenamiento, memoria y diseño del sistema

  • La discusión contrasta un motor de streaming personalizado con enfoques basados en mmap como llama.cpp.
  • Algunos afirman que el prefetching manual y la caché pueden superar significativamente al paging genérico del sistema operativo.
  • Preocupaciones sobre la swap: varios argumentan desactivarla por completo para evitar desgaste del SSD y bajo rendimiento; otros aclaran que el mmap de los pesos en solo lectura no daña la resistencia del SSD.

Cuantización y fidelidad del modelo

  • Este motor usa una variante residual re-cuantizada de 3 bits, no el K3 “puro”.
  • Se cita otro proyecto (deltafin) como capaz de ejecutar K3 sin alteraciones, pero con mayor ancho de banda por token (≈25.8 GB frente a ≈17 GB).
  • Un comentarista califica el README de confuso o contradictorio sobre si el modelo es realmente de “precisión nativa”; en general, no queda claro el impacto en precisión y calidad.

Coste y eficiencia energética

  • Estimación aproximada del coste: ~$5 por un millón de tokens a 42W y $0.20/kWh.
  • Algunos lo comparan desfavorablemente con clústeres de GPU modernos (órdenes de magnitud más tokens por Wh), pero señalan que las GPU tienen un coste inicial alto.
  • La discusión sobre solar/PV se centra en si la energía autoconsumida debe seguir tratándose como un coste de oportunidad real.

Calidad de la documentación y autoría con LLM

  • Un subhilo grande critica el README generado por LLM por ser verboso, opaco y demasiado centrado en lo interno.
  • Otros defienden la documentación asistida por LLM como mejor que no tener documentación, pero están de acuerdo en que debería editarse para mejorar la claridad.
  • Hay un debate más amplio sobre usar LLM para código, commits y documentación: algunos lo ven como “lazy slop”, otros como colaboración eficiente si el código se revisa.

Licencia, marca y confianza

  • Algunos desconfían de la empresa por licencias anteriores no open source y por la aparente confusión del nombre con SQLite.
  • La empresa responde que tiene derechos sobre el nombre y que este proyecto seguirá bajo una licencia permisiva.

Esfuerzos relacionados y perspectiva

  • El hilo cataloga múltiples esfuerzos casi simultáneos de autoalojamiento de Kimi K3: streaming solo con CPU, GPU de consumo y variantes GGUF comprimidas.
  • Muchos consideran este proyecto como un primer paso, todavía poco práctico, hacia una ejecución local eventualmente viable de modelos muy grandes.