DeepSeek 284B tourne sur CPU avec 64 Go de RAM
llama-modchipDeepSeek-V4-FlashCPU-инференс
Comment 284B paramètres tiennent dans une mémoire ordinaire
Le résultat essentiel est le suivant : llama-modchip affirme exécuter DeepSeek-V4-Flash et ses 284,33B paramètres sur un AMD Ryzen 9 9955HX à 16 cœurs, avec 64 Go de DDR5 et sans aucun GPU. Le dépôt du projet et son tableau de benchmarks indiquent une taille de modèle de 56,56 GiB, avec un pic de mémoire d’environ 57,6 à 58,9 GiB pour un contexte de 256K.
L’intérêt n’est pas qu’un modèle dense de 284B soit soudainement devenu peu coûteux à calculer sur CPU. DeepSeek-V4-Flash emploie une architecture Mixture-of-Experts : le nombre total de paramètres est très élevé, mais seuls environ 13,17B sont actifs pour chaque jeton. L’ensemble des experts doit toujours être conservé en mémoire, mais la charge de calcul par jeton est nettement plus faible.
Le second élément repose sur une quantification agressive et un format GGUF spécialisé. La documentation de llama-modchip attribue également un gain de 20,31 GiB à son implémentation de SwiGLU-H2. Avec le mappage mémoire et un contrôle strict des allocations, il reste de la place pour l’état du runtime et le cache KV, même si la marge sur une machine annoncée avec 64 Go demeure très étroite.
Les résultats publiés indiquent 43,16 à 44,36 jetons par seconde lors du traitement du prompt, puis 9,06 à 10,74 en génération normale. Avec des configurations Stockfish-PVS pour le décodage spéculatif, le projet annonce 11,50 à 14,69 jetons par seconde et environ 94,5 % d’acceptation des jetons brouillons. Il s’agit des chiffres publiés par le projet, pas d’une reproduction indépendante.
Le GPU n’est pas remplacé, mais l’équation évolue
Ce n’est pas un substitut aux accélérateurs pour l’entraînement ou le serving à grande échelle. C’est néanmoins une voie crédible vers l’inférence locale d’un grand modèle MoE. L’approche est utile lorsque l’autonomie, l’accès à un vaste ensemble de poids et l’absence de VRAM dédiée comptent davantage que le débit maximal.
Il faudrait d’abord vérifier la qualité après quantification, la stabilité sur les longs contextes et la sensibilité des performances à la mémoire. Dans ce type d’inférence, le goulot d’étranglement est souvent moins l’arithmétique du CPU que la bande passante RAM, le placement des threads et le déplacement de dizaines de gigaoctets de poids. Les résultats ne sont donc pas nécessairement transposables à un autre processeur ou à une mémoire plus lente.
Il est impossible de confirmer de manière fiable un fil Hacker News précis à partir des éléments disponibles ; il vaut donc mieux distinguer les conclusions des discussions communautaires. L’expérience reste intéressante : le nombre de paramètres décrit de moins en moins bien le coût réel de l’inférence lorsque l’architecture est sparse et que le runtime est optimisé avec le format des poids. La question principale n’est plus de savoir si le modèle démarre, mais s’il conserve sa qualité d’origine après compression.