---

Deux laboratoires, deux trajectoires : comment Moonshot et DeepSeek ont sculpté le duel de l’automne 2026

Pour comprendre pourquoi Kimi K3 et DeepSeek V4 Pro s’affrontent aujourd’hui au sommet des open weights, il faut remonter la chronologie — en acceptant d’emblée une asymétrie documentaire qui dit beaucoup de la manière dont ces deux laboratoires communiquent.

Moonshot AI a été fondée en mars 2023 en Chine, et son chatbot Kimi a été lancé en octobre 2023 après une phase de bêta fermée. La trajectoire est ensuite jalonnée de versions que l’on connaît surtout par des sources tierces : Kimi K2, un modèle à 1 000 milliards de paramètres, publié en juillet 2025 ; Kimi K2.5 en janvier 2026 ; Kimi K2.6 en avril 2026. Sur ce dernier, la page officielle de Moonshot décrit un modèle open source avec des capacités de codage présentées comme state-of-the-art, d’exécution longue et d’essaim d’agents — un positionnement agentique assumé. Puis vient Kimi K3, daté du 16 juillet 2026, que Wikipédia présente comme le plus grand modèle à poids ouverts avec 2 800 milliards de paramètres. Les pages officielles kimi.com et kimi.ai/agent confirment l’existence et la disponibilité de K3, ainsi que ses capacités multimodales (image et vidéo) et son orientation « Agentic Coding & Knowledge Work », sans pour autant publier dans les extraits disponibles la fiche technique détaillée qu’on attendrait d’un modèle de cette envergure.

Le contraste avec DeepSeek est saisissant. De l’aveu même de la matière collectée, aucune information sur DeepSeek V4 Pro n’apparaît dans les sources fournies : ni date de sortie précise, ni historique des versions intermédiaires entre 2024 et 2026, ni communiqué, ni paper. Le seul élément disponible est un chiffre de 1,6 billion de paramètres attribué à V4 Pro, provenant du titre d’un article tiers — sans spécification architecturale vérifiable. Autrement dit, l’un des deux protagonistes de ce « duel » est, dans notre corpus, presque entièrement documenté par ouï-dire.

Cette asymétrie n’est pas anecdotique. Elle signifie que toute comparaison sérieuse doit aujourd’hui distinguer deux registres : ce qui est affirmé (parfois par une seule source secondaire) et ce qui est vérifiable. Et elle invite à la prudence sur les récits trop propres d’un « choc des titans » : l’un des deux camps communique, l’autre reste opaque.

Deux événements périphériques méritent d’être signalés, avec leurs réserves. D’abord, des modèles Kimi auraient servi de base ou de support de post-entraînement à des modèles américains, notamment Inkling de Thinking Machines Lab et Composer 2 de Cursor — allégation issue d’une source unique, non recoupée. Ensuite, en septembre 2026, Anthropic aurait accusé Moonshot d’avoir secrètement routé des requêtes Kimi vers ses modèles Claude et distillé Claude via ces réponses. Là encore : une seule source, aucun communiqué officiel cité. Ces deux épisodes, s’ils se confirmaient, diraient quelque chose d’important sur la porosité des écosystèmes et la circulation des capacités entre laboratoires — mais ils ne peuvent pas, en l’état, servir de fondement à une analyse.

---

Architecture : ce que les chiffres disent vraiment (et ce qu’ils cachent)

C’est ici que la prudence doit être maximale, car c’est précisément le terrain où les chiffres circulent le plus vite et se vérifient le moins.

Pour Kimi K3, le chiffre qui circule est celui de 2 800 milliards de paramètres totaux, présenté comme un record pour un modèle à poids ouverts. Il provient de Wikipédia, sans qu’aucune source officielle Moonshot citée dans notre corpus ne le corrobore. Pour DeepSeek V4 Pro, le chiffre avancé est de 1,6 billion de paramètres, issu d’un titre d’article tiers. Aucun des deux ne s’accompagne des métriques qui comptent réellement pour un praticien : paramètres actifs (l’information décisive pour un modèle sparse), type de MoE, nombre d’experts, dimension d’attention, mécanisme d’attention (MLA, attention linéaire, hybride), contexte natif, tokenizer, modalités réellement supportées en entrée et en sortie.

