Un desarrollador logró empaquetar Kimi K3, el modelo insignia de código abierto desarrollado por Moonshot AI, en tan solo 29GB de memoria RAM, aproximadamente la capacidad total de una computadora personal estándar. El modelo logró ejecutarse, pero al preguntarle “¿Cuál es la capital de Italia?”, tardó 31 segundos en meditar antes de generar una respuesta de 16 palabras.
Imagen: Kimi K3, el modelo insignia de Moonshot AI liberado a finales de julio. Fuente: github.com/MoonshotAI
Este logro ha generado un intenso debate en las comunidades de desarrolladores durante los últimos días. Con más de 130 votos a favor y 50 comentarios en Hacker News, las opiniones variaron entre el asombro y el escepticismo técnico. A continuación, desglosamos los detalles clave y los puntos de discusión.
¿Por qué los modelos consumen tanta memoria?
Para comprender este hito, primero debemos aclarar la escala real de Kimi K3.
Kimi K3 es el modelo insignia más reciente presentado por Moonshot AI a finales de julio de 2026, con una cifra asombrosa de 2,78 billones de parámetros (2,78T).
Los parámetros pueden entenderse como los números almacenados en la red neuronal del modelo. La inteligencia de la IA depende de realizar operaciones matemáticas sobre este enorme conjunto de valores: por lo general, a mayor número de parámetros, mayor es la capacidad del modelo, pero también mayor es su tamaño en disco y memoria. En su versión oficial (comprimida a FP4), K3 ocupa 1,42TB, lo que ni siquiera cabe en un SSD estándar de 1TB.
Durante la inferencia, el modelo necesita cargar estos parámetros en la memoria RAM para realizar los cálculos. Intentar meter 1,42TB de datos en un espacio de 29GB de RAM representa un déficit de capacidad de casi 50 veces.
Normalmente, los modelos de esta magnitud operan exclusivamente en centros de datos en la nube equipados con cientos de miles de servidores, clústeres de GPU y terabytes de memoria RAM. Cuando realizas una consulta desde una app, el procesamiento ocurre en esos servidores y el resultado se envía de vuelta por streaming.
¿Por qué empeñarse en ejecutarlo de manera local?
Si los servicios en la nube son rápidos, prácticos y estables, ¿por qué hay ingenieros dispuestos a realizar semejante esfuerzo para ejecutar modelos localmente? Los motivos son bastante concretos.
El primer motivo es la privacidad. Cada frase enviada a la nube viaja a servidores de terceros. Aunque una charla informal no suponga un riesgo, muchas organizaciones prohíben estrictamente el envío externo de contratos, código fuente, registros médicos o informes financieros. Garantizar que los datos no salgan del equipo es la razón más sólida para la IA local.
El segundo motivo es el costo. Los proveedores en la nube cobran por token consumido. Si bien el costo es marginal para un uso cotidiano, se vuelve significativo al procesar grandes volúmenes de datos o ejecutar agentes autónomos. La inferencia local requiere una inversión única en hardware: una vez adquirido el disco y cubierta la electricidad, el uso es ilimitado.
El tercer motivo es la independencia offline. La ejecución local no requiere conexión a internet y queda inmune a caídas del servicio, incrementos en las tarifas de API o cambios en las políticas de los proveedores.
Además, existe el entusiasmo técnico de la comunidad. En el ámbito de la “inferencia local”, desarrolladores apasionados buscan constantemente superar los límites del hardware, logrando que modelos aparentemente inalcanzables se ejecuten en equipos domésticos. El proyecto, bautizado como WASTE, publicó todo su diseño y registros de experimentos en GitHub.
¿Cómo lograron empaquetar Kimi K3 en 29GB de RAM?
La primera técnica clave es la cuantización: reducir la precisión numérica de los pesos del modelo.
Originalmente, los parámetros se almacenan en formato de coma flotante de alta precisión. La cuantización recorta los decimales y guarda los valores en formatos de 4 u 8 bits. La versión oficial de K3 ya venía comprimida a 4 bits (1,42TB), y el proyecto WASTE cuantizó los componentes de los “expertos” aún más, reduciéndolos a 3 bits para alcanzar un tamaño total de 982GB.
Sin embargo, la compresión por sí sola no permite pasar de 982GB a 29GB. El verdadero truco de WASTE consiste en no cargar el modelo completo en la memoria RAM.
Kimi K3 utiliza una arquitectura de Mezcla de Expertos (MoE, Mixture of Experts) con 896 redes expertas. Lo crucial es que al generar cada palabra (token), solo se activan 16 expertos, mientras que los 880 restantes permanecen inactivos. Es similar a un gran hospital donde en cada consulta solo intervienen los médicos especialistas necesarios, mientras el resto permanece en espera.
Así, WASTE mantiene la estructura principal del modelo (27GB) fija en la memoria RAM, mientras que los 880 expertos restantes se quedan en el disco SSD y se leen dinámicamente en tiempo real solo cuando son requeridos.
Imagen: Visión general de la arquitectura de K3: Mezcla de Expertos con nuevo mecanismo de atención y 2,8 billones de parámetros. Fuente: sebastianraschka.com
La contrapartida es la velocidad. Para generar cada palabra, el sistema debe leer 17GB de datos de expertos desde el SSD. Un SSD NVMe interno de muy alta velocidad (12,78 GB/s) apenas logra mantener el ritmo; si se utiliza un disco externo USB (0,94 GB/s), la espera se eleva a 13 segundos por palabra.
Preparar este entorno tampoco es sencillo. Convertir los 1,42TB de la versión oficial a los 982GB cuantizados requiere casi 5 horas de procesamiento, además de contar con almacenamiento NVMe de alto rendimiento.
Por lo tanto, la cifra de “29GB” representa el umbral de memoria RAM del sistema, no el tamaño total del modelo. Los 29GB de RAM no contienen todo el modelo, solo albergan la estructura central más utilizada. Aunque un equipo con 32GB de RAM puede iniciar el proceso, se recomiendan 64GB para evitar que el sistema operativo use el disco como memoria virtual, lo que reduciría la velocidad 8 veces más.
El costo de una compresión agresiva
La cuantización no es gratuita. Al reducir la precisión de los números, la fidelidad de las respuestas disminuye. Pruebas realizadas por el equipo de Unsloth demuestran que la cuantización a 2 bits mantiene alrededor del 90% de coincidencia con el modelo original, mientras que a 1 bit la fidelidad cae cerca del 80%.
Imagen: A mayor compresión del modelo, mayor es la probabilidad de divergencia en las respuestas frente a la versión original. Fuente: unsloth.ai
Además, la calidad de la cuantización varía drásticamente según la técnica empleada. Dos versiones de 1 bit creadas por equipos distintos pueden presentar diferencias de rendimiento de más de 20 veces. La cuantización es una técnica artesanal compleja, no un simple recorte de dígitos.
0,5 tokens por segundo: Entre “funciona” y “es útil”
Una velocidad de 0,5 tokens por segundo equivale a generar aproximadamente media palabra por segundo.
Una respuesta corta de 16 palabras requiere 31 segundos, mientras que un texto de 128 palabras toma seis minutos. Esta velocidad resulta impráctica no solo para conversar, sino incluso para copiar texto. Además, como K3 es un modelo diseñado para “pensar antes de responder”, genera una cadena de pensamiento previa a la respuesta final, lo que incrementa el tiempo de espera en entornos locales.
No obstante, la postura de los creadores del proyecto es transparente: no promocionan la velocidad, sino el hecho de haber logrado ejecutarlo. Verificaron capa por capa la salida del modelo frente a la implementación oficial de referencia, confirmando un margen de error de unas pocas millonésimas. Según sus indagaciones, este es el primer caso documentado de un modelo de más de un billón de parámetros ejecutado mediante streaming desde SSD en una computadora personal.
En cambio, al aplicar este mismo método a modelos más pequeños, el panorama cambia por completo: el modelo Kimi-Linear de 48.000 millones de parámetros ocupa 19GB en disco, inicia con solo 1,87GB de memoria RAM y alcanza 10,7 palabras por segundo en un equipo estándar. Del mismo modo, en un centro de datos con GPU dedicadas, K3 supera los 100 tokens por segundo.
Entre “lograr que funcione” y “ser una herramienta práctica” existe una gran distancia. En una orilla está la hazaña de ingeniería; en la otra, la utilidad cotidiana. Este avance ha logrado acortar esa brecha.
El debate entre la inferencia local y la nube
Este experimento reavivó una discusión recurrente entre los defensores de la IA local y los partidarios de la nube.
- El bando local destaca la privacidad de los datos, la ausencia de tarifas recurrentes por token, el funcionamiento sin conexión y el control total del entorno.
- El bando de la nube resalta la velocidad (decenas o cientos de tokens por segundo), el acceso continuo a los modelos más recientes y la ausencia de mantenimiento de hardware.
En Hacker News, algunos ingenieros cuestionaron si la afirmación de ejecutar un modelo de 2,78T en 29GB de RAM era precisa, señalando que la estructura densa del modelo requeriría al menos 115GB de RAM en precisión nativa. Los autores explicaron que la combinación de cuantización de 3 bits para los expertos y el streaming mediante NVMe hace técnicamente válida la cifra.
Este tipo de debate riguroso impulsa a la comunidad. La inferencia local ha superado múltiples barreras históricas gracias a esta dinámica de cuestionamiento, prueba y perfeccionamiento.
Conclusión
Requerir 29GB de RAM para obtener medio token por segundo dista mucho de ser una solución práctica para el uso diario. Sin embargo, al analizar la trayectoria histórica, el progreso es notable: hace dos años, ejecutar un modelo de decenas de miles de millones de parámetros en una PC era noticia; hoy, modelos del orden del billón de parámetros comienzan a estar al alcance de equipos personales. A medida que mejore la velocidad de los SSD, se perfeccione la cuantización y se optimicen las arquitecturas, esta frontera seguirá desplazándose.
Para la mayoría de los usuarios, utilizar la app oficial de Kimi sigue siendo la opción más rápida. Pero la próxima vez que la pantalla indique “Respuesta generada en la nube”, valdrá la pena recordar la inmensa infraestructura y los desafíos técnicos que hacen posible esas palabras.
Enlaces de referencia:
- GitHub: Repositorio sqliteai/waste
- Discusión en HN (item?id=49123386)
- Hugging Face: Hilo de discusión #148 de moonshotai/Kimi-K3
- Sebastian Raschka: Notas sobre la arquitectura de Kimi K3
- Unsloth: Documentación para la ejecución local de Kimi K3
- Blog de Apidog: Cómo ejecutar Kimi K3 de manera local
