Top
Best
New

Posted by tosh 17 hours ago

Qwen3.8-Flash-Next(qwen.ai)
https://imageat.com/models/qwen-3-8-27b-uncensored
653 points | 213 commentspage 2
xlayn 11 hours ago|
For the impatient, I merged llama.cpp tentative branches to get it running here https://github.com/alainnothere/llama.cpp/tree/disk-cache-ev..., thing runs at 23.54 token/sec and my setup runs at high 30 the 3.8 dense 27B.

and this is the pelican from the iq4_xs model https://github.com/alainnothere/llama.cpp/blob/disk-cache-ev...

cmrdporcupine 10 hours ago|
If you've got a DGX Spark try my little engine: https://github.com/rdaum/eider/

NVFP4 quant

armcat 16 hours ago||
How is input token efficiency/verbosity on this model? Has anyone tried? GLM 5.2 was doing lot of turns and thinking piling up input tokens in the context (compared to Claude and GPT models). Then Qwen3.8-27B was 2x of that. Both delivered good output results but those cumulative input token costs were not cheap. Note this is on our specific business workloads. Genuinely interested in other people's experience (if you are able to try it out).
petu 16 hours ago|
Haven't tried, would be surprised if it's any different.

It's new arch demo for future Qwen 4 family, but (as I understand) training recipe/data is same as any other 3.8 model.

freakynit 16 hours ago||
Those benchmarks look seriously impressive.. considering how small of a MoE model this is.
hedgehog 11 hours ago||
In initial testing on Ryzen 395 / Strix Halo it's about 22 tokens/s generation and the output quality is impressive. Better and faster than 3.8 27B, and enough better to justify moving away from 3.6 35B even though 35B is still faster. The Unsloth weights don't come with vision support but you can add that back yourself. llama.cpp recipe in case anyone else wants to save some time on setup: https://pastebin.com/fcqsbDTv
mdp2021 11 hours ago||
> Better... than 3.8 27B

How can a "6b active per token" MoE be better than a just released 27b in the same family? Possible maybe, but quite interesting and requiring some explanation.

Edit: ok, on second thought, probably because the small "experts" are really rich in specialized training compared to the dense model. Still raising questions about the details, e.g. the reasoning abilities (or all meta-skills) of a "6b per token" network compared to the dense capabilities...

hedgehog 10 hours ago||
Separating knowledge from reasoning so you only pay for what you use is a big rationale for MoE, the big problem being MoE training has historically been hard to get right. In a dense model every single token you're paying a cost to determine whether you're now talking about the flavor of durian.
mdp2021 8 hours ago||
Sure, the "6b subset" can be more knowledgeable on its area than a whole 27b generalist (and more efficient), but where is the simulated Intelligence encoded? A 6b subset as or more intelligent than a 27b raises the question of how metacognition skills are stored.
mapontosevenths 5 hours ago||
MOEs are built by training a second "router" model to identify which parts matter inside the dense model.

Think of MOE as ignoring noise, rather than a more efficient encoding of the data we teach it which ones can be ignored. Turning down the noise actually sharpens the results sometimes.

Modern LLM's are wildly inefficient.

data-ottawa 11 hours ago||
We should still expect significant performance improvements.

I believe Unsloth’s branch (and ggml’s) don’t support MTP or the ngram embedding yet.

hedgehog 10 hours ago||
The active param count is so small I'm not sure how much advantage MTP will have, the current llama.cpp does load the ngram embeddings but I haven't verified it uses them. I expect to redeploy all this stuff every few days as the tooling gets improved.
cmrdporcupine 10 hours ago||
My initial implementation of MTP I have here in my own (DGX Spark specific) custom runtime brought it up from ~12 tok/sec without MTP to ~16 to ~20 with; depending on workload.

It's not world changing, but at those speeds I'll take anything I can get.

(The ngram embeddings in this case are paged to/from disk which seems to cost ... basically nothing).

https://github.com/rdaum/eider/

hedgehog 9 hours ago||
It should be faster, Q6 on Ryzen 395 using Vulkan llama.cpp is about 22 tokens/s with no MTP, and I'd expect the Spark to be 20% faster or something in that neighborhood.
cmrdporcupine 9 hours ago||
Probably. I've spent zero time with optimization at this point. Code is all new this morning.

Curious if llama.cpp is doing full BF16 for the n-gram embeddings table, or if that's quantized, too. I was going to try nvfp4 for that but wasn't sure about the quality risk.

Spark usually wins on prefill, not decode. I think memory bandwidth is about same between the two. What do you get for prefill/prompt?

hedgehog 9 hours ago||
Ok, at 50k context its about 126 prefill, 13 generation.
cmrdporcupine 9 hours ago||
Oh, interesting. So beats on prefill and matches at decode. MTP will help you a bit once you have it. I've got a lot of work to do to optimize prefill.

Kinda wish I had a Strix Halo here to play with as well.

hedgehog 6 hours ago||
I just took a minute to look at your eider repo, very cool. It looks like most of the code outside the kernels and immediately surrounding plumbing would work well on AMD APUs, and probably also on Apple and newer Intel.
cmrdporcupine 5 hours ago||
Thanks; I have another, currently private, repo that targets both pure CPU inference and wgpu (to vulkan.) It's somewhat similar but... different. Shares some common pieces but needs to be refactored to share more.

