Cos’è ds4 e perché usarlo

Benvenuto nel primo capitolo della guida. Qui capirai cosa rende ds4 diverso da qualsiasi altro loader di modelli LLM.

Cosa è ds4?

ds4 (chiamato anche DwarfStar) è un motore di inferenza nativo, auto-contenuto e volutamente ristretto progettato da Salvatore Sanfilippo (antirez, il creatore di Redis) per eseguire DeepSeek V4 Flash e DeepSeek V4 PRO su hardware personale di fascia alta.

Non è un wrapper attorno a llama.cpp, non è un runner GGUF generico. È un’implementazione scritta in C, Metal e CUDA che fa una sola cosa, ma la fa in modo completo e ottimizzato: far girare DeepSeek V4 in locale con qualità prossima ai modelli frontier.

“This project takes a deliberately narrow bet: one model at a time, official-vector validation, long-context tests, and enough agent integration to know if it really works.”

La filosofia monomodello (e perché è importante)

La maggior parte dei progetti di inferenza locale (come llama.cpp, Ollama, LM Studio) puntano a supportare centinaia di modelli. ds4 fa l’esatto opposto: supporta un solo modello alla volta, ma lo supporta in modo verticale.

Cosa significa “verticale”?

Validazione ufficiale – I logits (probabilità dei token) generati da ds4 vengono confrontati con quelli dell’API ufficiale di DeepSeek, token per token. Se c’è una minima differenza, è un bug.
Tool calling nativo – Non c’è conversione tra formati (es. OpenAI → DSML). ds4 parla direttamente il linguaggio dei tool di DeepSeek.
Cache KV su disco – Le conversazioni possono essere salvate e riprese istantaneamente, anche dopo un riavvio del server.
Agente integrato – Un’interfaccia testuale che controlla direttamente l’inferenza, senza passare da socket HTTP.

Questa scelta progettuale permette a ds4 di essere più veloce, più affidabile e più facile da eseguire per il modello supportato, a scapito della flessibilità.

Nota: Il modello supportato può cambiare nel tempo. Oggi è DeepSeek V4 Flash/PRO. Se domani uscisse un modello open-weight migliore (sempre nelle taglie 128 GB o 512 GB), ds4 potrebbe “switchare” e abbandonare DeepSeek. Il progetto è opportunistico, non legato a un singolo modello per sempre.

Perché DeepSeek V4?

DeepSeek V4 (Flash e PRO) ha alcune caratteristiche che lo rendono ideale per l’inferenza locale su hardware personale:

È un modello MoE (Mixture of Experts) – Solo una piccola parte dei parametri viene attivata per ogni token. Questo lo rende molto efficiente in termini di calcolo.
KV cache compressa 4:1 – La memoria necessaria per il contesto è ridotta di un fattore 4 rispetto ai modelli classici, permettendo contesti enormi (fino a 1 milione di token) con poca RAM.
Resiste molto bene alla quantizzazione 2 bit – Anche compresso a soli 2 bit (con una strategia asimmetrica), il modello mantiene qualità utili per coding e tool calling.
È “quasi-frontier” – Le prestazioni sono paragonabili a modelli molto più grandi, ma la dimensione dei pesi (circa 80 GB in 2 bit) è accessibile su Mac con 96/128 GB.

I tecnicismi che devi conoscere (anticipo)

Nel resto della guida approfondiremo ogni concetto, ma per ora ecco un glossario minimo:

GGUF – Il formato di file che contiene i pesi quantizzati del modello e i metadati. ds4 carica i tensori direttamente da questi file.
KV Cache – Una struttura dati che memorizza le rappresentazioni intermedie dei token già processati. Evita di ricalcolare tutto da capo a ogni nuovo token.
MoE (Mixture of Experts) – Architettura in cui solo pochi “esperti” (sottomodelli) sono attivi per ogni token. DeepSeek V4 ha centinaia di esperti routed, più alcuni esperti condivisi.
Quantizzazione asimmetrica – Diversi componenti del modello vengono quantizzati con precisioni diverse: gli esperti routed a 2 bit, le proiezioni a 8 bit, ecc. Perché? Gli esperti routed sono molti e poco attivati, quindi si può risparmiare memoria senza perdere troppa qualità.
Streaming su SSD – Quando il modello non entra in RAM, ds4 può tenere su SSD la maggior parte degli esperti routed e caricarli al bisogno. La latenza delle SSD moderne è sufficiente a mantenere una velocità accettabile.
Inferenza distribuita – Suddividere i layer del modello su più macchine collegate in rete. Utile per modelli enormi (es. PRO Q4) o per accelerare il prefill di prompt lunghissimi.

