Passer au contenu principal
Last verified: 2026-10-14
Kimi K3 est le modèle frontier de Moonshot AI : 2.8 billions de paramètres au total, 104 milliards actifs par token via le routage Stable LatentMoE (16 experts actifs + 2 experts partagés sur 896 au total), une entrée visuelle native via MoonViT-V2, et une fenêtre de contexte de 1 million de tokens. Moonshot a lancé K3 le 17 juillet 2026 pour le codage de longue haleine, le travail de connaissance et le raisonnement, et a publié les poids téléchargeables les 27-28 juillet 2026 sur HuggingFace (1.1M+ téléchargements). Les poids, la fiche du modèle et la licence sont publics. Vous pouvez auto-héberger K3 aujourd’hui sur un cluster suffisamment grand et le connecter à Tokios.
Les poids de Kimi K3 sont disponibles sur HuggingFace. Le dépôt a 1.1M+ téléchargements. Vous pouvez auto-héberger K3 avec vLLM sur un cluster avec 64+ accélérateurs et le connecter à Tokios.

Quelles options sont disponibles ?

Source : article de lancement de Kimi K3 et guide API Kimi K3.

Kimi K3 en un coup d’œil

Moonshot a publié le rapport technique, les fichiers de checkpoint et la fiche du modèle alongside la publication des poids. Lisez la fiche du modèle pour la spécification complète et les termes de la licence.

Pouvez-vous exécuter Kimi K3 en local ?

Oui — si vous avez un cluster suffisamment grand. Les poids sont disponibles sur HuggingFace, mais le plancher de poids de K3 d’environ 1.4 TB à précision 4-bit exclut toute configuration grand public et prosumer. La recommandation de Moonshot est un supernode avec 64 accélérateurs ou plus. Huit DGX Sparks mutualisent 1 TB de mémoire unifiée et restent tout de même 376 GB en deçà. Consultez le calcul mémoire DGX Spark pour le calcul complet. vLLM est le backend de service officiellement supporté. Vous pouvez aussi utiliser Docker Model Runner ou Transformers avec trust_remote_code.
K3 nécessite 64+ accélérateurs. Consultez quoi exécuter à la place de Kimi K3 pour le meilleur modèle de codage et général pour votre matériel exact, de Strix Halo à un cluster de 4 Sparks.

Exigences matérielles de Kimi K3

Aucune configuration grand public ou prosumer ne peut contenir K3. À exactement 4 bits par paramètre, 2.8T paramètres nécessitent environ 1.4 TB pour les poids seuls — avant les métadonnées de microscaling, les tampons d’exécution, les activations et l’état du contexte. À titre d’échelle : huit DGX Sparks mutualisent 1 TB de mémoire unifiée et sont toujours au moins 376 GB en deçà du plancher de poids brut, NVIDIA ne documente actuellement les clusters Spark que jusqu’à quatre nœuds, et Moonshot recommande de servir K3 sur un supernode avec 64 accélérateurs ou plus. Consultez le calcul mémoire DGX Spark pour le calcul complet, le tableau des clusters et les contraintes réseau.

Servir K3 en local

Le chemin de service officiellement supporté est vLLM. Docker Model Runner et HuggingFace Transformers (avec trust_remote_code) fonctionnent aussi.
K3 nécessite des noyaux KDA-aware et des sémantiques de cache. Un runtime qui se contente de charger les poids n’est pas automatiquement compatible K3. Utilisez vLLM avec le support KDA ou l’un des autres backends vérifiés.

Pourquoi l’architecture importe pour l’auto-hébergement

