L’essentiel
- Unsloth AI a compressé Kimi K3 de 1,56 To à 594 Go, soit 62 % de poids en moins, en conservant environ 78,9 % de la précision d’origine.
- L’équipe annonce une exécution locale sur un Mac Studio doté de 128 Go de RAM, très loin des 594 Go du fichier.
- Les démonstrations publiées tournaient sur quatre accélérateurs B200 à 36 tokens par seconde, face à Claude Opus 5 et GPT 5.6.
- Un autre essai a fait tourner le modèle en open weight sur huit B300 pour zéro dollar de dépense d’API.
Unsloth AI a fait tenir Kimi K3 dans 594 Go. Le fichier de poids d’origine en pesait 1,56 To, et l’équipe annonce environ 78,9 % de la précision conservée sur une variante qualifiée de 1-bit. L’annonce enchaîne aussitôt sur une promesse plus spectaculaire : « exécutez-le sur un Mac Studio doté de 128 Go de RAM ».
594 Go pour un modèle présenté en 1-bit
Reprenons le calcul. Kimi K3 aligne 2 800 milliards de paramètres, dont 104 milliards s’activent à chaque token. Une quantification (la réduction de la précision numérique des poids) réellement uniforme à 1 bit par paramètre donnerait un fichier de l’ordre de 350 Go. Unsloth publie 594 Go, soit près du double.
L’écart n’est pas une erreur de calcul : l’étiquette 1-bit désigne le traitement le plus agressif appliqué à certaines couches, pas le format du fichier entier. La moyenne réelle tourne autour de 1,7 bit par paramètre, les couches sensibles restant préservées à une précision supérieure. Et c’est précisément ce qui rend les 78,9 % annoncés crédibles : à 1 bit partout, un modèle de ce calibre ne tiendrait pas debout.
Le point de départ mérite lui aussi un regard. 1,56 To pour 2 800 milliards de paramètres, cela fait environ 4,5 bits chacun : Moonshot AI a entraîné son modèle directement en MXFP4, un format sur 4 bits dont les facteurs d’échelle par bloc gonflent un peu le total. Les 62 % économisés se mesurent donc face à un fichier déjà compact, pas face à une version haute précision.
Une précision conservée, mais sans détail des tests
Ce pourcentage est un ratio, pas un score de benchmark : il compare la version compressée à la version d’origine, sans que l’annonce précise les tests employés. Un agrégat de ce type indique combien on perd, jamais où la perte se loge.
L’indication la plus utile publiée par Unsloth se trouve ailleurs : les versions quantifiées continuent d’émettre des appels d’outils corrects et de résoudre des tâches entières en une seule passe. Pour un usage en boucle d’agent, cette capacité pèse plus lourd qu’un point de score. Un modèle qui produit un appel de fonction malformé une fois sur cinq reste inutilisable dans une chaîne automatisée, quel que soit son classement.
Le revers tient à la nature des démonstrations. Un aquarium en verre qui se fissure puis éclate, un labyrinthe de Pac-Man avec quatre fantômes qui traquent le joueur, un Snake reconstruit en 3D : autant de générations obtenues en une seule tentative, sur des exercices où un modèle se montre sous son meilleur jour. La comparaison face à Claude Opus 5 et GPT 5.6 a par ailleurs été conduite par l’équipe qui signe la compression, avec ses propres consignes. Rien de disqualifiant là-dedans, mais l’évaluateur est aussi l’auteur.
Le choix des adversaires compte autant que le résultat. Sur l’indice d’intelligence d’Artificial Analysis, Kimi K3 se range derrière Claude Fable 5 et GPT 5.6 Sol ; il prend en revanche la première place du Frontend Code Arena, devant ces deux mêmes modèles. Selon l’épreuve retenue, le même modèle sort gagnant ou battu.
128 Go de RAM annoncés, 594 Go à charger
Le grand écart de l’annonce tient dans deux nombres : 594 Go de poids pour une machine dotée de 128 Go de mémoire unifiée. Le fichier ne rentre pas, et de loin : un facteur 4,6 les sépare. La documentation d’Unsloth recommande d’ailleurs 610 Go de mémoire cumulée pour cette version.
Les poids doivent donc être lus par blocs depuis le stockage à chaque passe de génération. C’est faisable, et c’est ce qui rend l’affirmation défendable. En revanche, le débit n’est plus gouverné par la mémoire de la machine mais par son SSD.
D’où le second décalage, plus gênant. Les 36 tokens par seconde mis en avant ont été mesurés sur quatre accélérateurs B200, du matériel de centre de données. L’essai des jeux d’arcade, lui, tournait sur huit B300. La machine accessible et la vitesse annoncée ne viennent pas du même matériel, et aucune mesure de débit sur le Mac Studio n’accompagne l’annonce.
Zéro dollar d’API, et la facture qui se déplace
Le test des trois jeux d’arcade avance un chiffre imbattable : zéro dollar de dépense d’API, pour une qualité jugée au niveau du modèle cloud mis en face. Le montant est exact ; il ne mesure simplement rien de ce qui coûte réellement. Huit B300 alignés relèvent de l’immobilisation d’entreprise : achat, électricité, refroidissement et taux d’utilisation à tenir.
Le calcul qui compte porte ailleurs : à partir de combien de tokens par mois un parc possédé passe-t-il devant une facture au compteur ? La réponse dépend du volume et de la régularité de la charge. Une équipe qui consomme par rafales n’atteindra pas ce seuil au même moment qu’une plateforme qui tourne en continu.
Le seuil d’entrée matériel devient l’arbitre
Ce que déplace cette compression, c’est la liste de ceux qui peuvent héberger un modèle de ce calibre. Tant qu’un modèle frontière en open weight (poids publiés et téléchargeables librement) réclame 1,56 To, il reste la propriété de fait des acteurs qui exploitent des baies de GPU. À 594 Go, l’obstacle devient budgétaire plutôt que structurel, et il change de nature dans tous les secteurs où le blocage n’a jamais été le prix du token : santé, défense, juridique, industrie sous secret. Dans ces environnements, l’argument décisif tient en une phrase : les poids et les requêtes ne sortent pas du bâtiment.
Le palier suivant se mesurera en gigaoctets de mémoire unifiée bien plus qu’en points de précision. Le jour où une machine unique tient ces 594 Go sans aller les chercher sur son disque, l’arbitrage entre API facturée et exécution maison se jouera sur un terrain différent. Pour l’instant, le Mac Studio de l’annonce reste un argument de démonstration.
Mon avis
Une équipe extérieure vient de redimensionner un modèle frontière sans demander la permission à personne, et cela compte davantage que ses scores. Des poids ouverts, ça se recompresse, ça se redéploie, et aucun éditeur ne reprend la main dessus après publication. Je situe la prochaine ligne de front exactement là, sur le matériel d’entrée plutôt que sur les classements : le jour où une intelligence de ce niveau tient sur une machine qu’on peut commander, l’accès par API cesse d’être une évidence commerciale et redevient un choix. Ces 594 Go sont une marche de plus dans cette direction.
