Magazine LLM Opensource · 7 November 2026

Kimi K3.1 Pro, Qwen3.8-Max, Muse Spark Open : ce que la vague open-weight 2026 change vraiment pour ceux qui déploient

Le 16 juillet 2026, Moonshot AI dévoilait Kimi K3, un modèle de 2 800 milliards de paramètres. Trois mois plus tard, la lignée a muté : K3.1 Pro est en ligne, Qwen3.8-Max a ouvert ses poids début août, Meta a répliqué avec Muse Spark Open mi-octobre. Entre les annonces et les dépôts Hugging Face, une question que personne ne pose vraiment : une fois qu’on a téléchargé le fichier, qu’est-ce qu’on en fait ?

Le 16 juillet 2026, un modèle de 2 800 milliards de paramètres a fait vaciller les inscriptions

Il y a quelque chose de presque comique dans la séquence. Moonshot AI, startup pékinoise, annonce Kimi K3 le 16 juillet 2026. Le modèle est présenté comme « la plus grosse IA open source et gratuite jamais publiée » — un LLM open-weight de 2 800 milliards de paramètres. Quelques jours plus tard, la presse relaie que la plateforme suspend les nouvelles inscriptions, submergée par une ruée d’utilisateurs. Le 27 juillet, les poids complets, le rapport technique et les détails de licence sont publiés sur Hugging Face, dans un dépôt moonshotai/Kimi-K3. Forbes y voit, à juste titre, un signal de convergence vers l’open-weight plutôt qu’un simple coup marketing.

Voilà pour la chronologie. Maintenant, ce qu’on ne sait pas — et ce que trois mois de recul ont permis de trancher.

Car la situation a changé depuis l’annonce initiale. La lignée K3 s’est scindée : Moonshot a mis en ligne Kimi K3.1 Pro, présenté sur le site officiel comme une montée en gamme centrée sur le code et les tâches agentiques. Le dépôt de poids K3, lui, reste la référence pour qui veut self-hoster. Mais la fiche technique officielle complète — nombre de paramètres actifs, architecture d’attention exacte, nom précis de la licence, taille de contexte réellement exploitable — n’est toujours pas consolidée dans une source unique recoupée. Le chiffre de 2,8 T de paramètres totaux provient d’une source primaire (TechTarget), repris par plusieurs agrégateurs. La date du 27 juillet 2026 pour la publication des poids repose sur la même source, relayée par Axios. La tarification API — 0,30 $/million de tokens en cache, 3 $/M en entrée, 15 $/M en sortie — provient de deux sites tiers concordants, mais d’aucune page officielle Moonshot dans les extraits.

Ce n’est pas un détail méthodologique. C’est exactement le problème que pose la vague open-weight aux praticiens : l’écart entre le battage médiatique et la documentation vérifiable. Un modèle peut être « le plus gros jamais publié » et n’avoir, trois mois après sa sortie, aucune fiche technique recoupée. La question qui structure ce dossier n’est donc pas « Kimi K3 est-il bon ? » mais : que savons-nous vraiment de cette génération de modèles, et que signifie-t-elle pour ceux qui doivent les déployer en production ?

Kimi K3 : autopsie d’un modèle qu’on connaît surtout par ses titres

Démêlons ce qui est confirmé de ce qui relève du communiqué.

Ce qui tient. Kimi K3 est un modèle MoE open-weight de 2 800 milliards de paramètres totaux, développé par Moonshot AI (Pékin), annoncé le 16 juillet 2026, avec publication des poids le 27 juillet 2026 sur Hugging Face. Le contexte revendiqué atteint 1 million de tokens, avec vision native. Deux innovations d’attention sont citées par les agrégateurs : Kimi Delta Attention et Attention Residuals. La taille des poids sur disque serait d’environ 1,56 To — ce qui, en FP8, suggère plusieurs centaines de gigaoctets de VRAM, et en INT4 bien moins, mais aucun de ces calculs n’est explicité dans les sources.

