64 Go de RAM peuvent-ils vraiment faire tourner DeepSeek V4 Flash 284B sans GPU ?

Un projet communautaire rapporte l’exécution de DeepSeek V4 Flash 284B sur une machine Linux dotée de 64 Go, en utilisant uniquement le CPU. La configuration rapportée utilise llama-modchip, un point de contrôle personnalisé à environ 1,71 bit par poids et un processeur de bureau doté d’une bande passante mémoire importante. Considérez cela comme une expérience documentée réalisée avec une configuration précise, plutôt que comme une recommandation générale de dimensionnement pour le point de contrôle officiel.

Ce résultat est utile, car il permet de mesurer trois questions habituellement confondues : le fichier de poids peut-il tenir en mémoire, le processus peut-il conserver suffisamment de mémoire pendant la génération, et la sortie reste-t-elle exploitable à ce niveau de compression ? Le projet a été présenté dans une discussion communautaire du 8 novembre. Les mesures ci-dessous proviennent du dépôt du mainteneur de llama-modchip, et non de tests indépendants.

De quel modèle DeepSeek et de quel environnement d’exécution s’agit-il ?

Le projet cible DeepSeek V4 Flash, décrit dans sa documentation comme comptant environ 284B de paramètres au total, dont environ 13B actifs par jeton. Dans un modèle à mélange d’experts, le routeur sélectionne des experts pour chaque jeton. Cela limite le calcul par jeton, tandis que l’ensemble des experts doit toujours être stocké et rendu accessible. Consultez la fiche du modèle du développeur et l’aperçu des exigences matérielles pour connaître le contexte habituel de déploiement.

L’expérience utilise un transcodage spécialisé et des correctifs pour l’écosystème ggml/llama.cpp. Même un autre fichier annonçant la même famille de modèles peut avoir une disposition des tenseurs ou une précision différente. Un binaire llama.cpp standard et un fichier GGUF conventionnel doivent être considérés comme une voie distincte. Le guide de mise à jour de llama.cpp existant couvre la voie de publication en amont.

Comment 284 milliards de paramètres tiennent-ils dans 64 GB de RAM ?

Avec une moyenne de 1.71 bit par poids, 284 milliards de poids représentent environ 61 GB de données compactées en unités décimales. Le projet indique un fichier de 56.56 GiB et un pic de mémoire résidente du processus de 57.61 GiB dans sa configuration 256K. GiB et GB désignent des unités différentes. Vérifiez la mémoire réellement disponible sur l’hôte au moment du test pour évaluer la marge. Les réservations du micrologiciel, le processeur graphique intégré et les autres processus peuvent absorber une grande partie d’une faible marge restante.

La mémoire résidente et la taille du fichier de poids sont des mesures liées, mais aucune ne tient compte de toutes les allocations système. Pendant le chargement, le noyau peut récupérer le cache du système de fichiers ou conserver des tampons temporaires. Surveillez à la fois la mémoire utilisée par le processus d’exécution et la mémoire disponible du système. Une empreinte mémoire résidente élevée lors d’un seul test ne caractérise pas non plus toutes les longueurs de contexte et tous les types d’entrée.

Pourquoi les vitesses de traitement des invites et de génération divergent-elles ?

Le traitement de l’invite porte sur une entrée déjà connue, ce qui permet à l’environnement d’exécution de traiter plusieurs jetons par lots. La génération est séquentielle : le jeton suivant dépend des jetons générés précédemment. La génération sur CPU d’un modèle MoE dépend de la vitesse à laquelle la machine peut transférer en mémoire les poids des experts sélectionnés et leur état. La fréquence d’horloge, le nombre de canaux, les timings mémoire et le placement des threads peuvent tous modifier le résultat.

Séparez un test avec une courte invite d’une invite provenant d’un long dépôt de code. Mesurez séparément le délai avant le premier jeton et la génération suivante. Un préfixe plus long peut dominer la latence totale, même si le flux semble réactif une fois lancé. Indiquez si l’environnement d’exécution a réutilisé un état mis en cache. Un préfixe préchauffé et une exécution à froid répondent à des questions différentes. La documentation de l’outil de benchmark en amont explique les mesures de l’invite et de la génération.

Quelle perte de qualité entraîne cette précision ?

Le nombre de bits par poids résume l’espace de stockage, pas la qualité du modèle. La précision peut varier selon les tenseurs, et deux conversions de taille similaire peuvent se comporter différemment. Les raisonnements longs, la syntaxe exacte, les arguments d’outils et le vocabulaire inhabituel sont de bons cas à vérifier. Une réponse lisible à une question démontre que la génération fonctionne. Cela ne prouve pas que la même compilation est fiable pour un flux de travail de programmation.

