2.78 trillones de parámetros en 8GB de RAM: la comunidad logró lo que ningún lab corporativo haría (Kimi K3 in C)

El 1 de agosto de 2026, un desarrollador llamado Fareed Khan publicó un repositorio en GitHub con una afirmación que habría sonado a locura hace solo un año: su motor de inferencia corre Kimi K3 — el modelo de 2.78 trillones de parámetros de Moonshot AI — en una sola CPU con 8.24 GB de RAM.

Sin GPU. Sin BLAS. Sin PyTorch. Sin TensorFlow. Sin framework de ningún tipo. Un binario de 176 KB escrito en C99 puro, con solo dos dependencias del sistema (libm y OpenMP), ejecutando el checkpoint original de 1.56 terabytes sin modificar, sin cuantizar a la baja, sin destilar, sin quitar capas.

Cuatro días después ya estaba en el trending de GitHub con miles de estrellas. Y si esto te parece solo una curiosidad de ingeniería, te equivocas: es la demostración más clara de algo que venimos sosteniendo desde mayo — la comunidad open source está haciendo lo que ningún lab corporativo haría jamás, y eso redefine lo que significa la soberanía tecnológica.

Vamos a desarmar cómo funciona esta hazaña técnica, por qué es posible, por qué importa, y qué significa para ti — ya sea que corras una PYME, desarrolles software o simplemente quieras entender hacia dónde va la IA.

1. El problema que nadie quería resolver: no puedes correr lo que no puedes cargar

Cuando Moonshot AI publicó los open weights de Kimi K3 el 26 de julio de 2026 en HuggingFace, la reacción de la comunidad fue unánime: "¿y ahora quién puede correr esto?"

El checkpoint ocupa 1.56 terabytes repartidos en 96 shards de safetensors (o ~594 GB en la versión nativa MXFP4). Para cargarlo en memoria en bfloat16 necesitas 5.56 terabytes de RAM. Ninguna máquina de consumo puede con eso — y este es el punto clave que el proyecto martilla una y otra vez: esperar una máquina más rápida no ayuda, porque la pared no es de cómputo, es de capacidad. No puedes ejecutar lo que no puedes cargar.

Los grandes labs resuelven este problema de la única forma que les conviene: te venden acceso a sus GPUs. Ejecutas el modelo en sus data centers, pagas por token, y listo. La optimización para correr en hardware que tú puedas pagar no está en su hoja de ruta — porque si pudieras correr un modelo de frontera en tu propia máquina, ¿para qué los necesitarías?

2. La hazaña: cómo un motor de 176 KB corre 2.78T parámetros

El proyecto kimi-k3-in-c no hace magia. Hace algo mucho más interesante: explota la estructura interna del modelo que el propio fabricante ya diseñó.

Kimi K3 es un modelo Mixture-of-Experts (MoE). Eso significa que, aunque tiene 2.78 trillones de parámetros totales, solo una fracción se activa por cada token procesado. En concreto:

• 896 expertos en total por capa, pero solo 16 se activan para cada token.
• Eso significa que el 93% del checkpoint (1.447 TB de expertos enrutados) nunca necesita estar residente en memoria.
• Los expertos inactivos se leen bajo demanda desde el disco NVMe cuando el router los necesita.

El motor hace tres cosas brillantes:

a) Convierte la memoria en un dial, no en un piso

El mismo modelo corre en 8 GB, 128 GB o 224 GB de RAM. La diferencia no es si funciona — es qué tan rápido. Más RAM solo cambia el reloj, nunca la respuesta: el output es byte-idéntico en cualquier presupuesto de memoria. Ese es el detalle que separa a un ingeniero de un charlatán.

b) Streams de expertos desde NVMe con precisión quirúrgica

Los 1.447 TB de expertos enrutados se leen del disco solo cuando se necesitan, con O_DIRECT para saltarse la caché del kernel y gestionar el buffer manualmente con posix_memalign. Es ingeniería de bajo nivel que ningún framework te da gratis.

c) MXFP4 nativo sin frameworks

Kimi K3 ya viene en formato MXFP4 (4-bit) desde HuggingFace. El motor aprovecha esa cuantización nativa en vez de descargar pesos en fp16 y luego re-cuantizar — una eficiencia que reduce drásticamente tanto la memoria como la transferencia de datos.

La demo del README lo dice todo:

La confesión honesta del propio autor: a 0.03 tokens por segundo, esto no es un daily driver. Es una prueba de ingeniería — pero una que cambia el marco de lo posible. Si en 8 GB funciona (lento pero funciona), imagina lo que se puede hacer con 64 GB o 128 GB de RAM, que ya son máquinas de escritorio razonables en 2026.

3. Por qué ningún lab corporativo haría esto (y por qué importa)

Aquí está la pregunta incómoda: ¿por qué tuvieron que ser Fareed Khan y la comunidad open source quienes demostraran que Kimi K3 puede correr sin GPU — y no los propios ingenieros de Moonshot AI, Anthropic u OpenAI?

