antirez lance ds4 : le moteur d'inférence local qui rend DeepSeek V4 Flash utilisable sur un Mac

antirez lance ds4 : le moteur d'inférence local qui rend DeepSeek V4 Flash utilisable sur un Mac

🔎 Le créateur de Redis revient, et il a choisi son camp

Salvatore Sanfilippo — aka antirez — n'est pas un inconnu dans l'écosystème développeur. Il a créé Redis, l'un des systèmes de cache les plus utilisés au monde. Quand ce type sort un nouveau projet open source, on écoute. Surtout quand ce projet explose à 8000+ stars sur GitHub en quelques jours.

Son nouveau bébé s'appelle ds4. C'est un moteur d'inférence local écrit en C pur, optimisé exclusivement pour Apple Silicon via Metal, et conçu pour faire tourner un seul modèle : DeepSeek V4 Flash. Pas un runner GGUF générique, pas un wrapper autour de llama.cpp. Un moteur natif, monomodèle, taillé pour une architecture précise.

Le message est clair : le self-hosting de modèles frontier sur du hardware consumer n'est plus de la science-fiction. C'est du C compilé qui tourne sur votre MacBook.

L'essentiel

• ds4 est un moteur d'inférence en C pur, optimisé Metal, créé par antirez pour faire tourner DeepSeek V4 Flash (284B paramètres MoE) sur Apple Silicon.
• Il atteint 26 t/s sur un M3 Max avec contexte 1M tokens et thinking activé, grâce à une quantization asymétrique Q2 propriétaire.
• Le KV cache est stocké sur SSD, ce qui permet de gérer un contexte massif sans exploser la RAM.
• Un composant ds4-server expose des endpoints compatibles OpenAI et Anthropic, permettant de remplacer les API cloud en local.
• Ce n'est pas un outil généraliste : c'est un moteur dédié, et c'est précisément ce qui le rend si performant.

Outils recommandés

Ce qu'est vraiment ds4 — et ce qu'il n'est pas

ds4 est un moteur d'inférence, pas une bibliothèque générique. Il ne charge pas n'importe quel GGUF. Il ne se plugue pas sur vingt architectures différentes.

C'est un binaire compilé en C qui sait faire exactement une chose : exécuter DeepSeek V4 Flash sur des puces Apple M1/M2/M3/M4 avec le maximum de performance possible. Le code source est disponible sur le repo GitHub antirez/ds4.

Cette approche monomodèle est un choix architectural radical. La plupart des projets d'inférence locale (Ollama, llama.cpp, LM Studio) visent la généralité : supporter le plus grand nombre de modèles possible. ds4 fait le contraire. Il sacrifie la flexibilité pour gagner en performance pure.

Le résultat ? Un moteur qui compresse chaque cycle du processeur et chaque octet de mémoire带宽 au service d'un seul modèle.

Pourquoi un moteur dédié a un avantage structurel

Quand vous ciblez un modèle unique, vous pouvez optimiser à chaque couche. Vous connaissez la topologie exacte du réseau, les dimensions des matrices, les patterns d'attention. Vous n'avez pas de branchements conditionnels pour gérer des architectures différentes.

antirez a exploité cette connaissance pour écrire un pipeline Metal ultra-spécifique. Pas de kernel générique qui s'adapte à la volée. Des kernels écrits pour les dimensions exactes de DeepSeek V4 Flash.

C'est la même philosophie qui a fait le succès de Redis face à Memcached : sacrifier la généralité pour la performance sur un cas d'usage précis.

Les chiffres : 26 t/s sur M3 Max avec 1M tokens de contexte

Les benchmarks publiés par Pasquale Pillitteri dans son article technique sur ds4 sont sans appel. Sur un M3 Max, ds4 atteint 26 tokens par seconde en génération avec le thinking activé.

C'est impressionnant pour un modèle de 284 milliards de paramètres en architecture MoE (Mixture of Experts). Rappelons que DeepSeek V4 Flash n'active qu'une fraction de ses paramètres à chaque forward pass — c'est le principe du MoE — mais le modèle complet doit quand même résider quelque part.

Le contexte d'un million de tokens change la donne. Vous pouvez alimenter le modèle avec des dizaines de fichiers source, des logs complets, des documentations entières — et il garde tout en mémoire pendant la génération.

Le SSD comme RAM étendue : le KV cache sur disque

L'innovation la plus marquante de ds4, c'est son gestionnaire de KV cache. Le KV cache stocke les clés et valeurs d'attention calculées pour chaque token passé en contexte. Pour 1M tokens, ça ne tient pas dans la RAM d'un Mac, même bien équipé.

