2026 : DeepSeek V4 en local avec antirez ds4 (DwarfStar)
barrière 96 Go+ et location cloud Mac haute mémoire NOVAKVM

En 2026, les équipes macOS qui veulent DeepSeek V4 en local sans externaliser chaque session de coding agent se tournent vers antirez ds4 (DwarfStar) : un moteur d'inférence étroit, autonome, pensé d'abord pour Metal. Le README upstream fixe le plancher à 96 Go de mémoire unifiée pour Flash et à la classe Mac Studio 512 Go pour PRO. La majorité des flottes reste sur des Mac mini 16 ou 24 Go, incapables de charger les poids q2-imatrix recommandés. Ce billet s'adresse aux responsables techniques qui arbitrent entre l'achat d'un MacBook Pro 96 Go, d'un Studio, ou une location bare metal Apple Silicon toujours allumée pour ds4-server, le KV disque et les clients agents. Vous y trouverez les points de friction, une matrice de décision, l'architecture Metal/KV, un runbook en huit étapes, des chiffres issus du README ds4 (à revérifier à chaque release), et une conclusion NOVAKVM sur six régions. Tarifs : page tarifs ; commande : commander ; accès distant : centre d'aide ; croisez avec fenêtres CI et agents et OpenClaw SSH distant.

[ SECTION_01 ] // PAIN_MAP Pourquoi la plupart des flottes Mac ne peuvent pas héberger Flash localement

• La mémoire unifiée prime sur les cœurs. Flash en q2-imatrix implique environ 81 Go de poids seuls dans les notes de budget mémoire du README. Un Mac mini 16 ou 24 Go échoue avant même d'ouvrir un grand contexte.
• Plancher documenté : 96 Go ; zone confortable : 128 Go. Metal démarre sur des MacBook à partir de 96 Go de RAM ; les presets de téléchargement ciblent q2-imatrix pour des machines 96/128 Go. Les retours communautaires sur 96 Go avec contexte réduit après nettoyage de processus ne constituent pas un SLA d'équipe.
• Ambition de contexte vs résidence des poids. Jusqu'à 1 million de tokens sont annoncés ; le README évoque environ 26 Go supplémentaires pour un très grand contexte (indexeur compressé ~22 Go) et recommande 100k–300k tokens sur 128 Go avec q2.
• PRO est une autre ligue. pro-imatrix vise le Mac Studio 512 Go ; en deçà, PRO reste expérimental.
• Pas de chargeur GGUF générique. Seuls les GGUF Flash et PRO publiés pour ce projet sont supportés ; les fichiers tiers ne correspondent pas au layout tenseur ni au mix de quantification.
• Thermique et charge continue. Les longs prefills Metal saturent le GPU ; --power N limite la charge. Un portable en inférence 24h/24 n'a pas la même ergonomie qu'un Mac mini en salle.
• Maturité beta/alpha. Inférence et serving en beta, ds4-agent en alpha : prévoyez snapshots disque et fenêtres de changement.

[ SECTION_02 ] // DECISION_MATRIX MacBook 96 Go vs Studio vs location Mac dédiée

La question n'est pas « local ou cloud », mais qui porte l'inférence 24h/24, le risque mémoire et la latence régionale — et si vos traces d'agents restent sur du matériel que vous contrôlez.

La barrière n'est pas « Apple Silicon oui/non », mais la capacité à garder poids + KV + outils agents en mémoire unifiée sans partager le pool avec Xcode et les simulateurs.

[ SECTION_03 ] // ENGINE DwarfStar : Flash Metal, KV sur disque, serveur façon OpenAI

DwarfStar cible étroitement DeepSeek V4 Flash ; PRO est un chemin annexe sur machines très larges. Le dépôt fournit chargement, rendu de prompts, appels d'outils, KV RAM et disque, serveur HTTP et agent de code natif aligné sur les flux DSML. Metal est le backend principal sous macOS, au cœur des workflows créatifs Apple.

Deux idées structurent l'architecture : le README fait du disque un citoyen de premier rang pour le KV ; ds4-server expose des endpoints compatibles OpenAI, Anthropic et Responses pour brancher Codex ou OpenCode sans réécrire la stack. La relecture exacte des blocs DSML échantillonnés évite de reconstruire tout le KV à chaque tour d'outil.

Les commandes, quants et budgets mémoire font foi dans le README antirez/ds4 et les poids Hugging Face — rouvrez-les après chaque tag.

https://github.com/antirez/ds4

https://huggingface.co/antirez/deepseek-v4-gguf

[ SECTION_04 ] // RUNBOOK Huit étapes : déployer ds4-server sur un Mac distant dédié

Prérequis : Mac mini NOVAKVM dédié, tier mémoire maximal, NVMe rapide, SSH équipe. Vérifiez les flags sur le binaire compilé.