Cette absence n’est pas un détail cosmétique. Un modèle à 2,8 T de paramètres totaux avec, disons, quelques dizaines de milliards d’actifs par token, et un modèle à 1,6 T avec une proportion d’actifs différente, n’ont ni la même empreinte mémoire, ni le même débit, ni le même coût d’inférence — même si leurs scores de benchmark sont proches. La taille totale est un argument de communication ; la taille active est un paramètre d’ingénierie. Confondre les deux est l’erreur la plus fréquente dans les comparatifs grand public.

Ce qu’on peut dire de solide, en revanche, concerne les capacités fonctionnelles de K3, mieux documentées : entrées multimodales image et vidéo, fonctionnalité dite « Swarm » mobilisant des centaines de sous-agents (terme absent des extraits officiels, mais cohérent avec le positionnement agentique de la page kimi.ai/agent), et disponibilité via le web, une API et Kimi Code, un agent en ligne de commande. Ces éléments dessinent un modèle conçu pour l’orchestration agentique plus que pour la génération de texte pure — un choix architectural autant qu’un choix produit.

Pour DeepSeek V4 Pro, on ne peut rien affirmer sur l’architecture. Le titre d’article tiers évoque des « limitations » sans chiffres précis. Toute comparaison architecturale sérieuse entre les deux modèles est donc, à ce stade, impossible à mener rigoureusement. Ce n’est pas une dérobure : c’est le constat central de cette section, et il devrait tempérer l’enthousiasme des comparatifs qui circulent.

Un mot sur les implications pratiques de cette incertitude. Si vous dimensionnez votre infrastructure sur la base du chiffre de 2,8 T pour K3, vous prenez un risque : ce chiffre peut être inexact, obsolète, ou désigner une variante différente de celle que vous déploierez. La bonne pratique, face à un modèle à poids ouverts dont la fiche technique n’est pas publiée, est de mesurer soi-même : charger les poids, observer l’occupation VRAM réelle, benchmarker le débit sur votre matériel, et ne se fier aux chiffres publics que comme à des ordres de grandeur.

---

Licences : le vrai prix de l’open weights

C’est le point où le mot « open » mérite d’être manié avec des pincettes. « Open weights » ne veut pas dire « open source », et encore moins « gratuit pour un usage commercial à grande échelle ».

Pour Kimi K3, la licence est décrite comme personnalisée, avec une clause de partage de revenus pouvant atteindre 30 % pour les fournisseurs d’inférence générant plus de 20 millions de dollars de revenus annuels. Ce détail — précis dans ses chiffres — provient d’une source tierce unique (Wikipédia citant une référence non fournie dans notre corpus), sans accès au texte intégral de la licence. Il faut donc le traiter comme une indication sérieuse mais non confirmée. S’il se vérifie, il change radicalement l’équation économique pour tout acteur dont le modèle d’affaires repose sur la revente d’inférence : 30 % de revenus partagés, c’est un ordre de grandeur qui évoque davantage un accord de licence commerciale qu’une licence open source classique.

Pour DeepSeek V4 Pro, la situation est plus simple à résumer : aucune information sur sa licence n’apparaît dans les sources disponibles. Ni texte intégral, ni clauses restrictives, ni seuils de revenus, ni obligations d’attribution, ni restrictions géographiques. On ne peut donc pas comparer les deux licences — seulement constater que l’une est partiellement documentée et l’autre pas du tout.

La comparaison avec les licences établies de l’écosystème (Llama, Qwen, Mistral) n’est pas non plus possible à partir de notre corpus, qui ne contient aucune analyse de ces textes. On peut simplement rappeler, sans avancer de chiffre, que ces licences ont historiquement combiné des seuils d’usage (nombre d’utilisateurs mensuels, chiffre d’affaires), des obligations d’attribution et, pour certaines, des restrictions territoriales. La clause de partage de revenus attribuée à K3 s’inscrirait, si elle est confirmée, dans une tendance déjà perceptible : la monétisation de l’usage à grande échelle des poids ouverts.

Aucun retour d’expérience de juristes ou de DSI n’est disponible dans notre matière pour documenter les pièges réels — conformité, audit, réutilisation des poids, obligations de redistribution des dérivés. C’est une lacune importante, car c’est précisément là que les ennuis arrivent en production, souvent des mois après le déploiement initial. Un conseil de bon sens, en attendant : ne déployez jamais un modèle à licence personnalisée sans avoir fait relire le texte intégral par votre service juridique, et documentez la version exacte des poids utilisée, car les licences évoluent entre versions.

