2026: Run DeepSeek V4 Flash Locally with antirez ds4 — Real Hardware Bill on 96 / 128 / 256 / 512 GB Macs and a Cloud-Rent Decision Matrix

What ds4 actually is: why antirez did not write another general GGUF runner

ds4, short for DwarfStar 4, is by Salvatore Sanfilippo (antirez), the author of Redis. It is not a wrapper around llama.cpp. It is not a general GGUF loader. It is not yet another web UI. It is a native inference engine purpose-built for one model: DeepSeek V4 Flash. The primary backends are Metal on macOS and CUDA on Linux, including the DGX Spark. AMD ROCm lives in a separate branch. This deliberate narrowness is the reason ds4 picked up tens of thousands of GitHub stars in days and posts numbers that general runners cannot match.

The narrow scope buys real things. ds4 controls the MoE routing pipeline of DeepSeek V4 end to end, so it can apply aggressive 2-bit quantization to the routing experts while keeping the rest of the graph at higher precision. It treats the 1M-token context window as a first-class concern by spilling the KV cache to disk on demand, instead of recomputing prefill on every session. It ships a tool-calling loop and a coding agent that are part of the engine, not a separate framework glued on top. The list below summarizes the design choices and why they matter.

1. 01

   One model, taken to the limit. The README is explicit: ds4 is not a GGUF runner, not a wrapper, not a framework. Every graph path is built for the DeepSeek V4 Flash MoE structure, so routing experts can be quantized hard while the rest of the network keeps precision. Generic runners almost never do this for portability reasons.

2. 02

   Metal first, CUDA in parallel, CPU only for diagnostics. On macOS you build with make. On Linux you build with make cuda-spark or make cuda-generic. The README warns that current macOS virtual-memory behavior can kernel-panic when you actually use the CPU path, so do not try to run inference without Metal on a Mac.

3. 03

   On-disk KV cache built in. When you start ds4-server, pass --kv-disk-dir and --kv-disk-space-mb. The KV state is persisted to that directory and can be reloaded across sessions. Combined with the SSD inside a Mac, this turns the 1M-token context from a constant tax into a recoverable cost.

4. 04

   OpenAI-compatible server, agent built in. ds4-server exposes /v1/chat/completions, so you can point Cursor, opencode, Claude Code, or any OpenAI-protocol client at it. Tool calling is native, which means a real coding-agent loop without an extra framework.

5. 05

   Auditable by being small. The project is self-contained and does not pull in a third-party runtime. The codebase is small enough that a small team can audit the graph and the quantization choices. For anyone running large models in production, that matters.

Once you accept that ds4 is Flash-only by design, the next section follows naturally. The frequent claim that PRO will fit on a 512 GB Mac Studio needs correcting, and it is worth doing carefully.

Why it has to be a Mac: unified memory, bandwidth, and the on-disk KV cache

ds4 puts Metal first for engineering reasons, not aesthetics. Apple Silicon unified memory (UMA) shares one pool between CPU and GPU. There is no PCIe round-trip moving tensors between VRAM and system RAM. For an MoE model like Flash, where each token activates only a fraction of the experts, UMA lets the engine fetch the needed expert weights from one large pool without being constrained by a discrete-GPU memory ceiling. At consumer prices, no other platform gives you 96 GB at the low end and 512 GB at the top end as your effective inference memory.

The second factor is memory bandwidth. M3 Max sits at roughly 400 GB/s of unified-memory bandwidth, and M3 Ultra roughly doubles it to about 800 GB/s. That is the physical reason ds4 hits about 449 t/s long-prompt prefill on the M3 Ultra Mac Studio. Bandwidth governs how quickly the engine can pull weights, which is the dominant bottleneck for MoE inference. On a Mac, that bandwidth is contiguous, not sharded across discrete GPUs.

The third factor is often missed. Modern Mac internal NVMe SSDs pair well with the ds4 on-disk KV cache. ds4-server writes KV state into the path you pass to --kv-disk-dir and caps the footprint with --kv-disk-space-mb. When you reopen the same session, you skip seconds or minutes of prefill. Apple internal SSDs run at 5–7 GB/s sequential, which makes spill-and-reload cheaper than the alternative of paying RAM for every concurrent session.

Put the three together and the conclusion is direct. In 2026 consumer hardware, nothing fits DeepSeek V4 Flash and ds4 better than a high-memory Mac. The remaining question is whether you can afford a 256 GB or 512 GB Mac, and whether you will actually keep it busy long enough for the math to work out.

