Kimi K3 : ce que signifie, concrètement, le faire tourner en local, l'utiliser à distance ou le brancher sur Claude Code

Publié sur le blog TEN INVENT · Juillet 2026

La semaine dernière, Moonshot AI a annoncé Kimi K3. Hier, ils ont publié les poids. Depuis, Internet regorge d'articles qui répètent les trois mêmes choses : « 2,8 billions de paramètres », « le plus grand modèle open-weight de l'histoire », « faites-le tourner en local ». Cette dernière partie est, pour 99,9 % d'entre nous, fausse.

Cet article tente de répondre à trois questions pratiques pour quelqu'un qui gagne sa vie en développant des logiciels, pas pour quelqu'un qui collectionne les benchmarks : combien coûte le faire tourner en local, ce qui change si on l'utilise à distance à la place de Claude Code, et comment le brancher sur Claude Code en cinq minutes.

1. Les dates de lancement, vérifiées

L'ordre des événements compte, car il y a eu une fenêtre de dix jours pendant laquelle le modèle était en ligne mais pas les poids :

Le dépôt officiel est huggingface.co/moonshotai/Kimi-K3 — public, sans restriction d'accès, avec de vrais safetensors, une LICENSE et une model card complète. Il existe aussi un dépôt GitHub MoonshotAI/Kimi-K3 avec le rapport technique en PDF.

Un avertissement qui mérite d'être formulé explicitement : cette semaine, des dizaines de miroirs et dépôts « Kimi-K3 » qui n'appartiennent pas à Moonshot sont apparus. Si vous téléchargez quoi que ce soit, téléchargez depuis l'organisation moonshotai et épinglez le hash du commit. Le modèle exige trust_remote_code=True, ce qui signifie que vous exécutez du code Python provenant du dépôt. Lisez-le d'abord.

2. Ce qu'est K3, techniquement

D'après la model card officielle :

• 2,8T de paramètres au total, 104B actifs par token — MoE avec 896 experts, dont 16 activés (plus 2 partagés). Soit ~1,8 % de densité de routage.
• 93 couches, dont 69 KDA (Kimi Delta Attention — attention linéaire avec règle delta) et 24 Gated MLA.
• Contexte de 1 048 576 tokens, uniforme, sans paliers de prix.
• Multimodal natif (texte + image, encodeur MoonViT-V2 de 401M).
• Quantification native MXFP4 avec activations MXFP8 — quantization-aware training appliqué dès la phase de SFT.
• Le thinking est toujours activé. Il n'existe pas de mode non-thinking. reasoning_effort accepte low / high / max, par défaut max.

Côté benchmarks : c'est le premier modèle open-weight qui entre sérieusement dans la conversation avec le sommet. Il bat Claude Opus 4.8 et GPT-5.5 sur la majorité des épreuves de coding et agentiques, se situe à quelques points sous Claude Fable 5 et GPT-5.6 Sol sur la plupart des autres, et dépasse les deux sur quelques-unes (SWE-Marathon 42.0, BrowseComp 91.2, MCPMark 94.5). Artificial Analysis le place à 57 sur l'Intelligence Index — première place parmi les modèles open-weight.

Le détail d'architecture qui compte sur le plan opérationnel : KDA casse le prefix caching conventionnel. Moonshot a contribué sa propre implémentation de caching à vLLM au moment du lancement. Si vous servez K3 sur un vieux build de vLLM, ça va faire mal.

3. En local : les maths qui fâchent

C'est ici qu'il faut être honnête.

Les poids publiés occupent 96 shards, ~1,56 To (1,42 TiB). Pas 594 Go — ce chiffre a circulé massivement dans la presse d'avant le lancement et il est tout simplement faux ; on ne peut pas stocker 2,8T de paramètres en 4 bits dans moins de ~1,4 To, quelle que soit votre créativité. Et c'est avant le KV cache, qui à 1M de contexte devient lui-même un consommateur sérieux.

Ce que ça signifie en matériel :