---

Qualité par famille de tâches : là où les benchmarks mentent

C’est la section la plus difficile à écrire honnêtement, parce que c’est celle où le lecteur attend des chiffres — et où notre corpus en manque cruellement.

Ce qu’on a : aucune donnée de benchmark comparatif direct entre Kimi K3 et DeepSeek V4 Pro. Aucun score MMLU-Pro, GPQA, SWE-bench Verified, AIME, LiveCodeBench ou tau-bench attribué à l’un ou l’autre dans les sources fournies. Aucune évaluation indépendante (LMArena, Artificial Analysis, Vals AI, SEAL, HELM) les concernant.

Ce qu’on peut dire malgré tout : les deux modèles sont positionnés par leurs éditeurs sur des créneaux convergents — raisonnement, code, agents, long contexte. Kimi K2.6 est explicitement décrit par Moonshot comme doté de capacités de codage SOTA, d’exécution longue et d’essaim d’agents. K3 pousse la logique plus loin avec le multimodal (image, vidéo) et une architecture orientée orchestration de sous-agents. Pour DeepSeek V4 Pro, le titre d’article tiers évoque des limitations sans qu’on sache lesquelles.

Cette absence de chiffres comparatifs n’est pas propre à notre corpus : elle reflète une réalité du terrain. Les benchmarks publics sont de moins en moins prédictifs de la performance en usage réel, pour plusieurs raisons bien documentées :

1. La contamination des jeux de test. Les benchmarks les plus cités (MMLU, HumanEval, GSM8K) circulent dans les données d’entraînement depuis des années. Un score élevé peut refléter une mémorisation, pas une compétence.
2. L’écart entre benchmark et tâche réelle. Un modèle excellent sur SWE-bench Verified peut se révéler médiocre sur votre base de code propriétaire, avec vos conventions, vos dépendances et votre dette technique.
3. Le biais de sélection des tâches. Les benchmarks mesurent ce qui est facile à mesurer — pas ce qui compte pour votre produit (latence perçue, robustesse aux entrées malformées, respect des contraintes de format).
4. L’effet de harnais. Pour les tâches agentiques, la performance dépend autant du modèle que du harnais qui l’orchestre. Un même modèle peut afficher des écarts considérables selon le framework utilisé.

Dans ce contexte, la recommandation pratique est claire : ne choisissez pas entre K3 et V4 Pro sur la base de scores publiés. Construisez un jeu d’évaluation interne représentatif de vos tâches réelles — quelques dizaines à quelques centaines d’exemples suffisent — et faites tourner les deux modèles dessus. C’est la seule mesure qui vaille pour votre cas d’usage. Et documentez vos résultats : vous serez mieux informé que la plupart des comparatifs publiés.

---

Serving en production : mémoire, débit et le mur de l’infra

Ici, on entre dans le concret — et dans les ordres de grandeur, faute de chiffres précis.

Un modèle à 2,8 T de paramètres totaux, même sparse, ne se déploie pas sur un seul GPU. En précision 16 bits, 2,8 T de paramètres représentent environ 5,6 To de poids — bien au-delà de la VRAM de n’importe quelle carte unique. Même en quantification 4 bits, on parle d’environ 1,4 To, ce qui nécessite déjà un nœud multi-GPU conséquent. Pour DeepSeek V4 Pro à 1,6 T, les ordres de grandeur sont inférieurs mais restent dans la même catégorie : plusieurs centaines de Go en 4 bits.

Ces contraintes ont des conséquences directes sur le choix des outils. vLLM et SGLang sont les deux serveurs d’inférence de référence pour les modèles MoE à poids ouverts, avec des optimisations spécifiques (paged attention, continuous batching, parallélisme tensoriel et expert). Le choix entre les deux dépend souvent moins du modèle que de votre familiarité avec l’un ou l’autre et des fonctionnalités dont vous avez besoin (support du tool-calling, du multimodal, du préfixe caching).

Les leviers d’optimisation sont bien connus :