A minimum viable launch checklist for ds4 on a VpsMesh cloud-Mac node, plus Cursor integration

The following six steps boil all of the above into a repeatable Runbook. They assume a VpsMesh cloud-Mac node, 128 GB minimum, 256 GB recommended, 512 GB for long-context comfort. Each step ships with a clear pass/fail check so your team can reuse it.

1. 01

   Build ds4 with the Metal backend. git clone https://github.com/antirez/ds4 && cd ds4 && make. You get ./ds4 (CLI) and ./ds4-server (HTTP). Pass: both binaries exist and ./ds4 --help prints help. Do not run make cpu on macOS; the CPU path can kernel-panic.

2. 02

   Smoke-test the Metal backend. Run ./ds4 -p "Hello" --metal to confirm device acquisition and the basic graph path. On a node with 128 GB or more, you can move straight on to loading Flash q2 weights. Pass: no "Metal device not available" error, no OOM.

3. 03

   Pull DeepSeek V4 Flash q2 or q4 weights and verify. Use the GGUF source listed in the ds4 project. Sizes are about 86.7 GB for q2 and about 150 GB for q4. Always check SHA256. Keep weights and KV on separate volumes: weights on a large data disk with at least 500 GB free, KV on the Mac internal SSD. Pass: checksum matches; df -h shows at least 100 GB headroom on the data disk.

4. 04

   Start ds4-server with on-disk KV. Example: ./ds4-server --ctx 200000 --kv-disk-dir /Volumes/ssd-kv/ds4-kv --kv-disk-space-mb 16384 --bind 127.0.0.1:8080. Begin with a 200k window, not 1M, to avoid early memory pressure. Pass: startup log shows Metal ready and KV directory writable; curl http://127.0.0.1:8080/v1/models returns JSON.

5. 05

   Hook up Cursor, opencode, or Claude Code. Point the client base URL at ds4-server through an SSH tunnel that forwards the remote 8080 to local 127.0.0.1:8080. Never expose 8080 on 0.0.0.0. Set the Authorization header to whatever placeholder token your launch flags require. Pick the model name documented by the current ds4 release. Pass: a short streaming request to /v1/chat/completions returns 200 OK.

6. 06

   Set up observability and a rollback rule. Watch memory and disk with vm_stat, memory_pressure, and iostat. Define triggers: if swap stays high, if prefill drops below 50% of baseline, or if the KV directory crosses 80% of --kv-disk-space-mb, fall back to a cloud API (OpenAI, Anthropic, or the official DeepSeek endpoint). Pass: the rollback path produces a comparable result for the same input.

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 .

Three hard data points worth pasting into a team README.

• Throughput baselines. On a 512 GB M3 Ultra Mac Studio, q4 long-prompt prefill is about 449 t/s and generation about 26.6 t/s. On a 128 GB M3 Max MacBook Pro, q2 long-prompt prefill is about 250 t/s and generation about 21.5 t/s. Use these as health anchors per node.
• Memory budget. q2 weights are about 86.7 GB, a 200k-token KV cache adds about 8–14 GB, and the system needs roughly 8 GB. That is about 110 GB to begin with. A 96 GB node is therefore short-context only; 128 GB is the real lab floor, and 256 GB is where KV and concurrent sessions get headroom.
• Disk KV sizing. Start --kv-disk-space-mb at 16 GB. Reserve about 1–3 GB per long-context session. Use the internal SSD; an external drive will make KV reload the new bottleneck.

If you are weighing a 256 or 512 GB Mac Studio against renting a cloud Mac for ds4, weigh two things that rarely make it into spec sheets. First, the hidden bill for a physical machine: power, noise, cooling, repairs after the warranty, and the next two or three Apple Silicon generations arriving inside a three-year horizon. Second, the operational tax of self-hosting: daemonizing ds4-server across reboots, watching the KV disk waterline, and keeping the Cursor or opencode link self-healing. None of that is the work you wanted to do. For independent developers, researchers, and small teams who would rather spend their time running models and writing code than babysitting a server, the VpsMesh high-memory cloud-Mac nodes — switchable across 96 / 128 / 256 / 512 GB on demand — are usually the more realistic and more economical choice. Start with a week of 128 GB to validate Flash q2 fit. Move to a month of 256 GB to make Cursor and a coding agent feel good. Only then decide whether to commit to a 512 GB resident. That ladder is far less risky than dropping the price of a small car on a single top-spec Mac Studio up front.