Kimi K3 (2,8T) a 1 token/s en un MacBook Pro, transmitido desde cuatro SSDs
Un desarrollador ha conseguido ejecutar Kimi K3, un modelo Mixture-of-Experts de 2,8 billones de parámetros, en un MacBook Pro transmitiendo unos 1,45 TB de pesos de expertos desde cuatro SSDs, logrando aproximadamente 1 token por segundo pero con una demora de 6 minutos antes del primer token en un prompt de 512 tokens. El proyecto profundiza en cómo el ancho de banda del disco, la planificación de lecturas y las limitaciones de Thunderbolt afectan el rendimiento, documentando qué optimizaciones ayudaron y cuáles perjudicaron (por ejemplo, el striping RAID-0 y la caché en RAM). Los comentaristas debaten el valor práctico de una configuración tan lenta y limitada por almacenamiento frente a su importancia como prueba de concepto para ejecutar modelos a escala de frontera de forma local y totalmente offline.
Modelo y rendimiento
- MoE de 2,78T de parámetros (Kimi K3) con ~1,45 TB de pesos de expertos, ejecutado en un MacBook Pro M5 Max (128 GB) con 4 SSDs.
- Los expertos se transmiten desde el disco; el “tronco” de atención (~50 GB) permanece residente en memoria unificada con precisión int8.
- Decodificación reportada: ~1 token/s sobre 512 tokens, ~1,13 tok/s sobre 128 tokens, con comportamiento consistente entre pruebas.
- El tiempo hasta el primer token en un prompt de 512 tokens es de ~6,3 minutos debido a la intensa E/S de prefill.
Arquitectura de E/S y escalado
- Un archivo de 17,5 MB por (capa, experto); cada capa lee 16 expertos por token y debe esperar a la lectura más lenta.
- Cuatro SSDs mediante cajas Thunderbolt 5; un SSD interno solo ofrece aproximadamente la mitad de la tasa de decodificación de 4 unidades.
- “Escalera” empírica de unidades: 1/2/3/4 unidades ≈ 52% / 73–78% / 90–92% / 100% de la velocidad de 4 unidades; los rendimientos decrecen con más unidades.
- Se midieron RAID0/striping y algunas estrategias de caché y se encontró que perjudican el rendimiento, principalmente porque las barreras las marca el dispositivo más lento.
Prefill, contexto y ajuste a la carga
- El prefill es el principal cuello de botella: la planificación actual vuelve a leer los expertos varias veces, causando ~9 TB de lecturas para un modelo de 1,4 TB.
- Esto hace que las cargas de trabajo de “clasificador de un solo token” (prompt largo, 1 token de salida) sean actualmente el peor caso, no el mejor.
- La caché KV crece ~2,8 MiB por token; con 128 GB de RAM y otras reservas, el contexto queda limitado a alrededor de 4,4k tokens en esta configuración.
- Un prefill propuesto “expert-major” (leer cada experto una vez por capa, procesar todas las filas enrutadas) podría reducir la amplificación de 6,2x hacia ~1x.
Casos de uso y debate de “¿para qué molestarse?”
- Los escépticos sostienen que 1 tok/s con un prefill de varios minutos es impráctico y caro para uso interactivo.
- Los defensores ven valor en:
- Trabajos locales programados y desatendidos (informes, conciliaciones) donde la latencia no importa.
- Prueba de concepto de que modelos de frontera pueden ejecutarse localmente en absoluto.
- Experimentación hacker de “porque es difícil” y un paso hacia diseños más eficientes.
Herramientas, metodología y documentación
- La instrumentación personalizada (monitor de lectura por dispositivo, trazado de barreras, aserciones de configuración) reveló cuellos de botella no obvios; varias mejoras de >8–14% provinieron de corregirlos.
- Se ofrece un amplio catálogo de resultados negativos (caché, striping, streaming del tronco, varias APIs) como datos de advertencia.
- Algunos comentaristas encuentran el README denso y “LLM-ish”, prefiriendo el TL;DR corto; se señala el resentimiento hacia la documentación larga escrita por LLM.
Futuros del hardware e ideas de diseño del modelo
- La discusión toca los límites de ancho de banda de SSD (Thunderbolt/PCIe), posibles configuraciones de escritorio o basadas en GPU, y chips de inferencia tipo ASIC.
- Se debate si los modelos futuros deberían ser más modulares o más “pegajosos” en su enrutamiento de expertos, de modo que solo un pequeño subconjunto de pesos necesite residir en memoria; los enfoques MoE actuales se ven principalmente como ahorro de cómputo, no de memoria.