Run Qwen3.8-Flash-Next Locally on Windows 11, Mac and Kali Linux: GGUF Sizes From 66 GB, the N-Gram Table That Stays on Your SSD, Ollama, DGX Spark FP4, the $0.15 API and vs DeepSeek V4 Flash

Qwen3.8-Flash-Next is Alibaba's open-weight preview of the Qwen4 architecture, released on August 26, 2026: a 125-billion-parameter mixture-of-experts model with only 6 billion parameters active per token, a 262,144-token context, and image and video input, and it beats DeepSeek-V4-Flash on most coding and agent benchmarks. The part almost nobody expects: about 51 billion of its parameters are a giant n-gram lookup table that the model reads only 16 rows of per token, so that table can stay on your SSD while the rest sits in memory. That is why a 64 GB Mac has been measured at about 18 tokens a second on a 125B model, and why the smallest GGUF files (66.4 GB to 79 GB) are realistic on a 64 to 96 GB PC. You can run it with llama.cpp, Ollama (the official tags start at 105 GB), LM Studio, or NVIDIA's FP4 build on a DGX Spark, and if your machine is smaller, the hosted version, Qwen3.8-Flash, costs $0.15 per million input tokens and $0.47 per million output. Below: every file size and what it needs, the exact commands for Windows 11, Kali Linux and Mac, the thinking and vision settings, the AWS route, and the fixes for the errors people hit first.

Jake's computer shop builds small booking and stock tools for local businesses, and Ethan, his developer friend, writes most of the code. Clients keep asking the same question: can the AI that helps write their software stay inside the shop, so their code and customer lists never leave the building? Ethan's answer used to be "only a small model," because the strong coding models needed a server rack. Then Qwen put out a 125B model that people were running on a 64 GB laptop, and Ethan wanted to know how. This page is what he found: what the model is, what each download needs, and the setup for each kind of machine in the shop.

New to running models on your own machine? Our free plain-English series explains weights, quantization and VRAM in an hour. If you only need a good Qwen and your PC has 16 to 32 GB, the smaller Qwen3.8-27B is the easier start. This page is for the big one.

What Qwen3.8-Flash-Next is, in plain English

Qwen is Alibaba's family of open models, and Qwen3.8 is the generation that arrived in August 2026. Most of the family is ordinary: dense models such as Qwen3.8-27B that you can run on a gaming PC, and a very large flagship for servers. Flash-Next is the odd one out. It is an experimental preview of the architecture that will power Qwen4, which means it is where Alibaba tries its new ideas in public before the next big release. Those ideas also happen to make a strong model much cheaper to run.

You do not need to follow the research to use it, but three ideas explain everything else on this page, including why it fits on a desk.

• Mixture of experts. The model holds 125 billion parameters in its main body, spread across 512 small "experts" in each expert layer. For every word it writes, a router picks 10 of those experts plus one shared expert, so only about 6 billion parameters do work at a time. You still need memory for all of them, but the speed is closer to a 6B model than a 125B one.
• Mostly linear attention. Of its 48 layers, 36 use Gated DeltaNet, a kind of attention that keeps a fixed-size memory instead of a cache that grows with every word. Only the other 12 layers use Qwen Sparse Attention, which still keeps a cache but reads at most about 2,048 earlier positions for each new word. That is how it offers a long context without a server's worth of memory.
• A 51-billion-parameter lookup table. Near the start of the network sits an n-gram embedding: a table of 20 million entries, looked up by the last two or three tokens. Every word costs only 16 row lookups in it. The next section is about this table, because it is what lets a 64 GB machine join in.

A word on the license. Qwen3.8-Flash-Next uses the Qwen Community License 1.0, not Apache 2.0 like some smaller Qwen models. The weights are free to download and run, but read the license text on the model page before you build a paid product on it, as you would with any model license.

And a word on the name, because it confuses people. Qwen3.8-Flash-Next is the open model you download. Qwen3.8-Flash is the hosted API version on Qwen Cloud, with a 1-million-token context switched on by default. The Qwen3.8 models we covered in August are the smaller ones you can run on almost any PC; when we wrote that page, Flash-Next looked like a server-only model, and the community has proved that wrong since.

Jake: "125 billion parameters on a laptop? Our best laptop has 64 GB."

