Cómo kimi-k3-in-c hace funcionar 2,8 billones de parámetros con 8 GB de RAM

TL;DR

kimi-k3-in-c nunca carga el modelo completo en memoria. Mantiene siempre residente una pequeña parte fija (el tronco denso) y va a buscar el resto (los expertos) al disco por cada palabra generada, tomando solo los 16 expertos de 896 que realmente son útiles. Los expertos ya están comprimidos a 4 bits en el disco, una caché mantiene a mano los más solicitados, y la cantidad de RAM asignada solo regula la velocidad: la respuesta producida es idéntica, le des 8 GB o 224 GB.

---

El problema planteado: un archivo que no cabe en ninguna parte

El checkpoint de Kimi K3 pesa 1,56 TB en disco, repartido en 96 archivos. Ninguna máquina de consumo, ni ningún servidor por debajo del terabyte de RAM, tiene memoria suficiente para cargarlo entero. La cuestión que resuelve kimi-k3-in-c no es, por tanto, "cómo calcular más rápido", sino "cómo hacer que quepa un modelo 200 veces más grande que la RAM disponible sin cambiar su salida".

La respuesta se resume en cuatro decisiones de arquitectura, aplicadas en orden.

Recordatorio: un modelo de mezcla de expertos

Kimi K3 es un modelo de mezcla de expertos (Mixture-of-Experts, MoE). En lugar de una sola red grande que procesa cada palabra con todos sus parámetros, el modelo contiene 896 subredes especializadas, los expertos, y un enrutador que selecciona 16 para cada palabra que hay que producir.

Un modelo denso del mismo tamaño usaría sus 2,8 billones de parámetros en cada cálculo. Un modelo MoE como Kimi K3 solo activa una fracción: unos 104 mil millones de parámetros activos por palabra, es decir, el 3,7 % de los 2,8 billones almacenados. Esta propiedad, y no un truco de compresión, es la que hace posible el resto de la arquitectura.

Reducción uno: los expertos ya están a medio comprimir

En el disco, cada experto se almacena en formato MXFP4, un flotante de 4 bits en lugar de los 16 o 32 bits habituales. El motor multiplica directamente sobre esta representación compacta, sin pasar por una versión descomprimida en memoria. Primera ganancia: 1,45 TB de expertos enrutados caben en una cuarta parte de su peso original.

Reducción dos: separar lo que se queda fijo de lo que circula

El modelo se divide en dos partes de naturaleza distinta. El tronco denso, 93 capas que usan atención (MLA, un único latente compartido en lugar de 96 cabezas separadas, y KDA, una atención lineal cuya memoria no crece con el texto), se queda en memoria de forma permanente o se relee desde un archivo compacto según el presupuesto elegido. Los 1,45 TB de expertos enrutados, en cambio, nunca son residentes: se leen y se multiplican directamente desde el disco, bajo demanda.

El tronco se reescribe una vez, en el formato de un archivo de 109 GB donde cada capa vive en una ubicación conocida y se lee con una sola llamada a disco. Esta reescritura, el empaquetado, es lo que convierte la restricción de memoria en un mando regulable en lugar de un techo fijo.

La caché LRU: qué expertos mantener calientes

Con cada palabra generada, el motor ya sabe qué 16 expertos de 896 debe consultar, el enrutador acaba de designarlos. Una caché LRU (least recently used, el menos recientemente usado es el primero en ser expulsado) mantiene en memoria los expertos solicitados con más frecuencia, para evitar releerlos cada vez que vuelven a aparecer.

El tamaño de esta caché depende directamente del presupuesto de RAM elegido mediante los preajustes del motor (laptop, workstation, server). Cuanto mayor es, menos relee el motor el disco para los mismos expertos y más se acelera la generación.

El verdadero cuello de botella: el disco, no el cálculo

Las mediciones publicadas en el repositorio son inequívocas. Con el preajuste laptop, 8,24 GB de RAM, el motor produce una palabra cada 32,7 segundos de media. Con el preajuste server, 127,92 GB de RAM, ese retardo baja a 10,7 segundos por palabra.

El cálculo en sí, una multiplicación de matrices sobre 104 mil millones de parámetros activos, tardaría unos cientos de milisegundos en una CPU moderna. La diferencia viene de otro lado: cada experto que falta en la caché debe leerse del disco antes de poder multiplicarse, y esa lectura domina el tiempo total. Darle más RAM al motor no lo hace calcular más rápido, le evita releer el disco con tanta frecuencia.

Por qué la salida nunca cambia

Un detalle distingue este proyecto de una compresión con pérdida clásica: el presupuesto de memoria no modifica ni los pesos ni los cálculos, solo el lugar por el que transitan los datos antes de usarse. Tanto si el tronco es totalmente residente como si se relee capa por capa, tanto si la caché de expertos contiene 100 como 10 000 entradas, cada experto acaba multiplicado en su forma completa y exacta. El repositorio lo demuestra con una suite de pruebas que compara la salida del motor con una referencia de PyTorch, posición por posición, sobre un modelo reducido que comparte el mismo grafo tensorial que Kimi K3.

Qué se puede sacar de esto

La idea general, separar un modelo en una parte pequeña y siempre útil y otra grande y raramente consultada, y cargar esta última solo bajo demanda, se aplica mucho más allá de este proyecto. Es el principio detrás de la carga bajo demanda de llama.cpp o de los offloads de expertos para DeepSeek. kimi-k3-in-c ofrece una implementación especialmente legible, en C99 sin dependencias, con pruebas que demuestran cada afirmación en lugar de limitarse a enunciarla.

Queda la cuestión del uso real: de 10 a 32 segundos por palabra frente a lo que permite hoy una GPU, la diferencia no es anecdótica. Por qué una GPU sigue siendo indispensable detalla con precisión esa diferencia.