K3 n’est pas simplement un checkpoint K2 plus grand. Cinq changements importent pour quiconque prévoit de le servir :
  • Kimi Delta Attention (KDA) — une conception hybride d’attention linéaire qui rend les prompts de millions de tokens moins chers à préremplir. Il nécessite des noyaux correspondants et des sémantiques de cache : Moonshot indique que le cache de préfixe conventionnel ne correspond pas proprement à KDA et que sa contribution au cache de préremplissage vLLM est livrée avec les poids. Un runtime qui se contente de charger les poids n’est pas automatiquement compatible K3.
  • Attention Residuals (AttnRes) — des couches récupèrent sélectivement des représentations utiles depuis des profondeurs antérieures au lieu d’ajouter la sortie de chaque couche avec un poids fixe. L’article AttnRes de Moonshot rapporte un flux d’information plus stable dans les modèles profonds.
  • Stable LatentMoE — 16 experts actifs + 2 experts partagés routés par token sur 896 au total. L’activation sparse réduit le calcul par token, mais elle ne réduit pas le checkpoint stocké : chaque expert doit rester résident à travers le cluster de service, ce qui fait des interconnexions rapides une exigence de premier ordre.
  • MoonViT-V2 — un encodeur visuel de 401M paramètres qui traite les entrées texte, image et vidéo nativement.
  • MXFP4 natif — l’entraînement avec quantification-aware a été mené depuis l’étape de fine-tuning supervisé, ciblant des poids MXFP4 et des activations MXFP8. C’est le format de service prévu, pas un quant communautaire — donc le chiffre de 4-bit ci-dessus est un plancher, pas un compromis.

Comportement de l’API K3 à préserver

Si vous testez K3 via l’API de Moonshot, ou validez un runtime auto-hébergé, ces détails de protocole importent :
  • K3 raisonne toujours. Utilisez le reasoning_effort: "max" de niveau supérieur ; n’envoyez pas le paramètre thinking de K2.x.
  • Les réponses en streaming séparent le raisonnement dans reasoning_content et la réponse finale dans content.
  • Pour les conversations multi-tours et les boucles d’outils, rejouez le message assistant complet, y compris le raisonnement préservé et les champs d’appel d’outils. Ne renvoyer que content peut déstabiliser les tours suivants.
  • max_completion_tokens a pour défaut 131,072 et peut être réglé jusqu’à 1,048,576.
  • L’API de lancement fixe les valeurs d’échantillonnage. Moonshot recommande d’omettre temperature, top_p, n, et les paramètres de pénalité plutôt que de les outrepasser.
  • Les URLs d’images publiques ne sont pas acceptées. Envoyez des données base64 ou une référence ms://<file-id>.
Consultez le guide officiel API K3 pour le schéma de requête actuel.

Connectez K3 avec Tokios

Tokios se place après un runtime local. Il ne télécharge pas le modèle ni ne remplace vLLM. Servez K3 sur un cluster supporté et connectez-le à Tokios :
1

Vérifiez les artefacts officiels

Confirmez que le dépôt est moonshotai/Kimi-K3. Lisez la fiche du modèle, la licence, le manifeste de checkpoints, la liste d’accélérateurs supportés et les paramètres de parallélisme recommandés.
2

Servez K3 sur le cluster supporté

Exécutez vllm serve "moonshotai/Kimi-K3" ou suivez les instructions Docker Model Runner / Transformers. Confirmez que le serveur local peut compléter une requête en streaming, préserver reasoning_content, et exécuter une boucle d’outils multi-tours sur son propre API /v1.
3

Appariez le connecteur Tokios

Installez le connecteur sur un nœud qui peut atteindre le point de terminaison de service. Dans le dashboard, ouvrez Setup, sélectionnez Start pairing, et utilisez le code d’appairage unique TKS-XXXX-XXXX.
Windows
macOS
Linux
Puis approve l’appareil dans l’onglet Setup ou Connectors.
4

Enregistrez un déploiement

Pointez le connecteur vers l’URL de base /v1 compatible OpenAI du cluster. Enregistrez l’id de modèle upstream sous un nom de déploiement public tel que kimi-k3-tunnel.
5

Créez une clé API

Dans l’onglet Keys, cliquez sur Create key. Copiez la clé sk-tok-… maintenant — elle n’est affichée qu’une seule fois.
6

Testez avant de partager le point de terminaison

Testez le streaming, les tours longs, la vision, la sortie structurée et les appels d’outils via https://api.tokios.com. Utilisez une clé API sk-tok-… dédiée et gardez le contexte initial court pendant que vous validez l’utilisation mémoire.

Appelez-le depuis n’importe où

Une fois ce chemin vérifié, les clients appellent votre nom de déploiement plutôt que l’id de modèle upstream :

