Can DeepSeek V4 Flash 0731 Run on Hardware You Own?

The no-nonsense guide to DGX Spark, M3 Ultra, quantization, 1M context, and the costs hidden behind “it fits.”

Evidence snapshot: July 31, 2026, 18:38 UTC
Disclosure: This is a source and engineering analysis, not a claim that the author personally benchmarked every configuration below.

The verdict

Yes, DeepSeek V4 Flash 0731 can run on hardware an individual or small company can own. The answer changes sharply depending on what “run” means.

• A 512GB M3 Ultra Mac Studio has enough unified memory for the official mixed-precision checkpoint or a high-quality four-bit conversion, with ample working headroom. It is the cleanest single-box answer, if you can find one.
• A 256GB M3 Ultra Mac Studio can hold a roughly 155GB four-bit 0731 conversion and still leave useful headroom. It is viable, but context length and concurrency still need discipline.
• A single 128GB DGX Spark cannot hold the 166.9GB official checkpoint or the current roughly 155GB four-bit GGUFs. It needs a more aggressive two-bit or mixed two/four-bit conversion. That is technically credible, and the preview model has already run this way, but a mature, independently validated 0731 two-bit artifact was not available at this guide’s evidence cutoff.
• Two DGX Sparks have enough aggregate memory for a higher-quality build. They also introduce distributed-inference setup, network synchronization, software-version, and failure-mode complexity that a large-memory Mac avoids.
• A 96GB M3 Ultra, which is the only M3 Ultra memory configuration Apple was reportedly still selling directly by May 2026, is in the same basic class as one Spark for capacity: aggressive quantization or SSD streaming, with little room for a large active context.

DeepSeek V4 Flash 0731 is locally runnable, but “one Spark runs a 284B model” is marketing-grade shorthand. One Spark runs a severely compressed representation of that model. A 256GB or 512GB M3 Ultra is the more convincing single-machine deployment.

Local operation also does not make economic sense for everyone. DeepSeek’s API pricing is so low that buying hardware purely to save token fees requires enormous sustained usage. Local hardware wins for privacy, control, offline availability, experimentation, and predictable capacity. It usually does not win on raw dollars for a light or intermittent workload.

How to read the evidence

This model was released only hours before this evidence snapshot. Mixing current model facts with preview-era benchmarks would produce a confident-looking but misleading guide. Claims are therefore labeled as follows:

• Verified fact: Published in official DeepSeek, NVIDIA, Apple, or checkpoint metadata.
• Engineering inference: Derived from file sizes, memory arithmetic, architecture, or known hardware behavior. It is reasoned, not directly benchmarked here.
• Community result: Publicly reported by a runtime developer or third-party benchmark. Useful, but not an independent lab result.
• Needs testing: Plausible or claimed, but not adequately demonstrated on the final 0731 checkpoint at publication time.

That distinction matters most for speed and output quality. A model file can fit in memory and still fail because the runtime lacks a kernel, expects a different tensor layout, uses the wrong tokenizer, exhausts memory during prefill, or produces degraded answers after aggressive quantization.

What DeepSeek actually released

Verified fact: DeepSeek released DeepSeek-V4-Flash-0731 on July 31, 2026. The company says it has the same architecture and model size as the earlier Flash preview and was updated through post-training rather than a structural change. The official 0731 model repository describes a 284-billion-parameter mixture-of-experts model with 13 billion parameters active per token, a one-million-token context window, mixed FP4/FP8 weights, and an attached speculative-decoding module.

The model card lists an MIT license. That is permissive for the weights, but it does not provide the training data, make the training process reproducible, or override an organization’s procurement, export-control, privacy, or sector-specific obligations.

The 13B active figure is a compute fact, not a storage fact. The router selects only part of the model for each token, but the system still needs access to all routed experts. Unless weights are streamed from storage or divided across machines, the full compressed checkpoint must be resident.

The official weight index reports 166,878,536,440 bytes, or 166.9 decimal GB and 155.4 GiB. That exact figure can be inspected in DeepSeek’s checkpoint index. It is the most useful number for capacity planning.

Hugging Face metadata may display a parameter count around 304B because packed low-precision storage and the attached speculative module are counted differently. That does not mean DeepSeek silently changed the advertised 284B architecture. Capacity planning should use actual bytes. Architecture discussions should use DeepSeek’s stated parameter count, with the metadata discrepancy disclosed.

