Kimi K3 sur MacBook M1 : ce qui compte vraiment

Ils ont réussi à exécuter Kimi K3 en local, mais c’est une histoire de limites matérielles, pas de confort

Le fait le plus important ici est simple : dans un post Reddit, l’utilisateur écrit qu’il a chargé tous les 1,45 To d’experts sur un disque local et a amélioré l’inférence sur un M1 Mac à 16 secondes par token, contre environ une minute auparavant. Le prefill, selon lui, est tombé de 2429 secondes à 40. Ce n’est plus « totalement inutilisable », mais une démonstration claire de l’endroit exact où le modèle bute contre le système.

La source n’est pas un benchmark officiel, mais une mise à jour d’un post de la communauté LocalLLaMA. Et il est crucial de garder cela à l’esprit : je ne prendrais pas ces chiffres comme la norme pour Kimi K3, mais en tant que signal d’ingénierie, ils sont excellents. Si après profilage et ajustements de l’alimentation des données, l’accélération est aussi grande, c’est que le goulot d’étranglement n’était pas seulement dans la multiplication matricielle.

Au-delà, le tableau correspond à ce qu’on lit habituellement dans les analyses publiques de Kimi K3 : c’est un MoE de 2,8 billions de paramètres, avec 16 experts sur 896 actifs par token. Sur le papier, cela semble être une façon de rendre un géant « moins cher » à l’inférence. En pratique, le poids du modèle ne disparaît pas, et la classe mémoire de 1,4 To pour charger les poids reste la contrainte principale.

Et là, Apple Silicon est intéressant non pas par magie, mais par son profil de goulots d’étranglement. Pour de tels modèles MoE, le problème n’est souvent pas que la puce soit trop faible, mais que la livraison des bons poids et la répartition des experts commencent à dicter tout le reste.

Ce que cela change pour les LLM locaux et où s’arrête le battage médiatique

Ma conclusion est brève : cette nouvelle compte comme une preuve de douleur, pas comme une preuve de faisabilité pratique. Oui, on peut d’une manière ou d’une autre démarrer un modèle MoE super-grand localement, même sur du matériel de classe M1, mais cela ne fait pas de cette exécution un scénario de travail réaliste.

La première conséquence est évidente : optimiser le pipeline, le stockage et le prefill peut changer des ordres de grandeur. Si le prefill passe de 2429 à 40 secondes, alors le travail d’ingénierie autour de l’inférence est parfois plus important qu’un nouveau débat sur « quel backend est le plus rapide ».

La deuxième est moins évidente : pour Apple Silicon, la conversation sur les grands MoE tourne de plus en plus autour de la bande passante mémoire, de la répartition des experts et des stratégies de partitionnement, pas des FLOPS bruts. Ainsi, même de bons résultats sur des stacks de type MLX n’annulent pas le problème de base : le modèle est tout simplement trop gros pour un mode local confortable.

Et le troisième point, le plus lucide : l’auto-hébergement de tels modèles reste une histoire d’expériences très spéciales ou à l’échelle d’un cluster. Mais le simple fait que les gens parviennent déjà à passer de minutes à des dizaines de secondes montre une direction assez claire : l’avenir de l’inférence locale ne sera pas décidé uniquement par les nouvelles puces, mais par la capacité à réduire agressivement le mouvement des poids. C’est là que se produit la véritable magie en ce moment, sans aucun romantisme.

Nous avons déjà parlé de Rust LocalGPT, un assistant local en un seul fichier binaire qui ne nécessite pas de cloud et fonctionne directement sur la machine de l’utilisateur. C’est une étape naturelle dans la même direction que l’expérience avec Kimi K3 sur MacBook.