Qwen 3.8 has proven itself as a formidable open-weight model across its available range, from its larger 2-trillion-plus parameter model through to its 27-billion parameter little brother.
Qwen 3.8 Flash Next however sits in the “middle” with 125 billion parameters, but boasting the newer Qwen 4 architecture. In various independent tests it does seem to pull away from the 27B version, albeit steadily, but the gains are there.
Users running an NVIDIA Spark at home waited patiently, after it was announced, for the Flash Next model to be configured and tested on a single unit. The 27B proved to be a strong local presence but its performance at sub-20 TPS have made it painful to use. Flash Next, with its N-gram lookup table, seems to promise not only fitting the device, but also running a tad better too. The N-gram lookup allows the model to be broken up, with a portion of its memory possible to offload onto cheaper, more readily-available storage, like an SSD.
The well known model tweaker Mia, on X, has released a guide and setup harness to easily run the model on a single DGX Spark. If you have your unit ready, open the guide in another tab and let’s get started running Qwen 3.8.
Setting up the Qwen 3.8 Flash Next harness
Firstly, make sure that you have all other engine instances (llama.cpp, vLLM etc.) stopped so the memory is free enough to start Qwen. This includes any other memory-hungry applications, and a reboot might be in order anyway. Mia’s harness uses a custom fork of vLLM run via Docker, so make sure you have Docker installed (it should come pre-installed on new units).
Git clone the repository to a location on disk that’s easy to find. We chose ~/Applications/, and place most of our cloned repositories there, before building and running them. Once cloned, cd into the new directory and run the first setup commands in the readme of the repository:
# Copy the environment config
cp .env.sample .env
# Download the model
./download.sh
# Start the engine
./start.sh
The documentation states to edit the .env file with necessary values, such as a HuggingFace API key, but we’ve found this not to be necessary for this particular model. The steps above then download the model to disk, and the start command brings up the docker stack with vLLM. Once it’s finished, Qwen 3.8 Flash Next will be running in the background (it’ll return you to the command prompt).
Making use of Qwen 3.8 locally
With vLLM running on your Spark, you should now be able to connect to it. If you’re considering using it for coding, which we’d recommend, you may want to configure it in either OMP or OpenCode.
Assuming your spark is on an IP address in your local network like say 192.168.0.10 (you can check this on your Spark by running ip a), you can use the following configurations to attach your local coding harness to Qwen 3.8.
For OpenCode, edit ~/.config/opencode/config.json to look something like the following:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"spark": {
"npm": "@ai-sdk/openai-compatible",
"name": "DGX Spark",
"options": {
"baseURL": "http://192.168.0.10:8888/v1",
"apiKey": "dummy"
},
"models": {
"qwen3.8-flash-next": { "name": "Qwen3.8 Flash Next" }
}
}
},
"model": "spark/qwen3.8-flash-next"
}
Save that, open OpenCode and type /models to select a new model. If you search for “DGX Spark”, you’ll find it, and be able to select that as your new model.
For OMP, edit ~/.omp/agent/models.yml and make sure it contains something like the following:
providers:
spark:
baseUrl: http://192.168.0.10:8888/v1
api: openai-completions
apiKey: dummy
models:
- id: qwen3.8-flash-next
name: Qwen3.8 Flash Next
contextWindow: 262144
maxTokens: 32768
And then run:
omp models spark # verify discovery against /v1/models
omp setup # pick it as default model, or /model inside a session
Starting a new OMP session should yield Qwen 3.8 as the target model running on the Spark.
To Production!
Now you might be thinking: OK great it’s running locally, but how could I use this in a more professional setting? Qwen 3.8 Flash Next is capable of real work, and since you’re running it locally you have the privacy benefit over using cloud-hosted foundation models. You could use this in a remote or team setting, given the infrastructure for it. You may even have multiple compute units to run this model on, and stringing them together into a fabric of LLM inferencing would make load balancing possible.
There are some great utilities and platforms out there that make streamlining such a process possible. Infersec.ai, for example, allows you to dynamically connect compute through a configurable, authenticated endpoint you can provide to your team members or colleagues. It even supports self-hosting if you’re looking to keep everything out of the public eye.