Verified fact: DeepSeek’s API changelog reports substantial agent and coding benchmark scores, including 82.7 on Terminal-Bench 2.1 and 54.4 on DeepSWE. The same release notes say public code-agent tasks used an unreleased DeepSeek Harness in minimal mode, maximum reasoning effort, temperature 1.0, and top-p 0.95. Two DSBench sets are internal. These are vendor results, not independent validation.

Needs testing: Whether an aggressive Q2 local build preserves those benchmark results, and whether common local runtimes reproduce the API’s tool use, reasoning-effort behavior, or speculative-decoding gains.

Hardware comparison

Memory capacity answers “can the weights be loaded?” Memory bandwidth, kernels, prompt length, and runtime maturity answer “is it pleasant to use?”

Verified facts: NVIDIA specifies 128GB of unified LPDDR5x at 273 GB/s for DGX Spark, with a 140W SoC TDP and a 240W external power supply. NVIDIA describes one Spark as suitable for models up to 200B parameters and two for up to 405B. Those parameter limits are broad product guidance, not proof that every model in the range fits every runtime.

Apple specifies 819 GB/s memory bandwidth for M3 Ultra. Apple’s original March 2025 announcement offered up to 512GB of unified memory. By May 2026, Apple had reportedly removed the 256GB and 512GB options from new orders, leaving 96GB. Existing 256GB and 512GB machines are still ownable, but buyers may be dealing with used, reseller, or remaining inventory rather than normal configure-to-order availability.

Engineering inference: For single-user decode, the M3 Ultra’s roughly three-times-higher published memory bandwidth is a major advantage over one Spark because large-model generation is often bandwidth-bound. CUDA compatibility can make Spark easier for some server software, but CUDA does not erase the bandwidth difference.

The memory math, without the hand-waving

A first-pass estimate is:

weight bytes ≈ parameter count × bits per stored weight ÷ 8
required memory ≈ weights + quantization metadata + KV cache
                  + activations/graph workspace + runtime/OS
                  + speculative model + concurrency headroom

For 284B parameters, naive uniform storage would be:

The official file is 166.9GB because it is not a uniform four-bit dump. Some tensors remain at higher precision, and packed formats carry scales, metadata, and auxiliary weights.

Current community 0731 conversions provide a useful reality check. At the cutoff for this article, Bartowski’s 0731 MXFP4 GGUF totals about 156.4GB, while Unsloth’s UD-Q4_K_XL 0731 GGUF totals about 155.1GB. Runtime support and quality still need validation; their existence proves file availability, not production readiness.

For the earlier Flash preview, the DwarfStar project provides three instructive model sizes in its quantization repository:

Community result, not a 0731 artifact: Those preview sizes establish that a carefully designed Q2 representation can fit one Spark. They do not establish that a current 0731 Q2 file has been converted correctly, supported by the runtime, or scored for quality.

At the evidence cutoff, a 0731 Q2/Q4 repository advertised a planned 97.6GB file but did not yet contain the model shards. It is therefore excluded from the “currently runnable artifact” evidence. That repository may change after publication; inspect its file tree and revision rather than relying on this sentence.

There is another easy trap here: 128GB is 128 billion bytes, only about 119.2 GiB. The official checkpoint alone is 155.4 GiB. No memory-management trick makes that gap disappear. Unified memory avoids copying weights between CPU and GPU pools; it does not create capacity.

The active 13B parameter count also does not imply 26GB of FP16 memory. It reduces work per token. The routed experts that might be selected on later tokens must still exist somewhere.

How much headroom is enough?

There is no universal number. Context length, batch size, KV-cache precision, runtime graph allocation, and speculative decoding all move it. A sensible deployment does not run with only a few hundred megabytes free after loading weights.

Engineering starting points:

• On a 256GB Mac, treat a 155GB Q4 file as comfortable for a single session at moderate context, not permission to jump directly to one million tokens.
• On a 128GB Spark with an 87–98GB Q2-class file, preserve tens of gigabytes for the system and runtime, then start at 32K context.
• On a 96GB Mac with an 86.7GB preview-style Q2 file, resident execution is tight. SSD expert streaming or a smaller context may be necessary.
• On a 512GB Mac, capacity is not the main problem. Runtime correctness, prefill time, and useful generation speed are.

Quantization: what you gain and what you risk

Quantization is not a cosmetic file-compression setting. It changes the numbers used during inference.

Official mixed FP4/FP8