• Un nœud de 8× H100 80GB = 640 Go. Ça ne rentre pas. Même pas de loin.
• Un nœud de 8× accélérateurs de 192 Go = 1,536 To. Le modèle rentre en théorie, mais plus rien d'autre.
• La recommandation de Moonshot : minimum 64 accélérateurs (8 nœuds × 8), avec expert parallelism et une interconnexion sérieuse entre les nœuds.
• Quelqu'un a rapporté avoir démarré K3 sur 80× RTX 5090, obtenant 20 tok/s sur un seul stream, le premier jour, sans optimisation. C'est un exploit technique, pas une solution.

Les moteurs officiellement recommandés : vLLM, SGLang, TokenSpeed. La commande de base a l'air banale :

vllm serve moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --max-model-len 131072 \
  --trust-remote-code

Conseil pratique si vous y arrivez vraiment : commencez avec 128k–256k de contexte, pas 1M. La fenêtre complète exige soit un kernel d'attention linéaire supporté dans votre build, soit assez de GPU pour sharder le KV cache.

Statut GGUF : au moment où j'écris, il n'existe pas de ports GGUF de fidélité complète confirmés pour llama.cpp / Ollama / LM Studio. Ils viendront. Mais même un Q2 dynamique de type Unsloth resterait dans la zone des centaines de Go — il ne passe pas sous le seuil du « serveur », seulement sous celui du « datacenter ».

Traduction pour un cabinet de conseil de 1 à 5 personnes

Non. Il n'existe aucun scénario dans lequel faire tourner K3 en local a un sens économique pour nous. Un Mac Studio M3 Ultra, aussi bien équipé soit-il, ne voit pas ce modèle même avec des jumelles. Une RTX 4090 est une blague dans ce contexte.

Ce qui a du sens en local, si vous voulez la souveraineté sur vos données : Kimi K2.7 Code (1T de paramètres, 256k de contexte, ~325 Go en Q2 dynamique, ~605 Go en pleine précision) tourne sur un Mac Studio bien doté ou sur une station avec 256+ Go de mémoire unifiée. C'est un bon modèle. Ce n'est pas K3, mais c'est un bon modèle, et la différence entre « bon » et « frontier » compte moins que vous ne le pensez pour 80 % des tâches.

La conclusion honnête : « open weights » pour K3 signifie souveraineté pour les entreprises avec des racks, pas pour les développeurs avec des laptops. C'est une distinction qui se perd dans les gros titres.

4. À distance, à la place de Claude Code : l'économie réelle

C'est ici que la discussion devient intéressante, car c'est la seule option praticable.

Tarifs

K3 est au niveau de Sonnet en prix catalogue. Ce n'est pas le modèle chinois bon marché que tout le monde attendait après K2 — il est 3 à 4 fois plus cher que son propre prédécesseur K2.6 ($0.95/$4).

Ce qui change le calcul, c'est le cache hit à $0.30 — une réduction de 90 %. Dans les boucles agentiques, où vous renvoyez le même system prompt, les mêmes fichiers et le même contexte de repo à chaque étape, la majorité de l'input touche le cache. OpenRouter rapporte un taux de cache hit de ~92 % sur le trafic K3, ce qui ramène l'input effectif à environ ~$0.52/1M.

Le contrepoint, et il est sérieux : K3 réfléchit toujours à effort maximal. Chaque token de raisonnement est facturé à $15/1M. Il n'y a pas de bouton « réfléchis moins pour que je paie moins ». En blended (80/20 input/output), on arrive autour de $5.40/1M — contre ~$9 pour Opus 4.8. Réel, mais pas spectaculaire, et complètement dépendant de la loquacité du modèle sur votre tâche.

Mesures indépendantes d'Artificial Analysis sur l'endpoint Moonshot : ~62 tokens/seconde en output, ~2 secondes jusqu'au premier token. C'est plus lent que ce à quoi vous êtes habitué. Dans une longue boucle agentique, la latence par tâche peut annuler l'avantage de prix par token.

Où tourne réellement votre requête

C'est la question qui compte pour quiconque travaille avec des clients US ou UE sous NDA.

