Un modèle de 284 milliards de paramètres tourne désormais sur un Mac de 128 Go. Qui y perd ?

DwarfStar 4, ou ds4, est un moteur d'inférence écrit en C, sous licence MIT, qui fait tourner DeepSeek V4 et V4.1 Flash, GLM 5.x et Qwen3.8 Flash Next sur des machines Mac, CUDA et ROCm à forte mémoire. Le tableau de performances du projet indique qu'un M5 Max équipé de 128 Go de mémoire génère 39,4 jetons par seconde avec un contexte de 2 048 jetons, et 27,6 avec 65 536 jetons. Ces chiffres sont ceux du projet, et non des mesures indépendantes, mais ils décrivent un modèle de 284 milliards de paramètres qui répond à une vitesse de conversation sur une seule station de travail.

Comment un modèle de 284 milliards de paramètres tient sur une seule machine

DeepSeek V4 Flash est un modèle de type mixture d'experts. Au lieu de mobiliser tous les paramètres pour chaque mot, il contient de nombreux sous-réseaux spécialisés, appelés experts, et un routeur en choisit quelques-uns pour chaque jeton. L'essentiel du poids du modèle se trouve dans ces experts routés, ce qui en fait l'endroit évident pour économiser de la mémoire.

ds4 recourt à ce qu'il appelle une quantification asymétrique sur 2 bits. Quantifier consiste à stocker chaque nombre avec moins de bits, en échangeant un peu de précision contre un fichier beaucoup plus petit. L'asymétrie est le point clé : les experts routés sont fortement compressés, tandis que les chemins partagés que traverse chaque jeton restent précis. Le projet présente cela comme une compression, et non une lobotomie. La source ne démontre pas que cela tienne pour votre charge de travail, puisqu'elle publie des chiffres de vitesse mais aucune comparaison de qualité.

Deux autres choix de conception comptent. Le premier : ds4 enregistre le cache KV sur disque. Le cache KV est la mémoire de travail du modèle sur votre prompt jusqu'ici, et le reconstruire après un redémarrage (re-prefill) est lent sur les longs contextes. ds4 stocke les longs préfixes sur SSD et reprend à partir du hash du prompt. Le second : le même moteur alimente une CLI de chat, un serveur HTTP local et un agent de code persistant, qui partagent tous le même état du modèle et le même cache.

Qui y gagne, et qui est exposé

Le serveur expose /v1/chat/completions, /v1/messages et /v1/responses, et le projet cite OpenCode, Claude Code, Codex CLI et Pi comme clients. Concrètement, une équipe peut pointer ses outils de code existants vers une machine posée sous un bureau plutôt que vers un point d'accès cloud facturé à l'usage. Les bénéficiaires sont les équipes dont le code ou les documents ne peuvent pas être envoyés à un tiers, ainsi que toute organisation dont la facture de jetons croît avec l'usage des agents.

La partie exposée, ce sont ceux dont l'activité consiste à revendre l'accès à ces modèles à poids ouverts. La source ne dit rien des prix, donc l'ampleur des flux financiers reste inconnue. Mais le seuil matériel est précis : V4 Flash Q2 est la référence pour les machines de 128 Go, GLM 5.3 Q2 et Qwen Q4 tiennent aussi à cette taille, V4.1 Q2 est lu en continu depuis le SSD, et la page signale que Qwen est utilisable avec 64 Go.

Il existe aussi une exposition plus discrète du côté de l'acheteur. Rapatrier l'inférence en interne, c'est rapatrier aussi la charge opérationnelle : correctifs, capacité, et la question de savoir qui est d'astreinte quand le moteur dysfonctionne. La source décrit ds4 comme un moteur ciblé, ce qui joue dans les deux sens.

Ce que disent, et ne disent pas, les benchmarks

Les chiffres varient fortement selon le matériel. Le DGX Spark, lui aussi à 128 Go, affiche 825,8 jetons par seconde en prefill à 2 048 jetons, mais seulement 18,1 en génération, contre 39,4 pour le M5 Max. Le prefill, c'est la lecture de votre prompt ; la génération, c'est l'écriture de la réponse. Pour les longs documents et les sessions d'agents, la vitesse de prefill et la réutilisation du cache comptent autant que le débit de génération mis en avant. La page précise aussi que ses chiffres sont des estimations tirées du tableau de performances du projet.

Les questions à vous poser

• Que coûte la quantification sur 2 bits des experts routés en qualité de réponse sur nos tâches, et où sont les preuves au-delà des tableaux de vitesse ?
• Si nous rapatrions le trafic des agents en local, qui est responsable de la disponibilité, des mises à jour et des correctifs de sécurité d'un moteur C jeune et au périmètre étroit ?
• À environ 28 jetons par seconde avec un contexte de 65 536 jetons, un agent de code multi-étapes est-il assez rapide pour que les ingénieurs l'utilisent réellement ?
• Dans nos dépenses cloud actuelles, quelle part correspond réellement à l'accès au modèle, et quelle part au service qui l'entoure et que nous devrions reconstruire ?
• Les licences des poids des modèles, et pas seulement la licence MIT de ds4, autorisent-elles l'usage que nous prévoyons ?

Ce qu'il faut surveiller ensuite

Le signal à guetter, ce sont des tests de qualité indépendants des versions Q2 face aux modèles en pleine précision, menés sur de vrais travaux de code et de long contexte plutôt que sur les tableaux de vitesse du projet. Si ces résultats se confirment, la question ne sera plus de savoir si l'inférence locale de pointe fonctionne, mais quelles charges de travail doivent quitter le cloud en premier.