DeepSeek V4 Flash on a Single DGX Spark

Another day, another experiment. This time I'm trying out DeepSeek V4 Flash on a single DGX Spark.

The older ds4 implementation from Sanfilippo was already usable but slow for agentic work. It peaked at around 15 tok/s with 128k context. The community kept pushing on it though, and forked a recipe that hits ~26 tok/s on a single stream with 1M context. That's the kind of jump that gets my attention.

So I tried it. Here's what I found.

I like this model. It feels like having a frontier model on your desk. Tool calling is sharp, reasoning doesn't spiral into infinite loops (most of the time), and the speed stays reasonable even when you're doing multi-step agent work. But let's get into the details.

Commands, notes, and benchmarks for this experiment live in my DGX Spark Field Notes under models/deepseek-v4-flash.

Recipe

To run DeepSeek V4 Flash on the DGX Spark, I used the MiaAI-Lab recipe: DeepSeek-v4-Flash-One-DGX-Spark (DwarfStar 4 Engine).

This builds on the work from Entrpi/ds4-on-spark, who forked the original from antirez (Salvatore Sanfilippo) and improved token generation a lot.

The recipe defaults to 1M token context. I keep my Spark-side notes, commands, and benchmark artifacts in the deepseek-v4-flash field notes.

To run it:

git clone https://github.com/MiaAI-Lab/DeepSeek-v4-Flash-One-DGX-Spark.git
cd DeepSeek-v4-Flash-One-DGX-Spark
./start.sh

It installs the ds4-serve command and runs a few smoke tests to make sure everything is working.

Memory consumption looks roughly like this:

Don't panic. In my testing it never went OOM and held the full 1M context. Token generation does slow down as the context grows, but it degrades gracefully.

Benchmark

There are plenty of benchmark tools out there. I went with Ivan Fioravanti's: llm_context_benchmarks.

It tests token speed across different context sizes:

uv run openai-benchmark --model deepseek-v4-flash-0731 --base-url http://localhost:8888/v1 --contexts 2,4,8,16,32,64,128,256

I ran it up to 256k context and got this:

deepseek-v4-flash-0731 OpenAI Compat Benchmark Results Hardware: aarch64, 121.6GB RAM, 20 CPU cores

Total generated tokens: 1024

Batch Benchmark

Even at 256k context it stays around 19–20 tok/s, which is usable for agentic work. The ~26 tok/s I mentioned earlier is what you get in the 2k–32k range, where it peaks at 29.4 at 16k. The 1M context is the recipe's default CTX setting, not something I benchmarked throughput at.

The raw charts and notes for these runs are also in the deepseek-v4-flash field notes.

Other recipe to try out

I also tried AtomicChat's DeepSeek-V4-Flash-0731-GGUF (AD-IQ2_M) on the Spark. The quality is better but the speed isn't there yet for my use case:

deepseek-v4-flash-0731 OpenAI Compat Benchmark Results Hardware: aarch64, 121.6GB RAM, 20 CPU cores

Total generated tokens: 1024

Batch Benchmark

Model: AtomicChat/DeepSeek-V4-Flash-0731-GGUF

I trust this team and their work. The quality difference is real, but at 10–15 tok/s it's too slow for what I need right now. Worth keeping an eye on.

How to use it in your preferred harness

As I mentioned in the previous Laguna article, I prefer hosting it via Tailscale on my private network.

I've been using it in my Pi harness and in Hermes.

In Hermes I set up a Kanban board called "Engineering Pipeline" with an orchestrator subagent workflow.

The setup:

• Orchestrator: gpt-5.6-sol, high effort
• Worker: DeepSeek V4 Flash locally on the DGX Spark (one profile, runs multiple tasks in parallel)
• Reviewer: Grok 4.5 with OpenCode Go subscription (first month 5 euros, genuinely convenient)

I've since swapped models on the reviewer profile to experiment, but grok-4.5 via OpenCode Go is where it started.

When I want to work on something complex, I write a detailed prompt for the orchestrator through the Kanban board. It decomposes the work into tasks, fans them out to the workers, and the reviewer gates everything before it ships.

The three profiles:

# Orchestrator: plan, decompose, route
hermes profile create orchestrator --model gpt-5.6-sol

# Worker: local DeepSeek V4 Flash on the DGX Spark
hermes profile create flash-worker --model deepseek-v4-flash

# Reviewer: Grok 4.5 via OpenCode Go
hermes profile create reviewer --model grok-4.5

The three souls

Each profile has a different personality baked into its system prompt. You're not just switching models, you're switching worker archetypes.

The orchestrator is a planner that can't touch code. GPT-5.6-sol at high effort, but with a deliberately restricted toolset. No terminal, no file writes, no web. It reads your prompt, asks clarifying questions if something is ambiguous, sketches a task graph, then fans out cards to the right profiles. There are anti-temptation rules baked in: if it catches itself thinking "I'll just fix this real quick," that's the signal to stop and create a task for the right profile instead. All it does is decompose, route, and summarize.

The flash-worker is the hands-on engineer. DeepSeek V4 Flash on the DGX Spark, fast and cheap, full tool access. It reads the task brief, gets to work, sends progress heartbeats like "scanned 1.2M/2.4M rows," and hands off with structured metadata when done: changed files, test counts, decisions made, benchmark numbers. If it gets stuck it blocks with a one-line question and drops the longer context in a comment. The kanban dispatcher spawns a fresh worker process per card, so multiple tasks can run at the same time.