This is the highest-confidence representation because it comes from DeepSeek. It is also too large for one Spark or a 96GB Mac. A runtime must understand its packed format and model-specific kernels; having 167GB of free memory does not guarantee that a Metal application can load the original safetensors directly.

Best for: two-node or large-memory deployments where supported kernels exist and preserving vendor intent matters more than convenience.

Q4 or MXFP4 GGUF

The current 0731 files around 155GB are the practical quality-first local format. They fit easily in 256GB or 512GB unified memory and fit across two Sparks.

Tradeoff: Smaller than naive FP4 plus overhead might suggest, but still far beyond one 128GB Spark. “Four bit” also does not identify one universal quantization recipe. Compare tensor-by-tensor precision, calibration, tokenizer files, runtime support, and evaluation scores.

Q2 and mixed Q2/Q4

This is the one-Spark answer. DwarfStar’s preview recipe leaves non-routed and control-critical tensors at higher precision while heavily compressing the routed experts. That is more defensible than blindly quantizing every tensor to two bits.

Tradeoff: The capacity win is real. So is quality risk. Coding reliability, long reasoning traces, rare-domain knowledge, routing behavior, and tool-call syntax can degrade before casual chat makes the damage obvious.

Needs testing: A 0731 Q2 build should not be called production-ready until it passes side-by-side tests against the official API or higher-precision local model. The test set must include agent loops, structured output, long-context retrieval, code patches, and tasks where a subtly wrong answer is worse than a refusal.

SSD streaming

DwarfStar can keep non-routed weights resident and load routed experts from SSD on demand on Metal. Its documentation correctly presents this as a capacity mode, not equivalent performance. It still needs memory for dense weights, active experts, KV cache, graph workspace, and activations.

Tradeoff: SSD streaming can turn “does not fit” into “runs.” Decode is sensitive to cache misses because each new token routes through experts again. It also increases storage wear, latency variance, and operational complexity. Use it for occasional work or evaluation before treating it as a server design.

Speculative decoding and DSpark

DeepSeek’s DSpark auxiliary model proposes future tokens for the main model to verify. The DSpark model card says the same V4 Flash checkpoint is used with a speculative module attached.

The feature adds memory and another correctness-sensitive path. DwarfStar currently describes its own implementation as experimental and reports, at most, a slight speedup. Start without speculation. Add it only after baseline outputs and memory use are stable.

Deployment path 1: M3 Ultra Mac Studio

The M3 Ultra is the stronger single-machine platform for this model because its large unified-memory options combine capacity with 819 GB/s bandwidth. The catch is availability: the configurations that make this compelling may have to be bought used.

Recommended configurations

• 512GB: Use the official representation if a compatible Metal runtime supports it, or a verified 0731 Q4/MXFP4 GGUF. This is the least constrained local setup.
• 256GB: Use a verified 0731 Q4/MXFP4 GGUF. Begin at 32K context, then test 64K, 128K, and higher while recording peak memory and time to first token.
• 96GB: Wait for or build a validated 0731 Q2/mixed quant. SSD streaming is possible, but should be viewed as a compromise.

A safe bring-up sequence

1. Record the exact model repository, revision, file hashes, and total bytes.
2. Pin the runtime commit instead of following its moving main branch in production.
3. Confirm that the runtime explicitly supports the 0731 tensor layout and DeepSeek’s dedicated encoding files. The official model does not ship a conventional Jinja chat template.
4. Load the model without speculative decoding, at 32K context and one session.
5. Run deterministic smoke tests at temperature 0: plain completion, reasoning on/off, JSON, tool calls, code edits, and multilingual text.
6. Compare those outputs with the official API or a higher-precision reference.
7. Increase context only after measuring resident memory, prefill time, and decode speed.

DwarfStar currently documents this basic build shape for its supported GGUFs:

git clone https://github.com/antirez/ds4.git
cd ds4
make
./ds4 --help
./ds4-server --help

For a model larger than comfortable resident memory, its documented Metal pattern is:

./ds4 \
  -m /path/to/a-verified-supported-model.gguf \
  --ssd-streaming \
  --ctx 32768 \
  --nothink

These commands are a runtime skeleton, not proof that an arbitrary 0731 GGUF is supported. DwarfStar says it is not a general GGUF loader. Do not substitute a file because its name looks compatible and then trust the output.

Expected performance