• Quantification : 8 bits (peu de perte), 4 bits (compromis courant), formats spécialisés (AWQ, GPTQ). À titre de repère, AWQ réduit la pénalité de perplexité en INT4 d’environ 74 % par rapport à GPTQ (de 4,57 à 1,17) — un ordre de grandeur qui montre que le choix du schéma de quantification compte autant que le choix du modèle.
• Parallélisme : tensor parallelism (répartir une couche sur plusieurs GPU) et expert parallelism (répartir les experts d’un MoE), souvent combinés.
• Offloading : déporter une partie des poids vers la RAM CPU ou le stockage, au prix d’une latence accrue. Utile pour les modèles très volumineux sur des nœuds modestes, mais rarement viable en production à fort trafic.

Faute de mesures publiées dans notre corpus, on ne peut pas donner de chiffres de latence ou de débit pour K3 et V4 Pro. La règle empirique reste valable : mesurez sur votre matériel, avec votre charge, votre longueur de contexte et votre taux de concurrence. Les chiffres de débit publiés par les éditeurs sont presque toujours obtenus dans des conditions optimales (batch important, contexte court, matériel haut de gamme) rarement représentatives d’un usage réel.

Un point souvent négligé : l’impact de la quantification sur la qualité n’est pas uniforme selon les tâches. Les tâches de génération créative tolèrent bien une quantification agressive ; les tâches de raisonnement mathématique ou de code, beaucoup moins. Si votre cas d’usage est exigeant, prévoyez de tester plusieurs niveaux de quantification et de mesurer la dégradation sur votre propre jeu d’évaluation.

---

Coût réel par million de tokens : self-host vs API

C’est la question qui décide, en pratique, de l’architecture d’un produit. Et c’est aussi celle où les raccourcis abondent.

Le coût API est facile à lire : les deux modèles sont accessibles via API (K3 via kimi.com et son API, V4 Pro via l’API DeepSeek), avec des tarifs à la consommation. L’avantage est la prévisibilité : pas de capex, pas d’ingénierie d’infrastructure, mise à l’échelle instantanée. L’inconvénient est le coût marginal qui ne baisse jamais, et la dépendance à un fournisseur — avec les risques de changement de tarif, de dépréciation de modèle ou de restriction d’accès.

Le coût self-host est plus complexe. Il faut additionner :

• Le capex matériel : pour un modèle de la classe de K3, on parle de nœuds multi-GPU haut de gamme, dont le coût se compte en dizaines de milliers d’euros par nœud, souvent plusieurs nœuds pour la redondance.
• L’opex : électricité, refroidissement, bande passante, mais surtout l’ingénierie — c’est le poste le plus sous-estimé. Faire tourner un modèle MoE de cette taille en production, avec du monitoring, du scaling, des mises à jour et de l’astreinte, mobilise une équipe spécialisée.
• La maintenance : les poids évoluent, les bibliothèques d’inférence aussi (vLLM, SGLang), et chaque mise à jour est un risque de régression.

Le seuil de bascule dépend de votre volume. En dessous d’un certain trafic, l’API est presque toujours moins chère. Au-delà, le self-host devient rentable — mais le point d’équilibre dépend fortement de votre capacité à mutualiser l’infrastructure sur plusieurs usages et de votre coût d’ingénierie interne. Il n’existe pas de chiffre universel.

L’effet de la licence complique encore l’équation. Si la clause de partage de revenus attribuée à K3 (jusqu’à 30 % au-delà de 20 M$ de revenus annuels pour les fournisseurs d’inférence) se confirme, elle pèse directement sur le modèle économique des acteurs qui revendent de l’inférence K3. Pour un produit qui consomme le modèle en interne, l’impact est différent — mais la clause mérite d’être lue attentivement. Pour V4 Pro, en l’absence d’information sur la licence, on ne peut rien dire.

Modèles de coût par profil (qualitatifs, faute de chiffres précis) :

Profil	Volume typique	Recommandation probable	Raison
Startup	Faible à modéré	API	Capex et ingénierie prohibitifs ; flexibilité maximale
Scale-up	Modéré à élevé	Hybride (API pour le pic, self-host pour la base)	Optimise le coût marginal sans perdre l’élasticité
Grand compte	Élevé et stable	Self-host	Amortissement du capex, contrôle des données, souveraineté
Équipe recherche	Variable	Self-host sur cluster partagé	Besoin de fine-tuning et d’expérimentation sur les poids

---

Fine-tuning et quantization : l’écosystème qui fait la différence

Un modèle, même excellent, ne vaut que par l’écosystème qui l’entoure. Sur ce plan, la différence entre les deux camps est nette — mais pas nécessairement dans le sens qu’on attend.