Ethan: "That is the interesting part. A third of the download is a lookup table the model barely touches. It can live on the SSD."

The part that makes it fit: a lookup table that can stay on your SSD

Most of a language model is read in full for every word it writes, or at least the active part is. The n-gram table is different. It is a list of 20 million rows, and for each new token the model looks up only 16 of them: eight picked by the last two tokens and eight picked by the last three. Everything else in the table sits untouched for that token.

Your operating system already knows how to treat a file like that. llama.cpp opens model files with memory mapping (mmap), which means the file stays on disk and only the pages that are actually read get pulled into memory. For the expert weights, nearly everything gets read sooner or later, so they end up in RAM. For the n-gram table, only the rows the conversation touches get loaded, and those are a small slice. In practice, that splits the download into two parts:

• The weights you need in fast memory: the attention layers, the experts and the rest, about 37 to 75 GB depending on the file.
• The table that can stay on the SSD: 28.8 GB in ISTA-DASLab's GSQ-RCO files and 38.4 GB in AtomicChat's 64 GB build, kept as a separate file so it can be mapped on its own.

The best real-world evidence comes from a test published in late August on a MacBook Pro with an M1 Max and 64 GB. The tester ran AtomicChat's 84.9 GB build, with the 38.4 GB table left on the SSD, and measured about 17.6 tokens a second of output and about 182 tokens a second reading the prompt, with the model using roughly 46 to 49 GB of memory. The same tester's M5 Max with 64 GB reached about 36 tokens a second. The machine was under heavy memory pressure and swapped a lot, so treat 64 GB as the floor, not the comfortable middle.

Two practical rules follow from this:

1. Keep the model on a fast NVMe SSD, not a USB drive or a hard disk. The first answers are slower while the table rows load, and a slow drive makes that worse.
2. Leave memory mapping on. llama.cpp's --no-mmap and --mlock options force the whole file into RAM, which defeats the trick. Most users never set them, so this mainly matters if you copied a command from another model's guide.

Servers use the same idea in their own way: SGLang can move the table into the host computer's RAM instead of GPU memory, which saved 23.46 GiB per GPU in a four-GPU H200 test while the speed stayed the same.

Will it run on your computer? The memory table

Here are the files that matter, smallest first. "Fast memory" means RAM plus VRAM on a PC, or the unified memory on a Mac or a DGX Spark. The table part of each file can stay on the SSD as described above, which is why some rows fit machines smaller than the file.

Why two families of small files? Unsloth's UD files are the usual dynamic quants, tuned so the most sensitive layers keep more bits, and they are the files most guides use. ISTA-DASLab's GSQ-RCO files pick a separate quantization type for every tensor within a total size budget, and they ship the n-gram table as its own 28.8 GB shard. On the GSQ-RCO team's own tests, IQ3_XXS lands within about half a point of full precision on average across their task set (92.57 against 93.12), while the 2-bit Q2_0 gives up about four points (89.07). That is why IQ3_XXS gets the highlight in the table: the quality of a much bigger file in a download a 64 to 96 GB machine can take.

In plain terms:

• 32 GB or less: not this model. Use the API, or run Qwen3.8-27B, which needs a fraction of the memory.
• 64 GB: possible, with a fast SSD and patience. On a Mac, the 84.9 GB AtomicChat build is the measured route. On a PC with a 16 to 24 GB graphics card, GSQ-RCO Q2_0 or IQ3_XXS is the place to start.
• 96 GB, or 64 GB plus a 24 GB card: GSQ-RCO IQ3_S or Unsloth UD-Q3_K_XL, with room to spare.
• 128 GB of unified memory (Mac, DGX Spark, Strix Halo): the 4-bit files. This is the comfortable tier.

Our honest hardware tiers page explains which laptops and desktops land in which row, and why memory is now the spec that matters most for local AI.

The quickest route: Ollama

Ollama has Qwen3.8-Flash-Next in its official library as qwen3.8-flash-next, with vision, tool calling and thinking. It is the easiest setup, with one catch: the official tags are big, because they are built for machines that can hold the whole model.