But it's been hard to make it competitive with CUDA. At least on this Spark and my only non-NVIDIA machine (which only has 16GB unified relatively slow RAM.)

hedgehog 4 hours ago||
I know a little bit about this problem space from previous work (we were working on performance-portable deep learning back around 2016). The infrastructure has improved but as far as I can tell not many teams have really "squeezed the toothpaste tube" and worked through performance issues systematically. These days a small team and robots can probably do it though.
cmrdporcupine 4 hours ago||
At my day job I may get access to big AMD AI iron in a couple months (to do research/performance tuning with). That could be interesting. Though that's likely to be of a very different shape from consumer Vulkan. I'd still like to have a Strix Halo to futz with. But I'll wait for RAM prices to drop. (Hah!). I do have an older BC250 board lying around but that only has 16GB RAM.

I got prefill up to 190 tok/sec just now, BTW.

amclennon 16 hours ago||
It looks like this also undercuts the already absurdly inexpensive Deepseek Flash in pricing. Wild.
geooff_ 16 hours ago||
Where are you seeing that? At the bottom of this post from Qwen I see:

Qwen 3.8 flash: $0.16 / $0.47

Compared to

Deepseek 0723: $0.03 / $0.075

(units in USD/m tok)

twohaibei 16 hours ago|||
0.03 / 0.075 ? Where can i get that prices? Especially during peak hours DS4flash became much more money hungry than last month.

https://api-docs.deepseek.com/quick_start/pricing

kaelwd 15 hours ago||
https://openrouter.ai/deepseek/deepseek-v4-flash-0731?endpoi...

8t/s though apparently and their cache hit rate is terrible so I don't think it's worth it over Relace.

ls_stats 16 hours ago||||
Deepseek 0732 is $0.22/$0.66 off peak
water-drummer 10 hours ago|||
GLM-5.3-Flash which is larger and better, costs less than this
kzrdude 16 hours ago||
(Edited: I thought Qwen3.8 Flash Next was smaller, but it's not, in bytes. Here's how they compare.)

DSV4 Flash 304B params, 167 GB download (at full size)

Qwen3.8 Flash Next 180B params, 360 GB download (at full size)

dalant979 15 hours ago||
180B?
kzrdude 15 hours ago||
125B regular params, 51B engrams, 4B MTP. Something like that. It should have a label of effectively 125B params with A6B (6B active).
potus_kushner 7 hours ago||
at first this looked like something one could run on CPU with 64GB RAM with a 2-3 bit quant, at possibly half the speed of 3.6 35B-A3B, however the 50B ngram sidecar makes it impossible. and oddly, unsloth's page lists the ngrams as 50GB even though they say it's in 4 bits. should be 25GB according to my math. anyway, the new ngram architecture makes it pretty much unusable for regular folks who cant afford more than 32-64 GB ram in this RAMocalypse.
garo-pro 15 hours ago||
Interestingly they also share the parameter count for Qwen 3.7 Plus (397 b a17b). I don't think these were known before but I might be wrong.
kzrdude 9 hours ago|
I guess it was obscure before, but someone did "know" it: https://old.reddit.com/r/Qwen_AI/comments/1u7xnvq/how_big_is...
martinald 16 hours ago||
FYI: nothing seems to be able to run this (easily) yet. llama.cpp, vllm etc I couldn't get working because of no support in the mainline version.
kzrdude 16 hours ago||
They are giving pointers to how to run it now using for example https://recipes.vllm.ai/Qwen/Qwen3.8-Flash-Next (and an especially provided vllm release).
martinald 15 hours ago||
ah I don't think that page was up when I checked, it 404ed!
flounder3 10 hours ago|||
Relevant PR: https://github.com/ggml-org/llama.cpp/pull/27742

This branch works now: https://github.com/unslothai/llama.cpp/tree/qwen4exp/qwen3.8...

  cmake -B build -DGGML_CUDA=ON
or

  cmake -B build -DGGML_METAL=ON
then

  cmake --build build --config Release -j --target llama-server llama-cli
a_humean 15 hours ago||
Probably going to take a 1-3 days for support to land in llama.cpp and vllm.
anon373839 15 hours ago|
Does anyone have an idea how this might perform on a DGX Spark at longer contexts? I've been trying to investigate their performance with these medium-sized MoE models, but I'm seeing a lot of incomplete and conflicting information. The 273 GB/s bandwidth looks awfully bad on paper...
colingauvin 3 hours ago||
A single Spark alone is not worth the price. You are paying $1000 just for networking equipment you aren't using. At 2x it starts to maybe become worth it if you don't want to deal with Apple. Outside of the newest Macs, I can't think of anything else you can get 256 GB ~550 GB/s memory bandwith for $8200. Even at 3-4 Sparks it scales relatively well.

With 2x Sparks, I am getting 40 t/s. I'd guess that without MTP you'd get 12-15 on 1 Spark, maybe 20 with MTP?

rohansood15 14 hours ago||
Given the new architecture, speeds are harder to estimate. Max would be ~40 tok/s.
lxkarthi 13 hours ago||
I can run Deepseek flash 0731 version (ds4, esl3) on single DGX spark. getting around ~20 tok/s. It's great. Quantized version of this model would probably run on the DGX spark. I am excited to wait for quantized models that fits in single DGX spark.
More comments...