Ce qui flotte. Le nombre de paramètres actifs. Le nombre d’experts. Le type de routing. La licence exacte — MIT ? Apache 2.0 ? Licence custom à clause d’usage ? On ne sait pas. La disponibilité sur ModelScope n’est même pas mentionnée. Et le chiffre de 2,8 T lui-même repose sur une source unique.

Pour mesurer ce qui change réellement, il faut regarder la lignée. Kimi K2, sorti le 11 juillet 2025, était un MoE de 1 T de paramètres totaux pour 32 B actifs, sous licence MIT modifiée — avec une clause d’attribution pour les produits dépassant 100 millions d’utilisateurs mensuels ou 20 M$ de revenus. Kimi K2 Thinking, sorti le 6 novembre 2025, conservait cette architecture 1 T/32 B actifs, la même licence MIT modifiée, et un contexte de 256 k. Entre K2 Thinking et K3, on passe donc d’un contexte de 256 k à 1 M revendiqué, et d’une taille de 1 T à 2,8 T. C’est un saut quantitatif majeur — mais sur les paramètres actifs, la donnée manque.

Cette distinction n’est pas académique. Open-weight n’est pas open source. L’accès aux poids n’efface ni les clauses de licence, ni les obligations de gouvernance. Un modèle dont on peut télécharger les fichiers mais dont la licence impose des restrictions commerciales, ou dont le tokenizer évolue sans compatibilité ascendante, reste un modèle sous contrainte. La vraie question pour une équipe n’est pas « puis-je télécharger ? » mais « puis-je maintenir, auditer et redéployer ce modèle dans trois ans ? »

DeepSeek, Qwen, GLM, Muse Spark : la vraie carte de la vague open-weight fin 2025-fin 2026

La convergence open-weight n’est pas un slogan. C’est une séquence de publications datées, sous licences permissives, avec des tailles et des contextes qui progressent par paliers. Reconstituons-la, en intégrant les sorties les plus récentes.

Ce tableau raconte une cadence. En dix-huit mois, cinq laboratoires — Moonshot, DeepSeek, Alibaba (Qwen), Zhipu/Z.ai (GLM), Tencent — plus un acteur américain (Meta) et un européen (Aleph Alpha), ont publié des modèles frontière sous licences permissives, avec des tailles qui grimpent et des contextes qui doublent. DeepSeek V3.2-Exp a introduit l’attention sparse DSA fin septembre 2025. Qwen3 a couvert toute la gamme sous Apache 2.0. GLM-4.6 est passé sous MIT. Puis l’été 2026 a tout accéléré : Qwen3.8-Max a ouvert les poids de son modèle phare le 3 août, Tencent a suivi avec Hy4 Preview le 28 août, Meta a répliqué mi-octobre avec Muse Spark Open — décrit par Meta Research comme « le modèle open-weight américain le plus capable à ce jour », avec un contexte de 1 M et un positionnement explicite sur le code et l’agentique.

Attention aux modèles fantômes. DeepSeek V4 n’était pas confirmé comme sorti au moment de la rédaction initiale — même si des sources plus récentes évoquent un « DeepSeek V4.1 Flash » en septembre 2026, avec 552 milliards de paramètres MoE et une architecture Causal Encoder Decoder. GLM-5 n’est pas confirmé non plus. Et il existe une confusion possible entre Kimi K2 Thinking, Kimi K3 et Kimi K3.1 Pro — confusion que la proximité des noms et l’absence de fiche technique officielle consolidée ne font qu’aggraver.

Le point pour un praticien : cette vague n’est pas un bloc monolithique. Chaque laboratoire a sa cadence, sa licence, son architecture. Choisir « un modèle chinois » n’a aucun sens. Choisir ce modèle, sous cette licence, avec ce contexte réel, oui.

Ce que les classements disent vraiment — et ce qu’ils cachent

Les benchmarks qui font foi fin 2025 sont connus. Décortiquons-les, en gardant à l’esprit qu’ils datent d’avant K3 — et que les classements 2026, eux, sont devenus un genre à part entière.

