Comment exécuter Kimi K3 localement : matériel, mémoire et limites de déploiement

Exécuter le Kimi K3 complet localement est possible avec les poids publiés, mais le déploiement pratique nécessite encore une mémoire, des accélérateurs et des interconnexions à l’échelle d’un cluster.

Après la publication des poids ouverts du 27 juillet, la question n’est plus de savoir si un point de contrôle existe, mais si votre système peut le télécharger, le charger et le servir à une vitesse utile. Le dépôt public fait environ 1,56 To répartis sur 96 fragments safetensor, tandis que le modèle contient 2,8 trillions de paramètres totaux et active 104 milliards par token. Ces chiffres excluent un PC, Mac, NAS domestique ou serveur mono-GPU de la plage pratique du modèle complet, donc les sections ci-dessous séparent stockage, mémoire, topologie des accélérateurs, support d’exécution et chemins de secours réalistes.

Qu’est-ce qui est disponible maintenant que les poids Kimi K3 sont publiés ?

La publication des poids ouverts Kimi K3 inclut le point de contrôle complet du modèle et le rapport technique. Le dépôt public du modèle affiche actuellement environ 1,56 To de fichiers et 96 fragments safetensor numérotés. Ce chiffre est utile pour planifier les téléchargements et la capacité disque, mais ce n’est pas une spécification minimale de VRAM.

Le résumé du modèle publié confirme 2,8T de paramètres totaux, 104 milliards de paramètres activés, 93 couches, 69 couches Kimi Delta Attention et 24 couches Gated MLA. Son routage Stable LatentMoE sélectionne 16 experts parmi 896 experts routés par token et utilise également deux experts partagés. Les poids sont en MXFP4, les activations en MXFP8, et le contexte maximal annoncé est de 1 048 576 tokens.

Le support de déploiement est également plus concret qu’avant la sortie. vLLM, SGLang et TokenSpeed sont listés comme moteurs d’inférence recommandés, mais chacun nécessite des noyaux, du code modèle, du sharding et des réglages mémoire compatibles K3. Une commande générique affichée par une bibliothèque cliente ne transforme pas le point de contrôle en un modèle local à l’échelle consommateur.

Pourquoi le MoE clairsemé nécessite-t-il encore une mémoire énorme ?

Kimi K3 effectue le calcul avec 104 milliards de paramètres activés pour chaque jeton, mais tous les experts MoE consomment toujours de la mémoire de stockage et de service. Le routeur peut sélectionner différents experts pour le jeton suivant, donc l’ensemble complet des poids de 2,8T doit rester accessible quelque part dans le déploiement.

Sélectionner 16 des 896 experts routés réduit le travail des experts effectué pour un jeton. Cela ne signifie pas qu’une machine peut ne garder que 16 experts, jeter les autres et exécuter le modèle publié sans changement. L’élagage d’experts, la distillation ou le streaming créeraient un compromis opérationnel différent et ne doivent pas être confondus avec l’activation claire normale.

Le chiffre de 104 milliards de paramètres activés est donc une description de l’échelle de calcul, pas un raccourci pour estimer la taille du point de contrôle. Multiplier 104 milliards par quatre bits et affirmer que le modèle nécessite seulement environ 52 Go ignorerait les poids d’experts inactifs mais toujours nécessaires, les composants denses, les experts partagés, les couches d’attention, les poids de vision et l’état d’exécution.

Quelle est la limite inférieure minimale de la mémoire des poids ?

Avec 2,8 trillions de paramètres, le calcul le plus simple de la limite inférieure est le nombre total de paramètres multiplié par le nombre de bits stockés par paramètre. MXFP4 donne un plancher de charge utile de quatre bits : 2,8T × 4 bits correspond à environ 1,4 To, soit environ 1,27 TiO, pour la seule charge utile brute des poids.

Le dépôt publié fait environ 1,56 To, ce qui explique pourquoi la mémoire de service dépasse un simple calcul de poids. L'emballage du point de contrôle, les échelles de blocs, l'alignement des tenseurs, les fichiers de configuration, les ressources du tokenizer, les composants de vision et d'autres données du modèle font dépasser le téléchargement réel au-delà du plancher théorique à quatre bits.

Quatre budgets différents doivent être planifiés séparément : stockage persistant de téléchargement, espace de mise en scène temporaire, RAM hôte et HBM ou VRAM de l'accélérateur. Un service en fonctionnement nécessite ensuite de la place supplémentaire pour l'état KDA, le cache MLA KV, les activations, les tampons de communication, les noyaux, la capture de graphe et une marge pour les pannes. La taille du dépôt de 1,56 To n'est donc ni une exigence complète de RAM ni une exigence complète de mémoire GPU.

Quel matériel peut réellement exécuter Kimi K3 localement ?

