Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Wow. This model is so good, and we have GLM 5.3 (seems great voor security related work) and Deepseek. In a few months we'll have Fable/Sol-like capabilities that are not coming from the big US companies. I feel as a programmer that that is more than enough. How wil OpenAI and Anthropic survive when frontier model intelligence becomes commoditized?
    by svdr
  • The demand curve for speed and intelligence seems pretty steep to me.

    If you look at the hiring marketplace, being just marginally better than your peers can be very lucrative.

    If you’re competing on speed or capability as a company (or as an employee), you’re probably going to be willing to pay for the frontier.

    by awb
  • They’ll certainly try to stymie people by colluding with manufacturers until we get nvidia level hardware or LLM ASICs from the East.
  • I stopped using Fable and Opus 5 because I literally can't understand the output. The waffle is so intense it no longer makes sense. I don't understand who is using those to get real work done.

    I'm using kimi-k3 on a real high level dev & analysis task at the moment (with Gemini flash for fast implementation) and it is fantastic.

    I think we have passed the point where frontier intelligence is commoditized.

  • Image->html test for this.

    Original images: https://image.non.io/neonRamenDesigns.webp

    Qwen 3.8 build: https://html.non.io/neonRamenQwen3.8-27b

    Overall I'm very impressed with how well this did. It's a big improvement over 3.6, and it feels on-par with some much, much larger models. I think this one is on-par with Gemini 3.7 Flash.

    One thing to note - the build for this on my RTX 6000 pro blackwell took a long time. Easily one of the longest builds I've done. It took around 2 hours to build the site. Obviously we'll have some quants for this soon that will accelerate things, but I was still surprised with how long it took.

    Comparison builds from this week:

    https://html.non.io/neonRamenGemini3.7

    https://html.non.io/neonRamenGLM5.3 (note: non-multimodal)

    by jjcm
  • what token/s?
  • harness setup? how much vram ? how are you handling a 2hr long build ? multiple sessions? fan out sessions (subagents)?
  • Thank you Qwen team for this release.

    Compared to closed weight (especially unreleased and access-limited) and open weight/source large sparse MoE LLMs/VLMs, open weight/source small dense models benefits public the most because they just reaches more people.

    Compared to Qwen 3.6, 3.8's thinking style changed drastically. With xhigh budget, it thinks a lot MORE, and longer thinking session directly translates to better performance. This tradeoff between performance and computation, memory, etc. is meaningful to me.

    However, because Qwen 3.6 and 3.8 share the same architecture, with 32GB vram, llama.cpp, IQ4_XS model, MTP and FP16 mmproj, I can only get 200k context, which is not good compared to 640k context of muse glimmer. Hopefully this problem will be solved in Qwen 4.0 release.

  • I could kiss you right now
  • If the benchmarks don't lie, this is getting very close to Opus 4.6 capability - which was the turning point for me for when AI was "good enough" that it became very hard to justify not using it.

    I'm sure there's some benchmaxxing going on, and some things you get only with a a larger model.

    But I'm feeling pretty confident if not by Gemma 5 than by mid 2028 we'll have local models that are almost always as good as Opus 4.6 was and in many cases far better.

  • What kind of things you only get with a larger model?
  • If anyone else is running this on an RTX 5090, https://github.com/Neroued/ninfer as inference engine gets me ~138 tokens/second, roughly double what I get with a naive llama.cpp setup.
  • Yep, same, testing it now and it flies!
  • It there anything similar for RTX 3090 and RTX 4090?
  • Just enable MTP on llama.cpp and you will get the same decode speeds.
  • Amazingly enough, Hacker News decided to show this to me as the top comment, I'm also running an rtx 5090 and trying it out now, thanks for the tip!

    Edit: Absolutely blazing fast! Getting 163 tokens/sec on WSL and it generated a pretty sweet Pelican.

    https://gist.github.com/hansale/ed9e73fe35165a58ea2af6b1632a...

  • One thing a lot of people don't seem to factor when hyping Qwen is how much models like this tend to 'overthink' with seemingly endless 'second guessing'. 3.8 seems no different from what I've tried thus far.

    As capable as it is, it's hard to justify using it when a competing model (e.g. Gemma4:26b-a3b) can consistently achieve the same or similar response with only 1/10th as many 'thinking' tokens, achieve much higher tokens/second, and take a small fraction of the time. I suppose 'YMMV' depending on your use case.

    Also, I haven't used it enough yet to see if it's prone to infinite looping, but its predecessors sure were.

  • gemma4 can't hold a candle to 3.6
  • You can add a thinking budget thats not much effort in llamacpp. You can align the cut off message with your agent instructions.

    What you describe is a engineering harness problem.

    If you, and i mean the royal you, actually read tge thinking traces you can see and figure out where its stuck

    This means an effective harness would observe when the model is overthinking and step in with reasonable redirection, like increasing logging.

    Llamacpp can set reasoning budget and message per reauest, so it can be dynamic.

    Your complaint is "skill issue" based and will be resolved by people who do something ither than vibe code react demos.

  • > As capable as it is, it's hard to justify using it when a competing model (e.g. Gemma4:26b-a3b) can consistently achieve the same or similar response with only 1/10th as many 'thinking' tokens, achieve much higher tokens/second, and take a small fraction of the time.

    Not my experience at all. On my M1 Max MacBook Pro, Qwen 3.6 35B-A3B provides better responses in similar time (~60 tokens/second, vs. 50 for Gemma 4 26B-A3B). 3.8 27B is slower, being a dense model, but so are dense Gemmas.

  • This is why the "reduce thinking" approach of BottleCapAI is both quite interesting and very useful in practice:

    https://huggingface.co/bottlecapai/ThinkingCap-Qwen3.6-27B

  • “Thinking” is just a guiding methodology to help iterations (between the initial prompt, results, and a mixture of harness back and forth to the LLM) converge on something sane in a massive parameter space.

    I like to think of it much like (as a common example most people can relate to) the Newton-Rhapson method for finding roots of a (mathematic) function. Your initial prompt runs, then the ‘harness’ kicks in using whatever methodologies are behind them to iterate on that prompt (back and forth with the model, occasionally with the user to get better guidance) and refine the outputs to hopefully converge back to some sensible output or actions the user was initially looking for.

    So you’re hoping for an LLM that sort of ‘zero shots’ or needs minimal iterations from a prompt to give usable results. I find from my anecdata it varies across models and what I’m trying to get it to converge on. I tend to prefer models to not zero shot attempt because they tend to not do great, I want them to get feedback often to let me push them down the route of convergence in spaces I already understand well, meanwhile I like them to explore and give me new paths in spaces I’m not too familiar with.

    That’s really what all that “second guessing” is, it’s making sure you’re following a sane path in a massive parameter space of an ambiguously defined problem. Imagine if in Newton’s method you checked the slope and it didn’t decrease from the last iteration and you just say “screw it let’s keep trying that direction.” LLMs and their harnesses tend not to have that base assumption like iteration on decreasing slopes to guide them closer to convergence, it’s a lot messier.

  • Use 3.6 27b as a daily driver for months with charmbracelet crush. Gemma 26b-A3b is not even remotely comparable in terms of coding for me. YMMV depending on how you work, what harness you use, etc I suppose.
  • IME this is a strong/reliable model smell, you typically see smarter and less benchmaxxed models' thinking traces spending more time exploring the solution space, and benchmaxxed models more time trying to refine/decide on the response contents. It has always been a big problem with qwen.

    In general it's kind of a benchmaxxing/distillation (I don't mean that pejoratively here, read on) artifact where test time compute's purpose is to refine/zero-in on a particular input:output pair. Basically they're trying to "remember"/re-derive the answer rather than arrive at it deductively - it gets comical/absurd when you see it expending a huge amount of tokens trying to figure out the answer to some trivial question or response to some input, as if it were a trick question or the choice of wording was of the utmost importance. But it's not a bad thing when the output matters or the task is hard: basically the model has been trained to respond/act like a much smarter model and it's probably better for it to overgeneralize that behavior.

    Also, IME Gemma and most other local models that support thinking tend to have the same problem, and it's partly only a "problem" because they give you access to the thinking tokens themselves (which you don't in many cases see when working with frontier american models) and you can actually see how they're getting spent. For the local or bulk (runnin on owned or rented hardware) use case where you are paying in time/watts rather than purely by the token, IMO it's a good idea to just look at the task success rate / time per task and not worry about the raw thinking token count.

  • As usual, the Jinja templates are messed up so use this [0] to reduce or turn off thinking, fix tool calling, keep a 100% KV cache hit rate, etc.

    [0] https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates

  • Depends on your tooling and quant? I grabbed the unsloth Q3 and it works out if the box in opencode. I had issues with OpenWebUI with a random 3.6 A3B.
  • Thanks this bumped my agent success rate from 67% to 92.5% (!!!)
  • Interesting. Why don't the unsloth guides (https://unsloth.ai/docs/models/qwen3.8) mention this? Do they already include the fixes in their GGUFs?