1. Update Ollama first. New architectures need new engines. On Windows and Mac, quit Ollama and install the latest version from ollama.com; on Kali, rerun curl -fsSL https://ollama.com/install.sh | sh. Check with ollama --version.
2. Check your free space. The model needs 105 to 120 GB on the drive that holds Ollama's models. To move them to another drive on Windows, run setx OLLAMA_MODELS "D:\ollama" and restart Ollama.
3. Pull and run the tag for your machine:

# Mac with 128 GB
ollama run qwen3.8-flash-next:125b-mlx

# Windows or Linux with 128 GB or more
ollama run qwen3.8-flash-next:125b-a6b-q4_K_M

If your machine has 64 to 96 GB, the official tags are too big. Ollama can pull Unsloth's smaller files straight from Hugging Face instead:

ollama run hf.co/unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q2_K_XL

To send an image in the Ollama terminal, put the file path in your message, for example What does this error dialog say? C:\shots\error.png. In the desktop app, drag the image into the chat. If you see "model requires more system memory than is available," the tag is bigger than your free RAM; our Ollama memory error guide walks through the numbers, and the fix is a smaller file or llama.cpp with the table on the SSD. If it runs but crawls, check that Ollama is using your graphics card at all with our Ollama GPU guide.

Jake: "So Ollama is the easy way, but only if the machine is big."

Ethan: "Right. For the 64 GB laptop I want llama.cpp, so I can pick the file and leave the table on disk."

Run it on Windows 11 with llama.cpp

llama.cpp gives you the most control on a PC: you choose the exact file, decide what goes on the graphics card, and get a local web chat plus an OpenAI-compatible API. Support for this model (its architecture name is qwen4exp) was merged into llama.cpp on August 27, 2026, the day after release, so any current build works. Builds from v0.7.0 (October 15) on also changed the server's default port to 9931.

1. Check your memory. Press Ctrl + Shift + Esc, open Performance, and note the total under Memory and the "Dedicated GPU memory" under GPU. Pick a file from the memory table.
2. Check your SSD space. You need the full download size free, ideally on an NVMe drive.
3. Download llama.cpp. From the releases page on GitHub (github.com/ggml-org/llama.cpp/releases), take the latest Windows x64 zip for your card: CUDA for NVIDIA (plus the matching CUDA runtime zip from the same release), Vulkan for AMD or Intel. Unzip both into one folder such as C:\llama. You can also run winget install llama.cpp.
4. Choose where the model is stored. llama.cpp caches downloads on C: by default. To use another drive, run setx LLAMA_CACHE "D:\models" in PowerShell, then open a new PowerShell window.
5. Start the server with the command below.
6. Open the chat at http://127.0.0.1:9931 once the log says it is listening.

cd C:\llama
.\llama-server.exe -hf unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q2_K_XL --cpu-moe -ngl 99 --jinja -c 32768 -np 1

What each part does:

• -hf ...:UD-Q2_K_XL downloads the file from Hugging Face the first time and reuses it after that. Swap the name after the colon for another size from the table.
• --cpu-moe keeps the expert weights in system RAM and puts everything else on the graphics card. This is what lets a PC with a 16 or 24 GB card run a model this size.
• -ngl 99 sends every layer it can to the graphics card.
• --jinja uses the model's own chat template, which carries the thinking and tool-calling format.
• -c 32768 sets a 32K context. Start there; raise it once everything works.
• -np 1 serves one chat at a time. Early builds crashed when a second chat slot was used, and one slot also keeps memory use down.

To use the GSQ-RCO files instead, download one size with the Hugging Face command-line tool (install it with pip install -U huggingface_hub), then point llama.cpp at the first shard. The second shard, the n-gram table, is found automatically.

hf download ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF --include "IQ3_XXS/*" --local-dir D:\models\qwen-fn
.\llama-server.exe -m D:\models\qwen-fn\IQ3_XXS\Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS-00001-of-00002.gguf --cpu-moe -ngl 99 --jinja -c 32768 -np 1

On a PC, expect the first few answers to be slower than later ones while the table rows load from the SSD. If Windows starts swapping hard (the disk light stays on and the mouse lags), close the browser and anything else large, or step down one size. There are no independent PC speed measurements for this model yet, so treat any tokens-per-second figure you read for a gaming PC with care; the Mac numbers above are the solid ones.