La solution de ds4 : utiliser le SSD comme cache actif. Les données de KV cache les plus récentes restent en RAM, les plus anciennes sont swappées sur SSD avec un accès séquentiel optimisé.

Les SSD NVMe modernes ont des débits séquentiels de plusieurs Go/s. En accédant au KV cache de manière prédictive et séquentielle, la pénalité par rapport à la RAM pure reste acceptable. C'est un trade-off intelligent : un peu plus lent qu'un tout-en-RAM, mais ça permet de monter à 1M tokens au lieu de 32K ou 128K.

La quantization Q2 asymétrique : l'autre secret de ds4

Un modèle de 284B en FP16 pèse environ 568 Go. Même en INT4, on parle de ~142 Go. Aucun Mac ne peut charger ça en entier en RAM.

C'est là que la quantization asymétrique Q2 spécifique à ds4 entre en jeu. La recipe de quantization est détaillée sur Hugging Face, et elle diffère significativement des approches GGUF standard.

Q2 asymétrique vs Q2 symétrique standard

En quantization symétrique, on divise les poids par un facteur unique et on arrondit. Simple, mais on perd de la précision là où la distribution des poids est asymétrique.

La Q2 asymétrique de ds4 utilise un offset en plus du facteur d'échelle. Cela permet de mieux capturer la distribution réelle des poids du modèle, surtout quand elle est centrée autour d'une valeur non-nulle.

Le résultat : une qualité de sortie nettement supérieure à ce qu'un Q2 standard produirait, pour un footprint mémoire identique. antirez a littéralement créé un format de quantization sur-mesure pour ce modèle.

Pourquoi ce n'est pas un GGUF "normal"

Les fichiers distribués sur antirez/deepseek-v4-gguf sont au format GGUF, mais attention : ils ne sont pas compatibles avec llama.cpp ou Ollama. Le format contient des métadonnées et des tables de quantization spécifiques que seul ds4 sait lire.

C'est un point crucial. Si vous téléchargez ces fichiers en pensant les utiliser avec votre setup Ollama existant, ça ne marchera pas. C'est un choix délibéré : le format est optimisé pour le pipeline interne de ds4, pas pour l'interopérabilité.

ds4-server : remplacer les API cloud en local

ds4 ne se contente pas d'un mode CLI. Le projet inclut ds4-server, un composant qui expose des endpoints HTTP compatibles avec les APIs OpenAI et Anthropic.

Concrètement, vous lancez ds4-server en local, et vous pouvez pointer n'importe quel client compatible OpenAI (Cursor, Continue, Claude Code, etc.) vers http://localhost:PORT au lieu de l'API OpenAI ou Anthropic.

C'est un game-changer pour les développeurs. Vous gardez votre workflow existant, vos outils, vos configurations — vous changez juste l'URL de base. Et au lieu de payer par token à OpenAI ou Anthropic, vous utilisez votre propre matériel.

Cette approche s'inscrit dans une tendance plus large : le développement avec des agents IA open source qui s'exécutent en local. ds4-server fournit l'infrastructure d'inférence sous-jacente, et les agents viennent se brancher dessus.

Limites actuelles de ds4-server

Il faut rester factuel : ds4-server est un composant jeune. Il gère les endpoints de chat et de complétion de base, mais ne supporte probablement pas encore toutes les features des APIs cloud (streaming complexe, function calling avancé, embeddings, etc.).

Le projet évolue rapidement — 8000 stars en quelques jours génèrent beaucoup de contributions — mais si vous avez besoin de function calling fiable ou de structured output, vérifiez l'état actuel du repo avant de migrer votre pipeline de production.

ds4 vs Ollama vs llama.cpp : lequel choisir ?

Le guide de CometAPI sur l'exécution locale de DeepSeek V4 compare les différentes approches disponibles. Voici une synthèse orientée pratique.

Ollama : le généraliste comfortable

Ollama est l'outil que je recommande le plus souvent pour installer un LLM local. Il est simple, bien documenté, gère des centaines de modèles. Son API est compatible OpenAI nativement.

Mais pour DeepSeek V4 Flash spécifiquement, Ollama utilise des kernels GGUF génériques. Il ne bénéficie pas de l'optimisation Metal fine-grained de ds4, ni de la quantization asymétrique Q2, ni du KV cache sur SSD.

Ollama reste le meilleur choix si vous voulez faire tourner plusieurs modèles différents sur votre Mac. C'est un couteau suisse.

llama.cpp : le moteur sous-jacent

llama.cpp est le projet fondateur de l'inférence LLM sur CPU/GPU consumer. Ollama, LM Studio et beaucoup d'autres l'utilisent en backend. Il supporte Metal, mais de manière générique.