Community result on the preview model: DwarfStar reports M3 Ultra 512GB generation of 36.86 tokens/s with its Q2 build and 35.50 tokens/s with Q4 on a short prompt. At roughly 12K prompt tokens, it reports 27.39 and 26.62 tokens/s respectively. The project warns that some numbers may be stale and describes them as single-run results at 32K configured context.

An independent public oMLX preview benchmark reports 29.2 tokens/s generation at a 1K prompt, falling to 23.4 at 64K, with peak memory rising from 142.1GB to 176.7GB.

Needs testing on 0731: Equivalent speed, memory, output quality, and stability with the current checkpoint and current runtimes.

Deployment path 2: DGX Spark

DGX Spark is attractive because it is compact, uses the CUDA ecosystem, has 128GB of coherent memory, and can be paired over ConnectX-7. Its weakness for this particular model is straightforward: 128GB is less than the current high-quality weight files, and 273 GB/s is modest for decoding a model this large.

One Spark

Use a validated Q2 or mixed Q2/Q4 0731 artifact. Do not download a Q4 file and hope unified memory or Linux swap will rescue it. Start with:

• 32K context;
• one active session;
• speculative decoding off;
• no unnecessary desktop or service load;
• loopback-only serving until authentication is configured;
• recorded free-memory and UMA behavior before and after load.

DwarfStar’s documented Spark build target is:

git clone https://github.com/antirez/ds4.git
cd ds4
make cuda-spark
./ds4 --help
./ds4-server --help

Again, the mature download recipes in that project referred to the preview checkpoint at this article’s cutoff. A real 0731 deployment requires a supported 0731 GGUF plus output validation.

Community result on the preview model: DwarfStar reports 343.81 tokens/s prefill and 13.75 tokens/s generation on one Spark with Q2 at a 7,047-token prompt. This is plausible given the bandwidth difference from M3 Ultra, but it is one project’s result, not a 0731 guarantee.

NVIDIA’s current DGX OS 7.5 release notes list CUDA 13.0.2 and improved out-of-memory handling. Treat the OS, driver, compiler, and runtime as one pinned compatibility set. Newer is not automatically safer on release day.

NVIDIA also documents unexpected memory reporting caused by unified-memory reclaim behavior. Capacity tests should measure whether the model actually allocates and runs, not rely on one free or dashboard reading.

Two Sparks

NVIDIA documents connecting two Sparks over their 200Gb/s interfaces. In raw capacity terms, 256GB aggregate memory is enough for a roughly 155–167GB model plus working state.

This setup still needs a runtime that can partition the model correctly. Layers, experts, attention state, and output heads do not all have the same communication pattern. Some weights may be replicated. Every synchronization point can reduce decode throughput.

Engineering inference: Two Sparks are most compelling when CUDA compatibility, Linux administration, or a later multi-user serving path matters more than appliance simplicity. If the sole objective is one person’s fastest local interactive model, a 256GB or 512GB M3 Ultra is easier to justify.

Needs testing: Current 0731 throughput at 32K, 128K, and 1M context; whether native mixed-precision or Q4 offers better end-to-end latency; partitioning efficiency; failure recovery; and performance under two simultaneous sessions.

The one-million-token context claim

Verified fact: DeepSeek advertises a one-million-token context window for V4 Flash, and its current API pricing page lists a 1M context length and maximum output of 384K.

That is a model and API limit, not a promise that one million tokens are practical on every local machine.

Long context raises four separate costs:

1. KV-cache memory: Even with DeepSeek’s compressed attention design, active context consumes memory that cannot be assigned to weights or additional sessions.
2. Prefill time: The system must ingest the prompt before useful generation begins. High prefill throughput can still mean a long wait when the prompt contains one million tokens.
3. Attention and runtime workspace: Kernel implementations and chunking strategy affect whether peak allocations fit.
4. Quality: A model accepting a long sequence does not prove reliable recall, ordering, citation, or instruction adherence across the entire sequence.

DeepSeek’s V4 technical report says V4-Pro uses 10% of V3.2’s KV-cache size at one million context and 27% of its single-token inference FLOPs. Those exact numbers are stated for V4-Pro. They should not be silently copied onto Flash without a Flash-specific measurement.

Also budget input and output together. Do not assume “1M context” means one million input tokens plus another 384K output tokens in every runtime.

Engineering deployment policy:

• Qualify the model at 32K first.
• Test 64K and 128K with actual workload documents, not repeated filler text.
• Measure 256K only after memory and prefill behavior are understood.
• Treat 1M as a dedicated benchmark and research mode until the complete workload is measured.

A one-million-token demo that takes minutes to prefill, leaves no room for a second request, and retrieves the wrong passage is not a production success.

Cost and total cost of ownership

DeepSeek has made the buy-versus-rent comparison unusually harsh for local hardware.

Verified fact: The current DeepSeek API price for V4 Flash 0731 is $0.14 per million uncached input tokens, $0.0028 per million cached input tokens, and $0.28 per million output tokens. DeepSeek says future peak-period pricing will be double during two Beijing-time windows, with the effective date still to be announced.

NVIDIA raised DGX Spark pricing in 2026; the Founder’s Edition was reported at US$4,699. Local and reseller prices vary.

Simple break-even examples

At $0.28 per million output tokens, a $4,699 Spark equals about 16.8 billion API output tokens before counting input, electricity, storage, administration, downtime, or the fact that the local Q2 model may not match API quality.

For a hypothetical job containing 100K uncached input tokens and 10K output tokens:

API cost = 0.1 × $0.14 + 0.01 × $0.28
         = $0.0168 per job

At that mix, $4,699 buys roughly 280,000 jobs at base API pricing. Prompt caching makes the API cheaper still. Peak pricing would reduce that count, but would not turn light use into an obvious hardware win.

Another useful scenario is 1B uncached input tokens plus 100M output tokens per month:

input:  1,000 × $0.14 = $140
output:   100 × $0.28 =  $28
total:                  $168/month

Ignoring every other cost, a $4,699 machine takes about 28 months to equal that API spend. A hypothetical $10,000 large-memory Mac takes about 60 months. These are arithmetic scenarios, not price quotes or promises of equivalent quality and throughput.

Power is not the main cost, but measure it

Do not substitute PSU rating or SoC TDP for wall power. Measure the complete system under your actual prompt/decode duty cycle.

For illustration, a machine averaging 200W for eight hours a day uses:

0.2 kW × 8 hours × 365 = 584 kWh/year

At $0.15/kWh, that is about $88 per year. The larger costs are purchase price, operator time, spare capacity, and the chance that the software stack or desired model changes before the hardware pays back.

When local still wins

Local deployment can be rational when one or more of these are worth more than the token bill:

• data must not be sent to an external model provider;
• internet access is unreliable or prohibited;
• model behavior, system prompts, logging, and retention must be controlled;
• sustained heavy use would hit rate limits or create unpredictable queueing;
• the machine also serves development, media, simulation, or other workloads;
• the organization values an owned research platform rather than a narrow API replacement.

The honest TCO worksheet should include hardware, tax, storage, electricity, cooling, administrator hours, failed experiments, replacement value, uptime, and the cost of lower-quality outputs. “Tokens are free once I own the box” is bad accounting.

Security and privacy risks

Local inference removes one data recipient. It does not make the system private by default.

Model and artifact supply chain

• Download official files from the named DeepSeek repository and pin the commit. The official 0731 repository revision at this snapshot was 9e165c30e2704aec5d9d593cce3eebd58bbef1cb.
• Record hashes for every shard, tokenizer/encoding file, conversion tool, and GGUF.
• Treat third-party quantizations as executable dependencies in practical risk terms, even when the container format itself is data.
• Do not infer trust from download count or a familiar uploader name. Reproducible conversion plus evaluation is stronger evidence.

Runtime and agent risk

• Bind the server to localhost by default. Add authentication and TLS before remote access.
• Do not expose a model agent directly to a shell, cloud credentials, browser profile, password manager, Docker socket, or production filesystem.
• Run tools in a separate low-privilege sandbox with an allowlist and explicit time, network, and directory limits.
• Treat model-generated commands, SQL, code, and tool arguments as untrusted input.
• Block outbound network access unless a task needs it, then log destinations and payload policy.
• Pin Python, compiler, CUDA, Metal, and runtime dependencies. A one-line installer from a moving branch is not a production build process.

Data residue

Prompts can survive in server logs, traces, shell history, crash dumps, swap, on-disk KV caches, and monitoring platforms. DwarfStar’s documentation explicitly warns that KV-cache files include verbatim prompt content. Use full-disk encryption, define retention, restrict file permissions, and test deletion. Never place sensitive prompts in a benchmark artifact that will be published.