LMArena : Kimi K2 Thinking a occupé la 1re place parmi les modèles open-weight en novembre 2025. C’est un résultat tiers, donc solide — mais il porte sur K2 Thinking, pas sur K3 ni K3.1 Pro.

Artificial Analysis Intelligence Index (fin 2025) : Kimi K2 Thinking ~67, GLM-4.6 ~62, DeepSeek V3.2 ~57-60, Qwen3-Max ~60+. Un écart de 5 à 10 points qui, en pratique, se traduit par des différences de fiabilité sur les tâches longues.

SWE-bench Verified : Kimi K2 Thinking ~71,3 %, GLM-4.6 ~68 %, Qwen3-Coder ~67-69 %, DeepSeek V3.2 ~67-73 % selon les variantes. Notez l’amplitude de la fourchette DeepSeek : six points d’écart selon la variante évaluée. C’est énorme.

Pourquoi ces chiffres varient-ils autant ? Parce que le harness d’évaluation change le résultat. Un modèle évalué avec un scaffold agentique optimisé pour lui ne produit pas le même score qu’avec un harness générique. Les scores auto-déclarés par Moonshot sur HLE et BrowseComp — où K2 Thinking aurait dépassé GPT-5 — doivent être lus avec prudence : ce sont des chiffres revendiqués, partiellement corroborés par LMArena, mais pas reproduits indépendamment sur l’ensemble du spectre.

Un phénomène plus récent complique encore la lecture : la prolifération des leaderboards. Comme le documente notre dossier « Leaderboards open-weight 2026 : 97 modèles classés, mais que mesurent-ils vraiment ? », « 97 modèles classés » est devenu un argument de vente en soi, alors que deux classements peuvent diverger sur le même modèle selon l’agrégation (moyenne simple, Elo, win-rate), le protocole (zero-shot, CoT, few-shot, température) et la contamination des jeux de test publics. Sur un modèle comme Kolibri-1, les scores Tau2-Bench (76,7 % Airline, 69,9 % Retail, 94,7 % Telecom) et Tau3-Bench Banking (38,1 %) racontent une histoire très différente selon la tâche — et c’est précisément le bon niveau de granularité.

La conclusion pour un praticien est simple, et elle est libératrice : « quel modèle est le meilleur » est une question mal posée. La bonne question est : « quel modèle, évalué sur mon harness, avec mes prompts, sur mes tâches, donne un résultat acceptable à un coût soutenable ? » Un écart de 4 points sur SWE-bench Verified ne dit rien sur votre cas d’usage. Il dit seulement que les modèles sont proches.

Fine-tuner et servir en local : la pile réelle, du GGUF au vLLM

Passons à l’atelier. Que signifie concrètement déployer un modèle de cette famille ?

La quantization d’abord. Les options sont connues : FP8, INT4, AWQ, GGUF, et désormais NVFP4 côté NVIDIA. Le compromis qualité/coût est documenté pour AWQ : en INT4, AWQ réduit la pénalité de perplexité par rapport à GPTQ d’environ 74 % (de 4,57 à 1,17). C’est significatif — mais ça reste une pénalité, pas une absence de dégradation. Pour un modèle de 2,8 T de paramètres totaux, la question du format n’est pas cosmétique : elle détermine si vous tenez sur un nœud ou sur huit. Muse Spark Open illustre le dilemme : 816 B totaux, 42 B actifs, et un choix explicite entre BF16 et NVFP4 pour le déploiement.

Le serving ensuite. vLLM, SGLang, llama.cpp. Pour un modèle de cette taille, llama.cpp sur un laptop est une plaisanterie — le déploiement local complet est irréaliste pour un particulier, et l’API reste recommandée pour la plupart des usages. vLLM et SGLang sont les options sérieuses pour du serving multi-GPU. Deux évolutions récentes comptent ici : d’une part, Google a publié le 20 octobre 2026 des versions TPU de vLLM et SGLang, ce qui élargit le choix matériel au-delà du GPU ; d’autre part, llm-d 1.0 a été présenté le 20 octobre 2026 à la PyTorch Conference North America — une pile d’inférence distribuée native Kubernetes, annoncée par IBM Research, qui vise précisément le serving à grande échelle de modèles ouverts. Pour un modèle de 2,8 T, ce n’est plus un détail : c’est la différence entre un script et une plateforme.

