2026 : exécuter DeepSeek V4 Flash en local avec antirez ds4 — facture matérielle réelle sur Mac 96 / 128 / 256 / 512 Go et matrice de décision pour les nœuds Mac en cloud

Ce qu'est vraiment ds4 : pourquoi antirez n'a pas écrit un énième runner GGUF générique

ds4, abréviation de DwarfStar 4, est signé Salvatore Sanfilippo (antirez), l'auteur de Redis. Ce n'est pas un wrapper autour de llama.cpp, ni un chargeur GGUF générique, ni un énième UI web. C'est un moteur d'inférence natif conçu pour un seul modèle : DeepSeek V4 Flash. Les backends principaux sont Metal sur macOS et CUDA sur Linux, y compris le DGX Spark. AMD ROCm est maintenu sur une branche séparée. Cette spécialisation explique pourquoi ds4 a glané des dizaines de milliers d'étoiles GitHub en quelques jours et atteint des chiffres hors de portée des runners génériques.

Restreindre le périmètre rapporte des bénéfices tangibles. ds4 maîtrise la pipeline de routage MoE de DeepSeek V4 de bout en bout, ce qui lui permet d'appliquer une quantification 2-bit agressive aux experts de routage tout en conservant une précision plus élevée sur le reste du graphe. La fenêtre de contexte d'1 million de tokens est traitée comme une citoyenne de première classe grâce au déversement à la demande du cache KV sur disque, qui évite de recalculer le prefill à chaque session. Un boucle de tool calling et un agent de code sont intégrés au moteur, sans framework collé par-dessus. La liste ci-dessous récapitule les choix.

1. 01

   Un seul modèle, poussé à fond. Le README est explicite : ds4 n'est ni un runner GGUF, ni un wrapper, ni un framework. Chaque chemin d'exécution graphique est calibré pour la structure MoE de DeepSeek V4 Flash, ce qui permet une quantification agressive des experts de routage et le maintien de la précision ailleurs. Les runners génériques évitent cela pour des raisons de portabilité.

2. 02

   Metal d'abord, CUDA en parallèle, CPU pour le diagnostic. Sur macOS, make construit le backend Metal. Sur Linux, on utilise make cuda-spark ou make cuda-generic. Le README prévient que l'implémentation actuelle de la mémoire virtuelle macOS peut faire paniquer le noyau sur le chemin CPU : sur Mac, ne jamais inférer hors de Metal.

3. 03

   Cache KV sur disque intégré. Au lancement de ds4-server, on passe --kv-disk-dir et --kv-disk-space-mb. L'état KV est persisté et réutilisable entre sessions. Combiné au SSD interne d'un Mac, ce mécanisme transforme la fenêtre d'1 M tokens d'une taxe permanente en un coût récupérable.

4. 04

   Serveur compatible OpenAI avec agent intégré. ds4-server expose /v1/chat/completions, de sorte que Cursor, opencode, Claude Code ou tout client respectant le protocole OpenAI peuvent s'y connecter directement. Le tool calling est natif et permet une boucle d'agent de code productive sans framework supplémentaire.

5. 05

   Auditable par la petite taille. Le projet est autonome et n'embarque pas de runtime tiers. La base de code reste assez compacte pour qu'une petite équipe puisse auditer le graphe et les choix de quantification. Pour qui exécute de grands modèles en production, cet atout n'est pas anodin.

Une fois admis que ds4 cible exclusivement Flash par conception, la section suivante coule de source. L'affirmation récurrente selon laquelle PRO tournerait sur un Mac Studio 512 Go demande un correctif précis, d'autant qu'elle revient souvent.

Pourquoi un Mac s'impose : Unified Memory, bande passante et cache KV sur disque

