Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model

qwen.ai

Post reply on HN
Print view View original

431–440 of 482 posts

Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model

#431

Post by hedgehog »

russellbeattie wrote: post #319
simonw wrote: post #106

The pelican is excellent for a 16.8GB quantized local model: https://simonwillison.net/2026/Apr/22/qwen36-27b/ I ran it on an M5 Pro with 128GB of RAM, but it only needs ~20GB of that. I expect it will run OK on a 32GB machine. Performance numbers: Reading: 20 tokens, 0.4s, 54.32 tokens/s Generation: 4,444 tokens, 2min 53s, 25.57 tokens/s I like it better than the pelican I got from Opus 4.7 the other day: https://si…

You'd think by now the LLMs would have figured out that the body of a bicycle is basically just a bisected rhombus. → ◿◸ (I hope I don't ruin the test.)

It would be funny to do an optimization pass to find a compact description of how to coax an accurate pelican bicycle out of a few of the current models, then just blast that snippet everywhere.

Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model

#432

Post by Havoc »

2001zhaozhao wrote: post #369
Havoc wrote: post #323

Earlier quoted context omitted.

That's definitely doable. Planning similar except more webscraping / newsfeed / monitoring like. I've got 3x SBCs that can run the Gemma 4 26B MoE on NPU. Around 4W extra power, 3 tokens a second...so that can hammer away at tasks 24/7 without moving the needle on electricity bill

I wonder if some investment firms are already doing this internally at a large scale. (Probably.)

They are - I’ve seen it.

They just use APIs though. There is very little interest within them to do the model engineering and inference in house.

Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model

#433

Post by zozbot234 »

adrian_b wrote: post #412
zozbot234 wrote: post #386

Earlier quoted context omitted.

AIUI, the main obstacle to maximizing performance with SSD offload is that existing GGUF files for MoE models are not necessarily laid out so that fetching a single MoE layer-expert can be done by reading a single sequential extent off the file. It may be that the GGUF format is already flexible enough in its layout configuration that this is doable with a simple conversion; but if not, the GGUF specification would h…

You are right, which is why I do not intend to use a GGUF file but a set of files with a different layout, and this is why I need to make changes in llama.cpp.

If you have to come up with a custom format anyway, why not just make it a draft extension to GGUF layout definitions (something like "coalesced expert fetch" or the like) and submit it for inclusion in the standard? Then future models could be autoconverted to such a format.

Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model

#434

Post by domh »

qudat wrote: post #332
domh wrote: post #228

Earlier quoted context omitted.

I had the best success yet earlier today running https://pi.dev with a local gemma4 model on ollama on my m4 Mac with 48GB ram. I think pi is a lot lighter than Claude code.

I didn’t think pi supported local models?

It does! Ollama provides a helper to launch it with the local model too: https://docs.ollama.com/integrations/pi

So you can do:

   ollama launch pi --model gemma4:26b
And it launches and points to the local model in one command. pi seems to do some setting caching too, because after doing the above once I can just do `pi` and it's already setup to the local model.

Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model

#435

Post by simonw »

acchow wrote: post #428
simonw wrote: post #335

Earlier quoted context omitted.

Gemini did exactly that, and boasted about it at launch: https://x.com/JeffDean/status/2024525132266688757

That post doesn't say anything about training for SVG generation

https://blog.google/innovation-and-ai/models-and-research/ge...

> Code-based animation: 3.1 Pro can generate website-ready, animated SVGs directly from a text prompt. Because these are built in pure code rather than pixels, they remain crisp at any scale and maintain incredibly small file sizes compared to traditional video.

Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model

#436

Post by AlexC04 »

datadrivenangel wrote: post #279

So far I'm unimpressed for local inference. got 11 tokens per second on omlx on an M5 Pro with 128gb of ram, so it took an hour to write a few hundred lines of code that didn't work. Opus and Sonnet in CC the same task successfully in a matter of minutes. The 3.6:35b model seemed okay on ollama yesterday. Need to check out other harnesses for this besides claude code, but the local models are just painfully slow.

One other thing you might want to check out for running locally. (I have not independently verified yet, it's on the TODO list though)

https://docs.vllm.ai/en/latest/api/vllm/model_executor/layer...

vLLM apparently already has an implementation of turboquant available - which is said to losslessly reduce the memory footprint required by 6x and improve inference speed by 8x.

From what I understand, the steps are:

1. launch vLLM 2. execute a vLLM configure command like "use kv-turboquant for model xyz" 3. that's it

I've got two kids under 8 years old, a full time job, and a developer-tools project that takes like 105% of my mental interests... so there's been a bit of a challenge finding the time to swap from ollama to vLLM in order to find out if that is true.

SO buyer beware :D - and also - if anyone tries it, please let me know if it is worth the time to try it!

Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model

#438

Post by fwipsy »

synergy20 wrote: post #437

wish I had a rtx5090 instead of the rtx4090 so I can run this, need 32GB VRAM I assume, no I use Linux and I do not enjoy MacOS, I wish x86 family has something like M5 Pro though.

I was just wishing I had 24gb rather than 16gb so I could run q4 comfortably. Unsloth q4 variants are 15.4gb-17.6gb so it seems at least well worth trying on a 4090.

Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model

#440

Post by vintermann »

zargon wrote: post #162
m3kw9 wrote: post #153

Earlier quoted context omitted.

if they cook these in, i wonder what else was cooked in there to make it look good.

Everything is benchmaxxed. Whack-a-mole training is at least as representative of what is getting added to models as more general training advances.

I have an out-there idea. Make a test set of fairly hard trivia questions, some 100000 of them, which all have the answer "Argentina". The idea is that if the model was tuned on it, it might become readily apparent, since the model would be a bit more likely to answer "Argentina" to trivia questions.

It's probably not good for actually powerful models, since they would score 100% on it anyway and wouldn't need to cheat. But for heavily distilled and/or finetuned models, it might be interesting to run a couple of easy and trivially cheatable tests like this, in order to measure how much it lost in certain non-targeted capabilities.

Post reply on HN