Kimi K3 en C : un modèle de 2 780 milliards de paramètres sur un seul processeur

✦Faites exploser le trafic de votre site webEn savoir plus

Mille cinq cent soixante gigaoctets de poids sur disque, 8,24 gigaoctets de mémoire vive utilisés. L’écart entre ces deux chiffres résume tout l’intérêt du dépôt kimi-k3-in-c, ouvert le 1er août 2026 et crédité de 7 108 étoiles au 4 septembre 2026 (API GitHub). Le projet ne prétend pas remplacer une infrastructure de production. Il démonte une croyance tenace : celle qui veut qu’un modèle de frontière exige forcément une salle machine.

À retenir d’emblée : kimi-k3-in-c est un moteur d’inférence open source écrit en C, qui fait tourner le modèle Kimi K3 et ses 2 780 milliards de paramètres sur un seul processeur avec 8,24 gigaoctets de mémoire vive, sans carte graphique ni bibliothèque externe. Le dépôt affiche 7 108 étoiles au 4 septembre 2026. La démonstration reste lente, mais elle prouve qu’un modèle géant tient sur du matériel ordinaire quand son architecture s’y prête.

Temps de lecture : 13 min

Mis à jour le 4 septembre 2026

Qu’est-ce que kimi-k3-in-c et que démontre ce dépôt ?

kimi-k3-in-c est un moteur d’inférence open source écrit en C, qui fait tourner le modèle Kimi K3 et ses 2 780 milliards de paramètres sur un seul processeur avec 8,24 gigaoctets de mémoire vive, sans carte graphique ni bibliothèque externe. Le projet est publié sous licence Apache 2.0 et cumule 7 108 étoiles au 4 septembre 2026 (API GitHub).

Un moteur de 176 kilooctets, sans dépendance

Le moteur est écrit en langage C, dans sa version normalisée de 1999. Il ne s’appuie sur aucune bibliothèque d’algèbre linéaire, aucun cadre d’apprentissage automatique, aucune carte graphique.

Les routines de multiplication matricielle sont écrites à la main. L’auteur troque le débit maximal contre l’absence totale de dépendances et un chemin de code lisible de bout en bout.

Le binaire compilé pèse 176 kilooctets. À titre de comparaison, une installation classique de bibliothèque d’inférence occupe plusieurs centaines de mégaoctets avant même de charger un modèle.

Pourquoi écrire un moteur d’inférence à la main

La démarche paraît anachronique à l’heure des bibliothèques prêtes à l’emploi. Elle a pourtant deux vertus concrètes, indépendantes de toute considération esthétique.

La première tient à la portabilité. Un moteur sans dépendance se compile sur n’importe quelle machine disposant d’un compilateur et d’une bibliothèque mathématique standard, y compris sur du matériel ancien ou contraint.

La seconde tient à la lisibilité. Un chemin de code court se lit intégralement, se vérifie et s’audite, ce qu’aucune pile logicielle de plusieurs centaines de mégaoctets ne permet raisonnablement.

Le modèle visé, et son ordre de grandeur

Kimi K3 est un modèle publié par le laboratoire chinois Moonshot AI. Ses poids représentent 1,56 téraoctet de fichiers.

Chargé de la manière habituelle, en dépliant chaque paramètre en nombre à virgule flottante maintenu en mémoire, il réclamerait environ 5,56 téraoctets de mémoire vive. Ce volume relève de la baie de serveurs, pas du poste de travail.

Le dépôt annonce le même modèle, non modifié, tournant sur un processeur unique avec 8,24 gigaoctets de mémoire mesurés au pic. Le rapport entre les deux chiffres dépasse six cents.

Comment un modèle de 1,56 téraoctet tient-il dans 8 gigaoctets ?

La réponse tient en trois techniques empilées, dont aucune n’est un tour de passe-passe. Elles exploitent une propriété structurelle du modèle, pas une approximation de sa sortie.

Le mélange d’experts, une architecture creuse par construction

Kimi K3 compte 93 couches. La première est une couche dense classique ; les 92 suivantes routent chaque jeton vers 16 experts choisis parmi 896.

Pour un jeton donné, environ 104 milliards de paramètres participent réellement au calcul, sur 2 780 milliards. Les 96,3 % restants doivent exister quelque part d’accessible, sans obligation d’occuper la mémoire vive.

Cette architecture n’a rien d’exotique en 2026. La plupart des très grands modèles ouverts publiés cette année reposent sur le même principe, ce qui rend la leçon transposable au-delà de ce dépôt.