Si ds4 place Metal en premier, c'est par nécessité d'ingénierie. L'Unified Memory d'Apple Silicon (UMA) partage un pool unique entre CPU et GPU. Aucun aller-retour PCIe ne déplace les tenseurs entre VRAM et RAM système. Pour un modèle MoE comme Flash, où chaque token n'active qu'une partie des experts, l'UMA permet de tirer les poids nécessaires depuis un grand pool commun, sans buter sur un plafond de mémoire GPU dédié. Aux prix grand public, aucune autre plateforme n'offre 96 Go en bas de gamme et 512 Go en haut de gamme comme mémoire d'inférence effective.

Le deuxième facteur est la bande passante mémoire. Le M3 Max plafonne autour de 400 Go/s et le M3 Ultra double pour atteindre près de 800 Go/s. C'est cette bande passante qui explique les ~449 t/s de prefill long sur un Mac Studio M3 Ultra. La bande passante détermine la vitesse à laquelle les poids sont lus, ce qui constitue le goulot dominant pour l'inférence MoE. Sur un Mac, elle est contiguë, jamais fragmentée entre plusieurs GPU discrets.

Le troisième facteur passe souvent inaperçu. Les SSD NVMe internes des Mac modernes s'accordent parfaitement au cache KV sur disque de ds4. ds4-server écrit l'état KV dans le chemin fourni par --kv-disk-dir et limite l'empreinte avec --kv-disk-space-mb. À la reprise d'une même session, on économise plusieurs secondes voire minutes de prefill. Les SSD internes Apple atteignent 5 à 7 Go/s en séquentiel, ce qui rend l'option « décharger et recharger » plus économique que de payer en RAM pour chaque session simultanée.

Mises bout à bout, ces caractéristiques mènent à une conclusion limpide. Dans le matériel grand public de 2026, rien n'épouse mieux la combinaison « DeepSeek V4 Flash + ds4 + long contexte + KV sur disque » qu'un Mac à forte mémoire. La question qui reste est financière : pouvez-vous acquérir un Mac 256 ou 512 Go, et serez-vous en mesure de l'utiliser suffisamment pour rentabiliser l'investissement ?

Checklist minimale de mise en route de ds4 sur un nœud Mac cloud VpsMesh avec branchement Cursor

Les six étapes qui suivent compressent tout ce qui précède en un Runbook reproductible. Hypothèse de base : un nœud Mac VpsMesh, 128 Go minimum, 256 Go recommandé, 512 Go pour un confort longue contexte. Chaque étape comporte un critère succès/échec explicite et peut être réutilisée telle quelle par votre équipe.

1. 01

   Compiler ds4 avec le backend Metal. git clone https://github.com/antirez/ds4 && cd ds4 && make. Vous obtenez ./ds4 (CLI) et ./ds4-server (HTTP). Succès : les deux binaires existent et ./ds4 --help renvoie l'aide. Ne jamais exécuter make cpu sur macOS : le chemin CPU peut paniquer le noyau.

2. 02

   Test de bon fonctionnement Metal. Exécuter ./ds4 -p "Hello" --metal avec un prompt très court pour confirmer l'acquisition du device et le graphe de base. Sur un nœud de 128 Go ou plus, on peut passer directement au chargement des poids Flash q2. Succès : pas d'erreur « Metal device not available », pas d'OOM.

3. 03

   Télécharger et vérifier les poids DeepSeek V4 Flash q2 ou q4. Utiliser la source GGUF indiquée par le projet ds4 ; environ 86,7 Go pour q2 et 150 Go pour q4. Toujours vérifier le SHA256. Séparer les volumes : poids sur un disque de données ≥ 500 Go libre, KV sur le SSD interne du Mac. Succès : empreinte correcte ; df -h montre au moins 100 Go de marge sur le disque de données.

4. 04

   Démarrer ds4-server avec KV sur disque. Exemple : ./ds4-server --ctx 200000 --kv-disk-dir /Volumes/ssd-kv/ds4-kv --kv-disk-space-mb 16384 --bind 127.0.0.1:8080. Démarrer avec une fenêtre de 200k, pas 1M, pour éviter la pression mémoire initiale. Succès : le log de démarrage indique Metal prêt et le répertoire KV inscriptible ; curl http://127.0.0.1:8080/v1/models renvoie du JSON.

