Ejecuta Kimi K3 de 2.78T en un MacBook de 64 GB: El motor de transmisión NVMe de WASTE
Descubre WASTE, un motor de inferencia en C sin dependencias que transmite los pesos de los expertos desde NVMe para ejecutar el modelo completo de 2.78 billones de parámetros Kimi K3 en hardware de consumo a 0.6 tokens/s.
Imagina ejecutar un modelo de 2.78 billones de parámetros en una laptop. No una versión destilada, no una aproximación cuantizada, sino el Kimi K3 completo y original — los mismos pesos que alimentan uno de los modelos abiertos más grandes que existen. Eso es exactamente lo que logra WASTE (Weight-Aware Streaming Tensor Engine), y lo hace con una combinación inteligente de arquitectura de mezcla de expertos (MoE), cuantización agresiva y un profundo entendimiento de cómo el almacenamiento NVMe moderno puede actuar como una extensión lenta pero vasta de la RAM.
WASTE es un motor de inferencia incrustable escrito en C con cero dependencias de tiempo de ejecución de terceros. Mantiene el tronco compartido del modelo en memoria, transmite solo los pesos de los expertos activados directamente desde el disco, y usa la RAM restante como un caché limitado. ¿El resultado? El Kimi K3 completo de 2.78T se ejecuta en un MacBook Pro de 64 GB a aproximadamente 0.6 tokens por segundo. Eso es lento para los estándares de la nube, pero es un paso monumental para la IA local — y el objetivo final del proyecto es que Kimi K3 se mejore a sí mismo, ejecutándose completamente en tu escritorio.
Por qué esto importa: El problema del desperdicio de tokens
El nombre del proyecto no es solo un acrónimo ingenioso. Cada token que generas a través de una API en la nube se paga dos veces: una en tu factura, y otra en la electricidad de un centro de datos que ejecuta un modelo que podría — apenas, torpemente, pero genuinamente — caber en el hardware que ya posees. WASTE busca terminar con ese desperdicio demostrando que los modelos de escala fronteriza pueden ejecutarse localmente, aunque sea lentamente. Es una postura filosófica tanto como técnica.
Cómo funciona WASTE: Transmisión de expertos desde NVMe
Kimi K3 es un modelo de mezcla de expertos con 2.78 billones de parámetros, pero solo alrededor del 4% de esos están activos para cualquier token dado. WASTE explota esta escasez de una manera radical:
- Tronco residente: Las capas compartidas (no expertas) permanecen en RAM. Para K3, eso es aproximadamente 27.28 GB.
- Expertos transmitidos: El formato del contenedor está organizado para que cada experto requiera exactamente una lectura alineada del disco. Cuando el enrutador selecciona un experto, WASTE lo lee directamente desde NVMe.
- Caché de expertos limitado: La RAM no utilizada se convierte en un caché para los expertos recientemente usados, evitando lecturas repetidas del disco.
- Enrutador de anticipación: Un enrutador predictivo anticipa qué expertos necesitará la siguiente capa y comienza a leerlos temprano. El enrutador real aún toma la decisión final, por lo que esto solo cambia el tiempo, no los resultados.
- Cuantización agresiva: Los expertos usan cuantización vectorial residual de 3 bits, mientras que los pesos compartidos más sensibles permanecen en 4 u 8 bits.
Este diseño reduce drásticamente la huella de memoria. El contenedor K3 completo es de 982 GB, pero WASTE solo necesita 29.06 GB de RAM para abrirlo. El resto de tu memoria (hasta un presupuesto configurable) se usa para el caché de expertos.
Números de rendimiento: Qué esperar
En un MacBook Pro de 64 GB con un M5 Pro y SSD interno, esto es lo que WASTE entrega:
| Modelo | Tamaño del contenedor | RAM mínima | Velocidad de decodificación |
|---|---|---|---|
| Kimi K3 2.78T | 982 GB | 29.06 GB | 0.45–0.62 tok/s |
| Kimi-Linear 48B | 19 GB | 1.28 GB | 10.65 tok/s |
Para K3, 64 GB es el mínimo práctico. Una máquina de 32 GB puede técnicamente abrir el modelo pero paginará mucho, haciéndolo inutilizable. El presupuesto de memoria predeterminado en la máquina de prueba es de 46.25 GB, incluyendo un caché de expertos de 17.56 GB.
El equilibrio del tamaño del caché
El rendimiento de WASTE es muy sensible al tamaño del caché de expertos. El equipo midió cuatro configuraciones en un solo proceso:
| Caché de expertos | Tasa de aciertos | Velocidad de decodificación |
|---|---|---|
| 3.32 GB | 29.1% | 0.56–0.58 tok/s |
| 17.32 GB | 36.2% | 0.63 tok/s |
| 23.32 GB | 38.4% | 0.07–0.09 tok/s |
| 29.32 GB | 41.3% | 0.07–0.08 tok/s |
Las últimas dos filas son una lección crítica: darle más memoria al proceso no siempre lo hace más rápido. Cuando el caché excede lo que el sistema operativo puede acomodar cómodamente en RAM, los aciertos de caché se convierten en fallos de página, y el rendimiento colapsa ocho veces. El motor está dentro de su presupuesto, pero la máquina no lo está.
El almacenamiento es el verdadero cuello de botella
Un token K3 en frío lee aproximadamente 17 GB de expertos. El SSD interno sostiene 12.78 GB/s, pero un gabinete USB probado solo logró 0.94 GB/s — una diferencia de 13x. Siempre coloca el contenedor en almacenamiento NVMe interno.
Comenzando: De cero a ejecutar K3
Construye el motor
git clone https://github.com/sqliteai/waste
cd waste
make
make check
make construye el CLI waste y libwaste.a. make check ejecuta una suite de pruebas sin modelo que crea un modelo sintético pequeño, por lo que no se descargan pesos.
Obtén el contenedor convertido (la ruta más rápida)
La forma más fácil de obtener K3 es descargar el contenedor preconvertido a través de BitTorrent. Esto omite la descarga de la fuente de 1.42 TB y el proceso de conversión de 4.7 horas. Los hashes de las piezas del torrent verifican el contenedor a medida que llega.
aria2c --dir ~/models --seed-time=60 \
'magnet:?xt=urn:btih:abe7123a60b2b1171c1c4dcaa381b93c46806afe&dn=k3.waste&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.demonii.com%3A1337%2Fannounce'
Apunta --dir al almacenamiento NVMe interno — un contenedor en un disco externo será demasiado lento para usar.
Convertir desde pesos publicados (si prefieres)
Si prefieres no confiar en una copia de terceros, o ya tienes los pesos originales, puedes convertirlos tú mismo. El proceso es reanudable:
# Verifica el espacio de descarga requerido
tools/fetch_weights.sh --dest /Volumes/staging/k3 --dry-run
# Descarga los pesos originales
tools/fetch_weights.sh --dest /Volumes/staging/k3
# Conviértelos (salida en SSD interno)
uv run --with torch --with safetensors python tools/convert.py \
--src /Volumes/staging/k3 \
--out ~/models/k3.waste \
--jobs 3
La conversión toma alrededor de 4.7 horas con tres trabajadores en la máquina de prueba. Necesitarás 1.42 TB de almacenamiento temporal de preparación, que puede ser externo y liberarse después.
Ejecútalo
./waste plan ~/models/k3.waste
./waste run ~/models/k3.waste "La capital de Francia es" -n 32
./waste chat ~/models/k3.waste
No establezcas --budget a menos que tengas una razón. Por defecto, WASTE elige un presupuesto de memoria seguro y se niega a comenzar por debajo del mínimo del modelo. Dentro de un contenedor, se dimensiona contra el límite de cgroup en lugar de la RAM del host.
Multimodal y servidor
Kimi K3 es multimodal, y WASTE admite imágenes:
./waste run ~/models/k3.waste "Describe esta imagen" --image photo.jpg
./waste run ~/models/k3.waste "Compara estas imágenes" --image before.png --image after.png
En modo interactivo, /image FILE adjunta una imagen al siguiente mensaje. Una imagen de 896×896 usa 256 posiciones de prompt, y cada posición cuesta alrededor de 2.8 segundos de tiempo del modelo de lenguaje.
WASTE también incluye un servidor opcional compatible con OpenAI:
make libwaste.dylib # usa libwaste.so en Linux
python3 -m serve ~/models/k3.waste --port 8000
curl localhost:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model":"k3","messages":[{"role":"user","content":"¿Por qué el cielo es azul?"}]}'
Admite transmisión, herramientas, salida estructurada, controles de pensamiento e imágenes.
La biblioteca y la validación
WASTE también es una biblioteca C incrustable. El CLI y el servidor usan la API pública en src/waste.h. La ruta de inferencia depende solo de libc y pthreads — sin BLAS, Python, CUDA u otras dependencias externas.
La validación es rigurosa. Todas las capas se verifican contra una referencia de PyTorch; los logits finales concuerdan dentro de 3.6e-06, y la torre de visión concuerda con su oráculo dentro de 2.3e-06. La suite sin modelo construye un contenedor sintético, y las verificaciones de modelos reales confirman los viajes de ida y vuelta de conversión y el renderizado de prompts del servidor.
Estado del proyecto y filosofía
El formato y la API no están congelados. K3 es el objetivo principal y el modelo mejor probado. La ruta de CPU es actualmente la implementación medida más rápida, pero CUDA, Metal y otras optimizaciones específicas de hardware quedan por explorar. El proyecto mantiene un archivo docs/LEARNED.md para ideas fallidas y resultados negativos — una práctica rara y valiosa.
Las mediciones se tratan como resultados experimentales, no como números de marketing. Cada una está vinculada al hardware, contenedor, configuración y commit en el que se obtuvo. Las mediciones inestables se informan como rangos, y los resultados que luego se descubren incorrectos permanecen registrados como tales.
Reflexiones finales
WASTE es un experimento audaz que desafía la suposición de que los modelos fronterizos requieren infraestructura a escala de centro de datos. Al transmitir pesos desde NVMe y usar la escasez de MoE a su favor, trae un modelo de 2.78T a una laptop. Es lento, pero funciona — y es de código abierto bajo Apache 2.0.
Si eres un desarrollador interesado en empujar los límites de la IA local, WASTE vale la pena. Comienza con Kimi-Linear (contenedor de 19 GB, 10.7 tok/s) para familiarizarte con el motor, luego considera la experiencia completa de K3. El proyecto da la bienvenida a contribuyentes, especialmente para nuevos backends de hardware y experimentos de rendimiento — incluso los resultados negativos son valorados.
Consulta el repositorio de GitHub para la documentación completa, incluido el formato del contenedor, comparaciones de backends y direcciones de investigación.