La respuesta es de incentivos, no de capacidad:

• Anthropic vende Claude por API. Que corras el modelo en tu máquina no le genera un centavo — al contrario, le quita demanda de sus GPUs.
• OpenAI tiene un producto cerrado. La optimización para hardware local simplemente no existe en su modelo de negocio.
• Moonshot AI liberó los pesos (bien por ellos) pero su foco sigue siendo su propia infraestructura de inferencia.
• NVIDIA literalmente vende los martillos. Su interés es que compres más GPUs, no que aprendas a prescindir de ellas.

En cambio, la comunidad open source tiene un incentivo completamente distinto: la gente que construye estos proyectos quiere poder usar estas tecnologías en sus propios términos, en su propio hardware, sin pedir permiso. Esa es la cultura del software libre desde sus orígenes — y es exactamente la misma cultura que produjo Linux, PostgreSQL, Odoo, Kubernetes y todos los cimientos sobre los que corre internet.

4. Qué significa esto para LATAM (tu soberanía tecnológica real)

En LATAM no tenemos el lujo de ignorar los costos de hardware. El acceso a GPUs de gama alta está concentrado en unas pocas regiones del mundo, el dólar golpea cada compra, y la dependencia de APIs extranjeras nos deja expuestos a subidas de precios (como la de DeepSeek el 6 de agosto), a regulaciones ajenas y a decisiones que no controlamos.

Proyectos como kimi-k3-in-c atacan directamente esa vulnerabilidad:

1. Bajan el piso de entrada. Si un modelo de frontera de 2.78T puede correr — aunque sea lento — en una máquina de 8 GB, entonces la frontera de la IA ya no es exclusiva de quien tiene un cluster. Es cuestión de tiempo y optimización.
2. Demuestran que el conocimiento es reproducible. El código es Apache-2.0, abierto, documentado. Un estudiante en Santiago puede estudiar cómo se hace y replicarlo. Eso es transferencia de conocimiento real, no marketing.
3. Crean la economía del hardware que ya tienes. En vez de comprar GPUs de US$30.000, el futuro cercano es: comprar RAM. Y la RAM es barata, reutilizable y no se exporta.
4. Te desacoplan del proveedor. Tener los pesos en tu disco y un motor abierto para ejecutarlos es el último escalón de la soberanía: ni siquiera necesitas una API.

5. Los límites honestos (no todo es color de rosa)

Sería irresponsable de nuestra parte venderte esta historia sin sus límites. Seamos claros:

• 0.03 tokens/s no es usable para producción. Es una prueba de concepto, no un reemplazo de API. Para uso real necesitas 64 GB+ de RAM, y aun así estarás muy por debajo de la latencia de un data center.
• El cuello de botella es el NVMe. Con 1.4 TB de pesos que se leen bajo demanda, el rendimiento está limitado por el ancho de banda del disco. Un NVMe gen 4/5 es prácticamente obligatorio.
• Es Linux x86-64 only. Nada de macOS ni ARM por ahora (aunque el C99 puro sugiere que eventualmente podría portarse).
• El valor real es el demostrativo, no el productivo. Lo que este proyecto demuestra es que el techo está en nuestra imaginación colectiva, no en el hardware. Y eso, paradójicamente, es lo más valioso.

Pero aquí está el punto que nadie puede refutar: hace un año, correr un modelo de 2.78T en una CPU con 8 GB era "imposible". Ahora es lento pero posible. En un año, con la comunidad iterando sobre esto — mejor caching, mejor scheduling de expertos, quantización más fina — será tolerable. En dos años, será normal. Ese es el ritmo al que avanza la optimización comunitaria: exponencial, abierta y gratuita.

6. La conclusión: la soberanía también se construye con ingeniería, no solo con ideología

Llevamos meses escribiendo sobre soberanía de datos, soberanía digital y el costo real del vendor lock-in. Hoy queremos cerrar con la pieza que faltaba: la soberanía tecnológica no se decreta — se construye. Y se construye con proyectos como kimi-k3-in-c, que le bajan el piso a la frontera, que demuestran que el conocimiento es reproducible y que el hardware que ya tienes vale más de lo que crees.

Mientras los labs corporativos discuten sobre alineación, ética y policy papers, la comunidad está escribiendo código que literalmente cambia quién puede participar en esta tecnología. Eso no es ideología: es ingeniería. Y la ingeniería, a diferencia de los discursos, no miente.

La buena noticia para LATAM: no necesitamos pedir permiso para participar. Los pesos están abiertos, los motores son Apache-2.0, y la comunidad demuestra semana a semana que el hardware limitado no es una barrera — es una oportunidad para innovar. En un continente donde el dólar y la distancia deciden quién accede a la tecnología, ese tipo de innovación no es un lujo. Es la diferencia entre ser consumidor de IA o ser dueño de IA.