Mises en garde du lancement

  • Les résultats de benchmark de K3 sont rapportés par Moonshot. La reproduction indépendante nécessite la configuration d’évaluation.
  • Moonshot avertit que perdre l’historique de raisonnement préservé, ou basculer une session existante d’un autre modèle vers K3, peut rendre la sortie instable.
  • K3 est entraîné pour des tâches longues et difficiles et peut agir de manière trop proactive quand les instructions sont ambiguës. Mettez des limites explicites dans votre invite système ou AGENTS.md.
  • Une limite de 1M tokens est un maximum, pas une cible. Les contextes longs augmentent le temps de préremplissage, le stockage du cache et le coût d’inférence.
  • La licence Kimi K3 est personnalisée — lisez la fiche du modèle pour les termes avant de déployer en production.

FAQ

À sa précision native MXFP4 (4 bits par paramètre), K3 avec ses 2.8T paramètres nécessite environ 1.4 TB pour les poids seuls — avant les échelles de bloc, les tampons d’exécution, les activations et le cache KV. Cela représente environ 11 DGX Sparks à 128 GB chacun, juste pour le plancher de poids brut. En pratique, vous avez besoin de 14-16 Sparks minimum pour une pile de service distribuée hypothétique, et NVIDIA ne documente les clusters Spark que jusqu’à 4 nœuds.
Pas en pratique. Huit DGX Sparks vous donnent 1 TB de mémoire unifiée — 376 GB en deçà du plancher de poids. La topologie Spark documentée par NVIDIA culmine à 4 nœuds (512 GB), et Moonshot cible K3 sur des supernodes avec 64 accélérateurs ou plus. Pour les modèles à l’échelle Spark aujourd’hui, consultez Compatibilité des modèles DGX Spark.
Les poids sont disponibles sur HuggingFace sous une « Kimi K3 License » personnalisée — pas MIT ni Apache. Lisez la fiche du modèle pour les termes complets de la licence avant de déployer. Kimi K2.6 et K2.7-Code sont aussi à poids ouverts — consultez la famille de modèles Kimi.
Servez le checkpoint sur un cluster supporté avec 64+ accélérateurs. Le chemin officiellement supporté est vllm serve "moonshotai/Kimi-K3". Docker Model Runner et Transformers avec trust_remote_code fonctionnent aussi. Tokios peut frontaliser ce point de terminaison local avec des clés API à portée délimitée — consultez Connectez K3 avec Tokios ci-dessus. Vous pouvez aussi appeler l’API hébergée de Moonshot en utilisant l’id de modèle kimi-k3.
1,048,576 tokens (1M). Le paramètre max_completion_tokens a pour défaut 131,072 et peut être réglé jusqu’à la fenêtre de contexte complète. Les contextes longs augmentent le temps de préremplissage, le stockage du cache et le coût d’inférence — 1M est un maximum, pas une cible.
K3 est un modèle Mixture-of-Experts avec 93 couches (69 KDA + 24 Gated MLA), hidden dim 7168, 96 têtes d’attention, et 4 innovations clés : Stable LatentMoE (16 actifs + 2 experts partagés par token sur 896 au total, 104B actifs), Kimi Delta Attention (attention linéaire hybride pour un préremplissage efficace de millions de tokens), Attention Residuals (routage d’information en profondeur), MoonViT-V2 (encodeur visuel de 401M paramètres pour texte + image + vidéo), et MXFP4 natif (entraînement avec quantification-aware depuis SFT). Celles-ci ne sont pas compatibles directement avec le service de transformers standard — KDA en particulier nécessite des noyaux correspondants et des sémantiques de cache.

Kimi K3 sur DGX Spark

Le calcul mémoire complet, les contraintes de cluster et le tableau des preuves de lancement.

Modèles Kimi

Comparez K3 avec les K2.6 et K2.7-Code téléchargeables, et auto-hébergez Kimi aujourd’hui.

Quoi exécuter à la place de K3

Le meilleur modèle de codage et général pour votre matériel, de Strix Halo à un cluster de 4 Sparks.

Service et mise à l'échelle des modèles

Comprenez le parallélisme tensoriel, de pipeline et d’experts avant de planifier un cluster à l’échelle frontier.

Démarrage rapide

Appariez un connecteur et enregistrez un modèle local disponible aujourd’hui.