Il n'existe pas de liste honnête de GPU grand public minimum pour le modèle complet. Un système capable techniquement de mapper ou de diffuser le point de contrôle n'est pas automatiquement capable d'un service stable et interactif. Les exigences matérielles pratiques pour Kimi K3 dépendent de la résidence des poids, des noyaux MXFP4 supportés, de la bande passante d'interconnexion, de la capacité du cache, de la longueur du contexte, de la concurrence et du moteur de service.

Le support day-zero Kimi K3 publié par vLLM place la classe de départ réaliste à un nœud d'entreprise à huit accélérateurs. Les documents actuels de vLLM décrivent des accélérateurs de classe GB300 ou MI350X/MI355X comme points de départ, tandis que SGLang publie des exemples conscients de la topologie incluant B300 1×8, GB300 2×4, B200 2×8, H200 2×8, H100 4×8, et MI350X/MI355X 1×8.

Ce sont des recettes d'exécution publiées et des configurations de départ, pas un minimum certifié unique pour chaque charge de travail. Les accélérateurs plus anciens ou plus petits peuvent nécessiter plus de nœuds, des noyaux de quantification différents, un contexte réduit ou un parallélisme expert supplémentaire. Le trafic en production nécessite également une capacité pour les requêtes simultanées, les travailleurs défaillants et une marge de performance, et pas seulement la capacité d'adapter le point de contrôle une fois.

Pourquoi un seul poste de travail ou NAS reste-t-il une topologie inadaptée ?

La simple division de la capacité brute sous-estime le problème. Même si une mémoire agrégée suffisante est assemblée, le parallélisme expert transforme le routage en trafic réseau. Les tokens doivent atteindre les accélérateurs détenant leurs experts sélectionnés puis revenir au reste du pipeline du modèle.

Les nœuds d'accélérateurs d'entreprise offrent plus que de la mémoire. Ils combinent des liens GPU à haute bande passante, un réseau compatible RDMA, des bibliothèques de communication collective et des noyaux conçus pour le parallélisme tensoriel, expert, de données ou de pipeline. Un ensemble de GPU grand public connectés via un PCIe ordinaire ou un réseau domestique peut afficher une capacité nominale suffisante tout en restant beaucoup trop lent ou fragile pour un service utile.

Un NAS est précieux pour stocker des fragments de points de contrôle, des journaux, des ensembles de données, des index de récupération et des données d'application, mais le stockage réseau ne remplace pas la bande passante mémoire de l'accélérateur. Le rôle idéal d'un serveur domestique est généralement de garder les données privées et la récupération proches de l'utilisateur tout en laissant l'inférence des modèles de pointe à un cluster adapté ou à un point de terminaison hébergé. Dans cette conception, un serveur domestique sépare la couche de données locale de l'inférence de pointe.

Comment l'état KDA, le cache MLA KV et la longueur du contexte augmentent-ils le budget ?

Kimi K3 n'utilise pas un cache d'attention complète uniforme sur les 93 couches. Ses 69 couches KDA et 24 couches MLA à portes créent deux demandes de mémoire de service différentes : un pool d'état KDA avec une géométrie de modèle fixe pour les requêtes admises, et un pool paginé MLA KV qui croît avec les tokens stockés.

Cette séparation signifie que KDA peut réduire la croissance du contexte long observée dans l'attention conventionnelle, mais elle ne rend pas une requête d'un million de tokens gratuite. Comme l'état KDA et la mémoire MLA KV se disputent la capacité de l'accélérateur, le côté KDA peut limiter les requêtes admises tandis que le côté MLA limite le nombre total de tokens mis en cache.

La taille du lot, la simultanéité, la longueur moyenne des invites, la longueur du raisonnement généré, les entrées multimodales, la précision du cache et la stratégie de préremplissage/décodage modifient tous la capacité utilisable. Le chiffre de 1 million de tokens est une capacité maximale du modèle, pas une valeur par défaut recommandée. Un premier déploiement doit commencer avec un contexte maximal plus court, une taille de lot de un et une faible simultanéité avant de mesurer les échecs de mémoire, le temps de préremplissage, la vitesse de décodage et le trafic inter-nœuds.

Comment pouvez-vous exécuter Kimi K3 localement après la publication des poids ouverts ?

Exécuter Kimi K3 localement maintenant signifie construire un service d'inférence distribué autour du point de contrôle publié, pas installer une application de bureau normale. La séquence la plus sûre est de valider le stockage, le support d'exécution, la topologie et un petit point de fonctionnement avant d'augmenter le contexte ou le trafic.

