ds4 : analyse pratique pour un usage documenté

Ce qu'est DwarfStar

DwarfStar est un petit moteur d'inférence natif écrit en C, optimisé d'abord pour DeepSeek V4 Flash. Il prend également en charge GLM 5.2 et, sur les machines à très grande mémoire, DeepSeek V4 PRO. Le README le décrit comme délibérément étroit plutôt que comme un exécuteur GGUF général : chargement de modèle, rendu de prompt, appels d'outils, état KV, serveur HTTP et agent de codage sont construits et testés ensemble. Les backends pris en charge sont Metal comme cible principale sur les Mac de 96 Go ou plus, NVIDIA CUDA y compris les systèmes multi-GPU et DGX Spark, et ROCm sur les systèmes Strix Halo tels que le Framework Desktop. Le projet reconnaît llama.cpp et GGML comme référence essentielle et conserve certaines parties de leur code source sous licence MIT.

Support de modèles et choix de quantification

Le moteur ne fonctionne qu'avec les fichiers GGUF DeepSeek V4 et GLM 5.2 listés dans le README. Les fichiers GGUF arbitraires n'auront pas la disposition des tenseurs, le mélange de quantification, les métadonnées ou l'état MTP optionnel attendus par le moteur. Les quantifications 2 bits fournies sont vérifiées comme étant de haute qualité selon le README : elles se comportent bien, fonctionnent sous les agents de codage et appellent les outils de manière fiable. Les quantifications 2 bits utilisent un schéma asymétrique où seuls les experts MoE routés sont quantifiés, up/gate en IQ2_XXS et down en Q2_K, tandis que les autres composants tels que les experts partagés, les projections et le routage restent intacts. Le GGUF MXFP4 préserve les poids des experts routés publiés par DeepSeek plutôt que de les requantifier et fonctionne sur Metal et CUDA, les appareils CUDA Blackwell utilisant des instructions matricielles FP4 natives pour le travail par lots d'experts. Le support de GLM 5.2 est limité aux dispositions GGUF spécifiques testées, et les autres dispositions de quantification GLM sont considérées comme non prises en charge jusqu'à ce qu'elles soient ajoutées délibérément et notées.

Statut de développement et approche du projet

Le README indique que le logiciel change très rapidement et doit être considéré comme de qualité bêta. Avant chaque version, une grande exécution d'assurance qualité est effectuée, mais des instabilités sont possibles. L'auteur explique que le développement assisté par IA a façonné le projet : il a été construit avec une forte assistance de GPT 5.5, 5.6 et Claude Fable, les humains menant les idées, les tests et le débogage. Le README dit que si vous n'êtes pas satisfait du code développé par IA, ce logiciel n'est pas pour vous. Le projet doit aussi son existence à llama.cpp et GGML ; il ne lie pas contre GGML, mais utilise les noyaux, les formats de quantification, l'écosystème GGUF et les connaissances techniques développés là-bas. Certaines parties du code source sont conservées ou adaptées sous licence MIT, et l'avis de droit d'auteur des auteurs de GGML est conservé dans le fichier LICENSE.

Exécuter des modèles plus grands que la RAM avec le streaming SSD

Le chemin Metal normal tente de rendre le modèle résident dans la mémoire adressable par le GPU, ce qui est le chemin le plus rapide. DwarfStar dispose également d'un mode de capacité de streaming SSD sur Metal et pour GLM 5.2 sur ROCm. Dans ce mode, les poids du modèle non routés restent résidents, tandis que les experts MoE routés sont conservés dans un cache en mémoire et chargés à partir du fichier GGUF en cas d'échec de cache. Le README note que le streaming n'est pas aussi rapide que de placer l'intégralité du modèle dans la RAM, mais il est utile car les experts routés dominent la taille du modèle et les SSD Mac modernes sont assez rapides pour rendre les échecs de cache tolérables. Le budget de cache automatique prend 80 % de l'espace de travail recommandé par le backend, soustrait les poids non routés, puis applique la marge de préremplissage routé. Les utilisateurs peuvent également définir explicitement le cache d'experts routés avec --ssd-streaming-cache-experts NGB. Le README donne des exemples pour les MacBook de 64 Go et 128 Go avec des commandes de téléchargement et d'exécution spécifiques.

Inférence distribuée avec parallélisme de pipeline