• L'API Moonshot directe (api.moonshot.ai) — infrastructure en Chine. Pour beaucoup de contrats, un non-starter automatique, quelle que soit la qualité du modèle.
• Fireworks / Baseten — hébergement aux États-Unis, avec options Zero Data Retention, certifiés par Moonshot. Prix identique : $3/$15. Personne ne casse les prix, ce qui est en soi un indice sur la forme des accords de licence en coulisses.
• Vercel AI Gateway — route entre les fournisseurs US avec failover, même ID de modèle moonshotai/kimi-k3, plus un palier « Kimi K3 Fast » plus cher et plus rapide.
• OpenRouter — plusieurs fournisseurs, routage par prix/vitesse/précision du tool calling.

Si vous avez des clauses de résidence des données dans votre contrat, la variante hébergée aux US n'est pas optionnelle. Et elle mérite d'être lue avant, pas après.

5. Comment le brancher sur Claude Code

La bonne nouvelle : Claude Code ne vérifie pas à qui il parle. Il lit trois variables d'environnement — une URL, un token, un nom de modèle — et envoie la requête là où elles pointent. Moonshot expose un endpoint compatible Anthropic, donc le harnais reste identique : mêmes hooks, mêmes serveurs MCP, mêmes skills, mêmes habitudes.

La configuration (d'après la documentation officielle de Moonshot)

En persistant, dans ~/.claude/settings.json :

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.moonshot.ai/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "YOUR_MOONSHOT_API_KEY",
    "ANTHROPIC_MODEL": "kimi-k3[1m]",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "kimi-k3[1m]",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "kimi-k3[1m]",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "kimi-k3[1m]",
    "ANTHROPIC_DEFAULT_FABLE_MODEL": "kimi-k3[1m]",
    "CLAUDE_CODE_SUBAGENT_MODEL": "kimi-k3[1m]",
    "ENABLE_TOOL_SEARCH": "false",
    "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1048576",
    "CLAUDE_CODE_EFFORT_LEVEL": "max"
  }
}

Ou temporairement, pour la session en cours seulement, avec export sur les mêmes variables avant de lancer claude. Ne les mélangez pas — les valeurs de settings.json ont priorité sur celles exportées dans le terminal, et c'est la raison numéro un pour laquelle « la configuration ne marche pas ».

La vérification se fait avec /status, pas avec /model. Le menu /model est une liste fixe d'alias internes et n'affichera jamais de modèles Kimi — ce n'est pas un bug, il n'y a rien à basculer là-bas. /status doit afficher la base URL de Moonshot et kimi-k3[1m].

Les pièges, dans l'ordre où vous les rencontrerez

1. Un ANTHROPIC_API_KEY resté dans le shell. Il entre en conflit avec ANTHROPIC_AUTH_TOKEN et produit des erreurs 401 déroutantes. Supprimez-le.
2. Les variables de tier non configurées. Si vous ne définissez que ANTHROPIC_MODEL, les tâches d'arrière-plan (titres de conversation, résumés) et les sous-agents demandent des noms de modèles Claude que l'endpoint Kimi ne reconnaît pas — et échouent silencieusement. Définissez-les toutes.
3. ENABLE_TOOL_SEARCH doit être false. L'endpoint ne supporte pas encore la fonctionnalité. Claude Code la désactive de toute façon par défaut quand la base URL n'est pas Anthropic, mais explicite vaut mieux.
4. WebFetch ne fonctionne pas sur l'endpoint Kimi pour le moment — il renvoie « temporarily unavailable » ou du contenu vide. Contournement : collez le contenu dans le chat ou utilisez un MCP de scraping.
5. CLAUDE_CODE_AUTO_COMPACT_WINDOW doit correspondre au modèle : 1048576 pour K3, 262144 pour K2.7 Code. Trop petit → compactage prématuré et perte de contexte ; trop grand → erreurs de longueur de contexte.
6. Preserved thinking history. K3 a été entraîné dans un mode qui exige que le message complet de l'assistant — y compris reasoning_content et tool_calls — soit renvoyé dans messages, pas seulement content. Claude Code s'en sort, mais si vous construisez votre propre harnais ou changez de modèle en milieu de session, attendez-vous à un output instable.
7. La recherche web est facturée séparément, ~$0.004 par appel, en plus du prix des tokens.

