Kimi K3 sur 4GB : démêler 2,8 trillions de paramètres

Pouvez-vous réellement exécuter Kimi K3 sur un seul GPU 4GB ? Pas au sens ordinaire d'une "exécution locale". Les poids MXFP4 natifs de Kimi K3 requièrent environ 1,4 TB avant métadonnées et surcharge d'exécution. Une carte 4GB ne peut servir que de petit dispositif d'étape si un logiciel fait transiter de minuscules morceaux du modèle depuis le disque ou la mémoire hôte. C'est techniquement intéressant, mais ce n'est pas la même chose que de charger Kimi K3 dans 4GB de VRAM, et aucune recette Kimi K3 grand public actuelle n'en fait un configuration pratique.^[1][2]

Cette distinction compte car trois faits vrais sont souvent combinés en une conclusion trompeuse : Kimi K3 est creux, seuls 104B paramètres sont actifs par jeton, et les outils de déchargement par couche ont exécuté des modèles 70B plus petits sur GPU 4GB. Aucun de ces faits ne fait tenir un point de contrôle 2,8T sur 4GB. Ce guide fait le calcul mémoire, explique ce que le déchargement change vraiment, vérifie le support logiciel actuel et montre la route matérielle basse qui marche aujourd'hui.

Résumé rapide

• Kimi K3 a vraiment 2,8T de paramètres totaux. C'est un modèle clairsemé Mixture-of-Experts avec 104B de paramètres activés par jeton, 93 couches, 896 experts et une fenêtre de contexte de 1M jetons.^[1]
• MXFP4 ne le rend pas petit. Quatre bits par paramètre met le plancher brut du poids à environ 1,4 TB décimal, ou 1,27 TiB, avant échelles, métadonnées, tenseurs non-4-bit et état d'exécution.
• 104B actif est une figure de calcul, pas une figure de stockage. Le routeur peut choisir différents experts au jeton suivant, donc tous les experts doivent rester accessibles quelque part.
• Un GPU 4GB ne peut être qu'une zone d'étape. Le déchargement disque ou CPU déplace les morceaux du modèle à travers VRAM ; cela n'élimine pas le besoin de stocker le modèle complet.
• AirLLM ne documente pas actuellement le support de Kimi K3. Son exemple 4GB publié cible Llama 3 70B, tandis que Kimi K3 utilise une nouvelle architecture MoE multimodale personnalisée.^[4]
• La route pratique est une API. Un ordinateur portable bas de gamme peut appeler Kimi K3 via un point de terminaison compatible OpenAI pendant que le modèle s'exécute sur une infrastructure distante.

Réalité matérielle de Kimi K3 en un coup d'œil

Moonshot décrit Kimi K3 comme un modèle d'agent multimodal natif de poids ouvert construit sur Kimi Delta Attention, Residual Attention et Stable LatentMoE. Il active 16 des 896 experts routés pour chaque jeton et comprend un encodeur de vision MoonViT-V2.^[1][2]

Ces choix architecturaux réduisent le coût de calcul et de long contexte. Ils ne transforment pas un point de contrôle à l'échelle d'un billion en un modèle GPU pour consommateurs.

Pourquoi 2,8 trillions de paramètres MXFP4 ont encore besoin d'environ 1,4 TB

Le premier calcul est simple :

2,8 trillions de paramètres × 4 bits
= 11,2 trillions de bits
= 1,4 trillions d'octets
= environ 1,27 TiB

C'est une limite inférieure, pas une estimation complète de déploiement. Les vrais points de contrôle comportent aussi des échelles de quantification, des index, une configuration, des plongements, des tenseurs stockés à d'autres précisions, et l'encodeur de vision de 401M paramètres. L'exécution ajoute des activations, la mémoire de travail des experts sélectionnés, l'état d'attention, les noyaux CUDA ou NPU, et un budget KV ou d'état récurrent qui croît avec la concurrence et les paramètres de contexte.^[1]

Le point de contrôle officiel Hugging Face est divisé en de nombreuses grandes tranches safetensor ; les tranches individuelles listées sont mesurées en dizaines de gigaoctets. Une seule tranche peut dépasser la capacité entière d'une carte 4GB avant que le moteur d'inférence ait alloué un seul tampon d'activation.^[3]

Pour comparaison, une carte 4GB peut théoriquement contenir environ 8 milliards de paramètres 4-bit simples si chaque octet était disponible pour les poids. En pratique, elle peut en contenir moins car l'exécution a aussi besoin de mémoire. Kimi K3 est environ 350 fois plus grande par nombre total de paramètres.

Pourquoi "104B de paramètres actifs" ne signifie pas un modèle de 52GB