Our tool comparison covers when llama.cpp is worth the extra typing over Ollama or LM Studio.

Run it on Kali Linux

On Kali, or any Debian-based Linux, the quickest install is the official script, which puts a current llama.cpp on your path. If you prefer to build it yourself with NVIDIA support, the second block does that.

# Option 1: the installer
curl -LsSf https://llama.app/install.sh | sh

# Option 2: build with CUDA (NVIDIA)
sudo apt update && sudo apt install -y git cmake build-essential
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build -j --target llama-server llama-cli

Then start the server the same way as on Windows:

./build/bin/llama-server -hf unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q2_K_XL \
  --cpu-moe -ngl 99 --jinja -c 32768 -np 1

Linux needs one extra check: free disk space in the cache folder, which is under your home directory by default. Run df -h ~ before the download. If you run Kali in a virtual machine, give it as much RAM as the host can spare and put the model on a fast virtual disk; a VM with 16 GB will not run this model, whatever the host has.

For a headless Kali box, add --host 0.0.0.0 to reach the chat from another computer on your network, and open port 9931 in your firewall. Only do that on a network you trust, because the server has no password by default.

Run it on a Mac

Apple Silicon Macs are the friendliest machines for this model, because the CPU and GPU share one pool of fast memory. What you can run depends on that pool.

128 GB or more: use Ollama's MLX tag, which is built for Apple Silicon, or the 4-bit GGUF in llama.cpp.

# Ollama, MLX build (105 GB)
ollama run qwen3.8-flash-next:125b-mlx

# or llama.cpp with Homebrew
brew install llama.cpp
llama-server -hf unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q4_K_XL --jinja -c 32768 -np 1

64 GB: this is the setup from the M1 Max test, and it works with care. Download AtomicChat's 84.9 GB build (its table sits in its own 38.4 GB file), quit every large app, and start llama-server with the first shard. The tester used these settings, plus the vision file:

llama-server -m PATH/TO/first-shard.gguf \
  --mmproj mmproj-Qwen3.8-Flash-Next-F16.gguf \
  -ngl 99 -c 32768 -np 1 --jinja

Expect around 18 tokens a second on an M1 Max and more on newer chips (about 36 on an M5 Max with 64 GB), and expect macOS to swap. The tester also avoided two early bugs: a crash when a second chat slot was used (hence -np 1) and an error with an 8-bit KV cache (so leave the cache type at its default).

If you use MLX directly, the mlx-community organization has 4-bit, 2-bit and MTP builds (for example mlx-community/Qwen3.8-Flash-Next-4bit). The 4-bit MLX build belongs on a 128 GB Mac like the Ollama tag.

Jake: "Eighteen words a second. Is that fast enough to code with?"

Ethan: "For reading code and writing a function at a time, yes. For a whole project in one go, I would still use the API and keep the private parts local."

Run it in LM Studio

LM Studio runs this model through its built-in llama.cpp engine, so the two things to check are the same as above: a current runtime and a file that fits.

1. Update LM Studio, then open the runtime settings and update the llama.cpp engine to the latest version. Older engines do not know the qwen4exp architecture.
2. Search for "Qwen3.8-Flash-Next" in the model browser. Unsloth's files and the GSQ-RCO files both load in LM Studio.
3. Pick a size from the memory table, download it, and load it with a 32K context to start.

If LM Studio reports that it failed to load the model, the cause is nearly always an old engine or a file that does not fit; our LM Studio "failed to load model" guide goes through the checks in order.

DGX Spark and RTX PRO 6000: NVIDIA's FP4 build

NVIDIA published two Blackwell-ready versions of the model. nvidia/Qwen3.8-Flash-Next-NVFP4 appeared in early September, and nvidia/Qwen3.8-Flash-Next-FP4-Local, dated October 5, is the one built for desks. FP4-Local stores the experts in NVFP4 and parts of the attention and vision layers in MXFP8, about 96 GiB in total, and it loses little accuracy: 91.5 on GPQA Diamond against 92.2 for full precision.

NVIDIA validated FP4-Local on two machines: the DGX Spark (128 GB of unified memory) and the RTX PRO 6000 Blackwell (96 GB on one card), both with vLLM. The catch is software: upstream vLLM does not support this checkpoint's format yet, so you use a community container.