Pour Kimi K3, l’écosystème semble plus mûr : publication de poids, disponibilité via Hugging Face (implicite pour un modèle à poids ouverts), outillage officiel (Kimi Code, agent en ligne de commande), et une lignée de versions (K2, K2.5, K2.6, K3) qui a permis à la communauté de construire de l’expérience. Les méthodes classiques s’appliquent : LoRA, QLoRA, quantification 4/8 bits, avec des frameworks comme Axolotl ou Unsloth. La question ouverte est la faisabilité du fine-tuning à cette échelle : adapter un modèle de 2,8 T de paramètres, même en LoRA, reste une opération lourde, réservée aux équipes disposant d’infrastructure sérieuse.

Pour DeepSeek V4 Pro, l’absence d’information sur les poids, la licence et l’écosystème rend toute évaluation impossible. On ne sait pas si les poids sont réellement disponibles, sous quelles conditions, ni avec quels outils. C’est un point bloquant pour toute équipe qui envisage du fine-tuning.

Au-delà des deux modèles, l’écosystème open weights de l’automne 2026 est riche et concurrentiel. Mistral a dévoilé Mistral Large 4 (surnommé « Le Chonk ») le 6 octobre 2026, un modèle à plus de 1 000 milliards de paramètres dont 49 milliards activés par réponse, avec des poids prévus pour le 27 octobre 2026 — un positionnement explicite de « meilleur modèle à poids ouverts hors de Chine ». Reflection AI a présenté Beam le 5 octobre 2026, un MoE sparse de 501 milliards de paramètres totaux et 23 milliards actifs, orienté code et raisonnement, avec des poids attendus plus tard dans le mois. Cloudflare a publié Clef (27B) et Clef-flash (9B) sous Apache 2.0 le 3 octobre 2026. Autrement dit, le duel K3 vs V4 Pro se joue dans un écosystème bien plus peuplé qu’il n’y paraît — et pour beaucoup d’équipes, un modèle plus petit, mieux outillé et sous licence permissive sera un meilleur choix qu’un géant difficile à déployer.

---

Recommandations segmentées : quel modèle pour quel profil

Plutôt qu’un vainqueur unique — qui n’aurait pas de sens vu les lacunes documentaires — voici des recommandations par profil, avec leurs compromis assumés.

Startup à budget serré. L’API est votre amie. Consommez K3 ou V4 Pro via API, sans vous soucier de l’infrastructure. Privilégiez le modèle dont l’API est la plus stable et la mieux documentée pour votre cas d’usage, et gardez une porte de sortie (abstraction de l’appel modèle) pour changer de fournisseur si les tarifs ou les conditions évoluent. Ne construisez pas votre produit sur un modèle dont la licence n’est pas claire — vous le regretteriez au moment de lever des fonds ou de signer un gros client.

Scale-up en croissance. Approche hybride : self-host pour la charge de base, API pour les pics. Cela suppose une équipe d’ingénierie capable de faire tourner vLLM ou SGLang en production. C’est le profil pour lequel le choix entre K3 et V4 Pro a le plus d’impact — mais aussi celui pour lequel la mesure interne est la plus rentable. Investissez dans un harnais d’évaluation maison avant d’investir dans du matériel.

Équipe de recherche. Le critère décisif est la disponibilité réelle des poids et la liberté de fine-tuning. Sur ce plan, K3 est mieux documenté (poids publiés, lignée de versions, outillage), tandis que V4 Pro reste une boîte noire dans notre corpus. Si vous avez besoin de modifier le modèle, d’analyser ses activations ou de le distiller, K3 est aujourd’hui le choix le plus praticable — sous réserve de vérifier les termes exacts de sa licence. Si vous avez besoin d’un modèle plus petit et plus maniable, regardez du côté de Beam (501B/23B actifs) ou de Clef (Apache 2.0).

Produit agentique. C’est le terrain de jeu revendiqué de K3 : multimodal (image, vidéo), orchestration de sous-agents, agent en ligne de commande. Si votre produit repose sur le tool-calling, l’exécution longue et l’interaction multimodale, K3 coche les cases sur le papier. Mais attention : la performance agentique dépend énormément du harnais, et les benchmarks publics sont peu prédictifs. Testez, mesurez, itérez. Et gardez à l’esprit que la surface d’attaque des agents est un sujet de sécurité à part entière — les vulnérabilités de type exécution de commandes arbitraires dans les harnais agentiques sont documentées et exploitées.

