NVIDIA DGX Spark is a 15 × 15 × 5 cm AI computer built around the GB10 Grace Blackwell Superchip with 128 GB of unified memory: enough to run a language model of up to 200 billion parameters or fine-tune a 70B model. With DGX Spark as a Service from Remote Admin, the unit runs in our Tier III data center in Poland and your team uses it remotely, with no hardware purchase and no box under anyone’s desk.
NVIDIA markets DGX Spark as a personal AI supercomputer for your desk. The capabilities are real, but a desk is a poor home for a machine that a whole team depends on, that holds company data and that has to keep running when someone switches off the office power for the weekend. This article covers what DGX Spark can actually do, where its limits are, and how the service works when power, networking, backups and monitoring are our job.
NVIDIA DGX Spark specifications
Figures from the NVIDIA specification, as of November 2026:
| Component | Specification |
|---|---|
| Chip | NVIDIA GB10 Grace Blackwell Superchip |
| CPU | 20 Arm cores: 10× Cortex-X925 + 10× Cortex-A725 |
| GPU | Blackwell, integrated in the GB10 |
| Memory | 128 GB LPDDR5X unified memory (shared by CPU and GPU), 256-bit, 273 GB/s |
| AI compute | up to 1 PFLOP FP4 (theoretical, with sparsity) |
| Storage | up to 4 TB NVMe, self-encrypting |
| Networking | ConnectX-7 200 Gb/s (2× QSFP), 10 GbE, Wi-Fi 7 |
| Power | 240 W power supply, GB10 TDP 140 W |
| Size and weight | 150 × 150 × 50.5 mm, 1.2 kg |
| Software | DGX OS (Ubuntu-based) with the NVIDIA AI stack: NeMo, RAPIDS, NIM microservices, Blueprints, PyTorch |
| Model size (single unit) | inference up to 200B parameters, fine-tuning up to 70B |
| Clustering | 2 units (direct QSFP cable): 256 GB, models up to ~400B; 4 units (200 GbE switch): 512 GB, models up to ~700B |
Two lines in that table define what DGX Spark is good for. The first is 128 GB of memory shared by the CPU and GPU. In a conventional server a model has to fit into the graphics card’s VRAM, and 24 GB or 48 GB cards run out quickly. On DGX Spark the GPU draws on one large pool (minus what the operating system needs), so a model that would otherwise need several cards fits in a single unit. The second is the ConnectX-7 200 Gb/s adapter: server-class networking that lets two or four units work as one cluster.
To check whether a given model fits, use the rule of thumb: weights equal parameters times bytes per parameter (BF16 = 2 bytes, FP8 = 1 byte, 4-bit ≈ 0.5 bytes), plus memory for the context (KV cache) and 10–20% headroom. A 200B model at 4-bit is about 100 GB of weights alone. It fits, but leaves little room for long contexts. We walk through the maths with examples in How much VRAM does an LLM need.
What DGX Spark is good for
DGX Spark is a machine for working on models, not for serving heavy production traffic. In the first role it does very well.
Prototyping AI applications
A knowledge assistant over company documents (RAG), contract analysis, an agent in n8n, a chatbot: every one of these projects starts with checking whether the chosen model actually copes with your data. On DGX Spark you can compare models of very different sizes within a few days, from small ones such as Bielik-11B or Gemma 4 12B up to gpt-oss-120b, Mistral Small 4 (119B) or Mistral Medium 3.5 (128B) at 4-bit quantisation. Your data never leaves our data center while you do it.
Fine-tuning models up to 70B
Adapting a model to your own data (domain vocabulary, answer format, tone) is usually done on expensive GPUs rented by the hour. DGX Spark can fine-tune models of up to 70B parameters, in practice with memory-efficient methods such as LoRA and QLoRA. Full fine-tuning of every weight in a 70B model needs many times more memory; that is work for HGX servers.
Private inference for models up to 200B
For a small team that needs a large model for confidential work, DGX Spark can be the target environment, not just a sandbox. A handful of people taking turns, overnight batch jobs, background document processing: in these scenarios the limitations described below do not get in the way.
R&D teams and the NVIDIA stack
DGX OS ships the same software stack as NVIDIA’s larger systems: NeMo for training and fine-tuning, RAPIDS for GPU data processing, PyTorch, plus NIM microservices and Blueprints, which are pre-packaged model containers and reference application architectures such as AI agents. It is a good place to try NIM, build a first agent and test the whole pipeline before moving it to bigger hardware. We describe how to set up such an environment for a research team in our guide to building a private AI cloud on GPU servers in Poland.
Limitations: 273 GB/s of memory bandwidth
The main limitation of DGX Spark is memory bandwidth. Its LPDDR5X delivers 273 GB/s. An RTX PRO 6000 Blackwell Server Edition card has about 1.6 TB/s, close to six times more, and HBM-based GPUs in HGX systems have more still. When generating text, this translates directly into response speed.
Here is why. To produce each new token, a dense model reads all of its weights from memory. The theoretical ceiling for a single request is therefore memory bandwidth divided by the size of the weights. For a dense 70B model at 4-bit (about 35 GB) that works out at under 8 tokens per second. That is an upper bound from arithmetic, not a measurement, and real numbers will be lower. Mixture-of-experts (MoE) models, which compute only a subset of their parameters (the “active” ones) per token, do much better here, although all of their parameters still have to fit in memory.
What that means in practice:
- It is not a high-concurrency production server. A customer-facing chatbot or an assistant used by hundreds of employees at once needs GPUs with HBM or GDDR7 memory and an inference server with continuous batching (vLLM, SGLang).
- One unit is one point of failure. That is fine for a prototype, but a service your business processes depend on needs redundancy.
- Arm architecture. The NVIDIA stack is ready to go, but your own container images must be built for arm64. Mainstream AI tools support it; older or niche components are worth checking before the project starts.
- 1 PFLOP is a theoretical figure for FP4 with sparsity. Do not compare it directly with numbers quoted for data center GPUs at other precisions.
To be straight about it: if you know from day one that you must handle heavy traffic, DGX Spark is the wrong choice. If you are still working out which model and which architecture make sense, it is a sensible way to work with large models without sending data to public APIs.
Why DGX Spark as a Service instead of buying one
You can buy a DGX Spark. The question is what happens next. A unit sitting in an office needs stable power, secure remote access for the team, backups, updates and someone to react when it stops responding. With DGX Spark as a Service, all of that is on our side.
| Concern | Buy it and keep it in the office | DGX Spark as a Service |
|---|---|---|
| Upfront cost | hardware purchase (capex) | no purchase, you pay for the service term |
| Power | office socket, usually no UPS | redundant Tier III data center power |
| Team access | VPN into the office or exposing the unit to the internet | VPN, SSH and API set up by us |
| Physical security | the office | ISO 27001 data center with access control |
| Backups | your problem | off-device backups of data, checkpoints and configuration |
| Monitoring and incident response | none, or your own | monitoring, optional 24/7 administration |
| Scaling | more units, cables and a switch are yours to sort out | 2- or 4-unit clusters that we build and run |
| Changing hardware | the unit stays with you | move to GPU servers in the same data center |
There is a less obvious argument too. New GPU generations arrive often and model requirements keep growing. Buying a unit ties you to it for years. With a service, once the prototype is done you can move to a cluster or to a server with higher memory bandwidth without having to resell used hardware.
Your data stays in Poland, in a Tier III data center certified to ISO 27001, and the NVMe drive in DGX Spark is self-encrypting. For organisations in regulated sectors (finance, healthcare, the public sector) that is often the precondition for starting an AI project at all.
How the DGX Spark service works, step by step
- Consultation. We talk through what you want to build: which model or model family, how many people will use the unit, what data is involved and under which requirements (GDPR, NIS2, DORA). Based on that we tell you plainly whether one unit is enough, whether you need a cluster, or whether a GPU server makes more sense from the start.
- Configuration. We prepare the unit: current DGX OS, your chosen stack (for example NIM, vLLM, Ollama, PyTorch, NeMo), models downloaded, storage for your data, backups and monitoring. If you want, we expose the model through an OpenAI-compatible API so your application can use it without code changes.
- Remote access. You get access over VPN (per user, or a site-to-site tunnel to your company network) and key-based SSH. The unit is not exposed to the internet, and access is limited to your users and addresses.
- Support and operations. You choose how to work: full root access and self-management, or 24/7 administration by our team, covering updates, incident response and help with rolling out new models. Backups of data and checkpoints are kept off the device.
Pricing is a custom quote. It depends on the contract term, the number of units (single, 2-unit or 4-unit cluster) and the scope of administration.
From one unit to a cluster and a GPU server
DGX Spark has two 200 Gb/s QSFP ports for a reason. Two units connected directly with a cable give you 256 GB of memory and models of up to about 400B parameters. Four units connected through a 200 GbE switch give you 512 GB and models of up to about 700B. We build and run these clusters. How a model is split across units, and which models really fit, is covered in DGX Spark cluster: running 400B–700B models on 2 or 4 units.
When a prototype turns into production, the usual next step is a server with RTX PRO 6000 cards or an HGX B200 system. If you expose the model through an OpenAI-compatible API from the start and package your application in containers, the move is largely a matter of changing the endpoint URL and rebuilding images for x86. We compare the inference servers that make this possible in Ollama vs vLLM vs SGLang vs NVIDIA NIM, and lay out the full hardware ladder in DGX Spark vs RTX PRO 6000 vs HGX B200. You can go through every stage in one data center, with the same team and without moving data to another provider. As a Supermicro and NVIDIA partner, we also supply the hardware for the later stages.
FAQ: frequently asked questions
How much does DGX Spark as a Service cost?
Pricing is a custom quote. It depends on the contract term, the number of units (one, or a cluster of 2 or 4) and whether we or your team handle administration. There is no upfront hardware cost; you pay for the period you use the service.
What models can run on a single DGX Spark?
According to NVIDIA, one unit handles inference for models of up to 200B parameters and fine-tuning up to 70B. At 4-bit quantisation that includes gpt-oss-120b, Mistral Small 4, Mistral Medium 3.5, Devstral 2 and Qwen3.8-Flash-Next (180B, right at the limit). Smaller models such as Qwen3.8-27B, Gemma 4 31B, Bielik-11B or PLLuM-12B fit even at full BF16 precision.
Is DGX Spark suitable for production?
For small-scale production, yes: a few users, batch jobs, background document processing. For many concurrent users, no. The 273 GB/s memory bandwidth limits generation speed, and a single unit has no redundancy. For that kind of workload a GPU server with HBM or GDDR7 memory is the better fit.
Where is the DGX Spark physically located, and where is my data?
In our Tier III data center in Poland, certified to ISO 27001. Data stays in Poland and the EU, the unit’s drive is self-encrypting, and access goes through VPN.
Can several DGX Spark units be clustered?
Yes. Two units are connected directly with a 200 Gb/s QSFP cable (256 GB of memory, models up to ~400B); four go through a 200 GbE switch (512 GB, models up to ~700B). We build and operate the cluster as part of the service.
DGX Spark or a rented GPU server?
Choose DGX Spark for prototyping, fine-tuning and a small team working with a large model. Choose a GPU server when the number of concurrent users and response speed matter. Many projects start on DGX Spark and move to a GPU server once the application goes into production.
Want to know whether DGX Spark is enough for your project? Tell us about the model, the data and the number of users, and we will propose a configuration and a quote. Service details are on the DGX Spark as a Service page, and you can reach us through the contact form.