La clairsemé MoE réduit l'arithmétique, pas le point de contrôle que vous devez garder disponible. Kimi K3 route chaque jeton par un petit sous-ensemble de ses 896 experts, donc seuls 104B des 2,8T paramètres participent au passage avant de ce jeton. À quatre bits chacun, 104B de paramètres seuls représentent environ 52GB de données de poids avant surcharge d'exécution.

Même cette estimation de 52GB ne doit pas être confondue avec un mini-point de contrôle statique. Le jeton suivant peut choisir un ensemble d'experts différent. À moins que la charge n'épingle les choix d'experts—ce qui changerait le comportement du modèle—l'exécution a besoin d'accès au pool d'experts complet sur toute la séquence.

Il y a trois nombres séparés :

• 2,8T de paramètres totaux déterminent le stockage du point de contrôle complet.
• 104B de paramètres actifs se rapprochent du calcul et de l'accès aux données par jeton.
• 4GB de VRAM c'est seulement la quantité qui peut résider sur le GPU à un moment donné.

L'activation clairsemée rend Kimi K3 plus efficace qu'un modèle dense 2,8T. Elle ne rend pas le modèle complet un téléchargement 104B, et 104B est toujours bien au-delà d'un GPU 4GB.

Comment le déchargement par couche peut utiliser un GPU 4GB

Le déchargement par couche change où les poids attendent, pas combien de poids existent. Une boucle de déchargement de base ressemble à ceci :

1. Gardez la plupart des poids du modèle sur SSD ou dans RAM système.
2. Chargez la couche suivante requise ou une portion d'expert dans la mémoire GPU.
3. Exécutez cette partie du passage avant.
4. Éjectez la portion et chargez la suivante.
5. Répétez la séquence pour chaque couche et chaque jeton généré.

C'est ainsi qu'un modèle plus grand que VRAM peut s'exécuter du tout. AirLLM a popularisé le motif avec une démonstration Llama 3 70B sur GPU 4GB, décomposant un modèle en tranches par couche et chevauchant le chargement avec le calcul.^[4]

Kimi K3 rend le motif beaucoup plus difficile. Il a 93 couches, des centaines d'experts possibles, une pile d'attention KDA/MLA gérée personnalisée, une multimodalité native et plus d'un téraoctet de poids quantifiés. Une couche MoE complète peut elle-même être plus grande que 4GB, donc un moteur compatible aurait besoin de flux au niveau sous-couche ou expert—pas simplement du déchargement de couche ordinaire.

Le goulot d'étranglement de performance devient alors le mouvement de données. Générer un jeton peut déclencher de nombreuses lectures d'experts aléatoires ou semi-aléatoires sur des dizaines de couches. Même un SSD NVMe rapide est des ordres de magnitude plus lent que la mémoire accélérateur, et le même processus se répète pour le jeton suivant. Le déchargement peut faire démarrer une expérience ; il ne la rend pas interactive.

Pouvez-vous exécuter Kimi K3 sur un GPU 4GB avec AirLLM aujourd'hui ?

Non, selon son support publié et ses exemples au 1er août 2026. AirLLM documente Llama, Mixtral, Qwen, ChatGLM, Baichuan, Mistral, InternLM et les familles de modèles apparentées. Son résultat 4GB phare est Llama 3 70B, pas Kimi K3.^[4]

Cette absence compte. Kimi K3 n'est pas un plus grand point de contrôle Llama qu'un chargeur existant peut identifier automatiquement. Une implémentation fonctionnelle doit comprendre :

• Configuration de modèle personnalisée de Kimi K3 et noms de tenseurs ;
• Routage Stable LatentMoE sur 896 experts ;
• poids MXFP4 natifs et activations MXFP8 ;
• couches d'attention KDA et MLA gérée périodique ;
• sortie de raisonnement préservée et tour de vision multimodale ;
• partitionnement conscient des experts assez petit pour VRAM disponible.

Moonshot recommande actuellement vLLM, SGLang et TokenSpeed pour le déploiement Kimi K3. Elle ne répertorie pas AirLLM comme moteur pris en charge.^[1]

Cela ne prouve pas qu'un port 4GB communautaire est impossible. Cela signifie qu'un exemple Llama AirLLM copié n'est pas un tutoriel Kimi K3 reproductible aujourd'hui. Une affirmation crédible doit fournir une branche publique, un commit exact, des détails de stockage et RAM, une invite, une sortie, des jetons par seconde et la preuve que les poids officiels complets ont été utilisés.

À quoi ressemble un déploiement Kimi K3 validé

Les recettes Kimi K3 de production fonctionnent à l'échelle du cluster. Un guide vLLM-Ascend actuel valide un déploiement de contexte 131K sur quatre nœuds Atlas 800 A3, chacun avec seize NPU 64GB. Sa configuration 1M-contexte nécessite au moins huit tels nœuds.^[5]

