LM Studio on a DGX Spark: Linux ARM64 support, headless llmster, and speed next to llama.cpp and Ollama

LM Studio runs on a DGX Spark: it has shipped a Linux ARM64 build since 14 October 2025, when it launched as a Spark partner with a llama.cpp engine built for CUDA 13, and NVIDIA's lm-studio playbook (updated 21 October 2026) installs its headless daemon, llmster, and serves Nemotron 3.5 Super VL on port 1234 on 128 GB machines. As of 7 November 2026 the app is at 0.4.28. Speed follows the bundled llama.cpp runtime: the one published Spark comparison (November 2025) had LM Studio at about 10 tok/s against 14 for a fresh llama.cpp build on the same model, so update the runtime and expect llama.cpp numbers, not better ones.

Read on 7 November 2026. Licensing (free for personal and internal business use, not for offering as a service to third parties) and the API comparison with Ollama are in LM Studio vs Ollama; this page is about running it on GB10.

Does LM Studio run on the Spark's ARM64 CPU and GB10 GPU?

Yes, both, and that has been true since the Spark went on sale. LM Studio's launch post of 14 October 2025 says that "starting now, LM Studio ships for Linux on ARM (aarch64)" and that the team "brought up a new variant of LM Studio's llama.cpp engine with support for CUDA 13". Its system requirements list Linux on x64 and ARM64, Ubuntu 20.04 or newer, distributed as an AppImage, with the caveat that versions newer than 22 "are not well tested"; DGX OS 7 is Ubuntu 24.04 based. On the Spark the GPU engine shows up as llama.cpp-linux-arm64-nvidia-cuda13, the runtime name a GB10 owner quoted in bug-tracker issue 1742.

NVIDIA treats it as a supported path. The lm-studio playbook lists the DGX Spark with 128 GB of unified memory as its only platform, budgets 30 minutes, and asks for 65 GB of free memory and disk (70 GB recommended) for its example model. It installs llmster rather than the desktop app, which suits a Spark that sits under a desk without a monitor.

How do you install llmster headless on a Spark?

With one script, then four lms commands. These are the playbook's instructions, except that I bind to localhost; the playbook binds 0.0.0.0 so a laptop on the same LAN can reach it.

curl -fsSL https://lmstudio.ai/install.sh | bash
source ~/.bashrc                         # puts lms on PATH, per the playbook's troubleshooting
lms daemon up
lms get nvidia/nemotron-3.5-super-vl     # 70 GB or more, depending on the build
lms ls
lms load nvidia/nemotron-3.5-super-vl --context-length 32768
lms server start --bind 127.0.0.1 --port 1234
curl http://127.0.0.1:1234/v1/models

The lms load reference lists the flags worth knowing: --context-length, --gpu max to offload every layer, --ttl to unload after idle seconds, --identifier to give the model a short API name, and --estimate-only to print the memory estimate without loading. The server-start reference says --bind defaults to 127.0.0.1 and can also be set through LMS_SERVER_HOST, and warns that any other bind "exposes the server beyond localhost". LM Studio's API tokens (0.4.0 and later) are switched on in the desktop app's Developer page; the CLI reference shows no flag for them, so on a headless Spark I keep the bind on localhost and reach it through an SSH tunnel:

# on your laptop
ssh -N -L 1234:127.0.0.1:1234 you@your-spark
curl http://127.0.0.1:1234/v1/models

The playbook's alternative is LM Link, LM Studio's encrypted device-linking service: it runs over Tailscale mesh networking, needs no open port, is in preview, and is free for up to 2 users with 5 devices each. To start llmster at boot, LM Studio's startup-task page gives a systemd unit:

[Unit]
Description=LM Studio Server

[Service]
Type=oneshot
RemainAfterExit=yes
User=YOUR_USERNAME
Environment="HOME=/home/YOUR_USERNAME"
ExecStartPre=/home/YOUR_USERNAME/.lmstudio/bin/lms daemon up
ExecStartPre=/home/YOUR_USERNAME/.lmstudio/bin/lms load openai/gpt-oss-20b --yes
ExecStart=/home/YOUR_USERNAME/.lmstudio/bin/lms server start
ExecStop=/home/YOUR_USERNAME/.lmstudio/bin/lms daemon down

[Install]
WantedBy=multi-user.target

Save it as /etc/systemd/system/lmstudio.service, swap in your model, then sudo systemctl daemon-reload and sudo systemctl enable --now lmstudio. Models live under ~/.lmstudio/models/, which matters for disk planning on a 1 TB Spark; the planned model storage guide covers sharing one cache between engines.

What about the desktop app?

It runs, from the ARM64 AppImage, if the Spark has a display or a remote desktop. In the November 2025 forum thread where the speed numbers below come from, owners launched it with chmod +x LM-Studio-0.3.32-2-arm64.AppImage and ./LM-Studio-...-arm64.AppImage --no-sandbox; a second owner could open the app but every model load failed with exit code 127, which the first attributed to settings such as an oversized context. Two open bug reports are specific to Linux ARM64: issue 1954 (May 2026, LM Studio 0.4.13) describes the llmworker.js process using 90 percent or more CPU after inference until the model is unloaded, which made a GNOME remote desktop sluggish; and issue 1742 (April 2026) is Gemma 4 GGUFs failing with "unknown model architecture" on the ARM64 CUDA 13 runtime 2.8.0 until a newer runtime (2.10.0, per a commenter) arrived. Both point the same way: on the Spark, the runtime version matters more than the app version.

How do you keep the llama.cpp runtime current?

With lms runtime, separately from the app. LM Studio's runtime reference lists ls, get, select, remove and update. NVIDIA's troubleshooting tab ties one Spark error to it: a load that fails with "llama-server did not become healthy" (HTTP 503) means an outdated llama.cpp runtime. The playbook spells the fix lms runtime upgrade; the current CLI reference names the subcommand update.

lms runtime ls          # which llama.cpp build is active
lms runtime update      # pull the newest one
lms runtime select      # pick a version interactively

How far behind is it? LM Studio 0.4.26 (13 October 2026) shipped runtime 2.50.0, "upstream b11337" per the changelog. Upstream llama.cpp published b11337 on 2 October and b12189 on 7 November, 852 builds later by my subtraction. For most models that gap is harmless; for a model architecture that landed last week it is the difference between loading and failing.

How fast is LM Studio compared with llama.cpp and Ollama on a Spark?

Close to llama.cpp when the runtimes match, and nobody has published a current like-for-like LM Studio figure on a Spark that I could find. The evidence:

Reported by third parties. In the forum thread the llama.cpp quant was not stated for the 14 tok/s figure; a second owner got 14.34 tok/s with a Q4_K_M build in llama-cli. The Kubesimplify row is engine-reported decode after warm-up, with the identical GGUF blob mounted into each wrapper. LM Studio was not in that test.

The last row is the useful one. Three wrappers around llama.cpp, fed the same file, landed within about 3 percent of each other, which is what you would expect when the engine does the work. LM Studio is the same kind of wrapper, so with a current runtime I would expect it inside that band; that is my inference, not a measurement. The November 2025 gap (10 against 14) fits the other explanation, an older bundled runtime. If you need the numbers for your model, the llama.cpp build guide gets you the comparison point in 15 minutes, and the Ollama on a Spark guide has Ollama's settings.

What should the playbook's model do? By my calculation from the bandwidth, not from any measurement: Nemotron 3.5 Super VL is 120B parameters with 12B active per token, per LM Studio's catalog, and the GGUF it downloads is 70.1 GB at Q4_K_M.

bits per weight   = 70.1 GB x 8 / 120 B params        = 4.7 bits
bytes per token   = 12 B active x 4.7 / 8             = about 7.0 GB
decode ceiling    = 273 GB/s / 7.0 GB                 = about 39 tok/s
expected range    = 50 to 80 % of ceiling             = about 20 to 31 tok/s

same for gpt-oss-120b: 59.02 GiB / 116.83 B = 4.3 bits; 5.1 B active = 2.8 GB
ceiling about 98 tok/s; llama.cpp's 58.72 is 60 % of it

The 50 to 80 percent band is where the vLLM measurements on the benchmarks page landed. The model also has a built-in MTP head, and LM Studio has supported MTP drafters since 0.4.22 with llama.cpp engine 2.29.1 or newer, which is the one way past that ceiling for a single user.

Which models fit, and how much memory do they leave?

Anything in GGUF that fits in about 110 GB after the OS, one large model at a time. LM Studio's catalog gives minimum system memory per model: 70 GB for Nemotron 3.5 Super VL and 65 GB for gpt-oss-120b. On a 128 GB Spark that leaves room for the context of one big model or for two mid-size ones side by side, not two 120B models. Run lms load --estimate-only first, and use the memory calculator for the KV cache of long contexts. If a load fails with CUDA out of memory well inside the budget, the playbook's troubleshooting note on unified memory applies: flush the page cache with sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches'.

Can you run LM Studio on a rented Spark?

llmster should run there; the desktop app is not worth the trouble. A GPUwerk instance is a Docker container on a dedicated Spark where you are root (see the tenant environment). As far as LM Studio's docs show, llmster's installer and daemon need nothing the instance lacks except systemd. I have not seen GPUwerk or LM Studio test it in that setup, so treat these steps as my adaptation:

# once: keep LM Studio's files on the volume that survives a rebuild
mkdir -p /workspace/lmstudio && ln -s /workspace/lmstudio ~/.lmstudio
curl -fsSL https://lmstudio.ai/install.sh | bash

# /workspace/.gpuwerk-init (chmod +x; runs as root on every container start)
#!/bin/sh
[ -e ~/.lmstudio ] || ln -s /workspace/lmstudio ~/.lmstudio   # a rebuild resets /root
~/.lmstudio/bin/lms daemon up
~/.lmstudio/bin/lms load openai/gpt-oss-120b --yes
~/.lmstudio/bin/lms server start --bind 127.0.0.1 --port 1234

I would not count on LM Link there: it is built on Tailscale, and the tenant environment rules Tailscale out (no TUN device, no NET_ADMIN), so use the SSH tunnel above. The 1 TB disk is shared with the host, so check df before pulling two 70 GB models.

My verdict: on a Spark you also sit in front of, LM Studio is the friendliest way to browse and try GGUF models, and llmster makes it a reasonable headless server for one or two people. For a team endpoint I would not use it; one user's speed is llama.cpp's at best, and for concurrency vLLM or SGLang batch far better. If you only want an API, building llama.cpp yourself gets the newest kernels the day they land.

FAQ

Sources

Every figure above is attributed to its source in the sentence or table where it appears. Pages were read on 7 November 2026 unless a date says otherwise.

• NVIDIA DGX Spark (LM Studio blog), LM Studio, 2025-10-14
• Serve LLMs with LM Studio: Instructions, NVIDIA build.nvidia.com
• Serve LLMs with LM Studio: Overview, NVIDIA build.nvidia.com, 2026-10-21
• Serve LLMs with LM Studio: Troubleshooting, NVIDIA build.nvidia.com
• System Requirements, LM Studio docs
• Run LM Studio as a service (headless), LM Studio docs
• Setup llmster as a Startup Task on Linux, LM Studio docs
• lms server start, LM Studio docs
• lms load, LM Studio docs
• lms runtime, LM Studio docs
• Authentication, LM Studio docs
• LM Studio changelog, LM Studio, 2026-10-31
• nemotron-3.5-super-vl, LM Studio model catalog
• lmstudio-community/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-GGUF files, Hugging Face
• [Linux arm64 + CUDA] Gemma 4 GGUF fails: unknown model architecture 'gemma4' (issue 1742), GitHub lmstudio-ai/lmstudio-bug-tracker, 2026-04-03
• [Linux ARM64 / DGX Spark] llmworker.js CPU 100% usage persists after inference completes (issue 1954), GitHub lmstudio-ai/lmstudio-bug-tracker, 2026-05-22
• Any tips on running Magistral?, NVIDIA Developer Forums, 2025-11-23
• llama.cpp DGX Spark benchmarks, ggml-org on GitHub, 2026-02-05
• Releases · ggml-org/llama.cpp, GitHub, 2026-11-07
• NVIDIA DGX Spark performance, Ollama blog, 2025-10-23
• Local LLM Inference Engines on DGX Spark, Explained, Kubesimplify, 2026-07-17