Le streaming depuis le disque, et le cache

Les experts inactifs dorment sur le disque, dans leur forme compactée sur quatre bits, et sont multipliés directement depuis cette représentation. Seuls les experts sollicités remontent en mémoire, gérés par un cache qui évince les moins récemment utilisés.

Ce choix déplace le goulot d’étranglement. Le calcul cesse d’être le facteur limitant, la lecture disque prend sa place, ce qui rend un disque rapide indispensable.

La mémoire vive ne sert plus à contenir le modèle, mais à éviter d’aller le rechercher. Elle devient un accélérateur, pas une condition d’exécution.

Quelles performances réelles selon la machine dont vous disposez ?

Le dépôt publie des mesures par configuration, sur un même prompt court. Le résultat produit reste identique octet pour octet, seule l’horloge change.

Ce que ces chiffres disent, et ce qu’ils ne disent pas

Ces mesures viennent d’une machine à 124 cœurs équipée d’un disque rapide. Sur un disque plus lent, les trois premières configurations se dégradent nettement, puisqu’elles relisent le modèle à chaque étape.

Un jeton correspond à peu près à un morceau de mot. Produire une phrase de trente jetons demande donc plus de dix minutes sur un portable ordinaire.

Aucun usage interactif n’est envisageable à ce rythme. La démonstration porte sur la faisabilité, pas sur l’utilisabilité, et l’auteur ne prétend rien d’autre.

Le saut entre 64 et 128 gigaoctets mérite attention. Il correspond au moment où le modèle cesse d’attendre le disque, ce qui divise le temps par plus de trois.

Cette rupture nette est instructive pour tout dimensionnement. La performance d’une chaîne d’inférence ne progresse pas linéairement avec la mémoire ajoutée : elle bascule d’un coup, au moment où les données cessent de faire l’aller-retour.

Un calcul maison pour situer l’échelle

Rapporté à un ordre de grandeur budgétaire, le premier tableau relève de l’investissement en salle machine, le second d’un poste de travail existant plus un disque rapide. Le passage d’une colonne à l’autre ne coûte rien d’autre qu’une architecture adaptée.

Pour appliquer chez vous : passer en production une fois la fiabilité prouvée.

Pourquoi ce projet intéresse-t-il une PME qui vise l’IA locale ?

Aucune entreprise ne mettra ce moteur en production tel quel. L’intérêt est ailleurs : il déplace la frontière de ce qu’on croit possible sans infrastructure dédiée.

La souveraineté cesse d’être un mur budgétaire

Le sujet revient dans presque toutes nos discussions de cadrage. Données de santé, dossiers RH, contrats commerciaux : certaines entreprises ne peuvent pas envoyer ces contenus à une interface distante, quel que soit le fournisseur.

L’argument entendu contre l’hébergement interne tient en une phrase : le matériel coûte trop cher pour une PME. Cette démonstration montre que l’affirmation dépend entièrement de l’architecture du modèle retenu.

Les modèles à experts, plus creux par construction, ouvrent une voie que les modèles denses ferment. Le sujet rejoint celui du routage vers un modèle local, où le bon arbitrage consiste rarement à tout héberger.

Le bon modèle est rarement le plus gros

Un besoin d’entreprise se formule en tâches, pas en milliards de paramètres. Trier des courriels entrants, extraire des montants d’une facture ou reformuler une réponse type relèvent de modèles compacts, exécutables sur un serveur banal.

Le réflexe inverse coûte cher. Dimensionner l’infrastructure sur le modèle le plus impressionnant du moment conduit à un devis hors de proportion avec l’usage réel, puis à l’abandon du projet.

La reproductibilité, argument sous-estimé

La sortie reste identique de 8 à 224 gigaoctets de mémoire. Cette propriété a une conséquence directe en entreprise : un résultat obtenu sur un poste de test se reproduit sur le serveur, sans écart inexpliqué.

La newsletter HDVMA

Recevez 1 fois par semaine les articles IA, SEO & GEO de HDVMA

Votre email *

RGPD et données personnelles : *

Vos données ne seront pas commercialisées, elle serviront seulement à vous envoyer les informations demandées  Politique de confidentialité RGPD 

Je m'inscris

Veuillez ne pas remplir ce champ.

Un email par semaine maximum · Désinscription en un clic

Rares sont les chaînes d’inférence qui offrent cette garantie. Elle simplifie considérablement le travail de vérification, de recette et d’audit.

Quelles limites interdisent d’en faire un outil de production ?

