Hacker News new | past | comments | ask | show | jobs | submit
Will be interesting to see how Qwen3.8 27B compares against this once it releases this week. Seems like dense 30B is back in fashion?

EDIT: An open weight version of Muse Spark 1.2 is going to be released as well:

https://x.com/alexandr_wang/status/2086756152034066792

https://xcancel.com/alexandr_wang/status/2086756152034066792

Based on the benchmarks, it seems that Muse Glimmer barely edges out against Qwen3.6 27B, except for tool-calling skills (MCP, etc.). I wouldn't be surprised if they released it now because they are afraid they wouldn't beat Qwen3.8 27B.
I am glad they released it because I think we need a competitive culture of open weights that isn't just geopolitics.

But I have to say, I quite like the way Muse Glimmer thinks and talks. It's a cocky bastard in tone, but it's quite good, and its thinking traces are relatively terse.

{"dead":true,"deleted":true,"id":49254843,"parent":49248418,"time":1786435774,"type":"comment"}
Do AI companies make release plans based on upcoming other models like this? I would think all the processes that go into the repository and weight infrastructure pre-training, checkpointing, knowledge distillation, model compression, post training pipeline, ecosystem integrations, inference API, benchmarking, human eval/safety/alignment, docs, etc... all that dictates the release schedule.
Any company working in a competitive industry is generally aware of what their competitors are doing. PR is an important aspect to market success, so it factors into release schedule. It may not be the dominant factor given engineering constraints, but yea, it’s certainly a factor, and a large one at that.
Yes, not every model release is reactionary to other labs. Either they had hints for the release of other models or they cut efforts in late stage testing of the models to hit these earlier release dates. There’s always some flexibility. And there’s certainly the incentive to cannibalize the news cycles for competitor models.
I could imagine pulling out all the stops to get a release over the finish line a week early if you're worried about being surpassed by another release
Yeah but you can probably have everything ready and then accelerate as necessary. Meta itself did this when releasing Llama 4, it was a really botched release right when they were feeling the heat from DeepSeek and others.
> ...all that dictates the release schedule.

AI companies release models when they are ready - not on a set schedule. The steps are required to produce a release candidate, so a company can choose to bless the RC with the best metrics at any time - or alternatively continue (post/)training newer RCs if they feel they can do better, and they have time. When a model is ready for release is subjective, and can take into consideration what the competition is doing.

An obvious counter-example to schedules driving releases is the still unreleased Gemini 3.6 Pro.

There has been a long history of AI model releases made shortly before or after a major planned release by another company. Almost always to upstage or steal thunder.

Just recently, Minimax H3 released as open weights on the eve of Seedance 2.5 global availability. It's not as good, but it's good enough and it's completely open.

Flux 3, which is nowhere near as good as either, suddenly announced their release once news of these other two became public. They knew if they waited they'd be ignored. It didn't really help them much, unfortunately.

The LLM releases are even more rivalrous.

And don't forget all of the competing launches planned before Google IO or major release events.

Companies like to eat into the news and press cycle of their rivals.

I've seen it here on HN (it's particularly noticeable via the /active page) multiple times. If Google, OpenAI or Anthropic release something significant, odds are good you'll see a headline from one of the others.
BFL is in a rough spot here too. It’s pretty much looking like a repeat of the exact same situation they had when they released Flux2 at the same time Z Image Turbo came out and completely overshadowed their launch.

