Études de cas¶
Six démonstrations publiées dans le rapport. Elles sont plus parlantes que les scores, mais aussi plus sujettes à la sélection : ce sont, par construction, les meilleures réussites.
Comment lire ces cas
Une étude de cas prouve qu'une chose est possible, pas qu'elle est fiable. Aucune n'indique combien de tentatives ont été nécessaires.
Deux d'entre elles échappent partiellement à cette critique : le compilateur et la puce, dont le code est publié et donc auditable.
1. Optimisation de noyaux GPU¶
Le protocole¶
Chaque modèle travaille indépendamment dans une sandbox configurée à l'identique, avec un budget allant jusqu'à 24 heures par tâche pour profiler, réécrire et mesurer.
Quatre noyaux représentatifs, sur un GPU NVIDIA Hopper et un GPGPU d'un autre fournisseur :
| Noyau | Résultat obtenu par Kimi K3 |
|---|---|
| AttnRes | Latence réduite de 283,6 ms → 114,4 ms (×2,5) |
| DSA (DeepSeek Sparse Attention) | Temps d'exécution −55,1 % |
| KDA | Temps d'exécution −73,6 % |
| MLA (dimension de tête 512) | Plus de la moitié du pic de TFLOPS atteint |
Comparaison : Kimi K3 égale Claude Fable 5 (avec repli) et dépasse substantiellement Claude Opus 4.8, GPT-5.6 Sol et GPT-5.5.
Le détail le plus significatif
Beyond the benchmark, an early Kimi K3 checkpoint was already handling most of our kernel optimization work during late-stage development.
Ce n'est pas une démonstration : c'est un usage en production interne. Un checkpoint précoce de K3 faisait déjà l'essentiel du travail d'optimisation de noyaux de l'équipe qui construisait K3.
Deux des quatre noyaux optimisés — AttnRes et KDA — sont des composants de sa propre architecture. La boucle se referme.
2. Développement d'un compilateur GPU : MiniTriton¶
Kimi K3 a développé MiniTriton, un compilateur compact de type Triton.
Ce qu'il contient¶
| Composant | Description |
|---|---|
| Frontend | DSL Python au niveau des tuiles, avec système de layout personnalisé |
| Couche intermédiaire | Annotation et optimisation MLIR légères, au niveau des warps |
| Backend | Pipeline de génération de code PTX |
| Bibliothèque de tenseurs | Interface haut niveau de type PyTorch, en mode eager et compilé forward-only, partageant le même compilateur DSL et le même runtime |
| Extras | Autograd en mode inverse, modules de réseaux de neurones, primitives d'entraînement distribué sur NCCL, primitives éparses et de visualisation |
Les résultats mesurés¶
Sur un NVIDIA L20 :
| Mesure | Résultat |
|---|---|
Face à PyTorch eager et torch.compile |
Supérieur en moyenne géométrique sur sa suite de bancs |
| Chemin matmul tensor-core écrit de zéro | Approche cuBLAS aux plus grandes formes, ~90 % du toit machine mesuré |
| Noyau de prefill KDA au niveau DSL | Dépasse nettement une référence Triton équivalente |
| Entraînement d'un GPT de bout en bout | Courbe de perte suivant de près la référence PyTorch |
| Gradients de modèle complet | Écart avec l'autograd torch ≤ 10⁻⁴, soit l'erreur d'arrondi fp32 de torch elle-même, mesurée contre une référence fp64 |
Ce que cela démontre réellement
Le rapport le formule bien : cela montre que Kimi K3 peut construire un compilateur cohérent de bout en bout — du frontend DSL aux passes d'IR, puis à la génération PTX et au runtime CUDA — et non une collection de noyaux isolés.
La différence est majeure. Écrire un noyau optimisé est une tâche locale ; construire un compilateur exige de maintenir une cohérence sémantique à travers plusieurs niveaux de représentation.
Code publié : github.com/MoonshotAI/minitriton
3. Conception de puce : nano-kpu¶
L'étude de cas la plus spectaculaire.
La tâche¶
Concevoir un prototype de puce d'inférence pour un nano-modèle suivant la même architecture que Kimi K3 :
- attention hybride KDA et MLA en NoPE ;
- Block AttnRes avec une taille de bloc de 2 ;
- routage MoE à base de sigmoïde, un expert partagé ;
- quantification de poids INT4 par groupes de 128.
Les conditions¶
Une seule exécution autonome de 48 heures avec Kimi Code. Le modèle a construit, optimisé et vérifié la puce avec des outils EDA open source et la bibliothèque de cellules standard Nangate45.
Le résultat¶
| Métrique | Valeur |
|---|---|
| Budget de surface analytique | 4 mm² — respecté |
| Fermeture du timing | 100 MHz |
| Débit de décodage simulé au niveau RTL | > 8 700 jetons/s |
| Cellules standard intégrées | 1,46 million |
| SRAM | 0,277 Mio |
| Unité de calcul | Réseau MAC INT4 avec déquantification fusionnée |
RTL publié : github.com/MoonshotAI/nano-kpu
Pourquoi cette étude de cas est la plus solide
Elle est auditable. Le RTL est public. La fermeture de timing, la surface et le débit sont des propriétés vérifiables par quiconque dispose de la chaîne EDA open source.
Contrairement à une démonstration de raisonnement, il n'y a pas de place pour l'interprétation : soit le design ferme le timing à 100 MHz dans 4 mm², soit il ne le fait pas.
Les limites à garder
- C'est un prototype pour un nano-modèle, pas une puce de production.
- 100 MHz est très lent pour du silicium moderne (les accélérateurs commerciaux tournent à plusieurs GHz).
- Nangate45 est une bibliothèque académique en 45 nm, pas un nœud de fonderie moderne.
- Le rapport dit « preuve de concept précoce » — ce qu'il faut prendre au mot.
Cela reste, à notre connaissance, la première démonstration publiée d'un modèle de langage concevant et vérifiant une puce complète en autonomie.
4. Code pour la recherche : les relations I–Love–Q¶
Pour reproduire les relations universelles I–Love–Q en astrophysique computationnelle, Kimi K3 a :
- passé en revue plus de 20 articles et croisé leurs résultats ;
- implémenté le pipeline numérique complet ;
- évalué plus de 300 équations d'état ;
- identifié des incohérences dans des formules publiées ;
- écrit plus de 3 000 lignes de Python ;
- produit un tableau de bord HTML interactif.
En environ deux heures, contre « une à deux semaines pour un chercheur expérimenté ».
Le point le plus intéressant
« Identifié des incohérences dans des formules publiées » est plus remarquable que la vitesse. Cela exige de croiser plusieurs sources et de détecter une contradiction — pas seulement d'exécuter une procédure.
La réserve
Aucune de ces incohérences n'est nommée dans le rapport, ni vérifiable. C'est une affirmation non étayée, contrairement aux cas 2 et 3.
5. Travail de connaissance¶
Deux cas dans Kimi Work.
Cas A — Site de recherche sur l'industrie des ASIC d'IA. Couvrant 42 ans d'histoire, produit en plus de 120 tours de raffinement itératif, à partir d'un corpus de 87 rapports trimestriels et 99 PDF originaux (plus de 11 000 pages), via plus de 2 800 recherches web et plus de 1 100 requêtes de terminal.
Cas B — Analyse d'ondes gravitationnelles. Analyse de 391 événements du catalogue GWTC-5, en utilisant plus de 20 sous-agents concurrents, produisant sept visualisations scientifiques, deux tableaux de synthèse et une synthèse bibliographique de plus de dix articles.
Ce que ces chiffres illustrent
Le cas A est la meilleure illustration concrète du régime « long horizon » : 2 800 recherches web et 1 100 commandes de terminal dans une seule tâche. C'est exactement le comportement que les environnements RL visaient à entraîner.
Le cas B illustre l'orchestration en essaim — cohérente avec le premier rang de K3 sur Swarm Bench (76,3).
6. Montage vidéo et motion design¶
En exploitant son architecture multimodale native, Kimi K3 a :
- créé un explicatif en motion design de style 3Blue1Brown portant sur sa propre architecture ;
- monté sa vidéo teaser à partir de 56 clips sources, ce qui impliquait sélection de plans, coupes calées sur le mouvement, synchronisation rythmique à la frame, traitement audio et plusieurs tours de révision.
Le rapport estime qu'un monteur expérimenté mettrait « un à deux jours » pour une vidéo courte de densité comparable.
Le lien architectural
C'est le cas d'usage qui justifie le plus directement la multimodalité native : le modèle doit voir les images pour choisir les coupes, et écrire le code de montage — dans le même flux de jetons, sans passage de relais.
Synthèse¶
| # | Cas | Auditable ? | Ce qu'il démontre |
|---|---|---|---|
| 1 | Noyaux GPU | Partiellement (chiffres, pas de code) | Optimisation de bas niveau, usage interne réel |
| 2 | MiniTriton | Oui (code publié) | Construction d'un système cohérent multi-niveaux |
| 3 | nano-kpu | Oui (RTL publié) | Autonomie sur 48 h, domaine matériel |
| 4 | I–Love–Q | Non | Recherche computationnelle, revue critique |
| 5 | Travail de connaissance | Non | Long horizon extrême, orchestration |
| 6 | Vidéo | Non | Multimodalité en boucle |
La réserve générale
Ces six cas sont sélectionnés. Aucun n'indique le nombre de tentatives, le taux de réussite, ni le degré d'intervention humaine dans la formulation des consignes.
Les cas 2 et 3 sont les seuls dont le résultat est vérifiable de bout en bout. Ce sont, sans surprise, les plus convaincants.
Chapitre précédent : Cybersécurité
Fin de la partie Évaluations. Suite : Reproduire Kimi K3.