Exécuter Kimi K3 2,78 T sur un MacBook 64 Go : le moteur de streaming NVMe de WASTE
Découvrez WASTE, un moteur d'inférence en C sans dépendances qui diffuse les poids des experts depuis le NVMe pour exécuter le modèle complet Kimi K3 de 2,78 billions de paramètres sur du matériel grand public à 0,6 tok/s.
Imaginez exécuter un modèle de 2,78 billions de paramètres sur un ordinateur portable. Pas une version distillée, pas une approximation quantifiée, mais le vrai Kimi K3 original — les mêmes poids qui alimentent l'un des plus grands modèles ouverts existants. C'est exactement ce que WASTE (Weight-Aware Streaming Tensor Engine) accomplit, et il le fait grâce à une combinaison astucieuse d'architecture mixture-of-experts (MoE), de quantification agressive et d'une compréhension approfondie de la façon dont le stockage NVMe moderne peut agir comme une extension lente mais vaste de la RAM.
WASTE est un moteur d'inférence embarquable écrit en C avec zéro dépendance runtime tierce. Il conserve le tronc commun du modèle en mémoire, diffuse uniquement les poids des experts activés directement depuis le disque, et utilise la RAM restante comme cache borné. Le résultat ? Le modèle complet Kimi K3 de 2,78 T de paramètres fonctionne sur un MacBook Pro 64 Go à environ 0,6 token par seconde. C'est lent selon les normes du cloud, mais c'est une étape monumentale pour l'IA locale — et l'objectif ultime du projet est que Kimi K3 s'améliore lui-même, fonctionnant entièrement sur votre bureau.
Pourquoi c'est important : le problème du gaspillage de tokens
Le nom du projet n'est pas seulement un acronyme intelligent. Chaque token que vous générez via une API cloud est payé deux fois : une fois dans votre facture, et une fois dans l'électricité d'un datacenter qui exécute un modèle qui pourrait — à peine, maladroitement, mais réellement — tenir sur du matériel que vous possédez déjà. WASTE vise à mettre fin à ce gaspillage en prouvant que les modèles à l'échelle frontière peuvent fonctionner localement, même si c'est lent. C'est une position philosophique autant que technique.
Comment fonctionne WASTE : diffusion des experts depuis le NVMe
Kimi K3 est un modèle mixture-of-experts avec 2,78 billions de paramètres, mais seulement environ 4 % de ceux-ci sont actifs pour un token donné. WASTE exploite cette parcimonie de manière radicale :
- Tronc résident : Les couches partagées (non-experts) restent en RAM. Pour K3, cela représente environ 27,28 Go.
- Experts diffusés : Le format de conteneur est arrangé pour que chaque expert nécessite exactement une lecture alignée depuis le disque. Lorsque le routeur sélectionne un expert, WASTE le lit directement depuis le NVMe.
- Cache d'experts borné : La RAM inutilisée devient un cache pour les experts récemment utilisés, évitant des lectures disque répétées.
- Routeur anticipatif : Un routeur prédictif anticipe quels experts la prochaine couche aura besoin et commence à les lire tôt. Le vrai routeur prend toujours la décision finale, donc cela ne change que le timing, pas les résultats.
- Quantification agressive : Les experts utilisent une quantification vectorielle résiduelle à 3 bits, tandis que les poids partagés plus sensibles restent à 4 ou 8 bits.
Cette conception réduit considérablement l'empreinte mémoire. Le conteneur K3 complet fait 982 Go, mais WASTE n'a besoin que de 29,06 Go de RAM pour l'ouvrir. Le reste de votre mémoire (jusqu'à un budget configurable) est utilisé pour le cache d'experts.
Chiffres de performance : à quoi s'attendre
Sur un MacBook Pro 64 Go avec un M5 Pro et un SSD interne, voici ce que WASTE offre :
| Modèle | Taille du conteneur | RAM minimale | Vitesse de décodage |
|---|---|---|---|
| Kimi K3 2,78 T | 982 Go | 29,06 Go | 0,45–0,62 tok/s |
| Kimi-Linear 48B | 19 Go | 1,28 Go | 10,65 tok/s |
Pour K3, 64 Go est le minimum pratique. Une machine de 32 Go peut techniquement ouvrir le modèle mais paginera fortement, le rendant inutilisable. Le budget mémoire par défaut sur la machine de test est de 46,25 Go, y compris un cache d'experts de 17,56 Go.
Le compromis sur la taille du cache
La performance de WASTE est très sensible à la taille du cache d'experts. L'équipe a mesuré quatre configurations dans un seul processus :
| Cache d'experts | Taux de succès | Vitesse de décodage |
|---|---|---|
| 3,32 Go | 29,1 % | 0,56–0,58 tok/s |
| 17,32 Go | 36,2 % | 0,63 tok/s |
| 23,32 Go | 38,4 % | 0,07–0,09 tok/s |
| 29,32 Go | 41,3 % | 0,07–0,08 tok/s |
Les deux dernières lignes sont une leçon cruciale : donner plus de mémoire au processus ne le rend pas toujours plus rapide. Lorsque le cache dépasse ce que le système d'exploitation peut confortablement contenir en RAM, les succès de cache deviennent des défauts de page, et le débit s'effondre huit fois. Le moteur est dans son budget, mais la machine ne l'est pas.
Le stockage est le vrai goulot d'étranglement
Un token K3 à froid lit environ 17 Go d'experts. Le SSD interne soutient 12,78 Go/s, mais un boîtier USB testé n'a atteint que 0,94 Go/s — une différence de 13x. Placez toujours le conteneur sur le stockage NVMe interne.
Pour commencer : de zéro à l'exécution de K3
Construire le moteur
git clone https://github.com/sqliteai/waste
cd waste
make
make check
make construit le CLI waste et libwaste.a. make check exécute une suite de tests sans modèle qui crée un petit modèle synthétique, donc aucun poids n'est téléchargé.
Obtenir le conteneur converti (le plus rapide)
Le moyen le plus simple d'obtenir K3 est de télécharger le conteneur pré-converti via BitTorrent. Cela évite le téléchargement de la source de 1,42 To et le processus de conversion de 4,7 heures. Les hachages de pièces du torrent vérifient le conteneur à son arrivée.
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'
Pointez --dir vers le stockage NVMe interne — un conteneur sur un disque externe sera trop lent pour être utilisé.
Convertir à partir des poids publiés (si vous préférez)
Si vous préférez ne pas faire confiance à une copie tierce, ou si vous avez déjà les poids originaux, vous pouvez les convertir vous-même. Le processus est reprenable :
# Vérifier l'espace de téléchargement requis
tools/fetch_weights.sh --dest /Volumes/staging/k3 --dry-run
# Télécharger les poids originaux
tools/fetch_weights.sh --dest /Volumes/staging/k3
# Les convertir (sortie sur SSD interne)
uv run --with torch --with safetensors python tools/convert.py \
--src /Volumes/staging/k3 \
--out ~/models/k3.waste \
--jobs 3
La conversion prend environ 4,7 heures avec trois travailleurs sur la machine de test. Vous aurez besoin de 1,42 To de stockage de staging temporaire, qui peut être externe et libéré ensuite.
L'exécuter
./waste plan ~/models/k3.waste
./waste run ~/models/k3.waste "La capitale de la France est" -n 32
./waste chat ~/models/k3.waste
Ne définissez pas --budget sauf si vous avez une raison. Par défaut, WASTE choisit un budget mémoire sûr et refuse de démarrer en dessous du plancher du modèle. Dans un conteneur, il dimensionne par rapport à la limite cgroup plutôt qu'à la RAM de l'hôte.
Multimodal et serveur
Kimi K3 est multimodal, et WASTE prend en charge les images :
./waste run ~/models/k3.waste "Décrivez cette image" --image photo.jpg
./waste run ~/models/k3.waste "Comparez ces images" --image avant.png --image après.png
En mode interactif, /image FICHIER attache une image au message suivant. Une image 896×896 utilise 256 positions de prompt, et chaque position coûte environ 2,8 secondes de temps de modèle de langage.
WASTE inclut également un serveur optionnel compatible OpenAI :
make libwaste.dylib # utilisez libwaste.so sur 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":"Pourquoi le ciel est-il bleu ?"}]}'
Il prend en charge le streaming, les outils, la sortie structurée, les contrôles de réflexion et les images.
La bibliothèque et la validation
WASTE est également une bibliothèque C embarquable. Le CLI et le serveur utilisent tous deux l'API publique dans src/waste.h. Le chemin d'inférence ne dépend que de libc et pthreads — pas de BLAS, Python, CUDA ou autres dépendances externes.
La validation est rigoureuse. Toutes les couches sont vérifiées par rapport à une référence PyTorch ; les logits finaux concordent à 3,6e-06 près, et la tour de vision concorde avec son oracle à 2,3e-06 près. La suite sans modèle construit un conteneur synthétique, et les vérifications sur modèle réel confirment les allers-retours de conversion et le rendu des prompts du serveur.
Statut du projet et philosophie
Le format et l'API ne sont pas figés. K3 est la cible principale et le modèle le mieux testé. Le chemin CPU est actuellement l'implémentation mesurée la plus rapide, mais CUDA, Metal et d'autres optimisations spécifiques au matériel restent à explorer. Le projet conserve un fichier docs/LEARNED.md pour les idées échouées et les résultats négatifs — une pratique rare et précieuse.
Les mesures sont traitées comme des résultats expérimentaux, pas comme des chiffres marketing. Chacune est liée au matériel, au conteneur, à la configuration et au commit sur lesquels elle a été obtenue. Les mesures instables sont rapportées sous forme de plages, et les résultats ultérieurement jugés incorrects restent enregistrés comme tels.
Réflexions finales
WASTE est une expérience audacieuse qui remet en question l'hypothèse selon laquelle les modèles frontières nécessitent une infrastructure à l'échelle d'un datacenter. En diffusant les poids depuis le NVMe et en utilisant la parcimonie MoE à son avantage, il amène un modèle de 2,78 T de paramètres sur un ordinateur portable. C'est lent, mais ça fonctionne — et c'est open source sous licence Apache 2.0.
Si vous êtes un développeur intéressé par repousser les limites de l'IA locale, WASTE vaut le coup d'œil. Commencez avec Kimi-Linear (conteneur de 19 Go, 10,7 tok/s) pour vous familiariser avec le moteur, puis envisagez l'expérience complète de K3. Le projet accueille les contributeurs, en particulier pour de nouveaux backends matériels et des expériences de performance — même les résultats négatifs sont valorisés.
Consultez le dépôt GitHub pour la documentation complète, y compris le format de conteneur, les comparaisons de backends et les directions de recherche.