Pour DeepSeek V4 Flash, llama.cpp peut charger des quantizations GGUF standard. La qualité sera inférieure à ds4 (pas de Q2 asymétrique) et le contexte sera limité par la RAM disponible (pas de KV cache sur SSD).

llama.cpp est parfait pour l'expérimentation et le développement de nouveaux formats. Mais en production pour ce modèle précis, ds4 le surpasse.

ds4 : le spécialiste qui gagne sur son terrain

Si votre besoin est unique — faire tourner DeepSeek V4 Flash le plus vite possible sur un Mac avec le plus grand contexte possible — ds4 n'a pas de concurrent. C'est un fusil de sniper face à deux couteaux suisses.

DeepSeek V4 Flash : pourquoi ce modèle mérite un moteur dédié

DeepSeek V4 Flash est un modèle MoE de 284B paramètres total, avec 28B paramètres activés par token. Disponible sur NVIDIA NIM, il est optimisé pour le coding et les agents.

Dans le classement des LLM open source de juin 2025, les variantes DeepSeek V4 Flash (Max et High) se placent respectivement aux rangs 5 et 7 avec des scores de 76 et 71. DeepSeek V4 Pro (Max) domine le classement à 88 points. La famille V4 est clairement la référence open-weight du moment.

Mais c'est Flash qui est le candidat idéal pour le local. Avec "seulement" 28B paramètres activés par forward pass, il demande beaucoup moins de compute que le Pro (745B total, 38B activés) tout en restant extrêmement compétent en code et en raisonnement.

C'est précisément le profil parfait pour un moteur spécialisé : un modèle suffisamment puissant pour être utile au quotidien, suffisamment léger à l'exécution (grâce au MoE) pour tourner sur du hardware consumer avec les bonnes optimisations.

Le guide de RunLocalAI sur DeepSeek V4 confirme cette position : V4 Pro est le leader open-weight en coding et mathématiques pour le printemps 2026, et V4 Flash en est la version "rapide" qui conserve une grande partie des capacités.

Ce que cela signifie pour le self-hosting de modèles frontier

Il y a dix-huit mois, faire tourner un modèle de 284B paramètres en local relevait de l'expérimentation de laboratoire. Vous aviez besoin d'un serveur avec plusieurs GPUs NVIDIA, d'une configuration complexe, et les performances étaient médiocres.

Aujourd'hui, un binaire en C de quelques mégaoctets, téléchargé depuis GitHub, fait tourner ce même modèle sur un MacBook Pro à 26 t/s avec un million de tokens de contexte.

Le changement est structurel, pas incrémental. La combinaison de plusieurs facteurs rend cela possible :

L'architecture MoE réduit drastiquement le compute par token. DeepSeek V4 Flash active 10% de ses paramètres à chaque passe.

La quantization agressive (Q2 asymétrique ici) réduit le footprint mémoire d'un ordre de grandeur par rapport au FP16, avec une perte de qualité minimale grâce à l'asymétrie.

Le SSD comme mémoire élimine le goulot d'étranglement de la RAM pour le contexte long. Les SSD modernes sont rapides enough pour du streaming séquentiel de KV cache.

Apple Silicon offre une bande passante mémoire unifiée (100-400 Go/s selon la puce) qui est idéale pour l'inférence LLM, bien supérieure à ce qu'un GPU NVIDIA discret offre dans le même budget.

Quand vous additionnez ces quatre facteurs, le résultat est que le hardware consumer rattrape le hardware datacenter pour des cas d'usage précis. Pas pour l'entraînement, pas pour le serving à grande échelle — mais pour l'usage individuel d'un développeur, oui.

Les innovations techniques en détail

Le pipeline Metal

Apple Metal est l'API graphique et compute d'Apple, l'équivalent de CUDA mais pour les puces M. Metal a longtemps été critiqué pour son SDK moins mature que CUDA. Mais pour un moteur dédié écrit en C, les primitives Metal suffisent largement.

antirez a écrit des kernels Metal spécifiques pour chaque opération du forward pass de DeepSeek V4 Flash : matmul, attention multi-tête, activation, RMSNorm. Chaque kernel est dimensionné pour les shapes exactes du modèle.

Pas de compilation JIT complexe, pas de recherche d'algo à l'exécution. Du code compilé qui fait exactement ce qu'il doit faire.

La gestion mémoire

ds4 sépare le modèle en deux parties : les poids (qui tiennent en RAM après quantization Q2) et le KV cache (qui déborde sur SSD). Cette séparation n'est pas triviale — il faut gérer les transferts de manière asynchrone pour ne pas bloquer la génération.

