Kimi K3 ejecuta un modelo de 2,78 billones de parametros con 8,24 GB de memoria

Ejecutar un modelo de 2,78 billones de parametros con ocho gigabytes de memoria parece un truco de magia. El repositorio kimi-k3-in-c muestra donde esta el truco: el modelo no cabe en la RAM y tampoco intenta hacerlo. El motor conserva en memoria unicamente el conjunto de datos de trabajo y lee la mayor parte de los pesos desde el almacenamiento a medida que avanza el calculo.

Segun las mediciones del autor, una ejecucion completa de Kimi K3 alcanza un consumo maximo de 8,24 GB de RAM. No requiere GPU, BLAS ni el framework de ML habitual: el nucleo esta escrito en C99 portable. La contrapartida de esa cifra impresionante es un checkpoint de 1,56 TB, un archivo adicional de 109 GB que contiene la parte densa del modelo en formato empaquetado y decenas de segundos de espera por cada token.

Como cabe el modelo en una memoria convencional

Imagine un armario del que solo necesita un cajon cada vez. No tiene sentido llevar todo el armario hasta la mesa: basta con abrir el cajon necesario, procesar su contenido y pasar al siguiente. En este caso, la unidad NVMe rapida desempeña el papel del armario y la RAM, el de la mesa.

Kimi K3 utiliza una arquitectura dispersa: en cada paso solo esta activa una parte de los expertos. El motor lee directamente los pesos de los expertos seleccionados en un formato empaquetado de cuatro bits, conserva los datos usados recientemente en una cache LRU y carga secuencialmente las capas densas. El tamaño de la cache y la cantidad de capas que permanecen siempre en memoria pueden ajustarse a cada maquina.

Segun la tabla publicada, una configuracion con 8 GB de RAM genera un token en aproximadamente 26,5 segundos. Con 64 GB, el tiempo baja a 19,8 segundos; con 128 GB o mas, cae hasta 5,6 segundos porque la espera del disco casi desaparece. El autor afirma que, con la misma solicitud, el resultado sigue siendo identico byte por byte: cambia el tiempo, no los calculos.

Un ejemplo sencillo consiste en continuar la frase “The capital of France is”. En la configuracion minima, el motor genero ocho tokens en 261,5 segundos, con un consumo maximo de 8,24 GB. Es demasiado lento para un chat orientado al usuario, pero suficiente para demostrar que el enfoque funciona y explorar el modelo sin un rack de aceleradores.

Que se necesita en la practica

La principal barrera no es la RAM, sino el almacenamiento. El checkpoint, la parte densa empaquetada y los archivos auxiliares requieren unos 1,7 TB de espacio libre. Conviene utilizar una unidad NVMe local rapida: si los pesos no caben en memoria, el almacenamiento participa en la generacion de cada token. Con un SSD lento, el resultado tardara aun mas.

Para compilarlo se necesita un compilador C99, OpenMP y un procesador con AVX2/FMA en x86-64 o NEON en Arm. El repositorio es compatible con Linux, macOS y Windows. Es posible compilar el motor y ejecutar el conjunto de pruebas sin descargar el modelo de varios terabytes: compara las operaciones y los tokens generados con una implementacion de referencia sobre un modelo reducido que conserva el mismo esquema computacional.

No obstante, por ahora las cifras publicadas deben considerarse resultados del propio autor, no un benchmark independiente. El modo minimo demuestra la viabilidad tecnica, pero no es un servidor de inferencia listo para produccion. La primera version carece de herramientas, compatibilidad con imagenes, servidor API y compresion del historial de conversaciones. Incluso una estacion de trabajo potente sigue siendo considerablemente mas lenta que un servicio en la nube basado en GPU.

Por que un desarrollador deberia estudiar este codigo

El valor del proyecto no reside en la promesa de sustituir una GPU por ocho gigabytes de RAM. Muestra con codigo concreto cuatro tecnicas utiles: carga de capas en streaming, trabajo con pesos cuantizados sin desempaquetar todo el array, una cache limitada de expertos y presupuestos de memoria independientes para distintas partes del modelo.

Si esta desarrollando una herramienta local, una aplicacion para el edge o un prototipo sin conexion, estas soluciones pueden trasladarse a modelos de tamaño razonable para obtener una velocidad practica. Un equipo de producto debe comenzar por definir la latencia aceptable: si el usuario espera una respuesta en segundos, esta ejecucion de Kimi K3 no es adecuada. Si la tarea es un experimento por lotes, una auditoria de arquitectura o trabajar donde no existe ningun acelerador, el repositorio deja de ser un truco y se convierte en una util guia de ingenieria.