Le projet énonce ses limites sans détour, ce qui vaut mieux que bien des annonces commerciales. Trois d’entre elles disqualifient tout usage opérationnel immédiat.

La vitesse, le modèle de base, la dépendance au disque

La vitesse d’abord. Une réponse de deux phrases demande plusieurs minutes, y compris sur une station de travail bien dotée.

Le modèle ensuite. Il s’agit d’un modèle de base, sans gabarit de conversation ni ajustement aux instructions : il continue un texte au lieu de répondre à une demande. Un usage professionnel exige un modèle instruit.

Le disque enfin. Chaque jeton déclenche des lectures aléatoires. Un disque à plateaux rend l’exécution inutilisable, et un disque rapide s’use plus vite sous ce régime.

Une limite plus discrète : la maintenance

Un projet porté par une seule personne, ouvert depuis un mois, n’offre ni feuille de route, ni engagement de correction, ni version de long terme. Cette réalité vaut pour la plupart des dépôts spectaculaires du moment.

Elle n’interdit rien, elle impose seulement de savoir ce que l’on signe. Un code lisible et sans dépendance se reprend plus facilement qu’une pile complexe, ce qui atténue partiellement le risque.

Ce qui reste transposable malgré tout

Trois idées survivent au changement d’échelle. La première : mesurer la mémoire réellement nécessaire plutôt que la déduire du nombre de paramètres.

La deuxième : vérifier que votre chaîne produit la même sortie sur deux machines différentes, avant de bâtir quoi que ce soit dessus.

La troisième : traiter le stockage comme une composante de performance, au même titre que le processeur. Cette dimension disparaît systématiquement des devis initiaux.

Une quatrième idée mérite d’être ajoutée : préférer un code que vous pouvez lire. Le jour où une réponse aberrante remonte du terrain, la capacité à ouvrir le moteur et à suivre le chemin de calcul vaut tous les contrats de support.

Cadrez votre stratégie d’inférence locale sur des chiffres

La question de l’hébergement interne se tranche sur des mesures, pas sur des principes. Voici l’ordre qui évite les mauvaises surprises.

Six étapes avant tout achat de matériel

Aucune de ces étapes ne demande une compétence rare. Elles demandent surtout de résister à la tentation de commander la machine avant d’avoir posé le besoin.

• Décrire la tâche réelle et son volume quotidien, en requêtes et en longueur de texte.
• Identifier ce qui doit rester interne pour des raisons légales ou contractuelles.
• Tester deux ou trois modèles ouverts de taille modeste sur vos cas métier.
• Mesurer la mémoire vive au pic et le temps de réponse obtenus, pas ceux annoncés.
• Chiffrer le stockage rapide, souvent oublié et parfois décisif.
• Comparer le total à une année de facturation à l’usage chez un fournisseur.

Cette séquence prend deux à trois semaines. Elle évite les deux erreurs symétriques : acheter une machine surdimensionnée, ou renoncer à l’interne sur la foi d’un devis inadapté.

Un point mérite d’être posé dès la première étape : la répartition entre traitements sensibles et traitements banals. Rares sont les entreprises qui doivent tout héberger, plus rares encore celles qui peuvent tout externaliser.

Cette répartition détermine ensuite le dimensionnement. Une machine calibrée pour 15 % du volume coûte une fraction de celle qui absorberait la totalité, pour un bénéfice de conformité identique.

Le rôle des modèles compacts

La plupart des besoins d’entreprise se satisfont de modèles bien plus petits que ceux qui font l’actualité. Extraction d’informations, classement de messages, reformulation, résumé de compte rendu : ces tâches ne réclament pas un modèle de frontière.

Réservez les grands modèles aux cas qui l’exigent vraiment, et appelez-les par une interface distante quand c’est le cas. La question rejoint directement le panorama des dernières versions de modèles.

Gardez l’arbitrage du côté humain

Une infrastructure d’inférence engage plusieurs années. Le choix mêle des critères techniques, juridiques et budgétaires qu’aucun score ne résume.

Documentez la décision, ses hypothèses de volume et sa date. Elle se réexamine à chaque changement significatif de tarif ou de réglementation, et cette relecture sera bien plus rapide si le raisonnement initial est écrit.

Prévoyez enfin une porte de sortie. Une chaîne d’inférence dont le modèle se remplace par configuration vous laisse libre de changer d’avis, ce qui vaut mieux que le meilleur choix initial figé pour trois ans.

Cette réversibilité se conçoit au démarrage, jamais après. Elle coûte quelques jours de travail supplémentaires au moment de la construction, et fait économiser un projet entier lorsque les conditions changent.