Minimax H3 can run exceptionally fast (10 minutes for a 15 second 0.5mp video and that's stock cuda 13), works on 16 GB VRAM GPUs, etc. If Flux3 is anything like Flux2, it’s going to require an absolute monster truck of a machine and still run significantly slower. Even if it’s a better model, that won’t matter as much if nobody releases any LoRAs or fine-tunes for it.

Not to mention BFL licensing often feels deceptively confusing and restrictive.

>long history

Seems a bit premature of a statement lol

loading story #49242796
the last few items there (benchmarking, human evaluation, docs) can be rushed or skipped by leadership if they want to beat comp. they probably spend a few weeks on those things normally
One window that can be shortened is working with software ecosystem and upstream partners; think day 0 on together, fireworks, Unsloth, etc. That obviously happens from partners getting embargoed weights early.
It will also be very interesting to see some direct head to head benchmarks between qwen 3.6 27B (let's say all at Q8 XK quantization, using the GGUF that unsloth publishes as a baseline) vs 3.8 27B. Particularly in tool use, terminal use.

The whole class of what can reasonably fit in a single GPU is an interesting category of LLM, and based on the results I've seen from 3.6 35B A3B and 27B versus what existed a year prior, it seems there's a lot of room for advancement.

I would hope that Qwen 3.8 is better. It's been 4 months, and we've seen almost no progress in this space.

As people have called out, Glimmer appears to be a trade-off rather than a clear winner.

And from what I've been reading, no one is expecting Qwen 3.8's model in this space to be a clear winner, but just slightly and marginally better.

That's a little concerning as DeepSeek v4 Flash proved at it larger sizes there's a ton of room left to compress knowledge.

If we don't see something that's substantially better in the ~30B param space soon - it would appear we might've saturated that size with knowledge.

> If we don't see something that's substantially better in the ~30B param space soon - it would appear we might've saturated that size with knowledge.

I wouldn't be quite so pessimistic. We may have saturated the current approach, but I think there's a lot still left in terms of compression, attention, active parameters, caching etc. etc.

I don’t think four months without a major breakthrough is cause to abandon all hope just yet. ;) The wild pace of LLM development is highly atypical, and we’re still in the ‘initial rush’ phase of development.

For contrast, the Newcomen steam engine (widely considered the first commercially useful engine) was used for over 60 years before the next major improvements. Now, 300 years later, we’re still finding ways to significantly improve heat engines.

loading story #49252709
I honestly expect that major advances in the open 30B dense space will take about a year, but expect incremental advances every couple of months from different developers in the meantime.

Qwen 3.6 27B was already a massive gift to smaller homelabs around the world; anything more is just a delightful surprise.

For so many non-coding workflows, tool calling is more important.
Qwen3.6 27B has really punched above its weight for a long time. It’s shockingly good for its size. Very excited to see what 3.8 can do.
Qwen3.6 27B is the go-to medium sized model for coding, so beating it is not a small achievement
There is a finetune Qwen3.6-27B-Fable-Fus-711-UnHeretic-NM-DAU-NEO-MAX-NEO which seems to be as good at coding as vanilla Qwen, but way, way better at creative writing than Qwen and even better than Gemma 4 26 and 31b.
I saw that one in the "Popular models" sort at Hugging Face and tried it on some tasks I do frequently to compare models, and it feels damaged by the fine-tune, to me. It wrote security bugs into the code (probably just sloppy thinking, not intentional), it exhibited looping behavior in some configurations in llama.cpp, configurations I regularly use with the regular 27B, and it failed to write unit tests without being prompted (though the regular Qwen 27B tends to do so if it sees there are unit tests for everything in the repo). They have good benchmarks, but I'm not going to trust it. Also, that name is absolutely crazy.
loading story #49252737
loading story #49250555
Yes but it's also about 13 years old in LLM-years and 3.8 drops in a few days.
Yes, and also waiting for the next iteration of Gemma. Muse or Qwen are optimized for coding, while IMO Gemma is still better for non-coding tasks.

https://x.com/osanseviero/status/2086107547535122767

I am working on a project where we have to classify customer calls into more than 10 categories. As the client wants everything locally I tried a few local LLMs. Gemma turned out to be the best model for this task. The classification accuracy is impressive, and the client is happy that I am using an American model.
I guess the client is American.
loading story #49256808
You can partially tell by the tokeniser; which gives you some hint into the training corpus mix.

</div> is four Gemma4 tokens, but one Qwen3.6 token.

{"deleted":true,"id":49248506,"parent":49243395,"time":1786390046,"type":"comment"}
Looks like we have a /r/localllama dweller here.
Where do you find this information for each model?
When you look on HuggingFace.co at the files of a model, for each model you will see a file "tokenizer.json".

In that file you can see all tokens and their corresponding numeric codes.

The tokenizers are included in the open s̶o̶u̶r̶c̶e̶ weights releases; you wouldn’t be able to use the weights without the corresponding encoder/decoder, in fact.
> Will be interesting to see how Qwen3.8 27B compares against this once it releases this week

Considering that Meta distills Qwen[1] (and should!), it'd be hilarious if Muse loses the head-to-head; the "distillation attack!!1!" people claimed distillation on release n-1 is enough to match the intelligence of the latest version.

1. They wrote a paper about it

It’s really interesting timing, Qwen over thinking is what kills it for me. I’m just glad we have more options in this size class now.
I've been using Qwen3.6 35B A3B, and with reasoning turned on, I'd say 2/3 (give or take) of the tokens for a response are thinking tokens. Which at 70+ tps locally, that isn't that awful. I run an 80k context across 4-10 "agents" for my solo TTRPG, where Qwen is the GM, each NPC at a location, the director, and the narrator.

Each turn is about 45-60 seconds to generate all of the various responses. The GM and director have reasoning on, and the NPCs/Location/Narrator do not.

It's a fairly good "engine" for that. I'm not sure how a denser Qwen would do here regarding speed.

I like the tabletop RPG use case, and wanted to say: If your hardware likes it you should check out Gemma 4 for creative DMing use case. I found it to be much better at holding the plotlines and being creative on gaming turns. My experimental case was an audio-only Zork and Gemma 12B and even E4B were pretty good!
This sound very interesting, do you have any resource I could look at? Me and my son did a very rudimentary (compared to yours) setup to play Paranoia, but this is at another level.
I'll go over my repo, and see if it is hiding any API keys and maybe make it public. The issue I have is it relies on a nuget package that also isn't live (its in my local nuget feed).

I'm not sure what all is needed to make that work for people.

I'm working on something similar. My biggest annoyance is that the overly-helpful LLM was making every die roll succeed. I ended up building some tooling around rolling dice. Also some tooling around character stats and inventory management, so those don't get lost in context compression.
Is there some sort of dedicated tool for this type of setup, or did you hand-craft it ?
Somewhat hand rolled, somewhat claude coded.

Back in 2023 I started my own C# LLM library for doing tool calls and structured output, and over the years it has morphed bigger and bigger, and that is the backbone of almost all of my LLM-based projects.

I've never released it, but its easy to understand, and simple to add your own tools:

  [AIDescription("Get current weather for a location")]
  static string GetWeather(
    [AIDescription("The city name")] string city,
    [AIDescription("The country name")] string country,
    [AIDescription("Temperature unit", ["C", "F"])] string unit = "C")
  {
    // make some API call to a weather API and return a string to the LLM
    return $"The weather in {city}, {country} is 22°{unit} and sunny";
  }
  
  var chat = client.StartConversation("You are a helpful assistant with access to weather data.");
  var response = await chat.SendAsync<string>("What's the weather in London?", GetWeather);
I'm sure plenty of better libraries exist for this now, but in 2023, I don't think any existed in the dotnet ecosystem. I've never released it though, because I've never "finished" it.
loading story #49251807
Not parent, but I use Goose for my non-handcrafted Qwen use cases, I’m also working on handcrafting as well. Goose was the only harness that didnt bloat context too much with system prompts (like openclaw) and I could get reasonable web search working with Qwen.
Are you running inference in parallel? 70 tps seems low for parallel execution.
It is on a single 3090, and that seems to be where it averages out. I'll get 85tps on turn 0, but then it settles down to low 70s within a few turns, but holds steady at that.

My issue currently is KV Cache, because I can't keep enough parallel caches running (4 is where I'm at), so TTFT (is that the initialism?) can be long when I have a particularly large scene (basically more than 2 NPCs).

