2,8 trillions de paramètres, et personne pour les faire tourner

Version 1, 4 août 2026. Chiffres vérifiés sur deux sources, voir la note de bas d’article.

Le 26 juillet 2026, en toute fin de journée américaine, Moonshot AI a mis en ligne les poids de Kimi K3 : 2,8 trillions de paramètres, un million de tokens de contexte, une licence ouverte. C’est, à ce jour, le plus grand modèle à poids ouverts jamais publié, un système de niveau frontière, offert au monde, un jour avant même la date que l’entreprise s’était fixée. L’annonce a été saluée comme un moment de bascule pour l’IA ouverte.

Puis chacun a essayé de le télécharger.

Le checkpoint pèse 1,56 To. Le faire tourner « proprement » réclame de l’ordre de 1,7 To de mémoire GPU, soit, dans la recette de référence de vLLM, deux nœuds de huit H200 reliés en InfiniBand. Même comprimé à l’os, en 1 bit, le modèle pèse encore près de 600 Go, au-delà de ce que la quasi-totalité des machines peuvent charger. Sur un MacBook ? Impossible. Sur un ou deux H200 ? Non plus. Le seul « exploit local » qui circule, un moteur d’inférence écrit en C qui streame les poids depuis un SSD NVMe, produit un token toutes les 33 secondes, et son auteur précise lui-même qu’il ne faut « servir quoi que ce soit avec ».

Autrement dit : le modèle est ouvert, mais son usage ne l’est pas. Et cela déplace la question, deux semaines après la sortie. Pendant que l’attention se focalisait sur le trophée des 2,8 trillions de paramètres, une autre catégorie de modèles ouverts a livré, presque sans bruit, l’essentiel de la valeur, plus petits, presque aussi bons, et jusqu’à cinquante fois moins chers à l’usage. Non que le géant soit inutile : on verra qu’il fait progresser tout l’écosystème. Mais il n’est plus, pour la plupart d’entre nous, le bon point de départ.

L’exploit est réel, et c’est justement le problème

Il faut rendre à K3 ce qui lui appartient. C’est une prouesse. Architecture Mixture-of-Experts avec 896 experts dont seulement 16 s’activent par token (environ 104 milliards de paramètres actifs), entraînement nativement en 4 bits (MXFP4), une fenêtre de contexte d’un million de tokens, et deux innovations maison, la Kimi Delta Attention et les Attention Residuals, qui expliquent une partie de ses scores. Sur les classements de modèles ouverts, il se hisse tout en haut, à portée du meilleur du propriétaire.

Mais chacune de ces qualités a un coût matériel. 2,8 trillions de paramètres, même en 4 bits, ce sont ~1,4 To de poids à loger quelque part. Le fait que seuls 16 experts s’activent par token réduit le calcul, pas la place : les 896 experts doivent tous être accessibles à tout instant. C’est là que le rêve « un modèle ouvert pour tous » se fracasse sur la physique du stockage.

Le déploiement, en clair :

Recettes validées dès le jour 0 : vLLM (2 nœuds × 8 H200, tensor-parallel 16), SGLang (H200 2×8, H100 4×8, B200, GB300, MI350X…).
Minimum réaliste : de l’ordre de 16 H200, ou 8 H200 en configuration très serrée. Un seul nœud 8×H100 (640 Go) ne peut pas charger le modèle.
Quantisations communautaires : 1 bit ≈ 594 Go (≥ 610 Go de RAM), 2 bits ≈ 861 Go. Le plus petit quant tient encore à ~540 Go.
API hébergée Moonshot : 3 $ / 15 $ par million de tokens (entrée / sortie).

Pour l’immense majorité des équipes, startups, labos, indépendants, PME, aucune de ces lignes n’est atteignable en self-hosting. Reste l’API, à 15 $ le million de tokens en sortie. Et c’est précisément ce prix qui ouvre le débat.

Le local est (presque) fermé

Récapitulons les portes fermées, parce qu’elles dessinent le problème en creux.

Un MacBook n’a ni la mémoire ni le disque : hors sujet. Un Mac Studio à 512 Go de mémoire unifiée, le haut de gamme Apple, reste sous le tiers du checkpoint, et sa bande passante (400 à 800 Go/s contre 3,35 To/s pour la HBM d’un H100) condamnerait de toute façon la génération à moins d’un token par seconde. La seule piste Apple crédible est un cluster de plusieurs Mac Studio reliés en Thunderbolt 5, quatre machines à 512 Go selon les premières estimations, et le support MLX officiel n’existe pas encore.