For regulated or high-impact use, an open-weight license and local execution do not replace a privacy impact assessment, software bill of materials, incident plan, access controls, or legal review.

Troubleshooting: failure modes that matter

The model will not load

Likely causes: The weights do not fit; decimal GB was confused with GiB; runtime workspace was omitted; the GGUF layout is unsupported; a model shard is missing; or the runtime is loading both main and speculative models.

What to do: Verify total bytes and hashes. Disable speculation. Reduce context and sessions. Choose the smaller validated quant. Read the runtime’s tensor-layout support list. Do not use swap as a performance solution.

The machine reports confusing free memory

Unified-memory systems can reclaim and account for memory differently from discrete-GPU systems. On Spark, use NVIDIA’s UMA guidance and test a real allocation. On macOS, close memory-heavy applications and observe pressure during model load and long prefill, not only idle “free” memory.

Time to first token is terrible

That is usually a prefill problem, not decode speed. Record prompt tokens, prefill tokens/s, cache-hit state, and chunk size. Test a short prompt and a fixed long prompt separately. Prefix caching helps repeated prefixes; it does not make a new one-million-token document free.

Decode is much slower than advertised

Confirm the same quant, runtime commit, context length, reasoning mode, sampling settings, and prompt length as the comparison. Check whether expert weights are coming from SSD. Warm up the runtime. Measure one session before testing concurrency. On distributed systems, record network link state and partitioning.

Output is gibberish or tool calls are malformed

Suspect tokenizer and prompt encoding before blaming quantization. The official repository uses dedicated encoding assets rather than a normal Jinja chat template. Verify the runtime’s 0731 support, then test temperature 0 with a tiny prompt. Compare token IDs and rendered prompt text against a known-good implementation.

The model says it is the preview or gives the wrong version

Do not ask a language model to identify its own checkpoint. Verify repository revision, file hashes, index metadata, and runtime logs.

Spark compilation fails

Record DGX OS, driver, CUDA toolkit, compiler, and git commit. Use the runtime’s Spark-specific build target. Do not combine instructions written for x86 CUDA, an older CUDA release, and the current ARM64 Spark environment without checking each dependency.

One million context crashes late in prefill

Peak memory was underestimated or the runtime’s long-context kernels are not stable at that allocation. Reproduce at 32K, then double context until the failure boundary is known. Save memory and throughput at each point. A startup message accepting --ctx 1000000 is not proof that a one-million-token request will finish.

A reproducible benchmark methodology

“It runs at 30 tokens per second” is nearly useless without the model, prompt, phase, and settings. A credible local review should publish enough detail for another owner to reproduce it.

1. Freeze the system

Record:

• hardware SKU, memory capacity, storage, and node count;
• OS, kernel, firmware, driver, CUDA or macOS version;
• runtime repository and exact commit;
• compiler and build flags;
• model repository, revision, filenames, hashes, quant recipe, and total bytes;
• speculative decoding on/off and auxiliary-model hash;
• power mode, cooling conditions, and major background processes.

2. Separate the performance phases

Report at least:

• model load time;
• time to first token;
• prefill throughput in prompt tokens/s;
• decode throughput in generated tokens/s;
• end-to-end wall time;
• peak resident/unified memory;
• energy at the wall where possible;
• SSD bytes read and cache-hit rate when streaming;
• per-user and aggregate throughput for concurrent serving.

Never combine prefill and decode into one flattering throughput number.

3. Use fixed prompt-length tiers

Run the same content at approximately:

• 1K tokens;
• 8K tokens;
• 32K tokens;
• 128K tokens;
• 256K tokens;
• 1M tokens, only if prior tiers pass.

Use real, licensable text with answerable questions distributed near the beginning, middle, and end. Publish token counts from the model’s own encoding, not a generic tokenizer estimate.

4. Control generation

For speed measurements, use deterministic decoding where supported:

temperature: 0
fixed output target: 256 or 512 tokens
reasoning: explicitly on or off
tools: off for raw speed tests
sessions: 1, then a documented concurrency series
warm-ups: at least 2
measured runs: at least 5

Report median, minimum, maximum, and standard deviation. Do not keep only the best run.

For agent-quality evaluation, use DeepSeek’s recommended agent sampling as a separate suite: temperature 1.0 and top-p 0.95. Performance and quality experiments should not be mixed.

5. Test quality across precision levels

Compare official API or the highest-precision available reference against local Q4 and Q2 using the same prompts. Score:

• exact-answer and retrieval accuracy;
• JSON/schema validity;
• tool-call name and argument validity;
• code compilation and tests passed;
• patch correctness, not merely plausible prose;
• long-context citation to supplied evidence;
• refusal and prompt-injection behavior;
• repetition, truncation, and reasoning-mode control.

Use at least 100 tasks for a preliminary quant comparison and publish failures, not only averages. Blind the evaluator to quantization where practical.

6. Test context honestly

A 1M-context run should publish:

• exact input and output token counts;
• KV-cache precision and measured peak memory;
• chunk size and prefill time;
• retrieval accuracy by document position;
• decode rate at the end of the full context;
• whether prefix caching was warm or cold;
• whether any part of the prompt or weights was streamed from SSD;
• whether the run completed more than once.

One successful generation of a sentence after a million-token prefill proves capacity. It does not prove useful long-context performance.

7. Use a result table that exposes caveats

Publish the raw JSON or CSV alongside the article. Readers should be able to recompute the summary rather than trust a screenshot.

What is known, inferred, reported, and still open

Verified

• V4 Flash 0731 is a 284B-total, 13B-active MoE with a stated 1M context.
• The official checkpoint is 166.9GB and uses mixed low precision.
• Current 0731 Q4/MXFP4 community files are roughly 155–156GB.
• One Spark has 128GB at 273 GB/s; two can be linked.
• M3 Ultra provides 819 GB/s and was manufactured in 256GB/512GB configurations.
• DeepSeek’s API is priced at $0.14 per million uncached input tokens and $0.28 per million output tokens at base pricing.

Engineering inferences

• One Spark requires Q2-class compression; the official and Q4 files do not fit.
• A 256GB M3 Ultra is the sensible minimum for a quality-first single-box Q4 deployment.
• A 512GB M3 Ultra is the least constrained owned workstation path.
• Higher bandwidth should make M3 Ultra faster than one Spark in bandwidth-bound decode, all else equal.
• The API is cheaper than buying hardware for most light and moderate workloads.

Community results

• Preview Q2 and Q4 builds have run at roughly 27–37 generated tokens/s on a 512GB M3 Ultra, depending on prompt length and runtime.
• A preview Q2 build has run at 13.75 generated tokens/s on one DGX Spark in DwarfStar’s published test.
• Third-party M3 Ultra preview testing shows decode slowing and memory increasing as context grows to 64K.

Still requires testing

• Reproducible 0731 speed on one Spark, two Sparks, and 256GB/512GB M3 Ultra.
• Quality loss for a final 0731 Q2 or mixed Q2/Q4 conversion.
• Stable 1M-context memory, prefill, decode, and retrieval quality on owned hardware.
• Real speculative-decoding speedup and memory cost.
• Multi-session throughput, long-running stability, and recovery after failure.
• Local parity with API tool use and agent benchmarks.

Final recommendation

Buy or use a 256GB or 512GB M3 Ultra if you want the simplest high-quality, single-box local DeepSeek V4 Flash experience and are comfortable with the Metal/GGUF ecosystem. The 512GB version is the safer research machine; 256GB is enough for the current four-bit file sizes with sensible context limits.

Use one DGX Spark only if you accept Q2-class quantization, slower likely decode, and release-day runtime work. Treat it as an experimental local appliance rather than a full-fidelity 284B server.

Use two Sparks when CUDA/Linux alignment or distributed experimentation is the point. Do not buy two merely because a headline says “405B.” Compare their combined cost and complexity with a large-memory Mac and with the API.

If privacy or offline control is not a hard requirement, start with the API. Measure a month of real token usage and latency. Buy hardware when that measurement, a security requirement, or a broader research need justifies it.

Primary and technical sources

• DeepSeek API changelog and V4 Flash 0731 release notes
• DeepSeek V4 Flash 0731 official model repository
• DeepSeek V4 Flash DSpark model card
• DeepSeek API model limits and pricing
• DeepSeek V4 technical report
• NVIDIA DGX Spark hardware specifications
• NVIDIA DGX Spark release notes
• NVIDIA two-Spark clustering guide
• Apple M3 Ultra Mac Studio technical specifications
• Apple’s original M3 Ultra Mac Studio announcement
• DwarfStar/ds4 runtime and benchmark documentation
• KTransformers DeepSeek V4 Flash deployment guide
• oMLX M3 Ultra preview benchmark