Pourquoi un GPU reste indispensable, même quand un CPU fait tourner 2 800 milliards de paramètres
TL;DR
kimi-k3-in-c fait tourner un modèle de 2 800 milliards de paramètres sur un CPU avec 8 Go de RAM. Le prix : 10 à 32 secondes pour produire un seul mot. Ce n'est pas un défaut qu'une prochaine version corrigera, c'est la conséquence directe de lire un modèle depuis un disque plutôt que depuis une mémoire pensée pour ça. Un GPU reste, et restera, la seule façon de faire ce calcul à une vitesse utilisable. La démocratisation que ce projet démontre a une limite dure, et c'est une limite matérielle.
Ce que l'exploit démontre
kimi-k3-in-c charge un modèle de 1,56 To sur une machine à 8 Go de RAM en gardant en mémoire uniquement ce qui sert dans l'instant : un tronc dense compact, et les 16 experts sur 896 que le routeur vient de désigner. Le reste attend sur le disque. C'est une preuve de faisabilité solide, testée et documentée. Ce n'est pas une preuve que le GPU est devenu accessoire.
Le chiffre qui casse le rêve
32,7 secondes par mot avec 8 Go de RAM. 10,7 secondes par mot avec 128 Go. Pour écrire une réponse de 100 mots, il faut compter entre 18 minutes et une heure de calcul. Un GPU produit la même réponse en quelques secondes.
Aucun réglage ne comble cet écart. Multiplier la RAM allouée par seize, de 8 à 128 Go, ne fait gagner qu'un facteur trois sur la vitesse. Le rendement décroît vite, parce que la RAM n'attaque pas la vraie cause du ralentissement.
Pourquoi c'est structurel, pas un défaut d'optimisation
Le temps de génération est dominé par la lecture disque, pas par le calcul. Un SSD NVMe lit autour de 7 gigaoctets par seconde. Une carte graphique haut de gamme lit sa propre mémoire, la VRAM, à plus de 3 000 gigaoctets par seconde, l'équivalent d'un facteur 400.
Un GPU n'accélère pas seulement les multiplications, il les fait en parallèle sur des milliers de cœurs, avec les données déjà à portée de calcul dans une mémoire conçue pour ça. Un CPU qui streame ses poids depuis un disque, aussi bien écrit soit le code, reste soumis à la vitesse de ce disque. Ce n'est pas un problème que du code plus malin résout, c'est une différence de matériel que le code ne fait que contourner du mieux possible.
Ce qu'un GPU fait que ce hack ne peut pas faire
Un GPU garde le modèle entier, ou l'essentiel de ses poids actifs, dans une mémoire aussi rapide que ses unités de calcul. Il traite plusieurs requêtes en parallèle sans perdre en latence par requête. Il alimente un chatbot, une API en production, un agent qui enchaîne des dizaines d'appels par tâche : des usages où la réponse doit arriver en secondes, pas en dizaines de minutes.
kimi-k3-in-c ne vise aucun de ces usages, et le dépôt ne le prétend pas. Le nom du préréglage le plus lent, laptop, décrit une démonstration, pas un poste de travail.
Où cette approche a sa place
Streamer un modèle depuis le disque sert quand la latence n'est pas le problème à résoudre : vérifier qu'un modèle open source répond correctement sans louer un cluster, auditer un checkpoint en environnement isolé sans connexion réseau, ou simplement comprendre l'architecture d'un moteur d'inférence en le lisant plutôt qu'en l'important comme boîte noire. Ces usages existent, et kimi-k3-in-c les sert bien.
Une limite matérielle, pas logicielle
Le disque le plus rapide restera toujours plus lent que la mémoire d'un GPU, parce qu'il n'est pas conçu pour la même tâche. Aucune couche logicielle, aussi ingénieuse soit-elle, ne referme un écart de facteur 400 en bande passante. kimi-k3-in-c démocratise l'accès au poids d'un modèle, à sa lecture, à sa compréhension. Il ne démocratise pas sa vitesse, et rien dans son architecture ne prétend le faire. Pour produire une réponse en quelques secondes, il faudra toujours un GPU.