1. Préparez le stockage. Réservez au moins l'empreinte du dépôt d'environ 1,56 To plus un espace supplémentaire pour les téléchargements partiels, les caches, les images de conteneur, les journaux et les fichiers temporaires.
2. Sélectionnez un moteur pris en charge. Utilisez un chemin de déploiement vLLM, SGLang ou TokenSpeed spécifique à Kimi K3 avec le code modèle, les noyaux et la version du conteneur ou de la branche requis.
3. Adaptez la topologie. Choisissez une configuration multi-GPU ou multi-nœud d'entreprise avec suffisamment de HBM et le chemin NVLink, MNNVL ou RDMA attendu par ses paramètres de parallélisme tensoriel et expert.
4. Démarrez en dessous des limites principales. Réduisez la longueur maximale du modèle, la taille du lot et la simultanéité, puis vérifiez le chargement, le comportement en cas de mémoire insuffisante, la correction de la sortie, la vitesse de préremplissage, la vitesse de décodage et le trafic all-to-all.
5. Ne scalez qu'après mesure. Ajoutez le contexte, les requêtes simultanées, les fonctionnalités de cache, les entrées multimodales ou le décodage spéculatif une variable à la fois.

Une commande telle que vllm serve ou sglang serve décrit comment démarrer un environnement d'exécution distribué compatible ; cela ne supprime pas l'exigence matérielle. Lorsque la classe d'accélérateur requise n'est pas disponible, les choix réalistes sont une API hébergée, une architecture hybride qui conserve les fichiers et la récupération localement, ou un modèle local plus petit qui correspond à la mémoire réelle et au budget de fiabilité du serveur domestique.

FAQ

Puis-je exécuter Kimi K3 localement sur un PC, Mac ou NAS domestique normal ?

Pas à la vitesse pratique du modèle complet. Le dépôt fait environ 1,56 To avant les frais généraux de service, tandis qu'un système local normal manque également de la mémoire accélératrice et de la topologie à haute bande passante attendues par les environnements d'exécution actuels. Le streaming expert expérimental ou le déchargement intensif peuvent prouver qu'un lancement est techniquement possible, mais ce n'est pas équivalent à un service réactif ou prêt pour la production.

Quelle quantité de stockage et de mémoire Kimi K3 nécessite-t-il ?

Le plancher transparent de charge utile des poids MXFP4 est d'environ 1,4 To, tandis que le dépôt public est d'environ 1,56 To. Vous avez ensuite besoin d'espace disque supplémentaire, de RAM hôte, de HBM ou VRAM d'accélérateur, d'état KDA, de cache KV MLA, d'activations, d'espace de travail pour la communication et d'une marge opérationnelle. Il n'existe pas de chiffre unique représentant toutes ces couches.

Quelle est la configuration GPU minimale publiée pour Kimi K3 ?

Les plus petites configurations publiées au jour zéro sont des nœuds d'accélérateurs d'entreprise à huit cartes, avec les chemins actuels vLLM et SGLang centrés sur du matériel de classe B300, GB300 ou MI350X/MI355X. Considérez-les comme des points de départ pour l'exécution, pas comme un minimum universel garanti ; le contexte, la concurrence, la version du moteur et les objectifs de production peuvent nécessiter plus de ressources.

Kimi K3 peut-il fonctionner à partir d’un déchargement SSD ou NAS ?

Le stockage SSD ou NAS peut contenir des fragments de point de contrôle, et les environnements d'exécution expérimentaux peuvent diffuser les poids via la mémoire hôte. Le problème limitant est le déplacement répété des poids experts et de l'état à travers le stockage, le réseau, la RAM et les liens PCIe. Ces chemins sont bien plus lents que la HBM des accélérateurs et les interconnexions GPU à haute vitesse, donc un lancement expérimental peut entraîner une latence inutilisable.

Ollama exécute-t-il le modèle complet Kimi K3 localement ?

L'entrée actuelle Ollama Kimi K3 utilise le tag kimi-k3:cloud. Exécuter un client Ollama local ne signifie pas que le point de contrôle de 1,56 To est chargé sur la machine locale ; la route listée est soutenue par le cloud.

Conclusion finale

Kimi K3 est désormais véritablement disponible en tant que modèle à poids ouverts, permettant aux opérateurs de cluster de télécharger et déployer le point de contrôle complet plutôt que de se fier à des estimations préliminaires. Cette sortie modifie la vérification et la disponibilité des outils, mais ne change pas l'échelle physique d'un modèle à 2,8 trillions de paramètres.

Les chiffres de mémoire les plus utiles pour Kimi K3 répondent à différentes questions : environ 1,4 To est le plancher transparent des poids uniquement en quatre bits, environ 1,56 To est l'empreinte actuelle du dépôt, et 104 milliards est l'échelle de calcul activée par token. Aucun de ces chiffres ne décrit à lui seul la mémoire complète requise pour un service en fonctionnement.

Pour la plupart des particuliers et des utilisateurs de serveurs domestiques, la limite est claire : sans un nœud d'entreprise à huit accélérateurs ou un cluster distribué, utilisez l'inférence hébergée, conservez les données privées et la couche de récupération localement, ou choisissez un modèle plus petit. C'est la manière pratique de bénéficier de Kimi K3 sans traiter un NAS, une station de travail ou un GPU unique comme un super-nœud de modèle de pointe.