Published 2026-11-05

This article reports a one-week evaluation of the NVIDIA DGX Spark, a compact system with 128 GB of RAM. The unit was provided for testing by a subscriber. The evaluation covered running DeepSeek and Qwen models locally, three agent-driven development tasks, and a cost comparison with alternative hardware.

Hardware and Models

• System: NVIDIA DGX Spark, 128 GB RAM. Reviews describe the unit as quiet and comparable in size to a mini-PC. The author reports that it does not heat the surrounding area noticeably.
• Models tested: DeepSeek 4 Flash, DeepSeek 4.1 Flash, DeepSeek 1017, and Qwen 3.8 Flash Next.
• Quantization: The DeepSeek and Qwen runs used 2-bit quantized models. The author noted that a 2-bit quant typically reduces output quality compared with higher-precision quants.
• Memory and storage: The models ran across RAM and an SSD. The Qwen model is a mixture-of-experts (MoE) model. The author stated that it fits into RAM and deploys across RAM and disk.
• Context: The DeepSeek model was loaded with a one-million-token context window. The Qwen model was set to 260,000 tokens.

Performance Observations

DeepSeek

• Prefill speed: 600–700 tokens per second.
• First request ("Hi"): The model spent about seven minutes reading the context before responding.
• Generation speed: Slow enough that individual characters could be seen appearing. During tool creation, generation fell to about six tokens per second. The author stated that 25 tokens per second is the minimum acceptable speed for work.
• Context use: The model used 260,000 context tokens during the agent tasks.
• Storage streaming: The author initially expected about 0.5 tokens per second from SSD streaming. The measured rate was 10 tokens per second at the start, 8–9 tokens per second later in the session, and about six tokens per second at one point. The author attributed the higher-than-expected rate to the SSD not being connected through the standard PCI path and to part of the model being offloaded to RAM.

Qwen 3.8 Flash Next

• Prefill speed: 600–700 tokens per second.
• Prompt processing: Estimated at about 200 seconds, roughly 100 seconds faster than the DeepSeek run.
• Generation speed: About 20 tokens per second. The author described this as the lower limit of usable speed.
• Reference point: The author reported 90–100 tokens per second for the Q8 quant of Flash Next on a single RTX 3090.

Task 1: Preserving the Message Queue After Stop

Background

The author's custom agent harness, which replaced the PSDK-based agent loop, had a defect. When a user pressed "stop" during a running task, all queued messages were deleted. In one case, a long message was lost this way.

Requirements

The author asked the model to change the behavior so that queued messages remain after stop. Users could then send or edit them. The author also specified that the model must not test in the browser and must verify changes with unit tests only.

Procedure

1. The author submitted a task to write 20 paragraphs, then added further messages to the queue.
2. The author pressed stop and confirmed that the queue remained.
3. The model completed the implementation in about 2 hours 58 minutes.

Result

• The queue persisted after stop.
• The queue editor worked.
• The model did not launch a browser for testing.
• Changes were made to the frontend, backend, and documentation.
• The author had not yet committed the changes at the time of the report.

The author's first estimate for the same work on a full DeepSeek model, hosted by the author's provider on high-performance hardware, was about three minutes.

Task 2: Sequential Output Test

The author ran a second test to check instruction-following and response handling:

1. Write the word "three" 10 times.
2. Correct the instruction to "three."
3. Write "one," then the numerals 1, 2, 3, and 4, then stop.
4. Write "five" and observe the response.

The model produced "333" in place of the requested sequence and responded to the subsequent "four" and "five" prompts. The task took about 2 hours 55 minutes to 2 hours 58 minutes. The author described the model as slow but able to complete small tasks.

The author stated that the total raw footage for this test was eight minutes, and that the model's output required a large amount of waiting time.

Task 3: HTML Report Tool

Specification

The author specified a built-in tool for creating and editing HTML reports within a chat. The tool would have these features:

• Each report is assigned a UID.
• The tool can be enabled or disabled.
• When a user explicitly requests a visual report, the agent generates it, launches it, and makes it available for opening on the user's computer.

The author stated that visual reports are useful when an agent needs to present information visually and when the user works from a phone, where a formatted page is easier to read than text.

Task Design

• The design phase used two scenarios: an agent scenario and a developer scenario.
• The model outlined questions for the author in 19 minutes after searching the entire project.
• The model needed to create a task in Taskwad, an internal task management system. Taskwad connects to agents through a Model Context Protocol (MCP) server. The author stated that Taskwad is scheduled for public release in the near future.
• The author answered the model's questions. The author was uncertain about the fourth question, which concerned how separate ports would affect access to tokens.

Implementation

• The implementation phase took an estimated 3 hours 5 minutes, according to the timer. The author had initially expected 8 hours.
• The test report was launched on a different port.
• The model retrieved a token when localhost was enabled. The author stated that the token was an old one.
• Local storage was tied to the port.
• The author asked for the test report to be renamed from "test results" to "results."
• The author reported that the model committed the changes, added tests, and updated the documentation. The author stated that the task was completed in 20 minutes.

Planned Use

The author stated that the harness is intended to run in the cloud, so that clients could access it through a cloud layer. In that setup, reports could be created and shared through a link.

Cost Comparison

The author stated that a turnkey build costs more than a self-assembled system because of terms and warranties.

The author also noted that a large custom rig with water cooling can draw up to 15 kW, and that such a system requires electrical supply and heat dissipation planning.

Assessment

Limitations

• The DGX Spark runs models more slowly than GPU-based configurations with the same model family. The author estimated that Flash Next on a 3090 or 2080 setup would complete the same preparation work in about 15 minutes and the implementation in about 40 minutes. On the DGX Spark, the same work took about one hour for preparation and three hours for implementation.
• The author cannot run DeepSeek on the author's own GPUs, even at 2-bit quantization.
• The author stated that the 2-bit quantized models produced lower-quality output than 4-bit quantized models.

Advantages

• Model efficiency is improving. Newer models require less memory and less power for the same results. The author estimated that a year earlier, running a model at the level of Flash Next required hardware comparable to that needed for GLM 4.7. For a client, the author had estimated 25–30 million rubles of hardware for that model in a usable format. The author stated that the same capability now runs on two graphics cards, RAM, and an SSD.
• The DGX Spark can run large context windows. The author loaded a one-million-token context on DeepSeek and verified it. In a needle-in-a-haystack test, the model loaded about 800,000 tokens in about 50 minutes and solved the task.
• The system suits asynchronous workloads. Non-urgent tasks can run in the background, and a prepared task can be executed in one pass. The author stated that the workflow is already supported by a harness and skill set.
• The author states that the device is quiet and does not heat the room.

Author's Conclusion

The author stated that, for the author's own use, purchasing a DGX Spark is not justified. The author would accept one if it were provided free of charge. The author noted that the device could be useful to users who want a small, self-contained system for background agent tasks rather than a large custom build.