kimi-k3-in-c : faire tenir un modèle de 2,78 billions de paramètres dans 8,24 Go de RAM

Le problème : un point de contrôle de 1,56 To pour une machine qui n'en a que 8

Le README annonce 2,78 billions de paramètres et 1,56 To sur disque. Aucune machine de bureau ne charge cela en mémoire, et une carte graphique grand public encore moins. Le projet prend le problème par l'autre bout : au lieu de réduire le modèle, il réduit ce qui doit être résident à un instant donné. La cible est explicite dans le titre du dépôt et dans la section Requirements : Linux x86-64, C99 portable, zéro dépendance, pas de BLAS, pas de cadre applicatif, pas de GPU. Le public visé n'est donc pas celui qui veut servir un modèle à des utilisateurs, mais celui qui veut voir tourner un modèle de cette taille sur le matériel qu'il possède déjà, et lire le code qui rend cela possible. Le dépôt est organisé en deux parties : une prise en main avec commandes et options, puis une construction composant par composant de chaque boîte des schémas d'architecture. Cette seconde partie est le vrai contenu ; la première n'est qu'un mode d'emploi.

Quatre décisions sur l'emplacement des octets

L'architecture tient en une phrase du README : le tronc dense reste en mémoire jusqu'à la profondeur choisie et le reste est diffusé en flux, tandis que les 1,45 To d'experts routés ne sont jamais résidents et sont multipliés directement depuis leur forme empaquetée en 4 bits. Le schéma main_architecture montre un petit ensemble de travail résident en haut, le modèle sur NVMe en dessous, et quelques tuyaux étiquetés entre les deux. Le second schéma, fit_cascade, décrit quatre étapes qui font passer le déploiement d'un cluster à un ordinateur portable, avec la même sortie aux deux extrémités. C'est le point le plus intéressant du projet et aussi le plus contre-intuitif : la quantité de mémoire ne détermine pas ce que le modèle calcule, uniquement le temps qu'il met à le calculer. Le README affirme que la sortie est identique octet pour octet du plus petit au plus grand budget mémoire. Cette affirmation est vérifiable dans docs/data/, et c'est là qu'il faut aller si vous voulez la contester.

Le tableau des temps, et ce qu'il dit vraiment

Quatre lignes, un même prompt court. 8 Go de RAM : 26,5 s par token, le modèle entier transite depuis le disque à chaque étape. 32 Go : 24,2 s. 64 Go : 19,8 s. 128 Go et plus : 5,6 s, le modèle tient entièrement en mémoire et l'attente disque disparaît. Le saut entre 64 et 128 Go est le seul qui change vraiment la nature du problème, parce que c'est le seul endroit où le disque cesse d'être dans la boucle critique. Le README précise que ces mesures ont été faites sur une machine à 124 cœurs avec un NVMe rapide, et que sur les trois premières lignes un disque plus lent donne des temps plus élevés. Autrement dit, le tableau ne mesure pas seulement la RAM : il mesure la RAM et le disque ensemble. Les deux démonstrations exécutables citées plus bas sont, d'après le README, des captures faites sur un disque plus lent, ce qui explique des horloges plus hautes. La version v1.0.0 a par ailleurs allégé le calcul par token d'environ 8 fois, accéléré une question de suivi dans une conversation de 3,9 fois, et à peu près divisé par deux le coût des prompts longs, toujours selon le README.

Construire et lancer : les commandes réelles

Le README propose un quick start qui clone, compile et vérifie en une minute environ, sans modèle. Il faut ensuite le point de contrôle et le tronc séparément, d'où les deux chemins --trunk et le chemin positionnel. La ligne de commande complète donnée en exemple est : ./bin/k3 ~/k3model --trunk ~/k3trunk --preset laptop --tok ~/k3model --prompt "The capital of France is" --gen 8 --incremental. Sur cette invocation, le README rapporte 8 tokens en 261,5 s, soit 32,69 s par token, et un pic de RSS de 8,24 Go pour l'ensemble de l'exécution. Le second exemple remplace --preset laptop par --preset server, --gen 8 par --gen 28 et le prompt par "def fibonacci(n):" ; il rapporte 28 tokens en 299,3 s, 10,69 s par token, et 127,92 Go de pic RSS. Les options sont regroupées en familles dans le README : prompt, mémoire, génération, diagnostic. Deux clés de configuration méritent l'attention : --preset, qui sélectionne le budget mémoire, et --incremental, qui apparaît dans les deux exemples et conditionne la façon dont la génération avance. Le README documente aussi des variables d'environnement et des codes de sortie, ce qui compte si vous voulez scripter le binaire plutôt que le lancer à la main.

Un moteur de 176 Ko et un lecteur de configuration qui refuse de deviner

Le README annonce 176 Ko pour l'ensemble du moteur. C'est cohérent avec l'absence de cadre applicatif et de BLAS : tout ce qu'un cadre fournirait habituellement doit être écrit ici. La partie II détaille cette reconstruction dans l'ordre : lecture d'un point de contrôle de 1,56 To à partir de ses seuls en-têtes, lecteur de configuration, tokenizer octet par octet, experts déjà livrés sur un demi-octet, noyaux AVX2 avec un contrat en virgule flottante, puis les trois réductions restantes. Le titre de la section sur la configuration est un choix de conception assumé : le lecteur refuse de deviner. Cela signifie qu'une configuration incomplète ou ambiguë provoque une erreur plutôt qu'une valeur par défaut silencieuse. C'est défendable pour un moteur qui manipule des tailles de tenseurs et des profondeurs de tronc, où une supposition fausse se traduit par une lecture au mauvais offset. C'est aussi une source de friction à l'installation : attendez-vous à devoir fournir explicitement ce qu'un autre outil aurait déduit.