Choisissez un petit ensemble de référence avant les tests. Incluez une tâche de sortie au format exact, une fonction avec un test connu en échec, une recherche dans un long contexte et une demande à laquelle le modèle devrait répondre avec prudence. Comparez les résultats à ceux d’une référence de plus haute précision ou de plus petite taille, compatible avec le modèle, en utilisant les mêmes invites. Gardez les entrées de test constantes et consignez les sorties incomplètes, les appels d’outils mal formés et les délais d’expiration. Fixez les révisions du modèle et de l’environnement d’exécution afin de pouvoir attribuer toute amélioration ultérieure à un changement précis.

Comment reproduiriez-vous le résultat de manière responsable ?

Commencez par une machine de test Linux isolée, disposant de beaucoup d’espace SSD, et utilisez exactement le point de contrôle et la révision indiqués par le mainteneur. Lisez les instructions de compilation et de démarrage rapide du projet, inspectez les scripts avant de les exécuter et notez votre processeur, votre configuration mémoire et votre noyau. Une courte invite sans outils shell activés constitue un bon premier test. N’augmentez la taille du contexte qu’après avoir vérifié que la machine reste réactive.

1. Mesurez la mémoire libre et l’activité du swap avant le chargement. Arrêtez les autres tests gourmands en ressources sur la même machine.
2. Notez la taille exacte du fichier de point de contrôle et son empreinte, la version du moteur d’exécution ainsi que tout paramètre spécial de transcodage ou de placement des experts.
3. Mesurez le pic de mémoire RSS, le délai avant le premier jeton, le nombre de jetons générés par seconde et l’éventuelle utilisation du swap. Effectuez le test deux fois pour distinguer le comportement à froid des effets du cache.
4. Comparez la justesse des résultats avant d’utiliser le modèle pour une tâche plus longue. Vérifiez l’exposition des données et l’accès au système de fichiers si vous connectez ensuite un agent.

Utilisez des worktrees Git isolés pour les tâches sur un dépôt. Si l’hôte fournit également des services de stockage ou de sauvegarde pour le foyer, effectuez la première expérience sur une machine de calcul séparée. Un processus d’inférence qui mobilise toute la RAM peut perturber ces services bien avant qu’une erreur de mémoire insuffisante ne provoque son arrêt.

Dans quels cas vaut-il mieux choisir un modèle plus petit ?

Choisissez un checkpoint plus petit si vous avez besoin d’une vitesse interactive régulière, de mises à jour simples ou d’une marge suffisante pour plusieurs sessions. L’expérience communautaire est surtout intéressante si vous acceptez du code personnalisé, une précision réduite et une reproduction minutieuse des résultats. Un modèle utilisable au quotidien, compatible avec un environnement d’exécution pris en charge, peut être plus facile à maintenir et accomplir davantage de tâches utiles par heure. Comparez les deux sur la même tâche avant de modifier un environnement de production.

FAQ

Faut-il un GPU dédié ?

Le mainteneur indique avoir exécuté le checkpoint 284B spécifié sur CPU uniquement. D’autres configurations du dépôt comprennent des variantes accélérées par GPU ; évaluez donc chaque profil de test séparément.

N’importe quel PC avec 64 Go de RAM atteindra-t-il la vitesse indiquée ?

La seule mémoire installée ne permet pas de garantir une vitesse générale. La génération sur CPU dépend de la bande passante mémoire, des noyaux et de l’affectation des threads, et le système doit disposer de suffisamment de RAM.

Est-ce la vitesse que j’obtiendrai pendant une conversation ?

La valeur d’environ 44 tok/s correspond au traitement du prompt dans la configuration citée. Le dépôt indique une plage distincte et inférieure pour la génération autorégressive.

Le contexte de 256K est-il le premier réglage à essayer ?

Commencez avec un contexte plus court et mesurez les performances. La valeur mémoire indiquée par le mainteneur dépend d’un environnement d’exécution et d’une configuration de checkpoint spécifiques.

Cela remplace-t-il le guide matériel publié ?

Pour un déploiement standard, suivez le guide officiel du modèle. Considérez llama-modchip comme une solution communautaire, avec ses propres contraintes de précision, de compatibilité et de performances.

Conclusion

Le résultat intéressant est qu’un environnement d’exécution CPU spécifique et un checkpoint personnalisé à faible précision peuvent faire tenir un modèle MoE étonnamment volumineux dans un budget mémoire restreint. Reproduisez exactement la configuration, distinguez le préremplissage du décodage et vérifiez la qualité des résultats avant de vous y fier. Un modèle plus petit reste un point de comparaison utile pour évaluer la latence au quotidien.