Ce n'est pas un minimum universel—différents accélérateurs, moteurs, concurrence et limites de contexte changent les exigences—mais c'est un vérification de réalité utile. La configuration validée mesure la mémoire accélérateur agrégée en téraoctets, pas gigaoctets.

La bonne réponse matérielle dépend du fait que l'objectif soit une preuve d'exécution, une utilisation interactive, une livraison multi-utilisateurs ou un débit production. La phrase "s'exécute sur 4GB" est sans sens sans cet objectif.

Une liste de vérification pour évaluer n'importe quelle affirmation Kimi K3 4GB

Avant de suivre un tutoriel, recherchez des preuves qui répondent à ces questions :

1. Est-ce le point de contrôle officiel 2,8T ? Une distillation, mandataire ou modèle plus petit portant le nom Kimi n'est pas Kimi K3.
2. Où sont stockés les poids complets ? La réponse doit tenir compte de bien plus d'un téraoctet de stockage local ou réseau.
3. Combien de RAM système est requis ? "GPU 4GB" ne dit rien sur 512GB ou 1TB de mémoire hôte assis à côté.
4. Quel commit du moteur d'inférence supporte K3 ? Une commande pip install générique n'est pas suffisante pour une nouvelle architecture.
5. La vision est-elle prise en charge, ou seulement la langue ? Sauter l'encodeur de vision 401M change la surface du modèle testé.
6. Quelle longueur de contexte a été utilisée ? Une démo 64-jetons et une session 1M-jetons ont des besoins d'exécution radicalement différents.
7. Quel est le débit mesuré ? Exigez des jetons par seconde—ou par minute—plus le temps du premier jeton.
8. La réponse a-t-elle été vérifiée ? Un processus démarrant avec succès n'est pas une preuve qu'il a chargé les bons poids ou généré une sortie K3 cohérente.

Si une publication ne rapporte que VRAM, elle a omis les ressources qui rendent le tour possible.

Le moyen pratique d'utiliser Kimi K3 à partir d'un ordinateur GPU 4GB

La route qui marche aujourd'hui est de garder l'inférence distante et d'utiliser l'ordinateur bas de gamme comme client. Le GPU local est sans importance ; tout ce qu'il faut c'est une connexion réseau et une clé API.

reAPI expose Kimi K3 via un point de terminaison Chat Completions compatible OpenAI :

curl https://api.reapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $REAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {
        "role": "user",
        "content": "Explain how expert routing changes memory access in a sparse MoE model."
      }
    ],
    "reasoning_effort": "high",
    "stream": true
  }'

Ce n'est pas l'inférence locale, et ne doit pas être commercialisé comme tel. C'est la réponse pratique pour les développeurs qui veulent la capacité Kimi K3 sans acquérir et opérer un cluster accélérateur multi-nœud. Le contrat de demande complet est dans la documentation de l'API Kimi K3, avec les taux en direct sur la page du modèle.^[6]

Si vous voulez toujours expérimenter avec le déchargement local

Traitez-le comme une recherche système, pas une installation en une commande. Une liste de préflight réaliste est :

• au moins 1,5–2TB de stockage rapide libre pour le point de contrôle, les caches et les artefacts de conversion ;
• assez de bande passante et de patience pour télécharger de nombreuses grandes tranches ;
• une branche du moteur d'inférence qui supporte explicitement l'architecture Kimi K3 et le format MXFP4 ;
• un plan pour RAM hôte, mappage mémoire, cache de page et endurance SSD ;
• mode langue uniquement si l'exécution expérimentale n'a pas implémenté la vision ;
• contexte court et minuscules sorties pour la première validation ;
• instrumentation pour lectures disque, utilisation GPU, temps du premier jeton et exactitude de sortie.

N'inventez pas une commande fonctionnelle en remplaçant un ID de modèle Llama par moonshotai/Kimi-K3. Jusqu'à ce que le moteur de déchargement supporte explicitement K3, le résultat le plus probable est une configuration non prise en charge, une inadéquation de tenseur ou un échec de mémoire insuffisante lors de la conversion.

FAQ

Kimi K3 peut-il vraiment s'exécuter sur un GPU 4GB ?

Non comme un modèle local autonome et pratique. Un futur moteur spécialisé pourrait utiliser 4GB VRAM comme tampon d'étape tout en faisant transiter les poids d'un stockage ou RAM beaucoup plus grand, mais le modèle complet ne tient pas et les recettes 4GB grand public actuelles ne documentent pas le support de Kimi K3.

Quelle est la taille des poids de Kimi K3 ?

Le plancher théorique pour 2,8T de paramètres à quatre bits chacun est environ 1,4 TB décimal, ou 1,27 TiB. Le vrai point de contrôle et l'exécution ont besoin de plus à cause des métadonnées de quantification, des tenseurs non-4-bit, de l'encodeur de vision et de l'état d'exécution.

Pourquoi Kimi K3 dit-il que seuls 104B paramètres sont actifs ?

Kimi K3 est un modèle MoE clairsemé. Chaque jeton utilise un sous-ensemble d'experts, réduisant le calcul, mais les jetons futurs peuvent choisir différents experts. Le pool d'experts 2,8T complet doit toujours rester accessible.

MXFP4 signifie-t-il que n'importe quel GPU avec 4GB peut l'exécuter ?

Non. MXFP4 signifie que les poids principaux utilisent environ quatre bits par valeur. Quatre bits fois 2,8 trillions c'est toujours environ 1,4 TB avant surcharge.

AirLLM peut-il exécuter Kimi K3 ?

AirLLM ne répertorie pas actuellement Kimi K3 parmi ses familles de modèles documentées ni ne fournit une recette Kimi K3. Son exemple 4GB est pour Llama 3 70B. Le support pourrait être ajouté plus tard, mais ne doit pas être supposé du chargeur de modèle générique.

Quel est le moyen le moins cher et pratique d'utiliser Kimi K3 ?

Pour une utilisation occasionnelle ou de développement, utilisez une API par jeton hébergée. L'auto-hébergement ne devient rationnel que lorsque le contrôle, le volume soutenu ou les besoins de localisation des données justifient le matériel multi-nœud et le travail opérationnel.

Puis-je exécuter une version plus petite de Kimi K3 localement ?

Les distillations communautaires peuvent apparaître, mais ce sont des modèles séparés avec des poids et une capacité différents. Si l'exigence est un assistant local 4GB, choisissez un modèle conçu pour ce budget mémoire et étiquetez-le précisément.

Le sens honnête d'exécuter Kimi K3 sur un GPU 4GB

Exécuter Kimi K3 sur un seul GPU 4GB n'est crédible que sous une définition étroite : le GPU détient une petite pièce tandis que le reste d'un point de contrôle d'environ 1,4TB vit ailleurs et passe à travers lui. Cela peut devenir une démonstration de recherche précieuse, mais ce n'est pas un déploiement local pratique aujourd'hui.

Le titre est incroyable car il omet la machine autour du GPU : SSD, RAM système, moteur personnalisé, temps de transfert et souvent infrastructure distante. Comptez toutes ces ressources avant de juger l'affirmation. Si l'objectif est d'utiliser Kimi K3 plutôt que d'étudier le déchargement extrême, l'API est la route qui marche sur un ordinateur portable 4GB maintenant.

Divulgation : reAPI publie cet article et offre un accès API Kimi K3 hébergé. Les faits d'architecture et de quantification proviennent du référentiel officiel de Moonshot et du rapport technique. L'évaluation 4GB est dérivée de ces spécifications, de la documentation actuelle du moteur et d'une arithmétique de stockage basique ; ce n'est pas une affirmation que reAPI a reproduit une génération complète Kimi K3 sur un GPU 4GB.

Références

1. Moonshot AI. Référentiel officiel Kimi K3 — architecture, résumé du modèle, MXFP4 natif et moteurs d'inférence recommandés. Récupéré le 1er août 2026. github.com/MoonshotAI/Kimi-K3
2. Kimi Team. Kimi K3: Open Frontier Intelligence. Publié en juillet 2026. arxiv.org/abs/2607.24653
3. Moonshot AI. Poids officiels Kimi K3 et fiche modèle. Récupéré le 1er août 2026. huggingface.co/moonshotai/Kimi-K3
4. AirLLM. Familles de modèles pris en charge et exemple de déchargement par couche Llama 3 70B 4GB. Récupéré le 1er août 2026. github.com/lyogavin/airllm
5. vLLM Ascend. Guide de déploiement multi-nœud Kimi K3 validé. Récupéré le 1er août 2026. docs.vllm.ai/projects/ascend/tutorials/models/Kimi-K3
6. reAPI. Référence API Kimi K3 et page modèle actuelle. Récupéré le 1er août 2026. reapi.ai/docs/kimi-k3 et reapi.ai/models/kimi-k3

Lectures supplémentaires

• reAPI. Kimi K3 : Guide complet du phare 2,8T de Moonshot. reapi.ai/blog/kimi-k3-complete-guide
• reAPI. Meilleurs modèles vidéo IA open source pour GPU locaux. reapi.ai/blog/best-open-source-ai-video-models-local-gpu-2026
• Moonshot AI. Référentiel officiel Kimi K3. github.com/MoonshotAI/Kimi-K3