Exécuter Kimi K3 en local : matériel et coûts
Réponse directe : Kimi K3 peut être exécuté en local sur une infrastructure que vous contrôlez, mais le modèle complet n’est pas un LLM local pour un ordinateur ordinaire. Ses poids peuvent être téléchargés sans redevance de licence du modèle ; les coûts réels viennent des accélérateurs, du stockage, du réseau, de l’ingénierie et de l’exploitation continue.
Ce que signifie réellement « exécuter Kimi K3 gratuitement en local »
| Affirmation | Interprétation exacte | Coûts qui subsistent |
|---|---|---|
| « Les poids sont gratuits » | Moonshot autorise l’obtention, l’utilisation, la modification, le déploiement, le fine-tuning et la distribution de K3 sous sa licence personnalisée | Stockage, téléchargement, accélérateurs, électricité, serving, supervision et personnel |
| « Il fonctionne en local » | Le modèle peut être servi avec des moteurs compatibles sur une infrastructure contrôlée | Pour le modèle complet, « en local » désigne un cluster conséquent, pas un ordinateur portable |
| « L’API propose un essai gratuit » | Certains nouveaux utilisateurs de l’API Kimi reçoivent un coupon | Le centre d’aide chinois de Kimi précise que le coupon de 15 ¥ ne peut pas être utilisé avec Kimi K3 |
| « Les poids ouverts suppriment le coût API » | En exploitant votre propre stack, vous ne payez pas de frais par token à l’éditeur des poids | La dépense variable d’API est remplacée par des coûts de capacité et d’exploitation |
Données confirmées pour déployer Kimi K3
Les informations suivantes ont été vérifiées le 27 juillet 2026 à partir des sources Moonshot et des moteurs amont.
| Variable de déploiement | Valeur confirmée | Conséquence pour la planification |
|---|---|---|
| Paramètres totaux | 2,8 T | La planification diffère nettement de celle d’un modèle local de 7B à 70B |
| Paramètres actifs | 104B par token | L’activation sparse réduit le calcul, mais pas le stockage ni le routage des poids des experts |
| Format des poids et activations | Poids MXFP4, activations MXFP8 | La quantification publiée vise l’efficacité, mais dépend toujours du matériel et des kernels |
| Taille du dépôt | Environ 1,56 To avec 96 shards | Prévoir plus que le téléchargement brut pour les versions, le cache, les logs et le rollback |
| Fenêtre de contexte | 1 048 576 tokens | La mémoire d’état/KV et le prefill long contexte peuvent devenir des variables majeures |
| Topologie recommandée | Supernœud de 64+ accélérateurs | Recommandation pour une inférence de production efficace, pas seuil universel de démarrage |
| Moteurs pris en charge | vLLM, SGLang, TokenSpeed | Utiliser les recettes spécifiques à K3 plutôt que des options génériques mono-GPU |
Comment auto-héberger Kimi K3
1. Vérifier la licence avant le téléchargement
Trois clauses méritent une analyse juridique :
- Si le titulaire et ses sociétés affiliées exploitent un service Model-as-a-Service et dépassent 20 millions de dollars de revenus cumulés sur une période consécutive de 12 mois, un accord séparé avec Moonshot est requis avant tout usage commercial.
- Un produit commercial dépassant 100 millions d’utilisateurs actifs mensuels ou 20 millions de dollars de revenus mensuels doit afficher clairement « Kimi K3 ».
- Ces deux obligations ne s’appliquent pas à l’usage interne défini par la licence ni à l’utilisation via les produits officiels de Moonshot et ses partenaires d’inférence certifiés.
Ce résumé facilite la décision, mais ne constitue pas un avis juridique. Conservez les mentions de licence et de copyright et faites interpréter les conditions pour votre produit.
2. Planifier les artefacts et leur transfert
safetensors et pèse environ 1,56 To. Ne dimensionnez pas le volume exactement à 1,56 To : ajoutez l’espace nécessaire aux versions, au cache de téléchargement et au rollback.pip install -U "huggingface_hub[cli]"
huggingface-cli download moonshotai/Kimi-K3 \
--local-dir /models/Kimi-K3Épinglez une révision pour des builds reproductibles, conservez des sommes de contrôle ou un manifeste, séparez les artefacts immuables du cache de serving et planifiez la diffusion d’une nouvelle version à tous les workers sans saturer le réseau de production.
3. Choisir un moteur pris en charge en amont
/models/Kimi-K3, utilisez l’image K3 sur un nœud NVIDIA de validation à huit GPU et rendez le parallélisme explicite :docker run --rm --gpus all --ipc=host \
-p 8000:8000 \
-v /models/Kimi-K3:/models/Kimi-K3:ro \
vllm/vllm-openai:kimi-k3 \
--model /models/Kimi-K3 \
--tensor-parallel-size 8 \
--trust-remote-code \
--load-format fastsafetensors \
--moe-backend auto \
--gpu-memory-utilization 0.95 \
--max-model-len 32768 \
--reasoning-parser kimi_k3 \
--enable-auto-tool-choice \
--tool-call-parser kimi_k3Il s’agit d’une configuration de validation limitée, pas d’un déploiement multinœud complet. La limite initiale de contexte à 32K préserve de la capacité ; augmentez-la seulement après avoir mesuré mémoire et concurrence. La production exige toujours la recette upstream adaptée à la topologie, le parallélisme Tensor/Expert/Data, les kernels appropriés, le scheduler, les health checks et les tests de capacité.
4. Prouver la justesse avant le débit
reasoning_content, la conservation du raisonnement entre les tours, les appels d’outils, les sorties structurées, le long contexte, l’annulation et les retries. Un HTTP 200 ne prouve pas un déploiement correct. Comparez un jeu d’évaluation fixe à la route managée avant de déplacer le trafic.5. Ajouter le système de production manquant
L’auto-hébergement exige également :
- répartition de charge, contrôle d’admission, files d’attente et backpressure ;
- supervision du time to first token, du débit, du cache, des erreurs et de l’état des accélérateurs ;
- autoscaling ou politique volontaire de capacité fixe ;
- rolling updates, rollback des artefacts et mises à niveau du moteur ;
- protection contre les abus, authentification, rate limits, audit logs et rétention ;
- responsabilité d’astreinte pour les workers défaillants, l’interconnexion, les régressions et la saturation.
vllm serve.
Calculer le TCO mensuel de Kimi K3
Une comparaison utile garde les deux formules visibles :
managed_api_cost =
uncached_input_tokens × live_input_rate
+ cached_input_tokens × live_cache_rate
+ output_tokens × live_output_rate
self_host_monthly_tco =
accelerator_and_infrastructure
+ engineering_and_operations
+ one_time_setup / amortization_monthsNe transformez pas un tarif GPU trouvé sur Internet en devis réel. Demandez une offre pour la topologie requise et ajoutez stockage, réseau, support, redondance, utilisation et personnel.
| Votre situation | Meilleur point de départ | Pourquoi |
|---|---|---|
| Développeur individuel, évaluation ou prototype | API managée | Aucun engagement de cluster ; paiement à l’usage mesuré |
| Petite équipe avec trafic faible, irrégulier ou inconnu | API managée | Les coûts fixes d’infrastructure et d’astreinte sont difficiles à amortir |
| K3 n’est qu’une route d’un produit multimodèle | API unifiée EvoLink | K3, modèles plus petits et fallbacks restent derrière une seule intégration |
| Production stable à fort volume | Calculer les deux options | L’utilisation réelle et les devis peuvent justifier une capacité privée |
| Résidence stricte des données ou personnalisation des poids | L’auto-hébergement peut convenir | Le contrôle de l’infrastructure peut primer sur le coût |
| Cluster d’inférence et équipe d’exploitation existants | L’auto-hébergement est viable | Une grande partie des coûts fixes de plateforme et de personnel existe déjà |
Recensez ensuite tous les coûts propres avant de comparer au tarif actuel à l’usage :
| Poste de coût | Éléments à inclure |
|---|---|
| Artefacts du modèle | Environ 1,56 To par copie, plus téléchargement, staging, versions, cache et rollback |
| Cluster d’inférence | Topologie des accélérateurs, mémoire hôte, CPU et interconnexion pour les objectifs de latence et de concurrence ; Moonshot recommande 64+ accélérateurs |
| Stockage et réseau | Stockage persistant, trafic inter-nœuds, distribution des artefacts, logs et egress |
| Ingénierie | Intégration, serving distribué, évaluation, optimisation, mises à niveau et incidents |
| Disponibilité | Capacité de secours, health checks, bascule, supervision, sauvegardes et astreinte |
| Licence et conformité | Revue juridique, mentions, contrôle d’accès, audit logs, confidentialité et résidence |
Sans volume stable, devis réel du cluster et équipe responsable de l’inférence, ne commencez pas par l’auto-hébergement. Utilisez d’abord EvoLink à l’usage, collectez 30 à 60 jours de données réelles, puis recalculez.
Quand l’auto-hébergement est préférable
Il peut être rationnel si plusieurs conditions sont réunies :
- la demande soutenue maintient le cluster fortement utilisé ;
- des règles de confidentialité ou de résidence imposent une infrastructure contrôlée ;
- l’équipe exploite déjà de grands systèmes d’inférence distribuée ;
- des modifications des poids, un fine-tuning ou des changements profonds du serving sont nécessaires ;
- un volume prévisible amortit l’installation, le support et le renouvellement ;
- la Kimi K3 License convient au modèle commercial.
Quand une API managée est généralement moins chère
- le trafic est faible, irrégulier, saisonnier ou non mesuré ;
- l’équipe doit livrer une fonctionnalité plutôt qu’exploiter un cluster ;
- K3 n’est qu’une route d’un produit multimodèle ;
- l’adéquation de K3 au workload reste à tester ;
- disponibilité, reprise et upgrades consommeraient un temps d’ingénierie rare ;
- une grande capacité fixe réduirait la flexibilité de changement de modèle.
kimi-k3 derrière la même passerelle API unifiée que les autres modèles. L’équipe peut tester K3, laisser les tâches courantes aux modèles plus petits et conserver des fallbacks. Aucune capacité dédiée à K3 ne doit être achetée à l’avance. Les tarifs actuels sont sur la page Kimi K3 ; le guide API couvre les requêtes, le contexte, les outils et la migration.Un déploiement moins cher qui conserve l’option privée
Prenez la décision par étapes :
- Commencer avec du trafic API mesuré. Relever les entrées non cachées, lectures de cache, sorties, retries, latence et taux d’acceptation.
- Router de manière sélective. Laisser classification, réécriture et tâches simples aux petits modèles ; escalader les dépôts et tâches riches en outils vers K3.
- Construire le TCO avec la demande observée. Transformer 30 à 60 jours de tokens et de concurrence en besoins de capacité.
- Obtenir un vrai devis d’auto-hébergement. Inclure redondance et exploitation, pas uniquement la location d’accélérateurs.
- Réaliser une preuve de serving contrôlée. Valider qualité, débit, long contexte et reprise avant d’en faire un projet d’économies.
Cette séquence crée une référence de volume sans fermer la voie à un déploiement privé. Elle évite aussi d’acheter du matériel suffisant pour un benchmark, mais insuffisant pour la concurrence et l’astreinte en production.
FAQ
Kimi K3 est-il open source ?
Kimi K3 peut-il fonctionner sur un ordinateur portable ?
Pas comme modèle complet de 2,8 T dans une configuration de production pratique. Le dépôt seul représente environ 1,56 To et Moonshot recommande 64 accélérateurs ou plus pour une inférence efficace. Des dérivés plus petits peuvent apparaître, mais ce sont d’autres artefacts qui exigent leurs propres contrôles de qualité et de licence.
Puis-je tester gratuitement Kimi K3 via l’API officielle ?
Le centre d’aide chinois de Kimi indique que le coupon API de 15 ¥ offert aux nouveaux utilisateurs ne s’applique pas à K3. D’autres produits, promotions ou services tiers peuvent changer ; vérifiez leurs conditions actuelles.
Kimi K3 exige-t-il exactement 64 GPU ?
Moonshot recommande un supernœud de 64 accélérateurs ou plus pour une inférence efficace, sans en faire un minimum universel. La topologie réelle dépend de la mémoire, des formats, de l’interconnexion, du parallélisme, du contexte, de la concurrence et de la latence.
Quelle est la manière la moins chère d’évaluer Kimi K3 ?
Utilisez une API à l’usage sur un petit jeu de tâches représentatif, réutilisez des préfixes stables pour le cache, limitez raisonnablement la sortie et mesurez le coût par tâche acceptée. C’est généralement moins cher que de provisionner un cluster avant de connaître la demande et l’adéquation.
Quand une petite équipe doit-elle reconsidérer l’auto-hébergement ?
Lorsque le volume mensuel et la concurrence sont stables, qu’un devis réel existe, qu’un responsable du serving est désigné et que l’accès managé ne satisfait pas une exigence essentielle. Comparez le coût mensuel total et la fiabilité, pas seulement les tarifs par token.
Commencer avec EvoLink empêche-t-il un futur auto-hébergement ?
Non. Une API compatible fournit des données d’usage, de cache, de latence et de sortie pour planifier la capacité. Gardez l’adaptateur applicatif modulaire, conservez les jeux d’évaluation et traitez le backend d’inférence comme une route remplaçable.