Alternativement, Moonshot a son propre CLI — Kimi Code — avec lequel ils disent que le modèle travaille le mieux, et que vous pouvez installer en parallèle. La différence est visible dans leurs benchmarks : K3 fait 72,9 sur Kimi Code Bench avec leur propre harnais et 73,7 avec Claude Code, donc le harnais n'est pas le facteur décisif.

6. La licence — lisez-la

C'est la partie que la plupart des articles sautent.

K3 n'est pas MIT et pas Apache 2.0. C'est un document sur mesure, la « Kimi K3 License », étiquetée sur Hugging Face comme license:other. Artificial Analysis l'a classée « Commercial Use Restricted ».

Le texte est MIT sur la majeure partie de sa longueur — vous pouvez télécharger, exécuter, modifier, fine-tuner, redistribuer et utiliser commercialement sans coût de licence. Deux clauses changent les choses à grande échelle :

• Model-as-a-Service : si vous ou vos affiliés exploitez une activité offrant à des tiers l'accès à l'inférence ou au fine-tuning, et que les revenus agrégés du groupe (pas ceux attribuables à K3) dépassent 20 M$ sur n'importe quelle période de 12 mois consécutifs, vous devez signer un accord séparé avec Moonshot avant tout usage commercial.
• Attribution : tout produit commercial avec plus de 100 millions d'utilisateurs actifs mensuels ou plus de 20 M$ de revenu mensuel doit afficher « Kimi K3 » de manière visible dans l'interface.

L'usage strictement interne et l'accès via les produits de Moonshot ou leurs partenaires certifiés sont exemptés.

Pour un cabinet de notre taille, les deux seuils sont théoriques. Mais si vous construisez un produit que vous espérez vendre, ou si vous revendez de l'inférence, la clause 2 est une obligation contractuelle, pas une note de bas de page. Et le seuil de 20 M$ au niveau du groupe est suffisamment bas pour que pratiquement tous les fournisseurs sérieux d'inférence y soient soumis — ce qui explique pourquoi personne ne casse le prix de Moonshot.

7. Verdict

En local : non, sauf si vous avez un cluster. Pour la souveraineté des données à l'échelle d'une petite entreprise, K2.7 Code sur votre propre matériel est la vraie réponse.

À distance, en remplacement de Claude Code : ça vaut le test, les yeux ouverts. L'économie est réelle mais plus petite que ne le suggèrent les gros titres — ~40 % sous Opus en blended, conditionné par un bon taux de cache hit, et payé en partie en latence, parce que le modèle réfléchit toujours au maximum. Pour le travail client sous NDA, utilisez un fournisseur hébergé aux US avec ZDR, pas l'endpoint direct.

Comme deuxième cerveau : c'est là que ça me semble le plus intéressant. Vous avez déjà l'abonnement Claude Code. Le coût marginal de configurer un deuxième profil qui route vers K3, c'est cinq minutes et une clé API. Un deuxième modèle, avec un avis indépendant sur le même code, qui excelle exactement dans les domaines où il est classé premier — frontend, design, tâches agentiques très longues — n'est pas un remplacement. C'est un deuxième avis. Et cc-switch ou un simple alias dans .zshrc rend la bascule instantanée.

C'est ça, je crois, le vrai gain de cette semaine : pas que nous ayons un modèle moins cher, mais que le harnais soit devenu portable. Les outils dont nous avons fait des habitudes — Claude Code, MCP, skills — ne sont plus liés à un seul fournisseur. C'est une bonne nouvelle, peu importe qui vous choisissez à la fin.

Une note, comme d'habitude : je crois que l'IA est l'avenir et que les frictions ci-dessus — WebFetch qui ne marche pas, les variables d'environnement à définir à la main à huit endroits, 1,5 To de poids que personne ne peut faire tourner chez soi — sont des problèmes de jeunesse qui se résoudront. L'écosystème a 18 mois de maturité réelle. Mais tant qu'elles sont devant nous, elles méritent une discussion honnête, parce que les décisions d'infrastructure que nous prenons maintenant nous coûtent de l'argent réel dans les mois à venir.

Toutes les données de cet article ont été vérifiées le 28 juillet 2026 à partir de la model card officielle, de la documentation de la plateforme Moonshot et de rapports indépendants. Dans une semaine de lancement, les choses bougent chaque jour — vérifiez le dépôt avant toute décision de production.