Hardware supportato (e requisiti minimi)

ds4 supporta tre backend principali:

Backend	Hardware	Comando di compilazione
Metal	Mac con chip Apple Silicon (M3, M5, M3 Ultra) e almeno 64 GB di RAM (meglio 96/128 GB)	`make`
CUDA	DGX Spark / GB10 o schede NVIDIA generiche con driver CUDA	`make cuda-spark` o `make cuda-generic`
ROCm	Sistemi Strix Halo (es. Framework Desktop)	`make rocm` (in sviluppo)

La modalità CPU esiste solo per debug e test di correttezza, non è pensata per produzione. Anzi, su macOS c’è un bug nel kernel che può causare il crash del sistema se usi la CPU. Quindi usa Metal o CUDA.

Requisiti di RAM minimi consigliati (per Flash, non PRO):

Modello in RAM (veloce): 96 GB – 128 GB.
SSD streaming (lento ma funziona): 64 GB (con cache esperti 32 GB).

Cosa puoi fare con ds4 (casi d’uso)

Chat locale – Usare il CLI ./ds4 per conversare con DeepSeek V4 in modalità thinking.
Server API locale – Eseguire ./ds4-server e collegare agent come Codex CLI, Claude Code, Pi, OpenCode. Compatibile con OpenAI, Anthropic e Responses API.
Coding agent nativo – ./ds4-agent offre un’esperienza integrata con persistenza delle sessioni, switching rapido tra chat, tool calling.
Benchmark e valutazione – ds4-bench misura prefill e generazione a diverse lunghezze di contesto. ds4-eval testa il modello su 92 domande selezionate (GPQA, AIME, sicurezza).
Inferenza distribuita – Unire due Mac Studio per far girare il PRO Q4 da 512 GB.

Stato del progetto (beta, ma usabile)

Il codice e i file GGUF sono considerati qualità beta. Il progetto esiste solo da pochi giorni (primo rilascio 6 maggio 2026) e ci vorranno mesi per raggiungere una forma stabile. Tuttavia, il team (guidato da antirez) sta facendo progressi rapidi e il software è già in grado di eseguire inferenza, tool calling e agent in modo affidabile.

Attenzione: Alcune funzionalità sono ancora acerbe: MTP (speculative decoding) dà poco guadagno, l’agente è alpha, la distribuzione su reti lente può essere frustrante. Ma la base è solida.

Prossimi passi

Ora che hai capito il “perché” di ds4, sei pronto per passare alla pratica:

👉 Capitolo 2: Concetti fondamentali (glossario) – Approfondiamo MoE, KV cache compressa, quantizzazione asimmetrica.
👉 Oppure salta al Capitolo 3: Installazione e primo avvio per iniziare subito a usare ds4.

💡 Consiglio: Se sei già pratico di LLM, puoi leggere in ordine saltuario. Ma se vuoi capire a fondo ds4, ti consiglio di seguire i capitoli in sequenza, perché ogni concetto viene costruito sul precedente.

📘 Approfondimento: Perché antirez ha scritto ds4 da zero invece di contribuire a llama.cpp?

La ragione principale è la filosofia monomodello. llama.cpp è un progetto generico che supporta centinaia di architetture. Per ottimizzare per DeepSeek V4, antirez avrebbe dovuto inserire molte “special case” e compromessi. Invece, partendo da zero, può fare scelte radicali: ad esempio trattare la cache KV come “cittadino di primo livello del disco”, usare un formato di salvataggio specifico per lo stato delle sessioni, e validare ogni modifica contro i logits ufficiali. Il risultato è un codice più mirato, anche se meno riutilizzabile.

⚠️ Avvertenza importante

Su macOS, la modalità CPU (compilata con make cpu) può causare il crash del kernel e il riavvio forzato del computer. È un bug di macOS non risolvibile da ds4. Usa esclusivamente il backend Metal per l’inferenza su Mac.