KDA, MLA et la mémoire d'attention qui ne grandit pas

Deux sections de la partie II portent sur l'attention. La première décrit KDA comme une attention dotée d'une mémoire qui ne grandit jamais. La seconde décrit MLA comme un latent unique à la place de quatre-vingt-seize têtes. Ce sont les deux endroits où le coût mémoire d'une inférence longue est réellement contenu, et le README relie explicitement la réduction du coût des prompts longs d'un facteur deux à ce travail. Le compromis est classique : remplacer quatre-vingt-seize têtes par un latent unique réduit l'empreinte, mais introduit une projection supplémentaire que les noyaux doivent gérer. Le README mentionne une section sur la réorganisation de l'attention, ce qui suggère que la disposition mémoire des tenseurs d'attention a demandé un travail à part. Pour un lecteur qui veut porter ce code ailleurs, c'est probablement la partie la plus délicate, parce qu'elle combine une structure mathématique non standard et des hypothèses sur l'ordre des octets en mémoire.

Ce que le projet ne fait pas

Le README le dit sans détour : c'est un modèle de base, donc ce qui suit " Paris." est une continuation et non une réponse, et il n'y a pas de gabarit de chat. Si votre besoin est un assistant conversationnel, ce binaire ne le fournit pas et vous devrez construire la couche de dialogue vous-même. La plateforme est une autre limite dure : Linux x86-64, avec des noyaux AVX2. Le C99 est portable, mais les noyaux ne le sont pas nécessairement, et le README ne décrit pas de chemin de repli pour une architecture sans AVX2. Le débit est la troisième limite, et c'est la plus visible : 26,5 s par token sur une machine à 8 Go. Un prompt de quelques centaines de tokens se compte en heures. Enfin, l'absence de BLAS et de cadre applicatif est présentée comme une vertu, mais elle signifie aussi que vous n'héritez d'aucune optimisation tierce et que toute amélioration de performance devra venir du dépôt lui-même. Le projet est en v1.0.0, publiée le 7 août 2026, après une v0.1.0 le 2 août 2026 : l'écart de cinq jours entre les deux versions situe le projet très tôt dans sa vie, ce que le README ne cherche pas à masquer.

L'alternative : llama.cpp, et la différence de conception

L'alternative évidente pour exécuter un grand modèle sur CPU est llama.cpp. La différence n'est pas la performance brute, c'est la cible. llama.cpp est un moteur généraliste : il vise un grand nombre d'architectures de modèles, une quantification variée, des liaisons pour plusieurs langages et l'exécution sur CPU comme sur GPU. kimi-k3-in-c fait l'inverse. Il ne prend en charge qu'un seul modèle, le code tient en 176 Ko, il n'y a aucune dépendance, et les quatre décisions sur l'emplacement des octets sont taillées pour cette architecture précise, Mixture-of-Experts avec experts en MXFP4 et attention MLA. Le README présente d'ailleurs la partie II comme une construction de chaque composant depuis zéro, ce qui est une finalité en soi : le dépôt est autant une explication exécutable qu'un outil. Si vous voulez servir un modèle, llama.cpp a l'écosystème. Si vous voulez lire, modifier et comprendre chaque étape d'une inférence MoE sans cadre intermédiaire, kimi-k3-in-c est plus court à appréhender, précisément parce qu'il ne fait qu'une chose.

Licence, maintenance et ce qu'il faut vérifier en premier

Le dépôt est sous Apache-2.0, ce qui autorise l'usage, la modification et la redistribution, y compris dans un contexte commercial, à condition de conserver les mentions de licence et de copyright et de signaler les fichiers modifiés. Apache-2.0 contient une clause de brevets explicite, ce qui est plus rassurant qu'une licence de type MIT pour un composant que vous intégreriez. Cela ne dit rien du point de contrôle Kimi K3 lui-même, dont les conditions sont distinctes de celles du code et que le README ne traite pas ici. Sur la maintenance, les éléments disponibles sont minces : deux versions publiées à cinq jours d'intervalle, un fichier CHANGELOG.md, un flux d'intégration continue dans .github/workflows/ci.yml, et un dernier push au 26 août 2026. Le README ne décrit pas de politique de compatibilité ni de rythme de publication. La première chose à vérifier avant d'adopter, c'est le contenu de docs/data/ : c'est la source que le README cite pour chaque chiffre de ce document, et c'est là que se joue la seule affirmation forte du projet, l'identité octet pour octet de la sortie entre tous les budgets mémoire.

Conclusion éditoriale

À adopter si vous voulez comprendre ou expérimenter une pile d'inférence complète sans dépendance, sur une machine Linux x86-64 ordinaire, et si 26 secondes par token vous convient. À éviter si vous avez besoin d'un débit utilisable en production ou d'un modèle conversationnel : c'est un modèle de base, sans gabarit de chat, et le README indique lui-même que le point de contrôle pèse 1,56 To. Avant de vous engager, vérifiez deux choses concrètes : que votre disque atteint un débit suffisant, puisque les trois premières lignes du tableau de temps lisent le modèle depuis le disque à chaque étape, et que vos fichiers de configuration passent le lecteur qui refuse de deviner quoi que ce soit.

Sources officielles

1. FareedKhan-dev/kimi-k3-in-c on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases