Home / Blog / DGX Spark setup

October 11, 2026 · Hardware · ~12 min read

DGX Spark setup step by step — from unboxing to a tool your team actually uses

DGX Spark setup starts after delivery, and it usually looks different from what the buyer expected. The machine sits on the desk, powers on, the system boots and the GPU is visible. And yet nobody in the company is using it. This article is about that gap: between hardware that works and a tool your team works with.

It's written for someone who already has the hardware — prices and which machine to buy are covered in our ASUS GX10 vs DGX Spark comparison. Here you'll find an honest map of what needs to be done, how much of it you can do yourself, and where do-it-yourself deployments most often stall. We run two ASUS GX10 units — the same GB10 platform — every day, so part of this comes from our own setup. We deliberately don't copy commands or version numbers into this article; the reason is explained below, together with the official NVIDIA guides that do have them.

What's in the box — and what isn't

Let's say it plainly, because it saves weeks of disappointment: DGX Spark and the ASUS Ascent GX10 are workstations for people who build AI solutions, not office appliances. That isn't a flaw — NVIDIA sells them as exactly that, and as that they're very good. The disappointment comes from expecting a ready-made company assistant the moment the power cable goes in.

What you have after the first boot: an operating system prepared for AI workloads, drivers and libraries matched to the chip, the full unified memory visible, and an environment in which you can get a language model running in a quarter of an hour. That's a lot — on an ordinary workstation, this layer alone can take a day.

What you don't have, and what makes up a “company tool”:

An address your employees open. There's no interface for someone who doesn't use a terminal.
Logins and permissions. No employee accounts, no link to company accounts, and therefore no control over who sees what.
Access to company knowledge. The model doesn't know your contracts, quotes or procedures, and won't fetch them on its own.
Connections to your systems. Email, CRM, network drives and databases are out of its reach until someone connects them.
Maintenance. Backups, monitoring, and someone who reacts when the service stops responding at 8 a.m. on a Wednesday.

The sections below go through these gaps one by one, from the easiest to the hardest.

DGX Spark first boot: the setup wizard

NVIDIA's user guide describes two ways to get through the first boot. You only need one of them for the initial setup; afterwards you can use the machine locally, over the network, or both.

With a display: connect a monitor, keyboard and mouse (USB or Bluetooth), and the wizard appears on screen. If a USB-C/DisplayPort monitor shows nothing, NVIDIA suggests trying HDMI.
Headless, as a network appliance: on first power-on the Spark creates its own Wi-Fi hotspot. The network name and password are on a sticker on the Quick Start Guide in the box. Connect a laptop to that hotspot and the setup page should open in the browser; if it doesn't, its address is printed on the Quick Start Guide.

Before you plug in the power, three things from NVIDIA's checklist are worth following: connect the network cable and all peripherals first, because the machine starts the moment it gets power; make sure you have a stable internet connection — NVIDIA advises against hotel or airport Wi-Fi with a login page and against phone hotspots; and set aside time, because the download can take a while.

The wizard itself asks, in order, for:

language and time zone;
keyboard layout (only in the setup with a display);
acceptance of the terms;
a user name and password — the only account the wizard creates;
optional analytics and crash reporting;
a Wi-Fi network and its password (skipped if a cable already provides internet).

Then the system downloads and installs its full software image and reboots, sometimes more than once. Don't switch it off during this step. In the headless setup, NVIDIA says it can take up to 10 minutes after the wizard reports a reboot before the Spark shows up on your network. If the wizard fails at the network step, the fallback is to connect a display, keyboard and mouse.

On an ASUS GX10 or another partner machine, the system is the same, but check the vendor's quick start guide as well — the description above is NVIDIA's procedure for DGX Spark.

After the wizard: NVIDIA Sync and DGX Dashboard

Two tools from NVIDIA make day-to-day access easier, and both are worth setting up on day one:

NVIDIA Sync — a small app for Windows, macOS and Ubuntu that runs on your laptop. It manages SSH connections, port forwarding and tunnels in the background, launches supported IDEs and your own scripts on the Spark with one click, and includes a Cluster Assistant for linking several units.
DGX Dashboard — a web dashboard built into the system: current system metrics, applying updates, a few settings such as the device name, and JupyterLab. Locally it's in the app menu; from a laptop, NVIDIA Sync opens it in your browser.

Plain SSH and remote desktop work too. The practical point: once these are set up, the Spark can live in a server cupboard and nobody needs to sit in front of it.

The software stack — where it starts

The stack you need to assemble has four layers, each resting on the one below.

Operating system. The machines run DGX OS, an Ubuntu-based system prepared for this hardware. Versions, the release cycle and how to update safely are covered on our DGX OS page.
Drivers and the compute stack. Installed at the factory. Problems only appear during updates, when the layers stop matching each other.
Containers. In practice indispensable. Not because it's fashionable, but because containers isolate library versions from each other — so updating one tool doesn't stop all the others.
Inference engine and interface. The engine runs the model and exposes it as a service; a simpler one is fine to start with and for single users, a more efficient one handles many parallel requests. On top sits a browser interface — the only thing an employee will ever see.

Now something that needs saying directly. We don't copy specific commands or version numbers here, and it's a deliberate choice. This stack changes with every system and library release, and an outdated command in a guide is worse than none: it costs the reader an hour diagnosing a problem they didn't have. NVIDIA maintains its own official collection of more than 60 step-by-step playbooks for this hardware — inference engines, development environments, fine-tuning, networking and clustering. That's the right place for commands; the next section shows which ones to start with.

One surprise worth knowing in advance: the Grace Blackwell GB10 platform is built on ARM, not x86. Most mature AI tools have ARM builds, but not all of them — and this is the most common point at which a ready-made guide from the internet stops working on this machine. Check it before you install, not after.

Which playbook to start with: Ollama, ComfyUI, vLLM

The playbooks cover a lot, from robotics to data science. For a company that wants its first useful tool, five of them matter most. The time estimates are NVIDIA's own and include downloads:

Goal	NVIDIA playbook	What you get	NVIDIA's estimate
Chat in the browser for a few people	Chat with LLMs Using Open WebUI and Ollama	Open WebUI container with Ollama built in	15–20 min
Images and video	Generate Images and Videos with ComfyUI	ComfyUI in the browser, port 8188	about 2 hours
Many users at once, an API for your apps	Serve LLMs with vLLM on One Device	an OpenAI-compatible model server	—
Smaller or heavily compressed models	Serve Models with llama.cpp	a lightweight model server	—
A model too big for one unit	Serve LLMs with vLLM Across DGX Sparks	one model split across two or more units	—

The playbooks are written for DGX Spark. Since the ASUS GX10 has the same chip and the same system — and its own dashboard links to these playbooks — in practice you use them the same way.

DGX Spark and Ollama

The quickest way to a working chat is NVIDIA's Open WebUI and Ollama playbook. It runs a single container in which Open WebUI provides the chat interface and Ollama downloads and runs the models on the GPU. On the Spark's own desktop you open it on port 8080; from a laptop, NVIDIA Sync forwards it to port 12000. You pick models in the interface — NVIDIA's examples are gpt-oss:20b (about 15 GB) and qwen3.6 (about 25 GB), plus about 7 GB for the container image.

Two practical notes. First, the playbook expects you to paste terminal commands, and NVIDIA mentions that Docker permissions may require adding your user to a group and logging in again — a classic first-hour snag. Second, Ollama is a good start for one person or a small team; when a whole department works at once, a server built for parallel requests, such as vLLM, makes more sense — that's the “works great until the department joins” problem from the list further down.

DGX Spark and ComfyUI

ComfyUI is an open-source, node-based web app for image and video generation: instead of a single text box, you connect model loaders, samplers and decoders into a workflow, saved as a JSON file you can version and share. NVIDIA's playbook has two paths:

Image quick start — a Python install on the host with the Z-Image-Turbo model: about 24 GB of GPU memory and at least 30 GB of free disk.
Video workflows — a container with FLUX, Wan 2.1, HunyuanVideo and NVIDIA Cosmos in three tiers: at least about 70 GB of disk for the first tier (about 230 GB for all of them) and peak memory of about 80, 100 and 120 GB.

Those video numbers show what the 128 GB of unified memory is for: workflows that need more memory than consumer graphics cards offer fit on one desk-sized machine. If you plan to keep several video models next to your language models, check free disk space first — all three video tiers together take about 230 GB.

Which DGX Spark models to run — and why the answer changes every month

First, the hard limit. According to NVIDIA, one 128 GB DGX Spark runs models of up to 200 billion parameters, the 64 GB version up to 100 billion, and two linked units up to 400 billion. Everything else depends on your task.

You won't find a model ranking here. Not because we don't have one, but because a ranking put together in August 2026 will be misleading by November — and this article is meant to stay useful longer. Instead of a list of names: four criteria that won't age along with the models.

Criterion	What exactly to check
Memory footprint	The size of the weights at your chosen quantization plus headroom for context. That's the part most often forgotten: the longer the documents you process and the more people working at once, the more memory you need on top of the model itself. Weights that fit “just about” mean you'll run out of memory on the first long document.
Your language and your documents	Test on your own documents, not on benchmarks — those mostly measure general English tasks. Twenty to fifty real files from the process the model is meant to handle are enough.
License	“Open weights” doesn't always mean “commercial use allowed”. Some models restrict use cases or company size. Read it in the model card; don't assume it.
Quantization	A trade-off between memory and quality. Stronger quantization lets a bigger model fit, but costs precision — most of all on tasks that need exactness, such as working with numbers and citing sources.

The order of decisions is always the same: first the task, then a test on your own data, and only at the end the model's name.

For reference, what runs on our own hardware (measured): on a single GX10, Bonsai 2 27B writes at 30–35 tokens per second; on the two-unit cluster, MiniMax M2.7 (230B) runs at 33–36 tokens per second, and GLM 5.3 Flash (320B) is our everyday model. If your task is choosing between fixed options rather than writing text, small decision models are worth a look too.

The terminal: what you can't avoid

Honestly, because this question comes up in every conversation: the deployment stage happens in the terminal. There's no installer with a “Next” button. NVIDIA's own playbooks list terminal familiarity as a prerequisite.

What actually gets done on the command line: network configuration and the first start, installing the container layer and the engine, downloading models, running the engine as a system service — so it comes back by itself after a restart — configuring the web interface, and later updates and troubleshooting.

How much of it is there? Not hundreds of commands; realistically a dozen or so operations. But each one needs to be understood. The difference between “I copied the command” and “I know what it sets” only shows up at the first failure — for example when a service started by hand in a terminal window doesn't come back after a power cut, and the person who set it up is on vacation.

It's worth knowing, though, that this burden falls only on the person deploying it. After a proper deployment, end users never see a terminal — they open an address in the browser, log in and type.

Connecting it to your company's systems — where programming starts

This is the section this article was written for. Getting the model running ends the installation part and starts the programming part — and this is exactly where most do-it-yourself deployments stop. Not for lack of skill, but because the kind of work changes: until now it was configuration, from here on it's writing and maintaining code.

Three typical directions, and what actually has to be built in each:

Email. The model won't reach into a mailbox by itself. You need a connection to the mail server, rules deciding which messages are handled at all, a queue, error handling and — for outgoing replies — a step where a human approves them.
Company documents. For the model to answer from contracts and procedures, you need an indexing process and a vector database: who indexes, how often, what happens to changed files. Here lies the most overlooked problem: permission mapping. An employee must not get an answer containing content from a document they can't open on the network drive — and by default, that's exactly what will happen.
CRM, ERP, SQL databases. Access through an API or directly to the database, field mapping, limiting the scope of data, and control over what the model must not change.

Each of these connections is a component someone has to write, test and maintain as the source system changes.

What breaks most often

A list from practice, ordered by how often it comes back. The common denominator is unsettling: none of these problems shows up on day one.

Dependencies and versions. An update to a driver or library can stop an environment that worked for months. That's the main reason containers aren't a luxury.
Memory. The model fit during tests, but with a longer document or three people at once there's no room left for context. It shows up as an error or a drastic slowdown — usually on the first serious task, not during trials.
A model that won't load. The wrong file format, no build for this architecture, or an interrupted download. Usually the quickest to diagnose.
A service that doesn't come back after a restart. The classic: started by hand in a terminal session instead of as a system service. It surfaces at the first power cut.
Performance dropping with several users. An engine configured for one user handles requests one after another. The symptom: “it worked great until the department joined”.

When one unit isn't enough

One machine is one memory budget — and that, not compute, sets the limit of what you can run. When the model you need no longer fits, two units are linked directly with a dedicated cable, which gives you a shared, larger pool of memory: 256 GB and, per NVIDIA, models of up to 400 billion parameters. We describe how that works, with our own measurements, on a separate page — see our DGX Spark cluster guide.

Do it yourself or hire help — concrete criteria

Let's start with a sentence you usually don't find in articles that sell deployments: if you have a Linux administrator and a Python developer in-house, do it yourself. It's a sensible decision, the hardware is designed for it, and the knowledge stays in the company. The estimates below will help you plan.

Time required — estimates from our own deployments, not guaranteed figures, as of August 2026:

A model with a browser interface for a few people: one to two working days for someone who has done it before. For a first attempt, budget noticeably more — most of the time goes not into installation but into choosing the model and testing it on your own data.
Integration with one company system: weeks, not days. That's where the code, the tests and the permission mapping are.
Maintenance: a small, constant overhead — updates, backups, reacting to failures.

Outside help makes sense in four situations — check whether one of them describes yours:

You don't have those people. The simplest case. Learning on production hardware that costs thousands of dollars is expensive.
You have them, but their time is worth more. If your only developer spends three weeks not working on your product, the deployment costs their rate, not an invoice for a service.
The deployment touches confidential data. A mistake in document permission mapping costs more than the whole service — and nobody notices it until someone sees another person's contract.
You need someone accountable. “Got it running” and “is responsible for it running” are different things — whoever does the work, agree on who responds to failures and how fast.

If you'd like a second opinion on your plan, or help with a specific step, we do remote setup and consulting — tell us where you are. And if after reading this you decide to do it yourself, that's a good outcome too: this article was meant to leave you better informed whether or not you get in touch.

Frequently asked questions

How do I set up a DGX Spark out of the box?

Connect the network cable and any peripherals first, because the DGX Spark starts as soon as it gets power. A setup wizard then asks for language and time zone, terms, a user account, optional analytics and a Wi-Fi network, after which the system downloads and installs its full software image and reboots, sometimes more than once. Don't interrupt it. At that point you have a working machine, but not yet a tool your team can use. On an ASUS GX10 or another partner machine, check that vendor's quick start guide as well.

Can I set up a DGX Spark without a monitor?

Yes. On first power-on the DGX Spark creates its own Wi-Fi hotspot; the network name and password are on a sticker on the Quick Start Guide in the box. Connect a laptop to it and the setup page should open in the browser. The Spark also needs a stable internet connection for setup — NVIDIA advises against hotel or airport Wi-Fi and phone hotspots — and NVIDIA says it can take up to 10 minutes after the wizard finishes before the Spark appears on your network.

Do I need to know Linux to set up a DGX Spark?

For the deployment stage, yes. Installing the inference engine, downloading models, running them as a service that comes back after a restart, and troubleshooting all happen in the terminal; NVIDIA's own playbooks list terminal familiarity as a prerequisite. It isn't hundreds of commands, but each one needs to be understood, because some configuration mistakes only show up weeks later. End users never see the terminal: after a proper deployment they work in a browser window.

Does DGX Spark work with Ollama?

Yes. NVIDIA's playbook “Chat with LLMs Using Open WebUI and Ollama” runs Open WebUI in a container with Ollama built in. You reach it on port 8080 on the Spark's own desktop, or from a laptop on port 12000 through NVIDIA Sync. NVIDIA estimates 15 to 20 minutes including downloads. Ollama is a good start for one person or a small team; for many parallel users, NVIDIA has separate vLLM playbooks.

Can DGX Spark run ComfyUI?

Yes. NVIDIA's playbook “Generate Images and Videos with ComfyUI” installs ComfyUI with a browser interface on port 8188. The quick start for images needs about 24 GB of GPU memory and 30 GB of disk; the container-based video workflows (FLUX, Wan 2.1, HunyuanVideo, Cosmos) peak at about 80 to 120 GB of memory, which fits in a 128 GB DGX Spark. NVIDIA estimates about two hours, longer on the first run because of model downloads.

Which models can I run on a DGX Spark?

NVIDIA states up to 200 billion parameters on one 128 GB DGX Spark, up to 100 billion on the 64 GB version and up to 400 billion on two linked units. Within that limit, choose by four criteria rather than a ranking that ages in weeks: memory after quantization plus room for context, quality on a sample of your own documents, what the license allows commercially, and how much quantization you accept.

Is the ASUS Ascent GX10 set up the same way as DGX Spark?

On the software side the process is very similar: both machines use the same GB10 platform and run DGX OS. The differences are the case, cooling, ports and the support channel, and system releases and recovery tools for a partner machine come from its manufacturer. Before you install anything, check the support page for the exact model on your desk.

How long does it take to get a DGX Spark ready for a company?

A model with a browser interface for a few people usually takes one to two working days for someone who has done it before; budget more for a first attempt. Connecting it to company systems such as email, a network drive, a CRM or a database takes weeks rather than days, because it needs integration code, testing and permission mapping. These are estimates from our own deployments, not guaranteed figures.

Sources

NVIDIA, DGX Spark User Guide — First Boot — setup with a display or headless via the Wi-Fi hotspot, the wizard steps, the software download and reboots, the 10-minute note.
NVIDIA, NVIDIA Sync and DGX Dashboard — remote access, tunnels, apps, Cluster Assistant; monitoring, updates and JupyterLab.
NVIDIA, DGX Spark Playbooks — the official step-by-step guides. This is where to find current commands. In particular: Chat with LLMs Using Open WebUI and Ollama and Generate Images and Videos with ComfyUI (ports, memory, disk and time estimates).
NVIDIA, DGX Spark product page — model sizes: up to 200B on 128 GB, up to 100B on 64 GB, up to 400B on two units.
ASUS, Ascent GX10 — downloads and manuals and the vendor FAQ.

As of October 11, 2026; NVIDIA sources checked on that day. We don't give commands, version numbers or install scripts in this article — the software stack changes with every release, and an outdated guide is worse than none, so we point to NVIDIA's official documentation above. Time estimates for deployments come from our own work; speeds marked “measured” come from our own hardware.