Un ou deux H200 (141 Go chacun) sont très loin du compte. La seule voie « petite échelle » réaliste est l’offload : garder l’attention sur un GPU, poser les experts en RAM système ou sur NVMe, façon KTransformers. Techniquement séduisant, mais aucune recette K3 packagée et vérifiée n’existait à la mi-juillet, et les débits restent hors du temps réel.

Ces impasses ne sont pas des détails : elles sont le sujet. Un modèle qu’on ne peut essayer qu’en louant un cluster à ~70 $/heure n’est « ouvert » que sur le papier, pour qui n’a pas déjà l’infrastructure.

Le cas d’école : faire tenir 2,8 trillions de paramètres dans 8 Go

Il existe pourtant une démonstration qui, à elle seule, éclaire toute la mécanique du problème, et sa seule issue. Un développeur, Fareed Khan, a écrit kimi-k3-in-c : un moteur d’inférence de K3 en C99 portable, sans BLAS, sans framework, sans GPU. Six fichiers C, libm, OpenMP, un binaire de 176 Ko. Il fait tourner le modèle de 2,8 trillions de paramètres sur un seul CPU, avec un pic de 8,24 Go de RAM. Son auteur l’a construit après avoir déployé K3 sur 32 H100 au travail, agacé de ne pas pouvoir le faire tourner chez lui, « pour comprendre l’architecture en l’implémentant, pas parce que vous devriez servir quoi que ce soit avec ».

Ce qu’il fait, exactement. Il génère du texte correct à partir du vrai checkpoint de 1,56 To, avec une empreinte mémoire que l’on règle comme un curseur. Au plus petit budget, 8,24 Go de RAM, à ~33 secondes par token. Au plus grand, ~128 Go de RAM, à ~11 s/token. Fait remarquable : la sortie est identique bit pour bit à tous les budgets intermédiaires. La mémoire n’achète que de la vitesse, jamais une réponse différente.

Comment il fonctionne. Tout repose sur une observation d’architecture. Sur les 1,56 To du checkpoint, ~93 % sont des experts routés, et seuls 16 des 896 experts s’activent par token. Ces experts n’ont donc jamais besoin de résider en mémoire : ils sont lus depuis le NVMe à la demande, puis multipliés directement dans leur forme empaquetée à 4 bits (le format MXFP4 natif du modèle), sans même une étape de déquantisation. La partie dense du réseau, le « trunk », est réécrite dans un fichier où la couche L se trouve à un décalage connu, et diffusée une couche à la fois. Ce qui reste réellement en RAM, c’est un anneau de streaming et un cache LRU d’experts dont on choisit la taille : c’est lui, le fameux curseur. Donner plus de mémoire agrandit le cache et réduit les allers-retours disque, donc accélère, sans jamais changer le calcul.

La conséquence conceptuelle est élégante : le même modèle tourne en 8 Go comme en 224 Go, et produit exactement la même chose. Le plancher mémoire redouté devient un simple réglage. On peut d’ailleurs vérifier le moteur sans rien télécharger, un make && make test d’une minute construit un modèle-jouet de 13 couches au même graphe tensoriel et le compare à une référence PyTorch.

Mais, et c’est là que le cas d’école rejoint la thèse, ce n’est pas praticable. Il faut toujours ~1,7 To d’espace disque libre et un NVMe rapide, et une demi-minute par token disqualifie tout usage interactif. kimi-k3-in-c ne rend pas K3 utilisable en local ; il prouve pourquoi il ne l’est pas. Il montre que le calcul par token d’un très gros MoE est minuscule, et que le seul verrou est la place, le stockage et la bande passante pour aller chercher les bons octets à temps. C’est une pièce d’orfèvrerie pédagogique, pas un chemin de production.

Pour mémoire, ceux qui veulent « rétrécir » K3 plutôt que le streamer se tournent vers les quantisations 1-bit GGUF apparues côté communauté : elles ramènent le modèle à ~594 Go, au prix d’une perte de qualité, et réclament encore ≥ 610 Go de RAM, soit une station à très grande mémoire, hors de portée grand public. Deux stratégies opposées (streamer les 4 bits natifs, ou tout comprimer en 1 bit), même conclusion : il n’existe pas, à ce jour, de porte d’entrée locale grand public pour Kimi K3.

