El desarrollador Fareed Khan ha publicado kimi-k3-in-c, un motor de inferencia escrito en C99 que ejecuta el modelo completo Kimi K3, de 2,78 billones de parámetros, en una sola CPU y con un pico de memoria medido de 8,24 GB, sin GPU, sin PyTorch y sin librerías de cálculo externas. No es una versión reducida ni destilada: es el mismo modelo que se publica en Hugging Face, y el autor asegura que la salida es idéntica byte a byte se ejecute con 8 GB o con más de 200 GB de RAM. Lo que cambia es la velocidad: con la memoria mínima, cada token tarda unos 26 segundos en generarse.
Las claves de Kimi K3 en C con 8 GB de RAM en 20 segundos
- Qué es: un motor en C de 176 KB que ejecuta Kimi K3 completo solo con CPU.
- Velocidad: 26,5 s por token con 8 GB de RAM y 5,6 s con 128 GB o más.
- Requisito real: unos 1,7 TB de SSD rápido para el modelo.
El repositorio, con licencia Apache 2.0, se ha convertido en uno de los proyectos más comentados del momento en GitHub, con más de 9.000 estrellas. Su atractivo es evidente: Kimi K3, el modelo abierto de Moonshot AI, ocupa 1,56 TB tal como se distribuye y, en principio, exige un clúster de GPU para funcionar. Este proyecto demuestra que, si se acepta esperar, basta con un ordenador corriente con mucho espacio en disco.
El truco: casi todo el modelo duerme en el disco
La clave está en la arquitectura de Kimi K3, una mezcla de expertos (MoE). El modelo tiene 93 capas; la primera es densa y las otras 92 contienen cada una 896 expertos, de los que solo se activan 16 para cada token. Según los cálculos del autor, de los 2,78 billones de parámetros solo unos 104.000 millones, el 3,7 %, intervienen en cada paso. El resto tiene que estar accesible, pero no en memoria.
Los 82.432 expertos enrutados ocupan 1,447 TB, el 93 % del modelo, y se distribuyen ya en MXFP4, un formato de 4 bits por peso. El motor nunca los mantiene residentes: los lee del disco cuando el enrutador los pide y multiplica directamente sobre ese formato empaquetado, sin convertirlos a decimales de 32 bits. La parte que siempre se usa, el tronco denso con la atención, los enrutadores y los expertos compartidos, ocupa unos 113 GB y tampoco tiene por qué caber en RAM: se reempaqueta en un archivo de 109 GB que se va leyendo capa a capa. El autor resume el proceso como una cadena de reducciones que va de los 5.560 GB que ocuparía el modelo en bfloat16 a los 8,24 GB medidos, sin aproximar ni eliminar ningún peso.
Todo el motor cabe en un binario de 179.736 bytes, unos 176 KB, compilado a partir de un puñado de archivos en C con OpenMP como única dependencia. Necesita una CPU con AVX2 y FMA en x86-64 o NEON en ARM; no requiere AVX-512. Funciona en Linux, que es la plataforma de referencia, y también compila y pasa las pruebas en macOS con Apple Silicon y en Windows a través de MSYS2. Incluye un modo chat con el formato oficial del modelo, historial de conversación y la opción de desactivar el razonamiento, que según el autor es la mayor palanca de velocidad: en una prueba, 119 de los 150 tokens de una respuesta corta eran la fase de pensamiento.
Más RAM compra velocidad, no capacidad
El proyecto organiza la memoria en perfiles. Con 8 GB, todo el modelo se lee del disco en cada paso y la generación va a 26,5 segundos por token. Con 32 GB baja a 24,2 segundos y con 64 GB, a 19,8. Solo cuando hay 128 GB o más el tronco cabe entero en memoria y desaparece la espera del disco: 5,6 segundos por token. Existe incluso un perfil experimental de unos 3 GB para equipos muy limitados, que el autor presenta como prueba de vida, no como opción de uso.
Hay un matiz importante en esas cifras. Todas se midieron en una misma estación de trabajo con dos procesadores AMD EPYC 7763, 124 núcleos, 228 GB de RAM y almacenamiento NVMe rápido, limitando la memoria con grupos de control de Linux para simular cada escenario. Es decir, no se midieron en un portátil de 8 GB real, cuya CPU y cuyo SSD serán bastante más lentos. El propio autor avisa de que, con poca memoria, el cuello de botella es el disco, y que un SSD más lento o una unidad de red multiplican los tiempos. El perfil más modesto, además, recomienda unos 10 GB de memoria disponible para trabajar con margen.
El otro requisito es el almacenamiento: hacen falta unos 1,7 TB libres, 1,56 TB para el modelo y 109 GB para el tronco reempaquetado, idealmente en un NVMe local. La descarga lleva horas, y el script verifica el tamaño exacto de cada uno de los 96 archivos, porque una descarga incompleta no falla: produce tokens equivocados.
Salida idéntica, comprobada contra PyTorch
La afirmación de que el modelo es el mismo no se queda en la palabra del autor. El repositorio incluye una batería de pruebas que compara el motor con una implementación de referencia en PyTorch de forma exacta, no con un margen de tolerancia, sobre un modelo de prueba de 13 capas con la misma estructura y después sobre el modelo completo. Para conseguirlo, el autor renunció a usar librerías BLAS: cada una suma los productos en un orden distinto y produce resultados que difieren en los últimos bits según la versión o el número de hilos. Sus propias rutinas fijan ese orden para que la salida sea la misma en cualquier máquina. El tokenizador también se valida carácter a carácter frente a la librería oficial en chino, japonés, coreano, árabe o emojis.
Para el usuario, el proyecto no sustituye a una GPU ni a una API: a 26 segundos por token, una respuesta de unas pocas frases puede tardar media hora. Su valor está en otra parte. Demuestra que la barrera para ejecutar modelos gigantes de mezcla de expertos en casa ya no es la memoria, sino el disco y la paciencia, y documenta con detalle cada decisión de ingeniería, algo poco habitual. Es un buen material para quien quiera entender cómo funcionan por dentro estos modelos.
Preguntas frecuentes
¿Se puede ejecutar Kimi K3 sin GPU?
Sí, con kimi-k3-in-c, que usa solo CPU. El modelo completo funciona con unos 8 GB de RAM, aunque a unos 26 segundos por token.
¿Cuánto disco hace falta?
Unos 1,7 TB: 1,56 TB del modelo y 109 GB del tronco reempaquetado, preferiblemente en un SSD NVMe local.
¿El resultado es igual que con más memoria?
Según el autor, sí: la salida es idéntica byte a byte con cualquier cantidad de RAM, y el motor se valida de forma exacta contra una referencia en PyTorch.
¿En qué sistemas funciona?
Linux como plataforma de referencia, y también macOS con Apple Silicon y Windows mediante MSYS2. Requiere una CPU con AVX2 y FMA o NEON.
Fuentes:
