Reproduire Kimi K3

Cette partie répond à la question : avec ce que le rapport publie, jusqu'où peut-on aller pour réimplémenter Kimi K3 ?

Réponse courte : on peut réimplémenter l'architecture complète et la vérifier ; on ne peut pas reproduire le modèle.

Les trois niveaux de reproduction

Niveau	Ce que c'est	Faisable ?
1. Comprendre	Savoir ce que chaque module calcule, et pourquoi	✅ Entièrement
2. Réimplémenter	Écrire le code de l'architecture et le vérifier	✅ Presque entièrement
3. Reproduire	Obtenir un modèle de qualité comparable	❌ Impossible

Le niveau 3 échoue pour trois raisons, dans cet ordre d'importance :

1. Les données ne sont pas publiées, ni décrites quantitativement ;
2. Les hyperparamètres issus des lois d'échelle ne sont pas publiés ;
3. Le calcul requis se compte en dizaines de milliers de GPU-mois.

Ce que ce wiki apporte de plus que le rapport

Une reconstruction vérifiée. Les chiffres et les identités présentés ici ont été recalculés et testés, pas recopiés. Le script est fourni et exécutable sans aucune dépendance.

Ordre de lecture

#	Chapitre	Contenu
01	Ce qui est public et ce qui ne l'est pas	L'inventaire complet, module par module
02	Retrouver les 2,8 T de paramètres	Le calcul détaillé, vérifié à 0,2 %
03	Implémenter KDA	Pseudo-code de référence, testé
04	Implémenter AttnRes et LatentMoE	Block AttnRes, routage, Quantile Balancing
05	Un modèle jouet : nano-K3	Une configuration réduite, entraînable sur un GPU
06	Feuille de route de réimplémentation	L'ordre dans lequel construire, et comment vérifier chaque étape

Le script de vérification

Toutes les affirmations chiffrées de cette partie sont vérifiées par un script unique, en Python pur, sans aucune dépendance :

Télécharger : verif-kimi-k3.py

python3 verif-kimi-k3.py

Sortie obtenue :

[OK] KCP composition        erreur max = 6.94e-18
[OK] KCP balayage prefixe   erreur max = 1.39e-17  (4 rangs)
[OK] SiTU-GLU borne         max|f| = 100.000  <= b1*b2 = 100
[OK] SiTU vs SwiGLU local   ecart relatif max = 0.524 %
[OK] Quantile Balancing     desequilibre relatif (%), cible=512
       QB (sans hyperparam.) [10.5, 6.1, 4.3, 3.9, 3.5, 2.7, 2.7, 2.7]
       regle par signe       [10.5, 7.4, 4.9, 3.1, 3.5, 2.9, 3.1, 2.9]
[OK] Parametres             total = 2.779 T (papier 2,78 T)
                            actifs = 104.0 G (papier 104,2 G)
                            1 expert = 33.0 M | couche MoE = 29.78 G
                            couche MLA = 232.2 M | couche KDA = 440.4 M

Ce que ce script démontre

• L'identité de composition de KCP est exacte à la précision machine (\(10^{-18}\)) — la décomposition en transition cumulée + état local est mathématiquement correcte, pas une approximation.
• Le balayage préfixe sur 4 rangs redonne exactement le résultat d'une récurrence séquentielle unique.
• La borne de SiTU-GLU est atteinte exactement à \(\beta_1\beta_2 = 100\) et jamais dépassée, sur 200 000 tirages dans \([-500, 500]^2\).
• SiTU-GLU coïncide avec SwiGLU à 0,5 % près près de l'origine.
• Le décompte de paramètres reconstruit à partir du seul config.json donne 2,779 T / 104,0 G, contre 2,78 T / 104,2 G annoncés.

Ce que ce script ne démontre PAS

Sur Quantile Balancing, la reproduction à petite échelle (4 096 jetons, 16 experts) montre bien que QB réduit fortement le déséquilibre dès le premier pas et sans aucun hyperparamètre — mais elle ne reproduit pas l'avantage net sur la règle par signe que le rapport revendique à ~\(10^3\) experts.

C'est attendu : la règle par signe utilisée ici bénéficie d'un \(\gamma\) choisi à la main, et le régime problématique décrit par le rapport (896 experts, millions de jetons) n'est pas atteignable dans ce cadre.

Nous rapportons le résultat tel qu'obtenu, y compris là où il ne confirme pas le rapport.

---

Partie précédente : Évaluations · Partie suivante : Analyse critique