Le pivot : ce qu’on peut réellement utiliser

Voici le cœur de l’affaire. Sur la même quinzaine, trois modèles ouverts (ou en passe de l’être) ont livré l’essentiel de la valeur d’un modèle frontière, avec une accessibilité et un coût sans commune mesure.

Modèle	Sortie	Params (total / actifs)	Contexte	Prix API $/Mtok (in / out)	Repère perf	Self-hosting
Kimi K3	26 juil.	2,8 T / ~104 B	1 M	3,00 / 15,00	Top open-weight, niveau frontière	Cluster (≈16 H200)
Qwen 3.8 Max	3 août	2,4 T / ~95 B	1 M	2,00 / 6,00	Flagship Qwen, poids ouverts	Difficile (grand MoE)
Nemotron 3 Ultra	4 juin	550 B / 55 B	1 M*	0,50 / 2,20	AA Intelligence ≈ 48 (top open-weight US)	Nœud 8-GPU (quantisé)
DeepSeek V4-Flash	31 juil.	284 B / 13 B	1 M	0,14 / 0,28	AA Intelligence ≈ 50 · Terminal-Bench 82,7	Le plus léger

*Nemotron : 1 M annoncé, contextes de service souvent ~512 k. Prix DeepSeek = API officielle (les agrégateurs affichent parfois moins).

Lisez le tableau de haut en bas : à mesure que la taille diminue, le coût par million de tokens s’effondre, alors que l’écart de performance, lui, se réduit fortement. Entre K3 et DeepSeek V4-Flash, le rapport de prix en sortie est d’environ 54× (15 $ contre 0,28 $), pour un modèle qui obtient un indice d’intelligence Artificial Analysis comparable, voire supérieur, et un score de 82,7 au Terminal-Bench 2.1. Nemotron 3 Ultra, plus « intelligent » encore sur cet indice, se loue 2,20 $ en sortie et tient sur un seul nœud 8-GPU. Qwen 3.8 Max, le plus proche de K3 par la taille, coûte déjà 2,5× moins cher en sortie.

Pour la grande majorité des charges réelles, agents, extraction, RAG, génération de code, résumé, un modèle à 13, 55 ou 95 milliards de paramètres actifs franchit largement le seuil de qualité utile, et se déploie sur une infrastructure qu’on peut réellement se procurer. Le raisonnement « je veux le meilleur modèle ouvert, donc le plus gros » se retourne : le meilleur rapport valeur/coût n’est jamais le plus gros modèle, c’est le plus petit qui passe le seuil dont on a besoin.

L’autre extrême : quand le modèle rentre dans le téléphone

Et si l’on pousse la logique jusqu’au bout ? Le 14 juillet, la même quinzaine, encore, la startup PrismML a publié Bonsai 27B, obtenu en compressant Qwen3.6 27B en poids 1 bit et ternaires. Deux variantes sous licence Apache 2.0 : une build de 3,9 Go qui tient sur un iPhone, et une de 5,9 Go pour laptop. Elles conservent respectivement ~90 % et ~95 % de la performance du modèle en pleine précision sur la suite maison de 15 benchmarks, tout en restant multimodales et capables d’appeler des outils, sur l’appareil, hors ligne.

Bonsai n’est pas un rival de K3 sur la capacité brute, c’est le dérivé compressé d’un modèle moyen, et sa rétention est inégale (les maths et le code tiennent mieux que l’instruction-following, le tool-use multi-étapes ou la vision). Mais il matérialise, mieux qu’aucun tableau de prix, le vrai axe de 2026. À un bout, K3 : 2,8 trillions de paramètres, un datacenter. À l’autre, Bonsai : 27 milliards, une poche. Et entre les deux, la zone réellement exploitable, Nemotron, Qwen Max, DeepSeek Flash, où se joue l’usage.

J’ai d’ailleurs commencé mes propres tests de Bonsai, précisément pour éprouver ce que l’on peut réellement faire d’un modèle qui tourne sur l’appareil : où il tient ses promesses, où sa rétention flanche, ce qu’il permet vraiment hors ligne. Ces essais feront l’objet d’un article dédié : non plus « combien de paramètres », mais « qu’est-ce que ça fait, concrètement, entre mes mains ».

Quand K3 a quand même du sens