Le parallélisme de pipeline permet à DwarfStar d'exécuter un modèle trop grand pour une seule machine en répartissant les couches de transformateur sur plusieurs machines. Le principal exemple du README est la quantification Flash 4 bits complète sur deux MacBook de 128 Go : chaque processus ne mappe que sa propre tranche de couches, les activations sont envoyées via TCP, et le coordinateur conserve le comportement normal CLI/API. Le préremplissage peut être accéléré en utilisant plusieurs GPU en même temps sur différents micro-lots, mais la génération est strictement autorégressive et paie au moins un saut d'activation entre machines par jeton, elle est donc plus lente qu'un processus local unique. Le protocole distribué utilise des connexions TCP de contrôle et de données, n'a ni chiffrement ni authentification, et n'est pas stable pour une version ; le coordinateur et les travailleurs doivent être construits à partir du même commit et utilisés sur des réseaux de confiance. Le README fournit également des tableaux de comparaison de liens réseau montrant Thunderbolt 5, WiFi et Internet/VPN.

Parallélisme tensoriel sur RDMA et entre GPU CUDA

Le parallélisme tensoriel sur RDMA exécute un décodage unique sur deux Mac connectés par un câble Thunderbolt 5, répartissant le travail lourd par couche entre les deux GPU et échangeant des sommes partielles aux portes de synchronisation. Les deux machines travaillent sur le même jeton en même temps, ce qui réduit la latence par jeton au lieu de simplement faire tenir un modèle plus grand. Chaque machine conserve une moitié contiguë des experts routés, tandis que les poids denses, d'attention, d'experts partagés, d'incorporation et de sortie sont répliqués. Le README donne un exemple avec GLM 5.2 sur deux MacBook de 128 Go, y compris la configuration sysctl et ifconfig pour RDMA, et rapporte les vitesses de décodage et de préremplissage mesurées. Un mode de parallélisme tensoriel CUDA séparé sur un seul serveur divise DeepSeek V4 Flash sur un nombre pair de GPU en utilisant --cuda-tensor-parallel, avec un ordre des appareils qui place tous les hôtes d'abord puis tous les partenaires. L'hôte testé utilise huit cartes L40S avec un modèle imatrix Q4.

Benchmarking, évaluation, agent et serveur

Le dépôt comprend plusieurs outils. ds4-bench mesure le débit instantané de préremplissage et de génération aux frontières de contexte plutôt qu'une moyenne sur l'ensemble du run, en sauvegardant et restaurant l'état KV entre les lignes. ds4-eval est un benchmark d'intégration sur modèle réel avec un sous-ensemble intégré de 92 éléments provenant de GPQA Diamond, SuperGPQA audité, AIME 2025 et COMPSEC ; le README dit explicitement que ce n'est pas un exécuteur de classement et ne doit pas être rapporté comme un score de benchmark officiel. L'agent natif exécute l'inférence depuis l'intérieur de l'agent lui-même sans frontières de socket ou d'API, stocke les sessions dans ~/.ds4/kvcache et prend en charge /save, /list, /switch, /del et /strip. Le serveur démarre comme un serveur local compatible OpenAI/Anthropic et prend en charge --batched-session N pour plusieurs sessions KV résidentes. Le README note que le projet est encore en bêta et que l'agent nécessite plus de travail avant d'être prêt pour la production.

Test ciblé de ds4

Le dépôt ds4 vise l'inférence locale de modèles DeepSeek 4 Flash et PRO avec des chemins Metal, CUDA et ROCm. Cette orientation place la mémoire, le format des poids et le matériel au centre de la décision. Un poste Apple ne doit pas être évalué comme une machine CUDA : le backend Metal et le chemin de compilation doivent être observés séparément. Le README décrit un moteur local, mais ne constitue pas une mesure indépendante de latence, de précision ou de capacité de contexte. Les chiffres annoncés doivent donc rester des affirmations du projet tant qu'un essai reproductible ne les confirme pas.

Le premier essai utile consiste à compiler la révision choisie, lancer un modèle dont les fichiers et le format sont explicitement documentés, puis conserver la sortie complète et la consommation mémoire. Il faut comparer DeepSeek 4 Flash et PRO avec le même prompt, le même nombre de tokens et le même backend. Une erreur de chargement peut venir du modèle ou du pilote, et non du moteur. Les utilisateurs qui cherchent une API distante, une interface hébergée ou une garantie de débit ne trouveront pas ces engagements dans le matériau fourni. La licence MIT autorise l'usage et la modification selon ses conditions, mais elle ne fournit ni garantie ni support.

Conclusion éditoriale

ds4 s'adresse aux équipes dont le besoin correspond exactement au périmètre décrit dans le README. Il ne faut pas le traiter comme une garantie de production : commencez par le scénario propre à antirez/ds4, la commande ou le fichier documenté, puis observez la sortie, les erreurs, les permissions et les ressources consommées.

Sources officielles

1. Official README
2. Project repository