Le harness d’évaluation. C’est le point aveugle. AutoGen, par exemple, surconsomme les tokens de 3 à 5 fois par rapport à un harness optimisé. Sur un modèle à contexte étendu, cette surconsommation se traduit directement en coût. Le choix du harness n’est pas un détail d’ingénierie : c’est un poste de dépense.

Les limites documentées. Langues supportées : non précisé pour K3. Tool-calling : non précisé pour K3 — mais documenté pour Kolibri-1 (BFCL v4 à 61,4 %), ce qui donne un point de comparaison utile. Multimodalité : vision native revendiquée pour K3. Contexte effectif : 1 M revendiqué, mais quelle fenêtre utile en pratique ? Kolibri-1 fournit un contre-exemple instructif : 1 048 576 tokens maximum, mais ~262 144 tokens recommandés en production. Un contexte de 1 M tokens ne signifie pas qu’un modèle reste performant sur 1 M tokens. C’est même rarement le cas.

Le vrai coût n’est pas le GPU. C’est l’ingénierie de validation : construire un harness interne, tester le modèle sur vos tâches, mesurer la dégradation après quantization, vérifier le tool-calling, valider les langues. Cette phase est invisible dans les benchmarks publics et pourtant décisive.

H100, H200, B200 : le calcul économique du self-host (et son angle mort)

Voici la question que personne ne tranche publiquement : à partir de quel volume le self-host d’une pile open-weight devient-il rentable face aux API propriétaires ?

La réponse honnête : on ne sait pas, et les sources disponibles ne permettent pas de le calculer. Aucun chiffre sur le coût réel de self-host — prix GPU H100/H200/B200 en location cloud ou à l’achat, électricité, coût par million de tokens en self-host — n’apparaît dans la matière documentaire. Aucun seuil de rentabilité. Aucun benchmark économique public spécifique à cette génération de modèles. Ce que l’on sait en revanche, c’est que la vague d’octobre 2026 s’est heurtée de plein fouet à un « mur de mémoire » : comme le résume notre confrère the-agent-report.com, trois modèles de 816 B, 560 B et 120 B ont été publiés le même jour, et la contrainte n’est plus la disponibilité des poids mais la VRAM pour les faire tourner.

Ce qu’on a, en revanche, c’est la tarification API de Kimi K3 : 0,30 $/M en cache, 3 $/M en entrée, 15 $/M en sortie. Ces chiffres proviennent de deux agrégateurs concordants, mais non confirmés par une source Moonshot officielle. À titre de repère, un modèle comme Jev — décisionnel, pas génératif — est facturé 0,22 $ pour 1 000 documents contre 1,31 à 3,08 $ pour un LLM généraliste sur la même tâche. Ce n’est pas une comparaison directe, mais ça donne un ordre de grandeur des écarts. Autre repère de marché : Inception a lancé Mercury 3 le 19 octobre 2026, un modèle à diffusion facturé 0,10 $ par million de tokens d’entrée — un tarif qui redéfinit les attentes côté prix, même s’il ne s’agit pas d’un open-weight.

La taille des poids (1,56 To pour K3) donne un indice brut : en FP8, on parle de plusieurs centaines de gigaoctets de VRAM, ce qui implique un nœud multi-GPU. En INT4, nettement moins — mais avec la dégradation associée. Le calcul économique dépend donc entièrement du format de quantization retenu et du débit obtenu, deux variables qu’aucune source fournie ne documente pour K3. Pour Muse Spark Open, Meta revendique un usage sur Apple M5 Ultra Mac Studios — ce qui, pour un 816 B, suppose une quantization agressive et un débit qu’il reste à mesurer.

Ce que trois mois de recul changent : K3.1 Pro, la riposte et la vraie question

La chronologie de juillet ne suffit plus à décrire l’état de l’art. Trois mois après l’annonce de K3, le paysage s’est réorganisé autour de trois dynamiques.

