DeepSeek V4 en local en 2026 ? ds4 open source d'antirez et runbook location Mac cloud haute mémoire

L'écosystème local regorge de runtimes : llama.cpp, Ollama, vLLM et forks en série se disputent le titre de « chargeur universel ». ds4 inverse la logique — une famille de modèle, une pile optimisée de bout en bout. En C pur : exécuteur de graphe maison, chargement de poids dédié, rendu de prompt, tool calling, état KV RAM et disque, plus ds4-server comme couche API. L'ambition : sur une workstation haut de gamme ou un Mac Studio, offrir une expérience de code locale comparable aux modèles cloud — sans faire sortir le trafic du périmètre.

Le README officiel est clair : ds4 n'est pas un runner GGUF générique ni un emballage autour d'autres frameworks. Sur macOS, Metal est le chemin de production ; CUDA couvre Linux et DGX Spark ; le graphe CPU sert au diagnostic de correction. Sur certaines versions de macOS, l'inférence CPU peut déclencher des défauts de mémoire virtuelle noyau — la production doit rester sur Metal ou CUDA.

Pour un responsable technique, la question d'achat change. Plus « est-ce que notre GGUF charge ? », mais « avons-nous assez de mémoire unifiée sur Mac et acceptons-nous d'ancrer poids, KV et sémantique tool calling à ds4 et aux vecteurs officiels DeepSeek V4 Flash ? » Si oui, vous obtenez un plan d'inférence privé auditable de bout en bout. Sinon, les chargeurs génériques restent plus rapides pour expérimenter, moins adaptés aux spécificités MoE.

Benchmarks communautaires et documentation convergent : le goulot, c'est la RAM, pas l'absence de moteur. Le tableau suivant synthétise docs officielles, mesures Mac et niveaux de quantification courants — les chiffres exacts dépendent du paquet GGUF ou imatrix choisi :

• CapEx d'un coup : chercheurs isolés et équipes de moins de dix personnes peinent à justifier un portable 96 Go uniquement pour « essayer un MoE local ».
• Risque de mauvais achat : 64 Go semblent larges mais insuffisent pour Flash q2 ; 96 Go ne suffisent souvent pas pour q4 ou PRO — il faut changer de machine.
• Temps de mise en place : même avec le bon silicium, compilation, centaines de Go de poids, répertoires KV et ports API prennent souvent plusieurs jours avant un loopback stable avec Cursor.
• Profil de charge : l'inférence se concentre le soir et en fenêtres de release ; la machine reste vide en journée. Un Mac acheté peine à battre la location à l'heure sur l'utilisation réelle.

La vraie question en 2026 est donc : comment obtenir un environnement Metal + grosse mémoire exploitable en production à coût maîtrisé — pas de savoir si ds4 est « plus cool » que llama.cpp.

Le dépôt officiel et les premières mesures Mac et CUDA expliquent l'engouement :

• Metal en priorité : adaptation profonde au GPU Apple ; la communauté signale sur M5 Max un prefill autour de 463 t/s et une génération vers 34 t/s (selon quantification et contexte).
• Contexte million de tokens : fenêtre d'environ un million de tokens ; avec la compression KV de DeepSeek V4, gros dépôts et documents longs deviennent viables.
• KV sur disque : l'état KV peut persister sur NVMe et survivre aux sessions — moins de prefill répété sur de longues sessions de code.
• Experts de routage 2-bit : routeur MoE quantifié agressivement, autres couches plus précises — Flash plus tenable autour de 128 Go.
• API agent : tool calling, compatibilité OpenAI / Anthropic, ds4-server comme point de terminaison privé pour Cursor et OpenCode.

Metal comme cible principale n'est pas du marketing, c'est un alignement architecture / logiciel :

• Mémoire unifiée : CPU et GPU partagent la RAM physique ; des poids de 80 Go+ sans goulot de copie PCIe — difficile à reproduire sur x86 + GPU discret.
• Bande passante mémoire : les puces M en SKU haute bande passante offrent un débit d'inférence compétitif pour prefill et longs contextes.
• NVMe et KV disque : ds4 s'appuie sur SSD rapide pour KV persistant par session ; la pile macOS et les disques intégrés collent bien au modèle.

En bref : un Mac très mémoireé reste la meilleure forme grand public pour un MoE open source de pointe. Linux et CUDA fonctionnent (DGX Spark, etc.), mais les équipes iOS et full stack déjà dans Xcode, Cursor et macOS gagnent souvent plus avec un Mac haute mémoire en cloud ou sur le bureau qu'avec un second hôte Linux dédié à l'inférence.

• Modèle : DeepSeek V4 Flash environ 284B MoE / 13B actifs (sources publiques) ; ds4 se concentre sur Flash, PRO exige des paliers mémoire plus hauts.
• GitHub : ds4 a dépassé 10 000+ étoiles peu après l'ouverture — vérifiez le compteur live du dépôt.
• Bande passante : une Mac Studio Ultra atteint des débits mémoire unifiée dans la fourchette centaine de Go/s — pertinent pour « tout en UMA ».
• Location vs achat : un portable 96 Go se paie en une fois à quatre chiffres ; pour 40–80 heures concentrées par mois, un Mac cloud 128 Go à l'heure soulage souvent la trésorerie d'un ordre de grandeur — voir la page tarifs.
• Confidentialité : inférence locale ou sur instance dédiée : prompts et code hors API tierces ; pour finance, santé et réseaux souverains, c'est la différence structurelle avec « API cloud seulement ».

Ce runbook suppose un Mac cloud NUKCLOUD haute mémoire 96 Go+ — les frontières locataire et la baseline SSH peuvent être partagées avec le runbook agents GitHub :

1. 01
   Mémoire selon le modèle : Flash q2 au minimum 96 Go ; précision supérieure ou PRO → planifier 256 Go / 512 Go. Choisir la SKU sur la page commander — éviter « SSH oui, poids non ».
2. 02
   Geler la baseline : documenter minor macOS, Xcode Command Line Tools, état Metal ; quota disque pour poids + KV (souvent des centaines de Go libres).
3. 03
   Compiler ds4 : cloner github.com/antirez/ds4, make pour ./ds4 et ./ds4-server ; production Metal uniquement, pas de graphe CPU pour charge continue sur macOS.
4. 04
   Poids et KV : télécharger les paquets Flash conformes au README ; exemple : ./ds4-server --ctx 100000 --kv-disk-dir /var/ds4-kv --kv-disk-space-mb 8192 (adapter chemins et quotas).
5. 05
   Brancher les outils de code : Base URL Cursor/OpenCode vers loopback d'instance ou tunnel SSH (ex. http://127.0.0.1:8000) ; dépôts sensibles via VPN / lien privé, pas de port d'inférence public.
6. 06
   Coût et conformité : comparer CapEx/OpEx « Mac Studio sur site » vs Mac cloud à l'heure ; mutualisation avec le nœud CI Swift 6.

git clone https://github.com/antirez/ds4.git
cd ds4 && make
./ds4-server --ctx 100000 \
  --kv-disk-dir /var/ds4-kv \
  --kv-disk-space-mb 8192

Quand il faut à la fois confidentialité de niveau local et éviter de financer un Mac six chiffres, le Mac cloud très mémoireé tient souvent le milieu : ds4 + Metal, provisioning familier via la console.