• DGX Spark: eugr/spark-vllm-b12x:latest
• RTX PRO 6000: ghcr.io/local-inference-lab/vllm:release-10152026

Inside the container, set your Hugging Face token and the environment variables that ship with the FP4-Local release, then start the server:

export HF_TOKEN=hf_your_token_here
vllm serve nvidia/Qwen3.8-Flash-Next-FP4-Local   # plus the FP4-Local serve flags

The server listens on port 8000 and speaks the OpenAI API, so any chat app or script that lets you set a base URL can use it. The FP4-Local build supports the full 262K context and can be extended to 1M, though on a Spark, long contexts compete with the model for the same 128 GB.

If you have a Spark and want the simpler path, the GGUF files in llama.cpp also work there. The 4-bit UD-Q4_K_XL (111 GB) fits its memory, though the FP4 build is the one designed to use Blackwell's FP4 hardware.

GPU servers: vLLM and SGLang

On a real GPU server, run the official weights with vLLM or SGLang, which both had support at launch. The BF16 model is about 354 GB, so plan on several large GPUs; Qwen also publishes an FP8 version that halves that.

# vLLM
pip install vllm
vllm serve "Qwen/Qwen3.8-Flash-Next"

# SGLang
pip install sglang
python3 -m sglang.launch_server --model-path "Qwen/Qwen3.8-Flash-Next" --host 0.0.0.0 --port 30000

The speed on server hardware is remarkable for a model this strong. SGLang's launch tests reached 540 tokens a second for a single user on four B200 GPUs with multi-token prediction switched on, and on four H200s, moving the n-gram table into host memory freed 23.46 GiB per GPU and raised the room for conversation history by 78.54% with no loss of speed. Day-one NVFP4 weights from RadixArk run in SGLang on Blackwell GPUs.

Only 12 of the 48 layers keep a growing cache, so long conversations use far less memory than in a standard model of this size. That is the practical meaning of the linear attention layers: more users, or longer documents, on the same GPUs.

Thinking on or off, and the settings that matter

Qwen3.8-Flash-Next thinks before it answers by default: it writes out its reasoning first, then the reply. That helps on hard problems and wastes time on easy ones. You control it with three switches, which llama.cpp, vLLM and SGLang accept as chat template settings:

• enable_thinking: set it to false for direct answers.
• reasoning_effort: xhigh (the default), medium or low. Lower effort means shorter thinking.
• preserve_thinking: on by default, which keeps the reasoning from earlier turns in the conversation. Set it to false to keep only the latest turn's reasoning and save context.

Qwen's recommended sampling settings differ by mode:

Here is a short Python script that talks to your local llama.cpp server with thinking off and the matching settings. It uses the openai package (pip install openai), because llama.cpp speaks the same API:

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:9931/v1", api_key="local")
reply = client.chat.completions.create(
    model="qwen3.8-flash-next",
    messages=[{"role": "user", "content": "Write a Python function that checks a UK postcode."}],
    temperature=0.7,
    top_p=0.8,
    presence_penalty=1.5,
    extra_body={"top_k": 20, "chat_template_kwargs": {"enable_thinking": False}},
)
print(reply.choices[0].message.content)

In Ollama, type /set nothink in the chat, or start it with ollama run qwen3.8-flash-next:125b-mlx --think=false. If answers start mixing languages, lower the presence penalty; a high value can cause that, with a small drop in quality.

Leave room for long thinking. The model is built for up to 131,072 tokens of answer and 262,144 of reasoning on hard tasks. On a desk, that is more than you will give it, so the practical rule is: thinking off or low effort for routine work, xhigh for the hard problems, and a generous output limit when it is on.

Sending it images and video

Flash-Next reads images and video natively. On the published tests it is ahead of the dense Qwen3.8-27B on screen and document tasks, for example 84.5 on AndroidWorld (controlling an Android phone from screenshots) and 88.5 on RealWorldQA. In practice, that makes it good at reading screenshots, error dialogs, charts, scanned forms and diagrams.

In Ollama, images work in the normal chat: put the file path in your message or drag the picture in.

