Il y a un an, faire tourner un modèle de langage à mille milliards de paramètres voulait dire une salle serveurs. Des baies, du refroidissement, une facture d'électricité qui méritait sa propre réunion. Puis AMD a publié un compte rendu technique montrant quatre mini PC posés sur un bureau (le genre qu'on peut porter deux à la fois) accomplissant le même travail. Quatre petits boîtiers identiques, reliés par des câbles, exécutant un modèle avec plus de paramètres qu'il n'y a d'étoiles visibles depuis une rue de ville.
Le titre s'écrit tout seul : « Pas de cloud. Pas de centre de données. » Et c'est vrai. AMD a bel et bien fait tourner un modèle à 1.04 trillion de paramètres sur quatre systèmes Framework Desktop avec du silicium grand public à l'intérieur.
Mais il y a une partie que le titre a sautée, et c'est elle qui décide si c'est une étape marquante ou un tour de magie. Il y a un détail d'architecture qui rend « mille milliards de paramètres » techniquement honnête, un hic qui détermine si vous pourriez vraiment utiliser cette chose, et une raison qui compte plus que ce que lui accordent le battage ou la critique.
La version courte
- Le modèle est Kimi K2.5, et c'est une conception Mixture-of-Experts : 1.04 trillion de paramètres au total, mais seulement environ 32 billion d'entre eux s'activent sur un jeton donné. « Modèle à mille milliards de paramètres » est exact ; le calcul par jeton est plus proche d'une charge de classe 32B.
- Le cluster génère autour de 8 à 9.5 jetons par seconde, avec un délai jusqu'au premier jeton allant de 39.7 à 239.1 secondes selon la longueur de votre prompt. Convenable pour du travail par lots. Brutal pour une boucle de codage interactive.
- Ce qui a changé, ce n'est pas la vitesse. C'est que la mémoire unifiée a mis l'inférence à l'échelle de pointe sur du matériel qu'on peut acheter et poser sur une étagère, une catégorie qui démarrait autrefois à « posséder un centre de données ».
Ce qu'AMD a réellement fait
Le montage est presque anticlimactique une fois qu'on le voit exposé. Quatre machines Framework Desktop , chacune embarquant un Ryzen AI Max+ 395 et 128 GB de mémoire unifiée LPDDR5X. Dans le BIOS, chaque nœud peut exposer jusqu'à 96 GB en VRAM dédiée, soit 384 GB sur les quatre nœuds ; le guide Linux d'AMD utilise ensuite des réglages TTM/noyau pour porter cela à 120 GB par nœud, soit 480 GB au total. Cela compte, car le build GGUF Kimi K2.5 UD_Q2_K_XL qu'AMD a utilisé est répertorié à 375 GB, pas 240 GB.
Le liant, c'est llama.cpp tournant en mode RPC : un nœud contrôleur et trois serveurs RPC, avec le modèle réparti sur les quatre machines. AMD indique l'interconnexion comme un Ethernet à 5 Gbps, ce qui correspond au port Ethernet 5Gbit intégré du Framework Desktop. Voilà tout l'attelage. Pas d'interconnexion exotique, pas de cartes sur mesure, rien que vous ne puissiez commander cet après-midi.
Le mot intéressant dans tout cela, c'est unifiée. Sur un PC normal, la RAM de votre CPU et la VRAM de votre GPU sont des pools séparés, et un modèle trop gros pour la VRAM soit déborde vers la mémoire système lente, soit ne tourne pas. La mémoire unifiée fait tomber ce mur : le GPU peut adresser la banque entière, ce qui est la raison même pour laquelle un ordinateur de bureau de 4.5 litres peut contenir un morceau d'un modèle de cette taille en premier lieu.
Le propre compte rendu technique d'AMD couvre la configuration en détail. Ce qu'il ne couvre pas vraiment, c'est pourquoi « mille milliards de paramètres » fait plus de travail rhétorique qu'il n'y paraît.
Le tour de passe-passe : pourquoi « mille milliards de paramètres » est vrai mais pas toute la vérité
Voici ce sur quoi la fiche technique s'appuie sans l'expliquer : Kimi K2.5 est un modèle Mixture-of-Experts, et cela change ce que « mille milliards de paramètres » signifie en pratique.
Un modèle dense, le genre que la plupart des gens imaginent, fait tourner chaque paramètre pour chaque jeton. Un modèle dense à 70 milliards de paramètres effectue l'équivalent de 70 milliards de paramètres de calcul sur chaque mot qu'il produit. Un modèle Mixture-of-Experts est construit différemment. Kimi K2.5 a 384 « experts » distincts, dont 8 s'activent par jeton plus un expert partagé, répartis sur 61 couches. Ainsi, bien que le modèle porte 1.04 trillion de paramètres au total, seuls environ 32 billion d'entre eux s'allument sur un même passage avant. Un routeur choisit quels experts réveiller ; le reste reste là à ne rien faire pour ce jeton.
Alors, est-ce honnête de dire « faire tourner un modèle à mille milliards de paramètres sur quatre mini PC » ? Oui, vous avez réellement besoin de la mémoire pour contenir les 1.04 trillion de paramètres, et cette mémoire est la partie difficile. Mais le calcul que votre matériel doit faire par jeton est un travail de classe 32B, pas de classe 1T.
Ce qui tranche dans les deux sens, et c'est là que cela devient intéressant. Cela rend la démo plus impressionnante qu'elle n'en a l'air, car contenir un modèle complet à mille milliards de paramètres en mémoire sur des boîtiers grand public est la chose véritablement difficile qu'ils ont réussie. Et cela la rend moins impressionnante que ce que le titre implique, car la charge réelle par jeton est quelque chose que des boîtiers uniques avalent déjà plus vite sur des modèles MoE plus petits. Un modèle MoE de 120B tourne à plus de 50 jetons par seconde sur l'un de ces nœuds. Le chiffre du trillion de paramètres est réel, mais c'est une démonstration de mémoire, pas une démonstration de calcul.
À retenir : quand vous dimensionnez le matériel pour un modèle, c'est le nombre de paramètres actifs que votre machine doit alimenter par jeton, pas le total sur le boîtier.
Le hic : ce que 8 jetons par seconde et une attente de 40 secondes à 4 minutes signifient vraiment
Huit jetons par seconde est le chiffre qui décide de tout, alors prenez un instant pour y réfléchir. L'article d'AMD rapporte que le cluster génère environ 8.30 t/s avec un contexte de 8,192 jetons et à peu près 9.45 t/s en régime stable, avec un traitement du prompt autour de 100.77 t/s. Ce sont des chiffres corrects et justes pour ce qu'ils sont.
Celui qui fait mal, c'est le délai jusqu'au premier jeton. Avant que le modèle ne produise un seul mot, il doit lire votre prompt, et le propre tableau de référence d'AMD chiffre cette attente à 39.7 secondes pour un prompt de 4,096 jetons, 90.5 secondes pour un prompt de 8,192 jetons, et 239.1 secondes pour un prompt de 16,384 jetons avec Flash Attention activé. Donc vous tapez une question, puis vous attendez. Peut-être près de quatre minutes, avant que quoi que ce soit ne revienne.
Pour une boucle de codage interactive, c'est rude, et les développeurs dans la discussion Hacker News l'ont dit sans détour : plus d'une minute de silence avant le premier jeton ne colle pas à la façon dont quiconque écrit du code avec un assistant. Mais retournez la charge de travail. Si vous faites tourner des tâches par lots la nuit, traitez des documents en asynchrone, générez des choses que vous lirez plus tard, ou faites de l'inférence privée où tout l'intérêt est que rien ne quitte le bâtiment, 8 jetons par seconde est tout à fait vivable. Vous ne regardiez pas l'écran de toute façon.
L'astérisque : Ne vous attendez pas à reproduire ces chiffres dès le départ. La pile logicielle ROCm sur ce matériel est sensible aux versions d'une manière qui mord : un ticket GitHub a documenté un système Strix Halo bloqué à des fréquences GPU au ralenti et rampant à 0.5 t/s en inférence LLM sous ROCm 7.1.1 et le noyau Linux 6.14. Ce n'est pas « AMD est cassé », mais cela signifie que la performance publiée dépend d'une pile logicielle très spécifique, et vous pourriez finir par courir après des combinaisons de ROCm, de noyau et de firmware avant que votre installation n'atteigne les chiffres du compte rendu.
Encore une chose que la critique se trompe, c'est le coût. Les gens continuent de l'appeler un « cluster à 10 000 $ », mais personne ne publie cela comme une nomenclature fixe. Faites le calcul vous-même : quatre Framework Desktop de 128 GB au prix de lancement de $1,999 mettraient les machines seules à environ $8,000, tandis qu'un instantané de mars 2026 de Liliputing indiquait une configuration Framework Desktop 128GB/1TB à $2,851, soit environ $11,400 pour quatre avant le réseau. Ajoutez quelques centaines de dollars pour le switch et le câblage, et la fourchette pratique est plus proche d'environ $8.2K à $11.7K selon la configuration, la date d'achat et ce que vous possédez déjà. Pas rien. Pas une salle serveurs non plus.
Voici où j'atterris sur l'ensemble : le cluster fonctionne. Que huit jetons par seconde et une attente de plus d'une minute soit un triomphe ou un jouet dépend entièrement de ce que vous essayez de construire. Ce n'est pas une station de travail de codage interactive. Ce n'est pas non plus un jouet. C'est une vraie machine pour un type précis de travail patient, et prétendre qu'elle est plus ou moins que cela, c'est ainsi que tout le monde dans ce débat finit par parler à côté.
Où cela atterrit vraiment
Le cadrage honnête n'est pas « AMD a battu Nvidia ». C'est que ceci est un produit différent pour une personne différente. Le lecteur qui veut cela est celui qui a besoin de confidentialité, qui veut du hors ligne, ou qui ne veut pas payer au jeton pour toujours, pas celui qui court après la réponse la plus rapide possible.
Et l'argument le plus fort contre tout l'exercice mérite une réponse franche : vous pouvez simplement appeler l'API de Kimi. Artificial Analysis répertorie actuellement le propre endpoint K2.5 de Kimi autour de 56 à 60 jetons par seconde avec un prix mixte autour de 0,49 $ par million de jetons, tandis que la plateforme API officielle de Kimi indique une tarification K2.5 à $0.10/M jetons d'entrée en cache, $0.60/M jetons d'entrée, et $3.00/M jetons de sortie. Les fournisseurs tiers de K2.5 peuvent être plus rapides ou moins chers selon le routage, mais le point fondamental est le même : l'API est plus rapide que le cluster, évite de materner le matériel, et sera le bon choix pour la plupart des gens la plupart du temps.
Donc le scénario local n'a de sens que lorsque l'une de ces trois choses est vraie : les données ne peuvent pas sortir (confidentialité), la connexion ne peut pas être supposée (hors ligne), ou le volume de jetons est assez élevé et assez soutenu pour que posséder le métal batte le louer pour toujours (coût à l'échelle). En dehors de ces trois cas, l'API gagne. À l'intérieur, le cluster est la seule chose qui fait le travail tout court.
| Dimension | Cluster AMD à 4 nœuds | API Kimi / route cloud |
|---|---|---|
| Vitesse de génération | ~8 à 9.5 t/s | ~56 à 60 t/s sur le propre endpoint K2.5 de Kimi |
| Délai jusqu'au premier jeton | 39.7 à 239.1 s | dépend du fournisseur, bien plus bas |
| Modèle de coût | ~$8.2K à $11.7K de matériel | tarification API au jeton |
| Confidentialité / hors ligne | entièrement local | hébergé par le fournisseur |
| Cas d'usage le mieux adapté | travail privé, hors ligne, par lots | usage interactif/API |
Pour mémoire, le DGX Spark de Nvidia est le « mais qu'en est-il de » évident ici, et il l'emporte sur certains axes que le cluster AMD ne remporte pas. C'est un tout autre combat, et un que je reprendrai ailleurs. Si vous voulez le côté location de la décision matériel-vs-cloud, la page GPU VPS de Cloudzy est le point de comparaison le plus pratique.
La partie qui compte vraiment
Retirez le débit de jetons et les arguments de prix, et un fait reste debout : le matériel qui fait tourner un modèle à mille milliards de paramètres est désormais une étagère, pas un bâtiment.
C'est le basculement, et il est facile à manquer sous les chamailleries de vitesse. Il y a un an, la catégorie de personnes capables de faire tourner un modèle à 1.04 trillion de paramètres était « les opérateurs de centres de données ». Point final. Maintenant elle inclut quiconque dispose d'environ dix mille dollars et d'un peu de patience. La ligne n'a pas bougé d'un peu : tout un nouveau groupe de personnes vient de franchir une porte qui était verrouillée.
Ce que cela ouvre est la partie intéressante. Des agents privés qui tournent entièrement sur du matériel que vous possédez. De l'inférence qui fonctionne dans un avion ou derrière un air gap. Des modèles qui ne peuvent physiquement pas téléphoner à la maison parce qu'il n'y a nulle part où l'appel pourrait aboutir. Une économie de l'IA où le coût marginal d'un jeton est de l'électricité au lieu d'une ligne d'API facturée. Rien de tout cela n'était atteignable sur du matériel grand public il y a un an, et la mémoire unifiée est ce qui l'a atteint.
J'ai observé ce schéma assez de fois pour me méfier de « ceci change tout ». D'habitude non ; d'habitude c'est la chose de l'an dernier avec un nouveau logo. Celle-ci est différente, et pas parce qu'elle est rapide. Elle est différente parce que le plancher a bougé. La version lente, coûteuse et patiente de l'inférence locale à l'échelle de pointe existe maintenant, et la version rapide n'est qu'une question des prochaines générations de matériel qui la roderont. La partie difficile n'allait jamais être la vitesse. La partie difficile était l'accès, et l'accès vient d'arriver.
L'étape marquante ici n'est pas la vitesse. C'est de savoir qui est autorisé dans la pièce. La machine qui fait tourner des modèles à l'échelle de pointe était autrefois un bâtiment. Maintenant ce sont quatre boîtiers sur une étagère.
Foire aux questions
Peut-on vraiment faire tourner un modèle à mille milliards de paramètres sur un cluster de mini PC ?
Oui, avec une réserve importante. AMD a fait tourner Kimi K2.5, un modèle à 1.04 trillion de paramètres, sur quatre mini PC Ryzen AI Max+ 395. Dans le BIOS, les quatre systèmes peuvent exposer environ 384 GB de VRAM dédiée au total ; le guide Linux d'AMD porte ensuite l'allocation à 480 GB au total via des réglages TTM/noyau. Mais Kimi K2.5 est un modèle Mixture-of-Experts : de ces 1.04 trillion de paramètres, seuls environ 32 billion s'activent sur un jeton donné. Vous avez besoin de la mémoire pour tous les contenir, mais le calcul par jeton est plus proche d'une charge à 32 milliards de paramètres.
Qu'est-ce que Kimi K2.5 et pourquoi l'architecture MoE compte-t-elle ici ?
Kimi K2.5 est un modèle de langage à poids ouverts de Moonshot AI avec 1.04 trillion de paramètres au total et 32 billion actifs par passage avant, bâti sur une conception Mixture-of-Experts (384 experts, 8 activés par jeton plus un partagé). L'architecture compte parce que c'est le nombre de paramètres actifs, pas le total, que votre matériel doit calculer pour chaque jeton. C'est pourquoi un modèle avec mille milliards de paramètres sur le papier peut tourner sur des boîtiers grand public tout court.
8 jetons par seconde est-il assez rapide pour de l'IA locale ?
Cela dépend entièrement de la charge de travail. Pour le traitement par lots, les tâches asynchrones, l'usage hors ligne, ou l'inférence privée où rien ne peut quitter votre matériel, 8 jetons par seconde convient, vous ne fixez pas l'écran. Pour le codage interactif, c'est rude, surtout parce que le délai jusqu'au premier jeton sur ce cluster va d'environ 40 secondes à près de 4 minutes selon la longueur du prompt, et ce silence avant le premier mot tue une boucle itérative.
Pourquoi ne pas simplement utiliser l'API de Kimi ?
Pour la plupart des gens, vous devriez. Le propre endpoint K2.5 de Kimi est bien plus rapide que le cluster local dans les données actuelles d'Artificial Analysis, et les fournisseurs tiers de K2.5 peuvent être plus rapides ou moins chers encore. Le matériel local n'a de sens que lorsque vous avez besoin de confidentialité (les données ne peuvent pas sortir), de capacité hors ligne (aucune connexion à supposer), ou de coût à l'échelle (volume élevé soutenu où posséder bat louer). En dehors de ces cas, l'API est le meilleur choix.