Première dynamique : la lignée plutôt que le modèle unique. Moonshot ne vend plus un modèle, mais une famille. K3.1 Pro, sur kimi.com, est positionné sur le code et les tâches agentiques — avec un écosystème produit qui déborde largement du seul LLM : Kimi Work pour les fichiers locaux et l’automatisation navigateur, Agent Swarm pour les tâches complexes, Kimi Code pour le terminal et l’IDE, une extension navigateur. C’est un changement de nature : on n’évalue plus un checkpoint, on évalue une pile. Et cette pile, comme le montre notre dossier sur Gemini 3.8 Flash, impose de repenser son pipeline pour un monde à releases bi-hebdomadaires — pinning de version, routage, fallback.

Deuxième dynamique : la riposte américaine et européenne. Qwen3.8-Max (2,4 T totaux, 95 B actifs, poids en ligne une semaine après l’annonce du 3 août) a montré qu’Alibaba pouvait ouvrir son modèle phare. Tencent Hy4 Preview (770 B / 49 B actifs, Apache 2.0, contexte > 1 M) a prouvé qu’un acteur majeur pouvait le faire sous licence réellement permissive. Meta Muse Spark Open (816 B / 42 B actifs, 1 M de contexte) a déplacé la bataille sur le sol américain. Aleph Alpha Kolibri-1 (78,1 B / 3,46 B actifs, Apache 2.0, contexte max 1 048 576 tokens, recommandé ~262 k) a rappelé qu’un modèle européen compact et bien documenté pouvait être plus déployable qu’un titan. La leçon : la taille n’est plus le seul axe de compétition ; la documentation et la licence le sont devenus.

Troisième dynamique : le mur de mémoire. C’est le fil rouge de tous les dossiers de ce magazine depuis octobre. Un modèle de 2,8 T ne se déploie pas ; il s’API-ise ou il se quantize sur un cluster. Un 78 B sous Apache 2.0, si. La question n’est plus « quel est le plus gros modèle ouvert ? » mais « quel est le plus gros modèle ouvert que je peux réellement servir, maintenir et auditer ? » Pour beaucoup d’équipes, la réponse se situe désormais entre 70 et 120 milliards de paramètres totaux, avec un ratio d’activation faible — pas à 2,8 T.

Reste la question de fond, celle qui n’a pas bougé depuis juillet : que savons-nous vraiment de Kimi K3 ? Trois mois après, la fiche technique consolidée manque toujours. Ce n’est pas anecdotique. C’est le symptôme d’un écosystème où la vitesse de publication dépasse la vitesse de documentation — et où le praticien doit apprendre à travailler avec des modèles dont il ne connaît pas entièrement les paramètres. La compétence clé de 2026 n’est pas de choisir le bon modèle : c’est de construire les garde-fous qui permettent de l’utiliser malgré l’incertitude.

Sources

• Kimi AI — site officiel (K3.1 Pro)
• Kimi AI — produits et téléchargements
• Forbes — Why Kimi K3 Signals A Convergence Toward Open-Weight Models (27 juillet 2026)
• Meta Research — Introducing Muse Spark Open
• the-agent-report.com — 816B, 560B, 120B en un jour : la vague open-weight se heurte désormais à un mur de mémoire (16 octobre 2026)
• Unite.ai — llm-d 1.0 Debuts at PyTorch Conference with Production Inference Stack (20 octobre 2026)
• Note.com — vLLM et SGLang passent au TPU (21 octobre 2026)
• Unite.ai — Inception Releases Mercury 3, Its Flagship Diffusion LLM (19 octobre 2026)
• Hugging Face — How to Use Muse Spark Open: A Practical Guide (16 octobre 2026)
• Dossiers internes du magazine : « Kimi K3.1 Pro, Qwen3.8-Max, Muse Spark Open », « Qwen3.8-Max : 2,4 trillions de paramètres », « Tencent Hy4 Preview », « Leaderboards open-weight 2026 », « Gemini 3.8 Flash ».

Article recherché et rédigé automatiquement · Magazine Electrosens