Le moteur précharge les blocs de KV cache depuis le SSD avant qu'ils ne soient nécessaires par le mécanisme d'attention. C'est du prefetching classique, appliqué à un problème nouveau.

Le mode thinking

DeepSeek V4 Flash supporte le "thinking" — une phase de raisonnement interne avant la génération de la réponse. ds4 active ce mode par défaut, ce qui signifie que les 26 t/s incluent les tokens de thinking (qui ne sont pas affichés à l'utilisateur).

C'est important pour comparer avec d'autres benchmarks qui parfois ne comptent que les tokens de sortie visible. Le thinking consomme du compute mais améliore significativement la qualité des réponses sur les tâches complexes.

❌ Erreurs courantes

Erreur 1 : Confondre les GGUF ds4 avec des GGUF standard

Les fichiers GGUF de ds4 contiennent des tables de quantization propriétaires. Les charger dans Ollama ou llama.cpp produira des erreurs ou des sorties incohérentes. Téléchargez-les uniquement depuis le repo Hugging Face d'antirez et utilisez-les exclusivement avec ds4.

Erreur 2 : S'attendre à des performances similaires sur Intel Mac

ds4 est optimisé pour Apple Silicon via Metal. Il ne fonctionnera pas (ou de manière extrêmement dégradée) sur un Mac Intel. Si vous n'avez pas de puce M1 ou ultérieure, passez votre chemin et regardez du côté de llama.cpp ou d'Ollama.

Erreur 3 : Sous-estimer les besoins en stockage SSD

Le KV cache sur SSD signifie que votre disque va être sollicité intensément pendant la génération avec un long contexte. Un SSD NVMe interne est indispensable. Un disque dur externe USB ou un SSD SATA lent rendra l'expérience insupportable.

Erreur 4 : Comparer les t/s sans préciser le mode thinking

26 t/s avec thinking activé, ce n'est pas 26 t/s de tokens visibles. Si vous désactivez le thinking, la vitesse de sortie apparente sera différente. Précisez toujours votre configuration quand vous reportez des benchmarks.

❓ Questions fréquentes

ds4 peut-il tourner sur un Mac M1 de base avec 8 Go de RAM ?

Théoriquement oui grâce au KV cache sur SSD, mais l'expérience sera très lente. Le M1 de base a une bande passante mémoire de 68 Go/s et 8 Go de RAM partagée entre le système et le modèle. Un M1 Pro/Max avec 32 Go+ est le minimum recommandé pour une utilisation confortable.

Puis-je utiliser ds4 avec mon IDE (VS Code, Cursor) ?

Oui, via ds4-server qui expose des endpoints compatibles OpenAI. Configurez votre extension d'IA pour pointer vers l'URL locale de ds4-server. C'est l'un des cas d'usage les plus pratiques du projet.

ds4 remplacera-t-il Ollama ?

Non. ds4 est un outil spécialisé pour un modèle précis. Ollama reste le meilleur choix pour gérer plusieurs modèles, expérimenter, et avoir une interface unifiée. Les deux outils coexistent : Ollama pour le quotidien polyvalent, ds4 quand vous avez besoin du maximum de perf sur DeepSeek V4 Flash.

La quantization Q2 ne dégrade-t-elle pas trop la qualité ?

En quantization symétrique standard, Q2 est effectivement très agressif. Mais la Q2 asymétrique de ds4 compense significativement cette perte. Les retours utilisateurs preliminaires suggèrent une qualité comparable au Q4 standard pour ce modèle spécifique. Le format est taillé pour la distribution de poids de V4 Flash.

Existe-t-il un équivalent ds4 pour les PCs NVIDIA ?

Pas à ce jour. Le projet est explicitement ciblé sur Apple Silicon et Metal. Sur NVIDIA, l'écosystème existe déjà (TensorRT-LLM, vLLM, llama.cpp avec CUDA), et le besoin d'un moteur dédié est moindre car la bande passante mémoire des GPUs NVIDIA est généralement supérieure à celle des puces M.

✅ Conclusion

ds4 prouve qu'un moteur d'inférence taillé sur mesure pour un modèle précis sur du hardware précis peut battre les solutions généralistes. antirez applique la philosophie de Redis à l'inférence LLM : spécialisation radicale, performance brute, code propre en C. Le self-hosting de modèles frontier sur Mac n'est plus une expérimentation — c'est un workflow opérationnel. Si vous avez un Mac avec une puce M et que vous voulez le meilleur LLM pour coder en local, ds4 mérite votre attention.