Questions fréquentes sur l’inférence locale d’un très grand modèle

Qu’est-ce que kimi-k3-in-c ?

kimi-k3-in-c est un moteur d’inférence open source écrit en C, qui fait tourner le modèle Kimi K3 et ses 2 780 milliards de paramètres sur un seul processeur avec 8,24 gigaoctets de mémoire vive, sans carte graphique ni bibliothèque externe. Ouvert le 1er août 2026 sous licence Apache 2.0, le dépôt cumule 7 108 étoiles au 4 septembre 2026 et tient dans 176 kilooctets de code compilé.

Comment un modèle de 1,56 téraoctet tient-il dans 8 gigaoctets de mémoire ?

Par la conjonction de trois techniques. Le modèle est un mélange d’experts, donc seuls 16 experts sur 896 participent au calcul de chaque jeton. Les poids sont compactés sur quatre bits et restent sur le disque. Un cache ne garde en mémoire que les experts sollicités récemment. La mémoire vive achète de la vitesse, pas la faisabilité.

Peut-on utiliser ce moteur en production ?

Non, en l’état. Le temps de réponse va de 5,6 à 26,5 secondes par jeton selon la machine, ce qui interdit tout usage interactif. Le modèle chargé est un modèle de base, sans gabarit de conversation ni ajustement aux instructions. Le projet est une démonstration d’ingénierie et une base de code lisible pour l’étude.

Faut-il une carte graphique pour faire tourner un modèle en local ?

Pas nécessairement, mais elle change tout sur la vitesse. Ce dépôt prouve qu’un très grand modèle s’exécute sur processeur seul, au prix d’une lenteur rédhibitoire pour un usage courant. Pour un besoin professionnel réel, un modèle compact accéléré par une carte graphique d’entrée de gamme reste la configuration la plus raisonnable.

Quelle mémoire vive prévoir pour héberger un modèle en interne ?

La question se pose à l’envers. Mesurez d’abord la mémoire réellement utilisée au pic par le modèle candidat, sur vos propres cas métier et sur votre volume quotidien, puis dimensionnez la machine. Déduire le besoin du seul nombre de paramètres conduit à des devis surdimensionnés, parfois d’un facteur considérable sur les architectures à mélange d’experts. Ajoutez systématiquement le débit du stockage à vos mesures.

Pourquoi la sortie reste-t-elle identique quelle que soit la mémoire disponible ?

Parce que la mémoire ne sert qu’à éviter des lectures disque, jamais à modifier le calcul. Les mêmes experts participent au même calcul dans le même ordre, que le modèle soit lu depuis le disque ou depuis la mémoire. Cette reproductibilité constitue un avantage sérieux pour la recette et l’audit d’une chaîne d’inférence.

Audit IA gratuit en 48 h
Prendre contact
Parler à Eric

✦L’IA dans votre entreprise, c’est simple !En savoir plus

✦Que cherchez-vous ?400 articles · 12 domaines · réponse en quelques secondes

Automatiser mes devisÊtre visible dans ChatGPTUn LLM en localPar où commencer ?

➤

Réponses construites uniquement sur nos articles publiés.

Un article par semaine, dans votre boîte mail.Je m’inscris

Eric ChristopheFondateur · il répond lui-même☏ 06 25 34 34 25◷ Prendre RDV

Les domaines

Explorez par sujet

IA générative & LLML'IA générative et les grands modèles de langage (LLM) transforment la125Outils & agents IALes outils et agents IA permettent d'automatiser des tâches complexes et74Écosystème ClaudeL'écosystème Claude d'Anthropic est devenu la boîte à outils de référence52GEO & SEO techniqueLe GEO (Generative Engine Optimization) et le SEO technique déterminent votre37Actualité & société IAL'IA transforme l'économie, le droit et la société. Cette rubrique décrypte27IA locale & hardwareFaire tourner l'IA en local , sur un mini-PC, une station26Forward Deployed EngineerLe Forward Deployed Engineer (FDE), ou ingénieur déployé chez le client,23Robots & IA physiqueLes robots humanoïdes et l'IA physique passent du laboratoire au monde17Juridique & IAL'IA s'invite dans le droit : rédaction de conclusions, recherche de6Commerce IA & e-commerceLe commerce IA réinvente la vente en ligne : fiches produits5Marketing IALe marketing IA transforme l'acquisition : stratégie de contenu, génération de4Création de site & devCréer un site web et développer avec l'IA n'a jamais été4