5. 05

   Brancher Cursor, opencode ou Claude Code. Faire pointer l'URL de base du client sur ds4-server via un tunnel SSH qui redirige le 8080 distant vers 127.0.0.1:8080 local. Ne jamais exposer 8080 sur 0.0.0.0. Régler l'en-tête Authorization conformément aux options de démarrage et choisir le nom de modèle documenté par la version courante de ds4. Succès : une petite requête streaming à /v1/chat/completions renvoie 200 OK.

6. 06

   Mettre en place l'observabilité et une règle de retrait. Surveiller mémoire et disque avec vm_stat, memory_pressure et iostat. Définir des déclencheurs : swap durablement élevé, prefill sous 50 % de la base, ou répertoire KV au-delà de 80 % de --kv-disk-space-mb — basculer sur une API cloud (OpenAI, Anthropic ou DeepSeek officiel). Succès : le chemin de bascule produit un résultat comparable pour la même entrée.

ssh -L 8080:127.0.0.1:8080 vpsmesh-mac-node \
  './ds4-server \
     --ctx 200000 \
     --kv-disk-dir /Volumes/ssd-kv/ds4-kv \
     --kv-disk-space-mb 16384 \
     --bind 127.0.0.1:8080'

curl -sS http://127.0.0.1:8080/v1/chat/completions \
  -H "Authorization: Bearer $DS4_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-flash-q4","messages":[{"role":"user","content":"hello"}],"stream":false}' \
  | jq .

Trois données clés à coller dans le README de l'équipe :

• Référence de débit. Sur un Mac Studio M3 Ultra 512 Go, q4 en prompt long atteint ~449 t/s en prefill et ~26,6 t/s en génération. Sur un MacBook Pro M3 Max 128 Go, q2 en prompt long atteint ~250 t/s en prefill et ~21,5 t/s en génération. Utilisez ces chiffres comme indicateurs de santé par nœud.
• Budget mémoire. Poids q2 ~86,7 Go + KV pour 200k tokens ~8–14 Go + système ~8 Go ≈ 110 Go au démarrage. Un nœud 96 Go est donc limité aux contextes courts, 128 Go forme le plancher réel de laboratoire, et 256 Go libèrent de la marge pour le KV et les sessions concurrentes.
• Dimensionnement du KV disque. Démarrer --kv-disk-space-mb à 16 Go et prévoir ~1–3 Go par session longue. Toujours utiliser le SSD interne ; un disque externe fait du rechargement KV le nouveau goulot.

Si vous arbitrez entre l'achat d'un Mac Studio 256 ou 512 Go et la location d'un Mac cloud pour ds4, faites entrer deux postes dans votre comparaison. D'abord la facture cachée d'une machine physique : électricité, bruit, refroidissement, réparations après garantie, et les deux ou trois prochaines générations d'Apple Silicon attendues sur trois ans. Ensuite la charge d'exploitation de l'auto-hébergement : assurer la persistance de ds4-server à chaque redémarrage, surveiller le niveau du KV disque, garder la liaison Cursor ou opencode résiliente. Rien de tout cela n'est l'activité que vous valorisez. Pour les développeuses indépendantes, chercheurs et petites équipes qui préfèrent passer leur temps à faire tourner des modèles et écrire du code plutôt qu'à entretenir une machine, les nœuds Mac VpsMesh à forte mémoire — modulables entre 96 / 128 / 256 / 512 Go selon la demande — restent le choix le plus réaliste et le plus économique. Commencer par une semaine de 128 Go pour valider l'ajustement Flash q2, poursuivre par un mois de 256 Go pour rendre Cursor et un agent de code agréables à vivre, puis décider d'un 512 Go résident. Cette progression est nettement moins risquée que l'achat immédiat d'un Mac Studio haut de gamme au prix d'une petite voiture.