But my harness does let me offload to any OpenAI compatible endpoint, I just prefer local cuz free.

Just to play devil’s advocate: you can’t compare Qwen to a (proprietary/closed source) hosted model and deduce that Qwen is overthinking, as Qwen gives you the full reasoning/thinking trace while all the proprietary models now give you only a summary “to prevent distillation”, making it hard to properly compare apples to apples here.
You can compare Qwen with thinking to Qwen with no thinking though. I find my results are better without thinking because of overthinking.
No, but you can compare it to the similarly-sized Gemma4 model and see the difference, it's not subtle
You can tell how long the cloud models spend thinking based on the delay.

The Qwen models have a habit of going into thought loops where they go in circles for a while.

People say Qwen overthinks because they analyzed the thinking traces, and Qwen finds the answer relatively quickly but then second guesses itself multiple times for another 20,000+ tokens. Regardless of what other models do, that's clearly overthinking.
Qwen thinking is really good in Mandarin; and probably natively trained the most there.

Try a system prompt requiring it to think in Mandarin, while still delivering the response in the user’s language.

This is most likely because the vast majority of the information the model absorbed during training was in Chinese. As a native Mandarin speaker, I frequently need to convert the prompt into English and output it in English in order to avoid that the model falls back into Chinese reasoning logic.

