Run DeepSeek V4 Flash on a DGX Spark pair

Two NVIDIA DGX Sparks connected by their QSFP cable can serve DeepSeek V4 Flash Vision Exp, the 305-billion-parameter reasoning and vision model, at its full 1,048,576-token context with six requests in flight at once. Sogni runs three such pairs in production; this page is the same deployment packaged for anyone who owns a pair.

The pair is one Sogni worker. The first Spark (the head) exposes the model and runs the Sogni sidecar; the second Spark (the worker rank) holds the other half of the model over the cable. Never register the second Spark as a separate worker.

#Requirements

• Two NVIDIA DGX Sparks running DGX OS (Ubuntu 24.04, ARM64), connected directly by the QSFP cable. Both Sparks must be able to reach each other over that link with private addresses you assign, for example 192.168.100.10 and 192.168.100.11.
• Docker Engine with Compose v2 and the NVIDIA Container Toolkit on both machines, with your user in the docker group on both.
• About 200 GB free on each Spark for the 157 GB checkpoint and caches, or only on the head if you choose the NFS option in the settings file.
• The same username on both Sparks and key-based SSH from the head to the worker rank that works without a prompt.
• earlyoom disabled on both machines. It cannot tell a healthy 110 GB model server from a memory leak and will kill it under load.
• Internet access on the head for the one-time checkpoint download from Hugging Face. No Hugging Face account is needed; the model is published under the MIT license.
• One Sogni account with its API key and one Fast Worker NFT token ID for the pair.

The pair serves only DeepSeek V4 Flash Vision Exp. It does not serve the general LLM Worker catalog, and the regular Fast Worker installer refuses the LLM Worker choice on a DGX Spark for that reason.

#Install

Everything runs on the head Spark as your normal user. The installer, settings template and acceptance tests ship inside the sidecar image, so the first step is to extract them.

1. Extract the pair kit:

   mkdir -p ~/sogni-dspark && docker run --rm --entrypoint tar \
     sogni/sogni-llm-worker:deepseek-v4-flash-dspark-external-worker-1.0.19 \
     -C /opt/llm/dspark-kit -cf - . | tar -xf - -C ~/sogni-dspark --one-top-level=kit
   

2. Create your settings file and fill in every value. It holds your API key, so keep it private:

   cp ~/sogni-dspark/kit/pair.env.example ~/sogni-dspark/pair.env
   chmod 600 ~/sogni-dspark/pair.env
   nano ~/sogni-dspark/pair.env
   

   The file asks for the SSH target of the worker rank, the two cable addresses and port names, the cache path, and your Sogni credentials. Comments in the file explain how to find each value.

3. Check both machines before anything is changed:

   ~/sogni-dspark/kit/install-pair.sh preflight
   

   Fix every line marked FAIL and run it again until it reports preflight passed.

4. Install:

   ~/sogni-dspark/kit/install-pair.sh all
   

   This checks out the pinned serving recipe on both Sparks, pulls the pinned runtime image, downloads and verifies the checkpoint, and installs a background service that starts the pair and the Sogni sidecar. The download is 157 GB per Spark and takes as long as your connection allows. The first start compiles GPU kernels and takes 15 to 30 minutes; later starts take a few minutes.

5. Open dashboard.sogni.ai/fast-workers and confirm the NFT is online. The worker appears as one GB10 LLM worker.

To run each step yourself instead of all, use fetch, pull, weights, start, canary, sidecar and enable in that order. canary runs the same acceptance tests Sogni's own pairs passed before going live: a plain reply, a streamed reply, a tool call, an image, and six requests at once.

#Operate

The service restarts the pair after a crash and after a reboot of either Spark. While the model is loading, the Sogni sidecar stays offline so the worker never advertises capacity it cannot serve.

#What the pair serves and earns

The worker serves deepseek-v4-flash-vision-exp-dspark-1m: text chat, reasoning, tool calling, structured output and image input, with a 1,048,576-token context and up to six requests at once. Requests come from Unlimited subscribers, Premium Spark and SOGNI-paid users; Free Spark is not accepted for this model. Token-paid jobs credit as they complete, and subscription jobs count toward subscription earnings once your account has opted in from the Workers dashboard.

The model is priced per token, so what a pair earns follows how busy the network is. At the current price and the request mix Sogni observed on its own pairs, a fully busy pair processes on the order of 600 requests an hour.

#Exact versions

Every pair on the network runs exactly the same checkpoint, runtime and serving settings, and the Sogni sidecar refuses to start if the backend it finds differs. The kit pins them for you; do not edit the rendered recipe settings by hand.

There is no floating latest tag for this image. When Sogni publishes a new pair version it is announced in the LLM Worker release notes; upgrade by extracting the new kit and running install-pair.sh all again. A version change may also change the model contract, in which case the previous version stops being accepted.

#Troubleshooting

• preflight reports the RoCE device or interface is missing. Look at ls /sys/class/infiniband and ip -br addr on that Spark and put the port that carries the cable address into the settings file. The two QSFP ports are enp1s0f0np0 / rocep1s0f0 and enp1s0f1np1 / rocep1s0f1.
• The backend never becomes healthy. Read ~/sogni-dspark/logs/startup.log. A line reading boot shape warmup incomplete means the pair started but did not pass its own warm-up; the sidecar is deliberately kept offline. Stop, make sure nothing else is using memory on either Spark, and start again.
• The sidecar says the backend does not match. The rendered recipe settings were changed, or a different image or checkpoint is being served. Run install-pair.sh fetch to re-render the settings and install-pair.sh pull to restore the pinned image.
• The pair goes offline after a reboot. Confirm loginctl show-user $USER -p Linger reports yes on the head. Without lingering, user services only run while you are logged in.
• Something else needs a Spark. Stop the pair first. It cannot share either machine.