In llama.cpp, vision needs the separate projector file, the "mmproj." The GSQ-RCO repository ships it as mmproj-Qwen3.8-Flash-Next-BF16.gguf (0.91 GB). Pass it with --mmproj to llama-server and the web chat gets an image button, or use the command-line tool:

llama-mtmd-cli -m IQ3_XXS/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS-00001-of-00002.gguf \
  --mmproj mmproj-Qwen3.8-Flash-Next-BF16.gguf \
  --image screenshot.png -p "What error is shown here, and what should I click next?"

Video works through the server engines (vLLM, SGLang and Transformers), where you send a video file in the request. In desktop tools, the practical workaround is to send a few frames as images. For text-only use, skip the projector entirely and save the memory.

Context length: 262K by default, 1M if you need it

The model reads 262,144 tokens natively, roughly a 500-page book. Qwen's tests ran at 256K. For longer inputs, YaRN scaling stretches it to 1,000,000 tokens. In vLLM, add --max-model-len 1000000 together with the YaRN settings from the model card (a scaling factor of 4.0 on the original 262,144); in SGLang, use --context-length 1000000.

Two cautions. First, this YaRN scaling is static, so it applies to every request and can slightly hurt short ones; switch it on only for the job that needs it. Second, every token of context costs memory, even with the small cache this design keeps. On a 64 to 128 GB machine, start at 32K, move to 64K or 128K if you need it, and watch your memory.

The cheap way: the API

If your machine is too small, or you need speed for a whole project, the hosted version is cheap. On Qwen Cloud it is called Qwen3.8-Flash (model ID qwen3.8-flash), with a 1-million-token context on by default.

Limits on Qwen Cloud: up to 991K tokens of input (983K with thinking on), up to 131K tokens of output, and up to 262K tokens of reasoning.

Some quick math for a small business. Say your team asks 1,000 questions a month, each with 2,000 tokens of code or text going in and 800 tokens coming back. That is 2 million input tokens ($0.30) and 0.8 million output tokens (about $0.38), so about $0.68 a month. Thinking adds output tokens, so a month of hard problems at xhigh effort costs more, but it is still pocket change next to a 128 GB machine.

The trade is privacy. Your prompts go to Qwen Cloud's servers, so keep private code and customer data on the local model, and send the rest to the API. That is the split Ethan settled on.

Qwen3.8-Flash-Next on AWS

As of October 19, 2026, Qwen3.8-Flash-Next is not in Amazon Bedrock or the SageMaker JumpStart catalog. AWS added the smaller Qwen3.8-27B to SageMaker JumpStart on August 27, 2026, and published a guide to running the very large Qwen3.8-2.4T on SageMaker HyperPod. For Flash-Next itself, AWS means hosting it yourself on GPU instances.

The size math points to the G7 family. A g7.24xlarge has four NVIDIA RTX PRO 4500 Blackwell GPUs with 128 GiB of GPU memory in total, enough by the numbers for the 96 GiB FP4-Local build across four GPUs. It costs $14.25664 an hour on demand in US East (N. Virginia), about $342 a day. NVIDIA validated FP4-Local only on the RTX PRO 6000 and DGX Spark, so treat a G7 deployment as your own experiment, run with the same vLLM container approach.

Compare that with the API: $342 a day buys more than 700 million output tokens at $0.47 per million. Self-hosting on AWS makes sense only when you need the data to stay in your own account, or you have steady, heavy traffic. If you go that way through SageMaker, request the GPU quota first; our SageMaker ResourceLimitExceeded guide shows how. And if SageMaker is new to you, start with the plain-English overview.

How good is it? Qwen3.8-Flash-Next vs DeepSeek-V4-Flash

"Qwen3.8 Flash vs DeepSeek V4 Flash" is one of the most searched comparisons for this model, and the benchmark table released with the model answers it directly. All of these were run with a 256K context, against DeepSeek-V4-Flash-0731 (284B total, 13B active) and the dense Qwen3.8-27B. Higher is better in every row.

