#Kimi K3 en local : ce que Moonshot a réellement publié

Moonshot AI a mis en ligne les poids de Kimi K3 sur Hugging Face les 26 et 27 juillet 2026, sous une licence permissive. C'est un modèle Mixture-of-Experts (MoE) de très grande taille, dans la lignée des K2, mais poussé à une échelle inédite. La communauté a d'abord célébré : un modèle frontière avec des poids téléchargeables, c'est rare. Puis les chiffres sont tombés.

Paramètres totaux: ≈ 2.8 billions (2.8T), architecture MoE avec une fraction seulement des experts actifs par token.
Taille sur disque: ≈ 1.4 To de fichiers à télécharger, même en quantization native.
Quantization: MXFP4 (microscaling FP4), le format 4-bit natif utilisé pour publier les poids — ce n'est pas un GGUF communautaire.
Recommandation officielle: Moonshot évoque 64 accélérateurs ou plus pour un service en production.
Licence: Poids ouverts, redistribuables et modifiables — d'où l'engouement initial.

MoE, ça change quoi ?

Un modèle MoE n'active qu'une partie de ses experts par token. Le calcul par token reste raisonnable, mais TOUS les poids doivent tenir en mémoire pour que le routeur puisse choisir n'importe quel expert. 2.8T paramètres en mémoire, c'est le vrai mur — pas la puissance de calcul.

#Ce que pèsent vraiment les poids

Le chiffre qui compte pour l'auto-hébergement n'est pas « 2.8T paramètres » dans l'absolu, mais la mémoire nécessaire pour les charger. En MXFP4 (4 bits par paramètre), on est déjà à environ 1.4 To de poids. C'est plus que la RAM totale de la quasi-totalité des postes de travail, et bien au-delà de n'importe quelle carte grand public.

MXFP4 (4-bit natif): ≈ 1.4 To — le format de publication officiel, le plancher réaliste.
Un GGUF Q2 hypothétique: Toujours de l'ordre du téraoctet ; descendre plus bas dégrade sévèrement un modèle de cette taille.
FP16 (non quantifié): ≈ 5 à 6 To — purement théorique, réservé à l'entraînement/inférence datacenter.

Pour donner un ordre de grandeur : nos repères habituels situent un 70B en Q4 autour de 40 Go de VRAM. Kimi K3 en MXFP4, c'est ~35 fois cette empreinte. On ne parle plus de « combien de GPU », mais de « combien de nœuds ».

Le piège du téléchargement

Avant même de penser inférence : 1.4 To à récupérer, c'est plusieurs heures voire jours selon votre connexion, et autant d'espace disque libre. Beaucoup abandonnent à cette étape sans jamais lancer un token.

#Le matériel que Moonshot recommande

Pour servir Kimi K3 correctement, Moonshot parle de 64 accélérateurs ou plus. Concrètement, cela signifie plusieurs serveurs GPU reliés entre eux, avec une interconnexion rapide (NVLink/InfiniBand) pour répartir les experts et le KV-cache sans étrangler le débit.

Échelle: 64+ accélérateurs type H100/H200 (80 Go HBM chacun), soit 8 nœuds de 8 GPU ou davantage.
Interconnexion: NVLink intra-nœud + InfiniBand inter-nœuds ; sans ça, le débit s'effondre.
Budget: Infrastructure à six ou sept chiffres — ce n'est pas de l'auto-hébergement, c'est du datacenter.
Alimentation & refroidissement: Plusieurs dizaines de kW ; hors de portée d'un logement ou d'un petit bureau.

Autrement dit, la configuration « recommandée » de Kimi K3 est celle d'un fournisseur de cloud, pas d'un passionné. C'est là que le mot « local » perd son sens habituel sur QuelLLM.

#Et sur un Mac ? Environ 16 secondes par token

Certains ont tout de même tenté l'exécution sur une machine unique en s'appuyant massivement sur le SSD (offloading disque). Le résultat le plus parlant : sur un MacBook Pro M1 Max, Kimi K3 produit de l'ordre de 16 secondes PAR token. Pas 16 tokens/seconde — 16 secondes pour un seul token.

Faites le calcul

À ~16 s/token, une réponse de 200 tokens demande plus de 50 minutes. Une conversation de quelques échanges occupe une soirée entière. Techniquement « ça tourne » ; en pratique c'est inutilisable pour un usage réel.

Cette lenteur vient de l'offloading : les poids ne tiennent pas en mémoire unifiée, la machine lit donc les experts depuis le SSD à chaque token. Le goulot n'est pas le GPU du M1 Max, mais la bande passante disque. C'est la démonstration la plus honnête que « ça se lance » et « c'est utilisable » sont deux choses différentes.

#Les options réalistes pour tester Kimi K3

Si l'objectif est d'utiliser Kimi K3 et non de prouver qu'on peut le charger, voici les voies qui ont du sens en 2026.

