I ran Qwen 3.8-Flash-Next at 1-bit. Nothing broke
Yesterday I read the model card and asked whether my machine could even hold Qwen 3.8-Flash-Next. Last night I found out. I got it running on my 128 GB Strix Halo mini PC, left it alone overnight, and this morning had results for every Unsloth build that fits: 1-bit, 2-bit, 3-bit and IQ4_XS, all through the same four one-shot tests I have been running on the 27B, with the 27B at 4-bit and BF16 sitting in the table as the reference.
Short version: all of it ran, at about 20 tokens per second, and the 1-bit build did not fall apart. Then the part that matters more than the numbers: I do not think this is a daily driver on a machine I also work and game on. Both halves are below, and everything is on a page you can open yourself.
See it for yourself
Every number in this video is checkable. Open the full results page → every playable output, every thinking transcript, every server log, the exact llama.cpp build commands, and a ROCm vs Vulkan explainer.
How it ran before llama.cpp supported it
When the model dropped, Unsloth's bundled llama.cpp did not know the architecture and refused the file. The support lived in an open pull request from Unsloth, llama.cpp PR #27742, so I built llama.cpp from that branch with the Vulkan backend and pointed llama-server at the GGUFs directly. By the time I recorded, the PR had merged into master; the recipe on the results page still works, you just skip the branch checkout now.
Two caveats I say out loud in the video. MTP is still marked work in progress in that PR, so every Flash-Next speed here is plain decoding; from the MTP video I expect the number to go up, not down, once it lands. And the 27B reference runs were on Unsloth's ROCm prebuilt while Flash-Next ran on my Vulkan build, so I report the speeds with the backend named and never as a ratio between the two.
The ladder
Same four prompts, same samplers (Qwen's recommended ones), same seed, thinking on at medium. Peak memory is the whole system, OS included, out of the 123 GB the box exposes.
| Build | File | Peak memory | Generation | Whole exam |
|---|---|---|---|---|
| Flash-Next 1-bit (UD-IQ1_M) | 74.5 GB | 82 GB | 23.1 tok/s | 25m 21s |
| Flash-Next 2-bit (UD-Q2_K_XL) | 78.9 GB | 86 GB | 23.4 tok/s | 20m 29s |
| Flash-Next 3-bit (UD-Q3_K_XL) | 90.0 GB | 97 GB | 19.9 tok/s | 29m 00s |
| Flash-Next IQ4_XS | 93.7 GB | 99 GB | 20.4 tok/s | 19m 53s |
| Qwen 3.8-27B 4-bit (reference) | 17.9 GB | 38 GB | 19.9 tok/s | 21m 57s |
| Qwen 3.8-27B BF16 (reference) | 54.7 GB | 73 GB | 8.7 tok/s | 47m 56s |
The next file up is 111 GB, which does not fit with the OS and a 131k context on top, so IQ4_XS is the top of the ladder on this box. Speed barely moves with size, which is the 6B-active design doing its job: the work per token is the same at every quant, only the expert tables get fatter. The thing that did move was thinking time. The smaller the file, the longer it thought before answering: 14 minutes of thinking across the exam at 1-bit, under 4 and a half at IQ4_XS. That, not generation speed, is why the smallest file took the longest.
What changed from 1-bit to 4-bit
Less than I expected. The Blockfall games all load, all play, all reach game over. The volcano simulations all run at 60 fps; the 1-bit does a strange spiralling-lava thing I would not call intended, the 2-bit is boxier with nicer particles, the 3-bit is the weirdest shape, and IQ4_XS is the nicest looking with wind direction that actually works. On the 27B at medium I got a button to trigger eruptions; none of the Flash-Next builds thought to add one.
The Ledger is the one test with a provably right answer, and every build got it: the pivot, the totals, the dropped duplicate, the three excluded rows, the merged region spellings. IQ4_XS is the one with a bug, and it is the biggest file: its bar chart renders empty because of a NaN in the SVG, and it skipped the totals row. I say this in the video and I will say it here: one error on a one-shot prompt does not make Q4 worse than Q1. In a harness that runs the page and reads the console it would have fixed itself. Objectively it failed the test; it is not a verdict.
Nobody signed "Qwen"
The Blind Artist prompt asks for a dog in a hard hat driving a forklift with three servers on the forks, drawn as raw SVG, signed with the model's own name. All six builds drew the scene. Not one signed it Qwen. The 1-bit wrote "claude-sonnet-4-6", the 2-bit and 3-bit wrote "Claude (Anthropic)", IQ4_XS wrote "drawn by Claude", the 27B BF16 wrote "Claude", and the 27B 4-bit wrote "Gemini". The thinking transcripts show the models reasoning about which name to use and landing on Claude. Same result at every quant, so it is training data, not compression. Plenty of you had theories in the comments last time; I just find it funny that you cannot trust a model's own name in a prompt.
Is it practical? No
Here is the honest half. The 1-bit peaks at 82 GB of system memory. The 4-bit at 99. This is my personal PC, the one I work on, game on, and edit these videos on. A model that holds 100 GB in the background while I try to do anything else is not a daily driver; it is a leave-it-overnight model, and I think that is where it lives for me. For the vast majority of people running local AI, 82 GB means multiple GPUs, a Mac, a DGX Spark, or one of these Strix Halo boxes, and those are expensive. If this hits 30 or 40 tokens per second with MTP, the closet-box conversation starts. At today's prices it does not.
Two things worth knowing if you want it anyway. Artificial Analysis ranked it the same day at an intelligence index of 56, ahead of some paid frontier models, and Qwen sells the hosted version, confusingly named Qwen 3.8-Flash, at 15 cents in and 47 cents out per million tokens. For most people that is the practical way to run this model. And my one-shot prompts are basic; they show that a build renders and works and how fast, not how it behaves in a harness with tools. If you have better ideas for day-to-day local-AI benchmarks, I am listening.
Next: I am taking a short break from Qwen 3.8, because the channel is turning into a Qwen docuseries, and looking at GLM 5.3 Flash.
Sources
- The full results page, every output, transcript, log, and the build recipe
- llama.cpp PR #27742, "model: add Qwen3.8-Flash-Next (qwen4exp)", merged Aug 27
- unsloth/Qwen3.8-Flash-Next-GGUF, the four builds that ran
- Unsloth, Qwen3.8-Flash-Next: How to Run Locally
- Qwen/Qwen3.8-Flash-Next model card
- Artificial Analysis, Qwen3.8-Flash-Next, the intelligence index
- Qwen Cloud, Qwen3.8-Flash pricing
- Qwen 3.8-Flash-Next just dropped. Can I even run it?, yesterday's first look
- The thinking-dial results, where the 27B reference runs come from
- One llama.cpp flag made Qwen 3.8 3x faster, why MTP should help here
