Présentation

DwarfStar 4 (ds4) est un moteur d’inférence C dédié aux modèles de type mixture‑of‑experts (MoE) et aux LLM à forte consommation de mémoire. Il cible les machines Apple Silicon, les serveurs NVIDIA DGX Spark (CUDA) et les stations AMD équipées de ROCm, avec un minimum de 64 Go de RAM selon le modèle. Le projet, initié par Salvatore Sanfilippo (antirez), propose une pile complète : CLI, serveur HTTP compatible OpenAI/Anthropic et agent natif, le tout fonctionnant sur des poids au format GGUF.

Architecture et mécanismes

Le cœur de ds4 repose sur trois innovations : une quantisation asymétrique à 2 bits appliquée aux experts routés, un cache de clés‑valeurs (KV) stocké sur SSD et une interface unifiée. La quantisation 2 bits réduit la taille des experts tout en conservant la précision des chemins partagés, rendant praticable un modèle de 284 milliards de paramètres comme DeepSeek V4 Flash sur une machine de 128 GB. Le KV cache « disk citizen » persiste les préfixes longs sur le disque et les restaure via le hachage du prompt, évitant ainsi un re‑préremplissage complet après chaque redémarrage.

L’engin est écrit en C et compile selon le backend : make pour Metal sur macOS, make cuda-spark pour les GPU CUDA et make rocm pour les plateformes AMD. Il exploite le parallélisme de tenseur et le batch‑speculation pour maximiser le débit, tout en conservant un état de modèle unique partagé entre la CLI (./ds4), le serveur (./ds4-server) et l’agent (./ds4-agent).

git clone https://github.com/antirez/ds4
cd ds4 && ./download_model.sh ds4f-q2
make # macOS Metal
./ds4

Performances et limites

Les benchmarks publiés montrent des vitesses de préremplissage (prefill) supérieures à 790 tokens/s pour 2 048 tokens sur un MacBook Pro M5 Max (128 GB, quantisation q2). La génération chute à 39 tokens/s pour le même contexte, reflétant la charge de décodage. Sur un DGX Spark (128 GB, q2) le préremplissage atteint 825 tokens/s, mais la génération reste limitée à 18 tokens/s, indiquant que le goulot se situe davantage dans le décodage que dans le chargement des poids. Pour des contextes très longs (65 536 tokens) les taux baissent à 398 tokens/s (prefill) et 27 tokens/s (génération) sur le M5 Max, et à 823 tokens/s / 13,8 tokens/s sur le DGX Spark, ce qui confirme l’impact du KV cache SSD sur la latence de récupération.

Ces chiffres sont obtenus avec le modèle DeepSeek V4 Flash quantisé en q2. Les modèles GLM 5.x et Qwen 3.8 affichent des comportements similaires, mais la documentation précise que les versions Q4 de Qwen nécessitent au moins 128 GB de RAM et un streaming depuis SSD. L’approche « narrow » de ds4 exclut les formats GGUF génériques ; chaque layout doit être validé, ce qui limite la portabilité mais garantit la conformité aux sorties officielles.

Déploiement et utilisation

Le flux d’installation se résume à trois étapes : récupération du dépôt, téléchargement du poids ciblé via le script fourni, puis compilation adaptée au backend. Une fois le binaire disponible, l’utilisateur peut lancer une session interactive, exposer une API locale ou intégrer l’agent dans son éditeur préféré. Le serveur expose les endpoints /v1/chat/completions, /v1/messages et /v1/responses, permettant aux agents de codage comme Codex ou Claude de fonctionner sans dépendre d’un service cloud.

En résumé, ds4 propose une solution cohérente pour exécuter localement des LLM de très grande taille, en s’appuyant sur une quantisation agressive et un cache persistant. La performance reste conditionnée par la bande passante SSD et la capacité de décodage du CPU/GPU, ce qui constitue la principale limitation à l’échelle des contextes ultra‑longs.