Kimi K3 en 8 GB de RAM: funciona, a 26 segundos por token

“Alguien armó un motor en C puro que corre el modelo completo de Kimi K3”, contaba Nix0n en X, “usando solo CPU y 8 GB de RAM”. Ese alguien es Fareed Khan, y el proyecto, kimi-k3-in-c, existe y está muy bien documentado.

La hazaña técnica es real. Lo de que corre “en una laptop normal” hay que leerlo con cuidado: las cifras publicadas se midieron en un servidor de 124 núcleos con la memoria limitada.

Qué es

Un motor de inferencia en C99 para Kimi K3, el modelo de 2,78 billones de parámetros de Moonshot AI. No usa PyTorch, BLAS ni GPU, y su binario pesa 176 KB. Sus únicas dependencias son libm y OpenMP, aunque hace falta Python para descargar y preparar el modelo.

El repo no es de esta semana: se creó el 1 de agosto y la versión 1.1.0 salió el 2 de octubre. Cuando lo consultamos tenía 9.955 estrellas y 9 contribuidores. El motor es Apache 2.0 y no incluye los pesos, que siguen la licencia de Moonshot AI.

Cómo cabe un modelo de 1,56 TB en 8 GB

Kimi K3 ocupa 1,56 TB, pero no usa todo a la vez. El 93 % de esos datos son 82.432 “expertos”, y el modelo solo elige 16 de 896 en cada capa. El motor los lee del disco cuando hacen falta, sin mantener el resto en memoria.

El otro 7 % se usa siempre. Son unos 113 GB, que tampoco caben, así que el motor los transmite capa a capa desde el disco. Más RAM sirve para dejar más capas cargadas. Nada más. Por eso el autor insiste en que la memoria cambia la velocidad, no el resultado.

Lo que dicen las cifras y lo que no

Los datos del tuit coinciden con el README, pero falta la letra pequeña. Las cuatro filas salen de la misma máquina: un servidor con dos AMD EPYC 7763, 124 núcleos, 228 GB de RAM y NVMe rápido. La memoria se limitó por software. El README no incluye ninguna medición en un portátil corriente que respalde esos 26,5 segundos.

Y aquí importa mucho el disco, más que la RAM:

• Lee 25,83 GB por cada token en los escalones bajos de memoria, según las pruebas del autor. Con un SSD SATA a unos 500 MB/s, solo esa lectura supondría cerca de 52 segundos por token (cálculo nuestro).
• El tiempo de espera de disco va del 41 % al 61 % del total. En otro volumen, de red, una ejecución tardó 70,62 s por token frente a 31,71 s en NVMe local.
• El prompt cuesta aparte. Uno de 17 tokens tardó casi 98 segundos en su primer paso y leyó 200 GB, con 128 GB de RAM. El tiempo por token de la tabla es el de la generación, tras un prompt corto.

Además, un portátil con 8 GB justos probablemente no llegue al preset laptop. El script de diagnóstico del repo pide unos 10 GB disponibles, porque el pico real es de 8,24 GB. Para esas máquinas está ultra, con unos 3 GB previstos. Se verificó con cuatro ejecuciones en una Jetson Orin Nano Super. El changelog lo resume así: “lento, por diseño”.

“Es el mismo modelo”, con dos matices

Los pesos son los mismos, sin cuantización añadida. El autor comprobó además los 163.840 valores de salida de una posición frente a una implementación de referencia en PyTorch, con una diferencia máxima de 7,87 × 10⁻⁶. Y 12 presupuestos de memoria produjeron exactamente los mismos tokens.

Pero conviene matizar el “no es una versión recortada”:

• El motor solo hace texto. No tiene visión, llamadas a herramientas, servidor HTTP ni compactación de contexto. El chat sí está incluido, como dice el tuit.
• Esa comparación se hizo con un prompt sintético y en una sola posición. El propio autor avisa de que es una prueba sobre la aritmética y “ninguna evidencia sobre la calidad”. Tampoco hay evaluación de calidad, ya que a estas velocidades llevaría días de cómputo.

Nosotros no lo hemos ejecutado: necesita 1,7 TB libres y una descarga de 1,56 TB. Todas las cifras son las publicadas por el autor. Su documentación es muy detallada, incluidos sus datos en bruto y sus propias dudas: en una prueba, tres ejecuciones idénticas variaron un 33 %.

Para quién tiene sentido

Para usarlo como asistente diario, no. Con 3 horas y 40 minutos por una respuesta de 500 tokens, pagar la API o usar un modelo más pequeño sigue siendo lo práctico.

Sí merece la pena si te interesa cómo funciona la inferencia. El README es casi un libro sobre cómo ejecutar un modelo que no cabe en memoria, y también puede servir para trabajos por lotes sin prisa ni datos que quieras enviar fuera. Si solo quieres curiosear, el repo se puede compilar y probar sin descargar el modelo.