El problema fundamental que WASTE aborda es la brecha entre el tamaño de los modelos de lenguaje grandes (LLMs) de vanguardia, que superan el terabyte, y la capacidad de memoria RAM de los sistemas informáticos de consumo. Tradicionalmente, la inferencia de estos modelos requería infraestructuras de servidor con terabytes de DDR5 o acceso a APIs en la nube, lo que implicaba costos recurrentes, latencia de red y preocupaciones de privacidad. WASTE demuestra que es posible ejecutar modelos de escala trillonaria localmente en una máquina de consumo con 64 GB de RAM, al explotar una característica clave de las arquitecturas Mixture-of-Experts (MoE): solo una pequeña fracción de los parámetros del modelo (los 'experts') se activa por cada token generado. Esto transforma el desafío de 'caben en RAM' a 'son accesibles a tiempo desde disco'.
La relevancia de esta solución es que democratiza el acceso a la inferencia de modelos de frontera, eliminando la dependencia de la red y los costos por token. Al desplazar la carga de memoria a la velocidad de almacenamiento, WASTE cambia el paradigma de diseño de sistemas para LLMs, abriendo la puerta a aplicaciones de IA que operan completamente offline, con garantías de privacidad y sin facturas por uso. Este cambio es crucial para escenarios donde la sensibilidad de los datos o la intermitencia de la conectividad son factores limitantes.
Arquitectura del Sistema
WASTE es un motor de inferencia autocontenido escrito en C, sin dependencias de runtime de terceros más allá de libc y pthreads. Su arquitectura se centra en la gestión eficiente de la memoria y el almacenamiento para modelos MoE. El modelo se divide en un 'resident trunk' y múltiples 'expert banks'. El 'resident trunk' (aproximadamente 27 GB para Kimi K3) se carga completamente en RAM al inicio. Los 'expert banks', que constituyen la mayor parte del modelo (982 GiB para K3), se almacenan en disco en un formato optimizado.
Para cada token generado, el motor identifica los 'experts' necesarios (típicamente 16 por capa en 92 capas para K3, sumando 17 GB de datos). Estos 'experts' se transmiten directamente desde el disco NVMe utilizando operaciones de I/O directas (O_DIRECT en Linux, F_NOCACHE en macOS) para evitar el page cache del sistema operativo, que sería ineficaz para un modelo tan grande. La RAM restante se utiliza como un 'expert cache' de tamaño limitado (ej. 17.56 GB en una máquina de 64 GB). La lectura de expertos se superpone con las operaciones aritméticas (matmuls) en hilos separados para minimizar la latencia. Los expertos se almacenan usando Residual Vector Quantization (RVQ) para reducir su tamaño y se organizan en disco de manera que cada expert requiere exactamente una operación pread, optimizando el acceso aleatorio. El modelo también incorpora Kimi Delta Attention (KDA) para la atención, que utiliza un estado recurrente de tamaño fijo en lugar de un KV cache creciente, reduciendo drásticamente los requisitos de RAM para contextos largos (ej. 0.21 GB vs 11.25 GB para 4K contexto).
Flujo de Inferencia de Token con WASTE
- 1 Carga del Trunk El 'resident trunk' del modelo se carga completamente en RAM al inicio.
- 2 Generación de Token Para cada nuevo token, el modelo determina qué 'experts' son necesarios.
- 3 Consulta de Caché Se verifica si los 'experts' requeridos están en el 'expert cache' en RAM.
- 4 Lectura desde NVMe Si no están en caché, los 'experts' se leen directamente desde el disco NVMe ...
- 5 Procesamiento de Expertos Los datos de los expertos se procesan (RVQ, matmuls) superponiendo I/O y cómp...
- 6 Actualización de Caché Los 'experts' leídos se añaden al 'expert cache' (LFRU) si hay espacio.
- 7 Cálculo de Logits Se calculan los logits finales para el token.
- 8 Generación de Salida El token se decodifica y se añade a la secuencia de salida.
| Capa | Tecnología | Justificación |
|---|---|---|
| compute | C11 | Lenguaje de implementación principal para el motor de inferencia, elegido por su control de bajo nivel sobre la memoria y el hardware, y la ausencia de dependencias de runtime. vs Rust, C++ |
| storage | NVMe SSD | Almacenamiento primario para los 'expert banks' del modelo, crucial por su alto throughput (ej. 12.78 GB/s) para permitir el streaming de 17 GB de datos por token en un tiempo aceptable. vs SATA SSD, USB enclosure Uso de O_DIRECT (Linux) / F_NOCACHE (macOS) para bypass del page cache. |
| cache | Bounded LFRU Expert Cache | Gestión de una porción de RAM para almacenar 'experts' recientemente usados, mejorando la tasa de aciertos y reduciendo las lecturas de disco. El tamaño se ajusta dinámicamente para evitar paginación del SO. vs LRU, FIFO El motor selecciona el presupuesto de caché más grande que se ajusta a menos de 7/8 de la RAM física, en múltiplos del 'working set' de un token. |
| data-processing | Residual Vector Quantization (RVQ) | Formato de almacenamiento para los pesos de los 'experts', reduciendo el tamaño del modelo en disco y permitiendo la reconstrucción de matrices 'on-the-fly' con menos operaciones. vs Quantization a 4/8 bits, otros esquemas de compresión Tres etapas de codebooks de 256 entradas sobre vectores de 8 dimensiones, resultando en 3.00 bits por peso. |
| networking | OpenAI-compatible HTTP server | Proporciona una API estándar para interactuar con el motor de inferencia localmente, permitiendo la integración con aplicaciones existentes que esperan el formato de API de OpenAI. vs gRPC, API propietaria Implementado en Python usando ctypes para interactuar con la librería C, sin dependencias de runtime de Python para la inferencia. |
Trade-offs
Ganancias
- ▲▲ Accesibilidad de modelos de frontera
- ▲ Privacidad y seguridad de datos
- ▲▲ Costo operativo (sin facturas por token)
- ▲ Independencia de la red
Costes
- ▲ Velocidad de inferencia (tokens/segundo)
- ▲ Requisito de almacenamiento NVMe de alta velocidad
- ▲ Ventana estrecha de RAM utilizable para caché
waste_cfg cfg;
waste_cfg_init(&cfg);
cfg.ram_budget_bytes = 46ULL << 30; /* a hard ceiling, not a hint; 0 sizes it to this machine */
waste_ctx *ctx;
if (waste_open("/path/to/k3.waste", &cfg, &ctx) != WASTE_OK) return 1;
waste_generate(ctx, ids, n, ¶ms, on_token, user);
waste_close(ctx);# 1. preflight: reachable? how big? does it fit?
tools/fetch_weights.sh --dest /Volumes/staging/k3 --dry-run
# 2. download — resumable, safe to kill, safe to re-run
tools/fetch_weights.sh --dest /Volumes/staging/k3
# 3. convert into a container
uv run --with torch --with safetensors python tools/convert.py \
--src /Volumes/staging/k3 \
--out ~/models/k3.waste --jobs 3Fundamentos Teóricos
El concepto de Mixture-of-Experts (MoE) tiene sus raíces en la investigación de redes neuronales de la década de 1990, con trabajos seminales como el de Jacobs et al. (1991) y Jordan y Jacobs (1994) que exploraron la combinación de múltiples redes neuronales ('experts') con una red 'gating' para asignar entradas a los expertos más apropiados. Estos principios sentaron las bases para arquitecturas que pueden escalar el número de parámetros sin aumentar linealmente el costo computacional por inferencia.
La técnica de streaming de datos desde disco para modelos que no caben en memoria se relaciona con conceptos de gestión de memoria virtual y paginación, fundamentales en sistemas operativos desde los trabajos pioneros de Denning (1968) sobre el modelo de 'working set'. Sin embargo, WASTE implementa una gestión de caché de expertos explícita y un bypass del page cache del SO, lo que es una adaptación de estos principios a las características específicas de acceso a datos de los modelos MoE y la latencia de los dispositivos NVMe modernos. La optimización del layout en disco para 'one read per expert' es una aplicación directa de principios de diseño de sistemas de archivos y bases de datos para minimizar seeks y maximizar el throughput secuencial.