Kimi K3 exécute un modèle de 2,78 billions de paramètres avec 8,24 Go de mémoire

Exécuter un modèle de 2,78 billions de paramètres dans huit gigaoctets de mémoire ressemble à un tour de magie. Le dépôt kimi-k3-in-c révèle le secret : le modèle ne tient pas dans la RAM et ne cherche pas à y tenir. Le moteur ne conserve en mémoire vive que le jeu de données de travail et lit la majeure partie des poids depuis le stockage au fil des calculs.

D’après les mesures de l’auteur, une exécution complète de Kimi K3 atteint un pic de consommation de 8,24 Go de RAM. Aucun GPU, aucune bibliothèque BLAS ni aucun framework de ML classique ne sont nécessaires : le cœur est écrit en C99 portable. Le revers de ce chiffre impressionnant est un checkpoint de 1,56 To, auquel s’ajoute un fichier compressé de 109 Go contenant la partie dense du modèle, ainsi que plusieurs dizaines de secondes d’attente pour chaque token.

Comment le modèle tient dans une quantité de mémoire ordinaire

Imaginez une armoire dont vous n’avez besoin que d’un tiroir à la fois. Il est inutile de poser toute l’armoire sur la table : il suffit d’ouvrir le tiroir nécessaire, d’en traiter le contenu, puis de passer au suivant. Ici, le NVMe rapide joue le rôle de l’armoire et la mémoire vive celui de la table.

Kimi K3 utilise une architecture clairsemée : seule une partie des experts est active à chaque étape. Le moteur lit les poids des experts sélectionnés directement sous une forme compressée sur quatre bits, conserve les données récemment utilisées dans un cache LRU et charge séquentiellement les couches denses. La taille du cache et le nombre de couches résidant en permanence en mémoire peuvent être adaptés à chaque machine.

Selon le tableau publié, une configuration dotée de 8 Go de RAM produit un token en environ 26,5 secondes. Avec 64 Go, ce délai tombe à 19,8 secondes ; avec 128 Go ou davantage, il descend à 5,6 secondes, car l’attente liée au disque disparaît presque entièrement. L’auteur affirme qu’à requête identique, le résultat reste strictement identique octet par octet : seul le temps change, pas les calculs.

Un exemple simple consiste à compléter la phrase « The capital of France is ». Dans la configuration minimale, le moteur a généré huit tokens en 261,5 secondes, avec un pic de consommation de 8,24 Go. C’est beaucoup trop lent pour un chat destiné aux utilisateurs, mais suffisant pour démontrer la viabilité de l’approche et étudier le modèle sans disposer d’une baie d’accélérateurs.

Ce qu’il faut en pratique

Le principal obstacle n’est pas la RAM, mais le stockage. Le checkpoint, la partie dense compressée et les fichiers de service nécessitent environ 1,7 To d’espace libre. Un NVMe local rapide est recommandé : lorsque les poids ne tiennent pas en mémoire, le support de stockage participe à la génération de chaque token. Sur un SSD lent, le résultat prendra encore plus de temps.

La compilation nécessite un compilateur C99, OpenMP et un processeur prenant en charge AVX2/FMA sur x86-64 ou NEON sur Arm. Le dépôt est compatible avec Linux, macOS et Windows. Sans télécharger le modèle de plusieurs téraoctets, il est possible de compiler le moteur et d’exécuter la suite de tests : celle-ci compare les opérations et les tokens générés à une implémentation de référence utilisant un modèle réduit doté du même schéma de calcul.

Les chiffres publiés doivent toutefois être considérés, pour l’instant, comme les résultats de l’auteur lui-même et non comme un benchmark indépendant. Le mode minimal est une démonstration de faisabilité technique, pas un serveur d’inférence prêt pour la production. La première version ne propose ni outils, ni images, ni serveur API, ni compression de l’historique des conversations. Même une station de travail puissante reste nettement plus lente qu’un service cloud fonctionnant sur GPU.

Pourquoi les développeurs devraient examiner ce code

La valeur du projet ne réside pas dans la promesse de remplacer un GPU par huit gigaoctets de RAM. Son code illustre concrètement quatre techniques utiles : le chargement en continu des couches, le traitement de poids quantifiés sans décompresser l’ensemble du tableau, un cache d’experts de taille limitée et des budgets mémoire séparés pour les différentes parties du modèle.

Si vous développez un outil local, une application edge ou un prototype hors ligne, ces solutions peuvent être transposées à des modèles de taille raisonnable afin d’obtenir des performances déjà exploitables. Une équipe produit doit commencer par définir la latence acceptable : si l’utilisateur attend une réponse en quelques secondes, cette exécution de Kimi K3 ne convient pas. En revanche, pour une expérience par lots, un audit d’architecture ou un environnement totalement dépourvu d’accélérateur, le dépôt cesse d’être une simple curiosité et devient un manuel d’ingénierie utile.