The reviewer is the skeptic. It doesn't trust the workers' self-reports. Its prompt tells it to be skeptical, precise, and fair. It inspects the actual commands and raw measurements, checks the arithmetic, opens and validates cited sources where possible, flags unsupported claims, and returns PASS, PASS WITH CORRECTIONS, or FAIL. It doesn't rewrite the work. It produces a corrected evidence table that downstream tasks can safely use. It's the grader who reads your code, not the comments.

The loop is simple: the orchestrator plans, the workers execute, the reviewer checks. Nobody steps on each other's work.

Then I switch to the engineering board and create the orchestration task:

hermes kanban boards switch engineering

hermes kanban create "Orchestrate: implement the new API gateway with auth, rate limiting, and OpenAPI docs" --assignee orchestrator

The orchestrator picks it up, writes a plan, and fans out worker and reviewer tasks with the right dependency links. The reviewer task stays in todo until all its parent tasks finish, then auto-promotes to ready. No manual coordination needed.

You can follow the whole chain live:

hermes kanban tail <task_id>

Creating tasks from the Hermes Kanban dashboard

CLI is fine when I'm already in a terminal. Day to day I prefer the Kanban UI.

Hermes runs on my VPS. I keep the dashboard off the public internet and reach it over Tailscale, same pattern as the Spark endpoint in the Laguna article: private MagicDNS hostname on the tailnet, no LAN exposure, open the board from the laptop like a local app.

Open the Kanban view, pick the Engineering Pipeline board, leave Lanes by profile on so you can see which soul owns which cards. Hit + on the column where the work should start — usually Triage for a raw idea, or Todo if the prompt is already written — paste the orchestration brief, assign @orchestrator, and save.

That's how I created the first orchestration card on this board. From there the dispatcher does the rest: workers claim ready cards, blocked cards wait for a human answer, and done cards pile up on the right while I sleep.

Cool use cases

It's been a few days of 24/7 agent work, so I've got a few real examples.

One that finished cleanly: wrap day-to-day DeepSeek V4 Flash 0731 operations on the DGX Spark behind a proper CLI. I got tired of ad-hoc ./start.sh, log diving, and env hunting, so I asked the orchestrator to ship ds4ctl — start, stop, restart, status, logs, env, health, doctor.

I kicked it off from the CLI:

hermes kanban boards switch engineering

hermes kanban create "Build ds4ctl CLI wrapper for DeepSeek V4 Flash 0731" \
  --body "$(cat <<'EOF'
Orchestrate overnight: build a CLI wrapper for DeepSeek V4 Flash 0731 on my DGX Spark.

Goal
Create a small, reliable CLI that wraps day-to-day operations for DeepSeek V4 Flash 0731
(latest release, model id deepseek-v4-flash-0731) served via the MiaAI-Lab / ds4 recipe
on a single DGX Spark.

Working name: `ds4ctl` (or better if you find a clearer name)

Why
Today I start/stop/debug with ad-hoc scripts. I want one command surface for:
- start / stop / restart / status / logs / env / health check

Required task graph
1) Inventory recipe (flash-worker)
2) Design CLI contract (orchestrator)
3) Implement CLI (flash-worker)
4) Test/smoke-check (flash-worker)
5) Docs (flash-worker)
6) Independent review (reviewer)

Deliverables
- Working CLI with start/stop/restart/status/logs/env/health/doctor
- README + config example
- Smoke evidence
- Morning checklist

Anti-scope
- No Laguna support
- No web UI
- Wrap the recipe, don't replace it
EOF
)" \
  --assignee orchestrator

It decomposed the work into six dependent tasks and assigned them across the board:

The red arrow marks the card I created with the CLI command above: Build ds4ctl CLI wrapper for DeepSeek V4 Flash 0731 (t_a8a735e0), assigned to @orchestrator. That parent card moved to Done once the orchestrator finished planning and fanned out the child work. Inventory then went In Progress on @flash-worker, and the remaining design / implement / test / docs / review cards dropped into Todo. I only wrote one prompt. The board did the decomposition.

By the time I checked back, the whole chain had closed. Flash-worker inventoried the MiaAI-Lab / ds4 recipe, the orchestrator fixed the command contract, implementation and smoke checks landed, docs followed, and the reviewer gated acceptance. The dependency graph held: nobody jumped the queue, and nothing closed until review passed.

That's the loop I want from this setup. Not a chat window. A board that can take "make me a CLI for DeepSeek V4 Flash 0731 on the Spark" and turn it into inventory, design, implementation, tests, docs, and review without me babysitting every step.

And this is only one simple use case. You can run endless ones the same way, including with the /goal clause when you want Hermes to drive a longer objective instead of a single card. If you want more Hermes use cases, feel free to ask — I'll dig into them.

Next steps

DeepSeek V4 Flash 0731 is already useful for agent work on the Spark. The next experiments on my list:

• try Ling-3.0-flash-MXFP4 on the same host and see how it compares for speed and agent quality
• try MiniMax-H3 with the improved-speed Spark path
• add vision to the DeepSeek V4 Flash setup, so the local worker can take image context as well as text
• put LiteLLM in front of the OpenAI-compatible endpoints I've been serving, for one unified view across the custom models on the Spark

Same lab notebook as always: notes, commands, and benchmarks go into the DGX Spark Field Notes.