1. Choisir la classe mémoire sans illusion. Sous 96 Go unifiés, ne planifiez pas Flash q2-imatrix à grand contexte. Utilisez le nœud loué pour builds, téléchargements GGUF, tests KV disque ou serveur relais pendant que Flash tourne ailleurs sur 96 Go+.
2. Dimensionner le disque avant le réseau. Réservez des centaines de Go pour ./gguf/ et --kv-disk-dir ; extensions 1–2 To si plusieurs quants coexistent.
3. Compiler Metal. Cloner ds4, make macOS, valider ./ds4 et ./ds4-server sans piège CPU-only signalé dans le README macOS.
4. Télécharger les poids. ./download_model.sh q2-imatrix pour classe 96/128 Go ; pro-imatrix uniquement sur 512 Go.
5. CLI puis serveur. Smoke ./ds4 -p avec --nothink ; lancer le serveur avec --ctx, --kv-disk-dir, --kv-disk-space-mb en loopback d'abord.
6. Exposer l'API proprement. Tunnel SSH ou reverse proxy TLS devant loopback ; --host 0.0.0.0 seulement en connaissance de cause ; --cors pour clients navigateur.
7. Brancher les agents de code. Clients sur /v1/chat/completions ou /v1/responses ; plafond de contexte ≤ --ctx serveur ; IDs d'outils stables.
8. Exploiter avec traces et plafond de puissance. --trace pour audit ; --power 70 sur hôte partagé ; snapshot KV disque avant upgrade GGUF.

$ ./download_model.sh q2-imatrix
$ make
$ ./ds4-server \
    --ctx 200000 \
    --kv-disk-dir /var/ds4/kv \
    --kv-disk-space-mb 16384 \
    --power 75 \
    --host 127.0.0.1

listening: http://127.0.0.1:8000/v1/models
tunnel: ssh -L 8000:127.0.0.1:8000 user@remote-mac

[ SECTION_05 ] // HARD_FACTS Chiffres ds4 citables (vérifier le README upstream)

• Entrée Metal : README — Metal à partir de MacBooks 96 Go RAM ; Flash au centre, PRO expérimental hors classe 512 Go.
• Presets quant : q2-imatrix pour 96/128 Go ; q4-imatrix pour >= 256 Go ; pro-imatrix pour 512 Go.
• Contexte vs RAM : ~26 Go supplémentaires pour très grand contexte ; fenêtre 100k–300k recommandée sur 128 Go avec q2 ; retours 250k sur 96 Go avec hygiène processus stricte.
• Empreinte poids : notes serveur — quants 2 bit ~81 Go, d'où l'échec des hôtes 64 Go pour le graphe Flash documenté.
• Vitesse (table README) : ex. M5 Max 128 Go q2 génération ~34,27 t/s ; Studio M3 Ultra 512 Go PRO q2 à 32768 tokens prefill ~138,82 t/s, génération ~9,56 t/s.
• Maturité : inférence beta, agent alpha.

[ SECTION_06 ] // PLATFORM_CLOSE Six régions et pourquoi la location NOVAKVM haute mémoire gagne

Singapour et Hong Kong réduisent la RTT APAC vers ds4-server. Tokyo et Séoul gardent les sessions en région pour le Japon et la Corée. US East et US West améliorent les allers-retours GitHub et Hugging Face pour les équipes américaines — utile quand les workflows créatifs Apple partagent la même fenêtre horaire que les pipelines CI US.

Dimensionnez le tier M4 Pro 64 Go / 2 To NOVAKVM pour production ds4 adjacente : serveur permanent, stockage GGUF massif, KV disque NVMe, clients OpenClaw/Codex, CI de build ds4. Le Flash q2-imatrix plein à grand contexte reste aligné sur 96 Go+ selon upstream ; ajustez quant et --ctx au RAM réellement loué. Voir la matrice stockage parallèle si le disque sature avant le GPU.

Limites des alternatives. API seule : coût récurrent et données hors de votre périmètre. MacBook Pro 96 Go personnel : thermique et mobilité. Studio unique : immobilisation et latence mono-région. GPU cloud générique sans chemin Metal ds4 documenté : risque de compatibilité.

Pour un hôte Apple Silicon stable et géographiquement placé pour serveurs DwarfStar, clients agents et disques GGUF rapides, la location cloud Mac mini bare metal NOVAKVM est en général le meilleur compromis : six régions, Metal dédié, durées jour/semaine/mois, tiers Pro avec stockage To pour poids et KV disque. Consultez les tarifs, lancez un pilote via commander, et le centre d'aide pour SSH et sauvegardes avant de pointer vos agents de production vers un nouvel endpoint.