Un développeur a réussi l’exploit d’installer Kimi K3, le modèle phare en open-weights de Moonshot AI, dans seulement 29 Go de mémoire RAM, soit l’équivalent de la mémoire d’un ordinateur personnel standard. Si le modèle fonctionne bien, lui demander « Quelle est la capitale de l’Italie ? » a exigé 31 secondes de réflexion avant de générer une réponse de 16 mots.
Figure : Kimi K3, le modèle phare rendu open-source fin juillet par Moonshot AI. Source : github.com/MoonshotAI
Cette prouesse a fait grand bruit dans la communauté des développeurs ces derniers jours. Avec plus de 130 votes positifs et 50 commentaires sur Hacker News, les réactions oscillent entre émerveillement et scepticisme technique. Voici un décryptage des enjeux et du fonctionnement de cette expérience.
Pourquoi les modèles IA sont-ils si gourmands en mémoire ?
Pour comprendre l’ampleur de l’exploit, il faut d’abord mesurer la taille réelle de Kimi K3.
Kimi K3 est le dernier modèle phare publié par Moonshot AI à la fin du mois de juillet 2026, totalisant le chiffre vertigineux de 2 780 milliards de paramètres (2,78T).
Les paramètres peuvent être comparés à des valeurs numériques stockées dans le réseau de neurones du modèle. L’intelligence d’une IA repose sur des calculs mathématiques effectués sur ces volumes massifs de chiffres : plus un modèle compte de paramètres, plus il est performant, mais plus son empreinte mémoire est vaste. Dans sa version officielle (compressée en FP4), K3 occupe 1,42 To, une taille qui ne rentre même pas sur un disque SSD classique de 1 To.
Lors de l’inférence, le modèle doit charger l’ensemble de ces paramètres dans la mémoire vive (RAM) de l’ordinateur pour effectuer ses calculs. Faire entrer 1,42 To de données dans un espace de 29 Go de RAM représente un déficit de capacité de près de 50 fois.
En temps normal, les modèles de cette envergure fonctionnent exclusivement dans des centres de données cloud dotés de centaines de milliers de serveurs, de clusters de GPU et de téraoctets de RAM. Lorsque vous posez une question via une application, les calculs sont effectués à distance avant d’être transmis à votre écran.
Pourquoi vouloir exécuter ces modèles en local ?
Si les services cloud sont rapides, simples et performants, pourquoi des ingénieurs cherchent-ils à tout prix à exécuter ces modèles sur leur propre machine ? Les motivations sont très pragmatiques.
La première raison concerne la confidentialité. Chaque requête envoyée à une API cloud transite par des serveurs tiers. Si cela pose peu de problèmes pour une discussion informelle, les contrats d’entreprise, le code source confidentiel, les dossiers médicaux ou les rapports financiers ne doivent absolument pas quitter l’enceinte de l’organisation. Le respect de la vie privée et la souveraineté des données restent le moteur principal de l’IA locale.
La deuxième raison est économique. Les fournisseurs cloud facturent à l’utilisation (au nombre de tokens). Si le coût reste minime pour un usage ponctuel, le traitement par lots ou l’utilisation d’agents autonomes peut rapidement alourdir la facture. L’exécution locale repose sur un investissement matériel unique : une fois le matériel acheté et l’électricité payée, l’utilisation devient illimitée.
La troisième raison réside dans l’autonomie hors-ligne. Une IA locale fonctionne sans connexion Internet et reste à l’abri des pannes de réseau, des augmentations de tarifs ou des changements de politique des fournisseurs cloud.
S’ajoute à cela la passion des développeurs. La communauté dédiée à « l’inférence locale » s’efforce de repousser les limites matérielles pour faire tourner des modèles réputés inaccessibles sur des machines grand public. Le projet en question, baptisé WASTE, a publié l’intégralité de sa démarche et ses carnets d’expérimentation en open-source sur GitHub.
Comment faire tenir Kimi K3 dans 29 Go de RAM ?
La première technique essentielle est la quantification, qui consiste à réduire la précision numérique des poids du modèle.
À l’origine, les paramètres sont stockés sous forme de nombres à virgule flottante de haute précision. La quantification réduit cette précision en codant les poids sur 4 ou 3 bits. La version officielle de K3 était déjà compressée sur 4 bits (1,42 To). Le projet WASTE a poussé l’optimisation en quantifiant les « experts » du modèle sur 3 bits, ramenant la taille totale à 982 Go.
Cependant, la compression seule ne suffit pas à passer de 982 Go à 29 Go. La véritable astuce du projet WASTE repose sur une gestion dynamique de la mémoire.
Kimi K3 utilise une architecture de type Mélange d’Experts (MoE, Mixture of Experts) comprenant 896 sous-réseaux experts. Or, pour générer chaque mot (token), seuls 16 experts sont sollicités, tandis que les 880 autres restent inactifs. C’est le principe d’un grand hôpital où une consultation ne réunit que les spécialistes nécessaires tout en laissant les autres en réserve.
L’équipe du projet a donc conservé l’ossature principale du modèle (27 Go) en mémoire RAM permanente, tandis que les 880 experts restants sont stockés sur le disque SSD et chargés à la volée en temps réel selon les besoins.
Figure : Vue d’ensemble de l’architecture de K3 — Mélange d’experts et nouveau mécanisme d’attention pour 2,8 trillions de paramètres. Source : sebastianraschka.com
Le compromis réside dans la vitesse. Pour chaque mot généré, le système doit lire 17 Go de données d’experts depuis le disque SSD. Un SSD NVMe interne très rapide (atteignant 12,78 Go/s) parvient tout juste à suivre le rythme ; sur un disque externe USB (0,94 Go/s), il faut patienter 13 secondes par mot.
La préparation de cet environnement s’avère également exigeante. La conversion des 1,42 To originaux vers le format quantifié de 982 Go nécessite près de 5 heures de traitement, sans compter l’obligation de disposer d’un stockage NVMe haute performance.
Ainsi, la valeur de « 29 Go » correspond au seuil de mémoire RAM requis par le système, et non à la taille globale du modèle. La mémoire RAM ne contient pas l’intégralité du modèle, mais uniquement sa structure centrale active. Si une machine dotée de 32 Go de RAM peut lancer l’application, 64 Go sont recommandés pour éviter que le système d’exploitation n’utilise le disque comme mémoire virtuelle, ce qui diviserait la vitesse par huit.
Le coût d’une forte compression
La quantification comporte des contreparties. En réduisant la précision des chiffres, la qualité des réponses peut s’en trouver altérée. Les tests menés par l’équipe d’Unsloth montrent qu’une quantification sur 2 bits conserve environ 90 % de fidélité par rapport au modèle d’origine, tandis qu’une passe à 1 bit fait chuter la précision à environ 80 %.
Figure : Plus un modèle est compressé, plus la probabilité de divergence par rapport aux réponses d’origine augmente. Source : unsloth.ai
De plus, la qualité varie fortement selon la technique d’exécution. Deux quantifications à 1 bit réalisées par des équipes différentes sur un même modèle peuvent afficher des écarts de qualité allant du simple au vingt-uple. La quantification est un véritable travail d’orfèvre ingénieur.
0,5 token par seconde : Entre faisabilité et usage au quotidien
À un rythme de 0,5 token par seconde, obtenir une réponse courte de 16 mots prend 31 secondes, et un paragraphe de 128 mots nécessite six minutes. Une telle lenteur rend l’usage difficile pour une conversation fluide. De plus, Kimi K3 étant un modèle qui effectue une phase de raisonnement avant de répondre, cette étape préalable rallonge encore le temps d’attente sur machine locale.
Cependant, les auteurs du projet affichent une démarche exemplaire : ils ne cherchent pas à survendre la vitesse, mais à démontrer la faisabilité technique. En comparant couche par couche les résultats du modèle avec l’implémentation officielle de référence, ils ont confirmé une marge d’erreur inférieure à quelques millionièmes. D’après leurs recherches, il s’agit de la première démonstration publique de l’exécution d’un modèle de plus de 1 000 milliards de paramètres en streaming depuis un disque SSD sur un PC grand public.
À l’inverse, l’application de cette méthode à des modèles plus légers offre une expérience bien différente : le modèle Kimi-Linear de 48 milliards de paramètres ne nécessite que 19 Go de stockage et 1,87 Go de RAM au démarrage, tout en atteignant 10,7 mots par seconde sur un ordinateur classique. Sur des serveurs de centre de données, K3 génère plus de 100 tokens par seconde.
Entre « pouvoir tourner » et « être utilisable au quotidien », il existe un fossé. D’un côté se trouve une prouesse d’ingénierie ; de l’autre, un outil de travail fluide. Cette expérience a permis de réduire un peu plus cette distance.
Le débat : Exécution locale vs. Cloud
Ce projet a relancé le débat entre partisans de l’IA locale et adeptes du cloud.
- Les défenseurs du local mettent en avant la confidentialité des données, l’absence de frais récurrents à l’utilisation, le fonctionnement hors-ligne et le contrôle total des systèmes.
- Les partisans du cloud soulignent la vitesse d’exécution (plusieurs dizaines à centaines de tokens par seconde), l’accès immédiat aux modèles les plus récents et l’absence de gestion matérielle.
Sur Hacker News, certains ingénieurs ont contesté l’affirmation selon laquelle 29 Go de RAM suffisent pour faire tourner un modèle de 2,78T, rappelant que les paramètres denses nécessitent à eux seuls environ 115 Go en précision native. L’équipe du projet a précisé que la combinaison de la quantification 3 bits et du streaming NVMe valide scientifiquement ce chiffre.
Ce type de débat constructif fait progresser l’écosystème. L’inférence locale a franchi de nombreuses étapes réputées impossibles grâce à ces échanges et vérifications communautaires.
Conclusion
Afficher 29 Go de RAM requis pour 0,5 token par seconde est encore loin de proposer un outil d’IA prêt pour un usage quotidien. Néanmoins, replacée dans une perspective historique, la progression reste saisissante : il y a deux ans, exécuter un modèle de quelques dizaines de milliards de paramètres sur un PC relevait de l’exploit ; aujourd’hui, les modèles de mille milliards de paramètres deviennent accessibles. Avec l’augmentation des débits SSD, l’affinage de la quantification et l’optimisation des architectures, cette frontière continuera de reculer.
Pour la majorité des utilisateurs aujourd’hui, l’application Kimi reste le moyen le plus rapide d’obtenir des réponses. Mais la prochaine fois que votre écran indiquera « Réponse générée par le cloud », prenez un instant pour mesurer la formidable infrastructure technique qui alimente ces mots.
Liens de référence :
- GitHub : Dépôt sqliteai/waste
- Discussion HN (item?id=49123386)
- Hugging Face : Fil de discussion #148 sur moonshotai/Kimi-K3
- Sebastian Raschka : Notes sur l’architecture de Kimi K3
- Unsloth : Documentation sur l’exécution locale de Kimi K3
- Blog Apidog : Comment exécuter Kimi K3 en local