Grand compte avec exigences de souveraineté. Le self-host s’impose, mais le choix du modèle dépend de vos contraintes géographiques et réglementaires. Un modèle européen comme Mistral Large 4, entraîné en Europe et positionné sur la souveraineté, peut être préférable à un modèle chinois — indépendamment des performances brutes. C’est un arbitrage politique autant que technique, et il n’a pas de réponse universelle.

---

Ce que ce duel change pour l’écosystème open weights (et ce qui vient ensuite)

Au-delà du match K3 vs V4 Pro, l’automne 2026 dessine une dynamique plus large, et probablement plus importante que le duel lui-même.

Première dynamique : la course à l’échelle. K3 à 2,8 T (chiffre à confirmer), Qwen3.8-Max à 2,4 billions de paramètres dévoilé le 3 août 2026, Mistral Large 4 à plus de 1 000 milliards dont 49 actifs, Beam à 501 milliards dont 23 actifs. La taille totale des modèles open weights a franchi un cap symbolique, mais les architectures divergent : certains misent sur des modèles massifs à faible proportion d’actifs, d’autres sur des modèles plus compacts. Le débat se déplace de « qui a le plus de paramètres » à « qui a le meilleur rapport performance/coût d’inférence ». C’est une maturation bienvenue.

Deuxième dynamique : la pression sur les licences. La clause de partage de revenus attribuée à K3, si elle se confirme, marque une inflexion : les laboratoires cherchent à monétiser l’usage à grande échelle de leurs poids ouverts. Cela pourrait pousser une partie de l’écosystème vers des modèles sous licences plus permissives (Apache 2.0, MIT) — comme Clef de Cloudflare — ou vers des modèles plus petits, moins coûteux à servir et plus faciles à gouverner.

Troisième dynamique : la standardisation des benchmarks. L’absence de chiffres comparatifs fiables entre K3 et V4 Pro n’est pas qu’une lacune de notre corpus : c’est un symptôme. Les benchmarks publics saturent, se contaminent, et peinent à distinguer les modèles de frontière. La réponse émergente est la multiplication d’évaluations spécialisées et de jeux de test privés — mais cela laisse les praticiens sans référence commune. Un chantier de standardisation reste ouvert.

Quatrième dynamique : la sécurité. L’OWASP LLM Top 10 2026, publié le 6 août 2026 sous le titre évocateur « The model will be fooled », place les risques liés aux agents et à l’injection de prompt au cœur des préoccupations. Les incidents documentés — attaque par dataset malveillant sur Hugging Face ayant permis plus de 17 000 actions en un week-end, vulnérabilités d’exécution de commandes dans plusieurs harnais agentiques — rappellent que la puissance des modèles agentiques s’accompagne d’une surface d’attaque élargie. Choisir un modèle, c’est aussi choisir un écosystème de sécurité.

Ce qui vient ensuite. Trois directions se dessinent. D’abord, l’intégration multimodale poussée (vidéo, audio, peut-être action) comme nouveau standard. Ensuite, les agents autonomes capables d’exécuter des tâches longues avec peu de supervision — le terrain de jeu revendiqué de K3 et de ses sous-agents. Enfin, la question de la soutenabilité économique : entraîner et servir des modèles de cette taille a un coût énergétique et financier considérable, et la pression réglementaire (AI Act entré en vigueur en 2026) pourrait redistribuer les cartes.

Pour les praticiens, la conclusion est moins un verdict qu’une méthode : mesurez sur vos tâches, lisez les licences, dimensionnez votre infrastructure sur des mesures réelles, et gardez une porte de sortie. Le duel K3 vs V4 Pro est passionnant, mais il ne dispense pas de faire son propre travail d’évaluation. C’est précisément ce que les chiffres marketing ne feront jamais à votre place.

---

Sources

• Kimi — site officiel
• Kimi Agent
• Kimi — version anglaise
• Kimi K2.6 — page modèle officielle
• Kimi (AI) — Wikipédia
• Best Open-Source Agent Harnesses for Local LLMs in 2026 — MarkTechPost
• Kimi K3 vs DeepSeek V4 Pro: Best Open Source LLM in 2026? — Memeburn
• OWASP 2026 LLM Top 10: "The model will be fooled" — Help Net Security