Enterrer K3 serait malhonnête. Il garde une valeur réelle dans quelques cas précis. Pour les organisations qui possèdent déjà l’infrastructure data-center et veulent le plafond de qualité en interne, sans dépendance à une API, il est une option souveraine. Pour la recherche, c’est un objet d’étude majeur : KDA, Attention Residuals, MXFP4 natif, d’où l’intérêt de ce moteur en C, écrit précisément « pour comprendre l’architecture en l’implémentant ». Sur les tâches les plus dures, son plafond de performance peut rester devant. Et le simple fait qu’il soit ouvert tire tout l’écosystème vers le haut : quantisations, moteurs d’inférence, et une pression à la baisse sur les prix dont bénéficient, ironie, ses concurrents plus petits.

La vraie nouvelle de 2026

Le récit dominant reste celui du record : chaque mois, un modèle ouvert plus gros que le précédent. Mais pour quiconque doit réellement livrer un produit, la question n’est pas « peut-on faire tourner 2,8 trillions de paramètres ? », c’est « pourquoi le voudrait-on ? ». La frontière qui compte n’est plus la taille du modèle ; c’est le coût par million de tokens à performance donnée, et l’infrastructure minimale pour y accéder. Sur ce terrain-là, Kimi K3 n’est sans doute pas le modèle que la plupart d’entre nous utiliseront au quotidien.

Ce serait pourtant une erreur de le réduire à un mastodonte inutilisable. Ces très grands modèles ouverts jouent un rôle décisif, même pour ceux qui ne les feront jamais tourner : ils repoussent l’état de l’art dont tous les autres héritent. Les techniques que K3 met au point, Kimi Delta Attention, Attention Residuals, entraînement natif en 4 bits, deviennent demain le socle des modèles plus petits ; les meilleurs « compacts » d’aujourd’hui sont souvent des distillations ou des compressions des géants d’hier (Bonsai n’existe que parce que Qwen existe). Kimi K3 n’est donc pas le vainqueur de sa propre sortie au sens pratique, mais il fait progresser l’ensemble de l’écosystème open weight et open source, et c’est peut-être là sa contribution la plus durable. La course à la taille et la course à l’accessibilité ne s’opposent pas : la première alimente la seconde.

Note sur les sources et les chiffres

Chiffres arrêtés au 4 août 2026, recoupés sur au moins deux sources par donnée (OpenRouter, Artificial Analysis, pages officielles Moonshot / NVIDIA / Alibaba / PrismML, blogs vLLM et SGLang). Points à surveiller avant publication finale : le « minimum » matériel de K3 varie selon les sources (8 H200 en configuration serrée à 16 H200 confortables) ; les prix API promotionnels (notamment Qwen) sont volatils ; la longueur de sortie maximale de DeepSeek V4-Flash est donnée à 65 k tokens par OpenRouter, pas davantage ; les indices de performance proviennent de grilles différentes et méritent, pour la version finale, un tableau de benchmarks tête-à-tête sur une même échelle.

Références

Kimi K3

Poids officiels : huggingface.co/moonshotai/Kimi-K3
Preview d’inférence vLLM et cookbook SGLang
API et prix : openrouter.ai/moonshotai/kimi-k3

K3 en local (illustration)

Moteur C kimi-k3-in-c par Fareed Khan : github.com/FareedKhan-dev/kimi-k3-in-c
Discussion sur l’offload disque : huggingface.co/moonshotai/Kimi-K3/discussions/59
Support MLX et EXO cluster demandés : github.com/MoonshotAI/Kimi-K3/issues/5

Modèles alternatifs cités

Sur ce carnet, la ligne éditoriale continue

Kimi K3 : les poids sont libres, le compute ne l’est pas (encore) · l’article du jour de l’annonce, qui posait déjà la question du calcul comme prochain verrou. Cet article-ci en est le point d’étape à J+15.
La distillation, nouveau front de la guerre technologique sino-américaine · pourquoi les 80 % de start-up américaines qui vivent sur Qwen, DeepSeek et Kimi ne sont pas seulement un chiffre.
L’intelligence se loge dans la boucle · à modèle constant, la performance ne se joue plus dans les poids mais dans le harnais. Corollaire direct de cet article : préférer un modèle plus petit et mieux orchestré.
POSAIS 2026 : cap sur un modèle Frontier européen · la feuille de route européenne pour ne dépendre ni des hyperscalers américains ni des géants chinois.