01
1. L'API officielle Moonshot
La voie la plus simple et la plus rapide : consommer Kimi K3 via l'API de Moonshot (ou un fournisseur qui l'héberge). Vous payez au token, mais vous accédez au modèle complet à pleine vitesse, sans infrastructure. Pour évaluer la qualité du modèle, c'est le point de départ logique.
02
2. LM Studio en mode device / cloud
LM Studio propose désormais un mode hybride : l'interface locale que vous connaissez, mais l'inférence des très gros modèles déportée (device distant ou cloud). Vous gardez votre workflow habituel tout en laissant le calcul à une machine capable de charger 1.4 To. C'est le compromis le plus proche de l'esprit « local » pour un modèle de cette taille.
03
3. Location de GPU à l'heure
Louer un nœud multi-GPU (8× H100/H200) chez un fournisseur cloud le temps d'un test. Coûteux à l'heure, mais sans engagement matériel. Réservé à ceux qui ont un vrai besoin d'évaluer le modèle en profondeur.
04
4. Attendre les quants communautaires
Des GGUF quantifiés plus agressivement finiront par apparaître. Mais rappelez-vous : même un Q2 reste de l'ordre du téraoctet, et la qualité chute. Ne comptez pas dessus pour transformer Kimi K3 en modèle de bureau.

→

Le bon réflexe

Voulez-vous ÉVALUER Kimi K3 ou l'AUTO-HÉBERGER ? Pour l'évaluer, l'API officielle en 5 minutes vaut mieux qu'une semaine de bricolage. L'auto-hébergement d'un 2.8T n'a de sens que si vous avez déjà l'infrastructure.

#Open weights ne veut pas dire exécutable localement

C'est l'angle honnête de ce guide. « Open weights » garantit que les poids sont disponibles, redistribuables et modifiables. Cela ne garantit en rien qu'un individu puisse les faire tourner chez lui. Ce sont deux libertés distinctes, souvent confondues.

Ce qu'open weights vous donne: Le droit de télécharger, d'inspecter, de fine-tuner, de redistribuer, d'auditer le modèle. Une vraie valeur pour la recherche et la souveraineté.
Ce que ça ne vous donne pas: La capacité matérielle de l'exécuter. Un 2.8T reste un objet de datacenter, même avec des poids libres.
Pourquoi c'est important: Un modèle open weights de 30B que vous faites tourner sur une RTX 4090 vous appartient réellement. Un 2.8T que seul un cloud peut charger reste, en pratique, un service.

Kimi K3 est donc une excellente nouvelle pour l'écosystème ouvert — auditabilité, fine-tuning par des acteurs disposant de moyens, indépendance vis-à-vis des labos fermés — sans être pour autant un modèle « pour tout le monde à la maison ». Distinguer ces deux plans évite les déceptions et les configurations impossibles.

#Alternatives locales vraiment auto-hébergeables

Si votre objectif est un modèle puissant qui tourne pour de vrai sur votre matériel, plusieurs options frontière-orientées sont bien plus réalistes que Kimi K3 en 2026.

DeepSeek V4 Flash (284B MoE): 13B actifs, licence MIT, le premier modèle frontière exécutable sur une workstation type Mac Studio Ultra. Le meilleur compromis qualité/faisabilité.
GLM-5.2 (753B MoE, MIT): Le seul modèle frontier-size avec des quants GGUF confirmés sur Ollama et LM Studio, jouable sur un Mac 256 Go ou une box RTX 4090 en 2-bit dynamique.
Qwen3.7 Max: Pensé pour les workstations musclées multi-GPU, avec des quants viables et un débit exploitable.
GLM 5.1 32B / Qwen3 30B-A3B: Si vous plafonnez à 24 Go de VRAM, ces modèles réactifs offrent 90 % de l'usage quotidien sans le mur mémoire.

→

Règle simple

La bonne question n'est pas « quel est le plus gros modèle open weights ? » mais « quel est le meilleur modèle qui tient dans MA mémoire à un débit acceptable ? ». Pour la plupart des lecteurs, la réponse est un MoE de 200 à 750B en quant agressif, pas un 2.8T.

#Verdict : Kimi K3 en local, oui mais…

Kimi K3 est un jalon pour l'IA ouverte : 2.8T paramètres avec des poids libres, c'est du jamais-vu à cette échelle. Mais pour l'auto-hébergement au sens de QuelLLM — un modèle qui tourne utilement sur votre machine — la réponse est claire : ce n'est pas fait pour ça. 1.4 To de poids, 64+ accélérateurs recommandés, ~16 s/token sur un M1 Max : les chiffres parlent d'eux-mêmes.

Pour évaluer sa qualité: API officielle Moonshot ou LM Studio device/cloud.
Pour auto-héberger un frontier: DeepSeek V4 Flash ou GLM-5.2, bien plus réalistes.
Pour un usage quotidien: Un 30-70B en Q4 sur votre GPU reste le meilleur rapport plaisir/faisabilité.

#Pour aller plus loin

Kimi K3 illustre la limite haute de l'auto-hébergement. Ces guides couvrent les modèles frontière réellement jouables chez soi et les notions pour bien choisir.

Le frontier qui tient vraiment: « DeepSeek V4 Flash 284B : le 1er frontier qui tient sur Mac Studio » — la vraie alternative exécutable à Kimi K3.
Le géant jouable en GGUF: « GLM-5.2 en local : le géant MIT qui tourne vraiment » — configs réalistes sur Mac 256 Go et box RTX 4090 en 2-bit.
Comprendre les quants: « Choisir sa quantification (Q4, Q5, Q8, FP16) » — pour saisir pourquoi descendre en 2-bit sur un modèle énorme change tout.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Modèles · 14 min

Kimi K3 chez soi : la vérité sur le matériel nécessaire (2.8T paramètres)