Read it this way. On fixing issues in real code repositories (SWE-bench Pro, DeepSWE) and on using tools, Flash-Next leads DeepSeek-V4-Flash by a few points while using less than half the active parameters (6B against 13B). DeepSeek leads on building a whole repository from a description (NL2Repo). On hard knowledge questions (GPQA Diamond, Humanity's Last Exam) the two are close, with Flash-Next slightly ahead.

Two cautions. These are the maker's own numbers, run through coding agent harnesses, so your results in your own setup can differ. And DeepSeek has moved since: DeepSeek-V4.1-Flash-1017 arrived on October 17, after this table was published. Our DeepSeek V4.1 Flash page covers that side; the short version is that DeepSeek's files are several times larger, so on a desk, Flash-Next is the far easier model to run.

Flash-Next, Qwen3.8-27B or the API: which one should you use?

The right choice depends on your memory more than anything else.

• Under 32 GB: Qwen3.8-27B locally for private work, and the Qwen3.8-Flash API for the hard problems.
• 64 GB: Flash-Next works, but you will feel the limits: swapping, slow first answers, one chat at a time. It is a good fit for private code review and drafting; keep the 27B around for quick questions.
• 96 to 128 GB: Flash-Next becomes a comfortable daily model. On these machines it is the strongest local option for coding and agent work in this size class, judging by the benchmarks above.
• A team or a business: one 128 GB machine (a Mac Studio, a DGX Spark or a Strix Halo PC) running Flash-Next on the office network, with the API for overflow. That keeps private data in the building and costs little per month after the hardware.

Jake: "So the laptop can do it, but the shop should buy one big machine."

Ethan: "One 128 GB box in the back room, and everyone's editor points at it. The laptop is for when I am at a client's office."

Errors and fixes

These are the problems people hit most often in the first weeks, with the fix for each.

"unknown model architecture: 'qwen4exp'"

Your llama.cpp, LM Studio engine or Ollama is older than the model. llama.cpp support was merged on August 27, 2026, so update to the latest release. In LM Studio, update the llama.cpp runtime in settings, not just the app.

Out of memory while loading, or the PC freezes

The file is too big for your RAM plus VRAM. Step down one size in the memory table, close large apps, and make sure you did not add --no-mmap or --mlock, which force the whole n-gram table into memory. On Windows, check that the page file is on an SSD with room to grow.

The server crashes when a second chat starts

Early builds crashed when a second parallel slot was used. Start the server with -np 1 and update llama.cpp; the same early builds also stopped with an error when the KV cache was set to 8-bit (-ctk q8_0), so leave the cache type at its default.

Ollama: "model requires more system memory than is available"

The official tags start at 105 GB. On a 64 to 96 GB machine, pull a smaller GGUF with ollama run hf.co/unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q2_K_XL, or use llama.cpp so the table can stay on disk.

The first answers are very slow

That is the n-gram table loading from the SSD as new rows are needed. It speeds up as the rows it uses stay in the operating system's file cache. If it stays slow, the model is on a slow drive (move it to NVMe) or the machine is swapping (close apps or use a smaller file).

Answers stop halfway, or only the thinking comes back

Thinking at xhigh effort can use thousands of tokens before the answer starts, and the output limit cuts it off. Raise the output limit, set reasoning_effort to low or medium, or turn thinking off for routine requests.

It ignores the image

In llama.cpp, vision needs the projector file passed with --mmproj. Without it, the model only sees text. In Ollama, make sure the image path is correct and the file is a normal PNG or JPEG.

Connection refused on localhost:8080

llama.cpp v0.7.0 and later listen on port 9931 by default. Open http://127.0.0.1:9931, or add --port 8080 if another tool expects the old port. vLLM uses 8000 and the SGLang command above uses 30000.

Very slow on a PC with a good graphics card

Check that llama.cpp is using the CUDA or Vulkan build, not the CPU-only zip, and that -ngl 99 is set. In Ollama, run ollama ps to see how much of the model sits on the GPU. With --cpu-moe, the experts run from system RAM by design, so RAM speed matters as much as the card.

Frequently asked questions

By the end of the month the shop had one 128 GB machine in the back room running Flash-Next for every editor on the network, and Ethan's 64 GB laptop running the small build for client visits, thinking switched off unless a bug was hard. Private code stayed in the building; big refactors went to the API at a few cents a day. "A year ago this needed a server rack," Jake said. "Now it needs a shelf," said Ethan.

Revision note. Written October 19, 2026. "Don't judge a book by its cover," the saying goes; this model's cover says 180 billion parameters, and a third of them can sit on a shelf.