Por qué una GPU sigue siendo indispensable, incluso cuando una CPU ejecuta 2,8 billones de parámetros
TL;DR
kimi-k3-in-c ejecuta un modelo de 2,8 billones de parámetros (2 800 millardos) en una CPU con 8 GB de RAM. El precio: entre 10 y 32 segundos para producir una sola palabra. No es un defecto que una próxima versión vaya a corregir, es la consecuencia directa de leer un modelo desde un disco en lugar de desde una memoria pensada para eso. Una GPU sigue siendo, y seguirá siendo, la única manera de hacer este cálculo a una velocidad utilizable. La democratización que demuestra este proyecto tiene un límite duro, y es un límite de hardware.
Lo que demuestra la hazaña
kimi-k3-in-c carga un modelo de 1,56 TB en una máquina con 8 GB de RAM manteniendo en memoria únicamente lo que sirve en ese instante: un tronco denso compacto y los 16 expertos de 896 que el enrutador acaba de designar. El resto espera en el disco. Es una prueba de viabilidad sólida, probada y documentada. No es una prueba de que la GPU se haya vuelto accesoria.
La cifra que rompe el sueño
32,7 segundos por palabra con 8 GB de RAM. 10,7 segundos por palabra con 128 GB. Para escribir una respuesta de 100 palabras, hay que contar entre 18 minutos y una hora de cálculo. Una GPU produce la misma respuesta en unos pocos segundos.
Ningún ajuste cierra esa brecha. Multiplicar la RAM asignada por dieciséis, de 8 a 128 GB, solo gana un factor tres en velocidad. El rendimiento decrece rápido, porque la RAM no ataca la verdadera causa de la lentitud.
Por qué es estructural, no un defecto de optimización
El tiempo de generación lo domina la lectura del disco, no el cálculo. Un SSD NVMe lee alrededor de 7 gigabytes por segundo. Una tarjeta gráfica de gama alta lee su propia memoria, la VRAM, a más de 3 000 gigabytes por segundo, el equivalente a un factor 400.
Una GPU no solo acelera las multiplicaciones, las hace en paralelo sobre miles de núcleos, con los datos ya al alcance del cálculo en una memoria diseñada para eso. Una CPU que hace streaming de sus pesos desde un disco, por bien escrito que esté el código, sigue sometida a la velocidad de ese disco. No es un problema que un código más listo resuelva, es una diferencia de hardware que el código solo rodea lo mejor que puede.
Lo que una GPU hace y este hack no puede hacer
Una GPU mantiene el modelo entero, o lo esencial de sus pesos activos, en una memoria tan rápida como sus unidades de cálculo. Procesa varias peticiones en paralelo sin perder latencia por petición. Alimenta un chatbot, una API en producción, un agente que encadena decenas de llamadas por tarea: usos donde la respuesta debe llegar en segundos, no en decenas de minutos.
kimi-k3-in-c no apunta a ninguno de esos usos, y el repositorio no lo pretende. El nombre del preajuste más lento, laptop, describe una demostración, no un puesto de trabajo.
Dónde tiene sentido este enfoque
Hacer streaming de un modelo desde el disco sirve cuando la latencia no es el problema a resolver: verificar que un modelo open source responde correctamente sin alquilar un clúster, auditar un checkpoint en un entorno aislado sin conexión de red, o simplemente entender la arquitectura de un motor de inferencia leyéndola en lugar de importarla como una caja negra. Esos usos existen, y kimi-k3-in-c los cubre bien.
Un límite de hardware, no de software
El disco más rápido siempre será más lento que la memoria de una GPU, porque no está diseñado para la misma tarea. Ninguna capa de software, por ingeniosa que sea, cierra una brecha de factor 400 en ancho de banda. kimi-k3-in-c democratiza el acceso a los pesos de un modelo, a su lectura, a su comprensión. No democratiza su velocidad, y nada en su arquitectura pretende hacerlo. Para producir una respuesta en unos segundos, siempre hará falta una GPU.