PS: Switching the thinking process from Chinese to English can also significantly circumvent certain self-censorship mechanisms built into the model.

Is the quality of the thinking better or it's just shorter since Mandarin is more compact?
Disable thinking? I think many harnesses disable thinking on Qwen anyways because it interferes with tool calling.
Llamscpp provides reasoning budget and message. You can use the message to redirect it.

Once you get the agent and message consistent,itll keep moving.

You can use any message you want, but the model was tested to react reasonably well to the specific token sequence of "\nConsidering the limited time by the user, I have to give the solution based on the thinking directly now.\n</think>.\n\n" (from a Alibaba paper, struggling to find it now)

Edit: arXiv:2505.09388 Qwen3 Technical Report

loading story #49255417
Makes me feel hopeful. Things felt more positive around the llama 3 era. Now it’s like a dark, dreadful race.
I feel you. not sure if the "Glimmer" (of hope) branding is intentional to capture this vibe
yes i think everyone is waiting to see that ;d, i've been on qwen for the last year and a half now.
Well, it has to, since even the MoE models can't really hold a conversation.
> Seems like dense 30B is back in fashion?

Huh, well... no? Gemma A4B and Qwen A3B are quite popular in fact. I'm sure 3.8 35B A3B will outperform 3.6 27B by all metrics

I'd be skeptical w.r.t. "by all metrics".

Qwen3.6 is a definitive, significant downgrade from Qwen3.5 for creative writing and prose for example. Yes, it's better at agentic and coding, but it regresses in many non-coding areas compared to Qwen3.5.

Of course, I do expect the 3.8 ones to perform better for agentic coding.

One thing I would caution is staying out of the prediction market like this.

Tech tends to get boring when you judge current products against the hypothetical capabilities of unannounced products that may never ship. It's like comparing Nikon cameras against Canon camera rumours, or comparing iPhones against unannounced and therefore largely imaginary Samsungs.

- If they do a Qwen 3.8 35B A3B (and I hope they do because I love the 3.6 version)

- and if it beats 3.6 27B by all metrics

… then the local open weights world will be a better place.

But they have said nothing about it and they dropped several weight classes for 3.6, so who is to say they won't drop the 35B? And even if they don't, this is a tall order; why would the MoE tradeoffs no longer be apparent? (Again, I really like both the Qwen and Gemma MoEs)

FWIW I am enjoying testing Muse Glimmer — it's really quite impressive on chat, has nice terse and even amusing thinking traces, a bit of brass to it, and I'm hoping it will be good on agentic stuff.

> Seems like dense 30B is back in fashion?

Surprising that Meta don't host this model, even as rate-limited free-tier.

> open weight version of Muse Spark 1.2

Wait. Is this "version" different from what Meta serves?

It seems worse than 3.6, but a bit smaller.

UPD. was wrong on smaller, it's actually much larger

I'll back up your smaller claim, but be specific that it's UD-Q4_K_XL size:

- muse glimmer: 15.9GB

- qwen 3.6 27B: 17.6GB

My video card is so close to its limit that these GB thresholds are mattering too much for me :D

How is 30B smaller than 27B?
It uses fractal compression
They say it is trained with quantization awareness, so it should only be 15GB or so. Qwen was only trained in FP8 with QAT.

UPD, NVM, got misled by comments here. It is actually almost 60 GB so much larger

Quantization awareness doesn’t change the size of the weights, just means it won’t degrade when quantized. QAT = quantization aware training. They will both be very similar in size at the same quant.
loading story #49243083