llama-modchip fait tourner DeepSeek et ses 284 milliards de paramètres dans 64 Go, sans GPU

Si une équipe dispose d’un serveur sans carte graphique, elle peut tenter de faire tourner un assistant local sur son processeur. C’est précisément le scénario proposé par llama-modchip. La question pratique est simple : le matériel déjà payé peut-il analyser des documents ou aider à programmer avec une latence acceptable ? Le projet donne matière à expérimenter, même s’il n’apporte pas encore de réponse pour votre machine.

L’auteur affirme faire tourner DeepSeek-V4-Flash, doté de 284 milliards de paramètres, sur un système équipé de 64 Go de mémoire vive, avec un débit de génération de 9,1–14,7 tokens par seconde. Ces résultats sont ceux du développeur du projet ; nous ne les avons pas reproduits. Source originale : le dépôt llama-modchip.

Comment un grand modèle tient en mémoire

Le projet repose sur la compression des poids et sur des modifications des noyaux de calcul de llama.cpp. DeepSeek utilise une architecture MoE : seule une partie des paramètres intervient dans le traitement d’un token. Le nombre total de paramètres ne suffit donc pas à expliquer la charge de calcul. L’auteur estime la taille du modèle après compression à 56,56 Gio et présente des mesures réalisées sur un processeur AMD Ryzen 9 9955HX. Les conditions sont décrites dans le README.

Pour prendre une image courante, cela revient à conserver un gros ouvrage de référence dans un format plus compact : il occupe moins de place, et seuls certains chapitres sont nécessaires pour répondre à une question précise. L’analogie explique les économies de ressources, mais ne prouve rien quant à la qualité. Il faut vérifier séparément dans quelle mesure la compression préserve la qualité des réponses.

Imaginons un assistant interne destiné au support client. Un employé lui transmet une demande client et quelques extraits de documentation, puis le modèle prépare un brouillon de réponse. Dans ce scénario, il est utile de mesurer l’ensemble du parcours : envoyer la requête, attendre le début de la réponse, obtenir le brouillon complet et vérifier les faits. C’est ce temps total qui détermine si l’employé aura envie d’utiliser l’outil au quotidien.

Si l’assistant génère du texte assez vite, mais se trompe régulièrement sur les conditions de retour, les économies réalisées sur le matériel perdent leur intérêt. S’il répond correctement, mais impose une attente avant chaque message, il vaut la peine de tester un modèle plus compact. La taille affichée dans le nom ne remplace pas une comparaison sur une tâche réelle.

Les limites des promesses de vitesse

Les bornes basse et haute de la plage annoncée ont été obtenues avec des modes d’accélération différents. La compatibilité constitue une autre limite : les fichiers spécifiques du modèle nécessitent une compilation du projet ; les versions standard d’Ollama et de LM Studio ne peuvent pas les charger. Ces réserves figurent dans la documentation.

Pour un développeur, cela dessine un protocole de vérification concret. Commencer par réunir quelques dizaines de requêtes typiques et définir à l’avance les critères d’une bonne réponse. Soumettre ensuite le même jeu de requêtes à une solution que l’équipe envisage déjà : un modèle local plus petit ou une API externe. Comparer l’exactitude, la latence et la quantité de corrections manuelles nécessaires.

Un test distinct est nécessaire pour les requêtes simultanées. Une conversation fluide avec une seule personne ne signifie pas encore que le serveur supportera une journée de travail de toute l’équipe. Il est utile de vérifier comment la file d’attente s’allonge, s’il reste de la mémoire pour l’application et ce qui se passe avec une requête longue. Ces mesures sont particulièrement importantes sur une machine virtuelle : les résultats obtenus sur un processeur de portable précis ne permettent pas de déduire les capacités d’une instance louée.

Qui a intérêt à essayer

Le candidat le plus évident est une équipe qui dispose d’un serveur CPU et dont les tâches tolèrent un délai. Par exemple, préparer des brouillons, analyser des textes internes ou traiter une file de documents. Il s’agit d’usages possibles, et non de résultats confirmés du projet.

Il est raisonnable de commencer sur un environnement de test séparé, avec un petit échantillon de documents réels. Consigner la version compilée, les paramètres de lancement et les résultats permettra de reproduire l’expérience. Calculer ensuite le coût d’une réponse utile, en tenant compte de la location, de la maintenance et de la vérification humaine.

Pour un fondateur, l’intérêt de cette annonce réside dans l’apparition d’une option d’infrastructure supplémentaire. Pour un responsable produit, c’est la possibilité de tester un usage local avant d’acheter du matériel. Pour un développeur, c’est une expérience concrète : déterminer si le CPU disponible suffit à la charge visée. La décision de déploiement viendra après ces mesures.